Konzept: Testebenen
Diese Richtlinie unterteilt die Testaktivitäten in die Kategorien Entwicklertest, unabhängiger Test, Einheitentest, Integrationstest, Systemtest und Akzeptanztest.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Die Tests werden auf verschiedene Zieltypen und in verschiedenen Abschnitten bzw. auf verschiedenen Ebenen angewendet. Diese Ebenen werden normalerweise über die Rollen unterschieden, die am besten für das Design und die Durchführung der Tests geeignet sind, sowie über die auf der entsprechenden Ebene am besten geeigneten Techniken. Es ist wichtig, bei diesen verschiedenen Ansätzen einen Ausgleich der Schwerpunkte herzustellen.

Entwicklertests

Die Entwicklertests umfassen die Aspekte des Testdesigns und der Implementierung, deren Realisierung dem Entwicklerteam am wichtigsten ist. Dies ist als Gegenstück zu den unabhängigen Tests zu verstehen. In den meisten Fällen erfolgt die erste Testausführung mit der für den Entwicklertest zuständigen Gruppe, die den Test entworfen und implementiert hat. Allerdings sollten die Entwickler ihre Tests so erstellen, dass sie von Gruppen verwendet werden können, die unabhängige Tests durchführen.

Ursprünglich spielten Entwicklertests nur mit Bezug auf Einheitentests eine Rolle. Einige Entwickler führen Integrationstests zwar auf verschiedenen Ebenen durch, dies ist jedoch stark von der Unternehmenskultur und anderen Kontextfragen abhängig. Die Entwicklertests sollten mehr sein als nur isolierte Einheitentests.

Unabhängige Tests

Bei den unabhängigen Tests werden das Testdesign und die Testimplementierung von jemandem erstellt, der vom Team der Entwickler unabhängig ist. Sie können diese Unterscheidung als einen Teilbereich betrachten, der die unabhängige Prüfung und Validierung umfasst. In den meisten Fällen erfolgt die erste Testausführung mit der für die unabhängigen Tests zuständigen Gruppe, die den Test entworfen und implementiert hat. Allerdings sollten die unabhängigen Tester ihre Tests so erstellen, dass sie von Gruppen verwendet werden können, die Entwicklertests durchführen. Boris Beizer erläutert die unterschiedlichen Ziele der unabhängigen Tests und der Entwicklertests etwa wie folgt:

"Der Zweck der unabhängigen Tests besteht darin, eine andere Perspektive und somit auch andere Tests bereitzustellen; darüber hinaus sollen diese Tests in einer für den Tester möglichst reichhaltigen Umgebung durchgeführt werden." [siehe BEI95]

Unabhängige Stakeholder-Tests

Diese Variante der unabhängigen Tests konzentriert sich auf die Bedürfnisse und Problemstellungen verschiedener Stakeholder. Daher werden sie als Stakeholder-Tests bezeichnet. Das ist eine wichtige Unterscheidung, sie hilft, die Stakeholder-Interessen in stärkerem Maße zu berücksichtigen, als dies traditionell der Fall ist. Dabei wird der etwas generische Begriff "Kunde" erweitert. Außer Kunden und Benutzern werden Stakeholder berücksichtigt: Mitarbeiter des technischen Support, technische Trainer, Verkaufspersonal.

Abschließend sei gesagt, dass in XP der Begriff Kundentests sich auf diese Kategorie der unabhängigen Tests in RUP bezieht.

Einheitentests

Die Einheitentests konzentrieren sich auf die Prüfung der kleinsten testbaren Elemente der Software. Normalerweise werden Einheitentests auf Komponenten angewendet, die im Implementierungsmodell dargestellt sind, um zu überprüfen, ob Steuerungsabläufe und Datenflüsse abgedeckt sind und so wie erwartet funktionieren. Der Implementierer führt die Einheitentests durch, während die Einheit entwickelt wird. Die Details der Einheitentests sind in der Disziplin Implementierung beschrieben.

Integrationstests

Integrationstests werden durchgeführt, um sicherzustellen, dass die Komponenten im Implementierungsmodell ordnungsgemäß funktionieren, wenn sie für die Ausführung eines Anwendungsfalls kombiniert werden. Das Testziel ist ein Paket oder eine Paketgruppe im Implementierungsmodell. Oft kommen die zu kombinierenden Pakete aus verschiedenen Entwicklungsorganisationen. Integrationstests sollen unvollständige Stellen oder Fehler in der Spezifikation der Paketschnittstelle offenlegen.

In einigen Fällen setzen Entwickler voraus, dass andere Gruppen, z. B. unabhängige Tester, Integrationstests durchführen. Diese Situation birgt aus folgenden Gründen Risiken für das Softwareprojekt und letztlich auch die Qualität:

  • Integrationsbereiche stellen eine allgemeine Fehlerquelle für Software dar.
  • Integrationstests, die von unabhängigen Testern durchgeführt werden, verwenden normalerweise Blackbox-Techniken und befassen sich mit größeren Softwarekomponenten.

Ein besserer Ansatz ist, die Verantwortlichkeit für die Integrationstests sowohl den für die Entwicklungstests als auch den für die unabhängigen Tests zuständigen Testern zuzuweisen und sicherzustellen, dass die Strategien beider Testteams sich nicht stark überlappen. Die genaue Art dieser Überlappung basiert auf den Anforderungen des jeweiligen Projekts. Es wird empfohlen, eine Umgebung zu schaffen, in der Entwickler und unabhängige Systemtester dieselbe Vorstellung von Qualität haben. Weitere Informationen enthält der Abschnitt Konzept: Entwicklertests.

Systemtests

Traditionell werden Systemtests durchgeführt, wenn die Software als Ganzes funktioniert. Ein iterativer Lebenszyklus erlaubt, Systemtests wesentlich früher durchzuführen. Voraussetzung ist die Implementierung klar definierter Teilbereiche. Normalerweise sind die funktionierenden End-to-End-Elemente des Systems das Ziel.

Abnahmetests

Abnahmetests durch den Benutzer sind die letzte Testaktion vor der Implementierung der Software. Mit Abnahmetests wird geprüft, ob die Software betriebsbereit ist und von den Benutzern verwendet werden kann, um die Funktionen und Aufgaben auszuführen, für die sie entwickelt wurde. Weitere Informationen enthält der Abschnitt Konzept: Abnahmetest.

Es gibt andere Definitionen von Abnahmetests, die sich normalerweise dadurch auszeichnen, dass sie von einer Gruppe oder einem Team an die bzw. das nächste übergeben werden. Beispielsweise wird der Build-Abnahmetest durchgeführt, um die Übergabe eines neuen Software-Builds vom Bereich Entwicklung an den Bereich Unabhängige Tests bestätigen zu können.

Kommentar zur Reihenfolge und Ablaufsteuerung der Testebenen

Traditionell wird der Einheitentests in einem frühen Stadium der Iteration als erster Testabschnitt implementiert: Alle Einheiten, die vor der Durchführung weiterer Abschnitte übergeben werden müssen, werden getestet. In einem iterativen Entwicklungsprozess ist dieser Ansatz im Allgemeinen jedoch nicht angemessen. Besser ist die Methode, die Einheiten-, Integrations- und Systemtests mit dem größten Fehlerermittlungspotenzial zu identifizieren und sie dann basierend auf der Annahme des größtmöglichen Risikos unter Berücksichtigung der gegebenen Unterstützungsumgebung durchzuführen.