Freitag, 8. August 2014

Startschuss zur testgetriebenen Entwicklung.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im letzten Post habe ich die Bedeutung von Abnahmekriterien besonders betont. Sie bilden eine wichtige Schnittstelle in der Zusammenarbeit zwischen Kunden und Entwicklung. Die Annahmen, der Kunde will das ganz sicher so haben oder eigentlich wissen wir es besser als der Kunde, führen mit großer Sicherheit in die Irre. Deshalb kann ich nur noch einmal wiederholen: überzeugen Sie Ihren Kunden Abnahmekriterien zu schreiben, in seinem eigenen Interesse. In diesem Post möchte ich auf die Art und Weise eingehen, wie wir Abnahmekriterien dokumentieren.

Da unser System von der User Story über Szenarien zu Use Cases gelangt und dann in Bezug auf die Use Cases Anforderungen ermittelt werden, gibt es mehrere Objekte, an die Abnahmekriterien geheftet werden können. In Bezug auf die User Story heißt unser Abnahmekriterium allerdings Akzeptanzkriterium. Das Akzeptanzkriterium ist das Objekt, welches mindestens vom Kunden erstellt werden sollte. In Bezug auf Use Cases und Anforderungen verknüpfen wir Abnahmekriterien, wenn sie vom Kunden erstellt, und Entwicklerabnahmekriterium, wenn sie aus Not von der Entwicklung erstellt wurden. Im letzten Post finden Sie dazu eine Übersichtsdarstellung.



Bei der Dokumentation wollen wir Akzeptanzkriterien und Abnahmekriterien gleich behandelt. Im Grunde sind sie für uns zwei Ausdrücke für ein und dieselbe Sache. Deshalb spreche ich im nachfolgenden Text nur noch vom Abnahmekriterium. Abnahmekriterien erfassen wir in den meisten Fällen in einer Tabelle. Diese Tabelle enthält drei Spalten: Ausgangssituation, Ereignis und erwartetes Ergebnis.

Ausgangssituation Ereignis Erwartetes Ergebnis


Jedes Abnahmekriterien wird als kleiner Test beschrieben. [RUPP07] definiert die drei Spaltenwerte des Tests wie folgt: Die Ausgangssituation "beschreibt den Zustand des Prüflings und der Testumgebung vor der Testdurchführung. Dies kann zum Beispiel die Wertebelegung von Systemparametern sein, das Vorhandensein von Nachbarsystemen, Testgeneratoren, aber auch die erfolgreiche Durchführung von zeitlich >>vorgelagerten<< Abnahmekriterien." [S.328, RUPP07] Im Ereignis wird der Prüfling veranlasst, "sich gemäß der Anforderung zu verhalten (Englisch: event oder auch trigger). Dies kann eine Nutzeraktion, das Eintreffen einer Meldung an eine Systemschnittstelle oder auch ein zeitlich orientiertes Ereignis sein, welches das System veranlasst, eine Aktion auszuführen." [S.329, RUPP07] "Mit dem erwarteten Ergebnis legen Sie fest, welchen SOLL-Zustand der Prüfling bei korrekten Verhalten einzunehmen hat." [S.329, RUPP07]

Eine weitere Form der Dokumentation von Abnahmekriterien möchte ich an dieser Stelle noch erwähnen. Bei komplexen Bedingungen haben wir oft Entscheidungstabellen benutzt. Manchmal sind eine Reihe von Bedingungen miteinander verknüpft. Die Entscheidungstabelle bietet eine hervorragende Möglichkeit die Übersicht über die sich entwickelnde Komplexität zu behalten. Dazu legen Sie zuerst zwei Listen an. Die erste Liste enthält alle Bedingungen (Ausgebildet, Erfahren, Müde). Aus dieser Liste ergibt sich der Kopf der Entscheidungstabelle.

Ausgebildet J N
Erfahren J N J N
Müde J N J N J N J N


Es ergibt sich also ein umfangreiches Bedingungsgeflecht. Eine Person, die diese drei Bedingungen annehmen kann soll nun verschiedenen Aufgaben durchführen (Aufgabe 1 bis Aufgabe 5). Diese Aufgaben werden unterhalb der Bedingungen aufgetragen. Es ergeben sich eine Vielzahl von Möglichkeiten.

Ausgebildet J N
Erfahren J N J N
Müde J N J N J N J N
Aufgabe 1 x x x x x x x x
Aufgabe 2 x x x x x x - x
Aufgabe 3 x x x x - x - -
Aufgabe 4 x x - x - - - -
Aufgabe 5 - x - - - - - -


Jedes x in dieser Tabelle bedeutet, die entsprechende Person kann diese Aufgabe bewältigen und jeder – bedeutet, sie kann es nicht. Man sieht, dass nicht nur die Ausbildung und die Erfahrung Einfluss auf die Arbeitsleistung hat, sondern auch der physische Zustand der Arbeitnehmer. Für größere Entscheidungstabellen bietet es sich an, diese zu konsolidieren. [RUPP07] beschreibt in ihrem Buch sehr schön wie das geht. Auch führt sie dort ein weiteres durchgehendes Beispiel an, an dem man sich sehr gut orientieren kann.

Im Grunde beschreibt der Kunde eine Vielzahl kleiner und größerer Test, unter denen er bereit wäre, das System bzw. einzelne Funktionalität oder qualitatives Verhalten zu akzeptieren. Diese Tests bieten damit auch das Sprungbrett für umfangreiche Systemtests, auf die Sie natürlich nicht verzichten wollen. Solche Tests sind ausschließlich Black-Box-Tests. Bei diesen Test kennen wir die Eingaben und die Ausgaben, wissen aber nicht, was im Inneren passiert.

Im Folgenden möchte einige Methoden aufführen, die Sie beachten müssen, um eine möglichst gute Abdeckung mit Abnahmekriterien zum Testen zu erreichen. [RUPP07] führt drei Methoden an: die Funktionsabdeckung, die Äquivalenzklassenbildung und die Grenzwertanalyse. Das sind die wichtigsten Black-Box-Testverfahren.

"Abnahmekriterien gemäß der Methode der Funktionsabdeckung werden geschrieben, um nachzuweisen, dass die jeweilige Funktion oder Eigenschaft laut Anforderung vorhanden und auch durchführbar ist." [S.334, RUPP07] Zuerst gehen wir alle User Stories durch und formulieren Akzeptanzkriterien, die beschreiben, wie das jeweilige Normalverhalten geprüft werden kann. Danach wird das auf die Use Cases zur langfristigen Dokumentation übertragen und wenn erforderlich auf Anforderungen erweitert. Dieses Normalverhalten berücksichtigt jedoch keine Ausnahmen und Fehler. Dafür sind die Äquivalenzklassenbildung und die Grenzwertanalyse da.

In der Äquivalenzklassenbildung werden Wertebereiche mit identischen Verhalten gebildet. Diese nennen wir dann Äquivalenzklassen. Für jede Äquivalenzklasse schreiben wir dann mindestens ein Abnahmekriterium. Für eine Funktionalität kann es so zum Beispiel zwei Äquivalenzklassen geben. In jeder Äquivalenzklasse haben wir ein anderes Verhalten, also ein unterschiedliches erwartetes Resultat. Zu den Äquivalenzklassen gehören auch Wertebereiche, in denen wir Fehler als Ergebnis erwarten.

"Eine oft verwendete Vorgehensweise ist der Test der Grenzen einer Äquivalenzklasse, da Fehler besonders häufig an den unmittelbaren Grenzen von Wertebereichen auftreten." [S.336, RUPP07] Für die Tests beschreiben wir als Abnahmekriterien, deren Werte genau auf der Grenze der Äquivalenzklasse liegen.

Wir haben mit den Abnahmekriterien sichergestellt, dass unsere Anforderungen getestet werden können. Können wir zu einem Anforderungsartefakt keine Abnahmekriterium formulieren, müssen wir stark in Frage stellen, ob dieses Artefakt testbar ist. Da eine Anforderung jedoch testbar sein muss, müssen wir die Formulierung der Anforderung überdenken. Abnahmekriterien sind somit auch Tests für die zu testenden Anforderungsartefakte und sie sind gleichzeitig der Startpunkt für weitere umfangreiche Tests.

  • [RUPP07] Chris Rupp & SOPHISTen: "Requirements Engineering und – Management", 4. aktualisierte und erweiterte Auflage, Carl Hanser Verlag, München, Wien, 2007


vorheriger Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen