Die Qualitätssicherung von Softwareprodukten ist ein viel schichtiges Thema. Es gibt die unterschiedlichsten Vorgehensmodelle (V-Modell, Test Driven Development, etc. ) und Testmethoden (Blackbox, Whitebox, etc.). In der Agilen Softwareentwicklung etabliert sich bereits seit einiger Zeit ein neue Sichtweise auf das Testen von Softwareprodukten. Analog zu dem Agilen Manifest, ist ein Agiles Test Manifest entstanden. Es ist stark angelehnt an die Verhaltensweisen von Agilen Entwicklungsteam und verändert die Rolle eines Softwaretesters in gänze. Wie die Integration von Softwaretestern in ein Agiles Entwicklungsteam funktionieren kann, habe ich im Artikel Qualitätssichern in Agilen Entwicklungsprojekten erläutert.
Agile Entwicklungsmethoden eigenen sich, trotz dem hohen Maß an Flexibilität, um Softwaretests zu automatisierten und kontinuierlich anzuwenden. Man muss sich aber bewusst machen, dass man kompetenzbezogene und technische Vorraussetzungen erfüllen muss, um produktiv und erfolgreich Software automatisiert zu testen. Ein wesentlicher Aspekt ist die Technische Umsetzung des Softwareentwicklungsprozess und hierfür empfiehlt es sich die Konstrukte der Kontinuierlichen Integration (Continious Integration, kurz CI) zu betrachten. Ich habe auch hierzu den Artikel Continous Integration, ein Bericht aus der Realität verfasst. Dort wird die Technische Umsetzung eines CI-Prozess mit Scrum beschrieben der ausschliesslich Open Source Softwareprodukte verwendet. Um automatisierte Softwaretests erstellen können, muss der Softwaretester in der Lage versetzt werden diese zu programmieren. Das bedingt einmal die Auswahl der richtigen Werkzeuge für die Erstellung der programmgesteuerten Tests und natürlich die Technische Kompetenz der Softwaretester, um die Test zu planen und letztendlich zu programmieren.
Bei der Umsetzung von automatisierten Softwaretests empfiehlt es sich die Umsetzungstrategien von Agilen Entwicklern zu betrachten. Agile Entwickler sind dazu angehalten ihre Funktionen in kleinen, refaktorisierbaren Einheiten zu erstellen. Hierdurch wird der Gesamt Programmcode wartbar und es ist wesentlich einfach auf veränderte Anforderungen zu reagieren. Exakt die gleiche Strategie muss man bei der Entwicklung von automatisierten Softwaretests beachten. Je kleiner die Tests gefasst sind, desto einfacher lassen sich Testelemente anpassen und in anderen Funktionstests wiederverwenden. Speziell die Wiederverwendbakeit ist ein entscheidender Faktor. Wenn man eine Testfunktion erstellt die beispielsweise ein Vertragselement in einer Verwaltungssoftware anlegt, sollte man mit der gleichen Funktion x-beliebige Verträge mit verschiedenen Inhalten anlegen können. Somit erhält man die Möglichkeit Vertragsvariante A, B, C mit der gleichen Funktion zu testen. Und wenn sich die generelle Logik der Anlage eines Vertrages verändert, muss man nur eine Funktion anpassen, als X-Testfälle nachzuarbeiten. Ebenso ist Gruppierung von Testfunktionen zu verschiedenen Testfällen ein wichtiger Aspekt. Eine Testfunktion die in verschiedenen Testfällen integriert werden kann, gewinnt mehr Zeit für die Erstellung von anderen Testfällen und ist ein Katalysator für ein gesteigertes Maß an Qualität.
Eine weitere Herausforderung bei der Erstellung von automatisierten Tests ist die Interpretation der Testergebnisse. Ist ein Rückgabewert aus der Anwedung nun ein Fehlverhalten in der Software oder lediglich eine Konstellation, die in der Testfunktion noch nicht betrachtet wurde? Man sollte im Design des Testfalles daher sehr bewusst die Auswertung beachten, um nicht ungewollt einen Fehler zu melden, der eigentlich nicht im Softwareprodukt vorhanden entstanden ist, sondern in der betreffenden Testfunktion. Damit man auf eine solche Situation zielgerichtet reagieren kann, muss das Testergebnis ausführliche Informationen darstellen. Hierbei gilt die einfache Relation, je mehr Informationen zur Verfügung stehen, desto einfacher lassen sich Fehlerkonstellationen nachstellen. Neben den Informationen was ist passiert, sollte man auch Protokollieren welche Schritte vorher ausgeführt wurden bis zum Fehlerereignis. Welche Konfiguration wurde verwendet und manchmal hilft auch ein Screenshot um klar nachvollziehen zu können, was passiert ist.
Neben der Auswertung von einzelnen Testfällen, muss man im Programmablauf der Testfunktion auch auf die ggf. auftretten Fehler innerhalb der Testfunktion achten. Man muss klar darstellen können, ob es sich um einen Fehler in der zu testenden Produktfunktion handelt oder um einen Fehler in der Testfunktion selbst. Das ist besonders wichtig im Zusammenhang eines größeren Testdurchlaufes, in dem mehrere Testfälle abgearbeitet werden. Folgefehler, die infolge eines vorgelagerten Fehler entstehen, sind natürlich zu vermeiden, um die Analyse des enstandenen Fehlerfalles zu vereinfachen. Daher gilt es bei der Auswertung eines Testfalles stehts zu entscheiden, ob ein Testdurchlauf weiter durchgeführt werden kann, oder ob der aufgetrettene Fehler ein sog. „Showstopper“ ist und jeder weitere Test abgebrochen wird.
Der Vorteil von automatisierten Softwaretests wird in der Entwicklung von größeren Softwareprodukten leicht erkennbar. Ohne die Anforderungen die Qualität über mehrer Produktversionen sicherzustellen, ist die Investition in automatisierte Test nur wenig ertragreich. Ein kleiner Ertrag der bei allen größen von Entwicklungsprojekten, durch automatisierte Tests erbracht wird, ist das Aufdecken von Seiteneffekten. Wenn man ein Modul abgeschlossen hat und entwickelt ein weiteres, sollten im Buildverfahren trotdem alle Funktionen des ersten Moduls getestet. Falls durch die Entwicklung eines weiteren Moduls die Testergebnisse des ersten Moduls beeinflusst werden, kann das entweder bedeuten, dass es sich um einen Fehler (Seiteneffekt) handelt, oder dass die Testfunktionen des ersten Moduls überarbeitet werden muss. Es kann ja der Fall sein, dass bei der Entwicklung der Testfälle für das erste Modul die Gesamtanforderungen nicht bekannt waren und man auf die Veränderung reagieren muss.