Mein Einstieg ins Berufsleben begann als Testerin von Softwaresystemen. Vom Testen hatte ich keine Ahnung, dafür aber reichlich Motivation. Meine neuen Kollegen standen mir hilfreich zur Seite und es lief ganz gut. Schon bald fühlte ich mich sicher – zumindest bis zu dem Moment, als ich wissen wollte, woher denn die Information darüber kommt, was genau das Testobjekt können soll.

Die Frage stellte ich mehreren Personen und bekam interessante Antworten: »Ein guter Tester weiß das.« Oder: »Frag den Achim« oder auch: »Versuch halt rauszufinden, was du mit dem System machen kannst, ohne dass es abstürzt.« Aha! Wirklich zufriedenstellend war das nicht. Und natürlich fand ich mit einer etwas systematischeren Recherche schnell heraus, dass es eigentlich Spezifikationen geben sollte, in denen genau dokumentiert ist, was ein System können soll.

Zwei Welten, die nicht immer harmonieren

Obwohl das nun bereits 20 Jahre her ist und sich sowohl das Test Engineering als auch die Methodik des Requirements Engineering weiter verbreitet haben, kommt es mir manchmal noch immer so vor, als ob die eine Welt von der anderen nichts weiß.

Typische Problemquellen: 

• Fehlende oder ungenaue Requirements: Diese lassen den Tester im Unklaren über den tatsächlichen Funktionsumfang und das Systemverhalten.
• Requirements, die nicht testbar sind: Bei diesen lässt sich später nicht sagen, ob sie denn nun vollständig umgesetzt sind oder nicht. Ein Beispiel: »Das System soll einfach zu bedienen sein.« Wie lässt sich das nachweisen? Was für die eine Person einfach erscheint, mag für jemand anderen weniger naheliegen.
• Ziellose Tests: Dabei geht es um Tests, die keinen Bezug zu den Requirements haben.
• Fehlende Tests: Es kommt vor, dass nicht jedes Requirement später auch wirklich nachgewiesen wird.
• Ungenaue Dokumentation: Gefundene Fehler, die ihre Ursache im Requirement haben, werden zwar im System (z.B. im Code) korrigiert – die Spezifikation wird aber nicht aktualisiert. Die Requirements sind damit veraltet, noch bevor das System in Betrieb gegangen ist.

Testing und Requirements Engineering zusammen denken

Aus dieser Erfahrung heraus plädiere ich dafür, die beiden Disziplinen Requirements Engineering und Test Engineering gemeinsam zu betrachten und sehr eng miteinander zu verzahnen. Ganz nach dem Motto: Wer A sagt, muss auch B sagen bzw. wer »Requirements Engineering« sagt, muss zwingend auch »Test Engineering« sagen und umgekehrt.

Wenn Requirements Engineer und Tester bereits frühzeitig im Systementwicklungsprozess zusammenarbeiten, können sie einerseits durch wechselseitige Reviews feststellen, ob alle Requirements präzise genug und testbar beschrieben sind. Andererseits sehen sie, ob die Testfälle die Requirements auch wirklich korrekt widerspiegeln. Auch die gemeinsame Ausarbeitung von Abnahmekriterien für die Requirements wäre denkbar, um eine enge Verzahnung und damit einen engen Austausch zu gewährleisten.

Gemeinsam ein hochwertiges System schaffen

Manchmal fragen mich meine Seminarteilnehmer, ob es sinnvoll ist, zusätzlich zum »ISTQB® Certified Tester – Foundation Level«-Seminar auch noch das »IREB® Certified Professional for Requirements Engineering – Foundation Level«-Seminar zu besuchen oder umgekehrt. Ich persönlich würde das ganz stark befürworten – und es ist kein Zufall, dass ich beide Seminare unterrichte. Denn der gute Tester und der gute Requirements Engineer müssen beide über ihren Tellerrand hinausschauen können und etwas von der Methodik des jeweils anderen verstehen, um so effektiv wie möglich zusammenarbeiten zu können. So schaffen sie gemeinsam im Team ein hochwertiges System.