Reinventing Quality

ERROR: Content Element with uid "6656" and type "dce_dceuid16" has no rendering definition!

Das Richtige früh testen mit Risiko-basiertem Testen

Das Richtige richtig zu testen, bedeutet effektiv und effizient zu testen.

Effektivität erreicht man, indem man seine QS-Aufgaben (meist Testfälle) sinnvoll auswählt und priorisiert. Die wichtigsten Tests müssen zuerst durchgeführt werden, die weniger wichtigen später oder gar nicht.

Effizienz erreicht man, indem man jeden Testfall so effizient wie möglich durchführt, d.h. Redundanzen vermeidet, den Pflegeaufwand reduziert und darauf zielt, Defekte möglichst früh zu finden.

Im konzeptuellen Rahmen des „Risiko-basierten Testens“ (RBT) wird die Wichtigkeit eines Testfalls dadurch bestimmt, dass man  ermittelt, wie hoch sein Potential ist, das zum aktuellen Zeitpunkt bestehende Gesamtrisiko zu reduzieren. Die Testfälle werden, nach abnehmendem Risikoreduktions-Potential geordnet, in eine Warteschlange sortiert und nacheinander angestoßen. Der Test-Run wird so lange durchgeführt, bis die verfügbaren Ressourcen aufgebraucht sind oder sich die Durchführung weiterer Testfälle nicht mehr lohnt.

Die RBT-Methodik eignet sich besonders für geschäftskritische Software-Projekte mittleren bis großen Umfangs, die kontinuierlich weiterentwickelt werden und einem regelmäßigen Release-Zyklus unterworfen sind.

Risiko-basiertes Testen am Beispiel des ERiC-Projektes

Der Vortrag „Das Richtige früh testen mit Risiko-basiertem Testen“ beschreibt den Einsatz der RBT-Methodik am Beispiel des ERiC-Projektes, bei dem ebenfalls „Very Early Testing“ (VET) eingesetzt wird (s. eingereichtes Tutorial “Richtig testen durch Very Early Testing“). Bei der VET-Methode wird die Entwicklungsdauer bis zum Release in mehrere Phasen eingeteilt: eine frühe „aktive Entwicklungsphase“, eine mittlere „Stabilisierungsphase“ und eine späte „Finalisierungsphase“. Die Risiko-basierten Auswahlkriterien für die Testfälle variieren von Phase zu Phase.
In der „aktiven Entwicklungsphase“ ist das Risiko, dass ein Defekt in das Release wandert, sehr gering. Daher werden in dieser Phase vor allem solche Testfälle durchgeführt, die den Produktiv-Code  an denjenigen Stellen überdecken, welche stark geändert wurden, um möglichst viele Fehler schon in dieser Phase zu finden.

In der „Stabilisierungsphase“ wandert der Fokus dahin, Tests zu identifizieren, die man weglassen kann, weil sie keine neuen Defekte aufdecken können. In dieser Phase werden auch alle geschäftskritischen Testfälle durchgeführt.

In der „Finalisierungsphase“ werden ausschließlich Nachtests durchgeführt.

“Risikoreduktions-Potential“ eines Tests als zentraler Faktor

Mit vorliegendem Vortrag stellen wir heraus, dass dem „Risikoreduktions-Potential“ eines Testfalls zentrale Bedeutung zukommt. Diese Größe beschreibt die Befähigung eines Testfalls, das aktuelle Gesamtrisiko zu reduzieren, sofern er durchgeführt wird. Rechnerisch gesehen ist es die Differenz zwischen dem Gesamtrisiko vor und nach der potentiellen Testdurchführung.

Die jeweiligen Risikoreduktions-Potentiale werden, wie eingangs beschrieben, zunächst zur Priorisierung der Testfälle eines Test-Runs benutzt.

Darüber hinaus können die Risikoreduktions-Potentiale auch dazu dienen, ein Abbruchkriterium für einen Test-Run zu definieren. Testfälle, deren Reduktionspotential zu gering ist, sollten nicht mehr durchgeführt werden. Zum Ende der Warteschlange hin kann das rechnerische Risikoreduktions-Potential sogar negativ werden. Das bedeutet, dass den Testdurchführungs-Kosten voraussichtlich kein adäquater Nutzen gegenüber steht.

Ergebnis: Mehr Funktionalität mit weniger komplexer Infrastruktur

Anhand des Beispielprojektes zeigen wir, wie die Methoden des effektiven „Risiko-basierten Testens“ und des effizienten „Very Early Testing“ ineinandergreifen und ihre positiven Effekte wechselseitig verstärken. Bei dem Beispiel-Projekt ERiC hatte die Kombination beider Methoden extrem positive Auswirkungen, die sich bereits nach einem Jahr sehr deutlich auswirkten. Die Absicherung durch die QS erlaubte es den Entwicklern, ein umfangreiches Refactoring der Code-Basis und der API durchzuführen. Dabei konnte die interne Struktur der Software stark vereinfacht und der Umfang der Software deutlich reduziert werden. Mit einer technisch weniger komplexen Infrastruktur konnte ein Mehr an Funktionalität bereitgestellt werden.

Dr. Hans-Martin Adorf, mgm technology partners GmbH

Dr. Hans-Martin Adorf verfügt über drei Dekaden kombinierter Erfahrung in Forschung und Industrie.
Mehr als zwölf Jahre arbeitete er in dem Hubble-Weltraumteleskop-Projekt, u.a. an der Lösung astronomischer Entscheidungsprobleme mit Hilfe statistischer Klassifikation. Am European Southern Observatory, Garching, führte er das World Wide Web ein und entwickelte das erste webbasierte Entscheidungsunterstützungs-System für die Planung von Beobachtungen mit Hubble. Maßgeblich beteiligt war er zudem an der Entwicklung des SPIKE-Schedulers für Hubble.

Im Anschluss arbeitete er, verantwortlich für die weltweit führende „Leverage for Planning“-Software zur optimierten Kapazitätsplanung in der Halbleiterindustrie, bei der Interval Logic Corp., Mountain View, USA.
Nach einer weiteren Station in der astronomischen Forschung, wechselte Dr. Adorf zur mgm technology partners gmbh, München, wo er seit acht Jahren an der automatisierten Erzeugung von Testdaten und dem Risiko-basierten Testen arbeitet.

Dr. Martin Varendorff, mgm technology partners GmbH

Nach zehn Jahren Forschungsarbeit als Astrophysiker wechselte Martin Varendorff zum Software Engineering: Zunächst in den Bereichen Prozesskontrolle, Fabrikautomation und Laborinformationssysteme und dann zur Qualitätssicherung. Seit elf Jahren ist er bei mgm technology partners für die Qualitätssicherung von geschäftskritischen transaktionalen webbasierten Anwendungen für öffentliche Auftraggeber, Banken und Versicherungen sowie E-Commerce-Anwendungen verantwortlich.

Dr. Michael Felderer, Universität Innsbruck

PD Dr. Michael Felderer ist Assistant Professor und Projektleiter am Institut für Informatik der Universität Innsbruck. Er hat sich in Informatik habilitiert und promoviert. Seine Forschungsinteressen umfassen Testen und Software-Qualität im Allgemeinen, empirisches Software-Engineering und Software-Prozesse. In seiner Forschung arbeitet Dr. Felderer eng mit der Industrie zusammen und transferiert seine Forschungsergebnisse in die Praxis, zum einen als Senior Consultant für die Firma QE LaB Business Services und zum anderen als regelmäßiger Sprecher auf industriellen Konferenzen.