Softwarequalität

E2E-Test

Einführung

Nach der Installation oder einer Aktualisierung der Anwendung, kann die Anwendung an bestimmten Stellen noch einmal seitens der Endnutzer*innen getestet werden. Diese Art der Testung nennt sich End-to-end-Testung oder auch Akzeptanztest. Sie soll sicherstellen, dass durch die Installation oder durch eine Anwendungsaktualisierung keine Fehler in der Anwendung entstanden sind, die zu Fehlfunktionen während eines Studienlaufs führen könnten. Es kann mit solchen Tests aber auch das individuell konfigurierte Verhalten einer Testung getestet werden. Hier könnten dann bspw. so klassische Fälle, wie die an Bedingungen geknüpfte Navigation (responses/presentation complete) zwischen den Aufgaben, getestet werden

Vor jeder Veröffentlichung einer neuen Version führt das IQB eigene Testungen durch, die die gewünschten Funktionen der Anwendung sicherstellen sollen. Hierzu zählen E2E-Testungen und Testungen in anderen Phasen des Software-Lebenszyklus (Unit-Test etc.). Anfangs wurden IQB-seitig E2E-Tests manuell durchgeführt, was sehr viel Zeit und Personal bindet. Nach und nach hat das IQB Testfälle automatisiert und in den Code der Anwendung integriert. Somit ist es allen Endnutzer*innen möglich diese Tests zu nutzen oder diese als Vorlage für eigene Testszenarien zu verwenden.

Es ist mühselig und zeitraubend eigene Testszenarien zu entwickeln und zu erproben. Diese Arbeit möchte das IQB an dieser Stelle gerne abnehmen oder zumindest unterstützend einwirken. Am Ende steht es jedem frei, wie E2E-Tests für die eigene Instanz auszusehen haben. Es können hier ganz unterschiedliche Anforderungen bestehen, was wo und wie getestet werden soll. Falls die E2E-Testfälle des IQB genutzt werden sollen, werden hier Hinweise zu deren Verwendung gegeben. Sollen eigene Testungen entworfen werden, wollen wir zumindest auch hierzu Ratschläge aus eigenen Erfahrungen geben.

Eigene Testszenarien entwerfen

Eine eigen entworfene E2E-Testung nimmt in Planung und Durchführung einige Zeit in Anspruch. Es sollten also rechtzeitig entsprechende Zeiträume dafür eingeplant werden. Es ist davon abzuraten einfach drauf los zu testen. Testungen müssen reproduzierbar sein. Damit wird sichergestellt, dass ein aufgetretener Fehler auch ein weiteres Mal unter bekannten Umständen provoziert werden kann. Die Reproduzierbarkeit wird mittels detaillierter und eindeutiger Dokumentation erreicht.

Bevor eine Testung durchgeführt werden kann, muss klar umrissen werden, welche Funktionen eigentlich geprüft werden sollen. Der Anspruch, alle möglichen Fehler aufzudecken, sollte aufgegeben werden. Der zeitliche und personelle Aufwand wäre einfach zu groß. Stattdessen sollten Schwerpunkte gesetzt werden. Nachfolgend ist bsph. aufgeführt, welche Fragen sich die Verantwortlichen im Vorfeld stellen könnten, um diese Schwerpunkte zu definieren.

  • Können sich die in der Testtaker-XML angelegten Testpersonen am Testcenter anmelden?
  • Können die angelegten Booklets gestartet werden?
  • Werden die vorgesehenen Aufgaben in festgelegter Reihenfolge dargestellt?
  • Funktioniert das Blättern zwischen den Aufgaben auf die gewünschte Weise?
  • Sind vorgesehene Bezeichner und Schaltflächen vorhanden?
  • Darf erst zur nächsten Aufgabe geblättert werden, wenn Pflichtfelder zuvor ausgefüllt wurden?
  • Wenn Zeitbeschränkungen eingerichtet sind, sind diese während der Testung aktiv und funktional?
  • Weisen Aufgabenelemente die gewünschten Funktionen auf, sprich können diese wie vorgesehen bedient werden?
  • Werden die gegebenen Antworten auch korrekt gespeichert?

Sind Schwerpunkte definiert, können weitere Überlegungen angestellt werden:

  • Welche Testdaten werden benötigt?
  • Auf welchen Endgeräten und mit welchen Browsern soll die Studie durchgeführt werden?
  • In welchem Stadium der Studienplanung können Testdaten repräsentativ eingesetzt werden?
  • Mit welcher Version der Anwendung soll die Studie durchgeführt werden und steht diese zum Testzeitpunkt in der eigenen IT-Infrastruktur zur Verfügung?
  • Wie soll getestet werden, manuell oder automatisiert?

Im nächsten Schritt können die gesetzten Schwerpunkte in Testfälle und detaillierte Testschritte umgewandelt und entsprechend dokumentiert werden.

Manuelles vs automatisiertes Testen

Sind die Testszenarien entworfen und festgehalten, muss im nächsten Schritt überlegt werden, wie getestet werden soll. Es kann manuell oder automatisiert getestet werden. Es kann an dieser Stelle keine pauschale Empfehlung gegeben werden welche Methode angewendet werden sollte, da es von vielen individuellen Faktoren abhängt. Beides hat Vor- und Nachteile. Nachfolgend wird eine kurze Gegenüberstellung aufgezeigt, die für die Entscheidung behilflich sein können.

Manuelles Testen

Vorteile

  • sinnvoll bei selten ausgeführten Testungen und kleineren Studien
  • relativ schnelle Entwurfsphase, meist reicht ein Handlungsskript zur Durchführung
  • Pflege und Aktualisierung sind relativ einfach, da nur Skripte angepasst werden müssen
  • keine zusätzliche Software oder Programmierkenntnisse notwendig

Nachteile

  • Ausführung dauert lange und es wird Personal benötigt, bei größeren Studie erhöht sich der zeitliche Aufwand entsprechend
  • Auswertung muss ebenfalls manuell erfolgen, das kostet Zeit
  • Skripte und Auswertungen lassen sich schlecht organisieren und personalisieren (In welchem Verzeichnis liegt welches Skript und welche Auswertung gibt es dazu?)
  • wenn oft ausgeführt, werden aus mangelnder Motivation gerne Abkürzungen genommen und damit eventuell entscheidende Stelle nicht wie im Skript vorgeschrieben geprüft
  • alle Browser und Endgeräte die getestet werden sollen, müssen physisch vorhanden sein
Tipp

Es sei an dieser Stelle erwähnt, dass es auch für das manuelle Testen Anbieter gibt, die die Organisation von Testskripten vereinfachen. Somit können viele Einzeldokumente bspw. mittels Word oder Excel vermieden werden. Hier sind einmal bspw. Testomat.io und Testbench genannt. Beide Anbieter bieten freie Zugänge an, die für kleinere Testungen ausreichend sind. Natürlich gibt es hier viele weitere Anbieter.

Automatisiertes Testen

Vorteile

  • sinnvoll bei häufig ausgeführten Testungen und größeren Studien
  • Ausführung ist schnell und homogen
  • gute Auswertungsmöglichkeiten, da automatisch Testergebnisse gespeichert werden
  • Verwaltung der Tests und zugehörige Auswertungen ist übersichtlich
  • zu testende Endgeräte müssen nicht zwingend physisch vorhanden sein, es kann schnell gegen emulierte Geräte getestet werden

Nachteile

  • Entwurfsphase benötigt Zeit
  • Pflege und Aktualisierung können je nach eingesetzter Software aufwändig werden
  • zusätzliche Software notwendig und je nach Einsatz Programmierkenntnisse im kleineren Umfang notwendig

Ist eine Entscheidung für das automatisierte Testen gefallen, kann das IQB nachfolgend Software vorstellen, die für den Testentwurf und zur Testdurchführung genutzt werden könnten. Der Markt für Software zum automatisierten E2E-Testen ist riesig und jeder Anbieter hat Vor- und Nachteile. Da das IQB bereits den Großteil seiner Testszenarien automatisiert hat, wollen wir an dieser Stelle gerne das Werkzeug Cypress zur Integration von E2E-Tests empfehlen. Es ist schnell einsatzbereit und unkompliziert zu bedienen. Die Testschritte können in JavaScript oder TypeScript geschrieben werden.

Hier ein kleines Beispiel, wie ein sehr einfacher Test mit Cypress aussehen könnte:

//Testfall Beispiel
describe('Check Google', () => {

    //1.Testschritt: Prüfe ob Google geladen werden kann
    it('Öffne Google', () => {
        //Öffne Seite
        cy.visit(`www.google.com`);
        //Erwartungsauswertung: Konnte Seite geladen werden, 
        //dann sollte sie "Google" enthalten
        cy.contains('Google')
            .should('exist');
    });

    //2.Testschritt: Tue noch etwas auf der Google Seite
    it('Öffne Google', () => {
        
        //Tue etwas....
    });
});

E2E-Tests des IQB verwenden

Wie eingangs erwähnt, sind in der Anwendung bereits automatisierte Cypress E2E-Testfälle enthalten. Hier soll nun näher beschrieben werden, wie diese genutzt werden können.

Hinweis

Die nachfolgenden Beschreibungen beziehen sich auf das Betriebssystem Linux. Für Windows kann hinsichtlich der Funktionalität der nachfolgend genannten Schritte keine Aussage getroffen werden.

Vorbereitungen

  • Entwicklungsumgebung (IDE): Um die Bestandteile der Anwendung adäquat verwenden und sichten zu können, wird eine IDE benötigt. Hier genannt sei bspw. MS-Visual Studio Code.
  • Node.js: Zur Installation von Cypress wird der Node Package Manager (npm) verwendet.
  • Git: Wird zum Duplizieren des Testcenter Repositories benötigt.
  • Cypress in Version 13.3.3: Hinweise zur Installation sind hier zu finden.

Cypress starten

  1. Starten der IDE
  2. Spiegeln (clonen) des Testcenter GitHub-Repos
  3. Öffnen des gespiegelten Ordners mit der IDE
  4. Terminal öffnen und den Befehl: make test-system eingeben (es dürfen keine Fehler angezeigt werden), wenn erfolgreich ausgeführt, öffnet sich die Cypress Oberfläche
  5. “E2E Testing” in der Cypress Oberfläche auswählen
  6. TestBrowser auswählen

Cypress Tests ausführen

Nachdem die vorherigen Schritte abgeschlossen sind, ist eine Liste aller bereits angelegten Testfälle zu sehen. Da die Anwendung Testcenter vor jeder Veröffentlichung vom IQB getestet wird, sind für Endnutzer*innen nicht alle Testfälle interessant. Es sind ehr Testfälle interessant, die Funktionen testen, die direkt mit der Studiendurchführung zu tun haben. Hier wäre als klassisches Beispiel die bedingte Navigation (responses/ presentation complete) zu nennen. Nachfolgend werden die Testfälle aufgezeigt, die von Endnutzer*innen für ihre Konfiguration der Testdateien genutzt werden könnten.

Hinweis

Einige Testfälle sind gruppiert in Ordner.

Session-Management/hot-restart-mode und Session-Management/hot-return-mode

Hier werden die Grundfunktionen der Modi: hot-restart und hot-return getestet. In diesem Fall, ob Antworten und Logs gespeichert werden und ob sich die Modi bzgl. Anmeldung so verhalten, wie vorgesehen:

  • hot-restart: Bei erneuter Anmeldung wird eine neue Person angenommen und der Test wird neu gestartet
  • hot-return: Bei erneuter Anmeldung wird die selbe Testperson angenommen und der Test wird fortgesetzt

Session-Management/time-restrictions

Es wird die Funktion zeitlicher Beschränkungen in Testheftblöcken getestet.

Test-Controller/RunHotRestart und Test-Controller/RunHotReturn

Es werden alle hier gelisteten Funktionen der beide Modi getestet (ausgenommen der bereits im Session-Management getesteten Funktionen).

Hinweis

Die Testschritte sind so geschrieben, dass relativ einfach herauszulesen ist was diese Schritte tun, also was damit getestet wird.

Wo ist der Testcode zu finden?

Der Testcode ist im Projektverzeichnis: /e2e/cypress/e2e zu finden. Die Struktur der Testfälle ist dann genau so zu sehen wie in der Cypress-Oberfläche. Der Testcode kann hier bei Bedarf erweitert oder angepasst werden und ist dann direkt in der Cypress-Oberfläche ausführbar. Falls andere Beispielaufgaben eingebunden werden sollen, sind diese unter: /sampledata/system-test zu hinterlegen. Anschließend müssen sie in der Klasse: WorkspaceInitializer.class.php eingetragen werden. Es empfiehlt sich daraufhin das laufende Test-System noch einmal zu stoppen und erneut zu starten mit make test-system. Hierbei werden die neuen Daten der Datenbank hinzugefügt.

Zurück nach oben