Das Berufsbild Testen beschreibt, welche Aufgaben, Skills und Positionen Softwaretester heute brauchen, 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 Softwaretester 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:
- Beobachte, welche Aufgaben in deinem Team anfallen und wo Lücken sind.
- Kläre für dich, welche Tätigkeit dir liegt und welche du vertiefen willst.
- Sprich mit Kollegen aus den Testing Boards oder Fach-Communities über deine bisherige Erfahrung.
- 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.
Häufig gestellte Fragen
Braucht ein agiles Team überhaupt noch dedizierte Tester?
Entscheidend ist nicht die Person, sondern die Tätigkeit: Testen muss getan werden, damit Qualität entsteht. Der whole-team-approach verteilt diese Verantwortung auf alle Teammitglieder, unabhängig davon, was auf der Visitenkarte steht. Wer das Testdesign macht, wer automatisiert und wer die Testumgebung verantwortet, hängt von den Fähigkeiten im Team und von der aktuellen Aufgabe ab.
Warum scheitert das klassische, sequenzielle Testvorgehen in agilen Projekten?
Im klassischen Ablauf bekam der Tester fertige Requirements und danach die Software, die jemand anders gebaut hatte. Jede Tätigkeit war einer Person zugeordnet und lief nacheinander ab. Was fehlte, war der frühe Austausch mit den Kollegen und ein geteiltes Verständnis davon, was Testen ist. In kleinen Inkrementen mit laufend wechselnden Aufgaben trägt dieses Modell nicht mehr.
Wie bekommt man Entwickler dazu, sich mit Testmethodik zu beschäftigen?
Am leichtesten über das, was sie ohnehin tun. Wer If-Then-Else-Strukturen aufbaut, arbeitet mit Entscheidungstabellen und Kombinatorik im Kopf. In einer sauberen Architektur steckt implizit eine Äquivalenzklassenanalyse. Diese Denkweise entspricht dem Testdesign. Das Bewusstsein dafür zu schaffen, senkt die Hürde deutlich stärker als der Versuch, Testmethodik als fremdes Thema einzuführen.
Was ist mit einer Position im Unterschied zu einer festen Rolle gemeint?
Eine Position ist eine Aufgabe, die jemand für eine bestimmte Zeit verantwortlich übernimmt. Sie ist kein Lebensabschnitt und keine Stellenbezeichnung. Der Schwerpunkt wechselt: mal Backlog-Analyse und Acceptance-Kriterien, mal Testautomatisierung, Testdatenmanagement oder Testumgebung. Das German Testing Board hat sein erstes Berufsbild 2017 veröffentlicht und es überarbeitet, weil Agilität Aufgaben über die klassischen Rollengrenzen hinweg verteilt.
Reichen Zertifikate aus, um als Tester fachlich stark zu sein?
Nein. Wissen lässt sich in Kursen aneignen, Können entsteht erst durch die tatsächlich ausgeführte Tätigkeit. Wer Performance, Security und Safety gleichzeitig belegt, gewinnt Breite, aber nicht zwangsläufig Tiefe. Das ISTQB-Programm deckt das Testwissen ab, für ein vollständiges Profil kommen Domänenwissen, Technologiewissen und Prozesswissen hinzu. Vieles aus der Ausbildung wendest du nie an.
Muss ein Tester programmieren können?
Nicht zwingend, aber die klare Trennung ist entfallen: Ein Tester kann nicht mehr sagen, dass er nicht programmiert, und ein Programmierer nicht, dass er nicht testet. Testfall-Entwurf und Implementierung lassen sich aufteilen. Ein Tester mit Programmiererfahrung setzt den Testfall selbst um, oder ein Programmierer im Team implementiert den von jemand anderem entworfenen Testfall.
Gibt es in Scrum noch Testmanagement, wenn die Rolle fehlt?
Die Tätigkeiten bleiben, nur die Visitenkarte verschwindet. Planung, Schätzung, Metriken, Reports und Konzepte müssen weiterhin gemacht werden, sie sind ein Skill unter mehreren im Team. Scrum braucht Planung ohne Ende: Wer ohne Plan startet, steht nach drei bis sechs Wochen eher schlechter da. Wer diese Aufgabe übernimmt, wechselt je nach Kontext.
Wie hilft ein Berufsbild einer Führungskraft bei der Teamzusammenstellung?
Es liefert ein Referenzschema, gegen das sich vorhandene und fehlende Skills abgleichen lassen. Als Teamlead oder Personalverantwortlicher siehst du damit, was deine Leute können und welche Fähigkeiten im Projekt noch offen sind. Fachexperte im Testen musst du dafür nicht sein, um eine fundierte Empfehlung für den nächsten Entwicklungsschritt zu geben.
