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.

Podle mě je velkou chybou, když tester není součástí celého vývojového procesu a nemůže “kecat” do každé jeho částí. Testeři mají často lepší přehled o tom, jak aplikace (jako celek) funguje a jak ji uživatelé používají. Správná zpětná vazba může některé problémy odhalit mnohem dříve, než by vůbec nastaly, a ve výsledku tak ušetřit čas a tím i peníze.

Už při obdržení požadavku od zákazníka nebo stakeholderů může tester narazit na nesrovnalosti nebo chybějící informace v zadání. Z následných diskuzí potom často vyplyne spousta informací týkajících se samotného testování. Pomalu tak začíná vznikat také testovací scénář. Už se mi několikrát stalo, že diskuze o testování měly velký vliv na samotný návrh řešení.

Zatímco programátoři píšou kód, píšou testeři testovací scénáře a připravují si testovací prostředí. Při tom vzniká nejvíce otázek a nejednou se narazí i na nějakou komplikaci. Okamžitá zpětná vazba k vývojářům je v této fázi nejdůležitější. Vzpomínám si například na situaci, kdy jsme s kolegou diskutovali můj koncept testovacího scénáře a narazili na problém, který vedl ke kompletnímu přepracování implementace. Programátor tak sice “zahodil” jeden den práce, ale kdyby na tom pracoval celý týden a já mu to pak z testování obratem vrátil, bylo by takto zahozených dní mnohem více.

Co tedy vlastně dělá vývojář? V dnešní době se vývojáři zapojují do všech fází procesu a možná právě proto o nich mluvíme jako o vývojářích a ne jako o programátorech. Programátor je někdo, kdo “jen” píše kód. Tester je někdo, kdo “jen” testuje.

Přitom v každé fázi procesu je pro testera, stejně jako pro vývojáře, spousta práce. Ne nadarmo například Scrum roli “testera” vůbec nemá. Všichni členové scrumového týmu jsou vývojáři, jen se někteří specializují na konkrétní činnosti.

Přestaňte tedy testovat a začněte vyvíjet. Zapojte se do celého procesu, buďte součástí vývojového týmu. Staňte se vývojářem se specializací na kvalitu a změňte si na vizitkách slovo tester například na anglickou zkratku SDET – Software Development Engineer In Test.