Ob du recht hast oder nicht, sagt dir gleich …

Nein, nicht das Licht, in unserem Fall sagt uns das der Test. Allerdings ist Falsch und Richtig in IT-Projekten nicht so einfach zu definieren wie in Michael Schanzes legendärer Show „1, 2 oder 3“, die allerdings nur jene kennen, die zwischen 1977 und 1985 Kinderfernsehen konsumiert haben.

Die klassische Sicht auf Tests im V-Modell

Test spielen in allen Vorgehensmodellen eine große Rolle. Bei einem Werkvertrag geht es darum, die bei Vertragsabschluss festgelegten Eigenschaften des Produktes auf ihre Übereinstimmung mit der Lieferung zu testen. Tests stehen also ganz am Ende und es handelt sich um einen Abnahmetest.

Dieses Modell kann auch heute noch bei Hardwarelieferungen und für klar spezifizierbare Softwareprodukte praktiziert werden, allerdings sind auch hier viele eventuelle Mängel dabei nicht erkennbar.

Einen Schritt weiter in Richtung Realismus geht das V-Modell, es sieht Validierungen in allen Entwurfsphasen vor (siehe nachfolgende Grafik, über den Link gibt es auch ein informatives Video). Während der Implementierung finden natürlich auch Tests statt, diese sind allerdings in der Hoheit des Entwicklungsteams und setzen klar definierte und stabile Anforderungen voraus. Die Anforderungen der Anwender:innen und das Ergebnis der technsichen Umsetzung treffen erst beim Abnahmetest wieder aufeinander; jedenfalls wenn es laut Lehrbuch läuft.

Testen als durchgängiger Prozess – Die Sicht des SWEBOK

Der SWEBOK (Software Engineering Body of Knowledge) definiert Software-Testing als einen systematischen Prozess zur Bewertung der Qualität eines Softwareprodukts und zur Verbesserung dieser Qualität, indem Fehler erkannt und behoben werden. Testen ist dabei ein wichtiger Teil des Softwareentwicklungsprozesses, der sicherstellen soll, dass das Softwareprodukt die definierten Anforderungen erfüllt und korrekt funktioniert.

Im Detail beschreibt der SWEBOK das Testen wie folgt:

1. Ziel des Testens

– Das Hauptziel des Software-Tests ist es, Fehler und Abweichungen von den Anforderungen zu finden, um die Softwarequalität zu verbessern.

– Ein weiteres Ziel ist es, Vertrauen in die Software aufzubauen, indem gezeigt wird, dass sie unter den erwarteten Bedingungen korrekt funktioniert.

2. Testaktivitäten

SWEBOK unterteilt das Testen in verschiedene Phasen und Aktivitäten, die im Softwareentwicklungsprozess durchlaufen werden:

– Testplanung: Festlegung der Teststrategie, Testziele, Testarten, Zeitpläne und Ressourcen.

– Testdesign: Erstellung von Testfällen und Testdaten auf Basis der Spezifikationen und Anforderungen.

– Testimplementierung: Bereitstellung der Testumgebung und Einrichtung der Testwerkzeuge.

– Testdurchführung: Ausführung der Testfälle, Erfassung der Ergebnisse und Protokollierung von Abweichungen oder Fehlern.

– Testauswertung: Analyse der Testergebnisse, Bewertung der Softwarequalität und Entscheidung über die Freigabe der Software.

– Testdokumentation: Erstellung von Testberichten und Dokumentation der Testergebnisse.

3. Testebenen

Der SWEBOK beschreibt verschiedene Testebenen, darunter:

– Modultests (Unit Tests): Testen einzelner Softwarekomponenten oder Module.

– Integrationstests: Testen der Schnittstellen und Interaktionen zwischen verschiedenen Modulen, insbesondere auch solchen, die nicht Gegenstand der Entwicklungsarbeiten sind.

– Systemtests: Testen des gesamten Systems, um zu prüfen, ob es die definierten Anforderungen erfüllt.

– Abnahmetests (Acceptance Tests): Testen des Systems aus Sicht des Endbenutzers, um sicherzustellen, dass es den Geschäftszielen entspricht.

. Testmethoden

Der SWEBOK unterscheidet zwischen verschiedenen Testmethoden:

– White-Box-Testen: Der Tester kennt die interne Struktur der Software und testet spezifische Pfade und Anweisungen.

– Black-Box-Testen: Der Tester kennt die interne Implementierung nicht und testet die Funktionalität basierend auf den Anforderungen.

– Grey-Box-Testen: Eine Kombination aus White-Box- und Black-Box-Testen, bei der sowohl die Implementierung als auch die Spezifikationen berücksichtigt werden.

5. Testarten

Der SWEBOK erwähnt auch verschiedene Testarten:

– Funktionale Tests: Überprüfung, ob die Software die funktionalen Anforderungen erfüllt.

– Nicht-funktionale Tests: Testen von Aspekten wie Leistung, Sicherheit, Benutzerfreundlichkeit und Zuverlässigkeit.

– Regressionstests: Sicherstellen, dass Änderungen im Code keine neuen Fehler einführen.

– Explorative Tests: Tests ohne vorab definierte Testfälle, die der Erkundung des Systems und der Entdeckung von blinden Flecken in der Teststrategie dienen.

Der SWEBOK, den ich für einen viel zu wenig genutzten Schatz an Wissen halte, definiert Testen als einen umfassenden und strukturierten Prozess, der in jede Phase des Softwareentwicklungslebenszyklus integriert ist.

Testen als Teilbereich des Projektmanagements

Der SWEBOK deckt die Produkterstellungsprozesse ab, hinsichtlich der Prozesse des Projektmanagements verweist er auf die Standards des Project Management Institute (PMI). PMI sieht Tests als integralen Bestandteil des Projektmanagements, um die Qualität und Funktionalität der Projektergebnisse sicherzustellen. Hier sind einige wesentliche Punkte, die in den PMI-Standards zum Testen in IT-Projekten hervorgehoben werden:

• Planung der Testaktivitäten: Tests sollten frühzeitig im Projektlebenszyklus geplant werden. Dies umfasst die Definition von Testzielen, Teststrategien und Testplänen, die sicherstellen, dass alle Anforderungen und Spezifikationen abgedeckt werden.
• Testarten und -ebenen: PMI-Standards empfehlen die Durchführung verschiedener Testarten (z.B. Unit-Tests, Integrationstests, Systemtests, Abnahmetests) und Testebenen, um sicherzustellen, dass alle Aspekte der IT-Lösung gründlich geprüft werden.
• Risikobasierte Tests: Die Priorisierung von Tests basierend auf dem Risiko hilft, die kritischsten Teile des Systems zuerst zu testen und sicherzustellen, dass die wichtigsten Funktionen und Sicherheitsanforderungen erfüllt werden.
• Automatisierung von Tests: Die Automatisierung von Tests wird als Best Practice angesehen, um die Effizienz und Wiederholbarkeit der Tests zu erhöhen. Automatisierte Tests können helfen, Regressionen schnell zu identifizieren und die Qualität des Produkts kontinuierlich zu überwachen.
• Dokumentation und Nachverfolgbarkeit: Eine gründliche Dokumentation der Testergebnisse und die Nachverfolgbarkeit von Fehlern und Korrekturen sind entscheidend, um sicherzustellen, dass alle Probleme identifiziert und behoben werden.
• Kontinuierliche Verbesserung: PMI-Standards betonen die Bedeutung der kontinuierlichen Verbesserung der Testprozesse durch regelmäßige Überprüfungen und Anpassungen basierend auf den gesammelten Erfahrungen und Ergebnissen.

Diese Zusammenfassung aus einer größeren Zahl von Quellen habe ich mir übrigens von PMI’s Infinitymachen lassen, dem ChatBot, der auf qualitätsgesicherten Texten von PMI aufsetzt.

Testen in agilen Projekten

Die Teststrategie in agilen Projekten unterscheidet sich erheblich von der in klassischen Vorgehensmodellen. Agile Methoden wie Scrum oder Kanban legen großen Wert auf Flexibilität, kontinuierliche Verbesserung und enge Zusammenarbeit, was sich auch auf die Teststrategie auswirkt. Hier sind einige wesentliche Unterschiede:

• Integrierte Tests: In agilen Projekten sind Tests ein integraler Bestandteil jedes Sprints oder Iteration. Tests werden kontinuierlich durchgeführt, anstatt am Ende des Projekts, wie es in klassischen Modellen oft der Fall ist.
• Test-Driven Development (TDD): Agile Projekte nutzen häufig TDD, bei dem Tests vor der eigentlichen Implementierung geschrieben werden. Dies stellt sicher, dass der Code von Anfang an testbar ist und die Anforderungen erfüllt. TDD wird meist auf einer sehr technischen Ebene praktiziert, ich halte diesen Ansatz auch schon für frühe Phasen eines Projektes für praktikabel und wertvoll; dazu hier mehr.
• Automatisierung: In agilen Projekten wird stark auf die Automatisierung von Tests gesetzt, um die Effizienz zu steigern und schnelle Feedback-Schleifen zu ermöglichen. Automatisierte Tests helfen, Regressionen schnell zu identifizieren und die Qualität des Produkts kontinuierlich zu überwachen.
• Kontinuierliche Integration (CI): Agile Teams nutzen CI-Tools, um den Code regelmäßig zu integrieren und zu testen. Dies ermöglicht eine frühzeitige Erkennung von Fehlern und eine schnelle Behebung.
• Kollaborative Ansätze: In agilen Projekten arbeiten Entwickler, Tester und andere Stakeholder eng zusammen. Diese Zusammenarbeit fördert ein gemeinsames Verständnis der Anforderungen und verbessert die Qualität der Tests.
• Flexibilität und Anpassungsfähigkeit: Agile Teststrategien sind flexibel und passen sich den sich ändernden Anforderungen und Prioritäten an. Dies steht im Gegensatz zu den starren Testplänen in klassischen Modellen.
• User Stories und Akzeptanzkriterien: Tests in agilen Projekten basieren oft auf User Stories und deren Akzeptanzkriterien. Ich habe an anderer Stelleschon darauf hingewiesen, dass dieser Detaillierungsgrad nicht ausreichend, als Minimalvorgabe und Einstieg aber nützlich und wertvoll ist.

Insgesamt wird klar, dass Testen in agilen Projekten in allen Phasen des Entwicklungsprozesses praktiziert wird. Noch wichtiger halte ich aber den grundsätzlichen Paradigmenwechsel. Testen vergleicht nicht vorab fixierte Anforderungen mit einem Ergebnis, dass bei Abweichungen zu korrigieren ist. Es stehen auch die Anforderungen zur Disposition, sie werden aufgrund von Testergebnissen detailliert und oft sogar modifiziert. Der Anteil an explorativen Tests steigt also signifikant. Sie sind nicht mehr, wie im SWEBOK vorgesehen, Ergänzungen der vordefinierten Testfälle, sie dienen auch der Präzisierung der Anforderungsdefinitionen und der Sicherung des Wertes der entwickelten Lösung

Testen ist ein zentales Steuerungsinstrument

Testen ist ein Messvorgang, der qualitative und quantitative Metriken auf die jeweiligen Arbeitsergebnisse anwendet. Aus der Physik lernen wir, dass der Messvorgang Teil jedes Messergebnisses ist. Es macht keinen Sinn, sich eine Realität (das Kant’sche „Ding an sich“ oder die „objektive Realität“) vorzustellen, die durch einen Messvorgang dann mehr oder minder korrekt abgebildet würde. Es gibt keine Realität unabhängig von unserer Beobachtung, die man im Sinne des Höhlengleichnisses mit unserer Wahrnehmung vergleichen könnte.

Der Projektfortschritt z.B. ist ein Konstrukt und je nach Definition wird im Projekt anders gearbeitet, Entscheidungen fallen anhand anderer oder zumindest anderer Gewichtungen der Entscheidungskriterien.  Durch die Messung wird also das System verändert, das man beobachtet. Die Teststrategie ist daher eine wesentliche Weichenstellung für den Verlauf eines Projektes. Was dort adressiert wird, erhält in der Projektarbeit höhere Priorität. Vor allem in den Schlussphasen eines Projektes werden die Testberichte zum wichtigsten Indikator für die Ermittlung des Effort to Complete und damit die Abschätzung des Go-Live-Termins und den Budget-Forecast.

Testen ist der ultimative Reality-Check. Es kann sehr schmerzhaft sein, wenn die vorher abgegebenen Einschätzungen des Fertigstellungsgrades am Ende schlagartig nach unten korrigiert werden müssen. In agilen Projekten ist diese Gefahr deutlich geringer als in Projekten nach einem klassischen Wasserfallmodell, aber es ist auch hier genug Raum für illusorische Fertigstellungsprognosen.

Alles muss getestet werden

Testpläne fokussieren meist auf die Prüfung der Software. Aber das greift zu kurz. Sehen wir Testen als universell gültiges Instrument des Vergleichs von Anspruch und Wirklichkeit, so müssen wir z.B. auch die Anforderungen testen. Sind diese geeignet, das eigentliche Projektziel, die Realisierung des Business Case zu realisieren? Sind die funktionalen und nicht-funktionalen Anforderungen vollständig und stimmen sie mit den tatsächlichen Herausforderungen des Projektes überein?

Jedes Zwischenergebnis in einem Projekt, ob es ein Projektplan, eine Schnittstellenfestlegung, eine Prozessdefinition oder was immer ist, kann gegen die Anforderung getestet werden, die durch dieses Ergebnis erfüllt werden soll.

Bei jeder Verfeinerung oder Konkretisierung einer Anforderung oder einer Lösungsbeschreibung muss geprüft werden, ob diese mit der abstrakteren Version noch übereinstimmt bzw. deren sinnvolle Konkretisierung ist.

Diese Forderung artikulieren auch Tom deMarco u.a. in ihrem Muster 35 („Testen vor dem Testen“) des legendären Buchs „Adrenalin Junkies & Formular Zombies“. Wer also mir nicht glauben will, ist herzlich eingeladen, es bei diesen Giganten des IT-Projektmanagements nachzulesen.