Testmanagement im agilen Projekt – Ein Erfahrungsbericht

08.07.2016

Agiles_Projekt - TestmanagementDie Aussage im Bereich Testmanagement „Das sollte man noch testen“ ist sicher so häufig, wie die allgemein bekannten „Ich habe nichts gemacht“ und „Das kann nicht sein“.

Und schon sind wir mitten drin in der Diskussion: WAS sollte WER und WIE, in welchem UMFANG noch in der vorgegebenen Zeit testen? Erschwerend können dann noch Kapazitätsengpässe, Wegfall von Know how-Trägern, fehlende Testfälle, unvollständige oder gar keine Testdaten, Änderungen und vieles mehr dazu kommen.

Handelt es sich dann noch um ein agiles Projekt, nehmen die Herausforderungen für das Testmanagement nochmals deutlich zu. Der Grund: Parallel ablaufende Prozesse und Änderungen der Funktionalität innerhalb eines Zeitfensters.

Für den Tester bedeutet das: Er muss innerhalb kürzester Zeit auf dem aktuellen Informationsstand sein und sich ergebende Änderungen und deren Auswirkungen in kurzen Reaktionszeiten auf seine Tätigkeit und die Dokumentation umsetzen. Das ist nur über kurze und gut funktionierende Kommunikationswege zu den ausführenden Stellen und zum Projektleiter realisierbar.

Hier gilt in erster Linie der Grundsatz: „Ruhe bewahren“. Als erstes sollte man sich einen Überblick über das WAS soll getestet werden, verschaffen, die Testziele und die Abgrenzungen zu den Schnittstellen (UMFANG) definieren und die Funktionen des Testobjektes in einer geeigneten Struktur abbilden. Innerhalb dieser Struktur sollte für jede Komponente zu jedem Zeitpunkt die jeweilige Testabdeckung erkennbar. So können eventuell noch vorhandene Lücken geschlossen oder Unstimmigkeiten geklärt werden. Das daraus entstandene „Arbeitspaket“ wird der verbleibenden Zeit gegenübergestellt und die entsprechenden Anpassungen für Zeit, Geld und Leistung durchgeführt. Hier klärt sich unter anderem dann auch das WER.

In der Praxis habe ich, vor allem bei agilen Projekten, sehr gute Erfahrungen mit der Erstellung eines Arbeitsdokumentes, in dem diese Informationen enthalten sind, gemacht.

Erstellung eines Arbeitsdokumentes sorgt für gleiches Verständnis beim Testmanagement

Der Inhalt dieses Arbeitsdokumentes ist die komprimierte Zusammenstellung von testrelevanten Informationen, die in funktionelle Komponenten gegliedert ist. Folgende Komponenten sollten im Dokument enthalten sein:

  • Grafik der gewünschten Darstellung
  • Akzeptanzkriterien
  • Bemerkungen aus Besprechungen
  • testrelevante Umsetzungen mit Verweis auf zugehörige Testfälle
  • Berechtigungen der Rollen
  • weitere relevante Informationen

Das Ziel des Arbeitsdokumentes ist, jederzeit einen Überblick und eine Stellungnahme zum aktuellen Stand zu haben.

Der Vorteile dieses Arbeitsdokumentes liegt darin, auf die Änderungen im agilen Projekt mit kurzen Reaktionszeiten gezielt zu reagieren und jederzeit einen Überblick über die daraus resultierenden ToDo’s zu haben. Die Komponente ist schnell auffindbar, angepasst und die direkt betroffenen Testfälle ersichtlich. Diese können entsprechend erweitert/geändert/entfernt, bzw. die noch zu erstellenden Testfälle für die gewünschte Testabdeckung identifiziert werden.

Das Arbeitsdokument wird ständig fortgeschrieben, aber der Umfang innerhalb der Kapitel reduziert sich im Laufe der Zeit, weil die ursprünglichen textuellen Beschreibungen in eine kompakte Tabelle überführt werden. Damit hat man jederzeit eine aktuelle Dokumentation zur Verfügung, die in Gesprächen sehr schnell für das gleiches Verständnis sorgt und somit effektiv Fragen klärt, vorhandene Lücken füllt, Unstimmigkeiten entscheidet oder Änderungen erfasst. Es dient auch dazu, neuen Kollegen schnell einen Überblick oder bei einer Übergabe an Dritte den aktuellen Stand zu vermitteln.

Arbeitsdokument am Beispiel: Testen einer Web-Anwendung

Hier wird am Beispiel einer Web-Anwendung die Struktur und der Inhalt des Arbeitsdokumentes erläutert. Die Einleitung beinhaltet ein Übersichtsbild, in dem die Web-Anwendung mit den betroffenen Schnittstellen, Systemen und Zugängen dargestellt ist, sowie die prägnante Beschreibung der Aufgabenabgrenzung.

In den nachfolgenden Hauptkapiteln werden die einzelnen „Seiten“ der Web-Anwendung dargestellt. Die darunterliegenden Unterkapitel beinhalten die zugehörigen Komponenten dieser „Seiten“. Komponenten sind z. B. der Header, der Footer und einzelne Funktionsgruppen (z. B. Kacheln) auf dieser „Seite“. Der zugeordnete Screenshot der Komponente sorgt für ein einheitliches Verständnis und dient als „Checkliste“, ob alle Funktionalitäten durch Testfälle abgedeckt sind. Ergänzt wird dieses Kapitel mit testrelevanten Stichpunkten aus vorhandenen Dokumentationen und Besprechungen.

Bei der Komprimierung werden diese Stichpunkte mit den testrelevanten Ausprägungen in eine Tabelle überführt. Diese Tabelle wird erweitert um die Spalten „Bemerkung“ (Zusätzliche Informationen), „Testfall-ID“ (zugehöriger Testfall, und „Land“ (länderspezifische Abweichungen wie Formate, Einheiten, …). Meistens ergeben sich dabei bereits Spezifizierungen von Testdaten, die hier ebenfalls mit aufgeführt werden.

Beinhaltet das Kapitel eine abgebildete Logik, hat es sich als hilfreich erwiesen, eine Referenztabelle, die auch als Checkliste beim Testfall hinterlegt wird, zu erstellen. Das erleichtert die Testdurchführung und deckt eventuell vorhandene logische Lücken auf. Ein Beispiel für solch eine Referenztabelle könnte die Auflistung der Zustände für das Anzeigen der jeweiligen Ampelfarben sein. Eine logische Lücke wäre dann, es gibt die Ampelfarbe Gelb, aber keinen Zustand dafür.

Für die Testdurchführung ist es wichtig, Abgrenzungen festzulegen. Am Beispiel Fahrzeugtest: Sollte der Testfall „Fahrertür öffnen“ nur die – Fahrer Tür öffnen – und NICHT – Fahrertür öffnen und das Radio am linken Drehknopf einschalten – enthalten.

Die Vorteile dieser Abgrenzung sind z. B., dass bei Änderungen am Radio weniger Testfälle angepasst werden müssen und Duplikate leichter erkannt und vermieden werden. In der Dokumentation wird dies durch die Verwendung von Querverweisen abgebildet, d. h. wird die gleiche Seite „Test“ aus verschiedenen Komponenten aufgerufen, ist diese Seite auch nur einmal dokumentiert und die daraus resultierenden Testfälle haben einen eindeutigen Bezug.

Erfahrungsbasierte Zuordnung von Funktionsinhalten zu Testfällen

Testfälle sollten die Funktionen hierarchisch testen, damit sich der Testaufwand reduziert und bei der Auswertung eine differenzierte Aussage möglich ist. So muss zum Beispiel eine Verbindung grundsätzlich vorhanden sein, bevor die Einzelheiten der Verbindung getestet werden.

Vor allem bei Mehrsprachigkeit oder länderspezifischen Unterschieden hat es sich als Vorteil erwiesen, dass das Testen der Funktionalität in der Sprache und in dem Land, in dem die Quellinformationen vorliegen, durchgeführt wird. Auf diese Testfälle aufbauend werden dann nur noch die Sprach, bzw. länderspezifischen Unterschiede getestet, wodurch Duplikate in den Testschritten reduziert und Änderungen leichter pflegbar sind. Die entsprechende Ausprägung wird im Titel des Testfalles für eine leichtere Identifikation mit aufgeführt.

Wer sich für die Gestaltung von Testfällen interessiert, kann dies in meinem Beitrag „Testmanagement: Worauf kommt es an? Ein Erfahrungsbericht“ nachlesen.

Fazit:

Auch beim Testen gilt, dass bei allen Beteiligten das gemeinsame Ziel im Vordergrund steht und dass mit gefundenen Fehlern, Abweichungen oder Problemen offen und auf sachlicher Basis umgegangen wird.

In den vielen Jahren des Testens in verschiedenen Projekten bei unterschiedlichen Kunden gibt es immer wieder unterschiedliche Voraussetzungen und Bedingungen, so dass es kein „Schema F“ geben kann. Aber mit der Erstellung eines Arbeitsdokumentes als effektives Hilfsmittel, abgestimmt auf die jeweiligen Bedürfnisse, ist ein effizientes Arbeiten möglich. Genau diese unterschiedlichen Herausforderungen sind es auch, die dafür sorgen, dass es nie langweilig wird und es ein sehr abwechslungsreicher, spannender und interessanter Arbeitsbereich bleibt.

Mehr zu erfolgreichen Softwareprojekten erfahren Sie hier
Zurück zur Übersicht

2 Kommentare zu “Testmanagement im agilen Projekt – Ein Erfahrungsbericht

  1. Was ich hier lese klingt nach Wasserfall mit dem Namen Agil draufgeklebt.
    Das agile Paradigma zielt darauf ab die Verantwortung für die Qualität an das Team abzugeben und die Rollen Projektleiter und Testmanager abzuschaffen. Die Rolle des QS Menschen im agilen Prozess wandert an den Beginn der Prozesskette. Er arbeitet z.B. bei der Definition der Stories mit. Zu dem Thema gibt es einen guten Wikipediaeintrag. Ich empfehle ihn zu lesen.

  2. Testmanagement in agilen Projekten ist leider noch nicht so klar wie es bei konventionellen Methoden (V-Modell / Wasserfall) ist. Danke hier mal eine Interessante Variante zu lesen. Wobei es hier ja eher um eine Idee geht, das agile Testmanagement und die Absprachen inhaltlich durch das Arbeitsdokumentes zu verbessern.

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*