Abnahmetests, der agile Weg

Bei der Softwareentwicklung gibt es eine Sache, die sich jeder Entwickler immer merken sollte: Testen, testen und nochmals testen. Jedes echte agile Projekt dreht sich um das Testen. Testen Sie Ihren Code, Ihre Bildschirme, Ihre Datenbanken und testen Sie, ob Ihre User Stories tatsächlich funktionieren. Nichts wird dem Zufall überlassen, und das Testen erfolgt vor allem anderen und nachdem Sie fertig sind, und Ihr Code wird Regressionstests unterzogen, wenn Sie schon lange weg sind. Ziemlich offensichtlich, werden Sie vielleicht sagen, aber einige Teile des Testens sind offensichtlicher als andere. Unit-Tests sind so gut wie abgedeckt, es gibt Dutzende von Tools und Frameworks dafür, dasselbe gilt für Bildschirmtests. Aber eine Sache, die sich immer noch wie Neuland anfühlt, sind funktionale Tests (oder Akzeptanztests). In agilen Projekten gibt es zwei Einschränkungen, die für die 'traditionelle' Art und Weise, wie Akzeptanztests durchgeführt werden, gelten: Test first und agile (flexible) Testfälle. Wenn Sie mit dedizierten Testern arbeiten, müssen die Entwickler mit ihnen als ein einziges Team zusammenarbeiten. Beim 'test-first'-Ansatz brauchen Sie den Input der Tester, bevor Sie mit der Codierung beginnen können, da Sie sonst nicht wissen, ob Ihre Arbeit das tut, was sie soll. Ein weiteres Problem, mit dem sowohl Entwickler als auch Tester konfrontiert sind, ist das Reagieren auf Änderungen. Wenn der Kunde eine neue Funktion wünscht, können Sie nicht antworten: "Dafür wurde es nie gebaut!". Wir sind agil, also werden wir den Code bei Bedarf überarbeiten. Änderungen gelten auch für Tests, Anforderungen ändern sich und die Software ändert sich (Datenbankänderungen, Änderungen der Benutzeroberfläche usw.). Der Tester muss also in der Lage sein, mit diesen Änderungen umzugehen.Es gibt ein paar Dinge, die wir in Angriff nehmen können. Das Zauberwort heißt hier 'Fitnesse'. Mit Fitnesse können Sie die Spezifikation und Ausführung von Testfällen auf einer Seite zusammenfassen. Dies ermöglicht sehr intelligente Testfälle, z.B. etwas so Einfaches wie: Meine Testdaten:

id	Name
1	Tom
2	Dick
3	Harry

Der Test:

Benutzer nach Name suchen

Harry

Sie können diese Tabelle tatsächlich "ausführen" und mit Hilfe von Glue Code (Fixtures genannt) Ihre Anwendung für die Personensuche testen. Für diese Art von Testfallformat sind keine Kenntnisse über das Innenleben der Anwendung erforderlich. Egal, ob es sich um eine Swing- oder Web-Anwendung handelt, ob eine Datenbank oder ein Mainframe zum Speichern von Informationen verwendet wird. Die Fixture sorgt dafür, dass der Test funktioniert. Das macht ihn lesbarer und agiler, denn ich kann meine Anwendung refaktorisieren und die Art der Datenspeicherung ändern (z.B. den Mainframe nicht mehr verwenden), und solange die Fixture ebenfalls refaktorisiert wird, ist der Test immer noch ausführbar. So testen wir gerne: Wir lassen die Implementierungsdetails aus dem Test heraus und definieren sie auf funktionaler Ebene. Wir implementieren unsere Fixtures mit Selenium, so dass wir den Test direkt in einem Webbrowser (z.B. Firefox) ausführen können. Obwohl wir schon seit geraumer Zeit mit diesem Ansatz arbeiten, gibt es immer noch ein paar Probleme, die wir noch nicht ganz gelöst haben. Beim Benutzerakzeptanztest geht es darum, zu beweisen, dass die Anwendung genau so funktioniert, wie sie sollte. Der Tester muss nachweisen, dass keine (schwerwiegenden) Fehler vorhanden sind, indem er komplette Szenarien testet (z.B. den gesamten Prozess der Produktbestellung, von der Registrierung bis zur Bezahlung), aber auch Eckfälle testet. Aber es gibt ein Problem mit all diesen Testfällen: Sie müssen sie ändern, wenn sich die Anwendung ändert. Nach etwa einem Jahr der Entwicklung haben Sie Hunderte von Testfällen. Angenommen, der Registrierungsprozess ändert sich, und Sie haben die Registrierung in Dutzenden von Fällen verwendet, wie ändern Sie dann alle? Eine Möglichkeit, die Auswirkungen von Änderungen zu minimieren, besteht darin, die Idee der Einheitstests in die Akzeptanztests zu integrieren. Unit-Testing bedeutet, dass Sie jeweils eine Einheit testen. Wenn sich nicht verwandte Einheiten ändern, wird Ihr Test nicht abbrechen (weil er diese nicht getestet hat). Das Gleiche könnte für Tests der Benutzeroberfläche gelten. Sie könnten die Registrierung auf viele verschiedene Arten testen, aber beim Testen anderer Teile des Systems sollten Sie einfach davon ausgehen können, dass es einen Benutzer gibt, der sich anmelden kann (auch das ist etwas, was das Fixture lösen kann). Dieser Benutzer könnte als Standardbenutzer der Anwendung angegeben werden (ein 'John Doe'). Jetzt müssen Sie nicht mehr den ganzen Registrierungsprozess durchlaufen, nur um sich bei der Anwendung anmelden zu können. Unsere Testfälle (für unsere Webshop-Anwendung) können nun wie folgt geschrieben werden:"John sucht nach 'ipod' und findet diese Artikel..." Man könnte dies eine domänenspezifische Sprache nennen, die speziell für das Testen von User Stories entwickelt wurde. Auf diese Weise können Sie sehr leistungsfähige Tests erstellen. Obwohl Fitnesse ein gutes Tool für agile Tests ist, sind Akzeptanztests immer anspruchsvoll und vielleicht noch anspruchsvoller, wenn sie agil durchgeführt werden. Die meisten Kunden setzen professionelle Tester ein, aber die sind in der Regel nicht an die agile Entwicklung gewöhnt. Oft verlassen sie sich bei ihren Input-Output-Tests auf viele Excel-Tabellen, viele Spezifikationen und manchmal sogar auf eine Menge SQL-Skripte. Eine Menge Wissen über die Anwendung ist über all diese Dateien verteilt und dupliziert. Wenn Sie ihnen helfen, ihre Tests auf eine aussagekräftigere und komprimiertere Weise zu automatisieren, bleiben die Tests leicht zu ändern und für alle lesbar. Es bleibt jedoch eine Herausforderung, den effizientesten Weg zu finden, um den Testern den Einblick und die Kontrolle zu geben, die sie brauchen, und gleichzeitig agil zu bleiben.