2-tier Continuous Integration

Wie stellt man eine Umgebung für dauerhafte Test bereit? Die Frage ist nicht leicht zu beantworten. Zunächst ist es wichtig zu unterscheiden, was getestet werden soll. Bei der Entwicklung von Software sind das meistens Modul- und Integrationstests. Diese werden oft mit Hilfe eines entsprechendes Framework von den Entwicklern programmiert (z.B. JUnit/NUnit) und nach dem nightly build automatisiert angestossen (z.B. mit CruiseControl).

Bei der agilen Softwareentwicklung kommen kontinuierliche GUI Test hinzu. Aufgrund der Tatsache, dass man iterativ an einer Software entwickelt und stets brauchbare Funktionalität abliefern soll, ist es unerlässlich, dass man bereits implementierte Funktionen re-testet. Aber was soll getestet werden? Entgegen Modul- und Integrationstest, die meist diverse Worst-Case Szenarien abdecken, wird beim GUI Testing ein White-List Verfahren auf Ebene der Funktionen durchgeführt. Unter White-Test versteht man in diesem Zusammenhang das Vorhandensein und "korrekt arbeiten" von Funktionen, nicht jedoch Test, bei denen alle möglichen (fehlerhaften) Eingaben von Benutzer getestet werden (Black-List Testing). Im Vordergrund dieser Test steht die Sicherstlellung der kontinuierlichen Kundenakzeptanz.

Wie stellt man das sicher? Es gibt einen Ansatz - 2tier Continuous Integration. Darunter versteht man einerseits Modul- und Integrationstest (first tier) und GUI Akzeptanztests (second tier). Die folgenden Graphiken soll die Prozess veranschaulichen:





Idealerweise führt jeder Entwickler vor dem Checkin die Akzeptanztests auf seiner Entwicklermaschine aus. Je nach der Done Definition des Teams ist es sogar erforderlich, das alle Test erfolgreich waren, bevor man eincheckt.

Gibt es dafür Tools? Ja, Buildix. Dazu gibt es bereits einen Blog-Eintrag...