Ganzheitliches Testen (Holistic Testing) ist ein Ansatz, bei dem Qualitätsarbeit in jeder Stufe des Entwicklungszyklus stattfindet und nicht in einer einzelnen Testphase. Er verbindet die Verantwortung des ganzen Teams für Qualität mit Testaktivitäten, die durchgehend mitlaufen: in der Discovery, in der Planung, beim Bauen, beim Deployment und bei der Beobachtung, wie Kunden das Produkt in Produktion tatsächlich nutzen.
Das Wichtigste in Kürze
- Fehlendes gemeinsames Verständnis ist der Hauptgrund für Nacharbeit: Das Team baut und testet ein Feature, und der Product Owner lehnt es ab, weil die Anforderung nie wirklich durchdacht wurde.
- Testaktivitäten gehören in jede Stufe des Entwicklungszyklus, von der Bewertung einer Geschäftsidee in der Discovery bis zur Beobachtung des Kundenverhaltens in Produktion, nicht nur in eine eigene Testphase.
- Eine Risikoanalyse in der Planung verhindert Fehler, bevor eine einzige Zeile Code entsteht. Trotzdem lassen viele Teams sie aus, selbst wenn sie testgetrieben entwickeln und Continuous Integration betreiben.
- Tester, die Beziehungen zu Betrieb, Site Reliability Engineers und Designern aufbauen, sehen Risiken in Produktion, die innerhalb des Entwicklungsteams nie auftauchen.
- Eine gemeinsam erstellte Teststrategie als Mindmap wirkt stärker als ein geschriebenes Dokument, weil das Team damit arbeitet, sie aktualisiert und dabei auf Ideen kommt, die beim bloßen Lesen nicht entstehen.
Was ganzheitliches Testen bedeutet
Ganzheitliches Testen (Holistic Testing) verbindet zwei Gedanken: Das ganze Team ist für Qualität verantwortlich, und getestet wird einmal rund um den gesamten Entwicklungszyklus. Es ist keine Phase am Ende und auch nicht der Mini-Wasserfall, der sich am letzten Sprinttag staut.
Lisa Crispin und Janet Gregory haben das Modell auf die unendliche DevOps-Schleife gelegt und jeder Stufe Testaktivitäten zugeordnet. Die Anregung kam von Dan Ashbys Modell für Continuous Testing aus dem Jahr 2016. Sie wollten es ausbauen, denn die übliche DevOps-Schleife, wie man sie im Netz findet, zeigt genau eine “Test”-Stufe. Die meisten lesen das als automatisierte Tests in der Continuous Integration.
Genau diese enge Lesart ist das Problem. Damit Qualität in ein Produkt kommt, gibt es im ganzen Zyklus etwas zu tun. Wer das auf ein Kästchen im Diagramm reduziert, erzählt dem Team die falsche Geschichte.
Lisa und Janet sprechen bewusst von Stufen, nicht von Phasen. Zwischen Stufen gibt es keine Tore und keine Übergaben. Das Wort ist nicht egal: “Phase” lädt zur alten Gewohnheit ein, Arbeit über die Mauer zu werfen.
Der Zyklus beginnt lange vor der ersten Codezeile
Qualitätsarbeit beginnt in der Discovery, wo das Business entscheidet, was sich als Nächstes ändern soll. Schon hier kann jemand mit Testerblick unbequeme Fragen stellen. Passt die Idee zu dem, was das Unternehmen bisher gemacht hat? Welches Problem löst sie für das Business, und welches für den Kunden?
In der Planung bekommst du den größten Nutzen für den geringsten Aufwand. Das Team klärt, worauf es bei einem Feature am meisten ankommt: für den Kunden, für das Team, das die Software später wartet, und für das Unternehmen. Daraus wählst du die Qualitätsmerkmale aus, die am meisten zählen.
Oft spricht niemand über Qualitätsmerkmale, weil die Fachseite davon ausgeht, dass das Entwicklungsteam schon weiß, was zu tun ist. Sicherheit und Performance fallen genau in diese Lücke. Lisa spricht lieber von “Qualitätsmerkmalen” als von “nicht-funktionalen Anforderungen”, weil “nicht-funktional” ein falsches Signal sendet, wie wichtig sie sind.
Risikodenken gehört in die Planung, nicht hinterher. Lisa hat Teams erlebt, die testgetrieben entwickeln, Pair Programming und Continuous Integration machen und trotzdem die Anforderungen, die vom Produktmanagement kommen, ungefragt übernehmen. Fehler verhindern heißt: Risiken früh analysieren, die Arbeit schneiden und priorisieren. Mehr als etwa sechs Prioritäten gleichzeitig kann ein menschliches Gehirn nicht halten.
Die Planung auf Story-Ebene ist die nächste Schicht. Geh in jede Story hinein und bau mit dem Team ein gemeinsames Verständnis davon auf, was ihr gleich bauen wollt. Ein großer Teil der Fehler lässt sich verhindern, bevor jemand Code schreibt.
Kleine Änderungen senken das Risiko
Häufig in kleinen Schritten zu deployen ist der sicherere Weg, nicht der riskantere. Wenn du eine winzige Änderung auslieferst und etwas kaputtgeht, weißt du genau, was kaputt ist.
Beim Bauen entscheidet das Team, wie der Code für Monitoring und Observability instrumentiert wird. Exploratives Testen kann schon auf Story-Ebene stattfinden. Sobald der Code in einer produktionsnahen Testumgebung ankommt, sind neben den automatisierten Checks die Qualitätsmerkmale dran.
Manches Testen können nur Menschen. Exploratives Testen, Barrierefreiheitstests und andere Arbeit, bei der der Mensch im Mittelpunkt steht, lassen sich nicht wegautomatisieren. Sie stehen neben der automatisierten Suite, nicht in Konkurrenz zu ihr.
Testen in Produktion ist eine Option, wo die Domäne es erlaubt. Wo nicht, kannst du immer noch beobachten, was bei den Kunden passiert, oder ein Feature zuerst für eine kleine Gruppe freischalten. Ein Testerblick hilft, Muster, Anomalien und Risiken zu erkennen, wenn Änderungen live gehen, damit das Team schnell reagieren kann.
Auf der rechten Seite der Schleife halten sich Tester zurück
Viele Teams schauen nicht mehr hin, sobald ein Feature released ist. Für sie ist die Arbeit erledigt, weiter zum nächsten Ticket. Genau auf dieser Seite der Schleife hatten die meisten Tester nie die Chance, Fähigkeiten aufzubauen.
Faulheit ist selten der Grund. Die Leute sind überlastet und haben keine Zeit, darüber nachzudenken, was nach dem Release passiert. Die Arbeit wird an den Betrieb abgegeben, damit das Team mit dem Nächsten anfangen kann.
Tester zögern hier oft, weil ihnen die Werkzeuge fremd vorkommen. Sie fürchten, keine Logdateien lesen oder keine Monitoring-Dashboards bedienen zu können. Viele dieser Tools sind heute wirklich einfach zu benutzen, und die Fähigkeiten, die Tester schon haben, lassen sich direkt übertragen.
Wenn dein Team nicht nach dem Motto “you build it, you run it” arbeitet, bau Beziehungen zu den Leuten auf, die den Betrieb machen. Frag die Site Reliability Engineers und die Betriebsspezialisten, was sie in Produktion sehen und welche Risiken dem Team wehtun. Was du dabei lernst, fließt zurück in die Teststrategie, damit sie diese Risiken abdeckt.
Der Whole-Team-Ansatz reicht über das Entwicklungsteam hinaus. Du brauchst Kontakt zu Designern, zu den Marketingleuten, die die Analytics haben, und zu Platform Engineers, wenn keine in deinem Team sitzen. Beobachte, wie Kunden ein Feature tatsächlich nutzen. Manchmal ignorieren sie es, manchmal nutzen sie es ganz anders als gedacht. So oder so fließt das Gelernte in die nächste Geschäftsentscheidung.
Qualität ist eher eine Sache der Menschen als der Technik
Tools und Tech-Stacks machen Teams nicht erfolgreich. Lisa verweist auf dreißig Jahre Forschung: Was zählt, sind die richtigen Leute, die ihre beste Arbeit machen können. Manchmal heißt das einfach, ihnen nicht im Weg zu stehen.
Tester stellen oft Fragen, auf die sonst niemand kommt. Schon diese eine Gewohnheit kann ein Team verändern. Wenn du dich am Sprintende beim Testen aufreibst, such dir eine Person, der es genauso geht, einen Entwickler, der dasselbe Problem sieht, und überlegt gemeinsam, wie ihr mehr Leute ins Boot holt.
Mach das Problem sichtbar und deinen Beitrag zur Qualität gleich mit. Wenn Entwickler verstehen, was los ist, wollen sie nicht, dass Tester am Ende jeder Iteration in zermürbender Arbeit festsitzen. Die Leute wollen gute Qualität, und sobald die Kosten sichtbar werden, lösen sie das Problem meist gemeinsam.
Lisa sieht Tester als Übersetzer zwischen zwei Sprachen.
“Als Testerin hatte ich oft das Gefühl, dass ich die Leute aus dem Business und die aus der Technik zusammenbringen und in ein Gespräch bringen kann, in dem sie sich wirklich verstehen.”
(Lisa Crispin)
Programmieren muss man dafür nicht. Tester brauchen technisches Verständnis, einen Blick für die Produktarchitektur und die Fähigkeit, mit IDEs und Monitoring-Tools umzugehen. Starke Programmierer hat das Team schon. Was oft fehlt, ist jemand, der mit dem Business in dessen Sprache redet und mit den Entwicklern in ihrer.
Interne Qualität entscheidet das Team, nicht der Product Owner
Interne Qualität ist das, was für die Leute zählt, die die Software bauen, im Unterschied zur externen Qualität, die für die Kunden zählt. Kent Beck hat diese Linie vor Jahren gezogen, und die agilen Testquadranten führen sie weiter.
Ein Product Owner sollte nicht vorgeben, wie die Software umgesetzt wird. Das Team wurde genau für diese Expertise eingestellt. Wie gehostet wird, wie containerisiert wird, ob testgetrieben entwickelt wird: Das entscheidet das Entwicklungsteam.
Interne Qualität rechnet sich, weil Teams Code viel öfter lesen als schreiben. Schwer verständlicher Code erzeugt ständige Plackerei. Schreib klaren Code, dokumentiere ihn intern gut, und ein neues Teammitglied findet sich zurecht und versteht, wie der Prozess läuft.
Installierbarkeit und Portierbarkeit gehören auch in dieses Gespräch. Wenn du Desktop-Software auslieferst, plane die Installierbarkeit für dich und deine Kunden von Anfang an ein. Wenn das Produkt später auf andere Plattformen soll, denk jetzt an Portierbarkeit, statt sie nachzurüsten.
Nacharbeit ist ein Symptom verpasster Gespräche
Die meiste Nacharbeit geht auf fehlendes gemeinsames Verständnis zurück. Das Team glaubt zu wissen, was eine Story meint, baut sie, testet sie, gibt sie dem Product Owner und hört: Das war nicht das, was ich wollte.
Die Vorbeugung ist billig, der Fehlschlag teuer. Ein bisschen mehr Zeit in der Planung spart später viel Zeit. Wenn ein Fehler in Produktion landet, rufen die Kunden beim Support an, und die Kosten steigen.
“Das war eigentlich kein Bug, das war eine fehlende Anforderung”: Diesen Satz hört Lisa oft, und er hält nicht. Eine fehlende Anforderung ist ein verpasstes Gespräch. Flussdiagramme, Zustandsdiagramme und Kontextdiagramme in der Planung decken solche Lücken auf, bevor daraus Nacharbeit wird.
Ein Testkonzept, das das Team wirklich nutzt
Eine Teststrategie, die in einem Dokument verschwindet, das niemand liest, bewirkt wenig. Lisa hat in den 1990er-Jahren in Wasserfallprojekten ausführliche Testkonzepte geschrieben und war stolz darauf. Angeschaut hat sie sich niemand, nicht einmal die anderen Tester.
Eine Mindmap auf einem gemeinsamen virtuellen Whiteboard funktioniert besser, weil sie zum Mitmachen einlädt. Alle können gleichzeitig auf dem Board sein, Ideen ergänzen und zusammen brainstormen. Die Testaktivitäten stehen auf der Map, werden abgehakt und bekommen Screenshots oder Screencasts als Beleg, wenn etwas kaputtgeht.
Bilder stoßen Denken an, das Fließtext nicht auslöst. Etwas auf dem Whiteboard bringt jemand anderen auf eine Idee, die dem Team echte Zeit spart. Visualisierungen helfen, quer zu denken und unbewusste Denkfehler zu umgehen.
Der Punkt ist, das Team an der Map mitbauen zu lassen, nicht, sie ihm nur zu zeigen. Wer selbst etwas zur Strategie beigetragen hat, bleibt dran und schaut eine Woche später eher wieder rein.
Ein Team, mit dem Lisa gearbeitet hat, wollte bei einer Story, die alle für einfach hielten, keine Mindmap machen. Sie haben es trotzdem versucht, denn eine einfache Story wäre ja schnell gemappt. Eine Stunde später hatten sie eine große Map, die klar mehr als eine einzige Story abdeckte. Oft zeigt erst der eine Versuch, was die Methode bringt.
Wo du anfängst, wenn das Team unter Druck steht
Fang in der Planung an. In einem Umfeld voller Deadlines und gestresster Menschen bringt eine kleine Änderung dort am meisten, denn fehlendes gemeinsames Verständnis verursacht so viele der späteren Probleme.
Das Modell nennt Beispiele für Testaktivitäten, aber das sind Anregungen, keine Gebote. Lisa sagt ausdrücklich, dass ganzheitliches Testen ein Denkwerkzeug ist und keine Vorschrift. Teams haben eigene Themen ergänzt, etwa intensive UX-Design-Arbeit, wenn die User Experience das Produkt prägt.
Pass das Modell an deinen Kontext an und ergänze, was du brauchst. Die Aktivitäten auf der rechten Seite der Schleife verdienen ebenfalls Aufmerksamkeit, denn dort hatten die meisten Tester bisher die wenigsten Gelegenheiten zu lernen. Es gibt viele Ressourcen, um diese Lücke zu schließen.
Häufig gestellte Fragen
Ist ganzheitliches Testen nur ein anderer Begriff für automatisierte Tests, die in einer CI-Pipeline laufen?
Nein. Der Standard-DevOps-Zyklus zeigt eine einzige Testphase, die die meisten Leute als automatisierte Prüfungen in der kontinuierlichen Integration verstehen, und genau diese enge Auslegung ist das Problem. Das ganzheitliche Testen, das von Lisa Crispin und Janet Gregory auf der Grundlage von Dan Ashbys Testmodell für einen kontinuierlichen Test aus dem Jahr 2016 entwickelt wurde, sieht Qualitätsmaßnahmen in jeder Stufe vor, von der Erkundung bis zur Produktionsüberwachung.
In welchem Teil des Entwicklungszyklus zahlt sich der Testaufwand am meisten aus?
Die Planung. Das Team legt fest, was bei einer Funktion für den Kunden, für die Softwarewartung und für das Unternehmen am wichtigsten ist, und wählt dann die daraus resultierenden Qualitätsmerkmale aus. Auch Risikoanalyse, Aufteilung und Priorisierung gehören hierher, da das menschliche Gehirn nicht mehr als etwa sechs Prioritäten gleichzeitig im Blick behalten kann.
Macht häufigeres Deployen Releases riskanter?
Ganz im Gegenteil. Kleine Batches senken das Risiko, denn wenn du eine winzige Änderung deployst und etwas kaputtgeht, weißt du genau, was kaputtgegangen ist. Während des Builds entscheidet das Team außerdem, wie der Code für Überwachung und Observability instrumentiert wird, was es einfacher macht, Muster und Anomalien zu erkennen, sobald die Änderungen die Kunden erreichen.
Warum halten sich so viele Tester von Überwachungs- und Produktionsdaten fern?
Das ist selten eine Frage der Bereitschaft. Die Leute sind überlastet und haben keine Zeit, darüber nachzudenken, was nach dem Release passiert; daher wird die Arbeit an den Betrieb übergeben, während das Team schon mit dem nächsten Punkt beginnt. Tester befürchten zudem, dass sie Log-Dateien nicht lesen oder Dashboards nicht nutzen können, obwohl viele dieser Tools unkompliziert sind und sich die vorhandenen Testkenntnisse direkt darauf übertragen lassen.
Müssen Tester Code schreiben, um in einem modernen Development-Team nützlich zu sein?
Nein. Die Anforderungen sind: technisches Verständnis, ein Überblick über die Produktarchitektur und die Fähigkeit, IDEs und Monitoring-Tools zu nutzen. Das Team verfügt in der Regel bereits über versierte Programmierer. Was fehlt, ist jemand, der mit dem Business in dessen Sprache und mit den Entwicklern in deren Sprache sprechen kann und so als Übersetzer zwischen den beiden fungiert.
Sollte der Product Owner entscheiden, ob ein Team testgetriebene Entwicklung praktiziert?
Nein. Die interne Qualität liegt in der Verantwortung des Entwicklungsteams, da es genau dafür eingestellt wurde: wie die Software gehostet wird, ob sie in Containern bereitgestellt wird und ob testgetriebene Entwicklung praktiziert wird. Kent Beck hat die Grenze gezogen zwischen interner Qualität, die für die Entwickler wichtig ist, und externer Qualität, die für die Kunden wichtig ist.
Warum kommt es selbst in Teams, die gründlich testen, immer wieder zu Nacharbeiten?
Die meisten Nacharbeiten lassen sich auf ein fehlendes gemeinsames Verständnis zurückführen. Das Team glaubt zu wissen, was eine Story bedeutet, entwickelt sie, testet sie, und der Product Owner sagt, das sei nicht das gewesen, was er wollte. Der Satz „Das war kein Bug, sondern eine fehlende Anforderung“ zieht nicht: Eine fehlende Anforderung ist ein versäumtes Gespräch, und Fluss-, Zustands- und Kontextdiagramme in der Planung decken diese Lücken auf.
Warum funktioniert eine Teststrategie auf einer Mindmap besser als ein schriftliches Testkonzept?
Weil sich die Leute damit beschäftigen. Aufwändige schriftliche Testkonzepte bleiben oft ungelesen, sogar von anderen Testern, während eine Mindmap auf einem gemeinsamen virtuellen Whiteboard jeden dazu einlädt, gleichzeitig Ideen beizusteuern. Visuelle Darstellungen regen das Querdenken an und umgehen unbewusste Vorurteile. Es geht darum, das Team in die Erstellung der Mindmap einzubeziehen, nicht darum, eine fertige Version zu präsentieren.
