Wenn ein Fehler in die Produktion gelangt, liegt die Ursache oft nicht darin, dass jemand vergessen hat, einen Test durchzuführen. Es liegt daran, dass eine Anforderung nie in Frage gestellt wurde, die Testdaten falsch waren oder sich niemand darauf einig war, was „erledigt“ bedeutet. Der Lebenszyklus von Softwaretests geht diese Probleme an, indem er dem Testen eine klare Struktur von der ersten Anforderung bis zum Abschlussbericht gibt.

In diesem Leitfaden werden die einzelnen Phasen erläutert. Anschließend wird durch alle Phasen ein veranschaulichendes Merkmal erläutert: eine Anmeldeseite, die ein Konto nach fünf fehlgeschlagenen Versuchen sperrt. Über die Anzahl der Phasen sind sich die Quellen nicht ganz einig. Sie werden Modelle mit sieben oder acht sehen, die jedoch meist die gleiche Arbeit unterschiedlich aufteilen. Wir verwenden die weit verbreitete Sechs-Phasen-Version.

Was ist der STLC?

Der STLC ist eine definierte Reihe von Testaktivitäten, die durchgeführt werden, um zu bestätigen, dass die Software ihre Anforderungen erfüllt. Jede Phase hat ein Ziel, Inputs und Outputs, sodass die Tests geplant und nachvollziehbar sind und nicht am Ende improvisiert werden.

Die Vorteile sind praktisch. Tester werden frühzeitig eingebunden, wenn die Behebung von Fehlern kostengünstiger ist. Der Aufwand geht bis zum höchsten Risiko. Und wenn ein Manager fragt: „Sind wir zur Veröffentlichung bereit?“, kann das Team mit Beweisen antworten.

Die sechs STLC-Phasen im Überblick

Eintrittskriterien sind die Bedingungen, die erfüllt sein müssen, bevor eine Phase beginnt. Abbruchkriterien sind die Bedingungen, die wahr sein müssen, bevor es endet. Sie hindern ein Team beispielsweise daran, Tests an einem defekten Build durchzuführen und so einen Tag zu verschwenden.

Phase 1: Anforderungsanalyse

Tester untersuchen Anforderungen, um herauszufinden, was getestet werden kann und was unklar ist. Dies ist oft der günstigste Weg, einen Fehler zu verhindern, da eine Frage weitaus weniger kostet als ein Produktions-Fix.

• Eintrag: Anforderungsdokumente oder User Stories sind verfügbar.
• Aktivitäten: funktionale und nichtfunktionale Bedürfnisse identifizieren, Fragen stellen, Risiken bewerten und entscheiden, was automatisiert werden könnte.
• Beenden: Offene Fragen werden beantwortet und die Anforderungs-Traceability-Matrix (RTM) wird gestartet.
• Liefergegenstände: eine Liste testbarer Anforderungen und das RTM.

Anmeldebeispiel. In der Geschichte heißt es: „Sperren Sie das Konto nach fünf fehlgeschlagenen Versuchen.“ Ein guter Tester fragt: Fünf in welchem ​​Zeitraum? Wie wird es freigeschaltet? Setzt eine erfolgreiche Anmeldung den Zähler zurück? Welche Meldung wird angezeigt? Jede Antwort wird zu etwas Überprüfbarem.

Phase 2: Testplanung

Das Team entscheidet über Umfang, Vorgehensweise, Personen, Tools, Zeitplan und Risiken. Normalerweise ist der Testleiter für diese Phase verantwortlich.

• Eintrag: analysierte Anforderungen und eine erste Risikobewertung.
• Aktivitäten: Definieren Sie den Umfang, schätzen Sie den Aufwand, wählen Sie Tools aus, weisen Sie Rollen zu und legen Sie Abschlusskriterien für spätere Phasen fest.
• Beenden: Der Testplan wird überprüft und genehmigt.
• Liefergegenstände: der Testplan und Aufwandsschätzungen.

Anmeldebeispiel. Im Geltungsbereich: Sperrregeln, Zurücksetzen und Fehlermeldungen im Web und auf Mobilgeräten. Außerhalb des Geltungsbereichs: Single Sign-On, von einem anderen Team verwaltet. Das größte Risiko besteht darin, echte Benutzer auszusperren, damit diese die meiste Aufmerksamkeit erhalten. Wenn Sie sich nicht sicher sind, wie sich ein Plan von einer Strategie unterscheidet, lesen Sie Testplan vs. Teststrategie.

Phase 3: Testfallentwicklung

Hier schreiben Tester die detaillierten Testfälle, Automatisierungsskripte und Testdaten.

• Eintrag: ein genehmigter Testplan und stabile Anforderungen.
• Aktivitäten: Testfälle schreiben und überprüfen, Daten vorbereiten, automatisierte Prüfungen skripten und das RTM aktualisieren.
• Beenden: Testfälle und Daten werden überprüft und sind bereit.
• Leistungen: Testfälle, Skripte und Testdaten.

Beachten Sie, dass TC-01 und TC-02 beide Seiten des Grenzwerts testen, der direkt aus der Randwertanalyse stammt. Weitere Informationen dazu, wie Sie diese gut schreiben, finden Sie unter Testfälle schreiben.

Phase 4: Einrichtung der Testumgebung

Für die Durchführung von Tests ist ein realistischer Ort erforderlich: die richtigen Server, Daten, Konten, Browser und Netzwerkzugriffe. Diese Phase läuft häufig parallel zu Phase 3 und kann von Entwicklern oder einem DevOps-Team durchgeführt werden.

• Eintrag: ein Testplan, eine Architekturübersicht und Umgebungsanforderungen.
• Aktivitäten: Hardware oder Container einrichten, Daten laden, Zugriff konfigurieren und den Build installieren.
• Beenden: Die Umgebung ist bereit und ein Rauchtest besteht.
• Ergebnisse: eine Arbeitsumgebung und ein Rauchtestergebnis.

Login-Beispiel. Staging erhält Testkonten in bekannten Zuständen, zusammen mit einem verkürzten Sperr-Timer, damit Tester nicht warten müssen. Ein kurzer Rauchtest bestätigt, dass die Anmeldung überhaupt geladen wird, bevor der vollständige Durchlauf beginnt. Container tragen dazu bei, Umgebungen konsistent zu halten, wie in unserem Docker Compose-Tutorial gezeigt.

Phase 5: Testdurchführung

Tester führen die geplanten Tests durch, vergleichen tatsächliche und erwartete Ergebnisse und melden Mängel. Behobene Fehler werden erneut getestet und verwandte Bereiche werden einem Regressionstest unterzogen.

• Eintrag: Testfälle sind fertig, die Umgebung funktioniert und ein Build wurde geliefert.
• Aktivitäten: Führen Sie Tests durch, zeichnen Sie Ergebnisse auf, protokollieren Sie Fehler, testen Sie Korrekturen erneut und aktualisieren Sie das RTM.
• Beenden: Geplante Tests werden durchgeführt und Mängel werden behoben oder offiziell akzeptiert.
• Leistungen: Testergebnisse und Fehlerberichte.

Login-Beispiel. TC-04 schlägt fehl: Bei zwei Browsern erreicht der Zähler nur vier. Der Tester protokolliert den Fehler mit klaren Schritten und Beweisen, wie unter So schreiben Sie einen Fehlerbericht beschrieben. Sobald das Problem behoben ist, wird TC-04 erneut ausgeführt und die entsprechenden Anmeldeprüfungen durchlaufen die Regressionscheckliste.

Phase 6: Testabschluss

Diese Phase wird häufig übersprungen, was schade ist, da sich ein Team dadurch verbessert. Das Team wertet den Zyklus aus, archiviert seine Arbeit und zeichnet die gewonnenen Erkenntnisse auf.

• Eintrag: Die Ausführung ist abgeschlossen und der Fehlerstatus ist bekannt.
• Aktivitäten: Abschlusskriterien prüfen, Fehlertrends analysieren, Testressourcen archivieren und eine Retrospektive durchführen.
• Beenden: Der Abschlussbericht ist unterzeichnet.
• Ergebnisse: der Abschlussbericht und die gewonnenen Erkenntnisse.

Login-Beispiel. Der Bericht zeigt, dass alle fünf Fälle nach einem Fix erfolgreich waren. Die Lehre daraus ist, dass die Parallelität erst spät getestet wurde, sodass dieses Szenario bei zukünftigen Funktionen mit Zählern während des Entwurfs hinzugefügt wird.

STLC vs. SDLC

Der SDLC (Software Development Life Cycle) umfasst den Aufbau des gesamten Produkts. Der STLC ist der Teil, der sich auf das Testen konzentriert und parallel dazu läuft.

Die Anforderungsanalyse im SDLC speist die Anforderungsanalyse im STLC ein, und die Entwicklung liefert Builds in die Testausführung. Das Testen muss nicht warten, bis die Codierung abgeschlossen ist. Früh anfangen ist das, was man unter „Linksverschiebung“ versteht.

STLC in Agile und DevOps

Die Phasen können wie ein langer, einseitiger Prozess klingen, müssen es aber nicht sein. Bei Agile werden dieselben Aktivitäten innerhalb jedes Sprints kleiner und wiederholen sich oft in Stunden statt in Wochen:

• Anforderungsanalyse erfolgt bei der Verfeinerung des Backlogs durch Fragen zur User Story.
• Planung erfolgt in der Sprintplanung, mit kurzen Notizen anstelle langer Dokumente.
• Testdesign erfolgt neben der Codierung, oft als Akzeptanzkriterien und automatisierte Tests.
• Umgebungseinrichtung wird durch Container und Infrastruktur als Code automatisiert.
• Ausführung läuft kontinuierlich in einer CI/CD-Pipeline.
• Abschluss wird Teil des Sprint-Reviews und der Retrospektive.

Behalten Sie das Nützliche und skalieren Sie den Papieraufwand entsprechend dem Risiko. Für ein kleines internes Tool ist möglicherweise eine kurze Checkliste erforderlich, während ein Bankensystem aus regulatorischen Gründen möglicherweise formelle Genehmigungen benötigt.

Häufige Fehler

• Tester zu spät einbeziehen. In Anforderungen gefundene Fehler sind weitaus günstiger als solche, die nach der Veröffentlichung gefunden werden.
• Vage Ausstiegskriterien. Ohne sie treffen Fristen die Entscheidung für Sie.
• Testen in einer schlechten Umgebung. Durch fehlerhafte Daten oder Konfigurationen verursachte Fehler verschwenden Zeit und untergraben das Vertrauen.
• Abschluss überspringen. Das Team wiederholt dann dieselben Fehler im nächsten Zyklus.
• Ich befolge es zu strikt. Der STLC ist ein Leitfaden. Schwere Dokumente bedeuten nicht automatisch eine bessere Qualität.

Fazit

Der Softwaretest-Lebenszyklus ist einfach eine disziplinierte Antwort auf sechs Fragen: Was testen wir, wie, mit welchen Fällen, wo, was ist passiert und was haben wir gelernt? Schauen Sie sich Ihren nächsten Beitrag an und prüfen Sie, welche dieser Fragen Ihr Team normalerweise überspringt. Wenn Sie diese eine Lücke schließen, werden Sie wahrscheinlich den größten Gewinn erzielen.

Häufige Fragen

Lerne weiter