Testmanagement in agilen Softwareentwicklungsprojekten

Die agilen Vorgehensweisen leben von dem Grundgedanken, die Komplexität des großen Ganzen kleinteilig herunter zu brechen und in kleinen und vor allem einzelnen Schritten zu spezifizieren und umzusetzen. Für die Qualitätssicherung der dabei entstehenden Produkte trifft hierbei dasselbe wie für alle anderen Elemente zu: im Kleinteiligen wird es vermeintlich einfacher, da funktionaler und direkter beschrieben ist (siehe) bzw. getestet werden kann – idealerweise mit den betroffenen Ansprechpartner „vor Ort“ (dem Product Owner).

Dies ist jedoch ein trügerisches Bild, da nach meinen Erfahrungen übergreifende Tests – insbesondere System- und Integrationstest  aufgrund der iterativen bzw. schrittweisen Vorgehensweise (wie auch bei „klassischer Vorgehensweise“) erst gegen Ende des gesamten Erstellungszyklus erfolgen kann (wenn alle notwendigen Komponenten wie gewünscht ausgeprägt sind) bzw. zuvor aufgrund der Unvollständigkeit keine ausreichende Aussagekraft liefern.

Eine weitere kritische Einschränkung ergibt sich für übergeordnete Abnahmekriterien. Diese können bei einer agilen Vorgehensweise per se nicht zum Produktbeginn vollumfänglich feststehen, detaillieren und verändern sich im Verlauf des Projekts. Dasselbe trifft für den Scope (Lieferumfang) zu, dessen Umfang (scope fence) zu Beginn eines agilen Projekts nur undeutlich ausgeprägt ist und sich erst im Verlauf trennscharf ausprägt.

Beide Rahmenbedingungen verlangen auch beim Testmanagement in agilen Projekten nach unkonventionellen Vorgehensweisen. Für den Umgang mit einem im Projektverlauf (re-) fokussierenden Scope bedarf es weitreichender Methodik aus dem Projektmanagement (siehe). Agiles Vorgehen darf jedoch nicht darüber hinwegtäuschen – oder gar vergessen gehen lassen – dass es nach Fertigstellung und Integration aller Komponenten eines Softwareprodukts eines übergreifenden System- und Integrationstests bedarf. Hier bleibt ein wesentlicher Nachteil aus Projekten der „alten Welt“: gegen Ende des Projekts ergibt sich wie gehabt ein Hochlauf der Testaktivitäten und – auch das ist wie gehabt klassisch – der damit verbundenen Anstieg der Aktivitäten zur „Qualitätssicherung“ (mancher nennt es auch ganz ordinär „Test und Fehlerbehebung“) gegen Ende eines Softwareentwicklungsprojekts.

Dieser Beitrag wurde unter Testmanagement abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Hinterlasse eine Antwort

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

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>