Testers/QAs should not be Gatekeepers
There have been times throughout my career where I have been in a Gatekeeper position. Sometimes, this specific wording has been in the job description itself, and other times, it has just been a role I have found myself in.
What is a Gate Keeper?
The dictionary definition of a Gatekeeper is as follows:
a person whose job is to check and control who is allowed to go through a gate
To put this into the context of software development, the person in the Gatekeeper role is solely responsible for controlling whether the software is ready to be put into production. Meaning that Gatekeeper is shouldering full responsibility for the quality of the software. Usually this Gatekeeper is the dedicated Tester/QA in the team.
Why are Gatekeepers a bad idea?
There are a few reasons…
QA becomes a bottleneck
In the majority of development team’s I have worked in, they consist of 4–5 people, and usually only 1 being the dedicated role of ‘Tester’ or ‘QA’. It takes no maths wiz to work out that having 1 person responsible for testing and ensuring quality will inevitably cause a bottleneck.
Single Responsibility
The Gatekeeper model for QA within a team promotes the unproductive “chuck it over the fence” mindset. Having a Gatekeeper makes them the catch-all that gives other team members the false sense of security that they don’t need to worry too much about what they’re doing because it will be ‘caught in QA’. It also enables them to not shoulder any burden when bugs go into production as it was “missed by QA”.
Testers are not perfect humans
As much as I would love to catch every bug and think of every possible scenario and edge case, I am human, and I will miss things. So hedging all your bets on ensuring everything is working correctly on one person is a lot to ask.
Large feedback loop
When a developer has finished their bit, and passes it on to the Tester/QA in the team, they don’t sit there waiting for bugs and feedback to roll in, they will move onto the next thing. When the Tester/QA then raises any feedback, the developer will have to context switch back to that feature, leaving your Kanban board scattered with started and in progress features.
What’s the alternative to the Gatekeeper model?
One alternative is to remove QA as a phase during development and instead make the entire team carry out testing to prove their work.
How does this work in practice?
There is no right or wrong way to implement this, but in my own experience, this has worked well by having a ‘test kick-off’ session prior to a development starting on a new feature. The purpose of the session is a quick discussion between the developer and the Tester/QA as to what testing needs to be done to prove the work has been completed to the acceptance criteria, and most importantly, how automation will be added to ensure the feature never breaks in the future.
For example, you may be working on a story that involves adding the ability to add a secondary email address to a user’s account. The developer could create acceptance tests at the API level for the endpoints that will be added, allowing the QA to then focus on creating the UI level acceptance and functional tests to handle the potential responses from the endpoints. This would then share the workload of the testing and using this approach, will likely lead to more automated tests being created.
!It is assumed and expected that the developer would be writing code level (unit) tests regardless.
Shared responsibility
No more “throw it over the wall” culture! The safety blanket and scapegoat are gone! No one person is responsible for the quality of the software the team ships, it is now a collaboration to ensure quality.
Bottleneck removal
Now you’re not waiting for one team member to test, the work will get through to production much faster. The dependance on that one team member has been alleviated in part, freeing them up to focus on less at once.
More sets of eyes
There is no question about it, having 2 people check something is correct is better than 1. This should increase the likelihood that unforeseen issues are caught before shipping to production.
Tighter feedback loop
As the developers will now be looking to part evidence their work, they aren’t going to be context switching when issues are found. This should mean issues are fixed as they are found, reducing the delay of that feature going through to production.
So does this mean you don’t need dedicated Tester/QAs?
The idea behind removing the dedicated Tester/QA as a Gatekeeper is not to eliminate the need for that role, but to instead enable them to lead the team’s approach to testing and quality assurance.
