Was ist eine Software-Teststrategie und was beinhaltet sie 

Die Software-Teststrategie beschreibt den gewählten Ansatz, um in den einzelnen Teststufen zu testen sowie die Art und Weise, wie innerhalb der Teststufen vorzugehen ist. In der Software-Teststrategie werden die Entscheidungen festgelegt, um die Projektziele zu erreichen. Die Testentwurfsverfahren werden festgelegt, die Ausgangs- und Endkriterien definiert. Wie die geplanten Tests ausgeführt werden und die anzuwendende Testarten gehören ebenfalls in die Konzeptionierung der Teststrategie.

Teststrategie erstellen

Eigentlich ist vorgesehen, dass die einmal definierte Teststrategie niemals aktualisiert werden sollte. Jedoch ist die Teststrategie ein lebendes Dokument und wird in den meisten Projekten normalerweise im Verlauf des Projektes den Szenarien angepasst. Dokumentiert wird die Teststrategie in einem Teststrategiedokument und wird vom Testmanager verfasst.  

Die errichtete Teststrategie richtet sich nicht nur an die Softwaretester und der Qualitätssicherung, sondern das gesamte Projektteam. Dazu gehören beispielsweise die Entwickler, der Systemarchitekt, der Release Manager und der Produkt Manager. Sie sind in die Software-Teststrategie eingebunden.  

Testziele 

Im ersten Schritt einer Teststrategie sollten die Testziele im Projekt definiert werden, um einen Grund und Zweck für den Entwurf und Ausführung von erfolgreichen Tests zu haben. Die Testziele werden vom Testmanager und Stakeholdern/Projektverantwortlichen definiert. Die Testziele können unterschiedlich sein, abhängig vom Projekt und dessen Anforderungen. Beispielhafte Testziele in der Teststrategie wären: 

• Die vollständige Testabdeckung der hoch priorisierten Anforderungen mit Testfällen
• Die vollständige Abbildung der wichtigsten Arbeitsszenarien
• Die erfolgreiche Durchführung der nach Signifikanz „hoch“ und „kritisch“ oder Prioritätsklasse A und B definierte Testfälle und Testszenarien
• Der Datenschutz und die damit verbunden Sicherheiten müssen gewährleistet sein. Echtdaten werden nicht angewendet und veröffentlicht
• Bugs und Fehler mit der Priorität „hoch“ und „kritisch“ werden zeitnah behoben
• Die Bestätigung, dass alle im Test erzeugten Dokumente vollständig und korrekt sind und zentral gespeichert werden

Testprozesse 

Wurden die Testziele definiert kann im nächsten Schritt identifiziert werden, welche Testprozesse für das Testobjekt angewendet werden. Deren Einflüsse sollten mit einbezogen werden. Das Ziel ist eine hohe Qualität und Zuverlässigkeit zu garantieren. Für ein zu testendes Objekt können folgende Teststufen angewendet werden:  

• Komponententest (Whitebox) für das Testen des Programmcodes, beispielsweise mit JUnit. Der Source-Code wird analysiert und auf Korrektheit geprüft. Durchgeführt werden diese Tests von den Entwicklern.
• Integrationstest zum Testen der Systemarchitektur, sei es Schnittstellen, Komponenten oder Systeme. Sie sind an dem Testobjekt angebunden. Dies könnte zum Beispiel das zu testende System und eine Datenbankschnittstelle sein. In ihr sind die angelegten Personendaten gespeichert und zu jeder Zeit abrufbar. Der Markt von Testwerkzeugen ist groß, sei es kostenpflichtige Tools mit umfangreichen Features als auch kostenfreie Testwerkzeuge mit eingeschränkten Funktionalitäten.
• Systemtest für die Analyse der Anforderungsspezifikation, zum Testen der Funktionalitäten des Testobjektes. Systemtests können manuelle Tests sein, wo die zu testende Applikation manuell („händisch“) getestet wird. Neben den manuellen Tests gibt es auch automatisierte Systemtests. Der Entwicklungsaufwand von automatisierten Systemtests kann aufwendig sein. Jedoch hat sie aber den großen Vorteil, dass viel mehr Funktionalitäten beim Testen abgedeckt werden können. Ebenso sind diese Tests jederzeit ausführbar und beschleunigen die Zeit in der Testausführung. Jedoch müssen diese Tests regelmäßig gewartet werden und erfordern bei der Entwicklung der Tests Erfahrung und Softwarekenntnisse. Ein Beispiel eines automatisierten Systemtest könnte sein, die komplette Weboberfläche der zu testenden Applikation zu testen. Sind alle Buttons anklickbar sowie mit IDs identifiziert und die gewünschten Funktionalitäten den Anforderungen entsprechen. Das Testframework „Selenium“ erfreut sich großer Beliebtheit und Zuverlässigkeit in der Testautomatisierung.
• Abnahmetest (E2E-Test) oder auch Akzeptanztest genannt. Diese Tests werden normalerweise von den Fachbereichen in Begleitung mit den Softwaretester der zu testenden Applikation durchgeführt. Geprüft wird, ob die entwickelten Funktionen den Bedürfnissen der Kunden und Stakeholdern entsprechen.
• Smoketest Nachdem eine Produktversion (Release) eingespielt wurde, werden Smoke-Tests ausgeführt. Hier werden die wichtigsten (Grund-)Funktionen der zu testenden Software auf Korrektheit geprüft.
• Usability-Tests können in der finalen Phase des Projektes durchgeführt werden, wo Testpersonen ohne Erfahrung mit der zu testenden Applikation im alltäglichen Gebrauch testen.
• Last- und Performancetest zur Messung der Verarbeitungsgeschwindigkeit. Unterschieden wird zwischen den Testarten „Performance“-Test, um für bestimmte Anwendungsfälle die Last und die Abhängigkeit von Last zu testen, sei es die Messung der Antwortzeit oder die Messung des Durchsatzes. Ebenso gibt es den Lasttest zur Prüfung des Systemverhaltens bei steigender Last. Beim Stresslasttest wird das Systemverhalten beobachtet, wie die Last über den Normalwert und erwartete Lastspitzen reagiert.

Wie viele Teststufen angewendet werden hängt vom Projekt und Budget ab. Es empfiehlt sich, dass die Art der Tests an die entwickelten Funktionen des Releases bzw. des Sprints angepasst wird. Das heißt, bei einer technischen Funktion, wie etwa dem Datenbanktest, wird ein funktionaler Integrationstest der verbundenen Schnittstellen durchgeführt. Bei Fertigstellung einer Funktion in der GUI ein Systemtest und ein Akzeptanztest der implementierten User-Story.

Wichtig ist zu beachten, wie sich die Testprozesse auf die Gesamtkosten (Testkosten) des Projektes auswirken. Der Mehraufwand und vor allem der finanzielle Beitrag bei nachträglicher Fehlerkorrektur kann den Budgetrahmen sprengen. Daher sollte in die Teststrategie mit einfließen, dass die Testprozesse im Laufe des Projektes ein Update benötigen und angepasst werden können.

Eingesetzte Werkzeuge 

Ist für das geplante Softwareprodukt bekannt welche Testprozesse im Projekt angewendet werden, muss als nächstes für die Teststrategie die geeigneten Werkzeuge, die für den Einsatz der einzelnen Testprozesse benötigt werden, ermittelt werden. Eine gezielte Auswahl und effiziente Anwendung von Testwerkzeugen sind notwendig. Es soll eine zuverlässige Systemlandschaft ermöglicht werden. Hier müssen auch die Kosten für die Beschaffung der Werkzeuge und dessen Lizenzumfänge errechnet werden. Viele Werkzeuge werden kostenfrei angeboten, sind in den meisten Fällen jedoch begrenzt einsetzbar, sei es im funktionellen Umfang oder maximale Anzahl an Nutzer. Daher erfordert die richtige Werkzeugauswahl einen hohen zeitlichen Aufwand, dass für die Teststrategie erforderlich ist.

Der Testmanager evaluiert, welche Werkzeuge für die einzelnen Teststufen den größten Benefit für das Projekt gibt. Neben den Kosten der Werkzeuge muss die Wartung der Werkzeuge mit einbezogen werden. Falls Aktualisierungen für die Testingtools erforderlich sind, werden diese zentral ausgeführt und führen oft zu Downtimes. Ebenso müssen die Mitarbeiter in die Werkzeuge eingearbeitet werden. Viele Werkzeuganbieter bieten Schulungen sowie technischen- und fachlichen Support für ihre Kunden an.

Für das Anforderungsmanagement, die Dokumentation von Testfällen, die Protokollierung von Testdurchführungen und das Fehlermanagement empfiehlt sich ein ALM-Tool (Application Lifecycle Management). Mit einem ALM-Tool wird die Entwicklung und Qualitätssicherung zentralisiert und der Fortschritt des Projektes ist in Echtzeit verfolgbar. Eine verbesserte Transparenz ist garantiert. Auf Basis der Anforderungen werden Testfälle angelegt und sind zurück verfolgbar. Testläufe können verwaltet, geplant und strukturiert ausgeführt werden. Die Dokumentation der Testergebnisse muss für die Teststrategie eingebunden werden. So können vergangene Testdurchführungen zurückverfolgt werden, wenn nach bereites ausgeführten Testausführungen recherchiert wird.

Für die Testautomatisierung von Systemtests gibt es viele- und unterschiedliche Testingtools, ob kostenfreie Applikationen wie Selenium, Cypress und SoapUI (Schnittstellentest) als auch kostenpflichtige Tools. Ein Beispiel ist Ranorex, dass neben der Objektidentifizierung auch einen eingebauten Recorder hat, der alle Interaktionen aufzeichnet und bereitstellt.

Für Last- und Performancetests gibt es kostenfreie Versionen sowie kostenpflichtige Applikationen.

Wie man erkennen kann, ist die Auswahl von Testwerkzeugen groß. Daher ist es für die Software-Strategie sehr wichtig, dass die Werkzeuge zielgerichtet und umfangreich evaluiert, getestet und ausgewählt werden.   

Testdokumentation 

In der Entwicklung der Teststrategie sollte auch die Dokumentation von Tests mit eingebunden werden. Die Dokumentation von Testfällen, Bugs, Testprozessen usw. ist in der Teststrategie ein wichtiges Element und sollte nicht vernachlässigt werden. Neben dem Testkonzept, dass die Niederschrift des Testplanungsprozesses für das Testobjekt ist, gibt es noch weitere Testdokumentationen und Berichtswesen, die in die Software-Teststrategie eingebunden werden sollten.  

• Testfallspezifikation: Die Testfallspezifikation ist die Summe der definierten konkreten Testfälle. Die einzelnen Testfälle sollten enthalten eine Priorität, einen prägnanten Namen, das Ziel des Testfalls, Vor- und Nachbedingungen, die konkreten Schritte und Akzeptanzkriterien. Hilfreich ist auch die Rückverfolgbarkeit zur entsprechenden Anforderung.
• Testablaufspezifikation: Der Ablauf der Tests wird in Form von Testszenarien gespeichert. Diese bringen Testfälle in eine Reihenfolge. Berücksichtigt können bspw. die Priorität der Testfälle in Reihenfolge. Regressionstests werden gerne in Testszenarien eingebaut.
• Testfortschrittsbericht: Veröffentlichung/Bereitstellung in regelmäßigen Abständen über den Testausführungsfortschritt, der die Anzahl der durchgeführten und geplanten Testfälle des Testprozesses enthält.
• Testabschlussbericht: Nach Ende der Testaktivitäten wird ein Testabschlussbericht erstellt. Er sollte enthalten eine Zusammenfassung der durchgeführten Tests, abgedeckten Anforderungen und aufgedeckten und blockierende Faktoren, eine Bewertung der Testergebnisse und verbleibende Fehler.
• Fehlerberichte: Fehlerberichte sind essenziell, wenn Abweichungen von einem vorausgesagten Ergebnis eines Testfalls auftreten. Diese sollten zur Zurückverfolgung dokumentiert und bereitgestellt werden.

Testentwurf 

Um keine Hindernisse und offene Fragen in der Testfallerstellung während der Testentwurfsphase zu haben, wird bereits in der Software-Teststrategie festgelegt, wie das Grundgerüst von Testfällen aufgebaut ist und wie sie entwickelt werden. Grundsätzlich sollen Testfälle für Testbedingungen in absteigender Priorität erstellt werden, beginnend mit den wichtigsten zuerst.

Bei abstrakten Testfällen sollen alle Pflichtfelder korrekt ausgefüllt werden und die Beschreibung sollte Vorbedingungen, Aktion und Akzeptanzkriterien enthalten.
Konkrete Testfälle haben darüber hinaus die konkreten Testschritte und Testdaten (z.B. „Öffnen Sie die Person mit dem Code 47110815“ statt „Öffnen Sie eine Person“). In der Testautomatisierung sollten die Testfälle eindeutig und klar beschrieben sowie universell einsetzbar sein. Heißt, dass im eigentlichen Testfall nur die Methoden mit den benötigten Testdaten aufgerufen werden.

Testkriterien 

In der Teststrategie müssen die Testkriterien definiert werden, die sog. Testeingangskriterien und Testausgangskriterien, auch bekannt als Testanfang und Testende. 

Testeingangskriterien 

Die Testeingangskriterien erlauben eine Beurteilung der Testreife des Testobjekts und spezifizieren die Anforderungen an Testinfrastruktur und Testmittel, die zu Beginn der Testdurchführung erfüllt sein müssen. Beispielhafte Testeingangskriterien können sein:

• Die Anforderungen an die Bestandteile der Softwarelösung wurden durch die Stakeholder / Auftraggeber freigegeben
• Die Testfälle wurden implementiert, überprüft und zum Testen freigegeben. Die fertig erstellten Testfälle sind mit dem Status „Fertig“ markiert
• Die Testfälle wurden in die Testszenarien der entsprechenden Teststufen hinzugefügt und nach Priorität und Abhängigkeit sortiert
• Die Testumgebung steht allen beteiligten Testern zur Verfügung
• Die Rechte für alle im Test geplanten technischen Benutzer sind auf der Testumgebung eingerichtet
• Die Fehler / Bugs aus der vergangenen Teststufen und Sprints sind behoben worden oder von der Projektleitung / Stakeholder akzeptiert

Testendekriterien 

Die Testendekriterien spezifizieren die von allen Beteiligten akzeptierten Bedingungen für den Abschluss einer Teststufe oder des gesamten Testprozesses. Testendekriterien können beispielsweise sein:

• Die für den aktuellen Sprint / Zyklus geplanten Testfälle und Features wurden erfolgreich getestet
• Alle Anforderungen wurden durch Testfälle abgedeckt
• Es gibt keinen offenen Fehler mit der Priorität „kritisch“ und „hoch“
• Alle festgestellten Fehler / Bugs wurden dokumentiert (inkl. Referenz zum Testfall und Anforderung)
• Alle entdecken Fehler während der Testphase wurden behoben oder mit den Stakeholdern besprochen
• Alle Funktionen sind nachgewiesener Weise erfolgreich in einer Testumgebung ausgeführt worden
• Die zu testende Applikation hat die Performancetests erfolgreich bestanden

Softwaretestmetriken und Messungen 

Der Fortschritt der Testaktivitäten wird über die Erstellung beziehungsweise die Durchführung der Testfälle sowie die Zahl der identifizierten Fehler über die verbleibende Projektzeit gemessen. Die Bewertung der Performanz der Systeme erfolgt durch mehrere im Test generierte Metriken.

Testdatenmanagement 

In der Software-Teststrategie müssen die anzuwendende Testdaten identifiziert und berücksichtigt werden. Geprüft wird, bevor die zu testende Applikation erstmals testbar ist, mit welcher Art von Testdaten getestet werden kann. Für die Teststrategie muss neben dem Datenschutz auch die (automatisierte) Bereitstellung von Testdaten ermittelt werden. Dazu gehört auch das Zurücksetzten von Daten nach ihrer Nutzung, das Löschen von Testdaten aus allen Systemen nach Ablauf der vereinbarten Nutzungsgültigkeit.

Produktive Testdaten werden in den wenigsten Fällen angewendet, da es sich um echte Daten aus dem produktiven Umfeld handelt, sei es bspw. personenbezogene Testdaten. Diese Daten stammen von echten Personen und sind rückverfolgbar.

Neben den produktiven Testdaten gibt es auch synthetische Testdaten. Synthetische Daten sind von ihrer Struktur den der produktiven Daten ähnlich, besitzen aber keine Eins-zu-Eins-Korrespondenz mit den Personen um ursprünglichen Datensatz, entsprechen aber ihrer Logik und Struktur. Diese Daten sind realitätsnah und keine Datensätze wie „Micky Mouse“.

Als weitere Option können die anonymen Testdaten angewendet werden. Wie der Begriff „Anonym“ es beschreibt, handelt es sich um Testdaten, die nicht zurückzuverfolgen sind. Die Testdaten werden durch ein Anonymisierungsskript generiert und dann bereitgestellt. Das Testen des Testobjektes mit den anonymen Testdaten darf Datenschutzrechtlich nicht in der „freien“ Testumgebung durchgeführt werden, sondern in einer weiteren Zugriffsbeschränkten Umgebung.   

Fehlermanagement 

In die Strategie gehört auch das Fehlermanagement. Grundsätzlich gilt: Wird ein Fehler entdeckt, sollte dieser dokumentiert werden. Wichtig dabei ist, dass eine neutrale, sachliche und professionelle Sprache angewendet wird. Es sollte nur die Sache, nicht aber die Beteiligung von Personen oder gar deren Anteil oder Verantwortung am Fehler diskutiert werden. Ohne festgelegten Softwarestrategie kann das Fehlerhandling nicht richtig umgesetzt werden. Die Folge ist, dass Fehler qualitativ ungenügend beschrieben werden oder sogar komplett weggelassen werden. Fehler werden nebenbei behoben. Die Auswirkung ist, dass früher oder später die Applikation mit schwerwiegenden Fehlern infiziert ist.

Im Softwarestrategie-Dokument wird auch definiert, wie ein Fehler behoben wird. Sei es beispielsweise. eine interne Prüfung, wo auf Korrektheit der Anpassung geprüft wird. Im Besten Fall von dem Tester, der den Fehler berichtet hat. Hoch priorisierte Fehler sollten Vorrang haben.

Unterbrechungskriterien 

Berücksichtig werden muss in der Teststrategie auch die Situation, dass das Testen aufgrund von auftretenden Ereignissen unterbrochen werden muss. Man spricht von Unterbrechungskriterien. Diese könnten beispielsweise sein:

• Testdaten nicht vorhanden
• Auf die Testumgebung kann nicht zugegriffen werden oder sie ist nicht betriebsbereit
• Schwerwiegende Fehler wurden noch nicht korrigiert. Diese Fehler verhindern ein sinnvolles Testen

Wiederaufnahmekriterien 

Werden die testverhindernden Fehler behoben können die Testläufe fortgesetzt werden. Ebenso gilt:

• Die Testumgebung ist wieder erreichbar
• Wartungsarbeiten werden außerhalb der Testaktivitäten durchgeführt
• Kapazitäten fürs Testen sind vorhanden

Risiken und deren Umgang

Im Teststrategiedokument gehört auch der Umgang mit Risiken. Risiken müssen in der Planung mitberücksichtigt werden, um gegen sie rechtzeitig vorzubeugen. Sowohl die Stakeholder als auch die Entwickler und Softwaretester/Testmanager entwickeln eine Sicht auf die mit der Inbetriebnahme der Applikation verbundene Risiken.

Es kann im Projekt vorkommen, dass die geplanten Tests der Fachabteilung nicht geplant durchgeführt werden können. Hier muss frühzeitig die Ressourcenlage geklärt werden, ebenso die Anpassung der Zeitplanung.

Im Projektalltag kann das Szenario auftreten, dass Stakeholder keine Kapazitäten haben, um das Projekt zu unterstützen. In der Strategie könnte definiert werden, dass Stakeholder kurzfristig interviewend werden und Unterstützungsmöglichkeiten erfragt werden. Ebenso kann dies im Fachbereich auftreten, dass sie unterbesetzt sind oder im Alltäglichen Geschäft involviert sind. Sie stehen der Qualitätssicherung nicht zur Verfügung. Hier sollte vorab geplant werden, wann sie Kapazitäten für die Testphase haben.

Technische Fehler in der zu testenden Applikation oder in den Schnittstellen (interne sowie externe) können auch auftreten und schwerwiegende Folgen haben. Sei es schwerwiegende Verarbeitungsprobleme, die unbeabsichtigte Löschung von Daten. Hier greift die Teststrategie ein, in dem im Falle wie Diese eine enge und offene Zusammenarbeit innerhalb des Teams oder den externen Dienstleistern vorgebeugt werden kann.

Teststrategie Beispiel 

Anhand des folgenden Beispiels soll die Erstellung der Software-Teststrategie anhand eines realen Szenarios dargestellt werden. Die Ausgangssituation ist:

Ein Versicherungsanbieter möchte für seine Kunden ein Portal bereitstellen, wo die Kunden ihr Vertragsstatus erfragen können. Auch können Sie ihre Verträge verwalten und drucken. Dieses Portal soll für jeden Kunden bereitgestellt werden mit einmaligem Nutzerdaten- und Passwort. Nach der Erstanmeldung wird ein Passwort vom Kunden erstellt, dass den vorgegebenen Sicherheitskriterien entsprechen muss. Danach kann der Kunde auf seine Verträge zugreifen und diese ausdrucken sowie exportieren im Dateiformat „PDF“ oder „Word“. Persönliche Daten wie Adresse, Telefonnummer usw. sollten jederzeit anpassbar sein.

Das Projekt ist neu und vom Unternehmen freigegen. Neben den Anforderungen für das Portal sind keine weiteren Dokumente vorhanden. Für die Qualitätssicherung wurde ein erfahrener Testmanager mit viel Projekterfahrung eingestellt, der den kompletten Qualitätszyklus erarbeiten und bereitstellen soll. Als Testwerkzeug wird ein ALM-Tool bereitgestellt für die Erstellung von Fehler, Anforderungen und manuellen Testfällen. Ebenso ermöglicht das ALM-Tool die Integration ein – und mehreren Testautomatisierungswerkzeugen. Mit dem Testautomatisierungswerkzeug soll die Weboberfläche automatisiert getestet werden, ebenso die Regressionstests.

Neben dem Testplan entwickelt der Testmanager die Teststrategie. Niedergeschrieben wird die Teststrategie im Teststrategiedokument und soll ein lebendes Dokument sein. Die Softwaretest-Strategie kann über die Projektdauer aktualisiert werden.

Zunächst wird festgelegt welche Testziele im Projekt erreicht werden sollen. Für das Projekt wichtige Testziele wären:

• Die vollständige Abdeckung der hoch priorisierten Anforderungen mit Testfällen
• Die erfolgreiche Durchführung der nach höchster Signifikanz definierten Testfälle
• Die Bestätigung, dass alle im Test erzeugten Dokumente vollständig und korrekt sind
• Kritische- und schwere Fehler sowie Bugs sind in der produktiven Umgebung nicht vorhanden. Falls doch, dann werden diese zeitnah behoben. Je nach Wichtigkeit, abgesprochen mit den Stakeholdern, wird ein Hotfix eingespielt.

Nun müssen für die Teststrategie die Testprozesse ermittelt und definiert werden, die für das Portal notwendig sind.

• Komponententest, dass die Entwickler durchführen. Sie prüfen ihr Programmcode auf Korrektheit. Der erfahrene Testautomatisierer bzw. ein Softwaretester mit technischer Erfahrung, kann die Entwickler beim Code-Review unterstützen.
• Integrationstest zum Testen der angebundenen Schnittstellen, weil die Endpunkte wie „Aufbewahrung der Dokumente und Verträge in einer anderen Schnittstelle gespeichert werden und man auf diese Schnittstelle zugreift. Ebenso Komponenten, die an dem Testobjekt angebunden sind.
• Systemtest zum Testen der Funktionalitäten des Testobjektes. Die Systemtests werden manuell und automatisiert umgesetzt. Zu Beginn des Projektes, wo die Applikation noch in der Entwicklung ist und noch nicht viele Funktionalitäten bereitgestellt werden, werden die Tests manuell durchgeführt. Sobald das Grundgerüst (Funktionalitäten, Buttons usw.) der Applikation steht, können die ersten automatisierten Testfälle entwickelt werden. Für umfangreiche Arbeitsprozesse, beispielsweise Kunden anlegen -> Kunde erstellt Antrag -> Kunde bearbeitet Antrag -> Kunde greift auf Dokumente zu werden automatisierte Regressionstests erstellt. Diese Tests werden täglich im Jenkins-Pipeline auf der TEST-Umgebung ausgeführt. Die Testberichte werden automatisiert abgelegt und sind zur jeder Zeit abrufbar.
• Abnahmetest (E2E-Test) oder auch Akzeptanztest genannt. Diese Tests werden i.d.R. von den Fachbereichen und Softwaretester der zu testenden Applikation durchgeführt.

Auf Last- und Performancetest wird zum Projektstart noch verzichtet. Sobald die Applikation bereit ist und eine interne Analyse durchgeführt wird, beispielsweise wie viele Kunde auf das Portal zugreifen möchten, werden Last-und-Performance-Tests durchgeführt.

Nun kann spezifiziert werden, welche Bedingungen für den Entwurf von Testfällen erforderlich sind. Diese wären

• Es müssen Vorbedingungen des Tests niedergeschrieben werden. Dies können vorhandene Verträge, Nutzergruppen oder Scans innerhalb der Testumgebungen sein. Wenn eine Vorbedingung zur Testdurchführung nicht erfüllt ist, kann der Test nicht gestartet werden.
• Jeder Testfall soll mit der Anforderung verknüpft sein, die durch ihn verifiziert wird und mit allen anderen Testfällen, zu denen Abhängigkeiten bestehen.
• Die Testfälle müssen generell die konkreten Testschritte und konkrete Testdaten und Testdokumente enthalten.

Bevor es zum Testen kommt, muss sichergestellt werden, dass alle sich aus dem Testfall ergebende Anforderungen an die Testumgebung, Testmittel und Testdaten vor der Testdurchführung bereitstehen. Die Testreife des Testobjektes muss erfüllt sein.

Wenn die Tests ausgeführt wurden, müssen auch Nachbedingungen erfüllt sein. Ein Beispiel wäre, dass die Tests komplett durchgelaufen sind. Im Projekt werden Testendekriterien definiert, die diese Bedingungen spezifizieren. Eines dieser Kriterien wäre, dass alle im Rahmen der Testphase vorgesehenen Testfälle und behobene Bugs erfolgreich getestet wurden.

Wenn beim Testen Fehler oder Bugs identifiziert werden, sollten diese zeitnah behoben werden, spätestens zum nächsten Release (je nach Schweregrad des Fehlers). Für die Teststrategie wird im Projekt ein Fehlermanagement aufgebaut, der den Workflow eines Fehlers beschreibt. Wichtig ist, dass keine Schuldzuweisungen diskutiert werden. Der Fehler soll reproduzierbar sein.

Ist der Fehler behoben, werden Fehlernachtestes durchgeführt und dieser dann für das nächste Release bereitgestellt. Hochpriorisierte Fehler haben hierbei Vorrang. Je nach Schweregrad und Wichtigkeit des Bugs wird ein Hotfix eingespielt.

Die Testergebnisse werden zentral aufbewahrt und für Prüfungen, beispielsweise von Behören, bereitgestellt. Für jedes Release wird an die Stakeholder ein Release-Bericht (Release-Version) veröffentlicht mit allen umgesetzten Aufgaben, User-Stories und behobenen Bugs für das letzte Release.

All diese Punkte und Szenarien sind im Teststrategie-Dokument niedergeschrieben. Dieses Dokument wurde von Stakeholder und zugehörigen Fachbereichen geprüft und schließlich freigegeben. Es wird im Projektverzeichnis aufbewahrt und kann von allen Projektmitgliedern eingesehen werden. Bei Verbesserungsvorschlägen oder Anpassungen wird der Testmanager kontaktiert. Der Testmanager überwacht die Teststrategie und greift ein, falls die Softwarestrategie in der Umsetzung abweicht.

Fazit 

In der Softwarequalitätssicherung ist es unausweichlich auf eine Software-Teststrategie zurückzugreifen. Es ist vergleichbar mit dem Teamleistungssport: Ohne Strategie kann kein Erfolg entstehen. Ganz im Gegenteil. Es führt zu Problemen bis Chaos. Mit einer Strategie und einem Konzept wird das Qualitätsniveau der zu testenden Applikation hochgehalten. Jedoch bedarf dies einer intensiven Vorbereitung und viel Geduld. Am Ende wird sich der hohe Aufwand jedoch bemerkbar machen. Sowohl für das Entwicklerteam und die Tester in der Qualitätssicherung als auch beim Anwender, der mit der anzuwendenden Applikation keinerlei Fehler und Hindernisse haben wird. In der Qualitätssicherung sorgt eine Strategie für Ordnung und Struktur. Wichtig ist aber auch, dass die erarbeitete Software-Teststrategie auch tatsächlich eingehalten wird. Es ist kein loses Dokument, es soll im Projekt gelebt werden.