Gute Anforderungen sollten klar, präzise, vollständig, konsistent und überprüfbar sein. Dies lässt sich am besten erreichen, indem man bereits bei der Anforderungsspezifikation auch an die Testbarkeit denkt. Obwohl es einfach klingt, gleichzeitig Tests zu den Anforderungen zu entwickeln, wird dies in der Praxis selten umgesetzt, da es zunächst aufwändig erscheint und zeitintensiv ist. Doch dadurch geht viel Potenzial verloren!
Ein Beispiel: Stellen Sie sich vor, Sie sind Product Owner in einem agilen Team. Ihr Aufgabe ist es, eine Applikation zu entwickeln, mit der sich Bewerber:innen über die Unternehmenswebseite bewerben können. Eine Anforderung an so eine Applikation könnte beispielsweise sein:
Als Bewerber:in möchte ich Zertifikate hochladen, um meine Fertigkeiten und Fähigkeiten nachzuweisen.
Akzeptanzkriterien:
- Zertifikate können in unterschiedlichen Dateiformaten vorliegen (z.B. PDF, PNG, JPG).
- Eine hochzuladende Zertifikatsdatei darf bis zu 5 MB groß sein.
- Bewerber:in kann bis zu 30 Zertifikate hochladen.
Oft erfolgt nach dem Spezifizieren sofort die Umsetzung, Testfälle werden erst danach erstellt. Wir empfehlen stattdessen, bereits mit der Story und den Akzeptanzkriterien (oder Use Case oder funktionale Spezifikation) die Tests bzw. Testbedingungen zu spezifizieren. Testbedingungen beschreiben dabei auf Überschriftenebene jene Bedingungen, die beim Test zu prüfende und vom System zu erfüllen sind. Idealerweise werden die Testbedingungen vom Requirements Engineer (Product Owner, Product Manager etc.) gemeinsam mit Entwickler:innen und Tester:innen erstellt.
Für unsere Anforderung sollten Sie als Product Owner gemeinsam mit den Entwickler:innen und Franz, unserem Senior Test Engineer, Tests erarbeiten. Franz kann dabei als zertifizierter Tester methodisches Fachwissen einbringen, um effizient und vollständig Tests für eine Anforderung zu entwickeln:
Als Bewerber:in möchte ich Zertifikate hochladen, um meine Fertigkeiten und Fähigkeiten nachzuweisen.
Akzeptanzkriterien:
- Zertifikate können in unterschiedlichen Dateiformaten vorliegen (z.B. PDF, PNG, JPG).
- Eine hochzuladende Zertifikatsdatei darf bis zu 5 MB groß sein.
- Ein Bewerber kann bis zu 30 Zertifikate hochladen.
Tests (Testbedingungen):
- Benutzer:in lädt eine Zertifikatsdatei im PDF Format mit < 2 MB hoch.
- Benutzer:in lädt 10 PDF Zertifikatsdateien mit < 2 MB hoch.
- Benutzer:in lädt eine PNG und eine JPG Zertifikatsdatei mit < 2 MB hoch.
- Benutzer:in lädt 30 Zertifikatsdateien mit < 2 MB hoch.
- Benutzer:in versucht, 50 Zertifikatsdateien hochzuladen.
- Benutzer:in versucht, eine Zertifikatsdatei mit > 5 MB hochzuladen.
- Benutzer:in versucht 10 Zertifikatsdateien mit <= 5 MB und eine mit > 5 MB hochzuladen.
- …
PS: Wir empfehlen, Positiv-Testfälle als ganze Sätze aus Sicht der Benutzer:in zu schreiben und Negativ-Tests immer mit „Benutzer:in versucht…“ zu starten.
Während der Spezifikation der Testfälle erkennt Franz, der Senior Tester: „Moment mal, was passiert, wenn ein Bewerber versehentlich eine falsche Datei unter den 50 Dateien auswählt und hochlädt? Wäre eine Vorschaufunktion nicht sinnvoll, damit man noch einmal überprüfen kann, ob die richtigen Dateien ausgewählt wurden?“ Nach kurzem Überlegen stimmen alle Franz zu, und die Vorschaufunktion wird als zusätzliches Akzeptanzkriterium hinzugefügt.
Es passiert erfahrungsgemäß häufig, dass beim Erstellen der Tests fehlende Funktionen oder Mängel in den Anforderungen entdeckt werden. Wenn dies bereits während der Anforderungsspezifikation geschieht, können daraus resultierende Probleme kostengünstig behoben werden, ohne zusätzlichen Entwicklungsaufwand zu verursachen. Dadurch sinken die Gesamtentwicklungskosten, da die Tests ohnehin spezifiziert werden müssen. Genial, oder? Doch das ist nur einer der Vorteile, wenn man frühzeitig Tests spezifiziert. Hier sind einige weitere:
- Die Diskussion stärkt das gemeinsame Verständnis für die Anforderungen.
- Die Früherkennung von Mängeln und fehlenden Funktionen ermöglicht eine kostengünstige Behebung.
- Einfachere Identifikation von bisher verborgenen Sonderfällen und Ablaufvarianten.
- Entwickler:innen wissen, wie Funktionen getestet werden und können dies selbst umsetzen.
- Es ermöglicht Tester:innen ihren Aufwand besser zu verteilen. So kann vermieden werden, dass am Projektende alles zusammenkommt.
- Schnellere Fertigstellung eines besseren Produkts im Sinne von weniger Fehlern und funktionaler Vollständigkeit.
Tests gleich bei der Anforderungsspezifikation mitbeschreiben – das ist ein Beispiel für ein „Quick Win“ in der Software-Entwicklung, also mit wenig Aufwand viel zu erreichen. Das sollten wir nutzen, oder?
Wenn Sie mehr zu diesem Thema wissen möchten oder diesen und noch weitere „Wins“ und sogar „Quick Wins“ im Requirements Engineering, in der Software-Entwicklung oder im Testen und in der Qualitätssicherung in Ihrer Organisation nutzbar machen wollen, kontaktieren Sie unsere erfahrenen Software Quality Lab Consultants! Wir helfen Ihnen gerne dabei, Schritt für Schritt besser zu werden und Ihre Software-Entwicklung zu optimieren.