Blog Testen im Team

Testen im Team

Im laufenden Projekt ging es darum, die SOAP Schnittstelle eines Embedded Systems im Gesundheitswesen zu testen. Bis zu f├╝nf Kolleginnen und Kollegen sollten die Funktionstests durchf├╝hren. In den Vorbesprechungen wurden zwei Entscheidungen herbeigef├╝hrt: Die Open Source Variante von SoapUI sollte das Mittel der Wahl sein, um die Funktionstests umzusetzen. Au├čerdem wurde schnell klar, dass auch Mechanismen geschaffen werden m├╝ssen, um die Tests im Team effizient abwickeln zu k├Ânnen. Es galt, vier selbst gestellte Anforderungen umzusetzen:

  1. Die Tester sollen die Testf├Ąlle jederzeit untereinander austauschen k├Ânnen.
  2. Die Tests m├╝ssen als Regressionstests in Iterationen wiederholbar sein.
  3. Ähnlich wie beim Quellcode eines Produkts soll die Weiterentwicklung der Testskripte nachvollziehbar und dokumentiert sein.
  4. Die komplexe Teststellung aus zu testenden Endger├Ąten und SmartCard Kartenterminals soll keinen Einfluss auf die Portabilit├Ąt der Tests haben.

Da sich das Testteam aus erfahrenen Softwareentwicklerinnen und -entwicklern zusammensetzt, brauchten wir keine Scheu davor zu haben, uns aus dem Werkzeugkasten modernen Softwareengineerings zu bedienen.
SoapUI speichert die Testskripte ("Projekte") in Form von XML-Dateien ab. Dieses Textformat legt nahe, die Projektdateien unter Versionskontrolle mit Git zu stellen. Da wir bei n-design f├╝r interne Projekte einen Gitlab Server betreiben, fiel die Entscheidung einfach, dieses Werkzeug auch f├╝r die Testung zu nutzen.

Jedoch stellte sich schnell heraus, dass sich die Datenhaltung von SoapUI nicht uneingeschr├Ąnkt f├╝r das von uns beabsichtigte Vorhaben eignet. Die Projektdateien enthalten nicht nur die reinen Testskripte, die den Ablauf der Tests beschreiben, sondern dienen auch als persistenter Speicher f├╝r alle Test- und Konfigurationsdaten ("properties"), die im Rahmen der Tests anfallen. Diese Properties sind zum Teil hochgradig volatil, sodass gar keine Notwendigkeit besteht, die Daten zu persistieren. Es handelt sich dabei z.B. um Card Handles, die gesteckte Smart Cards referenzieren oder um Ergebnisdaten von Signier- und Verschl├╝sselungsvorg├Ąngen, die nach der Beendigung der Tests in den Daten des Projekts stehen und so beim n├Ąchsten Speichern persistiert werden. Arbeitsplatzspezifische Konfigurationsdaten wie IP-Adressen der Testger├Ąte und IDs der verwendeten Kartenterminals werden auf die gleiche Weise behandelt.

Das ist nat├╝rlich ein Show-Stopper f├╝r die effiziente Versionskontrolle der Projektdaten mit Git: Bei jedem Commit/Push werden die volatilen Testdaten und die Konfigurationsdaten des Arbeitsplatzes des Testers mit in das zentrale Repository ├╝bernommen. Das f├╝hrt dazu, dass jeder Tester nach einem Pull erstmal seinen Arbeitsplatz neu konfigurieren muss. Au├čerdem ist in dem Wust an ├änderungen pro Commit nicht mehr ersichtlich, welche Weiterentwicklungen die Testf├Ąlle genau erfahren haben.

So mussten wir zur├╝ck ans Whiteboard und unser Testvorgehen verfeinern.

Im ersten Schritt haben wir den Scope einer Projektdatei verkleinert. Anstatt wie vorher alle Testf├Ąlle einer Iteration (entsprechen in etwa Sprints in Scrum) in einer Projektdatei zu vereinen, sind wir dazu ├╝bergegangen, die Testf├Ąlle pro Anforderung aus dem Fachkonzept in einer Projektdatei abzubilden. Dieser deutlich kleinteiligere Schnitt erscheint im ersten Moment gr├Â├čeren Verwaltungsaufwand zu erzeugen. Doch f├╝r den gr├Â├čeren Overhead wurden wir mit deutlich weniger Merge-Konflikten belohnt. Dadurch sind wir unseren gesteckten Zielen ein ganzes St├╝ck n├Ąher gekommen: Tester k├Ânnen die Testskripte leicht untereinander austauschen und die Fortschritte bei der Entwicklung der Testskripte sind nachvollziehbar.
Das weitaus gr├Â├čere Problem blieb allerdings bestehen: Wie gehen wir mit den volatilen Test- und den statischen Konfigurationsdaten um? Hier half nur eine Mischung aus technischem und organisatorischem Vorgehen.

Zuerst mussten die in den Projektdateien angelegten Properties kategorisiert werden: Die statischen Konfigurationsdaten, die einen Arbeitsplatz beschreiben, wurden in eine klassische Java Properties-Datei ausgelagert. Diese Datei wird SoapUI ├╝ber den Kommandozeilenschalter "-Dsoapui.properties" ├╝bergeben. So importierte Konfigurationsdaten interpretiert SoapUI als globale Properties. Testskripte mussten angepasst werden, um diese Daten aus dem ├╝bergeordneten Scope zu lesen und nicht mehr als Properties einer Testsuite oder eines einzelnen Testfalls zu behandeln. Die arbeitsplatzspezifische Konfigurationsdatei liegt im selben Verzeichnis wie die Projektdateien, wird aber durch einen Eintrag in der .gitignore Datei nicht versioniert und steht somit nicht im zentralen Git Repository.

Im organisatorischen Teil der Ma├čnahme haben die Tester sich darauf verst├Ąndigt, als letzten Schritt eines Testfalls einen Aufr├Ąumschritt einzuf├╝gen, der alle zur Laufzeit des Tests erzeugten Properties wieder l├Âscht, sodass keine Properties persistiert werden. Ein Groovy-Dreizeiler sorgt daf├╝r:

testRunner.testCase.getProperties().each {

testRunner.testCase.setPropertyValue(it.key, "")

}


Dieses Aufr├Ąumen nach einem durchgef├╝hrten Test entspricht nat├╝rlich dem g├Ąngigen Vorgehen bei Unit-Tests. SoapUI unterst├╝tzt das Einhalten von Vor- und Nachbedingungen durch speziell designierte Testschritte, die ÔÇô wenn vorhanden ÔÇô vor, bzw. nach dem Test ausgef├╝hrt werden.

Damit haben wir das Ziel, die Konfigurationsdaten und die volatilen Testdaten von den Testskripten zu trennen, erreicht. Ein positiver Nebeneffekt ist, dass die Tester ein besseres Gesp├╝r daf├╝r entwickelt haben, auf welcher Ebene in SoapUI (Projekt, Testsuite, Testfall, Testschritt) welche Properties angesiedelt sein sollen. Dadurch haben wir auch das Ziel der Regressionsf├Ąhigkeit der Tests umgesetzt: Tests k├Ânnen jederzeit von jedem Tester in beliebiger Reihenfolge ausgef├╝hrt werden.