3 ms·

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. Subordinat

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
That's false. QA can also be concerned about growing new features in the next release. We have embedded QA's on our teams. They QA new features, as well as help to triage current bugs.
- failwhaleshark 5y ago
  Anecdotal. Embedded QA doesn't scale for projects where the teams are larger, or the concerns and complexity are significant. https://qualitysystemsanalyst.com/2017/10/06/independence-the-importance-of-separating-the-checking-from-the-doing/ https://qualitysystemsanalyst.com/2017/10/06/independence-th...
  - beatthatflight 5y ago
    Anecdotal too, but I've been QA lead on a team for a 9 figure project in aviation, concerns and complexity very significant, and it was very successful.
edgyquant 5y ago
I work at a startup so we have a small team. But for us it goes: 1. Develop some feature (me and the other engineer are full stack) 2. Send to other engineer for code review 3. Deploy to a staging site, with test data. Send to product girl to QA If she finds a bug (or realizes her design doesn’t look as right in practice as she envisioned) she sends back with notes, we implement or fix them, and then start back at 1-2. I think QA is different for every org but I believe there should be steps. At bigger orgs there should be QA for every feature developed (so each team should have a QA person) and then an integration QA of the current beta.
- failwhaleshark 5y ago
  QA is different for every type of engineering organization. It shouldn't be automatically thrown around or diffused as something tertiary that can be subordinate wherever it lands. That works in a 3 person startup, but not if you're building an aircraft carrier or an iPhone.
  - edgyquant 5y ago
    I agree that was kind of my point. It’s different everywhere so saying it only should exist to test stable is untrue.

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

That's false. QA can also be concerned about growing new features in the next release. We have embedded QA's on our teams. They QA new features, as well as help to triage current bugs.

failwhaleshark 5y ago
Anecdotal. Embedded QA doesn't scale for projects where the teams are larger, or the concerns and complexity are significant. https://qualitysystemsanalyst.com/2017/10/06/independence-the-importance-of-separating-the-checking-from-the-doing/ https://qualitysystemsanalyst.com/2017/10/06/independence-th...
- beatthatflight 5y ago
  Anecdotal too, but I've been QA lead on a team for a 9 figure project in aviation, concerns and complexity very significant, and it was very successful.

edgyquant 5y ago

I work at a startup so we have a small team. But for us it goes: 1. Develop some feature (me and the other engineer are full stack) 2. Send to other engineer for code review 3. Deploy to a staging site, with test data. Send to product girl to QA If she finds a bug (or realizes her design doesn’t look as right in practice as she envisioned) she sends back with notes, we implement or fix them, and then start back at 1-2. I think QA is different for every org but I believe there should be steps. At bigger orgs there should be QA for every feature developed (so each team should have a QA person) and then an integration QA of the current beta.

failwhaleshark 5y ago
QA is different for every type of engineering organization. It shouldn't be automatically thrown around or diffused as something tertiary that can be subordinate wherever it lands. That works in a 3 person startup, but not if you're building an aircraft carrier or an iPhone.
- edgyquant 5y ago
  I agree that was kind of my point. It’s different everywhere so saying it only should exist to test stable is untrue.