4 ms·

Why can’t the QA people just live on the dev team? Why do they need to be siloed away or not exist? I had this in my past job. Have 1 QA per two developers, th

Why can’t the QA people just live on the dev team? Why do they need to be siloed away or not exist? I had this in my past job. Have 1 QA per two developers, the QA sits with those two developers, and you are constantly telling them when a build is done and on staging. They write tests, do some manual checks, and then tell you how it is going relatively immediately. They also handle the problem of reproducing bugs and narrowing down exactly where they occur, which is not trivial. For all the faults in that organization (including letting our test runner be broken for months), we didn’t put out a lot of bugs and we found all manner of strange edge cases very quickly.

innagadadavida 5y ago
> Why can’t the QA people just live on the dev team? Because there is little incentive for devs to police themselves and there could be multiple dev teams spanning client/server that needs to be integrated and tested. A slightly better org to own QA would be product team.
- alistairSH 5y ago
  Each team should have some QA resources. Server can be tested independent of client, etc. Then the QA staff work together to ensure appropriate systems integration tests. Siloed QA team runs the risk of becoming a bottleneck as work from disparate teams comes through.
- damontal 5y ago
  Sure there’s incentives for devs to police themselves. I’d rather catch problems early than have a to deal with a shitstorm from pissed off product owners and VPs when bugs are found in production. But our QA person is on another team. I’d much rather have them on my team.
GaveUp 5y ago
The key part in that is communication. That’s makes all the difference whether it be with BA’s, QA’s, or the end user. Speeds up the development cycle and greatly reduces the number of bugs. The best experience I had was on a team that had essentially 2 BA’s and 7 devs. There was constant communication to clarify actual requirements, devs would build automated tests off them, BA’s would test against the requirements and then a business user would do a final look over. All in all features were able to be released usually within a day and there would be days we’d get out 3 or 4 releases. Only in one case did a major bug get released to production and the root cause of that was poorly worded regulations which had a clarifying errata come out at the 11th hour. For as many faults as that company had that caused me to move on I’ve yet to run across a team that functioned as well as that one did.
- failwhaleshark 5y ago
  Communication is great until someone becomes unreasonable and doesn't want to do something. Trust but the chain-of-command must verify. Shouldn't need to, but it should be there as insurance.
  - japorized 5y ago
    People don’t just randomly become unreasonable halfway through. If they’d be unreasonable, they’d do so from the start. If it happens midway, there’s almost always some reason. That said, I do I agree that the chain of command should always be aware of what’s going on, or have a reliable way to find out.
    - passerby1 5y ago
      > If they’d be unreasonable, they’d do so from the start. It sounds like a sentence about programs, not people. Consider people tend to make mistakes and being flexible in their intentions.
      - failwhaleshark 5y ago
        Yep. People aren't rational, compliant, cooperative actors 24/7. Agendas. Bad days. Illnesses. Family events. So then it's unreasonable and foolish to extend trust unconditionally, perpetually, and without auditing. If all people were angels, no government (or whoever regulates) would be necessary. If all people (and systems) were perfect, no backups would be needed.
failwhaleshark 5y ago
Terrible idea. The dev team manager is focused on growing new features in the next release. QA is focused on the excellent of the current release. Subordinating quality to new releases is the result. In a similar situation, devops supposedly addressed similar tensions of dev and ops.
- beatthatflight 5y ago
  QA here, disagree. In this situation QA is focused on the quality of the new features, so they're already excellent when they go out into the current release.
  - failwhaleshark 5y ago
    What about ongoing quality and quality regressions of existing functionality? What happens when the dev mgr asks QA to rush testing? Been There, Done That, Bought The T-Shirt, Said "No," and Tendered a Resignation
    - beatthatflight 5y ago
      do that too. Tests for new features also include regression testing, as does integration tests and automation CI/CD tests. In our working agile environments, you know the team's velocity. Managers know the team's velocity. Points per story include QA work. If they want something faster in this sprint, something else has to be taken out. Firm but fair, and it works very well.
- MattGaiser 5y ago
  I agree in theory and there are certainly teams where this could happen, but what happened on this team was that the bugs were found so quickly than the fixes were also quick (I would always get a bug report the same day and often within the hour), making shipping stuff with few bugs relatively painless. Was there pressure to keep releasing? Yes. But with the rapid feedback, it never became too onerous to get them done anyway.
- midev 5y ago
colordrops 5y ago
Makes a lot of sense to me. The best and highest quality software I've ever worked on (people could die if it failed) had the devs doing testing and writing automated tests, with an intermingled QA team doing further testing, and often jumping in on dev.
fredsters_s 5y ago
I think the ideal team setup is one you allude to: a cross-functional team with experts from each domain collaborating together. My intent was not to say that can't happen - but that it typically doesn't, because of specialization and organizational politics. The vast majority of software teams have a siloed QA team. Why? That's for another thread :)
Cthulhu_ 5y ago
We had that in one of my assignments. It kinda works, but at the same time, they were a gatekeeper, a barrier, and usually a release was delayed for a day while they tested out their new testing approach and went through their excel sheets of things to test for.
woutr_be 5y ago
I’ve experienced both, were the dev team also had to do QA, and a dev team with QA people. I personally hated writing automated tests, but it did give me a much deeper understanding of the product. Especially when writing tests for features I wasn’t working on. That said, having a dedicated QA person within the team is far more effective. The dev team can build features, while our QA person works with the business to come up with test cases and test data.

innagadadavida 5y ago

> Why can’t the QA people just live on the dev team? Because there is little incentive for devs to police themselves and there could be multiple dev teams spanning client/server that needs to be integrated and tested. A slightly better org to own QA would be product team.

alistairSH 5y ago
Each team should have some QA resources. Server can be tested independent of client, etc. Then the QA staff work together to ensure appropriate systems integration tests. Siloed QA team runs the risk of becoming a bottleneck as work from disparate teams comes through.
damontal 5y ago
Sure there’s incentives for devs to police themselves. I’d rather catch problems early than have a to deal with a shitstorm from pissed off product owners and VPs when bugs are found in production. But our QA person is on another team. I’d much rather have them on my team.

GaveUp 5y ago

The key part in that is communication. That’s makes all the difference whether it be with BA’s, QA’s, or the end user. Speeds up the development cycle and greatly reduces the number of bugs. The best experience I had was on a team that had essentially 2 BA’s and 7 devs. There was constant communication to clarify actual requirements, devs would build automated tests off them, BA’s would test against the requirements and then a business user would do a final look over. All in all features were able to be released usually within a day and there would be days we’d get out 3 or 4 releases. Only in one case did a major bug get released to production and the root cause of that was poorly worded regulations which had a clarifying errata come out at the 11th hour. For as many faults as that company had that caused me to move on I’ve yet to run across a team that functioned as well as that one did.

failwhaleshark 5y ago
Communication is great until someone becomes unreasonable and doesn't want to do something. Trust but the chain-of-command must verify. Shouldn't need to, but it should be there as insurance.
- japorized 5y ago
  People don’t just randomly become unreasonable halfway through. If they’d be unreasonable, they’d do so from the start. If it happens midway, there’s almost always some reason. That said, I do I agree that the chain of command should always be aware of what’s going on, or have a reliable way to find out.
  - passerby1 5y ago
    > If they’d be unreasonable, they’d do so from the start. It sounds like a sentence about programs, not people. Consider people tend to make mistakes and being flexible in their intentions.
    - failwhaleshark 5y ago
      Yep. People aren't rational, compliant, cooperative actors 24/7. Agendas. Bad days. Illnesses. Family events. So then it's unreasonable and foolish to extend trust unconditionally, perpetually, and without auditing. If all people were angels, no government (or whoever regulates) would be necessary. If all people (and systems) were perfect, no backups would be needed.

failwhaleshark 5y ago

Terrible idea. The dev team manager is focused on growing new features in the next release. QA is focused on the excellent of the current release. Subordinating quality to new releases is the result. In a similar situation, devops supposedly addressed similar tensions of dev and ops.

beatthatflight 5y ago
QA here, disagree. In this situation QA is focused on the quality of the new features, so they're already excellent when they go out into the current release.
- failwhaleshark 5y ago
  What about ongoing quality and quality regressions of existing functionality? What happens when the dev mgr asks QA to rush testing? Been There, Done That, Bought The T-Shirt, Said "No," and Tendered a Resignation
  - beatthatflight 5y ago
    do that too. Tests for new features also include regression testing, as does integration tests and automation CI/CD tests. In our working agile environments, you know the team's velocity. Managers know the team's velocity. Points per story include QA work. If they want something faster in this sprint, something else has to be taken out. Firm but fair, and it works very well.
MattGaiser 5y ago
I agree in theory and there are certainly teams where this could happen, but what happened on this team was that the bugs were found so quickly than the fixes were also quick (I would always get a bug report the same day and often within the hour), making shipping stuff with few bugs relatively painless. Was there pressure to keep releasing? Yes. But with the rapid feedback, it never became too onerous to get them done anyway.
midev 5y ago

colordrops 5y ago

Makes a lot of sense to me. The best and highest quality software I've ever worked on (people could die if it failed) had the devs doing testing and writing automated tests, with an intermingled QA team doing further testing, and often jumping in on dev.

fredsters_s 5y ago

I think the ideal team setup is one you allude to: a cross-functional team with experts from each domain collaborating together. My intent was not to say that can't happen - but that it typically doesn't, because of specialization and organizational politics. The vast majority of software teams have a siloed QA team. Why? That's for another thread :)

Cthulhu_ 5y ago

We had that in one of my assignments. It kinda works, but at the same time, they were a gatekeeper, a barrier, and usually a release was delayed for a day while they tested out their new testing approach and went through their excel sheets of things to test for.

woutr_be 5y ago

I’ve experienced both, were the dev team also had to do QA, and a dev team with QA people. I personally hated writing automated tests, but it did give me a much deeper understanding of the product. Especially when writing tests for features I wasn’t working on. That said, having a dedicated QA person within the team is far more effective. The dev team can build features, while our QA person works with the business to come up with test cases and test data.