Die Diskrepanz zwischen Anforderung und Implementierung

Man kennt den klassischen Weg, Anforderungen zu spezifizieren: ein Spezifikationsdokument mit den Kundenanforderungen wird erstellt (oft „Lastenheft“ genannt), dann ein Dokument, das die Umsetzung der Kundenanforderungen beschreibt (oft „Pflichtenheft“ genannt).

Ist damit sichergestellt, dass die Implementierung korrekt sein wird? Nein. Dafür gibt es – hoffentlich – Tests. Die Tests sollten die Implementierung gegen die Anforderungen prüfen. Bei Änderungen der Anforderungen, zum Beispiel bei einem neuen Release, muss die Implementierung wieder getestet werden.Gerade bei komplexen Software-Systemen kann man enorm Zeit sparen, indem man Tests automatisiert, denn nur dann lassen sich die Tests schnell und reproduzierbar wiederholen. Ansonsten besteht die Gefahr, dass gerade die scheinbar ungeänderte Funktionalität nicht ausreichend getestet wird – obwohl sich durch das Hinzufügen neuer Funktionalität auch in sie Fehler einschleichen können.

Aber: wer prüft denn, ob die automatisierten Tests das Richtige testen – also ob die Tests prüfen, ob die Anforderungen richtig umgesetzt wurden? Das Pflichtenheft kann perfekt zum Lastenheft passen, wenn die Tests dann nicht gegen die Anforderungen testen, war der Spezifikationsaufwand zumindestens teilweise umsonst.

Diesem Problem wird in der Praxis manchmal dadurch begegnet, dass man zusätzlich Spezifikationen für die Testfälle schreibt. Diese Testspezifikationen müssen zu den Anforderungen passen, und die Automatisierung der Testfälle geschieht dann anhand der Testspezifikation.

Ist damit nun endlich sichergestellt, dass die Implementierung korrekt ist? Nein. Selbst wenn alle Tests erfolgreich verlaufen, ist nicht sichergestellt, dass die Testfälle der Testspezifikation genügen und tatsächlich gegen die Anforderungen prüfen. Ist ein Element der Kette Lastenheft -> Pflichtenheft -> Testspezifikation -> Testautomatisierung fehlerhaft, dann gibt es eine Diskrepanz zwischen den Anforderungen und der Implementierung. Meine Erfahrung ist, dass auf ein Review der programmierten, automatisierten Testfälle häufig verzichtet wird – auch deswegen, weil sich die Autoren von natürlichsprachlichen Dokumentationen nicht unbedingt mit der verwendeten Programmiersprache auskennen.

Aber es gibt Hoffnung, Ansätze aus dem agilen Bereich. Ein Beispiel für einen solchen Ansatz ist „Specification by Example“. Die Testspezifikation (genauer: die Spezifikation der Akzeptanzkriterien) wird in einer teilformalisierten Sprache geschrieben, die sowohl für die Kunden verständlich ist, als auch automatisiert ausgewertet werden kann. Häufig enthält eine solche Spezifikation neben Testszenarien auch die notwendigen Testdaten. Hier ein Beispiel für eine solche Testspezifikation (Quelle Wikipedia, Artikel zu Behavior Driven Development) :

Story: Returns go to stock

In order to keep track of stock
As a store owner
I want to add items back to stock when they're returned

Scenario 1: Refunded items should be returned to stock
Given a customer previously bought a black sweater from me
And I currently have three black sweaters left in stock
When he returns the sweater for a refund
Then I should have four black sweaters in stock

Scenario 2: Replaced items should be returned to stock
Given that a customer buys a blue garment
And I have two blue garments in stock
And three black garments in stock.
When he returns the garment for a replacement in black,
Then I should have three blue garments in stock
And two black garments in stock

Solche Spezifikationen können nun mit den entsprechenden Tools mit Tests verknüpft werden, und dann kann automatisiert direkt gegen die Spezifikation getestet werden. Es gibt also nur noch eine Quelle für die „Wahrheit“, nicht mehrere Spezifikationen, die auf unterschiedlichen Ebenen beschreiben, wie eine akzeptable Lösung auszusehen hat.

In einem zweiten Teil des Artikel werde ich auf die Toolunterstützung für die „Specification by Example“ eingehen.

Series Navigation

Werkzeuge für „Specification by Example“ >>