Testing und Requirements Engineering

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.

Lust auf einen "Blick über den Tellerrand"?

Einen guten Einblick ins Testing und ins Requirements Engineering erhalten Sie in unseren Seminaren zum IREB® Certified Requirements Engineer und ISTQB® Certified Tester.

Dr. Gabriele Haller

Dr.,

Dr. Gabriele Haller ist im Auftrag der ISARTAL akademie für Seminare zum IREB® Certified Requirements Engineer und ISTQB® Certified Tester als freiberufliche Trainerin tätig. Darüber hinaus leitet sie den Arbeitskreis Requirements der GI-Regionalgruppe München.

Kommentare

Keine Kommentare

Kommentar schreiben

Ihre E-Mail-Adresse wird nicht veröffentlicht.

* Diese Felder sind erforderlich

Bleiben Sie auf dem Laufenden – Registrieren Sie sich für unseren Newsletter