Testers are not gatekeepers and production bugs are fine
As long as I can remember software testing has been subject (and debate) of change. It used to be us testers needing to move left in the v-model during the waterfall days, and through some detours we arrived at the whole automation wave with Agile and DevOps we are currently facing. In the midst of all this I noticed two fairly persistent factors that somehow were never part of the changes: testers are gatekeepers and production is a scary and dangerous place. Both are wrong of course.
Not that long ago production was off limits to testers. Functional testing within waterfall projects was very much about trying to break stuff and you wouldn’t want to break production now, would you? Besides that, the whole mindset those days was (understandably) based on catching bugs as early as possible to keep costs as low as possible. Production was an expensive place to find a bug.
Testers were considered to be the last line of defense between a bug and a production fix.
This gatekeeper role is something that is still often seen within Agile teams. The tester should look at everything before it goes live, because we don’t want bugs to land on production. When people are talking about the changing role of testers, the main focus of those changes is on automation and being able to work closer with developers. While developers transition nicely into the whole iterative/Agile way of working, testers are more often than not pushed into some sort of “mini-waterfall” project of their own. They are forced to act as a devoted Agile test automater, but are also supposed to still perform all duties associated with the gatekeeper role of days gone. It doesn’t take a genius to understand that this schizophrenic position is not sustainable, nor beneficial to either the Agile process or the quality of the software delivered.
Time is always limited, so choices must be made. Unfortunately, most of the time the wrong choice is made. I can’t even recall how many times I heard test colleagues utter something like: “I can spend 30% of my time on automation and the rest is for regular sprint work”. The percentage can vary, but you get the idea. Automation is less important than your old waterfall duties of checking everything before it is released. The problem is, this way you’ll never get to the point where you have a solid automated test suite that actually adds value. It always stays an afterthought until you decide to ga all in with automation. And to be very clear: you can’t do Agile without automated tests. The “regular sprint work” mentioned above, for a tester, should be automating the crap out of every test activity as much as possible.
While automating tests is important, gatekeeping is apparently considered even more important.
This is mainly caused by the fact that we are still afraid of bugs hitting production (it used to be expensive, remember?). But with Agile and, by extension, CI/CD we can do a deploy from commit to master to production within 20 minutes or so, tested and all. Bug fixes or rollbacks are easy to bring live and the time a bug can survive is greatly reduced. When you used to release every couple of weeks, I can understand why you would be afraid of a production bug. But with a solid deployment pipeline, bugs are no longer difficult, expensive or time consuming to fix. There really isn’t a reason why you should frantically check and double check everything before every deploy.
I also think that a lot of testers are still (at least partially) performing the gatekeeper role because there always has been a lot of misconception about what the main purpose of testing is. Most of the time people think it’s about finding as many bugs as possible. It’s not. Testing is about gaining confidence. And finding bugs can be a part of that process, but it shouldn’t be the main goal. Software will always have bugs, whether you find them or not.
“Program testing can be used to show the presence of bugs, but never to show their absence.”
Now, don’t get me wrong: you should always try to minimize the amount of bugs hitting production. It just shouldn’t be your sole purpose as the tester in a team.
Just perform as much (automated) testing as needed to make you feel comfortable enough to release your product. Once it’s on production you always can rollback or quickly fix a bug, if the severity is high enough. Your team is building things for the world to see and experience, so make sure that the world can use your product. Because actually running your software in production also has another benefit when it comes to finding bugs…
Production is populated by these mythical and hard to constrain creatures. They’re called users and they are the best testers I have ever encountered. The determination and dedication they possess in finding ways to not use your software how it is supposed to be, is mind blowing. They are able to break functionality and introduce bugs left and right in ways I could have never thought of. Now, that’s a lot af valuable information to gather.
Thank you for taking the time to reading this story! If you enjoyed reading this story, clap for me by clicking the 👏🏻 below so other people will see this here on Medium.
I work at Wehkamp.nl one of the biggest e-commerce companies of 🇳🇱
We do have a Tech blog, check it out and subscribe if you want to read more stories like this one. Or look at our job offers if you are looking for a great job!
