Some Thoughts on QA

A recent comment on Hacker News got me thinking about the role of QA people in software projects…

To quote Dodge (via Deming), "You cannot inspect quality into a product."

…

It doesn't matter how great your QA team is, if the quality isn't in the system the QA team can't put it there.

I’ve seen time and time again where managers become concerned about the low quality of the software their organization is producing, and deduce that the answer to their problem is to assign more QA people to the project, as if the lack of QA people is the reason for the low quality.

There seem to be some misconceptions about QA that I wanted to write a few notes about:

1. Testing of software should be at least 90% automated. The manual part is “exploratory” testing.
2. A corollary to #1 is that people who want to do QA as a full-time career need to be able to code.
3. The best QA people I’ve worked with in my career became more akin to business analysts (BAs) on the team, who were suggesting improvements to the user experience based on their knowledge of the business processes.
4. A corollary to #1, #2, and #3 is that QA can add value by:
• Being better at test automation than the developers.
• Knowing the business better than the developers.
5. Jobs that involve a large portion of repetitive, mechanistic work are begging to be automated away. Even slow-moving companies catch on eventually. Be the automator.