Crash test dummies or judges–what do Testers really do?

I read a lot about what the job of testers is. But no one wrote about what the job of testers really is. Like the Ministry of Testing has an extensive list of what testers do on a daily basis. And if you Google about the job of a tester, you only get task descriptions, like test design, bug hunting, documentation or test automation. But these are all just the day to day tasks. They aren’t what testing is about. All of that is incidental. What is the first and principal thing a tester does. What needs does a tester serve, by testing?

Answering the question of what a tester does with “test design is like answering what an architect does with “stroke-drawing or answering what an artist does with “applying paint to canvas”. Although all of this is technically true, it doesn’t convey the big picture. It does not portrait the larger purpose and higher meaning of architectural design or painting. Likewise, “test design does not convey the inert significance of what it means to be a tester. Yet, this is what people talk about. No wonder the job is underappreciated...

The need a tester serves

The purpose of a tester is to represent the user. A good tester understands the needs and desires of the user and can speak in the name of the user. A good tester is a substitute of the user, a sparring partner for the developer, that gets to see all the ugly warts of the application. A tester is a crash test dummy that crashes the application times and again, so the actual user can rest assured and can safely take the next shortcut in the process the developer didn’t foresee and think about. This way, the tester prevents the user from anger and frustration and the company from brand damage and user fluctuation.

In most projects I know, there are typically (simplified) three main parties:

The project managers or product owners

They often have a birds-eye view on things. They are mostly interested in the general functionality (e.g. “one has to be able buy an item”). They mostly care about time and cost constraints. They usually don’t care if the user needs three more clicks to achieve some functionality or if the product looks ugly. Quality becomes an issue only if a certain functionality does not work and this poses a risk.

The developers

They have a very technical view on everything. What works for them usually doesn’t work for not so technically inclined users. I see this in our own project regularly, when developers are baffled how “normal users struggle with e.g. using git from the command line. They often care more for technology and the beauty and elegance of technical solutions, than for the real needs of users.

“The problem is that software engineers don’t understand the problem they’re trying to solve, and don’t care to.”

The Testers

They are responsible to ensure that what developers claim works in principle or works technically, really works in practice. But they do so from a user perspective. Projects where no end-users are concerned (API-design, technical interfaces, frameworks, etc.) are the only projects that can afford to have no testers.

This also matches my experience of many projects: In most B2B projects, the user is not the one who pays the bill. Which sometimes means that the end-user of a system doesn’t have too much to say in its creation. The focus is on functionality – quality and usability are “add-ons”. In B2C projects on the other hand, where the end-user also is the one with the money, quality is often a priority and testers are premier team members.

One could also say the tester is a power like in the separation of powers. The legislative power (the PM or PO) decides what has to be done in general. The executive power (developers) decide on the specific details and execute (implement) what has been decided. The executive power (developers) is answerable to judiciary (testers), which in turn ultimately decides e.g. whether taken measures are appropriate. This system of checks and balances helps to hold the developers accountable. It doesn’t say that developers aren’t committed to high standards of quality on their own. Just like many Kings of the ancient where benevolent and made some good decisions without being directly accountable. But the past has shown times and again, that not all humans aspire to the highest of standards. The system of checks and balances tries to take individual commitment (the “human element) out of the equation. And it adds an “outside perspective”, that is often hard to attain from within–even with the best of intentions.

There are more job roles in software development projects you might say. What about the UX-designers? They, like developers, think in terms of a future potential product. A tester on the other hand, has a real actual product. Take the Dyson Airblade for example. This product was extremely well designed. But if you ever encountered an Airblade where many people use it, you also know that it was badly tested. Why? Well, it doesn’t dry the hand, it blows the water away. And that water then has to go somewhere. With many wet hands, you always have puddles underneath. That is exactly what I mean: Foreseeing such an effect from blueprints or simulation alone is hard for a designer or developer. Recognizing this problem is easy for a tester.

Even on their own website, the problem becomes apparent

Arguably, every situation is different, and so is the job and are the daily tasks of every tester. But in my experience and understanding of most projects, testers create the most value by completing the trinity of perspectives: represent the user and hold developers accountable for their work.

Why do IÂ ask?

Why is this question even relevant? Because it defines what testers will do in the long term. If all a tester does is defined by small day to day tasks, and these tasks get automated ... the perspective for testers are dim. But if these tasks are just the incidental work when trying to achieve a higher goal ... and the goal as such remains unchanged and important, then testers have nothing to fear. Then they should be fond of better tools and higher efficiency and e.g. embrace automation. Then, also, the sheer thought of automating the user perspective and the judiciary “away is almost comical.

What do you think?

I would love to hear your thoughts about that, preferably on Twitter (@roesslerj). Thank you!