Was sind die Phasen des Softwaretestens?

Geben Sie „was sind die Phasen des Softwaretestens“ in eine Suchleiste ein, und Sie erhalten zwei unterschiedliche Antworten. Eine Seite listet vier Ebenen auf, von Unit bis Abnahme. Eine andere nennt einen Prozess mit fünf bis sieben Schritten, der von der Planung bis zum Abschluss läuft. Beide haben recht, doch sie widersprechen sich, weil sie unterschiedliche Fragen beantworten.

Fragt man jedoch einen Tester im eigenen Team, erhält man eine dritte Antwort, die mit den anderen beiden gar nichts zu tun hat, aber ebenfalls richtig ist. Diese dritte Antwort taucht in Suchergebnissen nie auf, weshalb sie viele überrascht. Sie hat nichts mit dem Produkt als Ganzem zu tun, sondern ausschließlich mit einem einzelnen Bug. Jeder Bug durchläuft eine kurze Reihe von Zuständen. Jemand bestätigt, dass er real ist, ein Entwickler behebt ihn, und ein Tester überprüft das Ergebnis. Diese Abfolge ist es, was Menschen meinen, wenn sie sagen, ein Bug sei in die nächste Phase übergegangen.

Dieser Leitfaden trennt die drei Bedeutungen, damit Sie sie unterscheiden und herausfinden können, welche Sie gerade brauchen. Die meisten Unternehmen sind nur für eine oder zwei davon personell aufgestellt, weshalb die dritte häufig durchs Raster fällt. Ein dediziertes QA-Team deckt alle drei ab.

Was sind die Phasen des Softwaretestens? Drei Dinge, die damit gemeint sein können

Die Verwirrung ist real, denn eine einzige Formulierung deckt drei unterschiedliche Konzepte ab, und eine Quelle, die eines davon erklärt, erwähnt die anderen selten.

Betrachten Sie die mittlere Spalte: Ebenen betreffen den Umfang, der Lebenszyklus betrifft den Prozess, und der Bug-Lebenszyklus verfolgt einen einzelnen Fehler von der Meldung bis zum Abschluss. An einem beliebigen Nachmittag kann sich Ihr Team auf Systemebene befinden, mitten im Lebenszyklus stecken und vierzig Fehler in vier unterschiedlichen Zuständen halten. Keine dieser Tatsachen widerspricht den anderen.

Die Anzahl der Phasen hängt davon ab, wen man fragt, und wer eine einzige richtige Antwort verspricht, vereinfacht. Diese Abweichung ist nicht zufällig:

• Ebenen sind fest auf vier festgelegt. Niemand argumentiert ernsthaft für eine andere Anzahl.
• Der Lebenszyklus ist nicht festgelegt. Manche Autoren trennen Planung von Analyse, andere fassen sie zusammen, weshalb fünf, sechs und sieben alle vorkommen.
• Bug-Zustände folgen einer Konvention, keinem Standard. Sieben davon sind nahezu universell, und Ihr Tracker entscheidet, ob es weitere gibt.

Die vier Testebenen und was jede davon aufdeckt

Ebenen beantworten die Umfangsfrage: wie viel vom Produkt man jeweils gleichzeitig testet. Sie reichen vom kleinsten Baustein bis zum fertigen Produkt mit einer echten Person, die es benutzt.

• Unit-Testing: Eine einzelne Funktion, Methode oder Klasse, für sich allein geprüft, während alles Umgebende simuliert wird. Entwickler schreiben diese Tests parallel zum Code, und sie laufen in Sekunden durch.
• Integrationstesting: Zwei oder mehr Bausteine werden gemeinsam geprüft, was zeigt, ob sie sich über die zwischen ihnen ausgetauschten Daten einig sind. Genau hier stellt sich heraus, dass ein funktionierender Login und eine funktionierende Profilseite sich nicht darüber einig sind, wie eine Nutzer-ID aussehen soll.
• Systemtesting: Das gesamte zusammengesetzte Produkt wird durchgängig gegen das geprüft, was es leisten sollte. Unabhängige Tester führen dies durch, denn inzwischen möchte man jemanden, der es nicht selbst gebaut hat.
• Abnahmetesting: Die Personen, die das Produkt angefordert haben, entscheiden, ob sie es auch bekommen haben. Dies ist das letzte Tor vor der Freigabe, und es beantwortet eine Frage, die keine frühere Ebene stellt. Alpha- und Beta-Testing finden hier beide ihren Platz, ebenso wie die formale Freigabe.

Liest man diese letzte Spalte von oben nach unten, hat man das Argument dafür, alle vier Ebenen zu durchlaufen. Jede Ebene ist blind für etwas, das die nächste erfasst, und die Kosten einer Korrektur steigen mit jedem Schritt. Ein Benennungsfehler, der von einem Unit-Test erkannt wird, kostet einen Entwickler zwei Minuten. Derselbe Fehler, in der Abnahme entdeckt, kostet ein ganzes Release.

Auf Mobilgeräten ändert sich daran nichts. Auch dort gelten die vier Ebenen, und zu wissen, in welcher App-Testphase man sich befindet, sagt Ihnen, wer die Prüfungen durchführen sollte und wie teuer ein übersehener Fehler wird.

Beispiel: Passwort-Zurücksetzen durch vier Testebenen

Nehmen wir zum Beispiel ein Passwort-Zurücksetzen, da fast jedes Produkt eines hat und jeder es schon im echten Leben benutzt hat.

Unit-Testing betrachtet die kleinen Bausteine einzeln. Erzeugt der Token-Generator etwas, das niemand erraten kann? Liefert die Ablaufberechnung den richtigen Zeitstempel? Ein Entwickler schreibt diese Tests während der Entwicklung des Features, und sie laufen in Millisekunden durch.

Integrationstesting prüft, ob diese Bausteine miteinander übereinstimmen. Die Anfrage muss den E-Mail-Dienst erreichen, der Token muss die Hin- und Rückreise überstehen, und die Datenbank muss vermerken, dass ein Zurücksetzen aussteht. Die meisten Bugs beim Passwort-Zurücksetzen entstehen genau an diesen Übergabepunkten, weil jeder Baustein für sich allein einwandfrei funktioniert.

Systemtesting durchläuft die gesamte Reise so, wie es eine Person tun würde. Ein Zurücksetzen anfordern, die E-Mail öffnen, auf den Link klicken, ein neues Passwort wählen, sich anmelden. Ein Tester geht außerdem Pfade durch, für die niemand geplant hat: den Link zweimal anklicken, ihn ablaufen lassen, dreimal hintereinander um ein Zurücksetzen bitten.

Abnahmetesting stellt eine ganz andere Frage. Entspricht dies dem, was das Unternehmen vereinbart hat? Wenn Ihr Sicherheitsteam gesagt hat, dass Reset-Links nach einer Stunde ablaufen, der Build aber mit 24 Stunden ausgeliefert wird, bestehen alle drei vorherigen Ebenen den Test, und das Feature ist trotzdem falsch.

Die Abnahme ist die einzige Ebene, die das erkennt, weshalb sich alle vier Ebenen ihren Platz verdienen. Drei können grünes Licht geben, während das Produkt weiterhin genau den einen Test nicht besteht, der widerspiegelt, was tatsächlich angefordert wurde.

Warum Regression, Performance und Sicherheit Testarten sind, keine Phasen

Hier ist die Unterscheidung, die die meiste Verwirrung erspart, sobald man sie verstanden hat. Eine Phase ist etwas, das man der Reihe nach durchläuft, während eine Testart Arbeit ist, die man an mehr als einer Stelle davon durchführen kann. Folgendes sind Testarten:

• Regressionstesting ist überhaupt nicht an eine Ebene gebunden, da seine Aufgabe darin besteht zu bestätigen, dass das, was letzte Woche funktionierte, auch heute noch funktioniert. Führen Sie es über alles hinweg durch, was eine Änderung erreichen könnte, nicht nur über den geänderten Teil.
• Performance-Testing kann sich auf einen einzelnen Dienst für sich allein richten oder auf das gesamte System unter echter Last. Setzen Sie es überall dort ein, wo eine langsame Antwort Sie tatsächlich etwas kosten würde.
• Sicherheitstesting kann die Berechtigungen eines einzelnen Endpunkts untersuchen oder das fertige Produkt so, wie es ein Angreifer täte. Behandeln Sie es als fortlaufend, denn eine einzige Zugriffsänderung kann eine Lücke öffnen, die kein funktionaler Test bemerkt.

Fragt also jemand, zu welcher Phase Performance-Testing gehört, ist die ehrliche Antwort, dass die Frage so nicht ganz funktioniert. Es gehört zu welcher Ebene auch immer Sie gerade beunruhigt. Deshalb nennt ein nützlicher Testplan sowohl die Ebene als auch die Art.

Software-Testlebenszyklus: Kurzüberblick

Die andere gängige Antwort auf die Frage, was die Phasen des Softwaretestens sind, ist ein Prozess, keine Ansammlung von Ebenen. Dieser Prozess ist der Software-Testlebenszyklus, meist kurz STLC genannt. Er beschreibt, wie ein Testvorhaben organisiert wird, statt was getestet wird: Anforderungen prüfen, planen, Testfälle erstellen, eine Umgebung vorbereiten, die Tests durchführen und dann mit einem Bericht abschließen.

Diese Abfolge verdient mehr Raum, als dieser Artikel ihr geben kann, und wir haben dazu einen eigenen Leitfaden. Unser Leitfaden zum Software-Testlebenszyklus behandelt jede Phase samt ihrer Eintritts- und Austrittskriterien.

Eine Klarstellung gehört hierhin, weil sie für echte Diskussionen sorgt. Diese erste Phase setzt voraus, dass Anforderungen vorhanden sind, mit denen ein Tester arbeiten kann, was ein eigenständiges Problem mit einer eigenen Antwort in unserem Leitfaden zu Softwaretest-Anforderungen ist. Der Lebenszyklus sagt Ihnen, wann Anforderungen geprüft werden. Er sagt Ihnen nicht, wie eine gute Anforderung aussieht.

Der Bug-Lebenszyklus: Von „Neu“ bis „Geschlossen“ in sieben Zuständen

Testing findet Bugs, unabhängig davon, auf welcher Ebene oder mit welcher Art es geschieht, und jeder davon durchläuft dann eine eigene Abfolge. Das ist das dritte Konzept, das als „Phasen“ bezeichnet wird, und es ist wahrscheinlich das, was Ihre Entwickler damit meinen.

1. Neu vom Melder: der Bug ist erfasst, und noch niemand hat bestätigt, dass er real ist.
2. Einer Person zugewiesen: die Triage hat ihn angenommen und einer namentlich benannten Person übergeben.
3. In Bearbeitung bei einem Entwickler: jemand arbeitet an der Behebung.
4. Aus Sicht des Entwicklers behoben: eine Behauptung, keine endgültige Feststellung.
5. Erneuter Test durch einen Tester: jemand überprüft diese Behauptung anhand der ursprünglichen Reproduktionsschritte.
6. Durch den erneuten Test verifiziert: das Problem ist tatsächlich verschwunden.
7. Geschlossen und dokumentiert: die Arbeit ist abgeschlossen.

Zwei weitere Zustände liegen außerhalb dieser sieben. Wiedereröffnet bedeutet, dass eine verifizierte Korrektur erneut versagt hat, was in der Regel auf einen fehlenden Regressionstest hinweist und nicht auf einen nachlässigen Entwickler. Zurückgestellt bedeutet, das Team hat anerkannt, dass der Bug real ist, sich aber entschieden, ihn noch nicht zu beheben, was eine legitime Entscheidung ist, solange jemand aufgeschrieben hat, warum.

Wo ein Bug gefunden wurde, macht für die Zustände, die er durchläuft, keinen Unterschied. Einer, der von einem Unit-Test erfasst wird, und einer, der bei der Abnahme erfasst wird, folgen denselben sieben Zuständen. Was sich ändert, ist, wie viel jeder Schritt kostet, bis man dorthin gelangt.

Wie QAwerk diese Phasen in der Praxis umsetzt

Wir behandeln Testing nicht als eine einzelne Phase kurz vor dem Ende. Unsere Ingenieure steigen an dem Punkt ein, an dem sich ein Projekt gerade befindet, und arbeiten innerhalb des Sprints, sodass die vier Ebenen fortlaufend durchlaufen werden, statt sich vor einem Release aufzustauen. Für die wochenweisen Details siehe unseren Leitfaden zu agilem Testing.

In der Praxis bedeutet das, dass wir ein Produkt genau dort aufgreifen, wo es steht. Manche Teams holen uns hinzu, bevor auch nur eine Zeile Code existiert, während noch über die Anforderungen diskutiert wird. Andere übergeben uns einen fertigen Build und ein Launch-Datum. Beides funktioniert, wobei die erste Variante weniger kostet, aus demselben Grund, aus dem ein Unit-Test günstiger ist als ein Abnahme-Fehlschlag.

Qualität hängt davon ab, wer sie liefert. Wir haben über 30 erfahrene QA-Ingenieure mit durchschnittlich 9 Jahren Erfahrung, und wir haben seit 2015 mehr als 50.000 kritische Bugs in über 300 Projekten identifiziert. Diese Erfahrung zählt am meisten genau an den Stellen, an denen Ebenen blind werden: zu wissen, welche Integration wahrscheinlich nicht übereinstimmen wird, und welches Abnahmeszenario niemand aufzuschreiben bedacht hat.

Um herauszufinden, wo Ihr Produkt tatsächlich im Verhältnis zu den vier Ebenen steht, sprechen Sie mit unserem QA-Team. Wir bilden Ihre aktuelle Abdeckung ab, bevor Sie sich auf irgendetwas festlegen.

FAQ