Artikel

Leitfaden zur Testdefinition für automatisierte Softwaretests / 02

Beitrag von Udo Loeb
14. Januar 2014

Als Feedback zum ersten Teil dieses Leitfadens habe ich den Kommentar erhalten, dass das Thema „Anforderungen“ vernachlässigt wurde. Diese Anmerkung ist natürlich völlig richtig: Theoretisch testet man ja „einfach“ alle Anforderungen und dann weiß man, dass die Software funktioniert. Daher sollte der Bezug zu den Anforderungen nicht unter den Tisch fallen. Lassen Sie mich also die Ausgangssituation, die ich bei der Entwicklung dieses Leitfadens im Kopf habe, genauer beschreiben:

Ausgangssituation
Stellen Sie sich vor, Sie sind verantwortlich für eine komplexe Software, die über Jahre „gewachsen“ ist. In der Vergangenheit wurde die Entwicklung von Tests durch Entwickler getrieben, und es wurde Ihnen stets versichert, dass man eine sehr gute Testabdeckung vorweisen kann (über 90 Prozent). Trotzdem häufen sich in letzter Zeit Fehler, der Aufwand für den Service steigt rapide an.
Auf Nachfrage stellt sich heraus, dass die Testabdeckung von 90 Prozent sich auf die Anzahl der Zeilen Code bezieht, dass also 90 Prozent der existierenden Zeilen Code von mindestens einem (Unit-) Test aufgerufen werden. (Die Frage nach einfacher oder mehrfacher Pfadüberdeckung ignoriere ich bewusst.).

Jeder, der einmal in einer vergleichbaren Situation war, weiss, wie schwierig es nun ist, mit Kunden oder der Geschäftsführung über die Effektivität der Qualitätssicherung zu diskutieren. Da UNIT-Tests (lediglich) auf einer sehr granularen technischen Ebene arbeiten ist sehr schwer zu vermitteln, was genau dort getestet wird. Ein Zusammenhang zu den Funktionen der Software lässt sich allenfalls indirekt herstellen. Es fehlen also wichtige Qualitätssicherungsmaßnahmen, und die sollen nun schnellstens geschaffen werden.

Stellen wir uns weiterhin vor, dass Anforderungen nicht in einer Form vorliegen, die die Misere lösen könnte, und fertig ist unser gedankliches Grundgerüst.

Noch eine Anmerkung vorab: Natürlich müsste man als theoretisch gebildeter Tester zunächst Testziele definieren. Stellen wir uns also abschließend vor, dass wir zunächst unser Bestes versuchen, um eine vernünftige, entwickelbare und anpassbare Grundlage für eine ordentliche Testabdeckung zu schaffen, und legen wir los:

Step 1: Datensicht
Verschaffen Sie sich im ersten Schritt einen Überblick über die Daten, die Ihre Software verwendet, sei es zur Laufzeit oder persistent. Das Schöne an dieser Herangehensweise ist, dass Sie in jedem Fall eine endliche Liste bekommen, und dass die Elemente dieser Liste mit hoher Wahrscheinlichkeit gut definiert und somit unmissverständlich sind. Visualisieren Sie die einzelnen Datenpakete (Fachklassen) ruhig mithilfe von Post-its o.Ä..

Priorisieren Sie die Liste nach einem definierten Prinzip (entweder Stärke der Qualitätsprobleme, wenn sich ein Bezug zu bestimmten Fachklassen herstellen lässt, oder nach „Wert“ aus Unternehmenssicht).

Step 2: Benutzersicht
Da am anderen Ende der Software, in der Regel Menschen sitzen, nehmen wir nun die Sicht der Benutzer ein. Verschaffen Sie sich einen Überblick über die wichtigsten Interfaces (GUI-Elemente), mit denen Benutzer die oben definierten Daten anlegen, editieren, löschen aber auch ansehen können. Folgen Sie dabei der Priorisierung.

Konzentrieren Sie sich zunächst auf die wichtigste Fachklasse, um eine überschaubare Menge von Elementen zu behalten.

Step 3: Weitere Akteure

Da selbstverständlich nicht nur Menschen, sondern auch Maschinen die Daten manipulieren, verschaffen Sie sich einen Überblick über weitere Schnittstellen Ihrer Software.

Der Vollständigkeit halber müssen wir uns nun noch bewusst machen, dass die Software selbst auch ein Akteur ist, da sie z.B.. durch zeitgesteuerte Prozesse auch selbständig Datemanipulationen anstossen kann. Notieren Sie sich für diese Akteure die Funktionen oder Prozesse aus Benutzersicht, die für die Manipulation der Daten verantwortlich sind, z.B. den Ablauf eines Abonnements (nach dem die Software selbständig den Status der Benutzerdaten ändert).

In den folgenden Beiträgen wird es darum gehen, die Lücken zwischen Daten und Akteuren so aufzufüllen, dass nach und nach eine Testabdeckung entsteht, die auch aus Sicht der Benutzer „über 90%“ beträgt.

| Keine Kommentare