Projektmanagement_Symbolbild

Im Gastbeitrag erläutert meine Kollegin Wiebke Bergholz, was man unter Testmanagement versteht, wie es aufgebaut ist und wie es sich auch in agilen Software-Projekten anwenden lässt.

In den vergangenen Jahren ist das Testmanagement ein immer wichtigerer Bestandteil von Software-Projekten geworden. Ein gesamtheitliches Testmanagement spart langfristig nicht nur Zeit und Kosten, sondern führt auch zu zufriedenen Anwendern und Entwicklern. Doch was genau versteht man unter Testmanagement und wie lässt es sich sinnvoll in agilen Software-Projekten etablieren?

Das International Software Testing Qualification Board, kurz ISTQB, definiert das Testmanagement als „Konzeption, Planung, Schätzung, Überwachung, Berichterstattung, Steuerung und Abschluss von Testaktivitäten.“ Diese Definition zeigt auf, dass sich das Testmanagement über den gesamten Testprozess erstreckt – von der Planung des kompletten Testprozesses über die Spezifikation und Durchführung der einzelnen Tests bis hin zur Dokumentation der Ergebnisse und dem gesamtheitlichen Testreporting.

Wie unterscheidet sich Testmanagement von der Qualitätssicherung?

Nicht zu verwechseln ist das Testmanagement mit der Qualitätssicherung. Häufig werden beide Bergriffe gleichgesetzt und auch wenn beide Themen eng miteinander verbunden sind, gibt es doch Unterschiede. Die Qualitätssicherung ist nicht ausschließlich für die Identifizierung und Behebung von Fehlerzuständen verantwortlich, sondern analysiert darüber hinaus die Ursachen für die Nichterfüllung von Anforderungen. Die kontinuierliche Qualitätssicherung dient der Optimierung aller Prozesse und unterstützt somit ebenfalls ein angemessen und einwandfrei durchgeführtes Testmanagement.

Ziele des Testmanagements

Eines der Ziele des Testmanagements besteht unter anderem darin, einen standardisierten Ansatz für das Testen und das Testreporting innerhalb eines Software-Projektes festzulegen. Durch ein einheitliches Vorgehen können die jeweiligen Testaktivitäten nachvollziehbarer gestaltet werden und auch ein durchgängiges Reporting kann für mehr Transparenz der Testfortschritte im Projekt sorgen.

Die Ziele des Testens selbst hängen stark von der jeweiligen Teststufe ab, in der getestet wird, d.h. von der jeweiligen Ebene der Systemarchitektur. So ist das primäre Ziel der Komponententests, so viele Fehlerzustände der jeweiligen Einzelkomponenten wie möglich zu identifizieren. Das wesentliche Ziel der Abnahmetests ist derweil, nachzuweisen, dass sowohl die funktionalen als auch die nicht-funktionalen Anforderungen der Stakeholder im Gesamtsystem umgesetzt wurden.

Die vier Teststufen in Software-Projekten

Komponententests

Die einzelnen Komponenten einer Software werden auf niedrigster Ebene der Systemarchitektur vom Entwickler selbst getestet. Es soll festgestellt werden, ob die Komponente gemäß den Spezifikationen umgesetzt wurde.

Integrationstests

Das Zusammenspiel aller Teilsysteme wird während der Integrationstests überprüft. Fehlerzustände der Schnittstellen zwischen einzelnen Komponenten sollen hierbei aufgedeckt werden.

Systemtests

Getestet wird im Systemtest das integrierte Gesamtsystem. Ziel ist es festzustellen, ob alle Funktionalitäten gemäß den funktionalen und nicht-funktionalen Anforderungen umgesetzt wurden.

Abnahmetests

Der Abnahmetest stellt die finale Abnahme durch den Kunden bzw. Anwender dar. Vor Inbetriebnahme des Systems erfolgt somit ein abschließender Test.

Laden Sie sich hier unsere Infografik zu den Teststufen in Software-Projekten zum Teilen herunter.

Laden Sie hier die Infografik herunter

Die Zehnerregel der Fehlerkosten

Die Zehnerregel der Fehlerkosten sagt aus, dass die Kosten zur Behebung eines Fehlers exponenziell steigen je später der Fehler im Projektverlauf entdeckt wird. Konkret besagt die Regel sogar, dass die Kosten eines unentdeckten Fehlers von Projektphase zu Projektphase um ein Zehnfaches ansteigen.

Das heißt auch, dass die Behebung von Fehlerzuständen, die erst während der Abnahmetests entdeckt werden, deutlich kostenintensiver ist, als wenn sie bereits während der Anforderungsaufnahme oder der Entwicklung der Software identifiziert werden.

Allein aus diesem Grund ist eine frühe Einbeziehung eines Testmanagers oder geeigneter Testressourcen sinnvoll, um mögliche Fehlerzustände bereits während der Anforderungsaufnahme zu identifizieren. Auch eine frühzeitige Berücksichtigung während der Entwicklung der Software kann dafür sorgen, dass nicht nur die Komponententests stattfinden, sondern auch rechtzeitig mit geeigneten System- und Integrationstests begonnen werden kann.

Wie Testmanagement in agilen Projekten funktioniert

Agile Software-Projekte unterscheiden sich maßgeblich von klassischen Projekten, da sie nicht nur die Bedürfnisse der Kunden immer weiter in den Mittelpunkt rücken, sondern auch durch regelmäßige Iterationen kürzere Entwicklungszyklen und häufigere Releases ermöglichen. Aus diesen Gründen ist eine enge Zusammenarbeit zwischen den einzelnen Teammitgliedern essenziell, insbesondere zwischen den Entwicklern und den Testern.

Durch die regelmäßigen Iterationen während eines agilen Projektes, müssen sowohl die Entwicklung als auch das Testen der entwickelten Komponenten kontinuierlich und in enger Abstimmung zueinander stattfinden. Die Verantwortung für die Planung und Steuerung der Testaktivitäten übernimmt hierbei oftmals das Team gemeinsam. Um eine solche Kollaboration innerhalb eines Teams zu gewährleisten, muss häufig erst ein Umdenken stattfinden. Hierbei können folgende Punkte unterstützen:

Erstellung einer Definition of Ready

Eine „Definition of Ready“ – kurz DoR – wird vom Product Owner und dem gesamten Team gemeinsam definiert und vereinbart. Die DoR ist eine Checklist mit verschiedenen Kriterien, die erfüllt sein müssen, um eine Anforderung in einen Sprint aufzunehmen. Häufig wird hierfür die INVEST-Regel verwendet:

  • Independent (unabhängig): Die Anforderung steht für sich und ist unabhängig von anderen Anforderungen.
  • Negotiable (verhandelbar): Der Inhalt einer Anforderung ist verhandelbar und wird nach und nach durch das Team im Detail beschrieben.
  • Valuable (nützlich): Die Anforderung ist sinnvoll und bietet dem Anwender der Software einen Mehrwert.
  • Estimable (schätzbar): Der Aufwand der Anforderung muss sich durch das Entwicklerteam schätzen lassen.
  • Small (klein): Der Umfang einer Anforderung sollte passend sein, sodass sie innerhalb einer Iteration bzw. eines Sprints realisierbar ist.
  • Testable (testbar): Die Anforderung verfügt über Akzeptanzkriterien und ist mithilfe dieser testbar.

Erstellung einer Definition of Done

Die „Definition of Done“ – kurz DoD – wird ebenfalls vom Product Owner und dem Team vereinbart. Die DoD besteht aus Kriterien, die erfüllt sein müssen, damit eine Anforderung als „fertig“ betrachtet werden kann. Diese Kriterien können in jedem Projektteam unterschiedlich aussehen, sollten allerdings beinhalten, welche Tests erfolgt und erfolgreich abgeschlossen sein müssen. Eine DoD hat das Ziel, ein gemeinsames Verständnis zu den Qualitätskriterien im Team aufzubauen. So kann sichergestellt werden, dass jedes Teammitglied dieselben Qualitätsziele anstrebt und weiß, welche Erwartungen an jeden einzelnen gestellt werden.

Realisierung der Testaktivitäten von Beginn an

Wie bereits erwähnt, ist eine Einbindung der Testressourcen von Beginn an in die Projekte unabdingbar. Insbesondere in agilen Projekten ist das zeitgleiche Entwickeln und Testen notwendig, um alle Kernaktivitäten innerhalb einer Iteration zu erfüllen. Der aktuelle Status der Planung, Durchführung und Steuerung der einzelnen Aktivitäten innerhalb der Iterationen muss transparent zur Verfügung gestellt werden, sodass jedes Teammitglied denselben Kenntnisstand hat. Hierfür dienen regelmäßige Statusmeetings.

Das Team als Ganzes trägt in agilen Software-Projekten die Verantwortung sowohl für die Planung, Durchführung und Steuerung aller Entwicklungs- und Testaktivitäten als auch für die transparente und angemessene Dokumentation und Kommunikation innerhalb des Projektteams. Kurzfristige Änderungen an der Software können aufgrund der kurzen Entwicklungszyklen besser berücksichtigt werden und aufgetretene Fehlerzustände können umgehend identifiziert und behoben werden. Kurz gesagt, bietet das agile Projektvorgehen vielerlei Vorteile gegenüber dem klassischen Projektansatz und auch ein ganzheitliches Testmanagement ist im agilen Umfeld realisierbar.

Wir unterstützen Sie mit modernen Projektmanagement-Methoden bei der Durchführung Ihrer CRM-Projekte. Erfahren Sie mehr.

New call-to-action

 


Wiebke_Bergholz_profilbild_swWiebke Bergholz ist Consultant bei der ec4u und fokussiert sich auf die fachliche Beratung rund um die Themen Customer Journey Management, Requirements Engineering und Testmanagement.

Vernetzen Sie sich:

LinkedIn

Xing