Stop Testing and Start Developing

The diversity of tester position titles knows no bounds. Regardless of what's written in your employment contract, email signature, or business card, you usually introduce yourself as a tester. How about ending this designation and stopping testing to start developing?

Why don't I like the word tester? In my opinion, this word refers to someone who simply tests - whether following a test scenario or not. Yes, we all do this, but it's only a small part of our job. We do much more, and testing itself is just one of the final steps in the entire software development process.

Imagine a football match where the striker stands by the opponent's goal the entire time, waiting for a pass. But that's not how football is played. Even a striker must run across the entire field, defend, pass, or stand in the wall during a free kick. We can then call such a player a footballer. Striker is just a specific role in the team, or if you will, a specialization.

Sometimes, however, this is exactly how it looks on software projects. Testing is the final step of the entire process, and testers often only receive the assignment in the form of a customer requirement and a "finished product". Testers then have no overview of everything that happened during development and whether there were any changes to the requirements.

In my opinion, it's a big mistake when a tester is not part of the entire development process and cannot "interfere" in each of its parts. Testers often have a better overview of how the application (as a whole) works and how users use it. Proper feedback can reveal some problems much earlier than they would occur, ultimately saving time and money.

Even upon receiving requirements from the customer or stakeholders, a tester can encounter inconsistencies or missing information in the assignment. Subsequent discussions often reveal a lot of information related to the testing itself. Slowly, a test scenario begins to emerge. I've experienced several times that discussions about testing had a big impact on the solution design itself.

While programmers write code, testers write test scenarios and prepare the testing environment. This is when most questions arise, and complications are often encountered. Immediate feedback to developers is most important at this stage. I remember, for instance, a situation where a colleague and I were discussing my concept of a test scenario and encountered a problem that led to a complete redesign of the implementation. The programmer thus "wasted" one day of work, but if he had worked on it for a week and I had immediately returned it from testing, there would have been many more wasted days.

So what does a developer actually do? Nowadays, developers are involved in all phases of the process, and perhaps that's why we talk about them as developers and not as programmers. A programmer is someone who "just" writes code. A tester is someone who "just" tests.

Yet in every phase of the process, there's plenty of work for a tester, just as for a developer. It's no wonder that Scrum, for example, doesn't have a "tester" role at all. All members of a Scrum team are developers, just some specialize in specific activities.

So stop testing and start developing. Get involved in the entire process, be part of the development team. Become a developer specializing in quality and change the word tester on your business cards to, for example, the English abbreviation SDET - Software Development Engineer In Test.