Jonny Steiner, Product Marketing Manager
We’re sure that you must have experienced a scenario like this before: You are walking around somewhere in public and happen upon a younger person wearing a t-shirt of your favorite band. Perhaps your initial reaction is something like this, “Wow, a Nirvana t-shirt? I wonder if they know any Nirvana songs.” Sound familiar? Then congratulations you have gatekeeping potential! We say potential because in no case should you ever go up to people and grill them about their right to wear a Nirvana t-shirt. That is a lesson for life provided free of charge with this blog post.
Enough with the generalities though, we are here to discuss gatekeeping as it pertains to QA and testing teams. In the world of software development, a Gatekeeper is a person who has control over when a piece of software or update is ready to go into production. What that means is that in this scenario the gatekeeper takes all the responsibility for software quality. Often this role is played by a dedicated member of the testing or QA team.
Who Releases the Releases?
People often ask testers when they give their approval for release. Testers and developers often express frustration when they have worked on projects where QA held the keys to the release. Placing that level of responsibility on one team can lead to disputes and delays.
On some level, testing teams are proud of this designation as it places a great deal of power in their hands. However, it does bear the question of why QA or testing teams need to approve a release at all. Certainly not trying to take a potshot at QA or testing teams. We all know that when placed under difficult conditions these teams do the best they can with good nature and aplomb.
On the other hand, putting testers in this position as the people responsible for the final say on releases puts a lot of pressure on them.
Let’s look at some of the negative consequences of having QA be your gatekeeper:
- All the bottlenecks – Development teams usually consist of five people with one person being designated the “tester”. It’s pretty simple math to see that making one person responsible for testing and quality can lead to bottlenecks.
- Bearing the brunt of responsibility – Making one person responsible for releases means that other team members will function under the false notion that all defects will be caught in QA. Perhaps even worse it also gives them the out to not take responsibility for any bugs that make it into production because they can simply blame it on QA.
- No one is perfect, not even testers – Best not to base your entire release process on one person finding all the bugs. They are human and so are you, and humans make mistakes.
- Feedback loops – In the gatekeeper model when a developer finishes their part in the process, they hand it over to the tester or QA and then move on to their next project. However, when the inevitable feedback comes in, they will need to context switch back to the previous feature. That can result in a mess of half-started and stopped projects.
The Alternative to Gatekeeping is Gatebreaking
There are ways to execute testing that make sure you release quality applications without the need for any gatekeeping. If you give the work of QA to the whole development team, you will make them all responsible for quality. QA can still be responsible for testing, but there is more testing to do and other team members can help.
- Developers can cover the work they do by writing their own unit tests.
- Product managers can check the staging environments to make sure new features perform as executed.
- DevOps managers can use CI systems to monitor testing as each new code is committed.
You can start implementing this practice simply.
Start with a session before the development work begins on a new feature. That way the developers and testers can go into the sprint understanding what they need to do to prove that work has been completed to the acceptance criteria. With the work being discussed ahead of time the workload will be spread evenly among the team and with API tests being written by the developers QA can work on UI and functional testing.
As the project progresses and the team finds an issue that needs to be addressed, they can discuss it amongst themselves or between teams. For example, if QA discovers a defect, they can bring it up with the product development teams to see if it is something that needs immediate attention or if it can wait.
Even better, as more people get involved with a project and participate in testing it leads to a Shift-Left mentality in which testing is done as early in the process as possible. No one needs to wait for a specific time to start testing, it simply becomes an aspect of people’s day-to-day routine. In the long term, this should help minimize risk toward the end of the development cycle
Ultimately it leads to more tests which translate into better coverage because it makes interdisciplinary teams communicate with one another rather than staying in their own siloed teams. If siloed teams are an issue in your organization, you can even bring it up with the product owners and stakeholders. Promoting communication and collaboration is extremely important when taking care of a gatekeeping situation.
The outcomes will then look like this:
- Shared responsibility – With no one person responsible the entire team takes on the responsibility for delivering quality software.
- Bye-bye bottlenecks – It is not one person testing against the world anymore. With everyone testing, new versions and apps will get to production faster.
- Tightening the feedback loop – No more context switching when a defect is discovered. Defects will be discovered and mitigated early in the process, eliminating any delays to production.
Gatekeeping in QA is a Relic
It still happens in some organizations. QA is made responsible for a project’s release and holds the keys to the release. This harmful practice puts pressure on testers and leads to bad relationships between siloed teams as they work separately towards a goal they are not collaborating on.
There are two main negative scenarios when practicing QA gatekeeping:
- Delayed projects – As QA blocks certain small issues before release.
- Defects in production – Whenever a bug slips through the cracks QA is the scapegoat because they are seen as responsible for quality overall.
To shed this antiquated – and frankly anti-collaborative – method of development and testing, teams need to have everyone on the project working on testing as they develop, rather than have QA be responsible for all of it. They also need to shift left and test early and often. Having this basic understanding will help organizations create a system where everyone can do their part and the overall quality of their releases will improve as well.
Quality as a goal and as a concept needs to be one of the fundamentals of a team’s workflow. It also needs to be something that everyone who is involved in a project participates in. If you see some of the siloing or lack of cooperation between teams start to arise in your company you should bring it up with those in a position to change that. When a QA team is focused on gatekeeping your overall app quality will suffer, and that is a shame because the word is literally in their title.