Testbare Anforderungen

Die Grundprinzipien testbarer Anforderungen

Eine testbare Anforderung beschreibt eine Funktion oder ein Verhalten einer Anwendung so, dass man darauf basierend einen Test entwickeln kann, der prüft, ob die Anforderung erfüllt wird. Um dabei als testbar zu gelten, muss eine Anforderung eindeutig, messbar und vollständig sein.

Nehmen wir als Beispiel einen Test für eine Webshopanwendung. Die zugehörige Anforderung lautet: „Einfach zu verwendende Suche für den verfügbaren Bestand.“ Wenn man nun dieser Anforderung gemäß den Test erstellen will, ist man zum Interpretieren gezwungen: Was sind die Kriterien für „einfach zu verwendend“? Wie ist der „verfügbare Bestand“ definiert?  Formulieren Sie aus, was Sie mit subjektiven Bezeichnungen wie „schnell“, „intuitiv“ oder „benutzerfreundlich“ meinen.

Dabei müssen Anforderungen keine genauen Implementierungsdetails enthalten, wie etwa „Das Suchfeld soll sich in der oberen rechten Bildschirmecke befinden“, aber sie sollten messbar und vollständig sein.  Sehen wir uns als Kontrast zum ersten Beispiel nun folgende Anforderung an:

„Wenn wenigstens ein passender Artikel gefunden wird, sollen bis zu 20 passende Artikel aus dem Bestand in einem Raster oder einer Liste gemäß der in den Benutzereinstellungen definierten Reihenfolge angezeigt werden.“

Diese Anforderung definiert nun schon Details, aus denen sich abgegrenzte Testfälle ableiten lassen, wie z.B. „keine passenden Artikel“, „1 oder 2 passende Artikel“ und „19, 20 und 21 passende Artikel“. Allerdings beschreibt diese Anforderung bereits mehr als eine Funktion. Besser wäre es, sie in drei separate Anforderungen aufzuspalten:

  • Wenn wenigstens ein passender Artikel gefunden wurde, sollen bis zu 20 passende Artikel aus dem Bestand angezeigt werden.
  • Suchergebnisse sollen in einem Raster oder in einer Liste gemäß den Benutzereinstellungen angezeigt werden.
  • Suchergebnisse sollen gemäß der in den Benutzereinstellungen definierten Reihenfolge angezeigt werden.

Dieses Prinzip von „Eine Funktion pro Anforderung“ entspricht einer agilen Arbeitsweise. So könnte im obigen Beispiel die Suchfunktion selbst schon in einem ersten Sprint veröffentlicht werden, und in nachfolgenden Sprints dann die Raster-/Listenansicht oder die Ergebnisreihenfolge implementiert werden.

Folgende Dinge sollte eine testbare Anforderung nicht enthalten:

  • Irrelevanten Informationen. Wie auch bei Büchern sagt bei Anforderungen die Anzahl der Wörter wenig bis nichts über die Qualität aus. Entfernen Sie Text, der unnötig für das Verständnis der Anforderung ist.
  • Eine Beschreibung des Problems statt der Funktion, die es löst.
  • Details zur Implementierung. Details wie Schriftgrößen, Farben und Platzierung sollten in einer generellen Projektrichtlinie festgehalten werden, anstatt sie in jeder Anforderung zu wiederholen.
  • Unklare Formulierungen Anforderungen müssen eindeutig formuliert sein. Vermeiden Sie subjektive Bezeichnungen, die nicht messbar sind, wie „üblicherweise“. Verwenden Sie stattdessen objektive, messbare Bezeichnungen wie „80 %“.

Herangehensweisen an Anforderungen

Es gibt eine Reihe von verschiedenen Herangehensweisen zum Schreiben von Anforderungen, die von traditionellen Anforderungsdokumenten bis hin zu agileren Zugängen wie User-Storys, Test-driven-Development (TDD), Acceptance-Test-driven-Development (ATDD) und Behavior-driven-Development (BDD) reichen.

Icon User story

User-Storys

Eine User-Story ist eine Anforderung, die als Ziel formuliert ist und dabei auf technischen Jargon verzichtet, um für Endnutzer verständlich zu sein. User-Storys sind kurz und folgen dem Format „Als <Rolle> möchte ich <Funktion> um <Nutzen>.“ Zum Beispiel: „Als Kunde, der nach einem Produkt sucht, möchte ich mir aussuchen können, ob ich die verfügbaren Produkte in einer Liste oder einem Raster sehe, um die Produkte untereinander vergleichen zu können.“

Wie der Name schon vermuten lässt steht bei dieser Art der Anforderung der Nutzer bzw. Kunde im Vordergrund. User-Storys allein stellen normalerweise noch keine testbaren Anforderungen dar. Deswegen sollten sie Akzeptanzkriterien beinhalten, damit das Team auch weiß, wann die Story als abgeschlossen gelten kann. Mehr zum Thema User-Storys finden sie auf Agile Alliance.

Icon TDD

Test-driven-Development (TDD)

Im TDD werden Anforderungen als Unittests verfasst. Diese Unittests werden ausgeführt, bevor der durch sie beschriebene Code überhaupt existiert, und müssen deswegen fehlschlagen. Dann wird der Code so geschrieben, dass der Test erfolgreich durchlaufen werden kann, der Test wird zur Sicherheit nochmals ausgeführt und schließlich wird das erforderliche Refactoring durchgeführt.

Dieser Zugang wird auch als Developer-Testing bezeichnet, da einerseits die Tests von Entwicklern durchgeführt werden und andrerseits die Tests Bestandteil des Entwicklungszyklus sind. Dennoch spielen Tester auch im TDD eine wichtige Rolle: Sie können mit Entwicklern zusammenarbeiten, um bessere Unittests zu entwickeln, bspw. durch die Anwendung von Grenzwertanalyse, Äquivalenzklassenbildung und Risikoanalyse. Außerdem können sie dazu beitragen, dass die nötigen Integrations- und Workflowtests korrekt durchgeführt werden. TDD-Tests werden normalerweise in Tools wie JUnit oder VBUnit geschrieben und stellen einen integralen Bestandteil der Anwendungsdokumentation dar. Mehr zum Thema TDD finden sie auf Agile Alliance.

Icon ATDD

Acceptance-Test-driven-Development (ATDD)

Im ATDD werden User-Storys und ihre zugehörigen Akzeptanzkriterien zu Tests, die dem Kunden die ordnungsgemäße Funktion der Anwendung demonstrieren. Akzeptanztests werden normalerweise in Dreierteams, sogenannten „Three Amigos“ geschrieben, die aus einem Benutzerrepräsentanten, einem Entwickler und einem Tester bestehen. Um sicherzustellen, dass die Tests für jeden im Team verständlich sind, wird auf technischen Jargon verzichtet.

Der Arbeitsablauf ist im ATDD ähnlich wie im TDD: Zuerst wird die User-Story geschrieben und dann der Akzeptanztest ausgeführt. Anschließend wird die User-Story implementiert und das Team wiederholt den Akzeptanztest, um sicherzustellen, dass er erfolgreich ist. Schließlich wird eventuell nötiges Refactoring durchgeführt. TDD und ATDD können von einem Team auch gleichzeitig eingesetzt werden. Tipps zum Schreiben von guten Akzeptanztests finden Sie im Blog-Artikel The ABCs of Acceptance Test Design von Jeff Langr.

Icon unit testing

Behavior-driven-Development (BDD)

Um Anforderungen eindeutiger zu machen, können sie auch als realistische Beispiele statt abstrakt formuliert werden. Dieser Zugang wird auch Specification-by-Example (SBE) oder Behavior-driven-Development (BDD) genannt. BDD ähnelt ATDD, nutzt aber die sogenannte Gherkin-Syntax. User-Storys werden in BDD mit Beispielen ergänzt, um Szenarios zu erstellen. Die Szenarios für ein Feature werden zusammen in einer Featuredatei gespeichert und stellen eine ausführbare Spezifikation dar.

BDD-Szenarios werden in einer GEGEBEN-WENN-DANN-Syntax abgebildet, wie unten beschrieben.

Feature: Suchergebnisanzeige

„Als Kunde, der nach einem Produkt sucht,
möchte ich mir aussuchen können, ob ich die verfügbaren Produkte in einer Liste oder einem Raster sehe,
um die Produkte untereinander vergleichen zu können.“

Szenario 1
Gegeben ist, Dass ich eine Suche nach einem Bestandsartikel durchführe
Und Meine Suche wenigstens zwei Artikel findet
Wenn In meinen Einstellungen Listenanzeige ausgewählt ist
Dann: Sehe ich die von meiner Suche gefundenen Artikel in einer Liste.

Szenario 2
Gegeben ist, Dass ich eine Suche nach einem Bestandsartikel durchführe
Und Meine Suche wenigstens zwei Artikel findet
Wenn In meinen Einstellungen Rasteranzeige ausgewählt ist
Dann: Sehe ich die von meiner Suche gefundenen Artikel in einem Raster.

Szenario 3
Gegeben ist, Dass ich eine Suche nach einem Bestandsartikel durchführe
Und Meine Suche keinen Artikel findet
Wenn In meinen Einstellungen Listenanzeige ausgewählt ist
Dann: Sehe ich eine Liste mit anderen, vorgeschlagenen Artikeln.

Tools zur Erstellung testbarer Anforderungen

Prinzipiell sind keine Tools nötig, um testbare Anforderungen zu erstellen. Sie können Sie in Word-Dokumenten oder auch einfach nur auf Notizkärtchen festhalten. Spezielle Tools können aber die Effizienz erhöhen. ATDD-Tests können z.B. mit einem Tool wie FitNesse erfasst und automatisiert werden. Auch für BDD gibt es eine Reihe von Tools, die die Anforderungserstellung in der Gherkin-Syntax erleichtern und Anforderungen für die Automatisierung aufbereiten. Diese sind z.B.:

  • Cucumber für Ruby
  • Jbehave für Java
  • SpecFlow für C#
  • Jasmine für JavaScript

Ranorex Studio unterstützt mit seinen robusten Tools und der offenen API alle Testzugänge, inklusive TDD, ATTD und BDD. Im Blog-Artikel How to Use Ranorex Studio in Your BDD Process wird als praktisches Beispiel die Integration von SpecFlow zur Automatisierung von BDD-Szenarios beschrieben.

Fazit

Es gibt dutzende Bücher darüber, wie man effektive Software-Anforderungen verfasst. Dieser Artikel bietet nur eine kurze Übersicht über einige Strategien, die zeigen sollen, wie Sie Anforderungen testbar gestalten können. Die beste Strategie liegt allerdings darin, Tester und Benutzerrepräsentanten von Anfang an in den Prozess der Anforderungsdefinition miteinzubeziehen. Testbare Anforderungen erleichtern die Testautomatisierung, aber am wichtigsten ist, dass das gesamte Team Bescheid weiß, was genau die Anforderungen sind.

Steigen Sie direkt in die Testautomatisierung ein mit unserer kostenlosen 30-tägigen Testversion: