Article originally posted on LinkedIn.
A few weeks ago, I was reading a very interesting article that strucked me: Testers don’t test anymore, by Jason Arbon. It was reviewing the evolution of the Tester work in the Agile world today. While I mostly agreed with it, I was still amazed by this image of QA “breaking product” he used and spread.
This made me think of my own relationship to my job and reflect on the changes I observed since my beginning.
So what do I really do as a Tester?
Let’s be straight from the start: my job is NOT to “break a product”. Hey you, in the back! I see you looking at this article full of doubt. So let me develop!
It is true that when I get a product in my hand, my focus will be to stress it. But to be clear, I DON’T break anything. I will play with it, I will interact with it… But most importantly, I will highlight behavior that were already broken from the start! I do not create chaos, me evil QA/Tester engineers (hey, I know what you think!).
If the software is not answering properly to my activity, it means that there was already a gap in the development. I put the spotlight on it, for everyone to be aware and act adequately. And by adequately, I do not necessarily mean solving every single bug! I mean tracking it, informing our users about it, finding a fix, yes, but also simply making sure that the software does not crash. I see my job as a way to increase the knowledge base on the quality, the behavior and the limits of a product, could they be faulty or not.
Then why does this vision of “Tester = breaker” really bother me?
Call me picky if you want, but I believe words have a sense and we should use them properly. They shape the way we see the world, and in this particular case, the way the world sees and considers us.
I also think that starting a working relationship with this mindset can lead to a conflict relation. And you don’t construct a fruitful work relationship with such lack of confidence. At least not in the long run. Like saying software Developers are kids on the beach building their sandcastle, and Testers are those jumping on it and crushing all their efforts. As a Tester, my role is not to “rain on anyone’s parade”.
Now, let’s see the contribution of my job as Tester in the Agile world
First of all, I am part of a bigger group, including developers, designers and product owners. We all work for the same goal: making sure our customers can enjoy fully the product we deliver to them. And it’s true for all industries. Thus, this should not turn into a “clans versus others clans battle”.
Secondly, a bug is not about finger pointing someone’s mistake. We should reminds ourselves that bugs are always the result of a chain of missed steps. They should be an opportunity to improve, more than one to blame. A product does not exist miraculously only by the hand of developers. It involves a lot more expertise! If everyone is willing to take its part in Quality, the control happens as soon as the product is defined.
Of course, faulty code can happen. But we should learn from it, better than shame because of it.
More than trouble maker, let’s try to see and sell our job this way: helping every member to improve and master their skills
In any framework, including -but not limited to- Agile, Testers should work hand in hand with developers. More than trouble maker, let’s try to see and sell our job this way: helping every member to improve and master their skills, learn from their mistakes. To ensure in the same time that our customer benefits from these learnings. Increasing the knowledge on a product and its behavior leads to write better features and increase coverage. This is a win-win strategy.
A test is the result of an analysis of the product in a bigger context, so why not seeing our job the same way?
Edit: To complete the thought on this topic, I advise you to read this excellent article from Marilyn Paul on Moving from Blame to Accountability.