Wenn ein Testteam zu Ihrem Projekt stößt, fragt es zuerst nach Ihren Anforderungen. Diese Bitte wirkt vage, wenn Sie nur alte Spezifikationen, ein paar Tickets und Wissen haben, das in den Köpfen der Leute steckt. Anforderungen an Softwaretests sind die schriftlichen Beschreibungen dessen, was Ihr Produkt tun soll, klar genug, dass jemand außerhalb Ihres Teams das Ergebnis prüfen kann.
Sie decken die Funktionen ab, die Sie bauen, die Geschäftsregeln dahinter und die Bedingungen, die darüber entscheiden, ob etwas funktioniert. Tester lesen sie, um zu erfahren, was als korrekt gilt.
Allerdings sind „Anforderungen haben“ und „Anforderungen haben, gegen die jemand testen kann“ zwei verschiedene Dinge. Viele Teams besitzen Dokumente, die das Produkt korrekt beschreiben, und lassen einen Tester trotzdem ohne Möglichkeit zurück, nachzuweisen, dass eine Funktion funktioniert. Um genau diesen Unterschied geht es in diesem Leitfaden, denn er entscheidet, wie schnell Ihr Testing startet und wie viel davon auf Raterei beruht.
Sie erfahren, welche Dokumente Tester tatsächlich nutzen, was eine Anforderung testbar macht, wie ein QA-Team die von Ihnen gesendeten Anforderungen prüft und wo Sie anfangen, wenn noch nichts davon existiert. Falls Ihnen Letzteres bekannt vorkommt: unsere Services für technische Dokumentation decken genau diese Lücke ab.
Welche Anforderungen an Softwaretests Braucht ein QA-Team?
Die meisten Teams übergeben die Spezifikationen und Tickets, die sie ohnehin haben, und hoffen, dass es reicht. Meistens tut es das nicht, wobei die Lücke selten dort sitzt, wo man sie erwartet. Vier Dokumente tragen die Informationen, die Tester brauchen, und zwei davon haben Sie vermutlich schon:
- SRS, die Software-Anforderungsspezifikation. Das ist das detaillierte Dokument, das jede Funktion auflistet und beschreibt, wie sie sich verhalten soll.
- BRD, das Business-Requirements-Dokument. Es steht über dem SRS und erklärt, warum das Produkt existiert und wem es dient.
- User Stories und Use Cases. Sie nähern sich derselben Sache von der Nutzerseite und zeigen, was jemand erreichen will.
- Akzeptanzkriterien. Sie sind die kürzesten und oft die nützlichsten, eine Handvoll Bedingungen, die klären, ob eine Funktion fertig ist.
SRS
Wie sich jede Funktion verhalten soll
Business Analyst oder Product Owner
Tester raten das beabsichtigte Verhalten und melden dann funktionierende Features als Bugs
BRD
Warum das Produkt existiert und wem es dient
Business-Stakeholder
Der Aufwand verteilt sich gleichmäßig, statt das zu schützen, was Ihr Geld verdient
User Stories und Use Cases
Was eine Person erreichen will
Product Owner, gemeinsam mit dem Team
Die Abdeckung folgt Screens statt echten Nutzerwegen, also überleben kaputte Pfade
Akzeptanzkriterien
Die Bedingungen, die klären, ob eine Funktion fertig ist
Product Owner, verfeinert mit QA
Jedes Release endet in einer Diskussion darüber, ob die Arbeit abgeschlossen ist
Sie brauchen nicht alle vier, um zu starten. Ein klarer Satz Akzeptanzkriterien bringt einem Tester mehr als eine hundertseitige Spezifikation, die seit letztem Jahr niemand geöffnet hat. Entscheidend ist, dass jemand außerhalb des Gesprächs Ihre Anforderungen an Softwaretests lesen und wissen kann, was zu prüfen ist.
Hinter all dem steht auch ein offizieller Standard. ISO/IEC/IEEE 29148, derzeit in der Ausgabe von 2018, regelt, wie Anforderungen geschrieben werden sollten und was eine Spezifikation enthalten sollte. Sie müssen ihn mit ziemlicher Sicherheit nicht lesen, und die meisten Teams tun es nie. Es lohnt sich zu wissen, dass es ihn gibt, denn ein Auditor, eine Aufsichtsbehörde oder ein großer Enterprise-Kunde könnte fragen, welchem Standard Ihre Anforderungen folgen.
Was Macht eine Anforderung Testbar?
Eine Anforderung ist testbar, wenn eine Person, die sie nicht geschrieben hat, sie lesen, das Produkt prüfen und zum selben Schluss kommen kann wie alle anderen. Das klingt selbstverständlich, geht aber verloren, weil der Verfasser bereits weiß, was er gemeint hat, und die Lücken für ihn deshalb unsichtbar bleiben.
So sieht der Unterschied in der Praxis aus.
Die App sollte schnell laden.
Nutzer sollten ihr Passwort zurücksetzen können.
Eine Zurücksetzungs-E-Mail trifft innerhalb von 2 Minuten ein, und der Link funktioniert nach 24 Stunden nicht mehr.
Der Checkout sollte Fehler elegant behandeln.
Wird eine Karte abgelehnt, behält der Warenkorb seine Artikel, es fließt kein Geld, und der Käufer sieht den Grund.
Achten Sie darauf, was sich geändert hat: Jede testbare Version benennt etwas, das eine Person beobachten und dem sie zustimmen kann. Keine davon brauchte mehr technisches Detail, nur eine Entscheidung, die früher oder später ohnehin jemand treffen musste.
Drei Fragen verraten Ihnen, ob eine Anforderung bereit ist:
- Können Sie beschreiben, wie „funktioniert“ aussieht, ohne die Wörter gut, schnell oder einfach?
- Würden zwei Personen beim Lesen dasselbe Ergebnis erwarten?
- Kann jemand es prüfen, ohne den Verfasser zu fragen, was gemeint war?
Dreimal ja, und die Anforderung wird fast unmittelbar zu einem Testfall, und genau dort startet unsere Arbeit im Funktionstesten üblicherweise.
Wie Prüft ein QA-Team Ihre Anforderungen?
Bevor überhaupt ein einziger Test läuft, liest ein gutes QA-Team, was Sie geschickt haben, und kommt mit Fragen zurück. Diese Prüfung geht schnell und verhindert später eine Menge vergeudete Arbeit.
Ein Prüfer sucht nach einer bestimmten Gruppe von Problemen:
- Was passieren soll, wenn etwas fehlschlägt, da die meisten Dokumente nur den Erfolgsfall beschreiben
- Situationen, die niemand erwähnt hat, etwa ein leeres Konto, ein Erstbesucher oder eine abgelaufene Karte
- Zwei Dokumente, die Unterschiedliches über dieselbe Funktion sagen
- Regeln ohne jede Zahl, wie schnell, sicher oder benutzerfreundlich
- Wer was tun darf, wenn es niemand aufgeschrieben hat
Jeder Punkt auf dieser Liste wird zu einer Frage an Ihr Team. Eine davon zu beantworten, während die Dokumente noch entstehen, geht schnell. Dieselbe Frage nach dem Release bedeutet Code ändern, die Tests erneut laufen lassen und die Verzögerung demjenigen erklären, der das Problem gemeldet hat.
Es hilft, ein paar verwandte Begriffe zu trennen. Anforderungen sind das, womit Testing beginnt. Die Ziele des Softwaretestens sind das, wofür Testing da ist. Ihr Produkt gegen diese Dokumente zu prüfen heißt Verifizierung, und zu bestätigen, dass es das richtige Problem löst, ist Validierung. Den Unterschied erklären wir in Verifizierung vs Validierung im Softwaretesten.
Warum Sie Nicht auf die Finale Dokumentation Warten Sollten
Teams halten QA oft zurück, bis der Papierkram fertig ist. Bei einem Produkt, das noch gebaut wird, ist er das allerdings nie ganz.
Warten kostet Sie doppelt:
- Widersprüche überleben. Ein Konflikt zwischen zwei Dokumenten fällt erst auf, wenn jemand Code dagegen schreibt, und ihn dann zu beheben heißt umbauen statt redigieren.
- Sie verlieren Ihren besten Leser. Ein QA-Engineer, der eine halbfertige Spezifikation durchgeht, entdeckt die fehlenden Teile aus reiner Gewohnheit.
Übergeben Sie also, was heute existiert, so unvollständig es auch ist. Tester können anhand der bereits geklärten Teile mit dem Aufbau von Prüfungen beginnen, während der Rest nachzieht, und ihre Fragen fließen direkt in die Dokumente zurück, an denen Sie noch schreiben.
Deshalb steigen wir in Projekte in dem Stadium ein, das sie gerade erreicht haben, statt auf eine fertige Übergabe zu warten. Unser Leitfaden zum agilen Testen zeigt, wie das Sprint für Sprint läuft, und unser Rundgang durch die Phasen des Softwaretests behandelt die Etappen, die die Arbeit selbst durchläuft.
Was Tun, Wenn Ihre Anforderungen Unvollständig Sind
Viele Produkte erreichen uns mit fast nichts Schriftlichem. Das ist normal, besonders wenn das Team, das die erste Version gebaut hat, längst weitergezogen ist. Sie haben mehr Rohmaterial, als Sie denken.
- Schreiben Sie auf, was das Produkt heute tut. Bei einem laufenden Produkt ist das aktuelle Verhalten eine legitime Quelle, und es zu bestätigen schlägt es von Grund auf zu erfinden.
- Beginnen Sie mit den Wegen, die Geld verdienen. Registrierung, Checkout und Verlängerung verdienen schriftliche Bedingungen lange vor einem Einstellungsbildschirm.
- Verwandeln Sie vorhandenes Wissen laufend in Akzeptanzkriterien. Jede Antwort, die jemand in einem Meeting gibt, ist eine Anforderung, die darauf wartet, festgehalten zu werden.
- Legen Sie diese Entscheidungen an einen auffindbaren Ort. Eine gemeinsame Seite schlägt einen Chat-Thread, und der schlägt das Gedächtnis einer einzelnen Person.
Diese Arbeit ist eher ein Schreib- als ein Testjob, weshalb die meisten QA-Dienstleister sie Ihnen direkt zurückgeben und warten. Wir dagegen schreiben die fehlenden Dokumente selbst und testen dann dagegen, was Ihnen erspart, zwei Firmen dafür zu bezahlen, dass sie sich untereinander einig werden.
So lief das Projekt Logo Maker Shop. Seine Android-Version erreichte uns ganz ohne Testdokumentation, und die Regeln, die es gab, lagen verstreut als Kommentare auf Figma-Screens. Wir rekonstruierten den Rest daraus, wie sich die iOS-App bereits verhielt, fragten unterwegs nach dem, was fehlte, und schrieben 270 Testfälle von Grund auf.
Wie QAwerk die Anforderungslücke Schließt
Klare Anforderungen an Softwaretests zahlen sich aus einem schlicht wirtschaftlichen Grund aus. Sie senken die Stunden, die Ihr Team mit dem Erklären des Produkts verbringt, sie reduzieren die Defekte, die sich als Missverständnisse entpuppen, und sie beenden die Diskussion darüber, ob eine Funktion fertig ist. Testbare Anforderungen sind das, was alle drei möglich macht.
Wenn Ihre Dokumente dahinter zurückbleiben, schließen wir die Lücke in drei Schritten. Zuerst lesen wir, was Sie haben, und kommen mit den Fragen zurück, die es aufwirft. Dann bringen wir die fehlenden Teile zu Papier, damit Ihre Testfälle aus einem Dokument statt aus einer Annahme entstehen. Parallel startet das Testen mit dem, was bereits abgestimmt ist, und wächst von dort. Wir haben das in über 300 Projekten gemacht, mit über 30 Senior-QA-Engineers im Team, die im Schnitt je 9 Jahre Erfahrung mitbringen.
Wenn Sie unsicher sind, ob das Vorhandene zum Testen ausreicht, buchen Sie ein Gespräch mit unserem QA-Team, und wir gehen Ihre Dokumente durch, bevor Sie sich zu irgendetwas verpflichten.
FAQ
Was sind Anforderungen an Softwaretests?
Anforderungen an Softwaretests sind das, womit ein QA-Team arbeitet, üblicherweise eine Spezifikation, ein Business-Dokument, User Stories, Akzeptanzkriterien oder eine Mischung daraus. Ihre Aufgabe ist es, festzuhalten, was das Produkt tun soll, und zwar so präzise, dass ein Tester ohne Rückfrage entscheiden kann, ob ein bestimmtes Ergebnis korrekt oder ein Defekt ist.
Was ist ein SRS im Testing?
Ein SRS, also eine Software-Anforderungsspezifikation, ist das ausführliche Dokument, das jede Funktion im Detail darlegt. Ein SRS zum Testen zu nutzen bedeutet, dass sich jedes erwartete Ergebnis auf eine geschriebene Zeile zurückführen lässt, sodass ein Tester einen echten Defekt von etwas unterscheiden kann, das absichtlich so gebaut wurde. Teams mit kurzen Sprints lassen es oft weg und stützen sich stattdessen auf User Stories plus Akzeptanzkriterien.
Was macht eine Anforderung testbar?
Achten Sie auf Adjektive. Schnell, sicher, intuitiv und benutzerfreundlich beschreiben eine Meinung statt eines Ergebnisses, also werden zwei Personen sie unterschiedlich beurteilen. Eine testbare Version setzt etwas Messbares an ihre Stelle: eine Ladezeit, eine Berechtigungsregel oder die genauen Schritte, die eine Person durchläuft. Eine umzuschreiben dauert meist einen Satz und erspart Ihnen eine Diskussion, die Sie sonst beim Release hätten.
Kann Testing ohne vollständige Anforderungen starten?
Ja, und auf vollständige Dokumente zu warten kostet meist mehr, als früh zu beginnen. Ein QA-Team kann mit Teilspezifikationen, dem aktuellen Verhalten des Produkts und Gesprächen mit denen arbeiten, die es am besten kennen. Die Prüfung fördert die Lücken für Sie zutage, was schneller ist, als zuerst alles zu schreiben und die Widersprüche später zu finden.
Wer schreibt die Akzeptanzkriterien?
Normalerweise entwirft sie der Product Owner und verfeinert sie dann mit den Entwicklern und Testern, die damit arbeiten werden. Sie allein zu schreiben ist der verbreitete Fehler, denn die Bedingungen decken dann meist nur den Fall ab, in dem alles klappt. Eine kurze Abstimmung mit QA ergänzt jene, die der erste Entwurf übersieht, und genau dort beginnen die meisten Meinungsverschiedenheiten darüber, was fertig ist.
Gratis für Sie: Testfall-Vorlage
