Berufsbild Tester

Das Berufsbild Testen beschreibt, welche Aufgaben, Skills und Positionen heute notwendig sind, um Softwarequalität in agilen Teams sicherzustellen. Qualität ist dabei keine Einzelperson-Verantwortung mehr, sondern eine Teamaufgabe. Gefragt sind analytische, technische und planerische Fähigkeiten, die je nach Projektsituation unterschiedliche Personen im Team übernehmen.

Das Wichtigste in Kürze

• Testen ist keine Einzelperson-Aufgabe mehr: Im agilen Team trägt jedes Mitglied Verantwortung für Qualität, unabhängig davon, ob “Tester” auf der Visitenkarte steht.
• Entwickler wenden Testmethoden wie Äquivalenzklassenanalyse und Entscheidungstabellen unbewusst bereits an, wenn sie If-Then-Else-Strukturen aufbauen, ohne es so zu nennen.
• Planungs- und Managementfähigkeiten bleiben in agilen Teams unverzichtbar: Wer Scrum ohne Plan betreibt, scheitert, auch wenn die Rolle “Testmanager” offiziell nicht mehr existiert.
• Wissen allein reicht nicht: Erfahrung, also Konzepte tatsächlich angewendet und deren Wirkung erlebt zu haben, ist laut German Testing Board die entscheidendere Kompetenz.
• Das Berufsbild Testen des German Testing Board steht als kostenloser Download bereit und gibt sowohl Einzelpersonen als auch Führungskräften eine strukturierte Grundlage zur Karriereplanung und Teamzusammenstellung.

Das Berufsbild Tester wandelt sich, das Testen bleibt

Die Anforderungen an das Testen ändern sich nicht. Was sich ändert, ist die Art, wie Teams arbeiten. Genau dort liegt die Verschiebung, mit der sich Tester heute auseinandersetzen.

Früher lief Testen sequenziell ab. Ein Tester bekam die fertigen Requirements, dann die Software, die jemand anders gebaut hatte. Er schrieb seine Testfälle, fand Bugs und meldete sie. Jede Tätigkeit war einer Person zugeordnet, klar abgegrenzt, nacheinander.

In agilen Teams funktioniert dieses Modell nicht mehr. Es war auch vorher nie wirklich gut. Was fehlte, war die Zusammenarbeit: der frühe Austausch mit den Kollegen und ein geteiltes Verständnis davon, was Testen eigentlich ist.

Der Kern liegt in einer kleinen Umformulierung. Es geht nicht um den Tester als Person, sondern um das Testen als Tätigkeit, die getan werden muss, um Qualität sicherzustellen. Wer diese Tätigkeit ausführt, ist eine zweite Frage.

Warum Testen heute eine Team-Aufgabe ist

Qualität entsteht im Team, nicht durch eine einzelne Rolle. Der whole-team-approach trifft genau diesen Punkt: Nicht eine Person ist für Qualität zuständig, sondern alle gemeinsam.

Der Grund liegt in der Arbeitsweise selbst. Wenn ein Team in kleinen Inkrementen entwickelt, einzelne Features statt eines fertigen Produkts, ändern sich laufend die Anforderungen an das, was getan werden muss. Mal ist eine Datenbank aufzubauen, mal eine Oberfläche zu erweitern, mal eine Schnittstelle zwischen Frontend und Backend einzubauen, mal eine Komponente auszutauschen.

Diese wechselnden Aufgaben verlangen unterschiedliche Fähigkeiten zu unterschiedlichen Zeitpunkten. Ein Team ist manchmal zu klein für alle nötigen Kompetenzen, ein Produkt manchmal zu groß für ein einziges Team. Dann kommen Themen wie Releases, Testumgebungen und Testautomatisierung hinzu, die über das einzelne Team hinausreichen.

Tester haben nie Fehler eingebaut. Sie konnten früher nur nicht frühzeitig dafür sorgen, dass Fehler gar nicht erst entstehen. Genau das verändert der Team-Ansatz: Qualität wird nach vorne verlagert, in die Phase, in der noch nichts gebaut ist.

Was Programmierer schon tun, ohne es Testen zu nennen

Viele Disziplinen wenden Testmethoden bereits an, nur unbewusst. Das macht den Übergang leichter, als er klingt.

Ein Programmierer braucht eine Entscheidungstabelle und Kombinatorik im Kopf, um seine If-Then-Else-Strukturen aufzubauen und seine Methoden zu strukturieren. Eine Äquivalenzklassenanalyse steckt implizit in jeder sauberen Architektur. Das ist im Grunde dieselbe Denkweise, die Tester als Testdesign kennen.

Das, was du tust, ist ja schon Testing. Jetzt musst du das nur noch konsequent anwenden.

Steffen Schild

Dieses Bewusstsein zu schaffen, ist der Weg, andere Disziplinen ans Testen heranzuführen. Wer einem Programmierer zeigt, dass seine tägliche Arbeit längst Testmethodik enthält, senkt die Hürde, sich aktiv mit Qualitätssicherung zu beschäftigen.

Umgekehrt gilt dasselbe für Tester. Ein Tester kann heute nicht mehr sagen, dass er nicht programmiert. Ein Programmierer kann nicht mehr sagen, dass er nicht testet. Aus dieser Denkschematik der vergangenen Jahre sind agile Teams herausgewachsen.

Positionen statt Rollen: Verantwortung auf Zeit

Im neuen Berufsbild des German Testing Board ist von Positionen die Rede, nicht mehr von festen Rollen. Eine Position ist eine Aufgabe, die jemand für eine bestimmte Zeit verantwortlich übernimmt.

Das bedeutet nicht, dass du dein Leben lang in einer Position verharrst. Der agile Teamgedanke erwartet im Gegenteil, dass jemand zu unterschiedlichen Zeitpunkten unterschiedliche Schwerpunkte hat. Mal liegt der Fokus auf Backlog-Analyse und Acceptance-Kriterien, mal auf Testautomatisierung, Testdatenmanagement oder Testumgebung.

Das erste Berufsbild entstand 2017. Die Überarbeitung kam, weil Agilität die Rollen verschiebt und Aufgaben über klassische Grenzen hinweg verteilt. Vorausgegangen war eine Entwicklung beim ISTQB: Aus vier oder fünf Grundlehrplänen wurden um 2012 und 2013 herum rund 15 Lehrpläne, was die Frage aufwarf, wer diese eigentlich braucht und wie das Ganze zusammenhängt.

Welche Skills ein Tester heute mitbringen sollte

Das Spektrum ist breit, und die Schwerpunkte verschieben sich mit jeder Aufgabe. Drei Bereiche tauchen immer wieder auf.

• Analytische Fähigkeit: Das Big Picture verstehen. Herausarbeiten, wie ein neues Feature zum bestehenden System passt und ob es Inkonsistenzen gibt. Daraus Testdaten ableiten und Testfälle gestalten.
• Technisches Verständnis: Einschätzen, welche Auswirkung die aktuell implementierte Technik auf das bestehende System hat und auf das, was später noch dazukommt.
• Testautomatisierung: Den entworfenen Testfall implementieren. Das kann ein Tester mit Programmiererfahrung übernehmen oder ein Programmierer im Team, der den von jemand anderem entworfenen Testfall umsetzt.

Diese Aufteilung der Tätigkeiten nach Skill ist kein Notbehelf. Sie eröffnet Entwicklungsmöglichkeiten. Wer selbst automatisieren will, lernt zu programmieren oder holt alte Kenntnisse hervor. Wer sich für Schnittstellen interessiert, vertieft sich in REST und API.

Daneben existieren Spezialisierungspfade, die zu Nischen geführt haben: Performance, Security, Game-Testing, Testautomatisierung. Du greifst eine solche Nische auf, weil sie dich persönlich interessiert, oder weil sie für das Team wichtig ist und sonst niemand sie abdeckt.

Wissen ist eine Sache, Erfahrung die wichtigere

Ein Berufsbild trennt bewusst zwischen Wissen und Können. Wissen lässt sich in Kursen aneignen. Können entsteht erst, wenn du eine Tätigkeit tatsächlich gemacht und Erfahrung gesammelt hast.

Das ISTQB-Programm deckt das Testwissen ab. Für ein vollständiges Profil braucht es mehr: Domänenwissen, Technologiewissen und Prozesswissen. Sobald es um konkrete Werkzeuge geht, übernehmen die Werkzeughersteller mit spezialisierten Kursen.

Mehr Kurse machen dich nicht automatisch besser. Wer Performance, Security und Safety gleichzeitig belegt, gewinnt in der Breite, aber nicht zwangsläufig in der Tiefe. Für echte Stärke in einem Thema brauchst du Erfahrung, nicht nur Zertifikate. Vieles aus der Ausbildung wendest du nie an, anderes prägt dich, weil du gute Erfahrungen damit gemacht hast.

Management-Skills verschwinden nicht, sie verteilen sich

Planung, Schätzung, Metriken, Reports und Konzepte bleiben notwendig. In Scrum gibt es nur keine Rolle mehr, die “Manager” auf der Visitenkarte stehen hat.

Scrum braucht Planung ohne Ende. Wer Scrum ohne Plan startet, sollte es lassen, denn nach drei bis sechs Wochen wird die Lage eher schlechter als besser. Die Planungs- und Managementtätigkeiten müssen gemacht werden, sie sind nur ein Skill unter mehreren, der im Team vorhanden sein muss.

Wer diese Tätigkeit übernimmt, wechselt mit dem Kontext. An einem Tag ist derjenige Häuptling, der das Testmanagement plant. Am nächsten Tag derjenige mit der Business-Kompetenz für die Backlog-Analyse. Am dritten der erfahrenste Programmierer, der über Tool und Framework entscheidet.

Auch grundlegende Managementfähigkeiten gehören damit zu jedem im Team. Wer abschätzen kann, ob etwas in den Sprint passt, oder einen Report mit einer belastbaren Metrik unterlegen kann, bringt das Team weiter, egal welche Bezeichnung er trägt.

Wie du deine Testerkarriere heute planst

Orientierung beginnt bei dir selbst, nicht bei einem Kurskatalog. Schau aktiv, was in deinem Team passiert, und frag dich, wo es krankt und was dir am meisten Spaß macht.

Ein Reflexionszyklus hilft dabei: einen Plan machen, ihn umsetzen, regelmäßig prüfen, ob er noch passt. Wo liegen deine Stärken? Was willst du machen? Diese Antworten kann dir niemand von außen geben, aber ein Referenzschema wie das Berufsbild liefert die Landkarte dazu.

Konkret vorgehen kannst du so:

1. Beobachte, welche Aufgaben in deinem Team anfallen und wo Lücken sind.
2. Kläre für dich, welche Tätigkeit dir liegt und welche du vertiefen willst.
3. Sprich mit Kollegen aus den Testing Boards oder Fach-Communities über deine bisherige Erfahrung.
4. Gleiche deine Stärken mit dem Berufsbild ab und leite Weiterbildung und mehr Verantwortung daraus ab.

Karriere heißt hier nicht nur Fortbildung. Sie heißt auch, schrittweise Verantwortung zu übernehmen: erst für einen kleinen Bereich, dann für einen größeren. Wer sich engagiert und in eine Richtung weiterbildet, wird mit höherer Wahrscheinlichkeit auch im nächsten Projekt derjenige sein, der diese Tätigkeit verantwortet.

Das Berufsbild taugt nicht nur für Einzelne. Als Teamlead oder Personalverantwortlicher kannst du damit abgleichen, was deine Leute können und welche Skills im Projekt noch fehlen. Du musst kein Fachexperte sein, um eine fundierte Empfehlung für den nächsten Schritt zu geben.