I am proud to work with some of the best minds in QA the country has to offer. In this time I have come to learn something about what it means to do excellent QA work.
You see, I used to classify the QA role as the fact-checker. Ie, the primary questioned they answered was, did the developers deliver quality code? After all, isn’t that what Quality Assurance means? It is literally in the name. In practice, if all your QA team is doing is finding bugs left behind by your developers, then someone is dropping the ball.
Bugs in the code should be incidental, and if anything, you should expect there to be no technical bugs at all. The work of catching bugs is to be done by an automated system. If you employ a best practice such as BDD or TDD, then you foreclose the issue by design.
So how then why do QA’s test? In this entry, I will be exploring my view on this question.
To build a shared understanding.
I believe as many people as possible should have in-depth know-how of the system.
To clarify my terminology, I don’t just mean knowledge; I mean know-how. Knowledge is what you get from reading test cases; know-how is what gives you the intuitive feel the test case is incomplete.
It is unlikely the QA was there during upstream activities such as sketching, UX or writing user journeys and even in enlightened organizations when they are, the actual app is almost always different from what you originally envisioned.
Thus you must allow your QA access to incomplete versions of the application, let them experience the frustration of the dev team as they get the MVP out. Through this process is how they will come to understand the edges of the system.
By having as deep an understanding of the system as the developer, they can then provide a useful sounding board and insightful ideas as to how the development team should continue developing the product
To assess product value.
A lot of opinions abide about Tech being either a cost or profit center for the organization. I think this dichotomy is too simplistic. Still, If we commission work which takes two sprints to do, the best we know beforehand is we have cost the company salaries for a team for at least a month. The only thing the business knows for sure is they have a few more lines of code in their product, whether this translates to value is a whole other story.
Developers are by their very nature more interested in the technical aspects of their work. They will focus on technical metrics such as code coverage or cyclomatic complexity.
While QA’s can also be technical, for the most part, they tend to focus on metrics which the business can translate to value such as time to input a record, ease of reaching various relevant action items, etc.
Combined these two strengths, what you get is a technically superior product which the customers can use.
To assess “Look and Feel.”
On one of our solution evaluation meetings, someone mentioned GSuite is built for agility while office suite is built for power. This statement doesn’t speak of objective truth but instead, refer to an essence of the offerings.
Automated testing for such features would be almost impossible. Imagine trying to automate testing for an accent. Deciphering a Kikuyu from an American accent would be instantaneous even for a young child but would likely require state of the art AI to be automated.
Cultural factors also come into play here. We live and breath the culture we are born into and can tell what goes against the grain without being able to explain why. A QA being human comes with the capability to pick apart nuance built-in.
To come up with and test edge cases.
In demos, developers naturally incline towards the happy case, after all, its what they put most of their focus on. As part of the culture at Twiga, we always insist you start by showing us what wouldn’t work. Ie, triggers the error message.
QA’s are usually able to see beyond the most glaring flaws. For example, what happens to an integer field if you add a space at the beginning? Or even better able to think up scenarios which make sense individually but not as a bundle, for example, Can you order sugar and have it packaged in nets?
What does the QA do in your team? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex
