Requirements Engineering & Software Test

Eine leistungsstarke Kombination

Nach mehr als 40 Jahren Erfahrung im Software-Engineering werden immer noch zu viele Projekte überzogen oder scheitern gänzlich. Gründe dafür liegen u.a. in unvollständigen und sich ändernden Anforderungen.

Obwohl man schon viel erreichen kann, wenn man einen dedizierten Requirements Engineer im Team hat, geht dieser Beitrag noch einen Schritt weiter. Die Qualität im Projekt lässt sich noch verbessern, indem man die Erfahrung von Software-Testern bei der Erkennung von Fehlern in Anforderungsspezifikationen in frühen Projektphasen nutzt. Diese Kombination ist sehr vielversprechend, wie die aktuellen Ausbildungsmöglichkeiten für Software-Ingenieure zeigen. Die neue erfolgreiche Superzertifizierung QAMP® (QAMP Quality Assurance Management Professional) umfasst u.a. sowohl Tester- als auch Requirements-Engineering-Skills.

Einführung

Der Chaos Report der Standish Group, der seit 1994 aufgezeichnet wird, ist ein Synonym für die Visualisierung der hohen Raten von Projekten, die Zeit und Budget überziehen oder scheitern. Die Gründe für die niedrige Rate erfolgreicher Projekte sind seit langem Gegenstand von Untersuchungen und den meisten erfolgreichen Projektmanagern hinreichend bekannt. Während einige Probleme durch den Einsatz von Ingenieurtechniken und Standards reduziert werden konnten, sind die folgenden immer noch die häufigsten.

• Unrealistische Zeit- und/oder Ressourcenschätzungen
• Missverständnis des Umfangs/Ziels/Anforderungen
• Geänderte Anforderungen während der Entwicklung
• Mangelndes Engagement des Kunden/Endanwenders
• Schlechte Qualität der Arbeit
• Der Glaube an die Magie

Wie Sie sehen, sind Anforderungen eine der Hauptproblemquellen in dieser Liste. Nicht nur dadurch, dass sie unverständlich sind und sich ändern, sondern auch dadurch, dass sie andere Problemquellen wie Zeit- und Ressourcenschätzungen beeinflussen. Da viele ingenieurtechnische Probleme durch verfeinerte Technologien von der Projektstrukturierung bis hin zu Testmethoden als gelöst gelten, ist die Kluft zwischen Kunden- und Entwicklersicht erst in den letzten Jahren einer zunehmenden Standardisierung unterworfen worden. Während es Notationen und Vorlagen für Anforderungen gibt, gab es lange Zeit noch kein klares Konzept, wie man Anforderungen überhaupt erhebt. Wer soll befragt werden? Was ist zu tun, um keine wichtigen Stakeholder oder Einflüsse zu übersehen? Wie ermittle ich vermeintliche Anforderungen? Methoden zur Anforderungserhebung kombiniert mit Standards und Best-Practice-Ansätzen sind Bestandteil des “Certified Professional for Requirements Engineering” (CPRE), einer relativ neuen Ausbildung für Software-Ingenieure. Mit dem Aufbau dieser Zertifizierung lehnt sich das International Requirements Engineering Board (IREB) eng an das Vorbild des sehr erfolgreichen ISTQB Certified Tester.

Der Zugewinn an professionellem Requirements Engineering

Am Anfang eines jeden Projekts steht das Ziel, so vage und unterschiedlich dieses Ziel in den Köpfen aller Beteiligten auch sein mag. In der Phase der Anforderungsanalyse werden die Projektziele verfeinert und schließlich als konkrete Anforderungen festgehalten. Die Qualität dieser Anforderungen hängt sehr oft von den Fähigkeiten, den persönlichen Zielen und der Unterstützung der Personen ab, die sie aufnehmen. Um diesen Einfluss zu reduzieren, definiert das IREB eine dedizierte Rolle für Requirements Engineers. Dies führt dazu, eine neutrale Person zu haben, die alle Stakeholder und ihre jeweiligen Ziele in einem Projekt identifizieren und berücksichtigen kann. Durch den sorgfältigen Einsatz seiner Kommunikationsfähigkeiten, Vorlagen und Engineering-Methoden kann der Requirements Engineer alle relevanten Anforderungen erheben, dokumentieren und priorisieren. Auch die Validierung und Verifizierung von Anforderungen liegt in der Verantwortung des Requirements Engineers. Verschiedene Dokumentationstechniken sowie Reviews können helfen, unvollständige und fehlerhafte Anforderungen zu identifizieren. Nicht zuletzt hilft ein sorgfältiges Anforderungsmanagement, den Überblick über sich ändernde Anforderungen zu behalten. Der Gewinn liegt auf der Hand: Ein vollständiger Satz verständlicher und testbarer Anforderungen detailliert die Projektziele und erleichtert die Planung, Realisierung und den Test. Es sind die CPRE-Methoden, die wir einsetzen, wenn wir eine neue Anforderungsspezifikation zunächst auf Vollständigkeit und Testbarkeit prüfen und nicht selten identifizieren wir auf diese Weise Spezifikationslücken und vermeintliche Anforderungen.

Die reale Welt

Angesichts all der Ansätze und Techniken im Requirements Engineering sollte kein Projekt an einer unvollständigen Anforderungsspezifikation scheitern. Dennoch werden unserer Erfahrung nach in vielen Projekten Anforderungen immer noch von Domänenexperten spezifiziert, die mit verfeinerten Spezifikationstechniken nicht vertraut sind und oft keine Zeit und Unterstützung für die Erhebung aller relevanten Stakeholder und Details haben. Während die Tatsache, dass gute und erschöpfende Anforderungen ein entscheidender Faktor für den Projekterfolg sind, vielleicht noch nicht im Fokus der Projektleitung steht, ist es die Notwendigkeit des unabhängigen Testens sehr oft. Manche Projektmisserfolge erzeugen viel Medienaufmerksamkeit. Die öffentliche Schlussfolgerung ist sehr oft, dass systematisches Testen Probleme hätte verhindern können. Deshalb darf ein Projektteam nicht nur aus einem professionellen Requirements Engineer bestehen, sondern aus mehreren Testexperten für System– und Abnahmetests.

Lernkurve – Schritt 1

In vielen unserer Projekte erleben wir, dass Kunden das Testen noch als eine Phase nach der Implementierung betrachten. Wenn wir also in das Projekt einsteigen und zum ersten Mal die Gelegenheit bekommen, die Anforderungsspezifikation zu analysieren, befindet sich das System bereits in der Entwicklung. Als zertifizierte Tester hinterfragen wir dann Anforderungen, die nicht detailliert genug sind, um Testfälle zu spezifizieren. Details, die der Kunde vorgibt, sind den Entwicklern meist unbekannt und beinhalten manchmal sogar neue Anforderungen, die aus einer tieferen Reflexion über das System erwachsen sind. Während wir mit den erhaltenen Informationen zufrieden sein können, sind es die Entwickler meist nicht. Wie sollten sie auch, wenn der Kunde plötzlich das Ziel verschiebt. Die Folge sind oft lange Diskussionen, überzogenes Budget und Zeit. Dennoch ist das Feedback für Tester meist großartig, da die Projektleitung unseren tiefen Blick in die Anforderungen zu schätzen weiß. Wie viele der Fehler in einem Projekt auf fehlerhafte Anforderungen zurückzuführen sind, zeigt das folgende Diagramm.

Obwohl anforderungsbasiertes Testen sehr effektiv sein kann, um fehlerhafte Anforderungen zu erkennen, ist die Behebung dieser Fehler im Vergleich zu Fehlern, die in späteren Projektphasen auftreten, teuer.

Lernkurve – Schritt 2

Die offensichtliche Schlussfolgerung aus dem späten Testen ist: Fehler in den Anforderungen müssen früher im Projekt erkannt werden. Eine naheliegende Lösung: Das Testen beginnt bereits zu Beginn des Projekts. Dies ist eine Lösung, die unsere Kunden nach ersten Erfahrungen mit anforderungsbasiertem Testen sehr häufig umsetzen. Die Tatsache, dass dieser Ansatz auch durch den Lehrplan für zertifizierte Tester des ISTQB gefördert wird, hilft, das Thema für zukünftige Projekte zu forcieren. In einem ersten Schritt werden die Tester in den Review-Prozess eingebunden, bevor die jeweilige Anforderungsspezifikation für Design und Implementierung freigegeben wird. Durch ihre Erfahrung in der Qualitätssicherung sind Tester sehr gute Reviewer für Anforderungsspezifikationen. Da es ihre Aufgabe ist, aus Spezifikationen Testfälle abzuleiten, prüfen sie zunächst die Testbarkeit von Anforderungen. Gibt es Kriterien, an denen man erkennen kann, ob eine Anforderung erfüllt ist oder nicht? Sind die Anforderungen erschöpfend, um das Verhalten des Systems zu beschreiben? Wie viel ein Review durch Tester beitragen kann, zeigt die Anzahl der aufgeworfenen Fragen: Während einer 9-monatigen funktionalen Testphase, die bereits während der Implementierung begann, warfen zwei Tester ca. 250 Fragen auf, von denen einige sogar zu einer Erweiterung der Funktionalität bis hin zu Änderungswünschen führten, also etwa eine Frage pro Tester und Tag. In einem anderen, ähnlich komplexen Projekt überprüften 2 Tester ein Konzept vor Beginn der Implementierungsphase innerhalb von 2 Tagen. Da es das erste Review war, haben sie noch nicht einmal mit der Ableitung von Testfällen begonnen. Dennoch wurden in diesen zwei Tagen mehr als 60 Fragen aufgeworfen, die durch eine Überarbeitung des Konzepts gelöst werden konnten, was viele Tage Entwicklungs- und Testaufwand einsparte. Das Besondere an Testern in Reviews ist die andere Sichtweise. Während der Stakeholder oft nur genügend Informationen liefert, um seine Absichten zu vermitteln, ist es das Ziel des Testers, klare und testbare Anforderungen für die Ableitung von Testfällen zu erhalten. Wenn das angestrebte Verhalten in einem Testfall nicht bestimmt werden kann, wird ein Tester unweigerlich Details einfordern. Während z.B. ein Kunde eine ausreichende Performance fordert, damit der Benutzer “ohne Unterbrechungen arbeiten kann”, wird der Tester nach genauen Antwortzeiten fragen. Nur mit diesen ist es möglich zu entscheiden, ob ein Testfall bestanden oder nicht bestanden ist. Während Tester durch ihre Erfahrung gut darin sind, Anforderungen zu verbessern, kann ein Training in Requirements Engineering die Fähigkeiten in der Anforderungserhebung verbessern und das Bewusstsein für vermutete Anforderungen schärfen.

Status Quo

Die beschriebene Lernkurve basiert auf unseren Erfahrungen in relativ kleinen Projekten (jeweils in weniger als zwei Jahren realisiert). Oft hat ein und derselbe Kunde verschiedene Projekte mit verschiedenen Managern. Die Lernkurve beinhaltet also das allgemeine Wissen innerhalb eines Unternehmens. Dies ist ein typischer Status Quo:

Das Testen, das einst der Ausgangspunkt einer Initiative für Qualität in Projekten war, ist mittlerweile ein fester Bestandteil eines jeden Projekts geworden. Der etablierte Testprozess basiert auf den Empfehlungen des ISTQB und Qualifikationen wie eine Testzertifizierung Foundation Level oder Advanced Level werden für jeden neuen Testexperten gefordert, um ein gemeinsames Vokabular und eine gemeinsame Methodik zu etablieren. Mehr als 100.000 zertifizierte Tester in mehr als 40 Ländern beweisen, dass unsere Erfahrung mit den globalen Trends übereinstimmt. Zusätzlich stellen wir einen zunehmenden Fokus auf die Anforderungsqualität fest. Während noch vor wenigen Jahren ein Domänenexperte die Anforderungen an ein neues System anhand einer aus seiner oder der Erfahrung seines Unternehmens gewachsenen Vorlage aufschrieb, ist der Aufwand für die Anforderungserhebung dramatisch gestiegen. Die frühzeitige Einbindung von Testern und Reviews durch verschiedene Stakeholder sind ein Schritt zur zunehmenden Professionalisierung.

Weitere Verbesserung

Wie oben dargestellt, ist die Professionalisierung im Requirements Engineering im Gange. Hier möchten wir beschreiben, was wir zu erreichen hoffen.

Mindestens ein dedizierter Requirements Engineer pro Projekt

Es ist eine allgemein anerkannte Wahrheit, dass unabhängiges Testen ein neutrales und verlässliches Bild der Softwarequalität liefert, da es weder auf der Seite der Entwicklung noch auf der Seite der Kundeninteressen steht. Die gleiche Wahrheit sollte auch für das Requirements Engineering gelten. Obwohl immer noch viele Kunden Domänenwissen verlangen, kann ein engagierter Requirements Engineer mit neutralem Blick durch Domänenexperten eingebrachte Fehler vermeiden, die durch Gewohnheit abgestumpft sind. Zusätzlich kann er das in speziellen Schulungen, wie z.B. CPRE, erworbene Wissen anwenden. Eine gemeinsame Sprache bei der Modellierung von Anforderungen z.B. in UML vereinfacht die Kommunikation mit Entwicklung und Test.

Etablierung von echtem Requirements Testing

System- und Abnahmetests werden auch als spezifikationsbasierte oder anforderungsbasierte Tests bezeichnet. Viele bekannte Testverfahren, wie z. B. Use-Case-Tests oder State-Transition-Tests, sind anforderungsbasiert. Gemeinsam ist diesen Methoden, dass sie auf Modellen beruhen. Obwohl diese Methoden zertifizierten Testern gut bekannt sind, werden sie oft nicht systematisch angewendet.

Um einen sehr guten Anforderungs-Test zu erreichen, sind zwei Ansätze notwendig: Zum einen muss die Anwendung dieser modellbasierten Methoden bei der Spezifikation von Testfällen gefördert werden. Nur dies führt zu reproduzierbarer Testabdeckung. Zum anderen müssen die Modelle bereits in der Review-Phase auf die Anforderungen angewendet werden. Die meisten modellbasierten Testverfahren sind in der Lage, Spezifikationsfehler aufzudecken, eine Eigenschaft, die in der Spezifikationsphase oft unterschätzt wird.

Als Beispiel kann das Testen von Entscheidungstabellen genannt werden. Hier wird die Kombination von Bedingungen, Beziehungen und Constraints getestet. So können bei der Konstruktion von Testfällen undefinierte Ergebnisse aus seltenen Kombinationen erkannt werden.

Ein weiteres Beispiel ist das Testen von Zustandsübergängen. Während Anforderungen häufig in textueller Form dokumentiert werden, kann die Ableitung eines Zustandsmodells genutzt werden, um Prozesse und Verhalten in verschiedenen Zuständen eines Systems abzubilden. Auf diese Weise können oft zusätzliche Anforderungen identifiziert werden.

Letztlich führt die Anwendung der bereits bekannten Methoden nicht nur zu einer Verbesserung der Testabdeckung von Anforderungen, sondern auch zu einer Verbesserung der Anforderungsqualität.

Ein weiterer Vorteil gemeinsamer Modelle im Requirements Engineering und Testen ist die drastisch verbesserte Rückverfolgbarkeit. Besonders in sicherheitskritischen Systemen ist es notwendig, dass Anforderungen zu ihren Modellen und weiter zu den Testfällen, die diese Modelle verifizieren, und wieder zurück zurückverfolgt werden können. Durch die Verwendung gemeinsamer Modelle kann die Abdeckungsmetrik einen detaillierten Status liefern, beginnend mit der gesamten Testabdeckung bis hin zur Abdeckung jedes einzelnen Modellelements und jeder einzelnen Anforderung.

Sind wir schon da?

Das Ziel einer hohen Anforderungsqualität scheint nicht mehr weit zu sein. Das Bewusstsein für Anforderungsqualität nimmt bei Kunden und Anbietern von Software Engineering zu. Für eine nachhaltige Wirkung ist eine geeignete Schulung für alle Beteiligten unerlässlich. Die Schulung darf nicht nur einzelne Techniken ansprechen, sondern sollte sich auf die Zusammenhänge zwischen den verschiedenen Projektrollen konzentrieren. Gemeinsame Modellierungssprachen und eine Vorstellung von den Zielen und der Arbeit der anderen Teammitglieder verbessern die gegenseitige Wertschätzung und ermöglichen die Rücksichtnahme auf die Anforderungen des jeweils anderen. Die Erfordernisse der Zusammenarbeit sollten auch in Schulungen angesprochen werden. Es gibt bereits Qualifizierungsmaßnahmen für einen ganzheitlichen Ansatz zur Softwarequalität, der Requirements Engineering und Test integriert. Eines davon ist die neue Superzertifizierung QAMP® (Quality Assurance Management Professional), die auf CPRE und Certified Tester Foundation Level (CTFL®) aufbaut. Beide Ausbildungen folgen etablierten Ansätzen und sind in sich stimmig. Doch QAMP geht noch weiter: Obwohl CPRE und CTFL die Grundlage des QAMP bilden, werden Erfahrungsnachweise und weitere Qualifikationen, wie z.B. Projektmanagement, Testmanagement oder Secure Software Engineer gefordert. Für periodische Re-Zertifizierungen sind aktuelle Berufserfahrungen, Forschungsaktivitäten oder weitere Qualifikationen notwendig. Damit stellt QAMP die Verpflichtung zu lebenslangem Lernen jedes Zertifikatsinhabers sicher.

Es ist offensichtlich, dass Werkzeuge und Methoden ausreichen. Jetzt ist es unsere Herausforderung, ein Bewusstsein für den großen Nutzen zu schaffen, den die Kombination von Software-Test und Requirements Engineering bringen kann.