To QA or not to QA

Christopher
Sep 7, 2018 · 5 min read

I am an old coder. I started before the days of PC’s, before the web and before IT departments had QA teams. Developers were responsible for coding and ensuring the quality of their code.

Then someone had the bright idea that developers were not the best folks to ensure the quality of their code and created the first QA team. Because it was true, developers were not very good at ensuring the quality of their code, the idea grew until most IT shops had QA teams.

However, recently the idea of developers being responsible for the quality of their code has begun to return. With TDD and the like, why not? I have heard of shops doing away with QA teams entirely.

This essay gives my reasons why I believe that QA teams should stay. I have four reasons: mindset, second sight, cost and tools.

Mindset

If I was a security expert and I designed a security system for a client, who is the best person to review my design? Another security expert or a master thief? The mindset of the thief is how to break the security system. That mindset makes them the better person to review the design.

This is the most important reason why asking the developer to do QA is a bad idea. The developer’s mindset is about building, the QA tester’s mindset is about breaking. This mindset makes the developer blind to some possible bugs. The developer will test the changed section of code the most thoroughly, and potentially miss a ripple effect of the change. The developer will test their idea of how the system is ‘supposed’ to work. This can miss some edge cases and ‘second sight’ bugs.

Second Sight

No matter what tools a team uses, the requirements will need to be described in some manner using words and images. For any complex change, it is impossible to describe it so well that everyone who reads it will come to an identical understanding. This means that the developer and the QA tester will read the same set of requirements and come to two slightly different conclusions.

When the tester runs their tests and seeing something different than expected, a bug is raised. The developer is likely to say, “No, that’s not what the requirements say” and appeal to the BA. The BA may agree, in which case the bug is closed or the BA may disagree in which case the bug will be fixed. In the second case, having two people read and interpret the requirements has resulted in a delivery which more closely matches what the user asked for.

Cost

Here is an imaginary change request to existing legacy code. The change request is estimated to take 3 days to code, make changes to the unit test base and for basic testing. The same request is given to two developers. Developer one is very concerned about quality, not willing to stop at basic testing, the developer spends an additional 6 hours performing various tests again their code. Developer two is content to stop at basic unit testing. Both submit their code to the QA team. The QA team finds only 3 bugs in developer one’s code, but they find 6 bugs in developer two’s code. Developer one gets the gold star, spends 6 hours fixing the bugs and ensuring the fix is clean. The next pass through QA all is well. Developer two spends 4 hours fixing the 6 bugs. The next pass through QA finds 1 more bug, another hour for developer 1 and the final pass through QA finds no more bugs.

Now add up the time spent. Developer one spent a total of 36 hours. Developer two spent 29 hours: 7 hours less than developer one. In this imaginary change request, QA needs 6 hours to test the system. For developer one, QA spent 12 hours. For developer 2 QA spent 18 hours. Based on data from Indeed, a developer makes roughly double a QA tester. Here is the math where x represents the hourly cost of a QA tester and 2X is the hourly cost of the developer.

Developer one = 36 * 2x + 12 * x = 82x

Developer two = 29 * 2x + 18 * x = 76x

Granted, this is a very artificial scenario, but run some calculations with real numbers, real developers and I suggest that the savings are present and, over time, substantial.

Tools

In my imaginary scenario, I used the same 6 hours for the developer and QA tester to test the completed change request. However, the QA tester probably ran more tests on more platforms than the developer. Why? The QA tester has the tools. They have multiple devices configured and ready for testing; automated test tools that they use frequently and know well; tools for performance testing and load testing; spreadsheets of common test scenarios, edge cases and bugs found in prior test runs. Without the QA team, the bugs found from using these additional tools would not be found.


In this short essay I have covered my reasons for continued support and development of the QA test team. Those reasons were mindset, second sight, cost and tools. I’ve worked in environments before QA teams were used in IT departments. Moving QA back to the developers is a step backwards and will result in more bugs being released into production.

I’d love to hear your opinions and feedback.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade