Wenn Sie Software oder Systeme entwickeln, dann kennen Sie diese Situation: Ein Anwender stößt auf einen Fehler. Ärgerlich. Denn eigentlich sollte der Fehler in dem Softwarestand, den der Anwender einsetzt, längst beseitigt sein. Außerdem – so meint der Anwender – sei die Funktion nicht nur fehlerhaft, sondern auch unvollständig umgesetzt und entspreche nicht der Anforderung aus dem Lastenheft.
Hat der Anwender recht? Klar, die Fehlerbehebung hat in dieser Situation Vorrang. Aber wenn man aus Fehlern lernen will, ist Ursachenforschung angesagt. Warum wurde der Fehler beim Testen nicht entdeckt? Gibt es in dem Kontext überhaupt einen Testfall? Und wenn ja, wie sah die Anforderung aus, die damals realisiert und mit dem Testfall überprüft werden sollte?
Gehen wir also gemeinsam auf Spurensuche in der Vergangenheit.
Der Testfall für die Funktion, die beim Anwender nicht funktioniert, wird immer noch verwendet. Aber sah der Testfall damals genauso aus wie heute oder wurde er inzwischen geändert? Damit diese Frage beantwortet werden kann, müssen die erstellten Testfälle im Verlauf der Entwicklung versioniert werden, sodass ihre Historie zurückverfolgt werden kann.
Das allein reicht aber noch nicht aus, um die Aussagen des Anwenders zu überprüfen. Es muss auch die Anforderung ermittelt werden, zu der der Testfall erstellt wurde – und zwar in ihrem damaligen Zustand.
Allgemeingültiger formuliert stehen wir hier vor zwei Herausforderungen:
- Zum einen muss die Revisionssicherheit, d.h. die Zurückverfolgbarkeit der Historie von Artefakten – hier von Anforderungen und Testfällen – sichergestellt werden.
- Zum anderen muss aber auch die Traceability im Sinne des Nachvollziehens von Beziehungen zwischen Artefakten des Entwicklungsprozesses gewährleistet sein. Allerdings geht es hier nicht um Traceability im Rahmen der gegenwärtigen Entwicklung, sondern um das Nachvollziehen von Artefaktbeziehungen in der Vergangenheit.
Noch etwas kann die Spurensuche erschweren: Vielleicht haben Sie im Laufe der Entwicklung gemerkt, dass das Schema, nach dem Sie die Testfälle oder Anforderungen beschreiben, zu kompliziert ist oder – im Gegenteil – wichtige Eigenschaften fehlen. Sie haben also das Beschreibungsschema bzw. die Attributierung der Artefakte geändert. Wenn Sie formularbasiert arbeiten, bedeutet das, dass eine ältere Version beispielsweise eines Testfalls im aktuellen Formular nicht korrekt angezeigt wird. Es reicht also nicht aus, nur Informationen eines Artefakts zu versionieren. Es muss auch die Historie des zugehörigen Beschreibungsschemas oder Formulars mitgeführt werden.
Wir haben uns mit diesen Herausforderungen auseinandergesetzt und eine Lösung entwickelt, die Ihnen sowohl objectiF RM als auch objectiF RPM in gleichem Umfang anbieten. Diese Lösung möchte ich Ihnen am Beispiel Testfall/Anforderung jetzt kurz skizzieren:
Nehmen wir an, der Anwender bemängelt Fehler des Systems beim Erkennen von QR-Codes. Nachfolgend sehen Sie den aktuellen Testfall zu diesem Thema. Bei ihm, also in der Gegenwart, wollen wir die Spur aufnehmen. In seinem Formular ist auf der Registerkarte Geprüfte Elemente die zu testende Anforderung referenziert.
Die Referenz bedeutet: Zwischen dem Testfall und der aufgelisteten Anforderung besteht eine «verify»-Beziehung. Sie besitzt auch eine grafische Repräsentation in einem Anforderungsdiagramm:
Eine Anforderung mit ihren Testfällen – hier dargestellt in einem Anforderungsdiagramm
Alle Artefakte können versioniert werden – und zwar automatisch, beispielsweise bei einem Zustandswechsel oder explizit, wann immer es notwendig erscheint. Legt man von einem Testfall eine Revision an, dann wird nicht nur der Testfall selbst versioniert, sondern auch die «verify»-Beziehung und der zum Revisionszeitpunkt aktuelle Stand der Anforderung, die mit dem Testfall verbunden ist.
Sehen wir einmal in die Historie unseres Testfalls hinein. Sie besteht aktuell aus fünf Revisionen.
Der Weg zurück in die Historie eines Testfalls und zu dem damals aktuellen Stand der zugeordneten Anforderung
Gehen wir in der Historie zurück bis zu den beiden ältesten Revisionen. Sie wurden automatisch erzeugt: die erste beim Anlegen des Testfalls, die zweite beim Übergang in den Zustand definiert, ausgelöst durch das Ereignis Definition fertig. Wie sah der gerade fertiggestellte Testfall aus? In der Mitte der obigen Abbildung sehen Sie die damals erzeugte Revision. Sie wird mithilfe des Formulars angezeigt, das zum Revisionszeitpunkt für Testfälle aktuell war. (Wie das funktioniert und wie Sie generell die Attributierung von Artefakttypen ändern und eigene Formulare für Artefakte erstellen, ist ein Thema für sich. Das möchte ich hier nicht im Detail ausführen.) Zwei Dinge fallen auf: Zum einen zeigt das Namensfeld, dass der Testfall zum Revisionszeitpunkt schwächer formuliert war als heute. Das damals getestete Systemverhalten erweist sich aber im praktischen Einsatz beim Anwender als nicht gut genug und wird als Fehler wahrgenommen. Zum anderen sehen Sie auf der Registerkarte Geprüfte Elemente, dass der Testfall zu diesem Revisionszeitpunkt bereits über eine «verify»-Beziehung einer Anforderung zugeordnet war. Um herauszufinden, wie diese Anforderung damals definiert war, genügt ein Klick.
Beim Vergleich der aktuellen Anforderung im Anforderungsdiagramm mit dem Revisionsstand in obiger Abbildung fällt sofort auf, dass der Name inzwischen geändert und präzisiert wurde. Hier könnte die Ursache für die vom Anwender erkannten funktionalen Schwächen liegen. Möglicherweise hat sich der Entwickler damals nur am Namen orientiert und nicht in die Beschreibung der Anforderung geschaut. Übrigens: Sie sind natürlich nicht auf den Augenschein angewiesen. Ein maschineller Revisionsvergleich steht ebenfalls zur Verfügung.
Das Beispiel zeigt: Die Kombination aus dem Führen der Historie und der Traceability zwischen Revisionen verschiedener Artefakte kann zum Beispiel bei Maintenance-Aufgaben äußerst hilfreich sein. Auch bei einem Audit ist diese Funktionalität von Nutzen. Voraussetzung dafür ist, dass von den Artefakten an definierten Punkten Revisionen existieren. Damit Sie nicht für jedes einzelne Artefakt immer wieder Revisionen erzeugen müssen – das macht bei mehreren hundert Testfällen sicher keinen Spaß – bieten objectiF RM und RPM das Konstrukt der Elementgruppe an. Elementgruppen dienen dazu, von einer Menge beliebiger Artefakte mit ihren Beziehungen zum gleichen Zeitpunkt Revisionen anzulegen. Artefakte oder ganze Ordner mit Artefakten werden einer Elementgruppe einfach per Drag & Drop zugeordnet. Elementgruppen können darüber hinaus in sich strukturiert sein und wiederum Elementgruppen enthalten. Primär werden Elementgruppen dazu verwendet, Baselines zu ziehen. Sie können sie aber jederzeit auch nutzen, um damit einfach und schnell die Voraussetzung für die Spurensuche zu schaffen, wie ich sie hier beschrieben habe.
Mein Vorschlag: Erkunden Sie diese Möglichkeiten doch einmal selbst in objectiF RM oder objectiF RPM.