Der fundamentale Testprozess nach ISTQB

Das Bewusstsein für Tests und ihre Notwendigkeit ist bei den meisten Entwicklern seit Jahren stetig gestiegen. Somit stellt sich schon lange nicht mehr die Frage, ob das Testen in einem größeren Umfang notwendig ist, sondern die eigentliche Frage ist mittlerweile: „Wie gehe ich beim Testen am besten vor?“

Es gibt sicherlich viele Vorgehensweisen und Theorien, die mehr oder weniger Gemeinsamkeiten aufweisen. In diesem Blogeintrag möchte ich speziell den Testprozess nach ISTQB und seine Phasen beschreiben.

Das ISTQB (International Software Testing Qualifications Board) wurde 2002 gegründet und hat sich eine standardisierte Ausbildung von Softwaretestern zum Ziel gesetzt. Konkret werden nach aktuellem Stand 12.000 Zertifizierungen pro Quartal durchgeführt. Insgesamt gibt es in über 100 Ländern schon mehr als 350.000 zertifizierte Tester [1].

Weltweit existieren nationale Vertretungen wie z.B. das German, Austrian und Swiss Testing Board, die die Zertifizierungen vornehmen.

 

Eingeleitet wird der Prozess von der Testplanung und -steuerung. Diese zwei Punkte beeinflussen alle folgenden Phasen. Das bedeutet vor allem, dass die späteren Phasen den in dieser Phase erarbeiteten Ergebnissen unterstehen und dies auch kontrolliert wird.

Die Testplanung umfasst die Definition der Teststrategie und des Umfangs, in welchem getestet werden soll. Um den Umfang korrekt zu bestimmen, muss überlegt werden, welche Softwarekomponenten zu testen sind und was die konkreten Testziele sind. Es ist empfehlenswert, hier auch einen Zeitplan aufzustellen und im Zuge dessen die benötigten Ressourcen zu bestimmen, um diese einplanen zu können. Des Weiteren gehören zur Testplanung das Aufstellen von Testmetriken und die Definition der Eingangs- und Ausgangskriterien.

Die Teststeuerung beschäftigt sich mit dem Tracking der Tests. Die Testergebnisse werden unter Berücksichtigung der Parameter aus der Testplanung gemessen und analysiert. Ebenfalls überwacht und dokumentiert werden der Testfortschritt, die Testabdeckung und die Ausgangskriterien. Wenn dabei Abweichungen vom Plan festgestellt werden, kann es eventuell auch notwendig sein, den Plan anzupassen. In der Praxis sollte die Teststeuerung daher Feedback an die Testplanung geben, damit in Zukunft die Szenarien berücksichtigt werden können, die zu der aufgetretenen Abweichung geführt haben.

In der zweiten Phase – der Testanalyse und dem Testentwurf – wird es etwas konkreter. Darin wird die Testbasis untersucht; das Ziel ist die Erstellung einer Testspezifikation. Um an wertvolle Informationen für den Test zu kommen, werden Interviews mit den Entwicklern, Anwendern etc. geführt. Des Weiteren wird die Testbarkeit der Testbasis und der Testobjekte bewertet und die Testbedingungen werden identifiziert. Auf Basis dieser Informationen kann der Entwurf von abstrakten Testfällen beginnen. Selbst eine Priorisierung dieser Testfälle kann bereits zu diesem Zeitpunkt durchgeführt werden. Auch das Thema Rückverfolgbarkeit sollte nicht vergessen werden, also der Verweis von Testbasis zu Testfällen in beide Richtungen. Doch nicht nur die Testfälle werden in dieser Phase spezifiziert, auch die Testumgebungen werden genauer beschrieben.

In der dritten Phase „Realisierung und Durchführung“ werden aus der Testspezifikation, die abstrakte Testfälle beinhaltet, konkrete Testfälle abgeleitet. Bei Bedarf können diese in Testsuiten zusammengefasst werden. Die Priorisierung aus der vorherigen Phase wird weitestgehend auf die Testfälle angewandt und ein Testausführungsplan erstellt. Damit die Tests im Anschluss auch durchgeführt werden können, müssen die konkreten Testdaten erstellt und bereitgestellt werden.

Der Verantwortliche in dieser Phase sollte ebenfalls ein Augenmerk auf die Testumgebungen und deren Infrastruktur haben, damit es beim Testbeginn nicht zu Verzögerungen kommt.

Wenn alle Testfälle erstellt worden sind, kann die Testdurchführung starten. Egal, ob der Test manuell oder automatisiert durchgeführt wird, in beiden Varianten werden die Soll- und Ist-Ergebnisse miteinander verglichen. Falls es zu Abweichungen kommt, müssen die Ursachen analysiert werden. Unabhängig davon, ob es Abweichungen gibt oder nicht, wird jeder Testfall ausführlich protokolliert, sodass der Test später reproduziert werden kann. Dabei sind gewisse Daten besonders wichtig für die Protokollierung des Tests und dürfen nicht fehlen:

  • Datum, Testperson, verwendete Eingabedaten und Soll-Daten;
  • ID/Version des Testobjekts, Testwerkzeugs und der Testmittel;
  • evtl. Fehlerursachen, Anmerkungen von Besonderheiten.

Diese Daten werden im Testprotokoll zusammengefasst. Kommt es zu Abweichungen (Fehlern), werden Fehlerberichte erstellt. Diese Berichte gehen zur Korrektur an die entsprechenden Verantwortlichen, die z.B. in der Entwicklungsabteilung sitzen. Wurden die Fehler behoben, so ist ein Nachtest erforderlich, welcher zur Sicherheit auch durch weitere Regressionstests ergänzt werden kann. Es steht auch frei, andere (bereits abgearbeitete) Testfälle nochmals durchzuführen.

Nach der Testdurchführung folgen die Bewertung der Ausgangskriterien und der Bericht. Hauptsächlich geht es dabei um die Beurteilung, ob die Ausgangskriterien erfüllt sind und ob weitere Tests durchgeführt werden sollen. Das Ergebnis dieser Phase ist der Testabschlussbericht, der an die entsprechenden Entscheidungsträger verteilt wird.

In der finalen Phase, dem Testabschluss, werden hauptsächlich abschließende Arbeiten durchgeführt. Es wird geprüft, ob alle Arbeitsergebnisse erstellt und geliefert wurden und ob offene Fehler und Abweichungen ggf. in Änderungsanforderungen überführt werden müssen. Ein ganz wichtiger Punkt, der oft wenig Beachtung findet, ist die Dokumentation und Archivierung von Testmitteln und Testumgebung. Diese könnten für Nachfolgeprojekte sowie die Wartung wichtig sein, aber auch eine spätere Reproduktion von Fehlern wird erleichtert. Abschließend können zusätzlich in einem Lessons-Learned-Meeting die gewonnenen Erkenntnisse erörtert und daraus Verbesserungen für Folgeprojekte erarbeitet werden.

Fazit

Die fünf Phasen decken alle wichtigen Aufgaben des Testens ab und geben klare Anweisungen, welche Reihenfolge beim Testen am sinnvollsten ist, welche Dokumente in den Phasen entstehen müssen und welche Zuständigkeiten es in den einzelnen Rollen gibt. Meiner Meinung nach deckt der ISTQB-Testprozess alle relevanten Themen ab und ist für mittlere bis große Projekte geeignet. Ob der recht umfangreiche Rahmen der Testplanung in kleinen Projekten vonnöten ist, sollte von Fall zu Fall entschieden werden. Abhängig vom Projekt könnte die sehr umfassende Planung in einigen Punkten sinnvoll gekürzt werden. Auch der Testabschluss kann bei kleinen Projekten etwas reduzierter ausfallen. Wurden z.B. in einem Projekt nur Kleinigkeiten verändert, stellt sich die Frage, ob wirklich alle Umgebungen archiviert werden müssen. Insgesamt lohnt es sich auf jeden Fall, den ISTQB-Testprozess zu betrachten und seinen Einsatz in Erwägung zu ziehen. Es sollte aber kritisch geprüft werden, ob alle Bereiche ausführlich eingehalten werden müssen. Der Testprozess ist nämlich nur ein Ratgeber und nicht die alleinige richtige Lösung, die für jedes Projekt gleichermaßen eins zu eins angewandt werden muss, um erfolgreich zu testen.

Quellen