| Home | Projekt Sendgroups | Anforderungsphase | Testvorbereitung | |
Das Projekt Sendgroups
Die Testvorbereitung im Projekt Sendgroups erforderte zwei Schritte:
Die Erstellung von Testfällen erfolgt in üblicher Weise, indem zu jedem Aktivitätsblock in der Tango-Spezifikation ein Testfall definiert wird. Aus dem Pfad zum Aktivitätsblock ergeben sich die Randbedingungen dieses Testfalls. Das Verfahren ist vollkommen schematisch. Als Ergebnis entsteht die Niederschrift der (ungefalteten) Testfälle.
Die Referenz der Testfälle zurück in die Spezifikation erfolgt über eine beliebige Zeile des Aktivitätsblocks. Um diese Referenz unabhängig von möglichen späteren Änderungen der Spezifikation zu halten wurden die Referenzzeilen mit einem Kommentar wie // Tc36 versehen. Dabei wird die Zeilennummer in irgendeiner Version der Spezifikation verwendet, die in späteren Versionen möglicherweise nicht mehr der tatsächlichen Zeilennummer entspricht.
In einigen Zeilen von Aktivitätsblöcken der Spezifikation sind Varianten eines Szenarios zusammengefasst, die zwar grundsätzlich gleich zu behandeln sind, jedoch kann ein misstrauischer Tester alle diese Varianten testen. Daraus ergeben sich Referenzen auf mehrere Testfälle von einem einzigen Aktivitätsblock der Spezifikation aus. Diese Referenzen sind durch einen nachfolgenden Buchstaben unterschieden: // Tc38a, Tc38b, Tc38c.
Die Niederschrift der Testfälle erfolgte in tangoähnlicher Form. Dies bietet sich an, da die Testfälle direkt aus der Tango-Spezifikation abgeleitet sind. Ebenso wie die Tango-Spezifikation sind die Testfälle abstrakt beschrieben, auch wenn die durchzuführenden Schritte am Ende der Niederschrift als Tango-Aktionen (@examiner1.createSendableAction usw., bitte nicht verwechseln mit dem Fachbegriff Actions) etwas detailliert wurden. Wegen der abstrakten Beschreibungsebene dieser Testfälle und der Notwendigkeit der Weiterverarbeitung zu Testsequenzen ist dieses Pseudo-Tango hier die bevorzugte Beschreibungsart.Die Testfälle generieren Einträge in einer Datenbank, in der diese Einträge nur mit einem taggenauen Zeitstempel versehen sind. Der Austausch der Information in dieser Datenbank kann nur beobachtet werden, wenn Eintrag und Austausch an unterschiedlichen Tagen stattfinden. Deshalb erstrecken sich viele Testfälle über zwei Tage.
Einige Testfälle sind nicht ausführbar, weil dazu mehrere Sendgroup 2 Actions notwendig wären, aber bis jetzt ist nur eine einzige Action der Sendgroup 2 zugeordnet. Dies könnte sich in den nächsten Jahren ändern, deshalb wurden diese Testfälle trotzdem geschrieben, aber in späteren Schritten der Testvorbereitung als nicht anwendbar markiert.
Die Schritte in den Testfällen der Niederschrift wurden nach Vorbereitung (preparation) und den eigentlichen Testschritten (test) unterschieden. Beim späteren Falten der Testfälle kann der Vorbereitungsteil entfallen, aber niemals die echten Testschritte.
Jeder Testfall ist für sich ausführbar, unabhängig von allen anderen, deshalb beginnen alle mit einer Situation §{empty dossier}, wo noch keine Action erzeugt oder gesendet wurde. Der Zustand $actions beschreibt, welche Actions gerade im Postausgangskorb vorhandenen sind. Dies muss durch einen Blick in die entsprechenden Datenbanken (es gibt mehrere) verifiziert werden. Der Aspekt action115.NEW ist ein Hinweis, dass auf inhaltliche Änderungen einer Action in den Datenbanken geprüft werden muss, und nicht nur auf das Vorhandensein der Action.
Die Tango-Aktionen am Ende der Niederschrift (@examiner1.createSendableAction usw.) berücksichtigen keine Fehlerfälle von Check oder Send, da in diesem Fall der Test sofort beendet wäre. Einwandfreie Funktion des Gesamtsystems wird vorausgesetzt, d.h. wenn Check, Send oder andere Operationen nicht funktionieren, dann ist das System aus Sicht der Sendgroups nicht testbar.
Um den manuellen Aufwand bei der Testdurchführung zu reduzieren mussten die Testfälle so kombiniert werden, dass der vorangehende Testfall die Vorbedingung für den nachfolgenden Testfall erzeugt. Dies erfordert eine Charakterisierung der Zustände vor und nach einem Testfall. Das wesentliche Kriterium ist die Art und Anzahl von Actions im Postausgangskorb. Dies genügt zur Differenzierung, denn die Sendgroup-Tests prüfen nur das Verhalten der Datenbanken, und damit das Geschehen rund um den Postausgangskorb.
Die Zustände werden als sechsstellige Zahl notiert, dabei beziehen sich die ersten drei Zahlen auf Actions von Examiner 1, die letzten drei auf Actions von Examiner 2. Damit bedeutet
| 001000 | Im Postausgangskorb liegt eine Sendgroup 3 Action von Examiner 1, sonst nichts | ||
| 000111 | Im Postausgangskorb liegt je eine Action aus Sendgroup 1, Sendgroup 2 und Sendgroup 3 von Examiner 2 |
Mit dieser Charakterisierung der Zustände lassen sich die Testfälle kombinieren, wobei aus praktischen Gründen die Gesamtdauer einer Testsequenz zwei Tage nicht überschreiten darf. Die kritischen Testschritte sollten am ersten Tag durchgeführt werden, so dass im Falle eines Fehlers bei der Testdurchführung der Testlauf sofort neu aufgesetzt werden kann; andernfalls würde ein zusätzlicher Tag eingeplant werden müssen. Verbleibende Tests am Tag 2 sollten möglichst kurz und idiotensicher sein, pro Testsequenz wurde maximal ein Test auf den nächsten Tag gelegt.
Unter diesen Randbedingungen wurden in einer Tabelle die Testsequenzen miteinander kombiniert. Jede Sequenz beginnt mit dem Zustand 000000, d.h. der Postausgangskorb ist leer. Danach folgt ein Testfall oder eine Vorbereitung (prep), die einen neuen Zustand generiert. Die Spalte in orange zeigt den Zustand, der am Ende von Testtag eins und am Anfang von Testtag zwei erreicht ist. Die gelben Einzelmarkierungen wurden beim Auswerten der Tabelle als Merker hinzugefügt, sie sind insoweit ohne Bedeutung.
Gemäß den Sequenzen in der Tabelle wurden die Testfälle neu arrangiert zu einer Liste aus gefalteten Testfällen. Die Vorbereitung (preparation) der Testfälle wurde nicht entfernt, auch wenn sie in der Testsequenz nicht mehr verwendet wird, sie dient an dieser Stelle der Verifikation der Zwischenzustände. Die in Klammern gesetzten Testfälle ersetzen die Vorbereitung., z.B. (Tc87) vor Tc93. Im Falle, dass ein Testfall mehrfach verwendet wird, wie z.B. Tc87, ist der Testblock dieses Tests nur in einem einzigen dieser Fälle relevant, in den Wiederholungsfällen werden die Ergebnisse nicht mehr geprüft.
Testfälle, die direkt aufeinander folgen, sind ohne Klammern hintereinander geschrieben, z.B. Tc73, Tc75a, Tc75b.
Wenn ein Testfall nicht vollständig die Voraussetzung für den nächsten herstellt, dann ist eine Vorbereitung als Zwischenschritt notwendig, wie z.B. in der Sequenz prep, Tc22b, prep, Tc38b.
Die Testfälle in Klartext wurden aus der Liste der gefalteten Testfälle erzeugt und dabei direkt in Microsoft Excel niedergeschrieben, und anschließend im Hewlett-Packard Quality Center importiert. Es wäre nicht nützlich gewesen, die vollständig ausgearbeiteten Testfälle vorab in irgendeiner anderen Notation niederzuschreiben. Die Beschreibung der Testdurchführung wurde nur soweit detailliert, dass ein Examiner die Anweisungen versteht und die konkreten Schritte nachvollziehen kann. Deshalb finden sich in der Klartext-Beschreibung Formulierungen wie "geben Sie alle notwendigen Informationen ein, damit der Check der Action keine Fehler aufdeckt".
Die hier erstellten Testfälle sind als Testblock zu verstehen, d.h. um eine Aussage über die Qualität des Systems zu treffen müssen alle Testfälle ausgeführt werden. Die Aufteilung von Testfällen in einzelne Testsequenzen erfolgte unter rein testtechnischen Gesichtspunkten, es gibt keine "wichigen" oder "weniger wichtigen" Testsequenzen.
Die Abstraktion der Spezifikation liefert eine stabile, von Implementierungsproblemen unabhängige Grundlage. Hier wird nur niedergeschrieben was passiert, und nicht wie es passiert. Wenn diese Abstraktion auch bei der Testerstellung beibehalten werden kann, sind auch nachfolgende Dokumente wie die Liste von Testfällen weniger änderungsanfällig.
Der Aufwand zum Falten der Testfälle ist deutlich größer als die Erstellung der ungefalteten Testfälle selbst. Für die Automatisierung wären die ungefalteten Testfälle ideal, insofern wäre eine Abwägung lohnenswert, ob der Aufwand nicht besser in die Automatisierung gesteckt wird.
| Home | Projekt Sendgroups | Anforderungsphase | Testvorbereitung | |