Agiles Testen - Techniken

Testtechniken aus herkömmlichen Tests können auch beim agilen Testen verwendet werden. Darüber hinaus werden in den Agile-Projekten agilspezifische Testtechniken und -terminologien verwendet.

Testbasis

In agilen Projekten ersetzt das Product Backlog die Anforderungsspezifikationsdokumente. Der Inhalt des Product Backlogs sind normalerweise User Stories. Die nicht funktionalen Anforderungen werden auch in den User Stories berücksichtigt. Die Testbasis in Agile-Projekten ist daher die User Story.

Um die Qualitätsprüfung sicherzustellen, kann zusätzlich Folgendes als Prüfgrundlage betrachtet werden:

Erfahrung aus früheren Iterationen desselben Projekts oder aus früheren Projekten.
Bestehende Funktionen, Architektur, Design, Code und Qualitätsmerkmale des Systems.
Fehlerdaten aus aktuellen und vergangenen Projekten.
Kundenbewertung.
Benutzerdokumentation.

Definition von Fertig

Die Definition of Done (DoD) ist das Kriterium, das in agilen Projekten verwendet wird, um den Abschluss einer Aktivität im Sprint-Backlog sicherzustellen. DoD kann von Scrum-Team zu Scrum-Team unterschiedlich sein, sollte jedoch innerhalb eines Teams konsistent sein.

DoD ist eine Checkliste der erforderlichen Aktivitäten, die die Implementierung von Funktionen und Merkmalen in einer User Story sowie die nicht funktionalen Anforderungen, die Teil der User Story sind, sicherstellen. Eine User Story erreicht das Stadium "Fertig", nachdem alle Elemente in der DoD-Checkliste ausgeführt wurden. Ein DoD wird im gesamten Team geteilt.

Ein typisches DoD für eine User Story kann Folgendes enthalten:

Detaillierte überprüfbare Akzeptanzkriterien
Kriterien, um die Konsistenz der User Story mit den anderen in der Iteration sicherzustellen
Spezifische Kriterien in Bezug auf das Produkt
Aspekte des funktionalen Verhaltens
Nichtfunktionale Eigenschaften
Interfaces
Testdatenanforderungen
Testabdeckung
Refactoring
Überprüfungs- und Genehmigungsanforderungen

Neben dem DoD für User Stories ist auch DoD erforderlich -

auf jeder Teststufe
für jedes Feature
für jede Iteration
zur Veröffentlichung

Testinformationen

Ein Tester muss über die folgenden Testinformationen verfügen:

User Stories, die getestet werden müssen
Zugehörige Akzeptanzkriterien
Systemschnittstellen
Umgebung, in der das System voraussichtlich funktionieren wird
Verfügbarkeit der Tools
Testabdeckung
DoD

In agilen Projekten liegt es in der Verantwortung des Testers, - da das Testen keine sequentielle Aktivität ist und Tester in einem kollaborativen Modus arbeiten sollen -

Erhalten Sie laufend die erforderlichen Testinformationen.
Identifizieren Sie die Informationslücken, die sich auf das Testen auswirken.
Beheben Sie die Lücken gemeinsam mit anderen Teammitgliedern.
Entscheiden Sie, wann ein Testlevel erreicht ist.
Stellen Sie sicher, dass geeignete Tests zu relevanten Zeiten ausgeführt werden.

Funktionelles und nicht funktionales Testdesign

In agilen Projekten können die traditionellen Testtechniken verwendet werden, der Schwerpunkt liegt jedoch auf frühen Tests. Testfälle müssen vorhanden sein, bevor die Implementierung beginnt.

Für das funktionale Testdesign können die Tester und Entwickler die traditionellen Black-Box-Testdesign-Techniken verwenden, wie z.

Äquivalenzpartitionierung
Grenzwertanalyse
Entscheidungstabellen
Zustandsübergang
Klassenbaum

Für das nicht funktionale Testdesign können die Black-Box-Testdesign-Techniken nur zum Entwerfen der relevanten Testfälle verwendet werden, da die nicht funktionalen Anforderungen auch Teil jeder User Story sind.

Versuchsforschung

In agilen Projekten ist Zeit häufig der Begrenzungsfaktor für Testanalyse und Testdesign. In solchen Fällen können explorative Testtechniken mit den traditionellen Testtechniken kombiniert werden.

Exploratory Testing (ET) ist definiert als gleichzeitiges Lernen, Testdesign und Testdurchführung. Bei exploratorischen Tests steuert der Tester aktiv das Design der durchgeführten Tests und verwendet die beim Testen gewonnenen Informationen, um neue und bessere Tests zu entwerfen.

Exploratory Testing ist praktisch, um Änderungen in agilen Projekten Rechnung zu tragen.

Risikobasiertes Testen

Risikobasierte Tests sind Tests, die auf dem Ausfallrisiko basieren und die Risiken mithilfe von Testdesign-Techniken mindern.

Ein Produktqualitätsrisiko kann als potenzielles Problem der Produktqualität definiert werden. Zu den Produktqualitätsrisiken gehören -

Funktionsrisiken
Nicht funktionale Leistungsrisiken
Nicht funktionale Usability-Risiken

Eine Risikoanalyse ist durchzuführen, um die Wahrscheinlichkeit (Wahrscheinlichkeit) und die Auswirkungen jedes Risikos zu bewerten. Dann werden die Risiken priorisiert -

Hohe Risiken erfordern umfangreiche Tests
Geringe Risiken erfordern nur flüchtige Tests

Tests werden unter Verwendung geeigneter Testtechniken entworfen, die auf dem Risikograd und den Risikocharakteristiken jedes Risikos basieren. Anschließend werden Tests ausgeführt, um die Risiken zu minimieren.

Fit-Tests

Fit-Tests sind automatisierte Abnahmetests. Die Tools Fit und FitNesse können zur Automatisierung von Abnahmetests verwendet werden.

FIT verwendet JUnit, erweitert jedoch die Testfunktionalität. HTML-Tabellen werden verwendet, um die Testfälle anzuzeigen. Fixture ist eine Java-Klasse hinter der HTML-Tabelle. Das Fixture übernimmt den Inhalt der HTML-Tabelle und führt die Testfälle für das zu testende Projekt aus.