Reifegrade des Komponententests

Ad-Hoc Tests finden statt und sind stark von den Fähigkeiten einzelner Entwickler abhängig.

Unit-Tests werden durch die Entwickler unabhängig voneinander entwickelt und ausgeführt.

Eine Verwaltung und Speicherung der Tests erfolgt nicht.

Komponententests erfolgen isoliert auf Entwicklungsumgebungen

Häufig entstehen sie erst, nachdem der Code bereits geschrieben wurde

Nur rudimentäre Dokumentation der Ergebnisse, Eingangskriterien für die nächste Teststufe (Integrationstest) unklar

Starten Sie frühzeitig mit der Testvorbereitung.

Etablieren Sie formale Testtechniken wie White-Box-Techniken, um explizit Anweisungen im Programmcode zu testen.

Definieren Sie klare Ziele und Metriken und bestimmen messbare Eingangskriterien für den folgenden Integrationstest.

Messen und dokumentieren Sie die Ergebnisse der Testdurchführung für die Projektsteuerung

Ermitteln Sie den Abdeckungsgrad für den Test der Komponenten.

Stellen Sie die Bereitstellung geeigneter Testumgebungen sicher.

Verwenden Sie Tools zur Automatisierung der Testfälle.

Transparente Ergebnisse durch die Testdokumentation helfen der Projektsteuerung

Klare Vorgaben bezüglich der Eingangskriterien zur nächsten Teststufe

Abdeckungsgrade für die Komponenten sind bekannt

Neben den Ad-Hoc-Testmethoden werden auch formale Testtechniken angewendet, sodass eine Abdeckung zur Spezifikation nachzuvollziehen ist.

Testtechniken für das formale Testen werden eingeführt sowie deren Anwendung und Vorteile deutlich gemacht.

Werkzeuge für Komponententests sind vorhanden und für alle Entwickler/Tester wieder verwendbar (Testmittel).

Testfälle werden auf Basis der Spezifikation und den Anforderungen erstellt und dokumentiert.

Testausführung wird protokolliert, ggf. mit einem Report zur Abdeckung. Um dies zu gewährleisten, muss die Testautomatisierung vorangetrieben werden.

Die Module/Einheiten sollen unabhängig voneinander getestet werden → eigene Testumgebungen.

Verwenden Sie ein Testwerkzeug, welches die bidirektionale Rückverfolgbarkeit über einheitliche IDs zwischen Testfällen und Anforderungen ermöglicht.

Planen Sie Schulungen von Testtechniken ein, damit alle Tester, Entwickler mit den gleichen Mitteln und Wissen arbeiten können.

Beziehen Sie eine Risikobetrachtung zur Ermittlung der Komplexität der Komponenten in die Tests ein

Setzen Sie Review Methoden für den Testfall Quellcode bzw. die Testfallspezifikation ein.

Setzen Sie Mock-Objekte ein, um noch nicht realisierte Objekte im Test zu simulieren.

Die Komponententests bringen detaillierte Rückverfolgbarkeit der Implementierung.

Fehler werden durch Komponententest bereits während der Entwicklung erkannt, was zur Reduzierung der Fehlerkosten führt, da für nachfolgende Teststufen weniger Testaufwand anfällt.

Erhöht die Qualität des Programmcodes des Testobjektes (Feature-Implementierung) (Codeüberdeckung).

Es finden Reviews des Testfallquellcodes bzw. der Testfallspezifikation statt.

Testtiefe abhängig von der Risikoanalyse (hohes Risiko, höhere Komplexität → mehr Tests, geringeres Risiko → weniger Tests)

Eine Risiko-Analyse hat stattgefunden – d.h. man kennt die Bedeutung und Komplexität des Systems / der Komponente

Die Tests werden unterschiedlich in Tiefe und Abdeckung durchgeführt. Das hängt von der Risiko-Analyse ab (hohes Risiko, höhere Komplexität → mehr Tests, geringeres Risiko → weniger Tests).

Es werden eine oder viele formale und Ad-Hoc-Testtechniken angewendet, angepasst an die erforderliche Testtiefe.

Für das Nachtesten von Fehlern findet eine gut begründete Wahl statt zwischen "Einzeltest" und "Kompletttest".

Es finden Reviews der Implementierung und/oder der Tests statt.

Testwerkzeuge werden eingesetzt, mit denen schneller und besser getestet werden kann

Testauswertung in einem Bericht (Nachverfolgbarkeit)

Funktions- und Objektvirtualisierung (Mock-Objekt) werden verwendet, um die Abdeckung zu erweitern und Fehlerbedingungen zu testen

Stellen Sie eine Teststrategie auf, in der für jede Komponente eine Einschätzung der Wichtigkeit und der Testumfang beschrieben wird.

Um die Gefahr der Betriebsblindheit zu vermeiden, können Sie die Komponententests von anderen Entwicklern/Testspezialisten schreiben bzw. durchführen lassen.

Wenden Sie Pair-Programming/-Testing an (zwei Entwickler arbeiten am Test gleichzeitig)

Führen Sie die testgetriebenen Entwicklung (Test Driven Development, TDD), als Designstrategie ein.

Sie setzt die Erstellung der Tests als Ausgangspunkt für ein iteratives Vorgehen ganz an den Anfang, um die folgende Softwareentwicklung zu steuern.

Etablieren Sie einen kontinuierlichen Verbesserungsprozess, um den erreichten Zustand zu erhalten und an Änderungen anzupassen

Durch wiederholte Reviews und Retrospektiven sorgen Sie für kontinuierliche Prüfung des Vorgehens.

Ständige Weiterbildung und Schulung des Test- und QS-Teams

Dieser Reifegrad stellt sicher, dass zu immer gleichen Bedingungen höchste Qualität produziert wird.

Ressourcen (Zeit, Geld, Personal) werden demzufolge optimal eingesetzt

Produkt- und Projektrisiken werden minimiert und sind berechenbar

Nachhaltigkeit durch verbesserte Wiederverwendung bei geringstmöglichen Kosten

"Lernende Organisation

Dokumentation soll in einem Anforderungsmanagement-Werkzeug erstellt werden.

Die Verwendung der Werkzeuge für Komponententests werden regelmäßig auf ihre Wirksamkeit überprüft und verbessert.

Möglichst hoher Grad an automatisierten Komponententests erreichen.

Die Komponententests sind gut kommentiert.

Review der Implementierung findet statt.

Testauswertung in einem Bericht (Nachverfolgbarkeit).

Es findet nach jeder Auslieferung eine „Lessons-learned“-Runde statt um Verbesserungen am Komponententest durchzuführen.