English
This is a software engineer’s typical interpretation of what a tester does:
Verify a = b. If a != b then file bug
This is of course a very simplistic view, one that does not at all jive with what a tester actually does. However, as a former software engineer myself, this was exactly my view when I was an active developer. Testers were looked on as minor inconveniences, devoting their entire life to pointing out areas where you as a developer had screwed up by having bugs in your code. The typical rant during the water cooler conversations was “We have a terrific product – if only the darn testers would stop finding bugs.”
Then something changed: I joined a startup – a startup that developed and ultimately released the first commercial tool devoted solely to automating network testing. And just like that my typical day as a software engineer changed. I was forced to think like my target persona, a network tester. Live and breathe the life of a tester, day in and day out. And like most startups we were short-handed, often having only developers and none to very few testers. So, to ensure our product was properly tested we improvised by having a series of regular exercises where all developers switched hats, became testers, and attempted to break each other’s code.
That’s when I began to truly appreciate the job of a tester. I had to think outside the box as now my main job was to break stuff. That is not so easy as it sounds – you have to imagine all the different ways in which your ultimate end-user will end up interacting with the product, and then proceed with gusto to try and break all those interactions. The crowning moment would occur when after you had completed your exercise, the regular testers would proceed to show you exactly how many bugs you had missed. Oh, the agony!
Fast forward to today. I’ve now been immersed in test automation for more than ten years. And these ten years have seen the development of the principles of Agile methodology and cross functional teams. The only role recognized by Agile is the “Developer”. The separation between developing and testing has become blurred.
So do we not test anymore? Is the tester dead and buried?
Not really. What has happened is that the role of a typical tester has diminished, replaced by the activity of testing – basically everyone in the team is a developer and a tester.
What does this mean to a person who was just a tester before joining an Agile team? Does he now have to become a developer? Sure, if he wants to – that’s a great way to improve your skill set. But that’s not the only option. Guess what: there are now developers who need to learn the skillset and mindset of testing – which as I have painfully experienced before, is a lot harder than most folks give credit for. An engineer is always taught to build. The concept of break is alien and needs to be properly cultivated - it is both an art and science in itself.
This means that the tester of old now has an increased responsibility of educating, mentoring and guiding the Agile team to produce better quality by doing better testing. Of taking the lead in test-driven-development (TDD); coaching others in the mindset of being a tester – to break stuff. And given the variations in the skill sets in a team, some will perform more testing activities than others.
Testing remains an integral part of the development process, and as such the demand and need for the testing skillset and mindset is not going away anytime soon. Embracing the mentality of testing as an activity, and not being stuck on testing as a role is what I think today’s testers need to do to ensure success both for themselves as well as for the team.
This is the new Tester. This is today’s Tester. Long live the Tester!
