ScrumBut: "Developers don't do QA well."

Question

Since arriving at my company, I've come to find that they specifically hire QA Analysts for QA work within sprints across multiple products. I'm aware that this goes against the Scrum Guide which states that within a Scrum Team, there are no sub-teams or hierarchies.

We're continuously hitting the bottleneck every sprint, carrying tickets over, running into the age-old issue of work getting to QA too late in the sprint or coming in all at once, causing the iteration to fail to deliver.

I've attempted to coach my boss on the pitfalls of this approach, discussed the Scrum Guide and had a frank conversation about the repeated failures across all of our products, but the answer to my suggestion that we utilize developer time to do QA tasks, and collectively own the iteration together, was that they have tried to have developers do QA, but they're not skilled enough at QA-type tasks like writing detailed test cases, thinking through all scenarios etc. to be trusted with QA-type work. It had been tried, and quality suffered. So the decision was to have developers develop, and QA do QA.

If your teams do this well, how do you do it?

Answer 1

Your analysis of a problem existing may be correct. Your proposed solution is not.

Your boss is entirely correct. Development and QA require completely different skillsets. You might find people who can do both, but even then, why would you waste their time with QA tasks when you can just hire a lower-wage QA to do it?

---

Now, you say,

We're continuously hitting the bottleneck every sprint, carrying tickets over, running into the age-old issue of work getting to QA too late in the sprint or coming in all at once, causing the iteration to fail to deliver.

Even assuming that's completely true... I have no idea why you think having developers do QA would be at all related. How would that even help?

Say your team is either Alice and Bob the developers, or Alice and Bob plus Charlie the QA.

Case 1: Alice and Bob start stories A and B on Monday, and finish on Thursday. Now Alice starts to QA B while Bob QAs A. Neither finishes on time.

Case 2: Charlie starts writing test cases for A on Monday, finishes on Tuesday. He then writes test cases for B, finishing on Thursday. Now Charlie, with assistance from Alice and Bob, QAs A, finishing on Friday. He doesn't have time to QA B, so they're not finished on time.

How is Case 1 better? I don't understand the logic there.

---

Going through your complaints one-by-one...

We're continuously hitting the bottleneck every sprint

I'm assuming the bottleneck is QA? So eliminate the bottleneck. You don't do that by removing QAs. One way to do that would be to add more QAs. Another would be to have the developers work more closely with and assist QA. They'd become T-shaped, but you still need people whose specialties lie in QA.

carrying tickets over

You're including too many tickets in your Sprints. Look at your velocity and take on less wok accordingly.

work getting to QA too late in the sprint or coming in all at once

Split your stories more, e.g. so that each one takes a day instead of a week. Then the QA work will be staggered.

---

Your problem is in how you're doing QA (and development). Not who.

Answer 2

A lot can be done with the use of mocks and stubs.

The traditional approach might be something like this:

• Developer codes feature
• QA writes test case at the same time
• When developer has finished coding they hand over to the QA to run a manual test

As you mentioned this leads to the back-loading of sprints and to incomplete work.

The alternative is to do something like this:

• Developer rapidly produces a stub version of the feature - it has not fancy UI and just stubs for the back-end code
• Either the QA or the developers now write automated tests that run against the stub code
• Once the automated tests are ready, the developers start the process of adding in the real code needed to replace the stubs
• The automated tests validate that the code is working as expected and can be added to an automated regression test suite once the sprint is completed (which will save time in future sprints)

The process is collaborative. The QA uses their skill at writing test cases and at thinking of scenarios to assist the developers at every stage of the process. It may be that the automated tests get updated during development as well, but you still avoid the problem of back-loading the sprint.

Even better, you can start to use an approach like Behaviour Driven Development (BDD) where the developer, tester and business/product person discuss the scenarios in advance of the development work starting.