Testmanagement im Softwaretest

Echtes Testmanagement ist im Softwaretest noch immer kein Standard. Studien belegen, dass fast die Hälfte aller Softwarefehler erst im Produktivbetrieb gefunden werden [3]. Diese Tatsache ist nicht nur kostspielig, sondern wirkt sich auch negativ auf die Kundenbindung und mögliche Folgeaufträge aus. Der Grund für schlechte Softwarequalität ist dabei oft auf mangelndes Testmanagement, Softwaretest-Knowhow und QA-Budget zurückzuführen [2]. Viele Unternehmen haben es noch immer nicht geschafft, einen durchgehenden Testprozess in ihrem Unternehmen zu etablieren. Dies führt dazu, dass es zu Projektende unter Termindruck und der Angst vor möglichen Pönalen zur Streichung von geplanten Tests kommt. Dass dieses Vorgehen der Softwarequalität natürlich alles andere als zuträglich ist, bedarf keiner weiteren Ausführung. Dabei kosten Fehler, die erst nach dem Go-Live gefunden werden, um fünfmal so viel wie Fehler, die während der Entwicklung entdeckt werden [2]. Durch schlechtes oder nicht vorhandenes Testmanagement wird somit genau an der falschen Stelle gespart.

Probleme unzureichender Softwaretests

Der Mangel an methodischem Testmanagement in Unternehmen führt dazu, dass Softwaretests unsystematisch umgesetzt werden. So werden günstige Unittests häufig nicht oder nur spärlich eingesetzt und aufgrund von zeitlichen Beschränkungen im Laufe des Projekts nicht mehr durchgängig gewartet. Ähnliches gilt für die Testautomatisierung, die weder durchgehend geplant noch konstant umgesetzt wird. Dies führt dazu, dass zu Projektende die Basisfunktionalität der Software anhand einiger weniger Use Cases überprüft wird. Treten bei dieser Überprüfung Fehler auf, werden diese dann vielmals nicht standardisiert und lückenhaft an das Entwicklungsteam weitergegeben. Dadurch nehmen die Fehleranalyse und die Fehlerkorrektur mehr Zeit in Anspruch, als eigentlich notwendig wäre. Aufgrund von Zeitmangel wird anschließend auf die erforderlichen Regressionstests verzichtet, was wiederum dazu führt, dass die Wahrscheinlichkeit steigt, neue Fehlern in älteren und früher bereits getesteten Modulen zu übersehen. Alles in allem wird durch die spontane Organisation von einzelnen Testmaßnahmen, die losgelöst voneinander stattfinden, sehr viel Zeit verbraucht, die jedoch nur wenig zur Steigerung der Softwarequalität beiträgt. Ein gut durchdachtes Testmanagement kann hier Abhilfe schaffen.

Was ist Testmanagement?

Unter Testmanagement versteht man die Koordination aller Tätigkeiten im gesamten Testprozess. Der Testprozess besteht dabei aus vielen einzelnen Aktivitäten, die wie folgt gruppiert werden können. (Nach ISTQB® [1]):

• Testplanung und Teststeuerung
• Testanalyse und Testentwurf
• Testrealisierung und Testdurchführung
• Bewertung von Endekriterien und Bericht
• Abschluss der Testaktivitäten

Diese Aufgaben werden vom Testmanager von Anfang bis Projektende begleitet. Die Punkte "Testplanung und Teststeuerung" wie auch "Bewertung von Endekriterien und Bericht" obliegen in konventionellen (nicht-agilen) Projekten in der Regel dem Testmanager auch operativ.

Was umfasst Testmanagement im Einzelnen?

Egal ob agile oder konventionelle Softwareentwicklung, über grundlegende Softwaretest-relevante Dinge muss man sich Gedanken machen. Folgende Punkte müssen im Rahmen des Testmanagements definiert oder geplant werden, bzw. werden vom Testmanager im Zuge der Ausarbeitung von anderen Projektmitarbeitern stark mitbetreut

• Anforderungs-Definition an ein Testmanagement-Tool. Tool-Auswahl einer Testmanagement-Software/ALM-Software (Testfallverwaltung, Requirements, etc.). Bzw. Entscheidung, ob überhaupt ein Tool genutzt werden soll.
  • Testfall-Management (Wo und wie? Ggf. mit Requirement-Verknüpfung?)
  • Defect-Management (Wo und wie?)

• Viele Definitionen, die im Rahmen der Softwareentwicklung und des Softwaretests gebraucht werden und wo alle beteiligten eine gemeinsame Sprache sprechen sollten, müssen festgelegt werden:
  • Fehlerklassen, Definition und Bewertung der Fehlerschwere
  • Begriffe im Projektalltag der Tester, je nach Unternehmen und Projekt unterschiedlich.

• Testende Kriterien / Abnahmekriterien / Akzeptanzkriterien
  • Tipp: Denken Sie neben den Funktionalen Kriterien auch an die nicht-funktionalen Kriterien (Performance, Wartbarkeit, Ausfallsicherheit, Usability).

• Testumfang / Testabdeckung / Speziell auch Umfang der Regressionstests
  • Tipp: Zumindest eine grobe Planung muss her, was und welcher grob definierte Umfang getestet werden soll. Eine Testabdeckung zu definieren, ist besonders in großen Konzern-Projekten sehr schwierig.
  • Tipp: Nicht vergessen, es kann auch zu viel getestet werden. Wenn zu viel Zeit beim Testen „verloren“ geht, ohne wichtige Fehler zu finden, ist der Testumfang zu hoch.

• Testinhalt / Testdefinition, Umfang der Testobjekte und Qualitätskriterien
  • Tipp: Nicht nur Funktionale Tests beachten: Technische Tests (nicht-funktionale Tests), Logging-Verhalten, Last- und Performancetest, Ressourcen-Verbrauch, Unittests (Komponententests), Ausfalltests, Tests auf Schnittstellen oder GUI-Ebene, Einsatz von Crowdtesting, Usability-Test, letzteres gerade im Mobile-App-Bereich immer gefragter.
  • Testmanager unterstützt bei Testanalyse (Was ist zu testen?) und Testentwurf (Wie ist es zu testen?)

• Prioritäten im Test, Risikobewertung, ggf. strickte risikoorientierte Testvorgehen auswählen
  • Tipp: Das Testen ist (bzw. sollte immer) auf eine Art risikobasiert sein. Denn am Ende ist wichtig, dass die Geschäfts-kritischen Dinge laufen. Diese müssen auch gut getestet sein.

• Testarten und Abgrenzung der Teststufen (auch Black-Box-Tests vs. White-Box-Test)
  • Tipp: Vor allem auch wichtig, welche Tests manuell und welche automatisiert laufen sollen.

• Testumgebung
  • Tipp: Wann ist die Umgebung für wen verfügbar? Wer baut die Umgebung auf und pflegt diese? Welche und wie viele Testumgebungen werden gebraucht? Was umfasst eine Testumgebung alles? Welche Schnittstelle, Umsysteme, Mocks und welche Zugriffe werden benötigt?

• Testdaten
  • Tipp: Besonders technische – nicht-funktionale – Tests wie Last- und Performancetests brauchen oft eine große Masse an Testdaten. Möglicherweise muss man über Produktionsabzüge, Massen-Testdatengenerierung oder Anonymisierung nachdenken. Das alles gehört zum Bereich Testdatenmanagement was mit zum Testmanagement gehört, aber eine eigene Rolle haben kann.

• Ressourcen bzw. Test-Personalfragen, Testteam-Zusammenstellung
  • Alle personellen Fragen müssen überdacht werden: „Wann, Wer, Wo, Was?“ Dazu gehört auch "Wer“ kann "Was"? Sprich, wer soll welche „Tester-Rolle“ und welche „Testaufgaben“ übernehmen.

• Teststeuerung, Überwachung der Testaktivitäten und Erheben von Trends
  • Tipp: Durchgehende Kontrolle, ob alles gut läuft oder Probleme eskaliert werden müssen. Prüfen ob alles in Plan läuft. Wie entwickeln sich die Defects/Issues (Fehler/Abweichungen) von Woche zu Woche, bzw. von Meilenstein zu Meilenstein? Wie weit ist es bis zum nächsten Meilenstein? Schaffen wir das?

• Reporting, Berichte:
  • Welche Berichte sollen wann und an wen gesandt werden?
  • Welche Eskalationsstufen und Eskalationswege gibt es?
  • Tipp: Berichte und Testergebnisse sollten nachverfolgbar und transparent sein.

• Testplanung:
  • Tipp: Das Testen Frühzeitig starten (Siehe dazu auch den Absatz „Testing im Softwarelebenszyklus“). Zur Testplanung sind geeignete Metriken auszuwählen, mit denen man den Fortschritt des Tests überwachen kann und eine Aussage treffen kann, ob man „im Plan“ liegt.

• Defect-Prozesse, Fehlermanagement bzw. Defectmanagement-Prozesse
  • Tipp: Der Workflow für den Defectmanagement-Prozesse sollte möglichst leicht verständlich und in einer Form tool-unterstützt sein, sodass niemand, der in seiner Rolle Defects bearbeitet (egal ob Tester oder Entwickler), eine Anleitung bzw. eine Handreichung zum Defect-Management-Prozess braucht. Es sollte einleuchtend und selbsterklärend sein.
  • Tipp: Auch die Kontrolle / Überwachung vom Defectmanagement-Prozess und Status der Defects obliegt dem Testmanager, insofern die Rolle nicht an andere Personen ausgelagert wurde.

• Aufwandschätzungen / Testschätzung
  • Tipp: Diese Schätzungen macht der Testmanager normal nicht alleine, sondern durch das Einbeziehen der Tester und Testautomatisierer. Zuvor müssen natürlich die Aufwände erst einmal grundsätzlich geklärt werden.

• Und natürlich aktive kontinuierliche Verbesserung / Test-Improvement
  • Tipp: Unter anderem durch methodische Retroperspektive Meetings mit den Testern, welche vom Test Manager initiiert werden.

Das Testkonzept

Je nachdem, wie das Unternehmen und das IT-Projekt aufgestellt ist, können diese Punkte (siehe „Was umfasst Testmanagement im Einzelnen?“) dann in ein Testhandbuch, Teststrategie, Testkonzept (etc.) wandern, je nachdem welcher Entwicklungsprozess gepflegt wird. Es muss nicht zwangsweise alles in aufwendiger Dokumentation gefestigt werden, besonders in agilen Projekten nicht, dennoch wird sich über die meisten der Punkte auch im Agilen-Test Gedanken gemacht. Je weiter „lean“ oder „agile“ ein Softwareentwicklungsprojekt ist, desto kleiner wird die Dokumentation dazu sein. Agiles Kredo zur Dokumentation: „Just enough!“. Jedoch ist der Gedanke über die Themen rund um das Testmanagement nie fehl am Platz. Nach ISTQB ist das Testkonzept...

„Ein Dokument, das u.a. den Gültigkeitsbereich, die Vorgehensweise, die Ressourcen und die Zeitplanung der beabsichtigten Tests mit allen Aktivitäten beschreibt. (…)“[1]

Testing im Softwarelebenszyklus (Application Lifecycle)

So gut wie jedes Lehrbuch und jeder Lehrplan, der Softwaretest Themen umfasst, hat auch eine Passage mit folgender Aussage: Softwaretest-Aktivitäten bitte so früh wie möglich beginnen! Dennoch machen es die wenigsten. Wobei sich dies in Agilen Methoden ändert oder zumindest vermischt, da es in Agilen Vorgehen eher dazu gehört, dass der Tester die Storys bereits bei der Planung begutachtet. Jeden falls macht dies den Anschein, wenn man sich aktuell gängige Praktiken in der agilen Welt anschaut. Egal ob Agile oder nicht: Starten Sie also mit allen Testaktivitäten früh genug. Am besten lassen sie Tester bereits an der Projekt-Planung, Software-Konzeption und besonders der Anforderungs-Definition (bzw. Definition von Stories) teilhaben, zum Beispiel in Form von Reviews. Schlagwort: Testen über den gesamten Application Lifecycle! Der Testprozess darf nicht losgelöst vom Entwicklungsprozess betrachtet werden. Der Testprozess ist vielmehr eng mit dem Entwicklungsprozess verwoben und läuft im Idealfall zeitgleich mit dem Entwicklungsprozess ab. Nur wenn der Testprozess den Entwicklungsprozess begleitet, können Synergieeffekte gewinnbringend genutzt werden, was wiederum zu einer Steigerung der Qualität des Produkts führt. Der Testprozess endet dabei erst mit der erfolgreichen Abnahme der Software durch den Auftraggeber. Testmanager und Tester sollen somit von Beginn an mit einbezogen werden, um zu einem hochwertigen und möglichst fehlerfreien Softwareprodukt zu kommen. Tester und Testmanager helfen dabei, Fehler in Konzepten aufzudecken und Fragen zur Testbarkeit von Beginn an zu erörtern. Ferner starten Tester und Testmanager ihre Testanalyse & Testentwürfe, bzw. die Arbeit am Testkonzept.

Toolunterstützung im gesamten Softwarelebenszyklus (Application Lifecycle)

Um effizientes Arbeiten zu ermöglichen, muss nicht nur das Entwicklerteam mit vorab definierten und im besten Fall im Unternehmen etablierten Tools arbeiten, sondern auch das Testteam. Für die Testplanungen und Verwaltung kommen dabei in den letzten Jahren vermehrt sogenannte ALM-Tools (Application Lifecycle Management Tools) zu Einsatz. In diesen Tools können alle Softwareanforderungen für gewöhnlich einfach und transparent abgebildet werden. Die Tester haben danach die Möglichkeit, aus dieser Testbasis ihre Testfälle abzuleiten. Die Testfälle werden dabei wiederum im ALM-Tool erfasst. Durch eine konsequente Verlinkung der Testfälle mit den Requirements kann sichergestellt werden, dass keine Anforderung vergessen wird. Der Testmanager kann im Anschluss die einzelnen Testfälle zu unterschiedlichen Testläufen zusammenfassen und den jeweiligen Testern zuweisen, die diese dann ausführen. Treten während der Ausführung der einzelnen Testläufe Fehler auf, so werden diese im Tool standardisiert erfasst und priorisiert, so dass sich das Entwicklerteam im Nachgang um die Behebung der Fehler kümmern kann. Nachdem die Fehler behoben wurden, kann der Testmanager neue Testläufe planen und seinen Teammitgliedern zuweisen. Die ALM-Tools bieten für gewöhnlich eine automatische Auswertung der Testläufe sowie standardisierte Testfortschrittsberichte und Testüberdeckungsmetriken an. Dadurch ist das gesamte Team stets über den aktuellen Stand des Projekts informiert und kann bei Problemen oder Verzögerungen frühzeitig gegensteuern. Viele Unternehmen nutzen verschiedene Tools für diese Aufgaben. Die meisten bekannteren Tools am Markt lassen sich durch Schnittstellen auch miteinander verbinden. Somit kommt man auch mit vielen einzelnen Tools zu seiner ALM-Toollandschaft. Auch die Testautomatisierung ist durch ein Testautomatisierungstool unterstützt, dazu im weiteren Verlauf des Artikels mehr. Falls die Tool-Kette aus diversen Applikationen besteht, sollte die komplette Tool-Landschaft mit besonderem Augenmerk auf Testautomatisierung, Testfall-Management, (ggf. Anforderungen), Reporting/Teststatus und Defects/Abweichungen mit einander vernetzt sein und an allen nützlichen Stellen Informationen der anderen Tools anzeigen, bzw. über Schnittstellen austauschen und sich miteinander synchronisieren.

Standardisierung und Richtlinien im Softwaretest

Möchte man einen Testprozess etablieren, welcher nicht nur für ein Projekt verwendet werden kann, muss unternehmensweite Standardisierung eingesetzt werden. Hierzu können unternehmens-interne Testhandbücher / Testleitfäden / Teststrategien (laut ISTQB: Testrichtlinie) erstellt werden, welche als Vorlage dienen, wenn in einzelnen IT-Projekten konkrete Test-Strategien und konkrete Test-Konzepte konzipiert werden. Diese Art von Vorlage-Testhandbücher sind oft auch Teil eines übergeordneten Software-Engineering-Handbuchs (Software-Entwicklungs-Guideline) des Unternehmens. Als Minimum der Standardisierung im Softwaretest wären zum Beispiel Templates für Defect, Testfälle und Reports, welche sich ein Team für einen gemeinsamen Nenner erstellen kann. Oft werden in Unternehmen aber unternehmensweite Standards erarbeitet. Ferner kann man sich auf Standards im Softwaretest im Softwaretest und Softwaretest-Dokumentation beziehen, wie sie nach ISTQB, IEEE, ISO/IEC zu finden ist. Ein relativ neuer Standard im Softwaretest ist die ISO/IEC/IEEE 29119 Software Testing Diese umfasst [4]:

• 29119-1: Konzepte und Definitionen (Concepts & Definitions)
• 29119-2: Testprozesse (Test Processes)
• 29119-3: Testdokumentation (Test Documentation)
• 29119-4: Testtechniken (Test Techniques)
• 29119-5: Keyword-Driven Testing (Keyword Driven Testing)

Durch die einheitliche Vorgehensweise und die Verwendung von Best Practices kommt es einerseits zu einer Verringerung des Zeitbedarfs und andererseits zu einer verbesserten Zusammenarbeit im Team. Nur wenn jedem klar ist, was er zu tun hat und wie er es zu tun hat, kann effizientes Arbeiten stattfinden. Weiterhin können Personen schneller Teams wechseln, bei unternehmensweiten Standards auch über IT-Projekte hinaus. Die Testrichtlinie kann anstatt fein-granularen Details auch zumindest den Einsatz von bestimmten Vorgehen oder Standards (zB. ISTQB) oder Tools (zB. bestimmten Testautomatisierungs-Tools oder ALM-Tools) beinhalten. Ein wichtiger Punkt ist auch die Verwendung einer einheitlichen Sprache im gesamten Team. Hierbei kann beispielsweise eine verpflichtende ISTQB-Zertifizierung für alle Teammitglieder dabei helfen, das Team auf Schiene zu bringen und unnütze Diskussionen über Begrifflichkeiten zu vermeiden. Ein weiterer Vorteil von unternehmensweite Standardisierung ist zudem die erleichterte Auswertung von Kennzahlen und die Möglichkeit der automatischen Generierung von notwendigen Berichten. Standardisierung im Testmanagement bzw. im Testprozess ist natürlich ein gewisser Rahmen geboten. Unter Bedacht und guter Begrünung, sollte man stets einem unternehmensweiten Test-Standard entgegnen dürfen und eine individuelle Lösung vorziehen.

Outsourcing von Testprozessen

Das Outsourcing von Teilen des Testprozesses oder des gesamten Testprozesses kann je nach Unternehmen und Projekt Sinn machen oder auch nicht. So werden in der Praxis häufig Teilbereiche wie die Testautomatisierung an externe QS-Beratungshäuser bzw. externe IT-Dienstleister vergeben, da diese (hoffentlich ☺ ) bereits viel Know-how auf diesem Gebiet haben oder eventuell sogar kostengünstiger sind, als die eigene, interne Testabteilung. Vor der Entscheidung, Outsourcing einzusetzen, sollte jedoch immer eine ehrliche Kosten-Nutzen-Analyse und ein realistischer Zeitplan erstellt werden. Nicht selten laufen diese Projekte, wenn sie schlecht geplant wurden, nicht nur kostentechnisch aus dem Ruder. Vor allem der zusätzliche Kommunikationsaufwand und die Überprüfung der Endergebnisse werden in der initialen Planung eines Outsourcingprojekts häufig unterschätzt. Je nach Outsourcing-Modell kann es sich um Themen der Testautomatisierung, Manuelle Tests, bestimmte Tests (Lasttest) oder sogar der große Teil des Testprozesses (Integrationstests, Systemtest, Abnahmetest) handeln. Von Near-Shore bis Off-Shore ist je nach Projekt, Situation und Unternehmen die beste Wahl zu treffen. Es muss bei Start eines Outsourcingprojekts nicht nur festgelegt werden, welches Modell (Nearshoring oder Offshoring) gewählt wird und welche Ergebnisse erwartet werden, sondern auch, wer für die Kommunikation mit dem Drittanbieter verantwortlich ist und welche Maßnahmen bei Problemen ergriffen werden können.

Testplanung und Teststeuerung

Ohne eine gewissenhafte und saubere Testplanung können besonders größere Softwareprojekte schon zu Projektbeginn zum Scheitern verurteilt sein. Um eine hohe Softwarequalität und eine termingerechte Fertigstellung der Software zu garantieren, benötigt man daher zuverlässige Testplanung. Die Testplanung besteht dabei nicht nur aus einer simplen Ressourcenplanung, sondern umfasst auch die Erstellung eines Testkonzepts, in welchem alle wesentlichen Testobjekte, die Testeingangs- sowie Testausgangskriterien, die Testabbruchbedingungen und auch die eingesetzten Testmethoden und die Testvorgehensweise festgehalten werden. Zudem müssen zu Beginn des Projekts die notwendigen Ergebnisse und Dokumente definiert werden, welche zu Projektende geliefert werden müssen. Zur Teststeuerung gehört auch das Überwachen der Testaktivitäten und das schnelle Eingreifen bei Missständen.

Testanalyse und Testentwurf

In dieser Phase werden die Details der einzelnen Testobjekte betrachtet. Erst hier erkennt man, wie aufwendig das Projekt in Wirklichkeit ist und welche Testtechniken und Werkzeuge zur Anwendung kommen. Durch die genaue Analyse der Requirements wird beispielsweise erst klar, ob Performance Tests für das Projekt in der ersten Phase zwingend notwendig sind oder wie viele Tests automatisiert werden können. Die Absicht dieser Phase ist es, alle Testziele in konkrete Testbedingungen und Testfälle zu übersetzen, sodass am Ende dieser Etappe eine fertige Testentwurfsspezifikation vorliegt.

Teststufen und Testtechniken

Im Allgemeinen stehen dem Testteam verschiedene Testtechniken für unterschiedliche Teststufen zur Verfügung. Die Teststufen lassen sich dabei für gewöhnlich in folgende Teildisziplinen aufteilen:

• Unittests, Modultests, Komponententests
• Integrationstest, Schnittstellen-Tests
• Systemtests
• Abnahmetest

In diesen Teststufen können dann unterschiedliche Testtechniken wie Black-Box-Tests oder White-Box-Tests zum Einsatz kommen, wobei Unittests nicht immer in den Zuständigkeitsbereich des Testteams fallen. In welchem Ausmaß, welche Technik zum Einsatz kommt, bestimmt für gewöhnlich der Test Manager. Bei Punkten wie Unittests ist Absprache mit Entwicklungsleitung oder Projektleitung zu halten. Es sind bei Softwareprojekten in der Luftfahrttechnik oder im medizinischen Bereich beispielsweise rechtliche Vorgaben einzuhalten, die den Einsatz reiner Black-Box-Tests unmöglich machen.

Testautomatisierung

Im Zuge der Testanalyse muss außerdem entschieden werden, welche Tests sich zur Testautomatisierung eignen und welche Tests manuell durchgeführt werden sollen. Je nach Projekt und Zeit muss hierbei das bestmögliche Kosten-Nutzen-Verhältnis geschaffen werden. Vor allem Routinetätigkeiten und Module, die schon eine gewisse Stabilität aufweisen, lassen sich sehr einfach automatisieren, sofern im Testteam genügend Know-how vorhanden ist und dem Team ausreichend Zeit zur Verfügung steht. Ein häufiger Fehler hierbei sind unrealistische Managementvorgaben. Es macht wenig Sinn, vorab zu definieren, dass beispielsweise 70 % bis 80 % der Tests automatisch ablaufen müssen, wenn die Tester im Gegenzug dazu nur 20 % bis 30 % der Entwicklerzeit bekommen. In diesen Fällen ist es Aufgabe des Testmanagers, der Projektleitung eine realistische Einschätzung darüber zu geben, wie viele automatisierte Tests unter den gegebenen Voraussetzungen möglich sind und welche Module beispielsweise erst nach dem ersten Release automatisiert werden. Eine Liste von Testautomatisierungs Software findet sich hier und ein ausführliche Erläuterung über Testautomatisierung befindet sich hier.

Testdaten und Testumgebung

Um erfolgreiche, praxis-nahe Tests durchführen zu können, wie zum Beispiel für Last- und Performancetests erforderlich,  benötigen die Tester so früh wie möglich eine Testumgebung, die der späteren Produktivumgebung entspricht. Zudem müssen die QA-Engineers auf eine konsistente und realistische Datenbasis zugreifen können. Es hilft hierbei wenig, beispielsweise ein Data Warehouse, welches im Echtbetrieb mit Millionen von Datensätzen arbeitet, während des Tests mit nur einigen Hundert Testdatensätzen zu simulieren. Genauso wenig ist es sinnvoll, Applikationen, die später von Hunderten von Usern zeitgleich benutzt werden, im Performancetest mit nur 2 oder 3 Benutzern zu überprüfen. Hierbei kommt dem Sizing der Testumgebungen eine entscheidende Rolle zu und genau hier sind die Anknüpfungspunkte für das spätere Configuration Management und Release Management. Es ist Aufgabe des Testmanagers, diese Überschneidungen zu koordinieren und seinem Testteam die optimalen Umgebungen (je nach Einsatzzweck) bereitzustellen. Dazu gehören auch alle benötigten Umsysteme und eventuellen Mocks. Neben der Testumgebung spielen auch die passenden Testdaten eine wichtige Rolle. Je nach Einsatzzweck müssen die passenden Testdaten vorhanden sein. Praxis-vergleichbare Lasttests oder Fail-Over-Tests unter Lastbedingungen benötigen meist sehr viele Testdaten oder sogar einen vollen Praxis-Abzug. Um an die geeigneten Testdaten zu kommen gibt es viele verschiedene Wege. Die Schlagwörter dazu sind Anonymisierung, Pseudo-Anonymisierung, Synthetische Testden, Testdaten-Generatoren, Tesdatenmanagement-Tools, Datenschutz und Security. Die Planung, Generierung und Koordination der Bereitstellung der Testdaten gehört zum Testdatenmanagement, welches häufig in IT-Projekt keine eigene Rolle (bzw. Person) besitzt, sondern von den Testern und Entwicklern mit ausgeführt und vom Testmanager geplant wird. Gerade in sehr großen Unternehmen und sehr großen IT-Projekten können hierzu aber feste Rollen und feste Personen von Vorteil sein, die sich zentral mit dem Thema Testdaten auseinander setzen. Besonders wenn der Punkt Datenschutz hinzukommt, bedarf es einiges an Spezialisierung und Expertise in dieser Thematik.

Testrealisierung und Testdurchführung

Wurden alle Testeingangskriterien erfüllt, kann die Phase der Testrealisierung gestartet werden. In dieser Phase werden alle Testfälle und Use Cases auf Basis der Testentwurfsspezifikation ausgeführt und dokumentiert. Der Testmanager überwacht dabei den Testfortschritt und trifft beim Auftreten von schwerwiegenden Problemen allenfalls die Entscheidung zum Testabbruch. Zudem kümmert er sich darum, dass alle Testergebnisse gemäß den vorab definierten Standards nachvollziehbar dokumentiert werden und dass alle gefundenen Fehler lückenlos im verwendeten ALM-Tool oder Fehlermanagementtool aufscheinen.

Testauswertung und Bericht

Nach erfolgreichem Abschluss der Testdurchführung wird ein Testabschlussbericht erstellt. Dieser Report enthält eine Zusammenfassung der Tests und Testaktivitäten sowie eine Liste aller gefundenen Abweichungen. Jedes Testobjekt wird in diesem Bericht einzeln bewertet und es kommt zu einer Empfehlung über die Freigabe des jeweiligen Testobjekts. Häufig wird neben dem Bericht selbst auch eine Testüberdeckungsmatrix geliefert. Diese Matrix zeigt, welche Requirements durch welche Testfälle abgedeckt wurden.

Abschluss der Testaktivitäten

Nach der Freigabe der Software können die Testaktivitäten abgeschlossen werden. Zu diesen Abschlussarbeiten zählt beispielsweise die Archivierung der Testumgebung und der Testdaten, sowie die Erstellung von abschließenden Berichten und Dokumenten. Schlussendlich kommt es zu einer Bewertungssitzung, in welcher auch Best Practices für die nächsten Projekte erarbeitet werden sollten.

Aufgaben des Testmanagers

Eine Aktivität von Testmanagern ist die Erstellung einer Teststrategie und Testkonzept, die im optimalen Fall von allen Stakeholdern bindend unterzeichnet wird. Der Testmanager ist zudem gezielt für die „Testplanung und Teststeuerung“  und für das „Reporting und den Informationsfluss“ zuständig und nimmt bestenfalls an allen relevanten Projektmeetings teil. In diesen präsentiert er neben dem Testfortschritt seines Teams die vorab definierten Berichte und Metriken. Der Testmanager ist das wichtigste Bindeglied zwischen den Testern und allen Stakeholdern, die am Test und den Testergebnissen interessiert sind. Der Testmanager vertritt in Meetings einen Standpunkt von hoher Softwarequalität. Dabei ist vom Testmanager stets ein gutes Verhältnis zu allen Stakeholdern anzustreben. Der Testmanager muss die Stakeholder und ihre Test-Anforderungen wie auch ihre Kritik am Testvorgehen verstehen. Dazu kommuniziert der Testmanager natürlich den Teststatus (inkl. Defect-Status) oder beantwortet Rückfragen der Stakeholder dazu bei Bedarf. Dabei hat der Testmanager stets einen professionellen und objektiven Eindruck aufrecht zu erhalten. Der Testmanager muss Tests in seinem Testteam verstehen und Auskunft über den Sinn, Testabdeckungen und anderen Rückfragen geben können, die von Stakeholdern aufkommen. Aus diesem Grund muss er einen groben Überblick über die Gesamtbedingungen des Testteams haben, aber auch Detailwissen über die Tests verfügen. Da der Testmanager bestenfalls bei Testanalyse / Testentwurf zumindest konzeptionell und beratend unterstützt hat und den kompletten Testprozess mit geplant haben sollte, ist dieses Detailwissen meist vorhanden. Neben diesen Funktionen kümmert sich der Testmanager um die Aufwands- und Einsatzplanung und konzipiert das Testvorgehen sowie die Umsetzung der Tests. Er definiert dabei, welche Testumgebung zum Einsatz kommt und mit welchen Testing-Tools, Templates und Standards gearbeitet wird. Der Testmanager leitet das Testteam. Ferner bemüht er sich um eine gute und produktive Stimmung im Team und ist die erste Anlaufstelle für Teammitglieder beim Auftreten von Problemen oder Fragen. Dies stellt auch hohe Ansprüche in sozialer Kompetenz, Konfliktlösung und an einer sehr guten Führungsrolle des Testmanagers.  In der Regel baut der Testmanager auch das Testteam auf. Im besten Fall dient der Testmanager als Vorbild-Funktion für sein Testteam. Dazu ist er besten-falls auch in der Lage, seine Tester zu Coachen, in Testtechniken und beispielsweise Testfallentwurfsverfahren. Schlussendlich konzipiert, koordiniert oder bearbeitet (operativ) der Testmanager alle Punkte, die unter „Was umfasst Testmanagement im Einzelnen?“ aufgelistet sind.

Sind Testmanager immer nötig?

Testmanager werden für gewöhnlich erst dann eingesetzt, wenn das Testteam eine bestimmte Größe erreicht hat. In der Praxis hat sich dabei eine Teamgröße von 3 bis 7 Testern etabliert. Dabei leiten Testmanager ihr Team nicht nur während des Projekts, sondern übernehmen auch die Aufgabe einer zentralen Schnittstelle zwischen dem Projektmanagement, dem Entwicklungsteam und dem Testteam. Ist kein Testmanager vorhanden, übernimmt das Testteam die Aufgaben im Testmanagement implizit mit, da die meisten Belange daraus zwangsweise koordiniert und geplant werden müssen.

Die häufigen Probleme im Testmanagement

„Leider“ sind die häufigsten Probleme im Testmanagement ganz lapidarer Natur:

• Zu wenig Zeit für den Test, da Softwaretest-Aktivitäten meistens in IT-Projekt zu niedrige Priorisierung genießen.
• Test-Aktivitäten wurden zu spät im IT-Projekt gestartet.
• Es ist zu wenig Budget für den Test übrig bzw. für den geplanten Testumfang , der dem IT-Projekt gut tun wurde.
• Probleme rund um Testautomatisierung (schlecht wartbar, zu teuer, zu langwierig, zu langsam, läuft gar nicht, läuft nicht konstant, schlechte oder fehlende Abdeckung)
• Differenzen zwischen Testteam und Entwicklungsteam oder anderen Stakeholdern.

Testmanagement in agilen Softwareprojekten

In der agilen Softwareentwicklung sind viele klassische Testmanagementmethoden von Haus aus integriert (oder sollten es zumindest sein). Das führt dazu, dass Testmanager in diesen Entwicklungsmodellen meist eher eine beratende Funktion einnehmen bzw. „Testmanager“ eher eine imaginäre Rolle ist, die von einer (oder mehreren) Person aus dem agilen Team mit ausgeführt wird. Über viele Punkte aus „Was umfasst Testmanagement im Einzelnen?“ macht sich das agile Team auch Gedanken, aber hierbei eher im Team und durch kurze Absprachen. Testmanager können weiterhin Ansprechpartner für eingesetzte Testwerkzeuge und Testmethoden sowie für Test-Weiterbildungsmöglichkeiten und die Arbeitsplatzauslastung sein. Zudem besteht ihre Aufgabe darin, eine Testkultur im Team (bzw. über das Team hinaus) zu etablieren und eine gesunde Einstellung zu hoher Softwarequalität zu schaffen. Die meisten Agilen Methoden bringen grundlegende QS-Maßnahmen mit sich, beispielweise sollen Stories und deren Akzeptanzkriterien testbar sein und Testabdeckung (mindestens) in Form von Unittests gehört in der Regel dazu. Auch das Aufstellen und Einhalten der Definition-of-Done (DOD) ist meist mit QS-Aktivitäten bzw. Test-Aktivitäten verbunden. Denn auch dabei legt das Team meist eine Testabdeckung beispielsweise bei Unittest und Schnittstellen-Test, Einhalten von Kodierregeln oder anderen QS-Maßnahmen fest. Gegebenen-falls wird sogar Test-driven vorgegangen (TDD, BDD). In Vorhergehensmodellen wie beispielsweise SCRUM gibt es die Rolle des Testmanagers nicht direkt. Aber die Rolle des Testers gibt es in SCRUM auch nicht. Dennoch gibt es natürlich „Testaktivitäten“ in SCRUM und auch die Gedanken des Testmanagers (bzw. der Umfang des Testmanagements) sind im SCRUM Team vorhanden, nur eben eher im gesamten Team verteilt und eher implizit. Wie ein Unternehmen seine Qualitätssicherung ins SCRUM Team integriert, ist stark unterschiedlich. Oft weicht dies, je nach Personen im Team, auch innerhalb des Unternehmens stark von Team zu Team ab. Dies soll auch so sein, denn ein Grundgedanke des Agilen Manifests ist „Erst Personen, dann Prozesse“. Sprich, man schaut im agilen Team erstmal, was das Team kann bzw. wer welche Kenntnisse mitbringt und teilt seine Arbeit so ein, dass es den besten Erfolg inkl. höchster Qualität bringt. Soweit die Theorie. Die Hauptverantwortung trägt im SCRUM Team der Product Owner, der für den Erfolg des Produkts verantwortlich ist. Bei diesem sind in SCRUM Teams häufig die meisten Facetten des Testmanagers bzw. des Testmanagements zu finden. Denn der Product Owner sollte ohnehin dafür sorgen, dass das Team ein hohes Qualitätsbewusstsein an den Tag legt und dass sich jedes Mitglied des Entwicklungsteams von Anfang an für die Qualität des Produkts verantwortlich fühlt. Durch das agile Vorgehen können dabei natürlich Synergieeffekte genützt werden. Häufig wird in SCRUM Teams trotzdem nach „Entwickler“ und „Tester“ getrennt, auch wenn es SCRUM so nicht vorgibt. „Tester“ sind in SCRUM oft „Testautomatisierer“ da in agilen Projekten aufgrund der kurzen Zyklen meistens Testautomatisierung betrieben wird. Auf Unittest Ebene sowieso, aber auch auf Schnittstellen und GUI-Level. Im Agilen Bereich hat sich auch Continuous Integrations bzw. Continuous Delivery als Standard etabliert. Damit laufen grundlegende Tests direkt nach Code-Check-In und aufwändigere Tests sollten jede Nacht laufen. Aber auch hierbei bleiben die ganzen Gedanken aus dem Testmanagement (Testumgebung? Was testen? Was automatisieren und was nicht? Wer macht was?) nicht unbeantwortet, werden allerdings eben durch das Team beantwortet. Bzw. mit „Commitment“ des Teams. Ist eine Person aus dem Testbereich oder Testmanager im agilen Team, macht natürlich Sinn, gerade diese Person mit Fragen und Aufgaben aus dem Bereich Test und Testmanagement zu betrauen. So können Entwickler den Tester bei der Erstellung und der Integration von automatisierten Tests unterstützen, während der Tester selbst die Entwickler schon früh auf kritische Bereiche in den Testobjekten aufmerksam machen und Reviews durchführen kann. Zudem ist es dem Team möglich, flexibel auf Änderungen zu reagieren, da sie nicht an einen starren Testplan gebunden sind.

Exkurs: Das Testmanagement als Unterstützung der Vertragslage für beauftragte Software

Nicht selten sind die Abnahmekriterien für eine beauftragte Software schon vor Vertragsabschluss bekannt. Wenn auch noch nicht ausdefiniert, existiert auf detaillierter Nachfrage hin sicherlich eine gewisse Vorstellung vieler Abnahmekriterien in den Köpfen der Stakeholder. Um späteren Streitigkeiten Einhalt zu gebieten, kann die frühe Erstellung der Abnahmekriterien somit auch zur Festlegung der Vertragslage für eine Softwarebeauftragung sinnvoll sein. Durch die Verankerung der Abnahmekriterien im Vertrag kann das Projekt somit zügig abgewickelt und abgenommen werden, ohne unnötige Diskussion darüber, ob eine vom Kunden gewünschte Funktionalität nun ein Change Request oder ein Requirement ist. Der Einsatz konkreter für den Test auch nutzbaren Abnahmekriterien, hat zudem noch den weiteren Vorteil, dass es die Erstellung eines Testkonzepts vereinfachen kann. Auch terminliche Planung und Meilensteine, die auch im Testkonzept Erwähnung finden würden, können aus den Definitionen im Vertrag direkt in die Konzepte wandern. Bei diesem Konstrukt ist wichtig, dass der Testmanager bzw. das Test-Team direkt von Anfang an im Entwicklungsprozess beteiligt ist. Denn diese müssen direkt ihre Expertise einfließen lassen, was testbar ist und wie es später getestet werden kann. Dieses Konstrukt bietet an sich Vorteile, da so gut wie jedes Lehrbuch uns lehrt, den Test frühestmöglich im IT-Projekt zu beteiligen. Wie die Agile-Welt uns in den letzten Jahrzehnte zeigt (oder weismachen möchte), ist das frühe und (zu) detaillierte klären von Abnahmekriterien aber ein Unterfangen, dass auch Risiken und große Hürden mit sich bringt, da die Ansichten der Stakeholder sich auch ändern können. Denn auch die Stakeholder bekommen im Laufe des Softwareentwicklungsprozesses ja erst ein echtes Gefühl für ihre gelieferte Software. Meist lernen die Stakeholder auch erst mit der Zeit, was ihre Software wirklich benötigt. In diesem Fall müssen die vertraglichen Abnahmekriterien im gegenseitigen Einverständnis angepasst werden.

Fazit

Das erfolgreiche Testen von Software benötigt nicht nur Zeit und Personal, sondern auch ein durchgehendes Testmanagement. Ohne die Integration des Testmanagementprozesses in den Projektablauf kommt es immer wieder zu Verzögerungen und zu Budgetüberschreitungen im Projekt. Im schlimmsten Fall kann der Auftraggeber die Abnahme der Software sogar verweigern. Nur durch ein systematisches Vorgehen und durch ein konsequentes Umsetzen aller relevanten Themen können gesetzte Qualitätsstandards eingehalten werden. Dies kann nur dann gelingen, wenn der Testprozess im Unternehmen selbst etabliert ist und hinreichend gemanagt wird und wenn den Verantwortlichen genügend Ressourcen zur Verfügung gestellt werden.

Ihre Erfahrungen, Fragen, Feedback?

Haben Sie Fragen rund um das Thema Testmanagement oder Agile-Testing? Oder möchten Sie gerne eine Beigabe aus Ihrem Testmanagement-Knowhow beisteuern? Gerne Feedback, Ideen und Fragen in den Kommentaren weiter unten. Quellenverzeichnis

1. ISTQB Gloassar: http://glossar.german-testing-board.info (Abruf 07.02.2017)
2. Heise News: https://www.heise.de/newsticker/meldung/Bericht-Viele-IT-Projekte-scheitern-an-unzureichenden-Tests-1233377.html (Abruf 07.02.2017)
3. Heise News: https://www.heise.de/resale/artikel/Fuenf-goldene-Regeln-fuer-erfolgreiches-Testmanagement-1247450.html (Abruf 07.02.2017)
4. Wikipedia: https://en.wikipedia.org/wiki/ISO/IEC_29119 (Abruf 07.02.2017)
5. ISTQB CTFL TM: http://www.german-testing-board.info/wp-content/uploads/2016/07/CTAL_Lehrplan2012_TM_Final_Germ_V100.pdf (Abruf 07.02.2017)