© 2019 Pixabay

Im Namen der Qualität – check, re-check, double-check

Was nützt die beste Idee, wenn sie dem ersten Praxistest nicht standhält? Nichts, finden wir. Statt also sehr viel Zeit und Energie in Luftschlösser zu stecken, die beim ersten Betreten in sich zusammenfallen, sichern wir die Qualität unserer Produkte lieber schon während des Entwicklungsprozesses. So können wir garantieren, dass am Ende des Verfahrens statt heißer Luft ein vollfertiges Produkt steht, bereit, genützt zu werden.

Die Zufriedenheit unserer Kunden und die Qualität unserer Produkte stehen bei der eguana-Unternehmensphilosophie ganz vorne. Deshalb wenden wir für diese Prozesse viele Ressourcen auf. Aus diesem Grund widmen wir den heutigen Blogbeitrag der Qualitätssicherung und Performance Optimization mit besonderem Fokus auf das automatisierte Testen als eine der wesentlichsten Komponenten.

Das Problem

Unser Entwicklungsteam arbeitet mit einem Agilen Ansatz – kurze Entwicklungszyklen stellen ein zeitsparendes Prototyping der Kundenanforderungen sicher. So erhalten wir schon nach kürzester Zeit ein Feedback zur Eignung des Produktes. Der Vorteil für den Kunden besteht darin, dass neue Features und Funktionen im Vergleich zu traditionellen Entwicklungszyklen in relativ kurzer Zeit hinzugefügt werden können (Wir sprechen hier von Wochen vs. Monaten).

Der Nachteil ist der, dass herkömmliche Teststrategien für diesen Ansatz nicht gut geeignet sind.  Die kurze Zeit zwischen den Iterationen lässt keinen klassischen Testaufbau zu, da neue Funktionen zu Problemen in bereits existierenden Teilen der Anwendung führen können.

Bei eguana haben wir den Anspruch, unseren Kunden so rasch wie möglich qualitativ hochwertige Lösungen zu liefern. Um diesem Anspruch gerecht zu werden, musste das Testvorgehen neuer Software an den agilen Entwicklungsprozess angepasst werden.

Die Lösung

Auf der Suche nach alternativen Testverfahren sind wir auf das „automatisierte Testen“ gestoßen. Diesen Ansatz verwenden wir, um schnelle Innovationen zu garantieren und das Fehlerpotenzial unserer SCALES-Anwendung zu reduzieren.

Das Hauptziel der Testautomatisierung ist es, automatisch bestimmte repräsentative Aspekte der Software zu kontrollieren, je nachdem wie es vom Entwicklerteam festlegt wird. Die Idee ist es, einen repräsentativen Satz von Navigationspfaden durch die Benutzeroberfläche auszuwählen und diesen automatisch abzuarbeiten, so wie es ein menschlicher Benutzer tun würde; Sämtliche auftretenden Fehler oder Probleme werden von der automatisierten Testanwendung dem Entwicklerteam gemeldet, sodass die Ursachen von Problemen leicht lokalisiert werden können.

So können Fehler, die durch Veränderungen im System herbeigeführt werden, schneller identifiziert werden. Das verkürzt wiederum die Zeitspanne zwischen vom Kunden initiierten Änderungsanfragen und der Einführung neuer Funktionen in das Produktionssystem. Natürlich wird das automatisierte Testverfahren durch ausführliche, manuelle Tests des Entwicklerteams ergänzt, da nicht alle Aspekte automatisiert werden können oder sollen.

Der Ablauf

Um das Testverfahren zu automatisieren, hat das eguana Entwicklerteam eine Testanwendung implementiert, die in der SCALES-Benutzeroberfläche dieselben Aktionen wie ein menschlicher Benutzer durchführt; das Klicken bestimmter Knöpfe, das Einfügen entsprechender Eingaben, etc. Das Tool führt mehrere Testfälle durch; in jedem Testfall werden einfache Aktionen wie Klicken und Tippen verwendet, um die Benutzeroberfläche zu bestimmten Download-Seiten zu navigieren.  Anschließend werden beispielsweise Berichte mit speziellen Parametern heruntergeladen und mit gespeicherten Steuerungsversuchen verglichen, um Abweichungen zu identifizieren.

Die Ausgabe des Testwerkzeugs beschreibt Probleme innerhalb der Navigation („Drücken der Taste <OK> auf Seite X verursacht einen Fehler“) sowie Unterschiede zwischen dem Testbericht (der Version eines bestimmten Berichts, die während des Tests heruntergeladen wurde) und dem Kontrollbericht (einer hinterlegten, verifizierten Version desselben Berichts). Die Veränderung eines zugrundeliegenden Algorithmus‘ kann beispielsweise dazu führen, dass der Testbericht einen Volumenwert von 15,7 Litern angibt, während laut der Kontrollversion der Volumenwert 13,5 Liter betragen sollte. Ein weiteres Beispiel wäre die Erstellung eines Testberichts mit deutscher Interpunktion, wodurch fälschlicherweise Punkte statt Kommas für Dezimalstellen verwendet würden.

Die Berichte werden mithilfe unterschiedlicher Techniken verglichen:

CSV-Dateien können direkt anhand ihres Inhalts verglichen werden, da sie bereits in einem für Textvergleichsprogramme verständlichen Format vorliegen. Bei Unterschieden kann das Programm feststellen, in welcher Zeile der Datei sie vorkommen, und das Entwicklerteam entsprechend benachrichtigen.

Bei PDF-Dateien wie  Injektions-, Bohr- oder DSV-Protokollen, Tagesprotokollen, Ortsprotokollen oder Leistungsverzeichnissen ist es etwas komplizierter. Die Dateien werden zunächst in Bilder konvertiert, anschließend werden Testversion und Kontrollversion Seite für Seite, Pixel für Pixel, miteinander verglichen. Falls es Unterschiede zwischen den beiden Versionen gibt, wird eine Differenzbilddatei erstellt. Elemente, die nur in einer der beiden Version vorkommen, aber nicht in der anderen, werden in der Differenzbilddatei rot hervorgehoben (siehe Abbildung 1).

Abbildung einer Differenzbilddatei - Fehler sind rot markiert

(Abbildung 1: Differenzbilddatei)

Das automatisierte Testwerkzeug ist sozusagen die „erste Abwehrlinie“, bevor die Software auf den Entwicklungs- und Produktionsservern bereitgestellt wird. Wenn eine neue Version der SCALES-Software bereit für den Einsatz ist, wird das Testwerkzeug verwendet, um den definierten Testfall zu überprüfen. Offensichtliche Probleme werden rasch erkannt und können somit schneller als mit klassischen Methoden vom Entwicklungsteam gelöst werden.  Wenn das automatisierte Testverfahren keine groben, offensichtlichen Fehler feststellt, finden noch abschließende manuelle Tests statt. Schlussendlich, wenn beide Testverfahren beendet sind, werden die neuen SCALES-Funktionen dem Kunden auf dem Produktionsserver zur Verfügung gestellt, was eine rasche Lieferung eines qualitativ hochwertigen Produktes ermöglicht.

Und wenn zum Schluss unsere Kunden glücklich sind, sind wir es auch!

 

Um Mahatma Gandhi zu zitieren (ausgerechnet Gandhi, wer hätte das gedacht…):

„Der Kunde ist der wichtigste Besucher in unserem Hause.“

Recht hat er.

 

Beitragsbild:  © 2019 Pixabay

 

Anna Riedler

Als der Orientierungssinn vergeben wurde, hatte sich Anna gerade verlaufen. Umso besser, dass ihre Arbeit mit Baustellen nur peripher zu tun hat – sie würde vermutlich nie wieder zurück ins Büro finden. Stattdessen schreibt die studierte Journalistin fleißig Texte für unsere Homepage, unseren Blog, und literaturnobelpreisverdächtige Kurzbeschreibungen.