5 min read
Entspannt & glücklich auf Arbeit: 5 Tipps, um die Stimmung zu heben
Wenn die Tage wieder dunkler werden, geht das oft auch auf die Stimmung, da der Mangel an Sonnenlicht das Level vom...
5 Minuten Lesezeit
Projektmanagement-Expertin Wiebke Bergholz erklärt, was Testmanagement ist, wie es aufgebaut ist und warum es ein wichtiger Bestandteil des agilen Projektmanagements ist.
Inhalt:
- Testmanagement vs. Qualitätssicherung
- Ziele des Testmanagements
- Die vier Teststufen in Softwareprojekten
- Fehlerkosten: Die Zehnerregel
- Wie Testmanagement in agilen Projekten funktioniert
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 Anwender:innen und Entwickler:innen. 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.
Test management vs. quality assurance
Nicht zu verwechseln ist das Testmanagement mit der Qualitätssicherung. Häufig werden beide Begriffe 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 von den Entwickler:innen 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 die Kund:innen bzw. Anwender:innen dar. Vor Inbetriebnahme des Systems erfolgt somit ein abschließender Test.
Die Zehnerregel der Fehlerkosten
Die Zehnerregel der Fehlerkosten sagt aus, dass die Kosten zur Behebung eines Fehlers exponentiell 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 Kund:innen 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 Entwickler:innen und den Tester:innen. 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 den Anwender:innen 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 Satus 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 bieten Ihnen Managed Services und Technology Services, um Ihre Softwareprojekte zu realisieren, innovative Lösungen und Anpassungen zu entwickeln und Themen wie Cyber Security und Wartung zu unterstützen.
Share:
