The way we develop products is constantly changing. Currently, companies around the world are adopting agile product development, using some of its frameworks (Scrum, Kanban, Lean…).
This new way of working affects all traditional roles, including Test Analysts, or QA (Quality Assurance).
In this article, we’ll talk in a basic way about the differences between traditional QAs and Agile QAs, as well as a brief concept about agility and the Scrum framework.
Traditional context vs. Agile context
In a traditional context, project steps are planned in advance, before the start. The scope is defined and cannot be changed once development has started. Any change requires an approval and a new contract between the parties. The delivery date is also defined.
Moving from one stage to the next requires inspection and approval. This context is also called a waterfall (waterfall), and generally follows the model in the figure below:
In the agile model, the software is delivered in small pieces, usually already functional, within a period that varies from one week to one month, in the case of Scrum framework. With these small functional increments, you can quickly adapt to changes. Being agile is not being fast, but being adaptive!
Traditional QA
Based on the figure above, we see that testing only happens in the fourth stage of the project. At this stage, the software is practically ready.
Generally, in the traditional context, QAs do not have direct contact with developers. In this situation, QAs practically hunt bugs, sometimes the number of bugs found being a measure of performance.
Under these circumstances, only QAs are responsible for the quality of the product. It is they who ensure that the requirements have been met correctly. Any error in the software, or non-compliance with the requirements, is the sole responsibility of the QA person.
The Testing Manifest
The Agile Manifesto was created by a group of people who wanted to change the way software was developed. A few years later, following in the footsteps of the Agile Manifesto, the Testing Manifesto was created :
Test through all steps MORE test at the end;
Prevent bugs MORE find bugs;
Test understanding MORE THAN check functionality;
Build the best system MORE THAN break the system;
Team responsible for quality MORE THAN QAs sole responsibility.
Agile QA
Taking the Test Manifestos as a reference, we will describe here a little bit of how Agile QAs should behave. As in the Agile Manifesto, the item on the left is more valued than the item on the right – it’s not a replacement, you’ll keep doing what’s on the right, however, you’ll prioritize the left (not to be confused with politics ok!?) . Therefore, Agile QA must:
Test through all steps [more than] test at the end
Testing should start at the planning meeting. Based on the defined acceptance criteria, it is already possible to think about the test cases/scenarios that will be carried out.
If the team already has a test-oriented mindset and performs TDD, BDD or another technique, it’s time to combine the division of tests (application of the pyramid or another strategy); define what is worth being automated; how will the continuous integration be, etc.
It is also recommended that QAs do code review and pair programming. Many bugs and inconsistencies can be caught during development just by looking at the code, which leads to the next topic…
Preventing bugs [more than] finding bugs
With testing being done during development, the chance of a bug going into production is much smaller. At this stage the bug fix can be immediate, as the development team is working on the functionality.
Depending on knowledge, the moment the bug is discovered, the QA person can fix it himself.
Test understanding [more than] checking functionality
Quality goes beyond verifying that the software works as described. This can be done by a robot.
Quality also encompasses understanding the user’s need and ensuring that the need is really what the user needs. For this, the user must also participate together with the team in the development, as much as possible.
Build the best system [more than] break the system
As part of a team, pinpointing bugs and finding ways to break the system goes against the goal of delivering the best software possible. We have to keep in mind that flawless software does not always mean quality software.
The best system is the one that solves the pains of its users. Work for it.
Team responsible for quality [more than] QAs sole responsibility
Placing quality responsibility on just one person or area is to exempt other people involved in the process from any problems that will be identified.
Everyone who takes part, directly or indirectly, in developing a solution must be responsible for delivering the best possible within their role.
QAs may not be developers in the sense of being the person who codes the application, but they develop tests and are part of the development team. Everyone who contributes to product development, including designers/UX, is a developer and must be responsible for the quality of what will be delivered.
Working together
As the team is responsible for quality, QAs must be present at all stages of development, helping the team to deliver the best product. The figure below shows how, at each stage of the Sprint, QAs can contribute their own responsibilities and help team members.
Also, as part of the team:
help you find the right product;
collaborate to specify;
think of examples;
refine the specifications created by the team;
automate the specifications;
help maintain Continuous Integration;
help keep the Living Documentation up-to-date and accessible.
Traditional QAs vs. Agile QAs
Summarizing in topics the differences between traditional QAs and Agile QAs are:
Also, Agile QAs:
they are always learning new skills and technologies, adapting to change;
practice clear and effective communication, collaborating with technical and non-technical people;
understand the business, defend the product and collaborate with the customer;
disseminate the culture of quality and take care of the team’s health;
promote and get feedback, having the courage to expose what is wrong and praising what is right;
keeps simple and self-organized, not depending on instructions to carry out its activities;
like what they do 🙂
Are you in the traditional or agile context? If in traditional, would you like to go to agile? If in agile, does it do what was described in the text or is it already beyond? Leave a comment here!
