Hilft die ISO/IEC TR 29119-6 zum Software-Testing auch in agilen Projekten?

Die ISO/IEC TR 29119-6 soll dabei helfen, auch bei agilen Software-Projekten die Anforderungen der Normenfamilie ISO 29119 (also der anderen Familienmitglieder) zu erfüllen. Diesen Anspruch lässt sie bereits im Titel erkennen: „Guidelines for the use of ISO/IEC/IEEE 29119 (all parts) in agile projects“.

Ob die Norm diesem Anspruch auch gerecht wird und ob Sie überhaupt 173,30 EUR für den Kauf der ISO/IEC TR 29119-6 ausgeben sollten, erfahren Sie in diesem Artikel.

1. Kontext und Ziel der ISO 29119-6

a) Um was es geht

Die Normenfamilie ISO 29119 beschreibt Best Practices zum – so der Titel – Software and Systems Engineering – Software Testing. Diese Best Practices sind zwar unabhängig vom konkreten Entwicklungsmodell, aber viele erinnern an ein V-Modell-artiges Vorgehen.

Deshalb stellen sich in der agilen Software-Entwicklung oft folgende Fragen:

• Wenn man die Best Practices einer agilen Entwicklung befolgt, ist man dann auch konform mit den Vorgaben der Normenfamilie ISO 29119?
• Wie wendet man die Vorgaben dieser Normenfamilie in der agilen Entwicklung an?

Diese Überlegungen sind auch für Entwickler medizinischer Software zumindest indirekt relevant, weil die IEC 62304 auf die ISO 12207 verweist (Systems and Software Engineering – Software Life Cycle Processes). Und die ISO 12207 referenziert wiederum alle Teile der ISO 29119.

b) Was die ISO 29119-6 erreichen möchte

Die ISO 29119-6 hat sich zum Ziel gesetzt, die oben genannten Fragen zu beantworten. Dazu möchte sie

• die agilen Konzepte auf die ISO 29119-2 abbilden („mappen“),
• erklären, wie man die ISO 29119-2 für die agile Entwicklung anpassen kann und
• zeigen, wie sich die Templates der ISO 29119-3 für die Testdokumentation bei der agilen Entwicklung anwenden lassen.

2. Aufbau und Inhalt der ISO 29119-6

a) Kapitelstruktur

Die Kapitelstruktur der Norm ist eher ungewöhnlich. Abgesehen von den üblichen drei ersten Kapiteln (Anwendungsbereich, normative Verweise, Begriffsdefinitionen) besteht sie nur aus einem einzigen Hauptkapitel.

Nahezu der ganze normative Text entfällt auf das Kapitel 4.2. In diesem Kapitel versucht die Norm, insgesamt 62 „Agile practices and artefacts“ auf die ISO 29119-2 zu mappen.

b) Kapitel 4.2: Mapping der agilen Konzepte auf die ISO 29119-2

Dieses Mapping erfolgt – wo möglich – in tabellarischer Form, wie die folgenden Beispiele zeigen:

Beispiel 1: Acceptance criteria

Agile concept	ISO 29119-2: clause	Mapping details
Acceptance criteria	8.2.4.2 Create test model	Acceptance criteria would be created as a test model that lists atomic requirements to be met before a user story can be accepted as “done”

Beispiel 2: Burn-down and burn-up charts

Das zweite Beispiel zeigt, dass auch ein agiles Konzept von mehreren Kapiteln der ISO 29119-2 abgedeckt werden kann:

Agile concept	ISO 29119-2: clause	Mapping details
Burn-down and burn-up charts	7.3.4.3 Monitor	Testers contribute to burn-down and burn-up charts by charts executing test cases that verify whether each user story’s acceptance criteria have been met. This daily test execution progress would be tracked via the monitor (TMC2) activity, task a, which focuses specifically on collecting metrics to track progress towards completion.
	7.3.4.5 Report	The status of testing, including progress towards testing on each user story, would be reported via the report activity.

Beispiel 3: Epic

Es gibt auch agile Konzepte, für die es kein Mapping auf die ISO 29119-2 gibt. Dazu zählen neben dem Epic auch die Konzepte „Empowered team“ und „Pair programming“.

c) Annex B: Mapping der ISO 29119-2 auf die agilen Konzepte

Das umgekehrte Mapping beschreibt der Anhang B. Dieser sieht beispielsweise wie folgt aus:

Clause	Activity	Agile practices and artefacts covered in Clause 4
7 Test management process	7.2.4.3 Organize test plan development	4.2.3 Acceptance test-driven development 4.2.6 Behaviour-driven development 4.2.11 Continuous delivery and development …

3. Nutzen der ISO 29119-6

a) Es gibt ein Mapping zwischen agilen Konzepten und der ISO 29119

Falls jemand wissen möchte, wie Konzepte der agilen Entwicklung mit denen der ISO 29119-2 „mappen“ (und vice versa), dann ist die ISO 29119-6 hilfreich.

b) Die Norm zeigt Beispiele für Dokumente

Die Norm zeigt Beispiele für folgende Dokumente:

1. „Session Sheet“ mit der Spezifikation eines Software-Test-Cases
2. Defect report, der die Akzeptanzkriterien und die Ergebnisse des Tests zeigt
3. Daily Test Progress Report mit Burndown-Chart und Übersicht über offene und erledigte Tests und ihre Ergebnisse
4. Test Completion Report.

4. Kritik an der ISO 29119-6

a) Eingeschränkte konzeptionelle Integrität

Bereits die Kapitelübersicht bzw. die Übersicht über die 62 (!) „Agile practices and artefacts“ in Kapitel 4.1 verdeutlicht das Problem: Die Norm wirft alles in einen Topf:

• Best Practices
• Aktivitäten
• Konzepte
• Dokumente
• Rollen

Dadurch entsteht nicht nur eine unübersichtlich lange Liste. Es erschwert auch das Mapping, denn für das Mapping auf die ISO 29119-3 wären nur die Dokumente relevant. Zudem führt dieser Ansatz dazu, dass es Elemente in dieser Liste gibt, die keine Entsprechung in der ISO 29119-2 haben (können) und somit die Liste unnötig aufblähen.

Andere Normen, wie die ISO 15289, verwenden viel Energie darauf, eine Ordnung in das Begriffschaos im Bereich „Software Life Cycle Information“ zu bringen. Dieser Ordnungswille ist bei der ISO 29119-6 nicht in dem Maße erkennbar.

b) Mangelnde Nachvollziehbarkeit …

… der Struktur

Der Mangel an Struktur und innerer Logik spiegelt sich auch in der Kapitelstruktur wider. 62 Unterkapitel in alphabetischer Reihenfolge zu sortieren ist zumindest ungewöhnlich. Normen wie die ISO 9241 weisen darauf hin, dass in hierarchischen Informationsstrukturen nicht mehr als acht Elemente enthalten sein sollen, um hinreichend benutzungsfreundlich zu sein.

Die ISO 29119-6 soll helfen, zu verstehen, wie die ISO 29119 auf die agile Entwicklung anwendbar ist. Dies geht bereits aus der Einleitung von ISO 29119-6 hervor. Das Mapping von der Norm auf die agilen Konzepte wird jedoch nicht im normativen Teil der Vorschrift behandelt, sondern im nicht-normativen Anhang.

… der Auswahl von Elementen

Es ist unklar, nach welchen Kriterien die Autoren die „Agile practices and artefacts“ ausgewählt haben. Die Auswahl erinnert an eine Sammlung von Buzzwords zum Thema „Agile Development“.

Folglich ist nicht nachvollziehbar, wie vollständig die Kriterien sind. Dass sie vollständig sind, ist im Grunde auch gar nicht möglich.

Umgekehrt überrascht, dass die Norm „Feature Toggles“ zu den agilen Konzepten zählt.

… des Mappings

Ebenso wenig ist nachvollziehbar, wie die Autoren zu den konkreten Mappings und den „Mapping Details“ gelangen. Ob beispielsweise ein Testmodell („Create test model“) im Rahmen des Backlog-Managements erstellt wird, hängt sicher auch davon ab, ob es um ein Product Backlog oder ein Sprint Backlog geht.

Noch weniger hilfreich wird es, wenn die ISO 29119-6 ein agiles Konzept wie „Behaviour-driven development“ einfach „all clauses“ der ISO 29119-2 zuordnet.

c) Eingeschränkter Nutzen

Nicht nur ein unspezifisches Mapping wie „all clauses“ schränkt den Nutzen ein:

Einer der häufigsten Use Cases der Norm hätte sein können, dass eine agil entwickelnde Organisation darlegen muss, dass sie trotz Agilität (als ob das ein Widerspruch wäre) übliche Best Practices befolgt, wie sie beispielsweise die ISO 29119-2 benennt.

Zwar verlinkt die Norm im Anhang die Best Practices der ISO 29119-2 mit den „agile practices and artefacts“. Die Frage, ob damit die Anforderungen der ISO 29119-2 erfüllt werden, beantwortet die ISO 29119-6 nicht. Aber genau das ist der entscheidende Punkt, insbesondere in Audit-Situationen.

d) Gefahr der Irreführung

Es ist sogar zu befürchten, dass die Norm in Audit-Situationen abträglich ist. Beispielsweise ist eine Spezifikation eines Testfalls, wie in Anhang D gezeigt, problematisch:

Ein Testfall ohne Beschreibung der Vorbedingungen (außer der Software-Version) und ohne Beschreibung der Akzeptanzkriterien genügt den Vorgaben anderer Software-Normen (wie der IEC 62304, aber auch der ISO 29119-Familie) nicht.

Zudem lässt das Mapping der ISO 29119-2 auf agile Konzepte wie Scrum die Leser:innen vermuten, dass beides vergleichbar wäre und einander zugeordnet werden könne. Dabei ist Scrum ein Modell für Projekte: Es geht darum, wie man bei einem (Entwicklungs-)Projekt Aufgaben (Tasks) erstellt, aufteilt, abarbeitet und dabei immer besser wird. Scrum macht weder eine Aussage über Prozesse noch über Methoden der Software-Entwicklung. Scrum sagt nicht, wie eine Software-Architektur zu erstellen oder Testfälle abzuleiten sind.

5. Fazit, Zusammenfassung

a) Dank an die Autoren

Normen zu schreiben ist eine aufwändige und oft undankbare Aufgabe. Daher sollte zunächst Dank an die Autoren gehen, die sich die Arbeit gemacht haben zu beschreiben, wie die ISO 29119-2 in agilen Projekten angewendet werden kann.

Darüber, wie gut dieses Ziel durch ein Mapping der ISO 29119-2 mit agilen Konzepten tatsächlich erreicht werden kann, lässt sich zumindest streiten.

b) ISO 29119-6: Eine wirklich hilfreiche Norm?

Die ISO 29119-6 kann genutzt werden, um Zweiflern zu begründen, dass klassische Best Practices und agile Konzepte nicht im Widerspruch stehen – falls es diese Zweifler noch gibt.

Die ISO 29119-6 bleibt den Beweis schuldig, dass die Anwendung aller in der Norm genannten agilen Konzepte die Anforderungen z. B. einer ISO 29119-2 erfüllt.

Nach der Lektüre stehen die Leser:innen ratlos da, denn eine Handlungsanleitung bietet die Norm nicht. Auch wird sie ihrem Anspruch nicht gerecht, verständlich zu sein, wenn die Leser:innen nicht alle Teile der ISO 29119 (gut) kennen. Denn ohne diese kann man die Aussagen der ISO 29119-6 nicht nachvollziehen.

c) Kaufen oder nicht kaufen?

Wenn Sie ein beschränktes Budget haben und sich zwischen der ISO 29119-2 und der in diesem Artikel besprochenen Norm ISO 29119-6 entscheiden müssen: Kaufen Sie die ISO 29119-2.

---

Das Johner Institut unterstützt Medizinproduktehersteller bei der agilen und gesetzeskonformen Entwicklung ihrer Software. Damit gelingt den Herstellern eine schlanke Dokumentation, das erfolgreiche Bestehen von Audits und Zulassungen sowie eine sichere und rasche Vermarktung ihrer Produkte. Nehmen Sie Kontakt auf (z. B. über das Kontaktformular oder per E-Mail) und erfahren Sie mehr.