Testfälle und Prioritäten definieren

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Legen Sie fest, was getestet werden soll, definieren Sie Ihre Testfälle und priorisieren Sie sie.

Ramona Schwering

Im vorherigen Beitrag haben Sie mehr über Teststrategien, die Anzahl der Tests, die zum Testen einer Anwendung erforderlich sind, und die Auswahl der am besten geeigneten Tests erfahren, um die bestmögliche Zuverlässigkeit der Ergebnisse zu erzielen und dabei Ihre Ressourcen im Blick zu behalten. Dies gibt uns jedoch nur eine ungefähre Vorstellung davon, wie viel wir testen sollten. Sie müssen noch genau festlegen, was Sie testen möchten. Die folgenden drei Kriterien können Ihnen dabei helfen, zu verstehen, was Sie von einem Test erwarten können und welche Art von Test und Detailebene am besten geeignet ist:

1. Achten Sie auf den Happy Path. Dies ist die allgemeinste oder primäre User Story Ihrer Anwendung, bei der Nutzer sehr schnell einen Fehler bemerken.
2. Überlegen Sie sich gut, wie detailliert Sie die Informationen gestalten möchten. Gehen Sie genauer darauf ein, ob Ihr Anwendungsfall anfällig ist oder ein Fehler große Schäden verursachen würde.
3. Priorisieren Sie nach Möglichkeit Tests auf niedrigerer Ebene, z. B. Unit- und Integrationstests, gegenüber End-to-End-Tests auf höherer Ebene.

Im Rest dieses Artikels werden diese Kriterien und ihre Anwendung bei der Definition von Testfällen erläutert.

Was ist ein Testfall?

In der Softwareentwicklung ist ein Testfall eine Abfolge von Aktionen oder Umständen, die entwickelt wurden, um die Effektivität eines Softwareprogramms oder einer Softwareanwendung zu bestätigen. Mit einem Testfall soll sichergestellt werden, dass die Software wie geplant funktioniert und alle Funktionen ordnungsgemäß ausgeführt werden. Diese Testfälle werden in der Regel von Softwaretestern oder Entwicklern erstellt, um sicherzustellen, dass die Software die angegebenen Anforderungen und Spezifikationen erfüllt.

Wenn ein Testfall ausgeführt wird, führt die Software eine Reihe von Prüfungen durch, um sicherzustellen, dass die gewünschten Ergebnisse erzielt werden. Dabei erfüllt ein Test die folgenden Aufgaben:

• Überprüfung Die Software wird gründlich geprüft, um sicherzustellen, dass sie fehlerfrei funktioniert. Es ist entscheidend, festzustellen, ob das erstellte Produkt alle erforderlichen nicht funktionalen Anforderungen erfüllt und seinen beabsichtigten Zweck erfüllt. Es beantwortet die Frage: „Entwickeln wir das Produkt richtig?“
• Validierung Der Prozess, der dafür sorgt, dass das Softwareprodukt die erforderlichen Standards oder allgemeinen Anforderungen erfüllt. Dabei wird geprüft, ob das tatsächliche Produkt mit dem erwarteten Produkt übereinstimmt. Im Grunde beantworten wir die Frage: „Entwickeln wir das richtige Produkt für die Anforderungen der Nutzer?“

Angenommen, das Programm erzielt nicht das erwartete Ergebnis. In diesem Fall ist der Testfall der Bote, der ein negatives Ergebnis meldet. Der Entwickler oder Tester muss das Problem untersuchen und eine Lösung finden. Stellen Sie sich die Prüfungen und Aktionen als Pfade vor, die der Computer unabhängig vom Testtyp durchläuft. Gruppen von Eingabedaten oder Bedingungen, die zur Überprüfung verwendet werden, werden als „Äquivalenzklassen“ bezeichnet. Das getestete System sollte ein ähnliches Verhalten oder ähnliche Ergebnisse liefern. Die spezifischen Pfade, die in einem Test ausgeführt werden, können variieren, sollten aber mit den Aktivitäten und Behauptungen in Ihrem Test übereinstimmen.

Testpfade: Typische Arten von Testfällen

In der Softwareentwicklung ist ein Testfall ein Codeausführungsszenario, von dem ein bestimmtes Verhalten erwartet und getestet wird. Normalerweise gibt es drei Szenarien, aus denen Testfälle erstellt werden können.

Die erste ist die bekannteste und wird wahrscheinlich schon von Ihnen verwendet. Es ist der Happy Path, auch als „Happy Day-Szenario“ oder „Golden Path“ bezeichnet. Er definiert den häufigsten Anwendungsfall Ihrer Funktion, Anwendung oder Änderung – also die Funktionsweise, die für den Kunden vorgesehen ist.

Der zweitwichtigste Testpfad, der in Ihren Testfällen abgedeckt werden muss, wird oft ausgelassen, da er – wie der Name schon sagt – unangenehm ist. Es ist der „beängstigende Pfad“, mit anderen Worten der Negativtest. Dieser Pfad richtet sich an Szenarien, in denen der Code nicht richtig funktioniert oder einen Fehlerstatus aufweist. Das Testen dieser Szenarien ist besonders wichtig, wenn Sie sehr anfällige Anwendungsfälle haben, die ein hohes Risiko für die Stakeholder oder Nutzer darstellen.

Es gibt noch einige andere Pfade, die Sie kennen sollten und die Sie in Betracht ziehen können, die aber in der Regel weniger häufig verwendet werden. In der folgenden Tabelle sind sie zusammengefasst:

Es gibt mehrere Methoden, diese Pfade zu kategorisieren. Zwei gängige Ansätze sind:

• Äquivalenzpartitionierung Eine Testmethode, bei der Testfälle in Gruppen oder Partitionen kategorisiert werden, um so Äquivalenzklassen zu erstellen. Das basiert auf der Annahme, dass bei einem Testfall in einer Partition ein Fehler gefunden wird, andere Testfälle in derselben Partition wahrscheinlich ähnliche Fehler aufdecken. Da alle Eingaben innerhalb einer bestimmten Äquivalenzklasse dasselbe Verhalten zeigen sollten, können Sie die Anzahl der Testfälle verringern. Weitere Informationen zur Äquivalenzaufteilung
• Begrenzungsanalyse Eine Testmethode, die auch als Grenzwertanalyse bezeichnet wird. Dabei werden die Grenzen oder Extremwerte von Eingabewerten untersucht, um potenzielle Probleme oder Fehler zu finden, die an den Grenzen der Fähigkeiten oder Einschränkungen des Systems auftreten können.

Best Practice: Testfälle schreiben

Ein klassischer Testfall, der von einem Tester geschrieben wird, enthält spezifische Daten, die Ihnen helfen, den Inhalt des Tests zu verstehen, den Sie durchführen möchten, und natürlich den Test auszuführen. Ein typischer Tester würde seine Testaktivitäten in einer Tabelle dokumentieren. In dieser Phase können wir zwei Muster verwenden, die uns dabei helfen, unsere Testfälle und später auch unsere Tests selbst zu strukturieren:

• Muster „Anordnen, handeln, behaupten“ Das Testmuster „Arrange, Act, Assert“ (auch als „AAA“ oder „Triple A“ bezeichnet) ist eine Möglichkeit, Tests in drei verschiedene Schritte zu unterteilen: Test vorbereiten, Test durchführen und schließlich Schlussfolgerungen ziehen.
• Wenn, dann-Muster Dieses Muster ähnelt dem AAA-Muster, hat aber einige Wurzeln in der verhaltensgetriebenen Entwicklung.

In zukünftigen Artikeln gehen wir näher auf diese Muster ein, sobald wir die Struktur eines Tests behandeln. Wenn Sie in dieser Phase mehr über diese Muster erfahren möchten, lesen Sie die folgenden Artikel: Arrange-Act-Assert: Ein Muster für das Schreiben guter Tests und Given-When-Then.

In der folgenden Tabelle sind die Erkenntnisse aus diesem Artikel in einem klassischen Beispiel zusammengefasst:

Bei automatisierten Tests müssen Sie nicht alle diese Testfälle so dokumentieren wie ein Tester, auch wenn dies zweifellos hilfreich ist. Sie finden all diese Informationen in Ihrem Test, wenn Sie genau hinschauen. Lassen Sie uns diesen klassischen Testfall in einen automatisierten Test umwandeln.