Seit Jahren beschäftige ich mich mit qualitativen Maßnahmen im Bereich der Softwareentwicklung. Zwar ist mir als leidenschaftlichem Entwickler stets die Nähe zur Implementierung und zum Tooling wichtig, jedoch wurde mir in den letzten Jahren klar, dass viele Hindernisse bereits fernab von Programmierung und Tools umgangen werden können. Das kann mit einem Testkonzept erreicht werden.

Wenn wir ehrlich sind, tauchen doch stets die gleichen Fragen bei der Projektumsetzung auf. Wann testen wir? Muss ich Unit-Tests schreiben und wenn ja, wie viele? Können wir die Deadline verschieben? Diese und noch mehr solcher Fragen werden meist erst beantwortet, sobald der jeweilige Fall eintritt, und nicht langfristig im Vorhinein geplant und besprochen.

Wäre es nicht toll, wenn wir eine Möglichkeit hätten, für viele dieser auftretenden Fragen bereits zu Beginn des Projekts eine Antwort zu haben, sodass die notwendigen Maßnahmen auch tatsächlich eingeplant werden können? Willkommen beim Thema „Testkonzept“, der heilige Gral für Tester:innen und Entwickler:innen.

Bevor wir weiter in das Thema einsteigen, sei gesagt, dass es fast nicht möglich ist, hier das gesamte Spektrum des Testkonzepts darzustellen. Zudem kann aufgrund der notwendigen Flexibilität und Anpassbarkeit auch keine 1:1-Vorlage gegeben werden. Allerdings möchte ich Sie durch einige der gängigen Themen führen, die meines Erachtens in Softwareprojekten für Tester:innen, Projektmanager:innen und vor allem Entwickler:innen relevant sind.

Was ist ein Testkonzept?

Gemäß ISTQB (International Software Testing Qualifications Board), einer Vereinigung, die versucht, Softwaretests zu optimieren und zu standardisieren, versteht man unter „Testkonzept“ die Dokumentation der Testziele sowie der Maßnahmen und Zeitplanung, um diese zu erreichen, zum Zweck der Koordination von Testaktivitäten.

Ein Testkonzept ist ein durchaus hilfreiches und oftmals unterschätztes Dokument. Der Inhalt ist für mich persönlich wie eine Art Pflichtenheft, allerdings auf der Seite der Qualitätssicherung. Das bedeutet auch, dass aufgrund der Tatsache, dass im Bereich des Testens eine Art Pflichtenheft existiert, gleichermaßen mehr Gleichberechtigung und Wertigkeit für diesen Bereich des Projektteams ausgesprochen wird. Endlich werden die Testaufgaben greifbar und sind nicht nur ein Schatten der eigentlichen Implementierung.

Beim Schreiben eines Testkonzepts sind wir relativ flexibel. Letztendlich wählt man, sofern man keine Industriestandards erfüllen muss, die Themen, die einem helfen, das Projekt erfolgreich zu testen und durchzuführen. Es sollte voll mit hilfreichen Informationen sein und als Basis zur Gestaltung von Arbeitspaketen dienen, aber auch als Nachschlagewerk bei Fragen zu Abläufen und Prozessen. Das gewählte Medium kann dabei an das Projektteam angepasst werden. Sie können Testkonzepte in Word, Confluence, Notion oder anderen Systemen schreiben.

Starten wir also mit unserem fiktiven Testkonzept. Dieses befasst sich mit einem Onlineshop, also einem E-Commerce-Projekt, das implementiert werden soll.

Teststufen und Dokumente

Im Allgemeinen beinhaltet das Testkonzept alles, was es für die Maßnahmen und Zeitplanungen zu wissen gibt. Das kann, simpel betrachtet, ein mehr oder weniger langes Dokument sein. Allerdings gibt es Projekte und Industrien, in denen es Sinn ergibt, verschiedene Stufen des Projekts als eigenständige Testkonzepte umzusetzen.

Für Entwickler:innen beziehen sich die meisten Maßnahmen höchstwahrscheinlich auf quellcodebezogene Punkte, während für die End-to-End-Systemtests durchaus andere Vorgehensweisen und Voraussetzungen für das Testen relevant sind. Aufgrund dieser zum Teil sehr unterschiedlichen Handhabungen kann es sinnvoll sein, verschiedene Testkonzepte auf verschiedene Teststufen maßzuschneidern.

Hierbei wird gerne das Konzept des V-Modells (Abb. 1) in Betracht gezogen. Das V-Modell bietet eine bewährte Grundlage, um die verschiedenen Teststufen systematisch zu betrachten. Es stellt die unterschiedlichen Ebenen des Entwicklungsprozesses in einem V-förmigen Diagramm dar, wobei jede Entwicklungsstufe einer entsprechenden Teststufe gegenübergestellt wird. Diese Struktur hilft, die Komplexität von Testprozessen zu reduzieren und eine klare Zuordnung von Verantwortlichkeiten und Testaktivitäten sicherzustellen.

Im V-Modell sind die folgenden Teststufen definiert:

• Abnahmetests: Diese Tests dienen der finalen Überprüfung des Systems und stellen sicher, dass es die vertraglich vereinbarten Anforderungen erfüllt. Abnahmetests werden oft in enger Zusammenarbeit mit den Auftraggebern durchgeführt. Dabei handelt es sich nicht zwingend um detaillierte Testfälle. Abnahmetests sind eigentlich aus Sicht des Kunden zu betrachten. Was wollte der Kunde mit der Software bezwecken? Ist das nun entsprechend umgesetzt und funktioniert es für diese Fälle?

• Systemtests: Hier wird das gesamte System in einer Umgebung getestet, die der Produktivumgebung möglichst nahekommt. Ziel ist es, das Zusammenspiel aller Komponenten und Subsysteme zu überprüfen. Dabei haben wir normalerweise keinen Einblick in Abläufe und interne Strukturen und testen somit auf Basis von Blackbox Testing. Das bedeutet, wir sehen, was das System macht, aber nicht, wieso es das macht. Das Testen bezieht sich somit in der Regel darauf, ob das Gesehene dem Erwarteten entspricht. Zusätzlich sind diese Tests sehr teuer, da sie oftmals manuell durchgeführt werden und relativ lange dauern.

• Integrationstests: Auf dieser Teststufe werden die verschiedenen Komponenten und Subsysteme miteinander integriert und getestet, um sicherzustellen, dass sie nahtlos zusammenarbeiten. Wir besitzen hierbei Kenntnis über interne Strukturen und testen somit auf Basis von Whitebox Testing. Diese Stufe führt oft zu Missverständnissen, da es nicht klar ist, ob es sich um Integrationstests verschiedener z. B. Microservices zueinander handelt oder um Integrationstests der einzelnen internen Softwaremodule einer Anwendung. Deshalb könnte man aus dieser Stufe auch zwei Stufen machen, nämlich die Systemintegrationstests und die Komponentenintegrationstests.

• Komponententests: Die niedrigste Teststufe, bei der einzelne Softwaremodule isoliert getestet werden. Komponententests sind besonders wichtig, um Fehler frühzeitig zu identifizieren und zu beheben. Hier finden sich in der Regel unsere klassischen Unit-Tests auf Basis von Whitebox Testing. Diese Teststufe ist sehr günstig, da Tests automatisiert in Bruchteilen von Sekunden ausgeführt werden. Deshalb sollte besonders diese Stufe mit vielen Tests bestückt werden. Sie dient auch als Basis der Testing-Pyramide mit einem breiten Fundament, also einer größeren Anzahl von Tests als in höheren Ebenen.

Sofern man sich dazu entscheidet, einzelne Testkonzepte pro Stufe umzusetzen, hat man meist ein zusätzliches übergeordnetes Testkonzept, das Master-Testkonzept.

Bei den Projekten, in denen ich involviert bin, genügt es oftmals, sich auf Systemtests und Komponententests zu stützen. Diese decken in der Regel die wichtigsten Bereiche ab, die auch kleinere bis mittlere Teams in der Realität umsetzen können.

Was bedeutet das nun für unser gemeinsames fiktives Testkonzept? Wir erstellen ein einzelnes Dokument, in dem die allgemeinen Rahmenbedingungen und Fakten global, aber auch stufenübergreifend festgehalten werden, und definieren dann für unsere beiden gewählten Teststufen (Systemtests und Komponententests) einfach Unterpunkte, in denen spezifische Maßnahmen festgehalten werden. Dieses verschlankte Testkonzept bietet in den meisten Fällen bereits eine durchaus stabile Lösung, und lässt sich für Anfänger relativ einfach umsetzen.

Starten wir also mit unserem Testkonzept. Hierbei sei erneut erwähnt, dass Sie durchaus flexibel sein dürfen. Nicht alle Punkte sind für jedes Projekt relevant, bzw. es kann sein, dass es andere Themen gibt, die Sie in Ihrem individuellen Projekt benötigen.

Testbasis

Die Testbasis definiert, was wir zum Erstellen von Testfällen verwenden können. Sie zeigt uns somit die Funktionalität, Abläufe, aber auch die Optik der Anwendung. Eine Testbasis kann alles Mögliche sein, deshalb ist es so relevant, diese zu benennen. So können klassische Konzepte bzw. schriftliche Anforderungen in Confluence, aber auch Layouts in Figma Teil der Testbasis sein. Auch Ablaufdiagramme in Applikationen wie Miro oder sogar PDF-Beschreibungen eines ERP-Systems können hier genannt werden.

Bei einer Ablösung von alten Systemen, z. B. einer Migration von Shopware 5 auf Shopware 6, mit dem Ziel, den gleichen Shop wieder neu aufzubauen, könnte sogar der alte Shopware-5-Shop mit seinen Funktionalitäten zur Testbasis werden.

Daraus ergibt sich bereits ein Vorteil des Testkonzepts. Wir setzen uns hier zum ersten Mal schriftlich damit auseinander, wie im Projekt mit Features bzw. Anforderungen umzugehen...