Fokus auf eine Aufgabe und der Abbau von Altlasten

DSDM Atern ermöglichte dem Unternehmen, sich auf neue Entwicklungen zu konzentrieren und Zeit für High-Interrupt-Arbeit einzuplanen. Zuvor konnten die Teams nur selten ungestört an einem Projekt arbeiten; vielmehr wurde die Arbeit an Neuentwicklungen ständig durch Fehler, Vertriebsfragen und Infrastrukturprobleme unterbrochen. Es musste eingeplant werden, dass manche Fehler naturgemäss erst im Echtbetrieb beim Kunden entdeckt werden und dann umgehend behoben werden müssen. Gleichzeitig sollte Zeit für notwendige Verbesserungen der Betriebseffizienz eingeplant werden, damit die Entwicklungsarbeit möglichst ungestört und ohne Unterbrechungen voranschreiten kann.

DSDM Atern stellte Konzepte zur vollständigen Behebung des Testabdeckungsdefizits innerhalb von drei Versionen bereit. Im Vorjahr war es dem QC-Team nicht gelungen, auch nur eine Lücke in seinen Testautomatisierungs-Skripten zu schließen. Das Unternehmen wusste, dass die Produktqualität durch rechtzeitige und gründlichere Abdeckung der Testautomatisierung verbessert werden musste. Dies ist in der Tat ein wesentlicher Punkt für die Förderung von Integration und kontinuierlichen Tests.

1. Einführung von Regression und Timeboxen zur Qualitätssicherung

In der agilen Methodik von DSDM Atern besteht ein Release aus einer Reihe von Timeboxen. Normalerweise wird eine neue Funktionalität innerhalb einer Timebox fertiggestellt. Für einen Software-Anbieter, der Lieferzyklen einzuhalten hat und es einer Vielzahl an Kunden recht machen muss, ist dies aus zwei Gründen nicht ideal: (a) In der Realität konzentrieren sich die Entwickler auf neue Funktionen und nicht auf Fehlerbehebung und deshalb werden Fehler erst beseitigt, wenn die Situation eskaliert und (b) die gesamte Produkt-Suite wird nie als Ganzes getestet.

Der erste Teil der Lösung war, schon zu Beginn einer Release eine Timebox für Qualitätssicherung einzuplanen; also einen Zeitraum, in dem keine weiteren Funktionen entwickelt werden, sondern frühere Fehler aufgespürt und behoben werden können. Diese Fehler haben in der Regel zwei verschiedenen Ursachen, wie in der folgenden Tabelle ersichtlich ist:

Auch andere lang überfällige Betriebsverbesserungen wie Software-Aktualisierungen in der Entwicklungsumgebung, neue Erstellungsprozesse, Hardwareaktualisierungen oder auch Fortbildungen können während der Qualitätssicherungs-Timebox durchgeführt werden. Insgesamt ist diese Timebox der richtige Zeitpunkt für alle Aktivitäten, die nicht direkt mit der Entwicklung neuer Software zu tun haben und die ansonsten von der Entwicklungsarbeit ablenken würden.

Der zweite Teil betrifft die Einführung einer Regressions-Timebox, dem letzten Abschnitt eines Release. Ebenso wie in der Qualitäts-Timebox, werden auch hier keine neuen Funktionalitäten entwickelt; (diese sollten zu diesem Zeitpunkt bereits funktionieren, denn gemäß dem 4. Prinzip werden bei der Qualität niemals Kompromisse gemacht), so dass sich das ganze Unternehmen darauf konzentrieren kann, das Produkt als Ganzes zu testen und seine Robustheit auszuweiten.

Außerdem möchte kein Team in der Position sein, neue Funktionen weiter zu testen, weil sie die Hilfe von anderen Teams benötigen - es wird also ein gesunder Wettbewerb zwischen den Teams entstehen. Gleichzeitig kann ein Release-Kandidat (ein sogenanntes Beta-Release) eingesetzt werden, damit der Kunde sich mit der neuen Version vertraut machen kann, Probleme so schnell wie möglich behoben werden und die neuen Funktionalitäten in Webinaren demonstriert werden können.

Entsprechend dem Grundsatz, dass neue Funktionalitäten nicht erst beim Release vorgestellt werden, sind die Wirtschaftsanalysten in jedem Team dafür verantwortlich, die innerhalb einer Timebox verwirklichten neuen Funktionen persönlich oder per Webinar zu demonstrieren. Indem die Kunden und das Unternehmen konsequent einbezogen wurden, wurde erreicht, dass die Kunden die Software schneller als zuvor haben wollten. Das ist fabelhaft, denn so kann sich der Kunde schon viel früher mit dem Produkt vertraut machen und Probleme früher denn je zuvor mitteilen, wodurch die Produktseinführungszeit reduziert wird.

Mit der Kombination der beiden Timeboxen Regression und Qualitätssicherung wird ein längerer Zeitraum zur Verfügung gestellt, in dem die Architekten und Geschäftsführer den “Product Visionary“ bereits mit der Ausarbeitung des PRL für die nächste Version beauftragen können.

Die Einführung der Regressions- und Qualitäts-Timeboxen hatte eine beeindruckende und positive Wirkung auf die Statistik offener Fehler. Die HedgeSphere Product Suite umfasst über 75 Mannjahre. Transparenz ist wichtig, deshalb enthält diese Abbildung sowohl die von Kunden berichteten als auch die bei internen Tests festgestellten Fehler. Die Grafik wurde mittels JIRA erstellt.

Im April 2010 wurden bei einem Release ausschließlich Regressionstests durchgeführt. Dadurch vervielfachte sich ganz einfach die Zahl der festgestellten Fehler - eine gute Sache - und die Zahl der behobenen Fehler erhöhte sich entsprechend. Doch erst die Einführung der Qualitäts-Timebox brachte die Wende und führte dazu, dass mehr Fehler behoben wurden, als zuvor entdeckt worden waren.

Systematisch und kontinuierlich Fehler beheben zu können, noch ehe sie gemeldet werden, gibt dem ganzen Unternehmen beachtlichen moralischen Auftrieb: Das Gefühl der Frustration verschwindet auf allen Ebenen; stattdessen wird noch mehr Energie freigesetzt, die nun in die Entwicklung neuer Funktionen und den daraus resultierenden Innovationen fließt.

2. Automatisierte Testabdeckung

Auf Unternehmensebene können Kundenreferenzen ein größeres Problem darstellen, wenn das Produkt voller Fehler steckt. Die Notwendigkeit, den Trend umzukehren, liegt auf der Hand. Fehler müssen möglichst frühzeitig aufgespürt werden. Deshalb werden alle automatisierten Tests durchgehend wiederholt, um Fehler noch am selben Tag zu finden, an dem sie eingebaut wurden. Allerdings kann es vorkommen, dass nicht alle neuen Fehler durch die automatisierten Tests erfasst werden. Diese "Lücken" mussten geschlossen werden, was in fünf Phasen geschah:

1. Die Identifikation von wichtigen Funktionen in älteren Versionen, die keine End-to-End-Business-Testfälle hatten.
   
   
   
2. Bei allen folgenden Regressions-Timeboxen wurde jedem Mitarbeiter als „Must“ aufgetragen, einen bestimmten Teil der noch nicht getesteten Funktionen manuell zu testen und ferner als „Should“ das Test-Skript und als „Could“ die entsprechende Automatisierung zu schreiben. Folgendes konnte bei Infonic in allen folgenden Regressionstest-Timeboxen beobachtet werden:
   
   Während der ersten Regressionstest-Timebox wurden alle Funktionalitäten manuell getestet, einige manuelle Test-Skripte wurden geschrieben und ein paar wurden sogar automatisiert. Die manuelle Test-Skripte konnten in der Regressions-Timebox der folgenden Release wiederverwendet werden.
   
   In der nächsten Regressions-Timebox wurden weitere manuelle Test-Skripte aus der vorangegangen Timebox automatisiert und eine Reihe von Lücken wurde durch manuelle Test-Skripte abgedeckt.
   
   Dieser Prozess wird so lange wiederholt, bis die Lücke geschlossen ist. Erstaunlicherweise konnte Infonic seine Lücke innerhalb von drei Timeboxen schliessen. Das heisst, dass die manuelle Arbeit Leistung reduziert und die Automatisierung erhöht wird.
   
   
   
3. Sorgen Sie dafür, dass die Reihenfolge der automatisierten Tests konfigurierbar bleibt. Die schwierigsten Bereiche werden immer so konfiguriert, dass sie gleich zu Anfang getestet werden, damit die Entwickler möglichst frühzeitig ein Feedback erhalten.
   
   
   
4. Sobald alle Funktionen mindestens ein Mal automatisch getestet wurden, werden weitere hingefügt, wobei wiederum die problematischen Bereiche zuerst bearbeitet wurden.
   
   
   
5. Fügen Sie nicht-funktionale Testfälle wie Systemleistungs- und Lasttests hinzu.
   
   
   

Da Atern keine qualitativen Kompromisse zulässt, wird die „Lücke“ niemals größer. Neue Funktionalität wird immer mit automatisierten End-to-End-Testfällen geliefert. Diese End-to-End-Testfälle werden als Teil der “Foundation Phase” der DSDM Atern Methodik zur Verfügung gestellt. Eine Folge dieser Arbeitsweise war eine beträchtliche Effizienzsteigerung im Engineering, da Nebenerscheinungen schon während der Entwicklung behoben werden konnten, statt Wochen oder Monate später, wie es früher üblich gewesen war.

Der Aufwand lohnt sich

Doch letztendlich sind es die Kunden, die am meisten profitieren: Ein wichtiger Kunde berichtete, dass die Fehlerquote eines Produkts während seiner Regressionstests-Kampagne um 76 Prozent zurückging, wie in der Bildergalerie dargestellt wird.

Der leichte Anstieg von Q1 2010 auf Q3 2010 liegt in der Tatsache begründet, dass der Kunde gründlicher und umfassender als für diesen Zeitraum vorgesehen war testen konnte.