How to Introduce the QA Process Into an Agile Team

Imagine the following situation: A new project just kicked off and the client requests a Quality assurance engineer on the team. Neither he nor his development team have ever worked with a QA before, so reasonably, many questions appear – both from the team and the client. And guess what? You, as the QA engineer who’s joining the team, will have to answer them:

• How do we work from now on? Will QA block my progress and what happens with our velocity; does QA slow us down?
• What’s with all the bug tickets, do I really have to fix them? 
• Why should I let someone else test the app? I was doing just fine without them. 

‍First things first, keep in mind that it’s completely normal for them to have all these doubts. Being in QA for 5+ years myself, and having worked on numerous projects over the years, I’ve answered all of these questions multiple times. But, let me start by saying this: Introducing QA to the project team will not negatively influence the team’s work. Repeat after me – you are a much needed addition to the project team, not a burden. 

Got it? Good, now let’s move on to developing the QA process.

Creating the QA process

1. Introduce the Quality Assurance role to the project team

Your first step is to explain the QA engineer’s responsibilities and how he/she will contribute to the project. This is when you’ll have to make it clear that the role of a QA engineer is to help improve the process, stories, requirements and most importantly, the quality of the mobile or web application. Important notice: developers will still be very much involved in testing the app’s quality. ‍

a) To support these arguments, first you have to have the knowledge – that means learning everything you need to know about testing principles, levels, and types of testing. Without mastering the basics, you won’t be able to educate others about what you do and prove the importance of your work. In the end, it could make it harder to introduce the QA process to the team – and this is something we want to avoid.

b) Secondly, you want to get involved in all team activities, as much as possible, and right from the start. That means participating in all scrum meetings, from the beginning until the end. I have to warn you – in the beginning, there will probably be situations when the team doesn’t invite you to certain meetings. Don’t let this discourage you. Stay persistent, ask questions, and offer solutions – soon, they’ll see all the wonderful benefits of having you on the team.  

2. Get to know the project team

If you’re familiar with the agile methodology, you know that every team has its own dynamic and approach to work. And the key to success? You know it already, it’s adaptation.

From what I’ve gathered over the years, there are no general rules of getting familiar with your team – it all depends on your teammates. New project usually means a new team, so every time you start a project, you’ll probably have to come up with a fresh set of rules to define the type of the relationship you want to have with them. My advice is to always go with a friendly approach – it was proven to give the best results, at least in my case. This means building a relationship with the developers where you can openly tell them you found a bug and they’ll react positively to it. It also means reaching a level of comfort with the Product owners that allows you to openly discuss any issues and improvements. The Product owner should be your best friend on the project and believe in your approach – if you, for example, say it’s time for a release, they should trust your decision. The same goes with the designers. I always include them in the implementation part of the project and if I see that some part of the design doesn’t make sense, I’ll challenge them. Don’t be afraid to speak up, it’s all part of the job. But as I said, always do it in a friendly way.

When it comes to the team dynamics, it’s also important to recognize the velocity of your team. This will affect the QA process you’re trying to build with them, but also, the number of releases you have. For example, if your team works fast, it makes complete sense to have everyday releases. If not, once a week might be just enough. 

3. Start reporting!

Every bug you report, you need to document in the tracking tool you’re using on the project, for multiple reasons: 

• You don’t want to lose any bugs,
• You want to know the status of every bug, 
• You want a visible trace of your work; I like to call this no bugs under the table.

Until the team resolves all bugs, I suggest keeping the stories open. If resolving all of them is not a possibility, make sure at least all the major and critical ones are resolved. To help developers know what’s a priority, use prioritization. Here’s how we do it at COBE. Educate developers about the importance of having regular builds and small chunks which you can test fast. 

Another important thing is to adapt the tracking tool you’re using to the project. When you open the tracking tool, you should be able to see what’s ready for testing right away. So feel free to add an additional column or a simple label that will tell you when something’s done. Occasionally, a developer might say that something’s done because it works on their computer.

Keep in mind that until they’ve made a build with the included feature, something can’t be considered done.

4. Release

Since you, as a QA Engineer, are the person who’s testing the app the most, let’s face it: you’re the person who knows when it’s the right time to release it. That’s why you should be the one in charge of releases. If this doesn’t work for your team, for any reason whatsoever, try not to fight about it. Just make sure that you disclaim any blame if a release doesn’t go well. Remember, you can’t control something that you’re not responsible for. 

What now?

Last thing: just start! At COBE, we like to say: Better done than perfect. Working is a learning curve, but so is developing a process. You will encounter problems on the way, but good news is – you’ll also find solutions. And please remember that reading and covering the theoretic part makes you so much more prepared for any situation. You got this! 💪