Viele Projekte haben Testfälle, Testwerkzeuge und manchmal sogar ein ausführliches Testkonzept – aber keine gemeinsame Vorstellung davon, wie grundsätzlich getestet werden soll. Dann entscheidet jedes Team selbst, was „ausreichend getestet“ bedeutet. Eine Teststrategie schafft diesen gemeinsamen Rahmen. Dieser Artikel zeigt, was eine Teststrategie ist, was hineingehört und wie Sie sie in fünf Schritten entwickeln.
Eine Teststrategie beschreibt den grundsätzlichen Testansatz für eine Organisation, ein Programm oder ein Produkt: welche Qualitätsziele verfolgt werden, welche Teststufen und Testarten Standard sind, wie nach Risiken priorisiert wird, welcher Automatisierungsgrad angestrebt wird und wer wofür verantwortlich ist. Sie beantwortet also die Frage, wie getestet wird – nicht, welcher Testfall wann von wem ausgeführt wird.
Eine gute Teststrategie ist kurz genug, dass sie gelesen wird, und konkret genug, dass sich Entscheidungen daraus ableiten lassen. Ein Satz wie „Wir testen gründlich“ ist keine Strategie. „Jede Änderung an der Zahlungsabwicklung durchläuft automatisierte API-Tests und einen fachlichen Abnahmetest“ dagegen schon.
Die Begriffe werden oft vermischt. Hilfreich ist eine einfache Arbeitsteilung:
In kleineren Vorhaben verschmelzen Teststrategie und Testkonzept häufig zu einem Dokument. Das ist in Ordnung, solange klar bleibt, welche Aussagen grundsätzlich gelten und welche nur für dieses eine Projekt.
Am Anfang steht, wofür die Strategie gilt und welche Qualitätsmerkmale besonders wichtig sind. Für ein internes Verwaltungstool stehen vielleicht fachliche Korrektheit und Bedienbarkeit im Vordergrund, für ein Kundenportal zusätzlich Sicherheit, Verfügbarkeit und Antwortzeiten. Diese Gewichtung bestimmt alles Weitere.
Die Strategie legt fest, welche Teststufen vorgesehen sind – etwa Komponenten-, Integrations-, System- und Abnahmetest – und wer sie verantwortet. Dazu kommen die Testarten: funktionale Tests, nicht-funktionale Tests wie Lasttests oder Sicherheitstests, Regressionstests und Fehlernachtests. Wichtig ist auch, was bewusst nicht getestet wird.
Kein Team kann alles gleich gründlich testen. Die Strategie beschreibt deshalb, wie Risiken bewertet werden und wie sich das auf Testtiefe und Reihenfolge auswirkt. Das Vorgehen im Detail erklärt unser Artikel Risikobasiertes Testen.
Hier wird festgelegt, welche Tests automatisiert werden, auf welcher Ebene und mit welchem Ziel. Ein bewährtes Leitbild ist die Testpyramide: viele schnelle Tests auf Komponenten- und API-Ebene, weniger Tests über die Benutzeroberfläche. Die Strategie sollte auch klären, wie automatisierte Tests in die CI/CD-Pipeline eingebunden werden. Wie der Einstieg gelingt, beschreibt Testautomatisierung einführen.
Welche Umgebungen gibt es, wie nah sind sie an der Produktion, und woher kommen die Testdaten? Gerade bei personenbezogenen Daten muss die Strategie vorgeben, ob anonymisierte Produktionsdaten oder synthetische Daten verwendet werden.
Zum Rahmen gehören klare Zuständigkeiten (Entwicklung, Test, Fachbereich, Testmanagement), ein einheitlicher Umgang mit Fehlern inklusive Fehlerklassen sowie ein Reporting, das Entscheidungen unterstützt. Ebenfalls hierher gehören die eingesetzten Werkzeuge, etwa für Testmanagement und Fehlerverfolgung.
Der ISTQB-Lehrplan unterscheidet mehrere grundlegende Ansätze, die in der Praxis fast immer kombiniert werden:
Eine verbreitete Kombination ist ein analytischer, risikobasierter Kern, ergänzt um eine regressionsvermeidende Automatisierung und reaktive, explorative Tests für neue Funktionen.
Sprechen Sie mit Fachbereich, Entwicklung, Betrieb und gegebenenfalls Compliance: Welche Qualitätsmerkmale zählen am meisten, welche Vorgaben gibt es, wie oft wird ausgeliefert? Hilfreich ist auch ein ehrlicher Blick auf den Ist-Zustand – wo traten zuletzt Fehler in der Produktion auf, wo kostet der Test heute am meisten Zeit?
Leiten Sie aus den Qualitätszielen die wichtigsten Produktrisiken ab. Daraus ergibt sich, welche Bereiche und Qualitätsmerkmale besonders gründlich geprüft werden müssen.
Legen Sie fest, welche Teststufe welche Risiken abdeckt, welche Testarten Pflicht sind und was automatisiert wird. Achten Sie darauf, dass dieselben Prüfungen nicht unnötig auf mehreren Stufen doppelt laufen.
Beschreiben Sie Testumgebungen, Testdaten, Werkzeuge, Rollen, Fehlerklassen und Reporting. Formulieren Sie außerdem übergreifende Qualitäts-Gates, etwa: Ein Release geht nur live, wenn alle Tests zu hohen Risiken bestanden sind und keine kritischen Fehler offen sind.
Eine Teststrategie wirkt nur, wenn sie von den Beteiligten mitgetragen wird. Stimmen Sie den Entwurf ab, legen Sie ihn gut auffindbar ab und planen Sie eine regelmäßige Überprüfung, zum Beispiel einmal im Jahr oder bei größeren Änderungen an Architektur, Team oder Release-Takt.
Für eine Webanwendung mit regelmäßigen Releases kann eine Teststrategie auf wenigen Seiten auskommen:
Das konkrete Testkonzept für ein Release verweist dann auf diese Strategie und beschreibt nur noch, was für dieses Release abweicht oder dazukommt.
Auch in Scrum braucht es eine Teststrategie – sie sieht nur anders aus. Statt eines umfangreichen Dokuments genügt oft eine kurze, gemeinsam gepflegte Seite im Wiki. Wichtige Teile der Strategie landen direkt in den Arbeitsvereinbarungen des Teams: in der Definition of Done, in Standards für Akzeptanzkriterien und in der Pipeline, die bei jeder Änderung die automatisierten Tests ausführt. Arbeiten mehrere Teams am selben Produkt, sorgt eine gemeinsame Strategie dafür, dass „fertig“ überall dasselbe bedeutet. Wie Testen im Sprint konkret funktioniert, zeigt unser Artikel Agiles Testen in Scrum-Teams.
Eine Teststrategie legt fest, wie in Ihrem Softwareprojekt grundsätzlich getestet wird: mit welchen Qualitätszielen, Teststufen, Testarten, Prioritäten und welchem Automatisierungsgrad. Sie ist kein Selbstzweck, sondern die gemeinsame Grundlage, auf der Testkonzepte, Testfälle und Freigabeentscheidungen aufbauen. Kurz, konkret und regelmäßig überprüft, sorgt sie dafür, dass die Testzeit dort ankommt, wo sie den größten Nutzen bringt.
In der Regel das Testmanagement oder eine erfahrene Testleitung. Die Inhalte entstehen aber gemeinsam mit Entwicklung, Fachbereich, Betrieb und Projektleitung, denn nur so werden Qualitätsziele und Risiken realistisch eingeschätzt und die Vorgaben später auch eingehalten.
Eine feste Regel gibt es nicht. Bewährt hat sich eine Überprüfung etwa einmal im Jahr sowie immer dann, wenn sich Architektur, Teamstruktur, Release-Takt oder regulatorische Vorgaben deutlich ändern.
Nicht unbedingt. Gibt es eine übergreifende Teststrategie im Unternehmen, reicht für ein einzelnes Projekt oft ein Testkonzept, das darauf verweist und die Abweichungen beschreibt. Fehlt eine solche Strategie, sollten ihre Kernaussagen im Testkonzept des Projekts stehen.
30 Minuten Erstgespräch — kostenlos und unverbindlich. Wir schauen gemeinsam auf Ihr Projekt und zeigen, wie eine schlanke Teststrategie Ihre Qualitätssicherung wirksamer macht.
Jetzt Erstgespräch vereinbarenMehr zu unserer Leistung: Software-Qualitätssicherung in Hamburg →
Passend dazu: IT-Projektmanagement in Hamburg →