Requirements → Plan → Design → Development → Testing → Release and… Repeat. We are pretty sure you have heard of these phases regarding a project’s life cycle using Agile. But, have you heard of the PreQA phase? No? Keep reading to learn about it!
Intro to PreQA
Requirements → Plan → Design → Development → Testing → Release and… Repeat. I am pretty sure you have heard of these phases regarding a project’s life cycle using Agile. If so, you should know there are different tasks so goals can be accomplished, that continuous iteration takes place, and that releases are made constantly. But, have you heard of the PreQA phase?
First of all, let me tell you that PreQA is not a phase that “really” exists in a project’s life cycle. Why? Because, as we know, in Agile everything must be continuous and constant.
So, to tell you about PreQA, I am going to start by telling you how we started to use it in my project. I am also going to mention all the positive things it has brought to us. Spoiler alert: Now we can ensure Quality in each stage of any project.
##The story
At MagmaLabs we work with the Agile Methodology. That way helps us to release in a faster way, making each iteration more flexible. (If you want to learn a little more about how MagmaLabs uses this methodology you can check my last blog post.)
But, it was not until I was assigned to my current project (I have been working there for over 3 years) when I started using the PreQA step. So, with this experience taken, let me explain to you a bit about it:
Here it goes
The project I am working on is one of MagmaLabs´ biggest projects. We are working with about 20 members of the team, including 14 developers, 3 Project Managers, 1 Scrum Master, and 2 QA testers. The results that we have been getting these last two years have been so amazing, that now we need more people so we can achieve the goals of 2021. All this makes me feel joyful because this means we are making a great impact on our end-customers.
Nevertheless, things were not always like this. I remember my first year on the project, everything was total chaos! We believed we were an “Agile” team, but we were not actually putting into practice any of the processes and guidelines that this suggests.
It was not until a year later when we gradually started using Agile foundations. Sadly, despite our efforts, we noticed we were still getting many rejects from the testing team due to bugs found in the application.
We began to analyze our processes. Then, we realized the features were failing even in the happy path. Some other times they would not even let us do our job, blocking our review process. So, how could we be sure that at least the happy path works? Well, here it is where PreQA enters the room!
So, what is PreQA?
Basically: reviewing tasks before the testers themselves start doing their magic. As a developer, you should be able to know exactly all the things you do to your code. Short words: testing your task/feature. This may only be the happy path, but if you think your changes may affect/impact another part of your code, this should also be reviewed.
Just to be sure: Does the dev have to be the one doing PreQA? Yes! You might think that “quality” only belongs to the Quality Assurance team, but the truth is that when working with Agile (where everything must be quick) quality should be considered by all team members. If the Dev does an easy test (PreQA) of their work this will ensure at least the first scenario is just ok before the tester reviews all the test cases.
What benefits could PreQA bring?
- The reduction of rejects, making it clear that quality concerns everyone in the team.
- Reducing the lifetime of a ticket/feature
- Completing sprints on time.
Let me explain to you a bit: Usually, in the project I collaborate on, each ticket used to be rejected around 3 or 4 times. That showed us that there was NO quality in there. When we implemented PreQA the tickets were now rejected only 1 or 2 times. But, our goal was to get no rejects at all, so we had to embrace the process more deeply and consciously.
Slowly but surely, the process was getting better and better as the developers began to take the PreQA phase more seriously. They also began to consider quality from the moment they were coding. After that, the life cycle time of a started to be reduced. We also noticed that getting no rejections was helping us to complete our metrics every sprint in a better way. That allowed us to even add an extra ticket, exceeding 100% of our initial goal!
In the beginning, developers questioned if it was all worth saying that it was a waste of time, that was NOT part of their work since they were developers and not testers. They thought the PreQA process would only increase their working time.
I completely agreed with them. The process of ticket testing is part of the testing team since they are in charge of checking every possible scenario and checking the requirements are met. However, we are ALL in charge of the quality of our work and WE ARE ALL A TEAM.
In addition to that, the PreQA process does not necessarily take much time to be completed, it is a really simple test. It is only a matter of making sure that at least the happy path works (this does not take more than 30 minutes).
Conclusion
After some time, the benefits began to be quite noticeable. My partners noticed that their personal rejection metrics decreased too, and that was how the PreQA process became an official phase. When they noticed how good PreA actually was, they even added a few more scenarios in their tests, such as unhappy paths.
As I mentioned, the PRE-QA process has helped us to improve our metrics each sprint by reducing the number of failed tickets. But I think the best part of it is that it helped the devs to see that quality should concern us ALL, from the beginning to the end of the life cycle of a ticket.
THANKS FOR READING!!
