Warum Testkonzepte oft kein Testkonzept sind

Viele Testkonzepte sind keine. Sie zitieren die Testpyramide, definieren Unit- und Integrationstests und wiederholen Inhalte aus dem ISTQB-Foundation-Lehrbuch. Das Bundesverwaltungsamt bringt es auf den Punkt: “Das Testkonzept an sich gibt es nicht.”

Das Boilerplate-Problem

In der Praxis finden sich häufig Dokumente von 30 oder 50 Seiten, die grösstenteils projekt-unabhängig sind. Erklärungen zur Testpyramide. Definitionen der Teststufen. Allgemeine Aussagen zu Testautomatisierung. Hinweise auf das V-Modell. Diese Inhalte gehören in ein Onboarding-Wiki, nicht in das Steuerungsdokument eines konkreten Projekts.

Martin Klonk formuliert in Informatik Aktuell: “Leider entstehen dann […] Konvolute, die niemanden wirklich weiterhelfen und die vor allem ausser dem Autor kaum noch jemand später in die Hand nimmt.”

Was die Standards wirklich fordern

ISTQB CTFL v4.0.1 formuliert in Prinzip 6: “Testing is context dependent. There is no single universally applicable approach to testing.” IEEE 829 verlangt 16 Pflichtklauseln, davon mindestens fünf zwingend projektspezifisch — darunter Environmental Needs, Staffing and Training Needs und Risks and Contingencies. ISO/IEC/IEEE 29119-3 definiert Pflicht-Sections für Kontext, Risk Register, Kommunikation, Staffing und Schedule.

Keiner dieser Standards verlangt, dass ein Konzept die Testpyramide erklärt. Alle drei verlangen, dass es das Projekt beschreibt.

Was wirklich hineingehört

Automatisierungsstrategie. Welche Tests werden automatisiert, welche nicht? Lohnt sich Automatisierung bei einer einmaligen Migration? Gibt es Tests, die genau zwei- oder dreimal laufen? Diese Antworten entscheiden über Tooling und Return on Investment.

Regressionsabsicht. Tests für Regression haben andere Anforderungen als Tests für eine einmalige Abnahme. Stabilität, Wartbarkeit und Laufzeit zählen im ersten Fall kritisch, im zweiten kaum.

Testumgebungen. Was ist der Zweck jeder einzelnen Umgebung? Welche Aktionen sind dort erlaubt? Welche Daten dürfen dort liegen? Welche Produktions-Artefakte stehen zur Verfügung — und welche nicht? Hettwer Beratung formuliert: “Die Organisation der Testumgebung ist für jedes Projekt individuell festzulegen.”

Testdaten. Echtdaten aus Produktion sind in den meisten Fällen DSGVO-rechtlich unzulässig. Der Bundesbeauftragte für Datenschutz definiert eine klare Reihenfolge: zuerst synthetisch, dann anonymisiert, dann pseudonymisiert — Echtdaten erst, wenn alle anderen Wege ausgeschlossen sind. Diese Reihenfolge gehört in jedes Testkonzept, das personenbezogene Daten berührt.

Skills im Team. Welche Rollen sind besetzt? Gibt es Fachtester? Gibt es Testautomatisierer? Stehen Entwickler für Test-Support bereit? Welche Tech-Stacks beherrscht das Team — Python, JavaScript, Java? Ein Konzept, das Selenium-Java vorsieht, scheitert in einem Team aus Pytest-Profis, bevor es startet.

Tech-Stack. Welche Sprachen, Frameworks, CI/CD-Pipelines und Reporting-Tools sind im Einsatz? Welche Tooling-Entscheidungen passen zum bestehenden Stack? Diese Antworten sind nicht generisch ableitbar — sie hängen am konkreten System under Test.

Warum es zählt

Der World Quality Report 2025/26 von Capgemini nennt einen zentralen Schmerzpunkt der Branche: 60 Prozent der Organisationen kämpfen mit sicheren, skalierbaren Testdaten. Daran scheitern Projekte — nicht am Mischverhältnis der Testpyramide.

Selbst Mike Bland, der die berühmte 70/20/10-Regel bei Google mitgeprägt hat, räumt heute ein: “Yes, these numbers essentially were pulled out of a hat.” Spotify nennt die Pyramide für Microservices “actively harmful”. Martin Fowler relativiert seinen eigenen Beitrag von 2012. Der Konsens der Praxis ist eindeutig: Kontext schlägt Schema.

Drei Fragen für jedes Testkonzept

Steht im Dokument etwas, das in jedem anderen Projekt genauso stehen könnte? Dann gehört es nicht hinein.
Beantwortet das Dokument, was in welcher Umgebung mit welchen Daten getestet werden darf? Wenn nicht: zentraler Inhalt fehlt.
Hätten externe Leser nach der Lektüre eine klare Vorstellung von Risiken und Verantwortlichkeiten? Wenn nicht: Steuerungsfunktion fehlt.

Ein Testkonzept ist ein Steuerungsdokument für ein konkretes Projekt. Wer das ernst nimmt, schreibt andere Konzepte — kürzer dort, wo das Lehrbuch reicht, und länger dort, wo es um Umgebungen, Daten, Skills und Risiken geht. So entstehen Konzepte, in denen Tests Klarheit schaffen statt Seiten zu füllen.

Quellen

Sie schreiben gerade ein Testkonzept für ein konkretes Projekt? Im UTAA-Workshop arbeiten wir die projektspezifischen Inhalte heraus, die Standards verlangen. Mehr zur Methode oder direkt anfragen.