Durch eine Mail in der Firma bin ich heute darauf gestossen, dass ein Test Framework, welches wir in einem grossen Projekt genutzt haben, mittlerweile (vielleicht auch schon länger) frei verfügbar ist. Dabei bin ich zunächst mal über Google Code gestolpert. Das hatte ich zwar schonmal in Zusammenhang mit Android gesehen, aber mir war gar nicht bewusst, dass Google auch Project Hosting betreibt.
Project Hosting on Google Code is a free service to the open source community. Featuring a Subversion back-end, wiki support, file downloads, issue tracking and a clean, Google-style interface, our project hosting service is the world’s second largest open source hosting site after SourceForge.net.
Aber zurück zum Test Framework mit dem einprägsamen Namen Robot. Das Projekt bei dem ich Robot genutzt habe liegt etwas mehr als ein Jahr zurück, aber ich glaube ich kann mich an die wichtigsten Features noch ganz gut erinnern.
Also, wofür ein … dieses … Test Framework? Es geht darum einen automatisierten Blackbox-Test für eine Software aufzubauen. Automatische Tests sind ein Herzstück agiler Softwareprojekte, denn nur mit (guten!) automatisierten Tests lässt sich innerhalb einer Iteration sicherstellen, dass alle bereits fertigen Teile der Software immer noch wie erwartet funktionieren – und die neuen Teile natürlich auch. Hierbei gilt es die von der Software zur Verfügung gestellten Interfaces abzutesten (”Gutfälle” und “Schlechtfälle” gleichermassen). Natürlich hängt die Qualität der Tests stark vom Test-Entwickler ab, und das beste Framework kann keine schlechten Tests vermeiden, aber es kann die Implementierung guter Tests unterstützen. Und das tut das Robot Framework ganz gut wie ich finde.
Die Einarbeitungszeit in das Tool war relativ gering. Die Tests lassen sich in einzelnen Modulen implementieren. Dies kann entweder in Java passieren, oder in jeder Sprache, die sich per Shell aufrufen lässt, z.B. Perl. Ein Test erwartet einen gewissen Satz von Parametern, die dann an die Testmethode übergeben werden. Diese Methode implementiert dann den Test und liefert OK oder NOK zurück. Ein Testcase lässt sich aus mehreren solcher Methoden zusammensetzen. Auch kann man die Testcases taggen, um sich in den generierten Reports einen besseren Überblick über die getesteten Teile der Software zu verschaffen … Achtung … die benutzten Keywords müssen gut abgestimmt werden, sonst benutzt jeder leichte Abwandlungen.
Testmethoden lassen sich in einer Art Projekt zusammenfassen, wobei es natürlich sinnvoll ist ähnliche – und vor allen Dingen generische – Testmethoden einmal für mehrere Projekte zu schreiben. Solche Tests könnten z.B. sein: “Existiert eine Datei (Parameter Pfad zur Datei)” oder “Existiert ein Directory (Pfad zum Directory)”. Komplizierte Testcases können so aus einer Vielzahl (idealerweise bereits existierender) Testmethoden zusammengesetzt werden. Die generierten Reports zeigen übersichtlich die Anzahl der erfolgreichen/fehlgeschlagenen Tests an und es lässt sich auch anzeigen welche Tests wo fehlgeschlagen sind.
Was ist sonst noch zu beachten? Die eigentlichen Testcases werden in einer simplen HTML-Datei geschrieben, was die Ganze Sache recht einfach macht. Hier werden nur noch vorhandene Testmethoden genutzt und die Parameter übergeben. Zum eigentlichen schreiben der Testmethoden ist aber im Prinzip eher das Wissen eines Entwicklers als das eines Testers gefragt, denn die Entwicklung der Testmethoden kann sich leicht zu einem eigenen kleinen Software-Projekt entwickeln. Auf der anderen Seite ist es gefährlich wenn der Entwickler die Testmethoden für seine eigenen Komponenten entwickelt. D.h. hier sind Tester mit Programmiererfahrung gefragt oder aber die Testmethoden müssen von verschienden Team-Mitgliedern entwickelt werden. Es ist eh fraglich ob “reine Tester” in agilen Teams sinnvoll sind, insbesondere wenn diese auch noch in externe Teams ausgelagert sind. Ich denke es macht deutlich mehr Sinn Testkompentenz – zusätzlich – im agilen Team aufzubauen und zu nutzen. Dadurch bekommen die “Tester” auch direkt mehr Produktkompentenz und wissen besser welche Schnittstellen es zu testen gilt.
Testen von “Backend-Prozessen” und GUI … das werde ich hier nicht vertiefen, zumal ich nur bei Tests im Backend-Bereich involviert war. Aber zumindest schien es einige Probleme mit den Libraries zu geben, die für das GUI-Testen benutzt werden mussten. Aber da das über ein Jahr zurück liegt wird es sicherlich Fortschritte in dem Bereich gegeben haben.
In diesem Sinne “happy testing and roboting” … :-)
