10 things I wished they’d told me – Softwaretestdokumentation

Für alle die bei der Präsentation (1) nicht dabei sein konnten möchten wir hier die Gelegenheit nutzen Ihnen auch einen kompakten inhaltlichen Rückblick zu dem Vortrag und insbesondere eine schriftliche Übersicht der 10 Tipps zu geben.

Gerade mit dem Begriff Testdokumentation werden viele Begriffe und Standards in Verbindung gebracht. Was davon brauchen wir aber wirklich, also was ist der Kern einer guten Testdokumentation? Wie kann ich diesen bei Bedarf weiter ausbauen und optimieren?

Tag Cloud Test Documentation

Tag Cloud der Testdokumentation

Dokumentieren Sie immer die Testdurchführung

Ein Ansatz ist es einfach und schlicht nichts zu dokumentieren. Man bekommt das Testobjekt testet drauf los, schickt die Findings, welcher Art auch immer, direkt an die Entwicklung und diese erledigt eben diese so gut sie kann. Solang das Testobjekt überschaubar ist und die Entwicklung eng mit dem Test zusammen arbeitet, funktioniert dieses Vorgehen zur Beurteilung der Qualität auf Basis der Aussagen eines Testers. Dies ist aber auch implizit der Nachteil, in Wirklichkeit kann keiner außer diesem einen Tester die Qualität beurteilen.  Auch wenn er viel und gut getestet hat, gibt es dafür keinen Nachweis und seine Arbeit ist weder nachvollziehbar noch reproduzierbar. Dies gilt nicht nur für das Management, sondern auch für den Tester selbst. Er kann seine Regressionstests nicht mehr auf dem bereits einmal ausgearbeiteten und durchgeführten Tests aufbauen und hat keine Chance seine eigenen Aktivitäten zu verfolgen.  Aus diesen Gründen sollte man immer zumindest die Testdurchführung, die konkreten Ergebnisse der Durchführung (Test OK, Test Nicht-OK) und die Findings dokumentieren. Die Form der Dokumentation ist in dieser Ausprägung irrelevant, es kann ein Video-Capture der Tests sein oder Dokumentation im Notepad oder bereits in einem Testtool. Die Auswahl der geeigneten Methode ist schon eine Maßnahme der Optimierung, aber oft auch intuitiv gewählt.

Achten Sie darauf die Information zu „erhalten“

Basis der oben beschriebenen Durchführung sind Informationen und zwar Informationen welche wir vor unseren Tests sammeln müssen. Die üblichen Quellen sind Anforderungsmanagement, die Entwicklung, die Stakeholder, Benutzer aber auch das Know-how des Testers. Ein Grundempfinden für die Bedienbarkeit einer Applikation bringt heute jeder Digital Native mit, während die Geschäftsprozesse welche die Applikation bedienen soll vom Tester gesammelt werden müssen. Hat er ein gutes Anforderungsmanagement als Basis kommt er leicht an diese Informationen, hat er das nicht muss er sich die Information zusammentragen. Nicht nur im letzten Fall lohnt es sich Workshops mit den verschiedenen Parteien zu organisieren und sich die Informationen abzuholen. Von der Validierung der Anforderungen bis hin zur ersten Verifizierung von Funktionalitäten über Schaffung eines Verständnisses beim Tester für den tatsächlichen Bedarf, können viele der relevanten Qualitätskriterien abgedeckt werden.

Haben Sie diese Informationen so ist dies die Basis für die Spezifikation Ihrer Testfälle, welche wiederum als Basis für Ihre Testdurchführung dienen können, somit schließt sich ein Kreis. In diese Kreist laufen wir Tester vor und zurück. Ändert sich etwas an den Anforderungen, müssen wir die Testfälle anpassen und somit diese auch erneut durchführen. Finden wir Abweichungen so müssen wir die Applikation anpassen und evtl. auch die Anforderungen und somit wieder die Testfälle.  Deshalb ist es besonders wichtig, dass die Informationen in einer geeigneten Struktur abgelegt und jederzeit erreichbar und änderbar sind.

Halten Sie Ihre Konzepte möglichst schlank

Die IEEE829 (2) gibt dem Testmanagement ein sehr gutes Rahmenwerk zur Planung der Testaktivitäten vor.  Wir müssen aber darauf achten die einzelnen Punkte nicht einfach stur umzusetzen, sondern unseren Bedürfnissen anzupassen. Auch sollten die Inhalte so erstellt werden, dass sie schnell an aktuelle Änderungen angepasst werden können, denn dies wird bei der Steuerung der Testaktivitäten mehr als einmal nötigt sein.  Wichtig ist es auch möglichst früh mit der Planung anzufangen, da wir die Meilensteine für die Testaktivitäten legen können und auch Punkte die lange Vorbereitungszeit benötigen im Fokus haben. Bei der Planung der einzelnen Testphasen sollte auch das Testteam mit eingebunden werden, denn zumeist weiß das Team mehr über die Komplexität und somit den Aufwand der Testaktivitäten als der Testmanager.

Priorisieren Sie, zumindest nach Optional/Mandatory

Stellen wir uns folgende Situation vor: Die Testzeit ist vorbei und sie haben keine andere Wahl als mit dem Ist-Stand der Tests die Qualität der Applikation zu beurteilen. Unser Ist-Stand: Wir haben „nur“ 3000 von 15000 Testfällen durchgeführt.  Wenn die Testfälle nicht in irgendeiner Form priorisiert sind, können wir in diesem Augenblick auf Basis der Testfälle so gut wie keine Aussage über die bereits erreichte Abdeckung und somit der Qualität des Testobjektes machen.

Dieses Beispiel lässt sich beliebig auf Entscheidungen zur Testautomation und Entscheidungen zur Testportfolio Kürzung erweitern.  Sie müssen also zumindest in einer rudimentären Form priorisieren. Sie können, dass über die bekannte Risikomatrix machen. Auf der einen Achse haben sie den Schaden auf der anderen die Eintrittswahrscheinlichkeit der zu testenden Funktionalität. Den Input zu den Achsen erhält man zumeist aus der eigenen Erfahrung, der Entwicklung(z.B. Komplexität des Codes) und den Stakeholdern.  Ein weiteres Vorgehen welches in einigen Testtools bereits mitgeliefert wird, ist die Priorisierung auf Basis von Fragen an die Stakeholder oder Benutzer zur Funktionalität und ihrem Umgang damit.  Einige Beispiele: „Auswirkungen eines Ausfalls für Ihre Arbeit?“, „Auswirkungen eines Ausfalls für Ihr Unternehmen?“, „Auswirkungen eines Ausfalls auf Kunden?“. Die Fragen müssen geschickt gestellt werden, denn zumeist ist einem jede Funktionalität sehr wichtig und die Aspekte unter denen man darauf verzichten könnte, die aber für das Testobjekt und den Schaden relevant sind, müssen herausgearbeitet werden.

Stellen Sie sich auf Ihre Umwelt ein

Die verfügbare Zeit für die Testaktivitäten, die Eigenschaften des Testobjektes, die Herausforderungen der Testlevel, der Schaden welchen das Testobjekt verursachen kann, die Wiederverwendung unserer Testware, Standards und Normen und nicht zuletzt die Entwicklung, sind nur einige von der Einflussfaktoren die unsere Testdokumentation wesentlich beeinflussen. Diese müssen wir beim Aufbau unsere Testdokumentation zwingend berücksichtigen, denn die Testaktivitäten sind als Schnittstellenfunktion immer von Einflüssen getrieben und somit auch unsere Dokumentation.

Konservieren Sie die Testdokumentation

Nach jeder Testphase haben wir einen Haufen an Testfällen die in der ursprünglichen Form nicht mehr anwendbar sind und geändert werden müssen, da während der Durchführung keine Zeit dafür war. Diese müssen markiert und in einer eigenen Konservierungsphase gerade gezogen werden.

Auch gibt es nach jeder Testphase „Reste“, z.B. nicht gefixte Defects, nicht durchführbare Testfälle und ausstehende Retests. Oft werden die Reste einfach vergessen, weil die Priorität nach der Durchführung bereits auf der nächsten Durchführung liegt, das darf aber nicht passieren. Wir müssen also auch hier eine Markierung setzen und die Reste in der nächsten Phase berücksichtigen.

Optimieren Sie den Testfallaufbau

Schaffen von Testfalltemplates und Modulen als Optimierung des Testfallaufbaus. Das Wie findet man  auf unserem Blog: http://blog.seqis.com auf welchem gute Tipps/Artikel zu diesem Thema bereits gepostet wurden.

Beachten Sie die Kosten Ihrer Dokumentation

Nach Juran (3) gibt es Optimum zwischen den Fehlerfolgekosten und den Vorbeuge-,Prüf- und Beurteilungskosten. Das heißt es gibt einen Punkt ab dem es sich nicht mehr lohnt in die Qualität der Software zu investieren, weil die minimalen Gesamtkosten (Summe aus Fehlerfolgekosten und den Vorbeuge-,Prüf- und Beurteilungskosten) an diesem Punkt erreicht sind.

Wir können die Kosten unsere Testdokumentation und damit den in die Testdokumentation zu investierenden Aufwand auf eine ähnliche Weise skizzieren (siehe unten). Die Kosten für unsere Testdokumentation bestehen im Wesentlichen aus zwei Teilen: Den Kosten für die Entstehung der Dokumentation (Dokumentationskosten) und den Kosten für die Durchführung bzw. Verwendung der Dokumentation im vorhandenen Umfang (Durchführungskosten). Die Dokumentationskosten sind bei einem noch neuen Prozess relativ hoch, es muss viel auf der grünen Wiese gebaut werden, die Tester müssen Methoden und Tools kennenlernen, Informationen müssen verarbeitet werden und die Erstellung von Templates und Modulen verursacht am Anfang auch Aufwand gegenüber einer einfachen Dokumentation. Allerdings erreich dieser Prozess eine Sättigung, aber der an der Dokumentation zwar noch optimiert und ergänzt wird, aber dies nicht mehr mit dem enormen Aufwand verbunden ist.

Die Durchführungskosten können mit dem Aufbau einer hochwertigen Testdokumentation stark gesenkt werden, die Tester können während der Durchführung auf gut vorbereitete Testfälle zurückgreifen und somit ihre Effektivität und Effizienz steigern. Der Testmanager hat eine gut vorbereitete Planung die er an die aktuellen Geschehnisse adaptieren kann und mit der Priorisierung steuert er die Testabdeckung. Allerdings sinken diese Kosten nicht mit der Qualität der Dokumentation ins unendliche. Ab einem gewissen Punkt steigen die Kosten der Durchführung, die Dokumentation und die Ansprüche die sie stellt sind nicht mehr zu bewältigen. Nicht die Durchführung selbst, sondern die Dokumentation verschlingt den wesentlichen Teil des Aufwandes. Sie wird „lästig“ und automatisch immer mehr in den Hintergrund gesetzt, dies löst wiederum in der Nachbearbeitung Aufwand aus und so fallen die weiteren Dominosteine.

Cost of Test Documentation Curve

Kostenkurve der Testdokumentation

Fazit: Auch bei der Testdokumentation gibt es eine Grenze des sinnvollen und lohnenden. Ein Review nach jeder Testphase über die Verteilung der Aufwände, Feedback von den Testern sind gute Indikatoren für das überschreiten dieser Grenze.

Setzen Sie auf das richtige Tool

Testmanagementtools, Lasttesttools, Performancetesttools und Testautomationstools. Das alles und noch viel mehr brauchen wir ab einer bestimmten Reife unseres Testprozesses und Kritikalität der Applikation. Der Schwerpunkt muss hier aber eindeutig auf dem „ab“ liegen. Die Testaktivitäten müssen das Bedürfnis für ein Tool schaffen und nicht das Tool die Bedürfnisse für Testaktivitäten. Somit wird man nie an den Punkt kommen das Tool nicht zu nutzen und auch nicht in die Bedrängnis viele Testfälle in das neue Tool migrieren zu müssen. Diese Bedürfnisse dürfen sich während der Toolauswahl auf keinen Fall dem Tool anpassen, das Tool muss den Bedürfnissen entsprechen oder sich diesen anpassen können. Die gezielte Toolauswahl ist hierbei entscheidend, denn mittlerweile ist der Markt an proprietären aber auch Open Source Testtools enorm gewachsen. Auch hier der Verweis auf bereits Geschriebenes: http://www.whichtestingtool.com

Erweitern Sie Ihre Dokumentation von innen nach außen!

Ob wir ein komplett neues Testteam aufbauen oder bereits ein etablierten Testprozess und –dokumentation erweitern, spiel nur für die Positionierung der künftigen Aktivitäten eine Rolle. Bei beiden müssen wir darauf achten den vernünftigen nächsten Schritt zu setzen und nicht auf ein nächst höheres Level zu springen. Die Grundlagen sind immer die Dokumentation der Testdurchführung, -ergebnisse und Findings. Dies können wir mit Testfällen, einer intelligenten Planung und Risikomanagement erweitern. Das Vorhandene optimieren ist der nächste Schritt und erst wenn wir hier unseren eigenen Ideenpool ausgeschöpft haben ist es gut in erhaltende Maßnahmen zu investieren. Ein Review des Prozesses von außen, schafft neue Perspektiven, kann noch neue Methoden und Idee einbringen, unsere Vorgehen neutral bewerten, mit dem Wettbewerb vergleichen und manchmal auch einfach neuen Schwung in die Abläufe bringen.

SEQIS Bubble of Test Documentation

SEQIS Bubble der Testdokumentation

Literaturverzeichnis

1. Fojdl, Josef. 10 things I wished they’d told me! – Softwaretestdokumentation. [Online] 2011. http://www.seqis.com/images/downloads/10things_softwaretestdokumentation.pdf.

2. IEEE, SA Standards Board. IEEE Standard for Software Test Documentation. Piscataway NJ : The Institute of Electrical and Electronic Engineers Inc., 1998.

3. Juran, J.M. Quality Control Handbook. New York : McGraw Hill, 1979.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: