Projektgruppe Visual Analytics - Medieninformatik und Multimedia ...

12.2 Testvorgehen 213
Inspektionsrate beträgt damit sechs Seiten pro Stunde. Im Vergleich mit typischen
Softwareprojekten, welche eine Rate von 5-20 Seiten pro Stunde haben [GG93], ist
die Inspektionsrate damit am unteren Niveau. Von der in [GG93] genannten optimalen
Inspektionsrate von einer Seite pro Stunde besteht allerdings eine erhebliche Differenz.
Dies bedeutet, dass einerseits noch mehr Zeit in die Reviews einfließen könnte,
andererseits im Vergleich mit echten Softwareprojekten die Qualität der Reviews bereits
sehr hoch ist, denn mehr Zeit für Reviews bedeutet eine gründlichere Fehlersuche.
Das stetige Erstellen von Zwischendokumenten, die zeitnah einem Review unterzogen
wurden, gestattete die frühe Zusammenstellung des Abschlussberichts. Dieser konnte
noch vor der Abgabe durch externe Inspekteure kontrolliert werden und die dort
gefundenen Fehler korrigiert werden.
12.2.3 Programmtests
Ein weiterer Bestandteil der Qualitätssicherung ist die Sicherung der Qualität des
Programmes. Diese drückt sich zum einen durch einen lesbaren Code aus, der durch
die Coding-Konventionen (vgl. 12.1) sichergestellt ist, und zum anderen durch ein
fehlerfreies und benutzungsfreundliches Programm.
Das entwickelte Programm ist sehr stark oberflächenlastig, was das Testen des
Programms und damit das Finden von Fehlern äußert schwierig gestaltet. Unit-Tests sind
für das Testen von Algorithmen ausgelegt, allerdings nicht für das Oberflächentesten.
Aus diesem Grund hat sich die Projektgruppe dazu entschieden, Unit-Tests nicht als
vorrangige Testmethode zu verwenden. Als weitere Schwierigkeit gestaltet es sich, für
ein automatisches Testframework Daten zu entwickeln, die alle Randfälle behandeln.
Wegen den zwei genannten Schwierigkeiten ist auf automatisierte Tests verzichtet
worden. Stattdessen sind Live-Tests direkt am System durchgeführt worden. Hierfür ist
eine ganze Iteration, die Stabilisierungs-Iteration, eingeplant worden.
In dieser Iteration ist das ganze Programm nach einem vorgegeben Schema getestet
worden. Dabei ist die Funktionalität durch Anwendungsszenarios geprüft worden,
wodurch nicht nur die Benutzungsoberfläche, sondern auch implizit die darunter
liegenden Schichten, wie zum Beispiel das Multitouch-Framework, getestet worden
sind. Zur Dokumentation der Testfälle ist ein Wiki eingerichtet worden. Ein Wiki
hat den Vorteil, dass es von jedem editiert und ergänzt werden kann, wodurch jedes
Projektmitglied die aktuellen Änderungen sofort sieht. Damit die Einträge im Wiki alle
eine gleiche Form haben, sind diese nach einer Vorlage erstellt worden. Ein Eintrag
besteht aus folgenden Elementen:
Titel: Ein aussagekräftiger Titel zu diesem Testszenario
Beschreibung: Eine genaue Beschreibung des Szenarios