How We Eliminated the Gatekeeper of Quality

In the past couple of years, I’ve worked as a part of the Thoughtworks TechOps delivery team. Our work largely entails maintaining and enhancing internal system portals for employee information, resource management, client management etc.

Since my first assignment on the TechOps team, which was building a test automation framework from scratch, I have tested on various other internal systems that span numerous domains and technologies. A key challenge across all my projects as a Quality Analyst (QA) has been getting the entire team to have an active stake in the application’s quality. On the last project I worked on, an application for the Sales team, we hit all the right notes as far as collaborating on quality goes. It made a huge difference to our test coverage, team morale and most importantly - the app’s quality. Here are a few takeaways that helped us reach our testing sweet spot:

#1 Involve the QA from the start

The headstart gained from involving the QA from the start cannot be understated. It helps with analyzing and understanding business requirements from the user’s perspective leading to use-case scenarios that stand the test of time (and the UATs). While the BA focuses on what the system should do, the QA provides understanding of the boundaries around it, and the limits of the system. It also helps the QA to understand the business value of the requirements and put Behavior Driven Testing into practice.

#2 “Four Amigos” from Story Kickoff to Signoff

Having the Business Analyst (BA), QA, experience designer (XD) and developer pair (extending the Three Amigos of software development) come together at story kickoff not only helps creating a shared understanding of the story, but also helps the story to be understood through various viewpoints. The story scenarios are fully detailed and defects are prevented from the start rather than waiting for them to appear.

But this collaboration shouldn’t end at kickoff, but persist till signoff. For instance on our project, developers couldn’t move the story to 'Development Done' unless it was showcased together with the BA-QA-XD. This helps a lot in reducing the “testing re-testing” cycle that normally takes place both due to missed requirements as well as defects found after the story has moved to 'In QA' (with the developers having moved on to a new story). I can proudly say that most stories had few to no bugs by the time they reached my plate!

It also helps with sustaining a healthy test pyramid, as I detail in the next point.

#3 Encourage a healthy Test Pyramid

Having the team “own” quality is key to developing a robust test pyramid and achieving optimal test coverage. When developers thoroughly test their code using unit or integration tests, it pushes the majority of the tests to a lower, more granular level and we benefit from fast feedback and lower maintenance effort. This also enables us to swap numerous (and typically brittle) UI-level tests for fewer macro-level tests that are meaningful to the business.  

Owing to the emphasis on “collaborative quality” on our project, the developers write unit, integration, JavaScript, and contract-level tests where appropriate. We have one single, browser-level, automated user journey that tests the end-to-end critical happy path of the system. It is a single functional test that we can easily adapt to changes in the user journey or the addition of new features to the system. This is how we experienced the sustainable implementation the Test Pyramid and awesome test coverage.

When everyone has a stake in the application’s quality, not only are writing tests collaborative, but fixing tests too. Fixing the broken builds becomes a team exercise, and a huge learning experience for every role.

I hope these pointers help you encourage your team to own the application’s quality. Do share your thoughts and suggestions too.

Special thanks to Sreedevi  TK, Avadhut Diwane, Arvind Awte and Christopher Kozak for all their wonderful guidance.