Definition
Internationale Norm-Familie für Software-Testing. Sechs Teile: Konzepte, Prozesse, Dokumentation, Testtechniken, Keyword-Driven Testing, Continuous Testing. Definiert einen risikobasierten Test-Lebenszyklus mit klaren Rollen, Artefakten und Metriken. Wichtige Brücke zwischen Entwicklungsmodellen (V-Modell, Agile, DevOps) und qualitätsgesicherten Software-Auslieferungen.
In der Praxis
Die 29119 hat ein Imageproblem: Agile Teams halten sie für Wasserfall-Bürokratie, klassische Tester für eine Selbstverständlichkeit — beide liegen daneben. Die Normenreihe ist modellneutral; sie beschreibt, was ein geordneter Testprozess leisten muss, nicht in welchem Entwicklungsmodell er läuft. Der praktische Wert zeigt sich in drei Situationen. Erstens beim Aufbau einer Testorganisation: Die Norm liefert die Rollen, Artefakte und Prozessschritte, damit Testen nicht vom Einzelkämpfer abhängt. Zweitens in Audits und Kundenverhandlungen: „Wir testen nach 29119-Logik" ist eine belastbare Aussage — Testplan, risikobasierte Auswahl, dokumentierte Ergebnisse, Abschlussbericht. Drittens bei der Zusammenarbeit mit externen Testdienstleistern, weil beide Seiten dieselbe Sprache sprechen. Der häufigste Fehler: die Dokumentationsvorlagen aus Teil 3 eins zu eins übernehmen, statt risikobasiert zuzuschneiden — die Norm verlangt Angemessenheit, keinen Papierkrieg. Und nein: Eine Zertifizierung nach 29119 gibt es nicht; sie ist eine Verfahrensnorm, kein Zertifizierungsschema.
Verwandte Begriffe
Häufige Fragen zu ISO/IEC/IEEE 29119
Was ist der Unterschied zwischen ISO/IEC/IEEE 29119 und den ISTQB-Lehrplänen?
Die 29119 ist eine Norm: Sie definiert Konzepte, Prozesse, Dokumentation und Techniken des Software-Testens — also das Regelwerk, an dem sich Organisationen ausrichten können. ISTQB ist ein Personenzertifizierungsschema: Die Lehrpläne bilden Tester aus und prüfen ihr Wissen auf Stufen wie Foundation oder Advanced Level. Die Inhalte überlappen sich bewusst — der ISTQB hat seine Terminologie weitgehend an der Normenwelt ausgerichtet —, aber sie beantworten verschiedene Fragen: Die Norm sagt, wie ein Testprozess aussehen sollte; das Zertifikat sagt, dass eine Person Testwissen nachweisen kann. Praktisch ergänzt sich das gut: Die 29119 als Rahmen für die Testorganisation, ISTQB-Schulungen als Qualifizierung der Mitarbeiter darin. Wer nur zertifizierte Leute ohne Prozessrahmen hat, bleibt personenabhängig; wer nur den Prozess ohne Know-how hat, bleibt Papier.
Wie ist die ISO/IEC/IEEE 29119 aufgebaut — und ist sie zertifizierbar?
Die Normenreihe gliedert sich in sechs Teile: Teil 1 legt die allgemeinen Konzepte und Begriffe fest, Teil 2 beschreibt die Testprozesse auf Organisations-, Management- und Teststufen-Ebene, Teil 3 definiert die Testdokumentation, Teil 4 die Testtechniken, Teil 5 das Keyword-Driven Testing und Teil 6 das Testen in Continuous-Testing- beziehungsweise DevOps-Umgebungen. Das Herzstück ist Teil 2 mit dem risikobasierten Ansatz: Umfang und Tiefe des Testens folgen dem Risiko des Produkts, nicht einem starren Schema. Zertifizierbar ist die Norm nicht — sie enthält Prozess- und Verfahrensanforderungen, aber kein Zertifizierungsschema; ein „29119-Zertifikat" wäre Etikettenschwindel. Was möglich und sinnvoll ist: die Konformitätserklärung im eigenen Qualifizierungs- oder Ausschreibungskontext und der Nachweis im Kundenaudit anhand der dokumentierten Testartefakte (ISO/IEC/IEEE 29119, Teile 1–6).
Wie setzen wir die 29119 pragmatisch um, ohne in Dokumentationsbürokratie zu ersticken?
Arbeiten Sie die Ebenen von oben nach unten ab. Erstens die Organisationsebene: eine knappe Testrichtlinie, die Strategie, Rollen und Qualitätskriterien festlegt — zwei Seiten reichen. Zweitens die Managementebene: pro Projekt oder Release einen risikobasierten Testplan, der aus der Risikobetrachtung heraus festlegt, was wie intensiv getestet wird; die Vorlagen aus Teil 3 der Norm sind dafür ein guter Startpunkt, den Sie auf Ihren Bedarf kürzen. Drittens die Durchführungsebene: Testfälle mit Vorbedingungen, Daten und erwarteten Ergebnissen, Ergebnisprotokolle und ein Abschlussbericht mit Bewertung gegen die Freigabekriterien. Viertens die Verzahnung: In agilen Teams wandern diese Artefakte ins Sprint- und Release-Modell, in klassischen Projekten in die Teststufen — die Norm lässt beides zu. Und fünftens: Jedes Dokument, das niemand liest, wird gestrichen — die Norm verlangt Angemessenheit, nicht Vollständigkeit um jeden Preis (ISO/IEC/IEEE 29119-3).