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