No matter how long you’ve been a QA tester, I bet you can still feel the excitement that a new project brings. However, each project comes with its own set of challenges, but the ultimate challenge of them all is challenging your standard set of development practices and adopting a new approach. 

Talking to my team lead, we decided that the way we are used to doing QA doesn't work anymore. It needs not just a facelift but, better yet, a complete makeover. But before deciding to change our QA process completely, all these questions ran through my mind: 

How to build ownership and responsibility within the team? How to set up a quality culture? How to teach developers to navigate through the product and not only build it? Is my imagination too wild to even think of a world where the developer never ever utters: “It’s working on my machine”?

In traditional QA, testers are last in line, the gatekeepers, the ones that give the green light for deployment and slow down the process. Why is that? Well, the times where there was one tester per developer are long gone. Current norm is one tester per 10 developers. So it is normal that QA becomes a bottleneck. Imagine what happens when that one tester is on a vacation or sick leave ... e-v-e-r-y-o-n-e freaks out. Naturally, one cannot help but wonder if there is a way to get rid of the bottleneck issue and devs' reliance on testers?

The bottleneck issue is not the only one QA testers and developers are facing. Context switching is another big one. When the developer finishes work on a ticket, they (I presume) get pretty excited and would like for a tester to check it right away. But as they move the ticket from In progress column to In testing column, the initial excitement fades a bit as they get to see quite some tickets already sitting in the In testing column. Damn. What is there for the developer to do other than switch to working on another ticket and then come back when the tester finally has time? Context switching is a big issue for developers and we need to find a way to reduce it. 

FInally, constantly going back and forth between tester and developer gets dreary. Testers find bugs that developers fix. When retest is done, more bugs are found, and more fixing is needed. And this goes on until no major issues are detected. But how do we go about solving this?

With all these issues in mind, something had to be done. So for our new project I was determined to test out a new approach. As the backend and the frontend foundations were on the drawing board, I had quite some time to catch up on what was new in the QA world and decide in what direction to steer our quality boat. 

I stumbled upon this video from the Atlassian team about Quality Assistance. It caught my attention like a siren singing to the sailor - I was hooked. It seemed to have answers to all my burning questions. Under the Quality Assistance model, the developers are responsible for testing their work, with advice and guidance from the testers - assistance rather than assurance. And responsibility for keeping quality high is shared among the whole team - PM, team lead, developers, DevOps and testers.

Developers independence from testers is a north star in this model. To achieve it, one needs to learn the skills of testing. Improving developers’ testing skill set leads to them looking at their software more critically, thinking ahead for scenarios under which it can break. By doing this well, we prevent most bugs from happening in the first place, and we try to avoid bugs before they are written which means that the additional time and effort to fix bugs or rewrite code is reduced. 

Domain knowledge within the team improves over time, as testing user stories forces you to learn other software parts. If this shift left is done properly, developers take responsibility, and testers are under much less stress with providing the safety net. Holding developers accountable means that the scope of testers work is reduced, leaving space for more strategic contribution. 

In this case the role of a tester changes. It becomes more of a coaching, supporting role. Proactive. In Quality Assistance, all newly added activities to the development process have a common ground -  the knowledge sharing from tester to developer and overall quality awareness. Companies that shift from traditional QA to Quality Assistance have in a way similar but yet different development processes. We connected bits and pieces from various best practices to best suit our project and our team. These have become our new, main activities: 

• QA Kickoffs  - advice and guidance from testers start with QA Kickoffs. This is where the tester and dev “sit down” (via Zoom) together in a quick 15 min discussion about how the story will be tested. Things like positive, negative cases, edge cases, test data & test environment requirements, automated tests (Unit, E2E) etc. get discussed here, resulting in Testing Notes. Ending the meeting, the developer is equipped with knowledge on testing his work before coding begins.

• QA Reviews - once the developer is confident in his implementation of the story and testing done on his part, the tester and the developer review the testing that was performed so far together and identify what further testing needs to be done before deployment can start.

• Paired exploratory testing - an activity where tester and developer work together on one computer. An exploratory testing session lasts about 45-60min. They test various end to end scenarios for more involved/trickier stories. The developer strikes the keys while the tester suggests ideas or tests, pays attention and takes notes, listens, asks questions, grabs reference material, etc. This is also the most effective way of building domain knowledge. 

• MOB testing - a group testing activity utilizing one computer - In this one hour workshop, we boost our testing skills by learning from one another, getting the best knowledge out of the team into the task at hand. We learn to collaborate. It is also a great activity to nurture shared responsibility for quality.

It has always been an expectation that the developers test their own code before turning it over. These activities help improve the quality of testing done at this stage. But how to execute this radical change? 

Discussing with my team lead, we agreed to do this in phases to not cause too much resistance. It has been working well for us so far. 

Here are the steps that helped us introduce and implement the new process:

• Get buy-in from the team lead/PM that you will need support of
• Explain the reasoning and benefits of the change to developers that the change is affecting the most
• Do it in phases, so people have time to adjust. Introduce QA Kickoffs and see how it goes. Once the team gets the hang of it, add additional activities into the mix
• Have regular chats with your fellow developers/designers/PMs and see how the change is affecting their work. Then, if the process needs tweaking, make changes
• Monitor the change over time and see how you are reaching the goal of shared responsibility.

In this transition period, a lot of testing will still be done by testers in parallel. It will take months to achieve complete independence from testers even for small features. But hey, as Ozzy Osbourne once said: “You’ve got to try and take things to the next level, or you’ll just get stuck in a rut.” 

Hope this gives you the courage to become more proactive and take the QA in your team to the next level.

‍

Want to chat more about how we can help you elevate your tech venture with our web development services? Get in touch at sales@dlabs.io.

‍

‍