Was in ein Testkonzept gehört, und was ein Entscheidungsdokument daraus macht

Es gibt einen Dokumententyp, den fast jedes Projekt hat und fast niemand liest: das Testkonzept. Meistens ist es zwanzig bis vierzig Seiten lang, entsteht kurz vor der Testphase, beschreibt in allgemeinen Worten Testarten und Tools und wird nie wieder geöffnet. Es erfüllt eine Formalie, keine Funktion.

Das liegt selten am Autor. Es liegt daran, dass die Frage falsch gestellt war. Ein Testkonzept ist kein Beschreibungsdokument, sondern ein Entscheidungsdokument. Es legt fest, was geprüft wird, wie tief, mit welcher Begründung und woran man das Ende erkennt. Alles andere ist Beiwerk.

Der Begriff zuerst: Testkonzept oder Testplan?

Im deutschen Sprachgebrauch hat sich „Testkonzept“ durchgesetzt. Die internationale Norm kennt diesen Begriff nicht, sie spricht vom Test Plan. Das ist keine Übersetzungsfrage, sondern eine Bedeutungsverschiebung: „Plan“ betont, dass das Dokument Aussagen über die Zukunft trifft, die man später gegen die Wirklichkeit halten kann. „Konzept“ klingt nach einmaliger Ideensammlung.

Wir verwenden im Kundenkontakt weiter „Testkonzept“, weil danach gefragt wird, meinen aber den Test Plan im Sinne der Norm. Wer Unterlagen für ein Audit oder eine internationale Konzernmutter aufbereitet, sollte den englischen Begriff kennen, sonst sucht die Gegenseite nach einem Dokument, das scheinbar fehlt.

Woher die Struktur kommt

Die maßgebliche Normenreihe ist ISO/IEC/IEEE 29119, „Software and systems engineering — Software testing“. Sie besteht aus mehreren Teilen, die getrennt gepflegt werden:

• Teil 1 (2022), General concepts: Begriffe und Grundkonzepte des Testens.
• Teil 2 (2021), Test processes: das Prozessmodell. Kernstück der Reihe.
• Teil 3 (2021), Test documentation: die Dokumentvorlagen, unter anderem für den Test Plan.
• Teil 4 (2021), Test techniques: die Testentwurfsverfahren, von Äquivalenzklassen bis Zustandsübergangstest.
• Teil 11 (2020), Guidelines on the testing of AI-based systems: ein Technical Report zum Testen KI-basierter Systeme.

Teil 2 definiert drei Prozessebenen, und diese Dreiteilung erklärt, warum so viele Testkonzepte unscharf wirken. Es gibt den organisatorischen Testprozess, der festlegt, wie im Unternehmen grundsätzlich getestet wird. Es gibt die Testmanagement-Prozesse, also Planung, Überwachung und Steuerung sowie Abschluss. Und es gibt die dynamischen Testprozesse, in denen tatsächlich entworfen, aufgebaut, ausgeführt und berichtet wird.

Ein Testkonzept gehört auf die mittlere Ebene. Es übersetzt die allgemeinen Vorgaben des Unternehmens in Entscheidungen für ein konkretes Vorhaben und gibt der unteren Ebene die Vorgaben, nach denen sie arbeitet. Wer das vermischt, schreibt entweder eine Hausordnung, die für kein Projekt konkret genug ist, oder eine Testfallsammlung, die für die Steuerung zu detailliert ist.

Die Bereiche, die ein Testkonzept abdecken muss

Teil 3 der Norm liefert eine Vorlage. Sie lässt sich auf sieben Bereiche verdichten, und diese sieben finden sich in jedem Projekt wieder, ob man die Norm kennt oder nicht:

• Kontext: Was wird getestet, in welchem Umfeld, mit welchen Annahmen, unter welchen Beschränkungen. Hier steht auch, was ausdrücklich nicht Gegenstand ist. Der Ausschluss ist oft wertvoller als die Aufzählung.
• Kommunikation: Wer bekommt welche Information, wann, in welcher Form. Klingt banal, entscheidet aber darüber, ob eine schlechte Nachricht rechtzeitig ankommt.
• Risikoregister: die bewerteten Produkt- und Projektrisiken. Nicht als Anhang, sondern als Grundlage.
• Teststrategie: Testarten, Teststufen, Testentwurfsverfahren, Abdeckungsziele, Testdaten, Testumgebungen, Entry- und Exit-Kriterien, Umgang mit Abweichungen.
• Aktivitäten und Schätzungen: was zu tun ist und was es kostet, in Personentagen oder in Zeit.
• Personal und Rollen: wer was verantwortet, welche Qualifikation vorausgesetzt wird.
• Zeitplan: Meilensteine und Abhängigkeiten, insbesondere zu Zulieferungen aus der Entwicklung.

Der Bereich, an dem sich alles entscheidet

Von diesen sieben ist einer der eigentliche Kern: das Risikoregister mitsamt der daraus abgeleiteten Teststrategie. Es beantwortet die einzige Frage, die ein Testkonzept beantworten muss und die kein Tool beantworten kann: Warum prüfen wir diesen Teil tief und jenen flach?

Ohne diese Ableitung ist jede Testtiefe willkürlich. Mit ihr wird sie verhandelbar, und das ist der Punkt. Eine Geschäftsführung, die weiß, dass ein bestimmter Prozessschritt bewusst nur oberflächlich geprüft wird, weil sein Risiko als gering bewertet wurde, kann diese Entscheidung mittragen oder korrigieren. Eine Geschäftsführung, die es nicht weiß, erfährt es im Vorfall.

Der zweite Kern sind die Exit-Kriterien. Sie stehen in der Teststrategie und sie sind der Grund, warum ein Testkonzept vor dem Testen geschrieben werden muss und nicht danach. Ein Kriterium, das erst nach dem Testlauf festgelegt wird, ist kein Kriterium, sondern eine Beschreibung des Ergebnisses. Sobald die Zahlen auf dem Tisch liegen, verschiebt sich die Schwelle unbemerkt dorthin, wo man ohnehin gelandet ist.

Was nicht hineingehört

Drei Dinge blähen Testkonzepte auf, ohne sie besser zu machen:

• Test Cases. Die gehören in den Testfallbestand, nicht in das Steuerungsdokument. Ein Testkonzept legt den Autoren-Standard fest, nach dem sie geschrieben werden, und Muster, an denen man sich orientiert.
• Tool-Beschreibungen. Welches Tool wie bedient wird, gehört in eine Anleitung. Ins Testkonzept gehört nur, welche Funktion das Tool im Prozess erfüllt und was passiert, wenn es ausfällt.
• Lehrbuchtext. Erklärungen, was ein Systemtest ist, richten sich an niemanden. Wer das Dokument liest, weiß es, oder er braucht eine Schulung, kein Kapitel.

Wann es entsteht und wie lang es sein darf

Ein Testkonzept entsteht, sobald die Anforderungen so weit stehen, dass man Risiken bewerten kann, und lange bevor der erste Test Case geschrieben wird. Es ist ein lebendes Dokument: Ändert sich der Umfang, ändert sich die Risikobewertung, und damit die Teststrategie.

Zur Länge gibt es keine Norm und auch keine brauchbare Faustregel. Der Maßstab ist ein anderer: Jeder Satz muss eine Entscheidung enthalten oder eine Entscheidung begründen. Was diesen Test nicht besteht, kann weg. In der Praxis landen die meisten Projekte damit bei einer Größenordnung, die man in einer Sitzung durchsprechen kann, und genau das ist der Zweck.

Wer was macht

Qelivia erstellt das Risikobild und das Testkonzept, definiert den Autoren-Standard für die Test Cases und liefert voll ausgearbeitete Muster. Wir übernehmen Review und Abnahme des Testfallbestands sowie die Steuerung über die Testphase. Die Tests selbst führt Ihr Team durch, in Ihrem Tool oder in einer von uns bereitgestellten Umgebung. Der Grund ist fachlich: Das system- und prozessspezifische Detailwissen liegt bei Ihnen, und ohne dieses Wissen entstehen Test Cases, die formal korrekt und praktisch wertlos sind. Das Konzept orientiert sich am ISTQB-Testprozess und nutzt die Terminologie etablierter Testpraktiken. Die Struktur berücksichtigt außerdem relevante Prinzipien der Normenreihe ISO/IEC/IEEE 29119, soweit sie im jeweiligen Projektkontext anwendbar sind.

Fazit

Ein Testkonzept in diesem Sinne ist kein bürokratischer Mehraufwand, sondern die Abkürzung. Es zwingt dazu, drei Entscheidungen früh zu treffen, die sonst spät und unter Druck getroffen werden: welche Risiken wir ernst nehmen, wie tief wir deswegen prüfen und wann wir fertig sind. Wer diese drei Punkte schriftlich hat, diskutiert am Ende über Ergebnisse. Wer sie nicht hat, diskutiert über Meinungen.