When it comes to quality assurance, it’s always surprising how often the terms ‘tester’, and ‘qa engineer’ are used interchangeably. It’s so common, in fact, it's common to hear engineers and technical leaders say things along the lines of: “We don’t need a qa department here, our developers can test their own code.”
While this is belittling to somebody that’s decided to make a career in quality assurance, it’s also, sadly, something that the field of software quality assurance has brought upon itself.
To start, it’s good to understand why quality assurance and testing should be considered separately. Saying that testing and quality assurance are interchangeable is the development equivalent of saying that software development and code reviews are the same thing.
Imagine hiring a senior developer and expecting them to spend all of their time doing code reviews. It’s absurd. It’s a waste of not only company resources, but also the talents of this brilliant, and talented developer. On the flip side, however, this very experienced software engineer won’t be exempt from doing code reviews, their expertise and knowledge is invaluable when doing code reviews for less experienced team members.
In other words, code review is part of a developer’s job, it is not their job. To say otherwise is a waste and, frankly, an insult.
Testing is no different to quality assurance. Unfortunately so many either don’t realize this or have forgotten it, and most companies and individuals are complicit in crippling themselves and the careers of talented quality assurance engineers.
This however, begs the question. What is left for quality assurance if it’s more than just testing? The answer isn’t simple, but the name of the role gives a good place to start. Quality assurance works to make sure that the final product being shipped to the customer is acceptably high quality and relatively free of major bugs, but that’s just the obvious. Just as important, and much more rarely considered, is the responsibility to consider the process required to ship products.
To use a metaphor: Imagine a factory that produces 100 gizmos every day, and a tester finds that on average thirty of those gizmos are defective each day. In other words, the factory is operating at only 70% efficiency, even when running 100% of the time. That is a lot of wasted effort. Most factories (like software companies) can’t afford to slow down to root out the source of the problem. That’s where a good qa engineer can make all the difference.
In our imaginary factory, our quality assurance engineer will go backwards up the line and figure out what the source(s) of the 30% drop in efficiency is coming from. Is it a faulty part being used? A poorly performing machine? (the metaphor begins to break down, but the point is still the same.)
Often shoring up the source(s) of the problem can look like it’s slowing down production. After implementing fixes perhaps the factory is only able to produce 80 gizmos every day, but of those, the average number of defective gizmos has also dropped to 2. It may look like there has been a slow down, but the factory has increased production from 70, to 78 gizmos per day.
As mentioned above, in software the answers aren’t always cut and dry, but patterns always seem to assert themselves. For example:
What are the team’s metrics around quality? It can be shocking how often the answer to this question is a blank stare. The truth is most teams and companies say they want higher quality, but don’t actually understand what that means. A good qa engineer should be able to guide a team to important quality metrics, know how to track those metrics, and develop a strategy for improving them.
How does the team deal with major bugs (ie: critical, or priority 0 issues)? Many companies are competent at resolving major issues, otherwise they probably wouldn’t stay in business for very long. Many, however, fail to properly manage what comes after. Major issues are major problems, and sadly some companies stop at requiring a write up of what went wrong, and what should change in the future. While that’s not bad, it’s also a document that likely gets read by three people (at most) then promptly forgotten. If it’s a major issue, teams should make a big deal about it. A good quality assurance engineer will get the right people together to discuss what failed, and put together an action plan to fix the problem. More importantly, they will hold the team accountable for following through on that action plan.
All of this is just scratching the surface. There are many, many things that fall under the purview of quality assurance, the important takeaway though, is that testing != quality assurance.
Top comments (0)