On several occasions I’ve witnessed companies, who have decided to develop software using agile methodologies, view the QA role in teams as basically a waterfall tester who is involved with automated tests.
By this I mean someone who performs all the manual testing of the product required within the team, and who is also exposed to test code (the latter depends on many factors, and is explained fully here).
In my opinion, this description does a disservice to the breadth and depth of what I view the QA role to be. I often spend a fair amount of my time with clients explaining all the other facets of the role as well, and the value that each brings to the team and the product.
Having done this several times, I found it beneficial to create a one-page picture as a visual prompt to assist me in this discussion. It’s shown below and descriptions of each section follow it :-
The Title
The statement at the top and bottom is a summation of what a QA brings to the project, the mindset of "Are we building the correct product and, if so, are we building it correctly?". A person in this role is someone who consistently questions all parts of the process to ensure the team is producing the desired output.
My personal preference is to not use the word “Quality” here, and instead use “Correct”. By using “correct”, I am provided with a much better idea of what to focus on.
An example is if the user interface of a call centre application looks terrible from an aesthetic perspective - the colour scheme makes it hard to discern boundaries, poor sequential flow, large numbers of clicks and scrolling required etc. It is, however, perfect for people to tab through and in this case, as that is the only way that users will interact with it, then it is the correct product for the customer.
Using the word “quality” means many things to many people - using “correct” minimises the possible ambiguity of having multiple opinions in a team.
Principles
The image on the top left is to help in discussing the strategy and construction of maintainable test frameworks. The embodiment of this principle is the test pyramid.
The image on the top right represents what a QA is constantly thinking about and discussing with the team, story by story. It does not reflect that they are actively involved in all the activities.
Practices
The image in the middle represents the lifecycle of a story from a QA perspective, and each of the touchpoints they will be involved in.
Comparing these touchpoints during the lifecycle of a story with those of a ‘waterfall tester involved with automated tests’ highlights the additional scope of the role. Rather than it being a critique of what has already been built, the role encompasses looking to what’s coming up and ensuring the idea and description is sufficient.
Environments
The image on the bottom left is to help explain, from an environment perspective, the activities that reduce risk and help the team gain confidence that they’re building the correct product. Each environment provides the platform for unique validations to be made, each providing a different benefit and focus on the product.
Breadth and Depth of the Role
The image on the bottom right is to help explain that no QA is exactly the same. Some people in the role have a deep understanding of the Iteration Manager role and can seamlessly step into that role if required. Some can work as a BA without any need for further training, some can take on the UX role and some the developer role. Everyone has a unique mix of all these capabilities.
What is important to note is that a QA has a fundamental understanding of each of the roles in the team and, as such, is a ‘generalist by trade’. They require this broad understanding of the roles to be able to understand how projects and their products are progressing and, as a result, provide feedback on practices or processes that could be improved. And, above all, inform the team about whether the product under development is what the customer wants.
I hope this diagram encapsulates the essence of what you believe the QA role is as well, and assists in any discussions you may have on the topic.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.