Agile QA: what is it and how does it differ from the traditional?
At Invillia, every Wednesday at noon, we stop for an hour to nourish ourselves with the tips, how-tos, good practices and trends selected by our specialists in Product, Agile, Back and Front, Mobile, Quality, Security and Data. A vital exchange of experiences for those who love the new. And essential for innovation to never stop. If technology is in the blood. We make sure to keep it circulating more and more_
IN THE VEIN_ QA as an active participant throughout the innovation cycle_
5-minute read
In today’s article, we share the main lessons learned from the excellent edition on Agile QA, presented by Milo Scarano Oliveira, our expert in Quality. A very controversial and critical topic. Not only the QA knowing how to act in its context, but also how to relate and what role the other team members play. Is an Agile QA a QA that tests fast? As you will see in the next lines, not at all 🙂
QA Mission
QA is often understood as someone who is just testing, validating the output of what is being coded. In fact, the responsibility goes far beyond that. QA’s mission is to help build a better product and add effective value to the business. It works as the “lawyer” of the client and the end-user. It is the person who will defend them at all costs. Bringing their pain and expectations throughout the innovation and delivery process. In an agile context, it is an integral part of the development team. Minimizing costs and time through automation, clear definitions of business rules, understanding and monitoring end-to-end what is happening, and finding errors as soon as possible.
Traditional Context
The traditional context is characterized by the waterfall model, a sequential software development model. Here QA waits for his step after coding to test, validate and then proceed with delivery. Nobody on the team tests because it is understood that only the QA does that. The adoption of agile methodologies makes it impossible for this model to prevail, but many companies continue to follow it.
The Testing Manifesto
The Testing Manifesto was created a few years after the Agile Manifesto. After all, how is it possible for a team to be agile if nothing changes in the way it tests? There are then 5 fundamental principles:
- Testing throughout over testing at the end
- Preventing bugs over finding bugs
- Testing understanding over checking functionality
- Building the best system over breaking the system
- Team responsibility for quality over tester responsibility
Traditional QA vs Agile QA
What’s the difference between one and the other? In the traditional context, testing is a phase, a step. There is a separation where it seems that QA is in his world and the developer in another. He does not even follow the “to-do”.
In the agile context, testing is an activity over a cycle. Agile QA is part of the entire board, not just a single column. He follows from the beginning of the conception of the product history, how it is being developed and tested, everything that is happening on each card, whether in Jira or any other tool. And he also teaches, mentors team members. It propagates the culture of quality from the “to-do” to the “done”. The sooner we manage to act, the better the delivery will be.
In the traditional context, QA is often looking for bugs. In agile the goal is to prevent bugs. Testing and asking the right questions at the right time.
For example, when designing a user story ask how the interaction with the system will be, and not just click on something. And if he clicks differently what happens? What behaviors are expected? Is this mapped before the developer starts coding? How? At where? It is necessary to bring inputs not only for QA but for the team to understand what is being delivered.
In the traditional context, QA just checks that everything is working. But he is not a feature checker, he is much more than that.
In the agile context, he understands the needs and expectations and is part of the team to test at the most appropriate time and deliver with end-to-end quality.
In the traditional context, QA tries to break the system to find bugs, problems. In the agile context, he brings tools, automation, mechanisms, techniques to help build the best system. He is the developer’s best friend and not an “enemy” who came to “destroy”.
Agile QA helps to validate, to understand what is behind what needs to be coded. He has a positive and proactive attitude, brings new visions. He makes it happen, anticipates, acts together. He allows the response to changes to be much faster.
And now we enter what is most controversial. Is the QA solely responsible for quality? No, he is not. He will bring insights and a vision of quality assurance to make this happen as a team in the best possible way. He is not the gate that blocks. Rather, his goal is to open doors and discuss ideas.
Agile QA will help understand end-to-end what is happening and the entire team takes responsibility for quality. Developer, QA, Product Owner, Scrum Master, etc work together to build the best product. And only when everyone is confident it is ready to go into production. The decision is and will always be made by the team.
In a nutshell
Here is a summary of what distinguishes a Traditional QA from an Agile QA:
It is this perspective of Agile QA that we believe and we encourage at Invillia. We all work together to add more value. From understanding the product’s purpose to its development, implementation and evolution. It’s our Global Growth Framework in action. Data, People and Action combined to increase and accelerate in quality, scale and performance game changers’ continuous innovation missions.
Originally published at https://insights.invillia.com on September 23, 2021.
