In der Schweiz werden rund die Hälfte der IT-Projekte mit agilem Projektvorgehen entwickelt (siehe SwissQ Trends und Benchmark). Aus Testsicht stellt sich hier die grosse Herausforderung, dass die Funktionalität schrittweise getestet wird, sich viel ändert und daher ein hohes Maaß an Regressionstest durchgeführt werden müssen – wofür aber kein Budget zur Verfügung steht.
Die folgende Grafik verdeutlicht dies: Im Beispiel werden nach einer Vorbereitungsphase (oder einem Sprint null) drei normale Sprints durchgeführt, gefolgt von einer Abnahme (bzw. Sprint vier). Der Tester im Team hat eine gewisse Kapazität, die hoffentlich für den Test der aktuell umgesetzten Arbeitspakete reicht – aber sicher nicht, für die Durchführung aller Tests aller bereits erstellten Pakete. Entsprechend entsteht ein Risiko, welches im Laufe des Projektes wächst.
Der Tester im Team hat eine gewisse Kapazität, die hoffentlich für den Test der aktuell umgesetzten Arbeitspakete reicht – aber sicher nicht, für die Durchführung aller Tests aller bereits erstellten Pakete. Entsprechend entsteht ein Risiko, welches im Laufe des Projektes wächst
Ein Blick in einen Sprint zeit grob folgende Test-Tätigkeiten des Embedded Testers (Management, Testfallerstellung, etc. hier der Einfachheit halber mal aussenvorgelassen). Typischerweise gliedert sich der manuelle Testaufwand in Regressionstest, Systemstest und explorative Tests auf. Die Automatisierung von Systemtests und explorativen Tests ist wenig sinnvoll. Damit der manuelle Testaufwand trotzdem reduziert werden kann liegt die Lösung in der Automatisierung der Regressionstests.
Manuelle Test-Tätigkeiten während eines Sprints
Nur wenn die Regressionstests (zu einem hohen Grad) automatisiert werden, kann der Berg an Regressionstests bewältigt werden. Gleichzeitig gibt dies dem Tester die Möglichkeit, seinen Mehrwert gegenüber der Maschine, seine Erfahrung und Intuition, bei den explorativen Tests gewinnbringend einzusetzen. Somit ergibt sich eine Verschiebung der Testaufgaben, wie in der folgenden Grafik dargestellt.
Testautomatisierung der Regressionstests in agilen Projekte
Diese Erkenntnis ist nicht neu, basiert doch schon das Prinzip von XP darauf, dass alle Funktionen mit automatischen Tests abgesichert sein müssen:
- All code must have Unit tests
- All code must pass all Unit tests before it can be released.
- When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic, it is a test you forgot to write)
- Acceptance tests are run often and the results are published
[https://en.wikipedia.org/wiki/Extreme_programming#Testing_2]
In der Praxis wird häufig ein Spezialist für Testautomation (zu N-%) in das Projekt mit einbezogen und übernimmt die Aufgabe der Automatisierung. Die Finanzierung hierfür muss vom PO/PL/Auftraggeber entsprechend beurteilt und freigegeben werden.
Das diese Erkenntnis auch bei den Unternehmen angekommen ist, spiegelt sich in unserem aktuellen Trendwave Report wieder Die Investitionen in Testautomatisierung nehmen, wie auch schon in 2012, weiter zu und die Bedeutung von Regressionstests steigt. Auch wenn die weit verbreitete Methodologie Scrum sich zum Thema Test weitgehend ausschweigt, in der Praxis ist die Notwendigkeit angekommen. Auch die folgenden Plätze Testdaten und Testumgebungen sind Themen, deren Beherrschung zwingende Voraussetzungen für den erfolgreichen Einsatz von Testautomation sind.
Die Investitionen in Testautomatisierung nehmen, wie auch schon in 2012, weiter zu
Der Beitrag hat aufgezeigt, dass agile Projekte den Einsatz von Testautomation zur Beherrschung der Risiken von Fehlern benötigen. In einem folgenden Beitrag werden wir darauf eingehen, welche Arten von Tests sich besonders für den Einsatz von Testautomation in agilen Projekten eignen – und welche eher nicht.