Schreiben von Testfällen

Das Schreiben von Testfällen ist eine meist unterschätzte Herausforderung, die noch bedeutend größer wird, wenn die Testfälle geeignet sein sollen um automatisiert zu werden.

Diese Seite hat sich nicht zum Ziel gesetzt, die vielen Bücher und Fachartikel über das Schreiben von Testfällen zu ersetzen. Und schon gar nicht möchte diese Seite Stellung in den vielen vielen, zum Teil erbittert geführten Kämpfen um wichtige Fragen nach bspw. der Abgrenzung zwischen abstrakten und konkreten Testfällen oder nach angewandter Methodik vs. reiner Lehre, beziehen.

Was dieser Artikel möchte, ist auf die wesentliche Literatur zu verweisen und dazu ein paar einfache Wege aufzuzeigen, wie Testautomatisierung funktioniert. Beginnen wir also am Anfang. Auch wenn Sie den Eindruck haben, dass Sie über viel KnowHow verfügen: Lesen Sie mit uns den Grundlagenartikel über Testfälle.

Requirements / zugesicherte Eigenschaften

Gleich im ersten Satz des Grundlagenartikels steht etwas Elementares: Ein Testfall dient der Überprüfung einer zugesicherten Eigenschaft. Und dies ist einer der wertvollsten Tipps, die wir Ihnen geben können. Schreiben Sie Testfälle, die genau eine zugesicherte Eigenschaft Ihres System überprüfen. Da zugesicherte Eigenschaften in IT Projekten erstaunlich oft Mangelware sind, werden von manchen Testexperten lange Testfallketten, die z. B. die wichtigsten 100 Geschäftsprozesse durchlaufen, als Lösung angeboten. Die dahinter steckende Idee ist, dass Ihr System schon eine vertretbare Qualität haben muss, wenn die 100 wichtigsten Prozesse problemlos durchlaufen. Bei näherer Draufsicht hat dieses Vorgehen aber ein paar Schönheitsfehler: Wer kann denn festlegen, dass ein Totalversagen des 101ten Prozesses nicht ebenfalls katastrophale Folgen für das Unternehmen haben wird? Und wenn keine zugesicherten Eigenschaften bekannt sind, wie prüfe ich dann, ob meine 100 Prozesse wirklich das gewünschte Ergebnis hatten. Nur weil die Prozesse ohne Fehlermeldung durchgelaufen sind und ggf. ihre primären geschäftlichen Ziele erreicht wurden, heißt das nicht, dass alle Eigenschaften, die das System bei der Abarbeitung diese Prozesse hätte zeigen müssen, auch korrekt vorhanden waren. Ein plastisches Beispiel: Einer der 100 wichtigsten Prozesse einer Retail-Bank wird vermutlich der Transfer von Geld zwischen Konten in Form einer Überweisung sein. Also wird ein Testfall entwickelt, der eine Überweisung ausführt. Nach der Ausführung ist der Saldo des Auftraggeberkontos um den Überweisungsbetrag niedriger und der Saldo des Empfängerkontos um den Überweisungsbetrag höher, als vor dem Test. Das primäre geschäftliche Ziel wurde ohne Fehler erreicht. Aber: zu den zugesicherten Eigenschaften eines Retail-Banken Systems gehören sicher auch Dinge wie eine Autorisierung (nicht jeder darf Geld von jedem Konto überweisen), eine Prüfung der Limite (wird der Dispo richtig berücksichtigt?), eine lückenlose Dokumentation der Transaktion (kann die Zahlung nachverfolgt werden?). Sie sehen, wenn die zugesicherten Eigenschaften nicht Bestandteil der Überprüfung des Testergebnisses sind, sagt die Ausführung fast nichts über die Qualität des Testobjektes aus. Ein Test sollte nicht nur feststellen, dass da irgendetwas irgendwie läuft, sondern dass etwas Konkretes genau so läuft, wie gefordert. Sie müssen also die zugesicherten Eigenschaften betrachten.

Und wenn Sie keine zugesicherten Eigenschaften haben? Dann nehmen Sie die Quellen die Ihnen zur Verfügung stehen, das System und Ihre analytischen Fähigkeiten und formulieren Sie zugesicherte Eigenschaften in Form von Axiomen ("Bei einer ausgehenden Überweisung muss das System prüfen, ob der Überweisungsbetrag kleiner gleich der Summe aus Saldo + Dispo + Geduldeter Überziehung (10% des Dispos) ist. Ist der Überweisungsbetrag kleiner gleich, wird die Überweisung ausgeführt. Ist der Überweisungsbetrag größer, wird die Überweisung zur manuellen Freigabe in die Nachbearbeitung gegeben."). Dazu können Sie Testfälle schreiben. Und die Grundlage Ihrer Tests kann überprüft und ggf. korrigiert werden.

Formale Anforderungen an Testfälle

Es gibt nur wenige Bereiche, in denen so viel formalisiert wird, wie beim Schreiben von Testfällen. Viele Unternehmen versuchen die Qualität Ihrer Testfälle durch den Einsatz umfangreicher Formulare, die wie ein Testfallautorenkorsett wirken sollen, zu gewährleisten. Aber auch wenn Formulare sicher geeignet sind um eine Gleichförmigkeit zu gewährleisten: Die Formalien, die einen Testfall robust und aussagekräftig machen, sind durch ein Formular oft nicht erreichbar. Hier ein paar ganz einfache Tipps:

Klarheit und Verständlichkeit

Vor einiger Zeit stellten wir succest bei einem Großkonzern vor. Als wir erklärten, der Einsatz von succest würde die Qualität der Testfälle erhöhen, erklärte einer der bei der Präsentation anwesenden Manager, die Testfälle des Unternehmens wären auf einem extrem hohen Qualitätsstand. Man hätte umfangreiche Qualitätssicherungsmaßnahmen z. B. in Form von Excel-Formularen für die Erstellung der Testfälle ergriffen. Das Ergebnis wären Testfälle die man jedem Unternehmens- und Fachfremden ohne weitere Erklärung zum Testen an die Hand geben könnte. Unsere Kollegen, die diesen Großkonzern später in einem 'Proof of concept' begleiteten, waren weder unternehmens- noch fachfremd, konnten aber nur einen geringen Teil der vorhandenen Testfälle überhaupt verstehen und das ist unserer Erfahrung nach kein Einzelfall.

Sprache

Oft werden Testfälle nicht von den Personen ausgeführt, die die Testfälle geschrieben haben. Unterstellen Sie also nicht, dass alle Leser Ihres Testfalls auch über Ihr Fach- und Unternehmensvokabular verfügen. Egal ob Ihr Testfall später von einem Tester manuell ausgeführt wird, oder ob jemand mit Ihnen zusammen den Testfall automatisiert: Ihr Testfall muss verstanden werden. Sie müssen nicht jeden Fachbegriff umschreiben, 'die Anderen' werden Ihnen ein Stück entgegen kommen müssen. Aber setzen Sie Fachbegriffe nur dann ein, wenn Sie etwas deutlicher machen. Präzision ist auch ein Thema. Steht in Ihrem Testfall "Die Ergebnisliste muss einen Eintrag enthalten" ist unklar, ob Sie "mindestens einen" oder "genau einen" gemeint haben. Präzision wird oft unterschätzt, weil scheinbar viele Testfallautoren die "das ist doch klar"-Brille aufhaben. Und zum Schluss: Wenn Ihr Unternehmen in Indien testen lassen will, dann schreiben Sie ggf. auf Englisch. Vermeiden Sie, dass Ihr Testfall von einem unternehmens- und fachfremden Übersetzer für einen unternehmens- und fachfremden Tester aufbereitet wird. Es kommt nicht auf perfektes Englisch an, sondern auf Verständlichkeit und den richtigen Inhalt.

Fokus, Fokus, Fokus

Ihr Testfall bezweckt den Nachweis einer zugesicherten Eigenschaft. Schreiben Sie in Ihren Testfall all dass, was diesem Zweck dient. Nicht mehr! Wenn Sie eine Software schrieben, dann dürfen Sie ggf. ein Feature 'hübsch' ausgestalten, weil es den späteren Anwender vielleicht erfreut. Wenn Sie ein Wiki schreiben, dürfen Sie ggf. ein bisschen schwafeln, weil das den Leser vielleicht ein bisschen unterhält. Wenn Sie versuchen etwas zu beweisen, dann erinnern Sie sich kurz an Ihren Mathematikunterricht. Ein Beweis ist optimaler Weise ein kurzes, elegantes und vor Allem unerschütterliches Konstrukt, das genau einem Zweck dient.

Vollständigkeit

Nach all den Jahren, in denen unsere Berater nun schon in Testprojekten bei namhaften Großkonzernen unterwegs sind, finden wir immer wieder Beispiele für unvollständige Testfallbeschreibungen, die uns überraschen. Und meist hat es nicht am letzte Quäntchen fiegelinscher Methodik gefehlt. Meist fehlte es an GMV. Die folgenden Tipps sind gut und wichtig. Aber GMV ist das A und O beim Schreiben guter Testfälle.

Einleitung

Wenn Sie einen Testfall schreiben, gönnen Sie sich und anderen Konsumenten Ihrer Arbeitsergebnisse eine kleine Einleitung. Welche zugesicherte Eigenschaft soll der Testfall nachweisen? Und wie weißt der Testfall die zugesicherte Eigenschaft nach? Es gibt viele Wege nach Rom. Ein paar erklärende Worte werden auch Ihnen helfen, sich auf das Wesentliche zu fokussieren.

Inhalt

Es gehört alles in die Testfallbeschreibung, was zur Durchführung benötigt wird. Wenn es Vorbedingungen zur Ausführung gibt, dann müssen sie im Testfall beschrieben sein. Jeder Schritt muss beschrieben sein. Wenn der Ausführende sich am System Under Test (SUT) anmelden muss, bevor er weitere Schritte unternehmen kann, dann gehört das Anmelden als erster Ausführungsschritt in den Testfall. Das ist doch eh klar. ist keine Sichtweise beim Schreiben von Testfällen. Erst wenn Sie alle Schritte so detailliert beschrieben haben, dass ein Unternehmensfremder den Testfall für Sie ausführen könnte, besteht die Chance auf Automatisierung.

Entkopplung und Abgeschlossenheit

'Entkoppelt' bedeutet, dass der Testfall keine Abhängigkeiten zu anderen Aktivitäten hat. 'Abgeschlossen' bedeutet, dass der Testfall mit der damit endet, dass das Vorhandensein oder das Fehlen einer Eigenschaft nachgewiesen wurde. In der Theorie scheint es einfach, Testfälle so zu gestalten, dass sie entkoppelt und abgeschlossen sind.

Tipps zur Entkopplung

In der Praxis finden sich sehr oft Testfälle, die z. B. damit beginnen, dass eine bestimmte Datenkonstellation aus einem vorhandenen Datenbestand heraus zu suchen ist. In diesem Falle ist der Testfall nicht entkoppelt, da er nur dann ausgeführt werden kann, wenn vorher ein Testdatenbestand mit einer passenden Datenkonstellation angelegt sein muss. Besser wäre es, der Testfall würde mit den Schritten zur Anlage der passenden Datenkonstellation beginnen. Zwar wäre der Testfall ggf. viel länger würde erheblich mehr Aufwand in der Ausführung erfordern. Aber er könnte tatsächlich jederzeit, unabhängig von der Datenlage im System durchgeführt werden.

Es kommt auch regelmäßig vor, dass ein Tester beispielsweise einen Testfall B schreibt, der damit beginnt, dass ein Geschäftsobjekt, das in einem anderen Testfall A bereits verwendet wurde, nun 'weiter' benutzt werden soll. In dieser Situation kann der gefundene Testfall B nur dann ausgeführt werden, wenn zuvor der Testfall A erfolgreich ausgeführt wurde. Solche Kopplungen zwischen Testfällen bergen das Risiko, einen falschen Eindruck von der Qualität des SUT zu vermitteln. Wenn nämlich der Testfall A das Vorhandensein oder das Fehlen der zugesicherten Eigenschaft A' beweist und der Testfall B das gleiche für die zugesicherte Eigenschaft B' beweist, dann führt das Fehlschlagen des Testfalls A dazu, dass das Fehlen der Eigenschaften A' und B' bewiesen zu sein scheint. Würde man die für den Testfall B notwendigen Schritte aus dem Testfall A in B hinein-duplizieren, wären zwar Schritte doppelt und der Gesamtaufwand für die Ausführung des Testfalls würde sich erhöhen. Die Aussagekraft der Testfälle würde sich aber ebenfalls erheblich erhöhen.

Gerade für die zusätzlichen Aufwände einer konsequenten Entkopplung wird der Tester belohnt, weil entkoppelte Testfälle in der Regel viel leichter automatisiert werden können. Der scheinbare Nachteil der Entkopplung in Form der größeren Ausführungsaufwände verkehren sich also in der Regel ins Gegenteil.

Eindeutigkeit

Ein Testfall der genau eine zugesicherte Eigenschaft überprüft hat genau zwei relevante Ausführungsstatus (a. Die zugesicherte Eigenschaft wurde nachgewiesen, b. Die zugesicherte Eigenschaft muss nachgewiesen werden) und drei mögliche Ausführungsergebnisse (a. Die Ausführung weist das Vorhandensein der zugesicherten Eigenschaft zum Zeitpunkt der Ausführung nach, b. Die Ausführung weist das Fehlen der zugesicherten Eigenschaft zum Zeitpunkt der Ausführung nach, c. Die Ergebnis der Ausführung ist nicht konkludent).

Die Grundidee des Ausführungsstatus ist einfach. Entweder ist die zugesicherte Eigenschaft nachgewiesen. Andernfalls muss sie nachgewiesen werden, denn es handelt sich ja um eine zugesicherte Eigenschaft. Dabei ist der Ausführungsstatus eines Testfalls initial Die zugesicherte Eigenschaft muss nachgewiesen werden. Wurde der Testfall mit dem Ergebnis Die Ausführung weist das Vorhandensein der zugesicherten Eigenschaft zum Zeitpunkt der Ausführung nach ausgeführt, ändert sich der Ausführungsstatus des Testfalls zu ''Die zugesicherte Eigenschaft wurde nachgewiesen. Der Ausführungsstatus wechselt zurück in Die zugesicherte Eigenschaft muss nachgewiesen werden, wenn ein Ereignis den Nachweis ungültig werden lässt. Ein solches Ereignis könnte eine Veränderung der Software sein (ein neues Release z. B.) oder auch die Erkenntnis, dass der Nachweis ungenügend war (bespielweise zeigt sich in der Anwendung, dass die zugesicherte Eigenschaft unter bestimmten Bedingungen, die im Testfall nicht berücksichtigt waren, nicht vorhanden ist). Unser Tipp ist: Implementieren Sie nicht nur eine "grün/rot" Ampel. Viele Projekte führen Testfälle als 'passed' oder 'failed', berücksichtigen aber nicht, ob der Status 'passed' zum Zeitpunkt der Draufsicht noch valide ist. So kommt es täglich tausendfach vor, dass Computer-Systeme fehlerhaft arbeiten, obwohl Testfälle für die betreffenden Systeme vorhanden und ausgeführt waren und die Fehler hätten finden können.

Das Ausführungsergebnis ist fast noch einfacher. Ein Testfall wird ausgeführt und das Ergebnis wird am Ende der Ausführung bewertet. Es gibt zwei möglich Prüfergebnisse: Entweder haben alle Messungen die erwarteten Werte gezeigt. In diesem Falle wurde das Vorhandensein der zugesicherten Eigenschaft zum Zeitpunkt der Testfallausführung nachgewiesen. Oder die Messungen weichen von den erwartete Werten ab. In dem Falle ist nachgewiesen, dass die zugesicherte Eigenschaft zum Zeitpunkt der Testfallausführung nicht vorhanden war. Eine Sonderfall tritt ein, wenn der Testfall nicht bis zur Prüfung der Ergebnisse kommt, weil z. B. einer der Testschritte, aus Gründen, die mit der zu prüfenden zugesicherten Eigenschaft nichts zu tun haben, nicht durchgeführt werden kann. In diesem Falle ist das Ergebnis der Ausführung nicht konkludent. Die Unterscheidung zwischen dem nachweislichen Fehlen der zugesicherten Eigenschaft und dem nicht konkludenten Ausführungsergebnis hat lediglich operative Auswirkungen. Im ersten Falle muss die Software um die zugesicherte Eigenschaft ergänzt werden. Im zweiten Falle ist das Hindernis zu beseitigen, dass die Testfallausführung behindert hat. Die Wirkung des Ausführungsergebnisses auf den Ausführungsstatus ist in beiden Fälle gleich. Der Ausführungsstatus steht auf Die zugesicherte Eigenschaft muss nachgewiesen werden. Lediglich das Ausführungsergebnis Die Ausführung weist das Vorhandensein der zugesicherten Eigenschaft zum Zeitpunkt der Ausführung nach bewirkt einen Ausführungsstatus von Die zugesicherte Eigenschaft wurde nachgewiesen.

Wenn Sie Ihren Testfall so formulieren, dass er bei einem vollständigen Durchlauf nur die Ergebnisse Die Ausführung weist das Vorhandensein der zugesicherten Eigenschaft zum Zeitpunkt der Ausführung nach und Die Ausführung weist das Fehlen der zugesicherten Eigenschaft zum Zeitpunkt der Ausführung nach produzieren kann, werden Sie feststellen, dass Ihr Testfall eindeutig ist: Eindeutig in Bezug auf das was und das wie, und vor Allem eindeutig in Bezug auf die Interpretation des Ergebnisses.