Yesterday, when sitting in my hotel room grounded by flu and haze, I saw an interesting tweet linking to an Agile Testing Manifesto. I am somewhat sure that the original link is this one. Well, it is nice, even though a bit debatable. “Testing throughout” is actually not an agile idea (the first works pointing that out are way older) and “testing understanding over checking functionality” should be reworded in my opinion. I do absolutely agree with the notion behind that sentence, yet I have a hard time sidelining the functional correctness of a program in exchange the tester’s understanding. I know, it is meant differently!
Nevertheless, the points of that manifesto the author consider more valuable resounded very well with me. Yet, it brought me to the conclusion: “We have to get rid of testers!”
Here the are:
- testing throughout
- preventing bugs
- testing understanding (seriously, I don’t want to test anyone’s understanding – Let’s go with tester’s understanding)
- building the best system
- team responsibility for quality
Therefore, the Logical Conclusion is that We Must Get Rid of Testers
Not! Well, yes, but not that straightforward. The biggest problem is the the name of the job itself. When we talk about testers outside the community, there is still a vast majority of people to whom a testers job description sounds like that: “Tries out a program”. While definitely short and therefor vastly incomplete, this is what a tester is identified by.
We go into discussions whether something is checking or testing, which nobody outside actually gives a damn. The conclusions we draw from these discussions and a “better test” as a result are things the outside world cares.
A large number of people see testers still nearly in the sense of the words entymology (“a pot in which metals are tried”). Program into pot, trying, bugs out.
But we do not want to restrain ourselves to the software. We want to be engaged early on (again, not an agile idea). We have learned that reviews of all the other artefacts we create is important. This is also what testing throughout means. Challenging the product owner, reviewing design, coach developers to write better unit tests.
Yet engaging testers early is still seen cumbersome, and more often than not it is still the case – even in Agile settings – testers are kept out of the loop in early phases of product and feature creation and design.
Yet this is also what preventing bugs means. Bugs are prevented by reviews. Bugs are also prevented by due process. Whenever we find a step in our process we introduce bugs regularly, it will be in the testers interest to improve that process. And most testers I know will step up.
The good testers I know, always have a good understanding about the product. They also know the context of the product and the potential users and usage. They work closely with product managers to understand also the background of given features. They are also capable of challenging product design idea with their knowledge about the former. Yet there are many organizations, where the opportunities to work with product managers and requirements engineers is rather limited. And, due to the fact they are testers, quite often they are not recognized as a valuable source of information.
Building the best system means a system which has a high quality in use. A tester an only work towards that, if he has aforementioned knowledge and understanding. But it is way more effective to use that knowledge while creating and discussing features. At this point in time they have to be seen as persons being able to give that valuable input.
Finally, the question of team responsibility. I am sure everybody heard the sentence “has that ever been tested” when something did not work. It might be only the terminology, but the responsibility for something working not correctly is implicitly shifted towards the testers. And yes, of course, also developers do test quite a lot. But it is still in the heads of most people – and to quite some extent true – that the final testing is done by testers. It might be a team responsibility to deliver good software. I personally do not believe that this is an idea of agile. In all organizations I worked for, every developer and tester wanted to create the best possible thing. The opinions on what that actually was, often differed, but that is only fair.
However, making everyone responsible also can lead to a bystander problem, where everyone trusts someone else will take care. It always seems worthwhile to have someone to own and drive a topic, even though he or she is not the sole responsible for it. It is rather natural that a tester would take the lead in the area of quality. In my opinion it is also expected.
Image is everything
So we know that testers can do it, they prove it everyday. Yet, in a lot of settings these potentials aren’t used. And this is also true for Agile settings. Why is it that way? In my opinion one reason for that is the job title itself. No developer would be very happy, if we would call him coder. Yes, they do code. But this is not everything they do. Not even the majority of their work.
We might split hairs on what is actually testing, and that reviewing documents is testing as well. But no one cares. The name to an extent defines the thing. And its perception. And therefore a tester is a person who tests. And testing is defined the way the testers is seen, and not as what we, the community of quality professionals actually believe and know testing is about.
Therefore, we must get rid of Testers
We must change the perception. And that implies also changing the name of the role. We do more than test (at least with respect to what most people understand when using that word). This has to be expressed in the job title as well. Do I have a great one? No, by no means. I personally name our job openings “QA Engineers”, yet there are reasons why I am not happy about that as well. When it comes to describing myself, I refer to myself as a “quality guy”. Not catchy, but it quite defines how I feel about my work.
I help customers create better quality software. And I address many aspects of the lifecycle, starting with planning processes and lifecycle management spanning towards development processes and – yes – testing. Because many aspects have an influence on the quality of the end product.
Let’s get rid of testers. Let’s get us Quality Engineers, Q-Wizards, Customer Satisfaction Masters! Well, ok, and let’s work out a catchy name.
This post is also available in: German