Erfahrungstest Regressionstests prüfen

Redakteur: Martina Hafner

Um die Qualität von Regressionstests festzustellen hat UC4 ohne Wissen des Testteams spezifische Fehler in das zu testende System eingebaut. Das Ergebniss: wurden Fehler nicht gefunden, war lag dies an Prozessschwächen.

Firmen zum Thema

Tabelle 1: Um zu entscheiden, welche Fehler in das Produkt einzubringen wären, wurde eine Liste mit Selektionskriterien erstellt.
Tabelle 1: Um zu entscheiden, welche Fehler in das Produkt einzubringen wären, wurde eine Liste mit Selektionskriterien erstellt.
( Archiv: Vogel Business Media )

Um die Qualität von Regressionstests festzustellen hat UC4 ein Experiment durchgeführt und ohne Wissen des Testteams spezifische Fehler in das zu testende System eingebaut. Das Ergebniss: wurden Fehler nicht aufgefunden, war dies in allen Fällen auf bestehende oder früher vorhandene Prozessschwächen zurückzuführen.

Es ist eine allgemein bekannte Tatsache, dass Regressionstestfälle mit zunehmendem Alter ihre Effektivität verlieren. Die Ursachen hiefür liegen oft darin, dass die Produkte weiterentwickelt sowie Funktionen hinzugefügt werden oder aber sich die Implementation bestehender Funktionen änderte. Auch die Unterstützung zusätzlicher Plattformen mit ihren jeweiligen Eigenheiten kann dafür sorgen, dass das durch die Regressionstestfälle geknüpfte Sicherheitsnetz löchriger wird.

Bildergalerie

Die folgende Methode wurde in einem ersten Experiment bei UC4 Software zur Qualitätssicherung von Regressionstestfällen angewendet und in der Folge in die üblichen QA Maßnahmen integriert. Dieses Experiment war durch die Fragestellungen motiviert:

• Können wir sicher sein, dass unsere Regressionstests alle Schlüsselbereiche unseres Produkts abdecken, nachdem seit der Erstentwicklung mehr als sieben Jahre und unzählige Produktversionen ins Land gezogen sind?

• Haben Prozessschwächen oder gar fehlende Prozesse zu Fehlern oder Lücken in den Regressionstestfällen geführt, sodass möglicherweise nicht alle Schlüsselbereiche des Produkts durch Testfälle abgedeckt sind?

• Sind unsere Prozesse zur Testfallpflege gut genug, sodass Testfälle, welche im Rahmen der Produktentwicklung oder aber als Antwort auf Kundenprobleme entstanden sind, auch entsprechend in das Testfallportfolio eingearbeitet werden?

• Sind wir sicher, dass wir die Kernfunktionalitäten noch richtig testen, obwohl sich deren Implementation innerhalb der letzten Jahre geändert hat?

• Ist die von uns verwendete „Osterei“ Methode dafür geeignet, diese Fragen zu beantworten?

Für das Experiment brachte der Entwicklungsleiter die „Osterei“-Fehler in den Code ein. Insbesondere wurde darauf geachtet, dass die eingebrachten Fehler nur auf den Maschinen des Testteams auftreten konnten. Daher wurden diese Fehler in Abstimmung mit dem QA-Manager auf die zum Test vorgesehenen Maschinen eingeschränkt, indem die Fehlerroutine überprüfte, auf welchem Rechner das Programm ausgeführt wird. Als weiterer Sicherheitsmechanismus wurde ein Zeitfenster angegeben, welches im Bereich des geplanten Regressionstests lag. Eine Zeitabfrage in der Fehlerroutine verhinderte, dass die eingebrachten Fehler außerhalb dieses Zeitfensters ausgelöst wurden. Es wurden des weiteren entsprechende Kommentare in den Sourcen angebracht, welche die Entwickler instruierten, ohne Rücksprache mit dem Entwicklungsmanagement keine Veränderungen an diesen Code Segmenten vorzunehmen. Für die Entscheidung, welche Fehler in das Produkt einzubringen wären, wurde eine Liste mit Selektionskriterien erstellt, die als allgemein gültig, wenn auch nicht vollständig, gelten kann (Tabelle 1).

Ziel war es, Prozessschwächen aufzudecken

In ihrem Prinzip entspricht die verwendete Methode dem „defect seeding“, wie dies in verschiedensten Standardwerken beschrieben wird und vor allem im Embedded-Bereich statt findet. Jedoch war das Ziel ein anderes als üblicherweise, da nicht die zu testenden Kriterien festgelegt wurden, sondern Prozess- und Testfallschwächen damit aufgedeckt werden sollten. Die Einbringung der Fehler entspricht dem Prinzip von Mutationstests.

Einen wichtigen Faktor bei dieser Methode stellt die „Blindheit“ der Tester dar, da nur so sichergestellt werden kann, dass der Regressionstest in typischer Weise ausgeführt wird und die Tester keinen zusätzlichen Testaufwand treiben. Daher wurden weder Tester noch Entwickler von diesem Experiment informiert.

Die Regressionstests wurden innerhalb der Regressionstestphase in typischer Weise durchgeführt. Im Rahmen einer gemeinsamen Nachbesprechung wurde jeder der eingebrachten Fehler vorgestellt und in Hinsicht auf die folgenden Fragen analysiert:

• 1. Wurde der Fehler gefunden?

• 2. Wenn ja, geschah dies durch einen direkt darauf ausgerichteten Testfall?

• 3. Wenn nein, gibt es einen Testfall, der diesen Fehler hätte finden können?

• 4. Wenn die Antwort zu 3 ja war: woran scheiterte die Detektion?

• 5. Wenn die Antwort zu 3 nein war: weshalb existiert hiezu kein Testfall?

Die Antworten zu diesen Fragen verwiesen direkt auf vergangene oder bestehende Schwächen in Testfalldesign und Prozessen.

Nur drei von sechs Fehlern wurden entdeckt

Um die Art der Fehler zu verstehen, einen kurzen Überblick über das getestete System:

Bei UC4:global handelt es sich um ein System für unternehmensweites, plattformübergreifendes Job-Scheduling. Es ermöglicht dem Benutzer Jobs auf verschiedensten Plattformen zu planen, auszuführen und zu überwachen. Ebenso ermöglicht es die Steuerung und Überwachung von ERP-Systemen wie SAP oder OA. Architektonisch besteht es aus drei Hauptkomponenten, nämlich dem Server, welcher die gesamte Business-Logik beinhaltet, den Exekutoren, die für die Abwicklung der Jobs auf den einzelnen Plattformen zuständig sind, sowie dem Dialog-Client für Eingabe und Überwachung. Hierbei stellt der Server die kritischste Komponente dar und wurde daher als Ziel des error seedings gewählt. Die Art der Fehler und ihre jeweilige Motivation sind in Tabelle 2 beschrieben.

Tabelle 3 zeigt warum Fehler gefunden oder nicht entdeckt wurden, die Ursache für die (Nicht-)Detektion und die entsprechende Bewertung. So wurden nur drei der sechs Fehler durch die Regressionstests gefunden. Obwohl auf den ersten Blick ernüchternd, darf auf der positiven Seite vermerkt werden, dass die gefundenen Fehler sehr früh innerhalb des Regressionstests entdeckt wurden, bei dem ein Zyklus rund fünf Tage in Anspruch nimmt.

Fehler 1 wurde durch einen Seiteneffekt gefunden. Hierbei testete ein Testrobot den gesamten Ablauf der Benutzeranlage. Aufgrund der fehlerhaften Prüfroutine wurde ein vom Testfallskript erwarteter Dialog nicht aufgerufen. Dieser Fehler brachte die Tester dazu, dies näher zu untersuchen, wodurch der Fehler in der Folge entdeckt wurde. Die Fehler 2 und 3 wurden durch direkt auf sie abzielende Testfälle gefunden. Fehler Nummer 4 wurde nicht gefunden, obwohl Testfälle zur Prüfung dieser Funktionalität vorhanden waren und ausgeführt wurden. Es stellte sich heraus, dass bei diesen Testfällen Designfehler die Ursache waren, welche die Detektion verhinderten. Weitere Diskussion und Untersuchung führte auch auf entsprechende Prozessschwächen, welche diese Designfehler verursachten. Fehler 5 und 6 blieben beide aufgrund von Prozessschwächen unentdeckt.

Fehler wiesen auf Prozessschwächen hin

Das Nichtauffinden der Fehlern war in allen Fällen auf bestehende oder früher vorhandene Prozessschwächen zurückzuführen. Bei Fehler Nummer 4 lag die Nichtdetektion daran, dass die Testfälle zu dieser Funktion erst Jahre nach der Implementation entstanden. Diese Situation wurde noch durch die Tatsache verschärft, dass dem Testteam keine Anforderungsdokumente oder technischen Beschreibungen der Funktion zur Verfügung standen. Daher orientierten sich die Tester beim Testfalldesign an der Produktdokumentation. Diese jedoch beschreibt nicht den technischen workflow der Funktion, welcher in einer großen Anzahl von Szenarios bestimmte Code Teile überspringt. Für die Tester war es daher nicht feststellbar, dass die von ihnen entworfenen Szenarien entweder den entsprechenden Code nicht durchliefen oder aber nicht zur Fehlersituation führten. Das fehlerhafte Testfalldesign konnte also direkt mit einer früheren Prozessschwäche, nämlich einer mangelhaften Dokumentation, in Verbindung gebracht werden. Neben dem inzwischen eingeführten Entwicklungsprozess, welcher die verpflichtende Erstellung eines Anforderungsdokuments und eine technischen Designdokuments erfordert, wurde auch eine Prozessverbesserung formuliert, die eine Lösung für „dokumentationsarme“ Testfallerstellung darstellt. Sollte entsprechende Dokumentation fehlen, so hat ein „Grey Box Test“ Verfahren unter Mithilfe der Entwicklung angewendet zu werden.

Fehler 5 und 6 wiesen ebenso auf Prozessschwächen hin. Die Ursache für deren Nicht-Detektion liegt hierbei in der Entwicklung der Firma. Der Test wurde früher nicht als kontinuierlicher Prozess verstanden, sondern nur als Phase in einem Entwicklungsprojekt. Daher waren zwei wesentliche Prozesse der Testfallwartung nicht formalisiert, sondern fanden auf einer ad-hoc-Basis durch einzelne Tester statt. Der erste Prozess, welcher nun institutionalisiert wurde betrifft die Wartung der Regressionstestfälle nach einer Änderung bzw. Erweiterung bestehender Funktionalität. Hierbei wurde festgestellt, dass vor allem Testfälle zu neuen Funktionalitäten nach ihrer initialen Testung nicht die Aufnahme in das Regressionstestportfolio schafften.

Verbesserungen für die Zukunft formalisieren

Folgende Prozessverbesserung wurde formalisiert: Nach einer Versionsfreigabe wird ein Wartungszyklus für die Regressionstests durchgeführt. Hierbei werden entsprechend den Änderungen und Neuentwicklungen dieser Version die Regressionstestfälle angepasst bzw. ergänzt. Der zweite Prozess betrifft die Änderung bzw. Erweiterung von Regressionstestfällen nach kritischen Kundenproblemen. In diesem Fall wurde diese Schwäche durch eine Reorganisationsmaßnahme verursacht. So ging die Verantwortlichkeit für das Testen von Hotfixes von der QA auf die Entwickler über. Dies führte ungewollt zu einem Prozessbruch, da hierdurch das Testteam von Information über kritische Fehler im System abgeschnitten wurde. Folgende Prozessverbesserung wurde implementiert: Nach der Erstellung eine Hotfixs wird das Testteam über Ursache und Fehlerbehebung informiert. Das Testteam untersucht diese Problem und passt die Regressionstestfälle entsprechend an. Das Experiment zeigte, dass die vorgestellte Methode für die Prüfung von Regressionstestfällen geeignet ist und ebenso Prozessschwächen aufzeigt. Sie ist kosteneffizient, da der Aufwand für das Einbringen der Fehler, die zusätzliche Untersuchungs- und Testzeit sowie Nachbesprechungen bei nur rund 15 Personentagen lag.

Psychologische Effekte nicht unterschätzen

Zusätzlich zu den prozesstechnischen Punkten ist es äußerst wichtig, die psychologischen Effekt dieser Methode auf die QM-Organisation zu berücksichtigen. So gilt es bei den Nachbesprechungen zu betonen, dass es sich bei der angewandten Methode nicht um ein Mittel handelt, die Tester zu kontrollieren sondern zur Qualitätskontrolle und Verbesserung der Prozesse. Können an diesem Punkt die Mitarbeiter des QM davon nicht überzeugt werden, kann diese Methode kein weiteres mal eingesetzt werden, da die Tester dann zu anderen Mitteln greifen werden, die eingebrachte Fehler zu finden, anstatt die Regressionstestfälle anzuwenden. Aus diesem Grund müssen auch personenbezogene Auswertungen der Detektionsrate, sowie „Schuldzuweisungen“ – z.B. „Den Fehler hätten Sie finden müssen!“ - unterbleiben. Bei UC4 erhielt das QA-Management von ihren Testern positives Feedback, da diese die Methode als ein Werkzeug sehen, mit dem sie ihre Arbeit verbessern können. Nichtsdestotrotz zeigten sie jedoch auch Skepsis in Hinblick auf „unnötige Mehrarbeit“ durch die eingebrachten Fehler. Auch aus diesem Grund ist es empfehlenswert, nicht mehr als zwei bis drei Fehler pro Tester in das Produkt einzubringen.

UC4 Software

Tel. +43 (0)2233 77881345

*Bernhard Burger ist Manager Quality Assurance bei UC4 in Wolfsgraben, Österreich. Kontakt: Bernhard.Burger@uc4.com

(ID:180978)