Fünf Gründe, warum Requirements Engineering für Tester:innen wichtig ist

Höheres Verständnis für den Inhalt der Anforderungen

Wusstest du, dass es zahlreiche Möglichkeiten gibt, Anforderungen darzustellen? Im agilen Umfeld werden sie häufig in Form von User Stories erfasst. Diese zählen laut der Definition des international tätigen IREB Boards und dem Lehrplan zum Basiszertifikat Certified Requirements Engineering - Foundation Level (IREB CPRE) zu den vorlagenbasierten Arbeitsprodukten, da sie typischerweise einer festen Syntax folgen („Als [Rolle] möchte ich [Ziel/Aktion], sodass [Nutzen]“).

Neben diesen gibt es auch Anforderungen in reiner natürlicher Sprache, bei der Anforderungen frei formuliert werden. Das kann zu mehr Interpretationsspielraum führen.

Wenn ihr es ganz formal haben möchtet, könnt ihr außerdem Modelle nutzen. Diese bieten durch ihre Formalität oft mehr Eindeutigkeit – vorausgesetzt, man ist mit ihnen vertraut.

Im Kurs lernst du nicht nur, wie du Modelle nutzt, sondern auch, wie sie helfen können, Anforderungen besser zu verstehen. Zum Beispiel, indem du eine Anforderung in eine andere Darstellungsform überführst, um zu prüfen, ob sie wirklich eindeutig und verständlich ist.

Bessere Testfälle durch bessere Anforderungen

Genau diese Überführung von Anforderungen in verschiedene Dokumentationsformen kann auch zu besseren Testfällen beitragen. Wie aus dem ISTQB CTFL (ISTQB Grundlagenkurs des international anerkannten Zertifikats zum ISTQB Certified Tester Foundation Level) bekannt, greifen Tester:innen häufig auf systematische Test Entwurfsverfahren zurück.

Vorlagenbasierte Arbeitsprodukte (wie z. B. Satzschablonen) oder Modelle bieten dabei nicht nur Eindeutigkeit, sondern können auch direkt bei der Testfallableitung unterstützen.

Zusätzlich lernen Tester:innen im IREB CPRE die Qualitätskriterien kennen, die Anforderungen möglichst in hohem Maß erfüllen sollten. Wenn Tester:innen aktiv in den Review-Prozess eingebunden werden, entstehen nicht nur bessere Anforderungen – sondern auch die Chance, daraus eindeutige und risiko-orientierte Testfälle abzuleiten.

Unterstützung des Whole-Team-Ansatzes

In der Regel gibt es im Projekt nicht „den einen“ Requirements Engineer. Jede Person, die Aufgaben übernimmt, die dem Requirements Engineering zugeordnet sind, übernimmt in diesem Moment auch Verantwortung in diesem Prozess.

Im Whole-Team-Ansatz sollen durch vielfältiges Wissen, gemeinsames Interesse an Qualität und Eigenverantwortung Synergien entstehen. Diese können gefördert werden, wenn z. B. ein:e Tester:in bereits bei der Erstellung oder Verfeinerung von Anforderungen mitwirkt.

Ganz im Sinne des Shift-Left-Prinzips werden Anforderungen möglichst früh statisch geprüft. Über eine „Probeentwicklung" – zum Beispiel durch die Überführung in Testfällen – kann bereits früh ein gemeinsames Verständnis im Team aufgebaut werden.

Natürlich müssen im Whole-Team-Ansatz nicht zwingend Tester:innen diese statischen Prüfungen durchführen. Es ist jedoch häufig sinnvoll, unterschiedliche Rollen in die Validierung einzubeziehen. (Validierung im Sinne des Requirements Engineering bedeutet die Prüfung der Arbeitsprodukte und Anforderungen hinsichtlich ihrer Qualität.)

Änderungsmanagement und Traceability

Wer kennt es nicht: Alles ist eigentlich release-fertig – und dann muss aus irgendwelchen Gründen eine Anforderung doch noch einmal geändert werden. Das ist nicht nur ärgerlich, sondern kann auch einen enormen Mehraufwand verursachen.

Wie groß dieser Aufwand ist, zeigt uns eine Auswirkungsanalyse. Um sie nutzen zu können, brauchen wir sogenannte Traces.

Was passiert, wenn ich Anforderung N ändere? Was ist davon betroffen? Wo ist diese Anforderung implementiert? Welche Testfälle müssen angepasst werden? Und wie hoch ist das Risiko dieser Änderung?

Diese und viele weitere Fragen sollten im Rahmen des Änderungsmanagements beantwortet werden. Für uns als Tester:innen sind dabei vor allem der zusätzliche Testaufwand und das möglicherweise veränderte Risiko interessant.

Im IREB CPRE lernst du, wie du Anforderungen sinnvoll nachverfolgbar machst (und auch, wann zu viel Traceability eher schadet), sodass du im Projekt das Änderungsmanagement unterstützen kannst, um auch auf Änderungen optimal reagieren zu können.

Erhöhung der gesamten Produktqualität

Unterschiedliche Rollen tragen durch ihre Erfahrung unterschiedliche Perspektiven zur Projektarbeit bei. Ein:e Tester:in wird oft andere Risiken identifizieren als z. B. ein:e Entwickler:in.

Tester:innen können einen wichtigen Beitrag leisten, indem sie bereits zu Beginn eines Requirements-Engineering-Prozesses unterstützend am Kontext* mitarbeiten, sodass dieser möglichst konkret erfasst wird und Risiken früh minimiert werden können.

So kann Test-Know-how einen erheblichen Beitrag zur Produktqualität leisten – und zwar lange bevor überhaupt das erste Inkrement „in der Hand gehalten“ werden kann.

(*Hinweis: Der Kontext im Requirements Engineering bezeichnet die Gesamtheit, die einen Einfluss auf das zu entwickelnde System hat. Er beeinflusst also maßgeblich die Anforderungen. Es ist hierbei wichtig, den Kontext möglichst von Anfang an stabil zu halten, um das Risiko von Fehlern zu minimieren.)

Fazit

In einer idealen Welt wird Qualität nicht erst am Ende „reingetestet“, sondern entsteht schon am Anfang – bei Anforderungen, Verständnis und gemeinsamen Erwartungen. Damit Tester:innen hier wirklich mitgestalten können, brauchen sie mehr als Testmethoden: Sie brauchen ein solides Verständnis dafür, wie Anforderungen entstehen, wie man sie bewertet und wie man sie verbessert, um Anforderungen wirksam zu hinterfragen, testbar zu machen und aktiv zur Qualität beizutragen – und genau das vermittelt die IREB CPRE Schulung.