6 Testdokumentation

6.1 Nutzung von Standards

Die Richtlinie IEEE 82912 „Standard for Software Test Documentation” wurde nach
der Spezifikation 1982 im Folgejahr 1983 herausgegeben und 1991 in einer überar-
beiteten Version veröffentlicht und definiert Inhalt und Format von acht grundle-
genden Dokumenten, die den gesamten Testprozess abdecken. Dieser Standard
wurde auch von ANSI (American National Standards Institute) übernommen. Die
letzte Überarbeitung der IEEE 829 erfolgte 2008 (was aber von uns in diesem Kapi-
tel nicht berücksichtigt wurde, da wir bisher mit der vorhergehenden Version ge-
arbeitet haben).
Der Standard definiert den Zweck (Purpose), Aufbau und Inhalt (Outline) jedes
der grundlegenden Dokumente. Diese decken die Bereiche Testplanung, Testspezi-
fikation und Testreporting ab und sind sowohl für die Dokumentation in der Ent-
wicklungsphase einer Software als auch für das Testen von nachfolgenden Soft-
wareversionen geeignet.
Bei den acht Dokumenten handelt es sich um:
1. Testplan (Test Plan)
2. Spezifikation des Testdesigns (Test Design Specification)
3. Testfallbeschreibung (Test Case Specification)
4. Spezifikation des Testablaufs (Test Procedure Specification)
5. Konfigurationsbericht des Testobjekts (Test Item Transmittal Report)
6. Testbericht (Test Log)
7. Fehlerbericht (Test Incident Report)
8. Abschlussbericht (Test Summary Report)
Die Richtlinie “829 IEEE Standard for Software Test Documentation” ist universell
bei allen Arten von Software in allen Stadien der Softwareentwicklung einsetzbar.
Sie ist unabhängig von der jeweils gewählten Testmethode und somit z.B. im
Rahmen eines “White Box Test” oder eines “Black Box Test” gleichermaßen nütz-
lich. Auch die performanceorientierten Ausprägungen eines “Black Box Test” wie

12 Die Definition IEEE 829 ist ein veröffentlichter Standard, der einen Satz von 8 Basis Do-
kumenten zur Dokumentation von Software-Tests beschreibt

A. Vivenzio, D. Vivenzio, Testmanagement bei SAP-Projekten,

DOI 10.1007/978-3-8348-2142-3_6, © Springer Fachmedien Wiesbaden 2013
44 6 Testdokumentation

z.B. ein “Volume Test” oder ein “Stress Test” profitieren von dieser standardisier-
ten Vorgehensweise.
Die Bedeutung der Richtlinie “829 ANSI/IEEE Standard for Software Test
Documentation” wird offenbar, wenn man bedenkt, dass sich auch der ISO-9000
Standard auf ANSI Standards als Basis für die Testdokumentation bezieht und die
meisten Zertifizierungsprozesse zumindest die Verwendung eines Teils dieser
Dokumente fordern.

6.2 Der Testplan

Ziel und Zweck (Purpose) der Softwareentwicklung ist die Umsetzung der betrieb-
lichen Anforderungen in ein ausführbares Produkt. Die Teststrategie ist kein
Selbstzweck, sondern ordnet sich dem gleichen Ziel unter. Die Strategie beim Tes-
ten findet ihren Niederschlag in einem Testplan, der für jedes Projekt gesondert zu
erstellen ist.
Die wesentliche Informationsquelle zur Erstellung dieses Plans ist das Lastenheft
der Software. Es kommt im Wesentlichen darauf an, die dort niedergelegten For-
derungen in Testszenarien für die Software umzusetzen. Der Testplan bezieht sich
als übergeordnetes Dokument auf die Systemebene und betrachtet daher die
Komponenten und Subsysteme als Ganzes.
Sollte ein Pflichtenheft nicht vorhanden sein, so können diverse andere Dokumen-
te als Basis für die Funktionalitätsbeschreibung dienen, z.B. Entwicklungsdoku-
mentation, Anwenderhandbuch, usw.
Die prinzipiellen Anforderungen an den Testplan als fundamentales Dokument
der Richtlinie 829 sind Korrektheit, Konsistenz, Vollständigkeit und Klarheit
(Correct, Consistent, Complete, Clear).
Der Testplan beschreibt das Ziel, die Teststrategie, die benötigten Ressourcen und
den geplanten Ablauf der Testaktivitäten. Er benennt die Testobjekte, die zu tes-
tenden Funktionalitäten, die abzuarbeitenden Testaufgaben und die Zuordnung
von Verantwortlichkeiten. Außerdem beinhaltet der Testplan eine Risikoabschät-
zung.
Der Testplan nach IEEE 829 gibt folgende Struktur (Test Plan Outline) vor:
1. Test Plan ID (Test Plan Identifier)
2. Einführung und Referenzen (Introduction/References)
3. Testobjekte (Test Items)
4. Zu testende Funktionalitäten (Features to be Tested)
5. Nicht zu testende Funktionalitäten (Features not to be Tested)
6. Teststrategie (Approach)