Anforderungs-, Qualitäts- und Testmanagement in agilen Projekten

Erweiterte Scrum-ProzesseDie Agilen Methoden gewinnen in der heutigen Softwareentwicklung immer mehr an Bedeutung. Sie sind die Antwort auf die sich schnell ändernden oder anfangs unvollständigen Anforderungen an die Software. Das „Agile Manifesto“ empfiehlt ein leichtgewichtiges Vorgehen. Eine prominente und weit verbreitete agile Methode ist Scrum. Dabei wird mit Hilfe von selbstorganisierenden Teams in kurzen Iterationen (1 bis 4 Wochen Sprints) der gesamte Lebenszyklus von Software-Entwicklungsprozessen wiederholt durchlaufen und damit die Software schrittweise über lauffähige Zwischenstände (Inkremente) zum auslieferbaren Produkt entwickelt.

Die kurzen Entwicklungsiterationen bringen für den gesamten Lebenszyklus Herausforderungen mit sich. Für agile Entwicklung angepasste Konzepte für Anforderungsmanagement (AM), Testmanagement (TM) und ein durchgängiges Qualitätsmanagementkonzept (QM), die den gesamten Lebenszyklus abdeckt, sind Schlüssel für ein effektives und effizientes Projektmanagement bei agilen Projekten. Abbildung 1 zeigt einen erweiterten Scrum-Prozess, der den Entwicklungs-Lebenszyklus und dazu gehörige Management-Maßnahmen veranschaulicht.

Anforderungsmanagement

Während eines initialen Planungssprints werden die Produktvision und Anforderungen an das zu entwickelnde Softwareprodukt mit Hilfe eines AM-Konzeptes aufgenommen und in einem Produkt-Backlog in Form einer Makro-Planung gespeichert. Dabei erstellt ein Business-Analyst eine Ist- und Anforderungs-Analyse mit dem Kunden (Endnutzer, Produkt-Owner). Die Ergebnisse dieser Analyse werden in einem Produkt-Backlog dokumentiert, welches grob die funktionalen Anforderungen und den gewünschten zeitlichen Fortschritt in der Realisierung der Anforderungen spezifiziert. Das AM-Konzept muss in dem Planung-Sprint sicherstellen, dass die Anforderungen wenn auch grob, thematisch vollständig dokumentiert, priorisiert und ihre Entwicklungs-Aufwände geschätzt sind.

Nach dem Planungssprint starten die Entwicklungssprints, die je nach Projektkontext 1-4 Wochen dauern können und n-mal durchlaufen werden. Das Ziel eines Sprints ist es, Anforderungen aus dem Produkt-Backlog innerhalb eines Sprints zu einem lauffähigen Inkrement zu entwickeln, so dass der Kunde eine Rückmeldung nach jedem Sprint geben kann. So ein Entwicklungssprint durchläuft den gesamten Lebenszyklus: In der Sprint-Planung wird eine überschaubare Menge aus den priorisierten und aufwandgeschätzten Anforderungen aus dem Produkt-Backlog ausgewählt und im Sprint-Backlog gespeichert. Das AM-Konzept muss sicherstellen, dass die ausgewählten Anforderungen gemeinsam mit dem Kunden und den Entwicklern verfeinert werden, so dass die Anforderungen im Detail verstanden und die technische Machbarkeit und die notwendigen Entwicklungsaktivitäten abgestimmt werden. Auch die Tester müssen in diese Phase einbezogen werden, um die Testbarkeit und die Abnahmekriterien für die Anforderungen mitzubestimmen. 

Testmanagement

Burndown-Chart für AnforderungenDie verfeinerten und mit den Entwicklern abgestimmten Anforderungen aus dem Sprint-Backlog sollen innerhalb eines Sprints entwickelt und zu einem lauffähigen Inkrement überführt werden. Ein Erfolgsfaktor für agile Entwicklung ist die Continuous Integration (CI), die sicherstellt, dass die Entwicklungsergebnisse täglich in einem zentralen Repository gesammelt werden, die vordefinierten Qualitätserwartungen erfüllen, kompilierbar sind und grundsätzliche Entwicklertests erfolgreich durchlaufen haben. Neben den Entwickleraktivitäten muss ein TM-Konzept auch auf die Endnutzer-bezogenen Tests fokussieren und den fachlichen Testern eine methodische Unterstützung beim Testen anbieten.

Die fachlichen Tester sollen sowohl die Entwicklungssprints begleiten und die Ergebnisse jedes einzelnen Sprints prüfen (Sprint-Tests), als auch am Ende der Entwicklungsphase einen dedizierten Abnahmetest (User Acceptance Test) durchführen. Bei diesen Testphasen sollen für einzelne Anforderungen Testfälle mit einer Testablaufbeschreibung und mit dazu gehörigen Testdaten definiert werden.

Idealerweise sollen die Testfälle neben den erwünschten Szenarien (Positiv-Testfälle) auch unerwünschte oder unvorhersehbare Szenarien (Negativ-Testfälle) berücksichtigen. Wenn ein Testfall fehlschlägt, ist eine aussagekräftige Fehlerbeschreibung notwendig, so dass die Entwickler den Fehler reproduzieren, die Fehlerursache identifizieren und den Fehler beheben können.

Das TM-Konzept muss sicherstellen, dass die Abnahmetests einen besonderen Fokus auf das Zusammenspiel zwischen beteiligten Softwaresystemen (End-to-End-Tests) und auf das Testen von nicht-funktionalen Anforderungen (NFRs) legen. Zu wichtigen NFRs gehören neben Sicherheits- und Performanzanforderungen auch die Usability-Anforderungen, die sicherstellen, dass die Endnutzer das Softwareprodukt auch entsprechend ihrer fachlichen und persönlichen Bedürfnisse einsetzen können.

Qualitätsmanagement

Während die AM- und TM-Konzepte konstruktive Maßnahmen aus Sicht des Projektmanagements beschreiben, definiert das QM-Konzept analytische Maßnahmen für das Projektmanagement. Dabei sollen die Qualität der durchgeführten Aktivitäten (Prozessqualität) und die Qualität der zu entwickelnden Software (Produktqualität) gemessen und mittels Reporting sichtbar gemacht werden. Ein oft vernachlässigter Qualitätsaspekt ist die Testqualität, die die Messung der Produktqualität überhaupt möglich macht, denn die Produktqualität ist nur so gut messbar wie die Testqualität es ermöglicht.

Cumulative-Flow-Chart für Testfälle Für das QM in agiler Entwicklung bieten sich leichtgewichtige Metriken, die eine Momentaufnahme der Qualität darstellen und anschauliche Grafiken, die den Fortschritt der Entwicklungsaktivitäten veranschaulichen an. 

Ein Burnddown-Chart für Anforderungen veranschaulicht die Relation zwischen dem idealen und dem tatsächlichen Arbeitsfortschritt. Die gestrichelte graue Linie (Ideal) in der Abbildung 2 zeigt, wann wie viele Anforderungen (Issues) idealerweise abgearbeitet werden müssten, damit am Ende eines Sprints alle Aufgaben erledigt sind. Die blauen Linien (Actual und Total) zeigen die tatsächlich abgearbeiteten Aufgaben. Die Differenz zwischen der idealen und tatsächlichen Linien zeigt, wie viele Anforderungen noch offen sind und auch eine Tendenz, wie realistisch es ist, unter Betrachtung des bisherigen Fortschritts eine vollständige Erledigung der Anforderungen am Ende des Sprints zu erwarten. Je näher die Total-Linie zur Ideal-Linie verläuft, desto besser ist die Prozessqualität.

Eine weitere Grafik ist das Cumulative-Flow-Chart für Testfälle, die zeigt, wie sich die Testfälle entwickeln. Die neu definierten Testfälle (Status: New) müssen mit der Zeit abgearbeitet werden und die Abarbeitung muss in ihrer Statusänderung sichtbar werden. Am Ende bestimmt das Verhältnis zwischen den bestandenen Testfällen (Status: Closed) und den fehlgeschlagenen Testfällen (Status: Failed) definiert die Produktqualität. Die Testqualität wird durch das Verhältnis zwischen den Anforderungen und den Testfällen folgendermaßen gemessen: die Testqualität ist nur so gut, wie die Abdeckung der Anforderungen durch die Testfälle (sowohl Positiv- als auch Negativ-Testfälle).

Referenzen

  • Baris Güldali, Masud Fazal-Baqie: Skalieren von großen agilen Projekten mit verteilten Backlogs. OBJEKTspektrum Online Themenspecial Agiltiy 2015
  • Silke Geisen, Baris Güldali: Agiles Testen in Scrum – Testtypen und Abla¨ufe. OBJEKTspektrum Online Themenspecial Agility 2012

Dr. Baris Güldali

Dr. Baris GüldaliDr. Baris Güldali ist Senior Researcher im s-lab – Software Quality Lab an der Universität Paderborn. Seine Arbeitsschwerpunkte sind Anforderungs- und Testmanagement. Nach dem Studium zum Bachelor of Computer Engineering an der Middle East Technical University in Ankara arbeitete er als Software-Entwickler in der Industrie sowie als EDV-Angestellter des Instituts für Elektrotechnik und Informationstechnik der Universität Paderborn. 2005 wechselte er an das s-lab, wo er 2014 über modellbasierte Testtechniken promovierte.

Er ist Mitglied im Leitungsgremium der Fachgruppe TAV (Test, Analyse und Verifikation von Software) in der Gesellschaft für Informatik (GI) und gleichzeitig der stellv. Sprecher des Arbeitskreises „Testen objektorientierter Programme / Model-based Testing“ (TOOP/MBT) in der Fachgruppe TAV. Seit 2014 führt er Lehrveranstaltungen im bib International College durch.

Während seiner Beschäftigung im s-lab hat er mehrere Projekte für S&N begleitet. Aktuell ist Dr. Güldali in einem S&N-Projekt im Bankenumfeld als Qualitäts-Berater tätig und für die Erstellung und Umsetzung von Konzepten für Anforderungs- und Testmanagement für agile verteilte Projekte zuständig.