Its "Testing" - not "A Tester (he/she/divers)"

"Testing" - an attempt to get around the hotly debated gendering? No. "Testing" - an attempt to bypass the cost discussion when hiring or adding a certain tester person? No. We know the discussions that arise in every project: at what point do we need testers, at what stage of the project do they have anything meaningful to do (in truth: how long can we delay bringing in testers for budgetary reasons).

Since we develop agile and the principle of "test automation first" applies there, the developers can also do this thing of „writing test cases“ (in truth: the programmers). They are in the project anyway, so we save on additional employees. These discussions are annoying.

The approach of switching to the term "testing" brings to the fore the aspects that are really important: what actually needs to be done to ensure the necessary quality. Only then the question is considered, which positions we need for this in our (agile) team, so that the tasks are done with the necessary know-how and the required efficiency. As a result, only then the original question can be answered in a qualified way, which persons fit into our team based on this individual analysis.

The talk would like to present this different, exciting, realistic approach and show its flexibility. By the flexible approach of approaching the team composition based on the necessary tasks to be done, the ideal of the self-determined, efficient and quality-conscious team becomes tangible and experienceable. A "whole team responsibility for quality" is created. 


This approach was used by the German Testing Board as the basis for a new „Berufsbild Testen (job description for testing)“. As I had the chance to participate in creating this new version, I want to share my insights, my motivation and a lot of lessons learned from working with other people on this fascinating, real world view.