Qualitätsmanagement als Lifecycle-Disziplin

Produkte und Dienstleistungen werden immer intelligenter und die Innovationszyklen verkürzen sich. Das Risiko, dass Fehler in der Programmierung gravierende Auswirkungen haben können, steigt rasant. Dabei ist es ein gravierender Unterschied, ob ein Softwarefehler bewirkt, dass eine Layoutfunktion in einem Textverarbeitungsprogramm nicht funktioniert, oder ob er dazu führt, dass sich ein Flugzeug nicht mehr sicher landen lässt.
Software etabliert sich immer mehr zu einem unentbehrlichen Baustein der heutigen Zeit. In gleichem Maß steigt die Komplexität intelligenter Produkte und Systeme. Zudem zeigt sich eine noch nie dagewesene Konnektivität zwischen Systemen, Prozessen und Infrastruktur. Daraus ergeben sich weitreichende Konsequenzen für eine wirksame und gleichzeitig wirtschaftlich vertretbare Qualitätssicherung. Eine Untersuchung von Capers Jones vom August 2011 belegt, dass Software mehr wirtschaftliche Probleme verursacht als jedes andere von Menschen hergestellte Produkt. Weiterhin stellt das Marktforschungsinstitut fest, dass unzureichende Softwarequalität für hohe Verluste verantwortlich ist: jedes Jahr geschätzt über 500 Milliarden US-Dollar weltweit. Qualität kann jedoch nicht nachträglich in ein Produkt hineingetestet werden. Dennoch wird in vielen Projekten ein sehr eingeschränktes Verständnis von Qualitätsmanagement deutlich. In der Testphase zwischen Entwicklungs- und Produktfreigabe scheint es eine Art Naturgesetz zu sein, dass sich der erste Zeitpunkt nach hinten verschiebt, während der Zeitpunkt der Marktfreigabe unverrückbar in Stein gemeißelt ist, sodass für die Tests immer weniger Zeit bleibt.

Vom Test zum Application Lifecycle Management

Unter ‚Testen‘ ist die technische Untersuchung des Prüfgegenstandes zu verstehen mit dem Ziel, qualitätsrelevante Informationen zu erheben. Mehr Testen bedeutet jedoch zunächst nur, dass man mehr Fehler findet; eine Verbesserung der Qualität ist damit noch nicht erreicht. Allerdings umfasst Qualitätsmanagement nicht nur Tests, sondern auch, dass Qualität bereits während des Entstehungsprozesses in ein Produkt eingebracht wird. Dadurch lässt sich im besten Fall verhindern, dass Fehler überhaupt entstehen. In dem Maße wie ein Unternehmen einen gewissen Reifegrad erreicht und dabei die Softwareentwicklungsprozesse definiert, verfeinert und optimiert, setzt sich die Erkenntnis durch, dass Tests nicht alles sind, um ein akzeptables Qualitätsniveau zu erreichen. Abbildung 1 zeigt ein übliches Reifegradmodell mit fünf Stufen von chaotisch bis optimiert. Im oben genannten Beispiel befindet sich ein Unternehmen etwa im Übergang von Stufe 2 zu Stufe 3. Hier tritt erstmalig der Teamgedanke auf. Denn wirksame Qualitätssicherung bedarf effektiver Zusammenarbeit. Mit einer Application Lifecycle Management-Umgebung (ALM) erhalten Teams vielfältige Möglichkeiten, gemeinsam an Aufgaben zu arbeiten, Schnittstellenprobleme zu minimieren und Grenzen zwischen Entwicklungsdisziplinen zu überwinden. Eine zukunftsfähige ALM-Umgebung sollte dabei so angelegt sein, dass sie eine Organisation beim Erreichen der nächsthöheren Stufe im Reifegradmodell unterstützt. Dabei sollte sie Unternehmen ab jeder der fünf Stufen begleiten.

Teamarbeit ermöglichen

Allerdings erweist es sich als schwieriger, die notwendige Qualität einzubauen, wenn gleichzeitig immer weniger Zeit dafür zur Verfügung steht. Agile Ansätze bieten eine Möglichkeit, diesen Konflikt zu lösen. Diese Ansätze berücksichtigen gleichzeitig die gängigste Definition von Qualität: Die Idee, genau das zu liefern, was Kunden erwarten. Dies erreichen Entwickler, indem sie in kurzen Abständen (Iterationen) überprüfen, ob sich die Entwicklung in diese Richtung bewegt, mit dem Ergebnis, dass das Produkt exakt den Anforderungen entspricht. Das Application Lifecycle Management koordiniert die Aktivitäten und Artefakte des Entwicklungszyklus, von den Anforderungen über Design und Entwicklung, Projektmanagement, Änderungs- und Konfigurationsmanagement bis hin zum Qualitätsmanagement. ALM bietet eine Möglichkeit, verteilte Arbeitsgruppen und Disziplinen in einem Projektteam zusammenzubringen. Dazu benötigen Unternehmen jedoch die passenden Werkzeuge, um das notwendige Maß an Zusammenarbeit zwischen Spezialisten und Lokationen zu erreichen. Für ein durchgängiges Qualitätsmanagement ist zudem jeder der fünf sogenannten ALM-Imperative relevant: Zusammenarbeit im Kontext, Real-time Planung, Verfolgbarkeit über den gesamten Lebenszyklus, Entwicklungsintelligenz und Kontinuierliche Verbesserung.

Anforderungen exakt definieren

Die Definition und das Management von Anforderungen sind entscheidende Voraussetzungen dafür, dass ein Projekt den Bedarf der Kunden erfüllt, dem Vertrag entspricht und sich innerhalb des geplanten Zeit- und Kostenrahmens durchführen lässt. Eine schlecht beschriebene Anforderung kann verheerende Auswirkungen haben: zeitaufwendige Nacharbeiten, unzulängliche Lieferungen, Überschreitungen des Budgets und Probleme bei der Konformität können die Folge sein. Die besten Anforderungen sind solche, die technisch möglich, rechtlich zulässig, vollständig beschrieben und präzise formuliert sind. Sie sind konsistent und widersprechen sich nicht. Zugleich sind sie in der Lage, ein eindeutiges Kriterium für die Erfüllung dieser Anforderung zu definieren, so dass für jede Anforderung ein Test formuliert werden kann. Anhand dessen muss sich zweifelsfrei feststellen lassen, ob diese Anforderung erfüllt ist oder nicht. Jede Anforderung sollte eindeutig identifiziert und somit über den ganzen Prozess verfolgt werden können. Anforderungen sollten unabhängig vom Design sein; sie sollten die Erwartungshaltung definieren, ohne eine konkrete Umsetzung zu präjudizieren.

AIterativen Plan gemeinschaftlich fortschreiben

Verifikation und Validierung dienen der Überprüfung und dem Nachweis, dass Entwurf, Entwicklung, Test und Auslieferung des Projektergebnisses in jeder Hinsicht den Anforderungen entsprechen. Testmanagement und Projektplanung sollten im Idealfall vom gesamten Team gemeinschaftlich getragen werden. Wenn Entwickler nur für sich selbst planen und parallel Tester ihre eigenen Pläne erarbeiten, besteht ein hohes Risiko, dass Pläne divergieren und sich ggf. sogar gegenseitig blockieren. Ein gemeinsamer großer ‚Big Bang‘-Plan, der einmal zu Anfang des Projektes aufgestellt wird, birgt jedoch die Gefahr, dass er sich während des Projektverlaufs nicht mehr sinnvoll realisieren lässt, so dass ein gewisses Planungsvakuum entstehen kann, in dem dann verschiedene Planvarianten gebildet werden. Diese Szenarien kann ein iterativer Plan verhindern: Er ist mit den Projektiterationen synchronisiert und wird gemeinschaftlich fortgeschrieben. Er erfordert weniger Overhead und benötigt weniger Annahmen über den zukünftigen Projektverlauf. Dieser Plan ist ausführbar, weil er nichts fordert, was zum Zeitpunkt der Planung noch nicht vorausgesehen werden konnte. Dem Team bleibt zudem genügend Zeit, das Ergebnis der aktuellen Iteration zu untersuchen und gefundene Fehler zu beseitigen.

Dynamische Sicht zeigt Versionen und Testergebnisse

Der Schlüssel zur funktionierenden Testplanung ist die Zusammenarbeit und die Transparenz über das gesamte Team. Daher bietet der Testplan eine dynamische Sicht, die Mindestanforderungen definiert und die Ausführung der Testaktivitäten mit der Planung und aktuellen Ergebnissen verknüpft. Damit liefert dieser Plan eine Art Dashboard, in dem alle Kriterien klar und eindeutig definiert sind und vom gesamten Team eingesehen und verwendet werden können. Alle Projektmitarbeiter orientieren sich an denselben Zielen, und alle Stakeholder haben Zugriff auf den aktuellen Status in Realzeit. In einer ALM-Umgebung geschieht dies, ohne dass die die Spezialisten ihre gewohnte Tool-Umgebung verlassen müssen. So können beispielsweise Tester aus ihrem Werkzeug heraus von einem Testfall per Verknüpfung auf die dazu gehörende Anforderung zugreifen, um mehr über Hintergründe und Intention zu erfahren, was wiederum für die Testgestaltung relevant sein kann. Tester können dabei davon ausgehen, die jeweils aktuelle Version der Anforderung vorliegen zu haben. Umgekehrt können Anforderungsanalysten von einer spezifischen Anforderung per Verlinkung auf die zugehörigen Testsequenzen zugreifen und auf einen Blick sehen, welche Tests mit welchem Resultat bereits ausgeführt wurden. Alle diese Informationen stehen dem gesamten Team in Echtzeit und innerhalb ihres vertrauten Werkzeuges zur Verfügung.

Virtualisierung der Testumgebung

Als weiteres Problem zwischen Entwicklungs- und Testteam zeigt sich häufig, wenn das Testteam nicht genügend Zeit hat, notwendige Vorbereitungen für einzelne Testläufe zu treffen, während in den Entwicklungsbereichen fleißig Code geschrieben wird. Wenn es bspw. drei Tage dauert, um eine spezifische Testumgebung aufzusetzen, gerät der Testablauf damit um die selbe Zeit in Rückstand. Umso enttäuschender ist es, wenn sich dann nach drei Tagen herausstellt, dass der Prüfling noch weit davon entfernt ist, auch nur die ersten Testsequenzen zu überstehen. Ein Teufelskreis entsteht: die Lücke zwischen Entwicklung und Test wird immer größer und führt schlussendlich zu Qualitätseinbußen. Die größte Hürde, die eine engere Synchronisation zwischen Entwicklung und Test verhindert, ist die Zeit, die erforderlich ist, um eine spezifische Testumgebung aufzusetzen. Wenn es gelingt, diese Setup-Zeiten zu verkürzen, könnten Tester mehr Zeit mit sinnvollen Tätigkeiten verbringen und vielleicht sogar im Einklang mit dem Entwicklungsfortschritt arbeiten. Einen Weg zu kürzeren Setup-Zeiten bietet die Virtualisierung der Testumgebung. Denn das größte Problem beim Testaufbau sind die vielfältigen Systemabhängigkeiten, die jeweils spezifische Hardware, Systeme oder Fachkenntnisse erfordern, die dem Testteam möglicherweise gar nicht zur Verfügung stehen und erst beschafft werden müssen. In einer virtuellen Testumgebung hingegen lässt sich das Verhalten einer Applikation vollständig simulieren. Dabei kann dieses virtuelle Testbett grundsätzlich in einer beliebigen Umgebung laufen, auf einer vorhandenen Hardware sowie in einer Private oder Public Cloud. Jeder Mitarbeiter kann mit seiner eigenen Testumgebung arbeiten, ohne dass die Systeme physikalisch mehrfach vorhanden sein müssen. Aus einem relativ unübersichtlichen Szenario wird eine klar strukturierte und mit wenig Aufwand konfigurierbare virtuelle Testumgebung für die ganze Organisation. Ein weiterer Vorteil der Virtualisierung besteht darin, dass virtuelle Komponenten nach und nach mit realen Komponenten kombiniert werden können, um beispielsweise Integrationstests bereits zu einem frühen Zeitpunkt im Projekt zu ermöglichen. Mithilfe einer virtuellen Testumgebung können Verifikation und Validierung parallel zur Entwicklung stattfinden und lassen sich mit dem Entwicklungsfortschritt eng synchronisieren. So verkürzen sich Wartezeiten im Projekt und die Projektlaufzeit insgesamt. Das hier skizzierte Qualitätsmanagement erfordert klar definierte Prozesse mit Übergabepunkten, Schnittstellen und organisatorischen Abläufen, die dem Team vertraut sind und deren Notwendigkeit akzeptiert wird. Eine geeignete Tool-Umgebung kann viel dazu beitragen, dass die Qualitätssicherungsmaßnahmen wie erforderlich durchgeführt werden, ohne dass Teams mit administrativem Mehraufwand belastet werden. Abbildung 5 zeigt exemplarisch, welche Bereiche im Qualitätsmanagement durch IBM Rational Produkte für Qualitätsmanagement abgedeckt werden.