Vorab bemerkt: SuperX ist eine Software die "agil", d.h. in der Regel bei der bzw. für die Hochschule entwickelt wird. Alle Beteiligten unterstützen das Agile Manifest. Die Hochschule fungiert oft als Auftraggeber/in und als Tester/in und ist insofern an einer hohen Qualität interessiert, und somit an Software Tests. Die folgenden Folien zeigen die Zielsetzung und Implementierungsvorhaben des Moduls.
Zunächst zur Frage Warum:
Statistiken arbeiten mit den Daten der Hochschule und sollten valide sein und schnell abrufbar sein, bei einzelnen Statistiken ist wichtig dass der jeweilige Ergebniswert sich nicht ändert (z.B. bei Stichtagsdaten).
Außerdem betreiben Hochschulen oft mehrere "Säulen" der Software, und Änderungen an der Software (z.B. Versionsupgrades) sollten getestet werden. Ein andere Szenarion wäre eine Wechsel der grundlegenden Softwarearchitektur, z.B: der Wechsel von Informix zu Postgres.
Das Testen selbst ist eine mühsame Arbeit und sollte wenn möglich automatisiert werden.
Nun zur Frage was getestet werden sollte:
Alle Funktionalitäten der Software sollten getestet werden, d.h. die Installation bzw. Upgrade, die Laderoutinen und Bearbeitungsformulare sowie die Berichtsgenerierung, d.h. die Ergebnisse von Statistiken. Neben einer grundlegenden Funktionsfähigkeit sollten auch die Laufzeit der Implementierung und die Validität der Ergebnisse getestet werden. Validität kann in einzelnen Werten oder Wertebereichen liegen.
Nun zur Frage, wie getestet werden sollte:
Wir wollen Testfälle planen, einrichten, automatisiert ausführen und die Ausführung prüfen. Dazu benötigen wir Protokollfunktionen.
Und wer testet? Natürlich die Hersteller der Software, und die Hochschule. Bei SuperX wird auch an der Hochschule entwickelt, deshalb sollten wir es eher an Tätigkeitsbereichen festmachen: Es sind jeweils Entwickler/innen und die jew. Fachabteilung beteiligt.
Nun zur Frage wann getestet wird: Natürlich sollten die Tests nach den nächtlichen Laderoutinen automatisch lauffähig sien, oder nach Versionsupgrades. Es kann auch sinnvoll sein, Testfälle manuell auszuführen.
In der derzeitigen Implementierung können Masken automatisiert ausgeführt und einzelne Ergebnise im generischen Standardlayout überprüft werden. Die Testfall-Planung kann im Browser vorgenommen werden, und die Ausführung funktioniert Superx-typisch über Nacht bzw. die Hauptladeroutine. Noch nicht implementiert sind
Im QA-Modul werden Testfälle angelegt und automatisiert ausgeführt. Zunächst planen Sie den jew. Testfall.
Sie können Masken-Ausführungen für den Test planen, indem Sie
Wir wollen an einem Beispiel zeigen wie Testfälle angelegt werden. Zunächst identifizieren Sie die Maske, die Sie absichern wollen, hier z.B. eine Maske "Studierende nach Alter", die ein Klon der Release Maske ist:
Die Maske führen wir für das WiSe 2018/2019 aus. Im Ergebnis erhalten wir 574 Studierende gesamt. Wir notieren die Zeilen und Spaltennummer der Ergebnisses, das wir absichern wollen.
Für die Planung der Testausführung müssen wir in der Maske natürlich das Semester festhalten, hier das WiSe 2018/2019. Wir bringen die Schlüsselwerte zur Ansicht, indem wir die Schlüsselanzeige aktivieren:
Die Werte für die Felder "Seit Semester" und "Bis Semester" sind also 20182, der Code fürs WiSe 2018/2019.
Das Arbeitsprinzpi eines Maskentestfalls sieht wie folgt aus:
Bei Datenblatt-Berichten im Testfall muss man folgende Fallstricke beachten:
Wir haben für diese Funktionalität auch einen Lehrfilm erstellt.
Wir legen den Testfall an, indem wir in die Maske Qualitätssicherung -> Administration Qualitätssicherung -> Masken-Ausführung planen gehen. Dort können wir filtern auf Merkmale eines Testfalls, z.B. die zugehörige Maske, die Komponente oder den Namen des Testfalls.
Nach der Erstinstallation ist die Maske und das Ergebnis leer. Sie können dann aber einen neuen Testfall anlegen.Hier existiert bereits ein Testfall:
Wir tragen im Bearbeitungsformular zunächst den Namen des Testfalls und die Maske ein, sowie die Komponente. Nach dem Speichern können wir die Unterformulare zu den Feld-Vorbelegungen und zu den erwarteten Ergebnissen füllen. Wir übernehmen die Werte aus der Testfall-Identifikation, d.h. also im WiSe 2018/2019 in Zeile 1 und Spalte 4 den Wert 574. Sie können auch "Toleranzgrenzen" (von-bis) festlegen. Außerdem können Sie mehrere erwartete Ergebnisse hinterlegen, z.B. in Spalte 5 einen weiteren Wert.
Damit ist der Testfall geplant, und mit dem Schalter "Aktiv=1" wird er aktiviert. Damit wird er mit der Hauptladeroutine des QA-Moduls ausgeführt.
Sie können Testfälle auch in einer xlsx-Datei anlegen und dann im Browser hochladen. Nehmen wir als Ausgangsbeispielt folgendes Berichtsergebnis, das wir als korrekt ansehen:
Wir definieren für die rot hinterlegten Zellen einen minimalen Schwellwert, z.B. mindestens 600 für die Gesamtzahl im WiSe 2018/2019. Dieses können wir in Excel abbilden anhand der Vorlage in der Datei
Die Struktur der xlsx-Datei sieht so aus:
Die führenden zwei Zeilen dienen als Spaltenüberschriften, darunter kommen dann die Angaben
Diese Datei können Sie im Menüpunkt "Qualitätssicherung -> Administration Qualitätssicherung -> Testfälle hochladen" hochladen:
Nach dem Upload können Sie den Testfall über die Verwaltungsmaske prüfen:
Nach Ablauf des Konnektors können Sie das Protokoll prüfen:
Analog zu Maskentests können Sie auch Datenbanktests ausführen.
Sie können Datenbank- und Maskentests zu Profilen zuordnen, um die gruppiert auszuführen oder auszuwerten. Hier ein Beispiel für einen Maskentest:
Die Projekte lassen sich als Filter in den Verwaltungsmasken für Masken- und Datenbanktests nutzen.
Die Hauptladeroutine des QA-Moduls führt alle als aktiv gekennzeichneten Testfälle aus, normalerweise geschieht dies über Nacht. Nach dem Ausführen können Sie das Protokoll aufrufen. Gehen Sie dazu ins Menü Qualitätssicherung -> Testfall-Protokoll.
In der Maske können Sie auf einen Start der Ausführung filtern (defaultmäßig heute -3 Tage), sowie nur auf aktiv geplante Testfälle. Außerdem können Sie Testfall-Namen als Stichwort oder Masken, die getestet werden, filtern, oder auf Projekte bzw. Testfall-Typen filtern.
Wenn Sie das Formular abschicken, erhalten Sie das Ergebnis-Protokoll:
Sie sehen, ob die Maskenausführung erfolgreich war (Spalte Ausführungsstatus), und wie der erwartete und gefundene Wert war. Außerdem sehen Sie die Dauer das Maskenausführung. Die Spalte "Ausführungsstatus" kann drei Werte enthalten:
Mit dem "Detail"-Button können Sie noch Details anzeigen, was insbesondere im Warnungs- oder Fehlerfall aufschlußreich ist, weil damit die Differenz bzw. Fehlermeldung angezeigt wird.
Hier ein Detail-Protokoll von Masken-Testfällen:
Im Detail-Button können Sie auch eine unformatierte Ansicht der Ergebnistabelle zur Laufzeit aufrufen:
Das Testfall-Protokoll bietet noch einen formatierten Bericht mit einer Kreuztabelle über Projekte und Ausführungsstatus. Sie können diesen im Tabellenkopf aufrufen:
Wenn Sie auf "GO" klicken, erhalten Sie eine formatierte Ansicht und am Ende die Kreuztabelle:
Die Funktion "Tabellen-Abgleich" kann über ein vorgegebenes Profil zwei Tabellen abgleichen Differenzen leicht auffindbar machen. Ein Beispiel ist der Abgleich der Amtl. Studierendenstatistik mit der in SuperX.
Sie können im KENN Modul einen Lieferfile der amtlichen Studierendenstatistik hochladen.
Wir haben im QA Modul eine kleine Anwendung erstellt, die diesen Lieferfile mit SuperX abgleicht, indem
Hier ein Beispiel: Die Maske "Tabellen-Abgleich" bietet ein ausgeliefertes Profil "Vergleich Studierende ASTAT (Fach/Abschluss) Stichtag amtl. Stat.":
Das Profil gleicht die amtl. Studierendenstatistik mit der Studierendenstatistik im SOS-Modul zum Stichtag "Amtl. Statistik" ab. Gasthörer und Exmatrikulierte werden automatisch ausgeschlossen.
Im Ergebnis erhalten Sie die Differenz:
Sie können auch den Abgleich auf Datensatzebene vornehmen. Hier ist es sinnvoll, nur noch auf Warnungen zu filtern:
Hier wäre der "Primärschlüssel" eines Datensatzes die Matrikelnr., das Semester, sowie amtliches Fach und amtlicher Abschluss. Sie erhalten eine übersichtliche Liste mit einer Markierung, ob der jew. Datensatz im Bestand vorhanden ist (x) oder nicht.
Sie können auch auf Feldebene vergleichen, auch hier sollten Sie wieder nur auf Warnungen filtern:
Im Ergebnis finden Sie die verglichenen Felder und die Anzahl der Differenzen.
Die Differenz selber ist ein Hyperlink, und bietet eine Detailansicht. Wenn wir z.B. die Differenzen zum Feld "Staatsangehörigkeit" sehen wollen, klicken wir auf die "7" und erhalten eine Detailliste:
Diese Liste zeigt z.B. dass sich die Staatsangehörigkeit von 0 (Deutsch) in der amtlichen Statistik auf 121 in SuperX geändert hat. Offenbar wurden die Daten zum Stichtag nicht eingefroren.