What is the role of the QA Team?

In 2015 Yahoo decided that it didn’t have one. They got rid of QA and asked engineers to handle testing. In the fiery discussion of this event on Hacker News and Reddit, many developers accused Yahoo that it was just a cost saving move that was disguised as well intentions. So what actually happened? Yahoo says: fewer errors and development. But of course they would say that…. Humans have an amazing ability to do something impulsively and then rationalize it without an end.

‍

In my 20 year experience in the Development Arena (yes we do fight to the death, see tabs vs spaces war), I found that QA does have a role, but it is not what you think.

QA in Medieval Times

Long long time ago (5–10 years) QA was an important functional team in most organizations.

The process went like this.

Developers would be given some vague business requirements and a deadline of about half the time needed to do the task. Developer would try to push back and say that they don’t have enough requirements and time to finish this task. But management would reply with nah nah nah nah, I can’t hear you and would hang up. So developers would cut every corner in the process like doing any proper design, following coding conventions and absolutely minimal testing. I mean sometimes just checking that the code still compiles.

Then the developer would send the half baked code for QA deployment and move on to coding the next feature. At this point QA would be scrambling to get the release tested with about 10 half baked features and also have enough time for regression.

Anyways, QA would start testing and find that some features were not tested by developers and some were tested maybe 10%. They would send almost all cases back to developers. And that would be just the beginning of the spiral of doom.

Here is my re-enactment of dev/qa interaction using iconic music and video clip:

‍

Kirk is Dev.

Spock is QA.

McKoy is Scrum Master.

The lady with funny ears is Stakeholder.

Everyone else is Ops.

‍

Dev: Here is the feature fully done and ready for prod.

QA: This feature is not implemented even for the basic scenario. Here are the steps of what I did and what is expected..

Dev: Ok… Now it should really work. Please test.

QA: Nope, still not working.

Dev: Are you testing it correctly

QA: Yes

Dev: Ok let me read the requirements again. Aaaah sorry, I implemented something else. Now it should really really work. Here is a screenshot.

QA: The screenshot is obviously photoshopped. Here is a whole video with soundtrack and special effects that clearly demonstrates that the feature doesn’t work.

Dev: … … … sounds of compiling… …

QA: Sorry what?

Dev [2 days later]: Sorry there was a production issue and the CEO had me fix it or be drawn and quartered. Finally I had some time to deal with your problem. Please test again.

QA: Ok now the feature kinda works. But here are a couple of error cases that will happen pretty often, that are not handled…

2 days later, both QA and Dev have beards and black circles under their eyes. But a release is finally ready to go. There is a whole other horror movie that happens after it rolls to prod, but let’s save it for another time.

You may say, yes it kinda works like this and I get your point, but this is the way it has been done for 100s of years. Is there a better way?

Yes grasshopper there is. Get rid of a QA team!

‍

Get rid of all QA?

That’s what Yahoo did in 2015, and look where they are now. Ok… Yahoo may not be the best example, but other companies have done the same and with positive results.

So what are some of the reasons to get rid of QA:

1. Who owns the quality? In the past it was QA team. Now, it should be developers who should own the quality of the feature/task that they work on. Otherwise if developers are told to just code the task and pass it on for someone to test, why would they ever do anything, but minimal testing.
2. Each hand-off increases Lead Time. Every time Developer sends a task to QA they need to wait till QA tests it and sends the task back if they find any issues. Then Developer needs to find some time for the fix, perform a context switch (a major productivity killer) and send the fix to QA. This goes back in a circle till the task can be rolled. So wouldn’t it be much better if the Developer doesn’t do hand-off and performs majority of the testing.
3. The QA team works a bit like accountants, who work 2 months, like crazy, during tax season and don’t have much to do during the rest of the year. If the SCRUM sprint is two weeks, the QA team is drinking fruity beverages on the beach for 1.5 weeks and then scramble like crazy after a code freeze for 2–3 days (+ the weekend) to get the release out. Yes we all say that they should test whatever the developers send them during the whole sprint, but somehow most cases are completed on the day of code freeze or the day after. There are probably some good ways to optimize QA Team’s time, but getting rid of them should definitely be on the list.

So is there still a place for QA on the tech team? Yes there is, but it is not the same as in the past.

Lean and mean QA Team

Developers should own the quality of the work that they do.

‍

So where does the QA team fit into the development process?

1. QA should make sure that automated Regression testing is always up to date and covers the whole system
2. QA should train and assist developers with writing Acceptance and E2E automated tests. We all know how much developers like to do manual testing: on a scale of 1–10 it would be -20. But we also know how much developers love to automate everything. So let them do what they love, automate the E2E tests, but with proper training and guidance.
3. QA are able to do exploratory manual testing. Developers usually skip this type of testing. They are just not built that way. Exploratory testing is thinking outside the box and includes use cases that may not be covered in general Acceptance Tests. Many QAs are as happy to break things as developers to get things working, so I say, let them do what makes them happy.
4. QA works with Business Analysts to provide acceptance criteria in something like Gherkin syntax, so that it is easy for developers to write the actual auto tests.

To fulfill these requirements you don’t need 1 QA for 2 developers. One QA for 5 or even 10 developers would suffice. This one QA would be need to do a lot of things:

• an expert in automated testing
• a hacker’s skill for exploratory testing
• guide developers on writing auto acceptance tests
• organizing and constantly updating regression testing

Just like Developer who are evolving in Dev/Ops/Tester, QA also has to evolve into a new species.

Conclusion

In this article we examined how QA and Developer teams interacted in the past and how QA teams need to evolve the same way as Developers are doing. Previously Developers were coders who only had one responsibility: to code, and we had QAs who had one responsibility: to test.

Now with a Lean/Agile revolution, big specialized teams are splitting into small cross functional teams. These small teams, as well as every member of the team, have only one responsibility — to create value for the business. There has been plenty of discussion on how it should work for Developers, but not much for QAs.

NO we shouldn’t get rid of all QA, but instead they should become more lean and efficient. They should work closely with Developers and Business analysts to lead overall testing efforts on a daily basis and help the team to succeed.

‍

‍

‍

‍

‍