Testdokumentation mit der ISO/IEC/IEEE 29119-3:2021

Wenn man ein neues Testprojekt aufsetzt, stellt sich üblicherweise bald die Frage, welche Dokumente erstellt werden sollen. Hier kann das eigene Qualitätsmanagementsystem (QMS) oder z.B. das des Kunden die Antwort geben, wenn denn überhaupt ein QMS existiert.

Von der IEEE 829 zur ISO/IEC/IEEE 29119

Viele Tester kennen und folgen der Norm IEEE 829 “IEEE Standard for Software Test Documentation“. Es gibt umfangreiche Materialien basierend auf der IEEE 829. Man findet leicht adaptierbare Beispiele im Netz oder in Büchern. Es gibt Präsentationen, YouTube-Videos, …

Und so stelle ich immer wieder fest, dass auch interessierte Tester/Test Manager (besonders, wenn sie schon länger im Geschäft sind) nicht mitbekommen haben, dass die geliebte IEEE 829 abgelöst wurde. Der IEEE 829 weiter zu folgen, ist sicher besser, als ohne Konzept zu testen und zu dokumentieren. Bei neuen Projekten oder wann immer im Nachgang die Frage nach “state of the art” gestellt werden könnte (regulierter Markt, gescheiterte Auftragsarbeiten, etc.), sollte allerdings erwogen werden, die aktuelle Norm umzusetzen.

Seit 2013 ist die IEEE 829 abgelöst durch die ISO/IEC/IEEE 29119-3 “Software and systems engineering — Software testing — Test documentation“. Und jetzt ist der beste Zeitpunkt um um- oder einzusteigen, denn die ISO/IEC/IEEE 29119-3:2021 ist im Oktober frisch erschienen und kann erworben werden.

Die 29119-3 kommt aber nicht allein. Wie sich leicht vermuten lässt, ist sie der dritte Teil einer Normenreihe. Wer noch besser sein will, legt sich auch die 29119-2:2021 daneben, in der erläutert wird, wie man zu den Dokumenten kommt. Wer jeglichen Zweifel ausräumen will, beschafft sich alle 5 Teile der Norm.

Wem die Kosten zu hoch sind (ca. 200€ pro Normenteil) oder wer (unbegründet) Respekt vor dem Lesen einer Norm hat, dem sei das hervorragende Buch “ISO 29119 – Die Softwaretest-Normen verstehen und anwenden” von Matthias Daigl und Rolf Glunz ans Herz gelegt. Es beginnt mit den verheißungsvollen Worten: “Ein Buch über eine neue Norm und darüber, wie man diese Norm in der Praxis anwendet, das klingt attraktiv und spannend – wenn auch sicher nicht für jeden gleichermaßen.” Neben einer enthusiastischen Einführung in die Norm, bringt das Buch die Argumente mit, warum die Norm ihren Preis wert ist und sich die Investition schnell auszahlt (ROI). Mit anderen Worten werden Sie sich nach dem Erwerb des Buchs also doch noch wenigstens einzelne Teile der ISO/IEC/IEEE 29119 beschaffen wollen (so geschehen bei mir).

Und um den Erwerb kommen Sie nicht herum. Anders als Nomen der ISO 25000-Reihe, zu der hier detaillierte Inhalte veröffentlicht sind https://iso25000.com, gibt es das für die Reihe der ISO 29119 nicht.

Inhalte der ISO/IEC/IEEE 29119-3:2021

Die Norm beschreibt folgende Dokumente:

• Test policy
• Organizational test practices
• Test plan
• Test status report
• Test completion report
• Test model specification
• Test case specification
• Test procedure specification
• Test data requirements
• Test environment requirements
• Test data readiness report
• Test environment readiness report
• Actual results
• Test results
• Test execution log
• Incident report

Es werden zuerst alle Dokumenttypen inhaltlich erläutert. In einem weiteren Abschnitt werden alle Informationselemente bezüglich der Notwendigkeit ihrer Verwendung aufgeführt. Diese Differenzierungen gibt es:

• verpflichtend
• empfohlen
• möglich

Dann folgt zu jedem Dokumenttyp je ein Beispiel für ein agiles und ein klassisches Projekt. Um abschließend den Umstieg von der IEEE 829 zu erleichtern, ist ein Mapping zwischen beiden Normen Teil der ISO/IEC/IEEE 29119-3.

Die erläuternden Kapitel verweisen wechselseitig aufeinander und führen auf, welche Informationen jeweils auch in andere Dokumente eingegliedert werden könnten, sollte man sich für den Wegfall einzelner Dokumente entscheiden. Sinnvolles Tailoring unter Erhalt des Geistes der Norm wird also immer schon mitgedacht und vermittelt.

Entscheidende Neuerung in dieser Version: Das Konzept “test model” ersetzt das Konzept “test condition”. Ich gehe davon aus, dass das in der Fachwelt umfänglich diskutiert wird, daher soll es in diesem Beitrag kein Thema sein.

Die Norm eignet sich besonders auch als Basis zur Ausgestaltung eines Auftrags, wenn Software Test durch einen Vertragspartner behandelt werden soll.

Kritik an der ISO/IEC/IEEE 29119-3:2021

Bei aller Begeisterung muss ich als Qualitätssicherer allerdings auch Kritik äußern:

• Sehr detailliert werden die geforderten Angaben aufgeführt. Das vermittelt das Gefühl, dass weitere Informationen überflüssig sind. Im Bereich der Testausführungsdokumentation fehlt mir aber eine Referenz auf die Version des Testlings (System Under Test, Application Under Test, Device Under Test etc.). Hier und da werden unpräzise Versionsbezeichnungen verwendet. In Projekten mit Iterationen hat mich aber die Erfahrung gelehrt, dass exakte build-Bezeichnungen zum Nachvollziehen von Test-, Fehler- und Reparaturverläufen Gold wert sind.
• Dass sich hinter der Bezeichnung “incident report” der allgemein bekannte “bug report” verbirgt, wird erst spät in den beschreibenden Kapiteln eingeführt. Das ist verwunderlich, da in der Folge dann ganz selbstverständlich über “bug-tracking-tools” geschrieben wird.
• Als QS-Ingenieur lese und prüfe ich Dokumente ganzheitlich. Im Fall der 29119-3:2021 haben mich sprachliche Auffälligkeiten gestört. Besonders in den Beispielen finden sich verschachtelte Bandwurmsätze, fehlerhafte Grammatik und Flüchtigkeitsfehler (typos).
• In den beschreibenden Kapiteln findet sich keine gute Abgrenzung zwischen Produktrisiken im Sinne von “risk based testing” und Projektrisiken des Entwicklungs- oder Testprojekts. Beispielrisiken sind zum Großteil nur die Beschreibung von Situationen, die zu Schäden führen können, anstatt der eigentlichen Schäden. So ist “Unverständliches Handbuch” kein Schaden. “Verschwendeter Dünger” ist ein Schaden, der u.a. durch ein unverständliches Handbuch ausgelöst werden kann. Ein Risiko ist aber als Risiko = Schadenschwere x Schadensauftretenswahrscheinlichkeit definiert. Ohne konkret benannten Schaden kann ich also auch kein Risiko benennen. Sicher ist die  ISO/IEC/IEEE 29119-3 keine Norm zum Risikomanagement. Falsche Beispiele erschweren aber das ohnehin für viele ungewohnte Denken in Risiken.
• In der Einführung der Beispiele wird erklärt, dass sie nicht untereinander konsistent sind. Jedes sei als einzelnes für sich zu sehen. Das finde ich ungünstig, da die Dokumente für zwei zuvor skizzierte Beispielfirmen beschrieben sind. Zur Verdeutlichung wäre Konsistenz innerhalb jeder Beispielfirma schon günstig. Vermutlich wollte man sich nicht der Gefahr aussetzen, Inkonsistenzen übersehen zu haben. Denn die Beispiele sind teilweise in sich schon nicht konsistent. Der erfahrene Tester wird das aber erkennen und in seinen eigenen Dokumenten korrigieren.

Fazit

Die 29119-3 ist sehr praxisnah und bringt ausführliche Beispiele mit, die für agile oder klassische Projekte leicht angepasst und verwendet werden können. Ich finde die Norm nützlich und hilfreich und dieses Urteil ist durch die genannten Kritikpunkte nicht eingeschränkt.