Immer wenn ein neues Release ansteht
Auch wenn es dem einen oder anderen manchmal nicht so erscheinen mag, auch mein campus wird regelmäßgig getestet. So geschieht es auch momentan wieder im Rahmen des Releases für mein campus Version 4.0.
Diese neue Version von mein campus beinhaltet ein Upgrade der QIS-Module auf Version 11.1, einige neue Funktionen und Fehlerbereinigungen. Diese Entwicklungen wurden auf einer Entwicklungsumgebung durchgeführt, die parallel zum Produktivsystem besteht. Da auch bei sorgfältigster Entwicklung und in Anbetracht der komplexen Struktur von mein campus nicht ausgeschlossen werden kann, dass sich Fehler einschleichen, muss die Software, bevor sie auf das Produktivsystem gespielt wird, ausgiebig getestet werden. Dazu gibt es einen fixen Termin, ab dem alle Weiterentwicklungen am Entwicklungssystems gestoppt werden, den sogenannten „code freeze“. Zu diesem Zeitpunkt wird das Entwicklungssystem in die Qualitätssicherungssäule überführt, auf dem die Tests durchgeführt werden. Gleichzeitig wird ein neues Entwicklungssystem aufgesetzt, auf dem von nun an die Weiterentwicklungen vorgenommen werden.
Auf der Qualitätssicherungssäule werden die Tests durchgeführt und die Fehlerkorrekturen (Bugfixes) vorgenommen. Dies wird optimalerweise an getrennten Systemen vorgenommen, damit die Tests nicht durch die Fehlerbehebung beeinträchtigt werden. Beide Systeme basieren auf der gleichen Datenbasis, allerdings werden Bugfixes nicht auf das Testsystem gespielt. Nur wenn ein Fehler das Testen unmöglich macht, sollte dieser auf dem Testsystem behoben werden. Allerdings ist das Vorgehen nicht immer so durchfürbar, da die einzelnen Komponenten stark miteinander verwoben sind und so Fehlerbehebungen nicht immer gezielt auf das Testsystem gespielt werden können. Somit werden dann meistens im Rahmen der Fehlerbehebung auf dem Testsystem alle bisher vorgenommenen Bugfixes eingespielt, was dann aber koordiniert geschieht.
Das Testsystem wird anhand von verschiedenen Verfahren getestet. Da gibt es den Oberflächentest, bei dem es darum geht, das visuelle Äußere und die Handhabbarkeit des Systems zu überprüfen. Dazu wird beispielsweise der Seitenaufbau betrachtet, die Navigation, das optische Erscheinungsbild und die allgemeine Benutzbarkeit des Systems. Die Prüfungen werden anhand von Checklisten durchgeführt und protokolliert. Ein weiterer Test ist der Browsertest. Hier wird das System unter verschiedenen Betriebsumgebungen getestet. Das bedeutet, dass die Anwendung mit verschiedenen Kombinationen aus Browser und Betriebssystemen getestet wird. Außerdem werden verschiedene Einstellungen beim Browser vorgenommen und das Verhalten der Anwendung geprüft. Getestet werden hier die Kombinationen, mit denen am häufigsten auf die Server von mein campus zugegriffen werden. Auch hier wird anhand von Checklisten getestet.
Die bisher genannten Testverfahren überprüfen lediglich die Oberflächen und nur rudimentär die Funktionalität. Um diese zu testen, werden Black-Box-Tests durchgeführt. Dazu wurden für die unterschiedlichen Funktionen der Anwendung spezifische Testfälle generiert. Dabei wurde darauf geachtet, dass die zu testenden Fälle ein möglichst großes Spektrum an Fehlermöglichkeiten abdecken. Um dies zu erreichen, wurden die Testfälle auf Basis der Dokumentation, konkreten Fällen aus dem Support und auf Basis von Erfahrungen aufgestellt. Die eigentlichen Tests werden anhand von Protokollen durchgeführt und dokumentiert.
Da das mein campus-Team relativ klein ist und die Zeit zum Testen und Fehlerbereinigen begrenzt ist, muss ein Teil des Teams die Tests durchführen und der andere Teil die gefundenen Fehler beheben. Natürlich gibt es hier auch Überschneidungen. Dadabei testet in der Regel speziell bei den Black-Box-Tests ein Tester den Bereich, über den er fachliches Wissen besitzt. Dadurch ist es für ihn leichter, auch fachliche Fehler zu erkennen und entsprechende Fehlermeldungen mit Lösungshinweisen zu verfassen. Alle Fehler, die beim Testen gefunden werden, werden in der Bugtracker-Anwendung Bugzilla eingestellt und somit dokumentiert.
Dies war jetzt ein kleiner Einblick in die Qualitätssicherungsmaßnahmen von mein campus, speziell auf das Vorgehen vor dem Start einer neuen Version. Kontinuierlich werden die einzelnen Maßnahmen immer weiter optimiert, was natürlich nur unter Berücksichtigung der zur Verfügung stehenden Resourcen möglich ist. Ein Bestreben ist es, die Testfälle noch weiter zu verbessern und zu präzisieren. Ebenso wird ein Schwerpunkt in der Zukunft sein, den Qualitätssicherungsprozess im Allgemeinen noch zu optimieren.