Langsam wird’s komplex… auch wenn unser LiMux-Basisclient überwiegend auf die echten Debianpakete aus sarge (bald etch) setzt, ergeben sich durch viele Anpassungen immer wieder Situationen, in denen Tests notwendig sind.
Derzeit haben wir für die meisten Komponenten (z.B. KDE, OpenOffice.org, K3b) typische Anwendungsfälle als Testszenarien, dazu noch die Standardfunktionalitäten (Booten, Login, Neuinstallation) und jede Menge weiterer täglicher PC-Arbeiten (USB-Stick, Scanner, …). Bei kleineren Versionssprüngen ist das noch beherrschbar, zumeist werden grundlegende Funktionen und die geänderten Komponenten anhand der Szenarien getestet, mit mal mehr und mal weniger Erfolg.
Aber ist das noch machbar, wenn jetzt im Winter der komplette Austausch der Systembasis (sarge zu etch) und einige umfassende Erweiterungen der Pflege- und Verwaltungsoberfläche GOsa umgesetzt und in ein nächstes Release “LiMux Basisclient 2.0″ gepackt werden sollen?
Die klassischen Akzeptanztests (durch den Kunden) machen wir, klar. Wir arbeiten auch die definierten Testszenarien ab, auch klar. Nur, gibt’s da nicht etwas, das uns unser Leben vereinfacht?
Wir beginnen gerade mit der Suche - das Ziel ist, ein für uns sinnvolles, aber keinesfalls überzogenes Testkonzept zu entwerfen, dass die Aufwände für rein manuelles Testen senkt, die Qualität mindestens gleich bleibt (besser noch erhöht) und die neuen Aufwände zur initialen Automatisierung und fortlaufenden Pflege der automatisierten Tests im angemessenen Verhältnis zum Nutzen stehen.
Wer Erfahrungsberichte kennt oder Tooltipps hat, bitte melden 