Rückblende – vor 27 Jahren
1995 steckte die Qualitätssicherung tatsächlich noch in den Kinderschuhen. Wir hatten keine eigene Abteilung dafür. Das Release-Prozedere war nicht festgelegt, es gab keine automatisierten Tests. Das Produkt war da auch gerade erst ein paar Jahre alt, combit war deutlich kleiner als heute – es war schlicht eine andere Zeit. Ich erinnere mich noch gut daran, dass wir bei Version 5 schließlich bei Unterversion 64 gelandet waren, d.h. es gab 64 Zwischenreleases, alle paar Tage ein neues. Das Changelog war nicht öffentlich, sodass niemand wusste, was wir geändert haben. Das war – so muss man es aus heutiger Sicht sagen – eine wirklich üble Gemengelage. Uns war klar, so kann es nicht weitergehen.
Daher haben wir uns recht rasch professionalisiert. Ich habe zuletzt vor ca. 2 Jahren unsere Vorgehensweise dazu dokumentiert. Seitdem haben wir aber weiter an unserer Qualität gearbeitet. Es ist Zeit für ein Update.
combit Qualitätssicherung 2022
Die Qualitätssicherung ist mittlerweile eine eigene Abteilung, die von meinem Kollegen Daniel Kenner geleitet wird. Alle Prozesse sind standardisiert und in detaillierten Ablaufplänen (Checklisten) festgehalten. Der gesamte Buildprozess inklusive aller automatisierten Tests läuft jede Nacht vollautomatisch, sodass jeden Morgen ein frisches Setup inklusive aller getesteten Module zur Verfügung steht.
Nachfolgend eine kleine Übersicht, welche vielfältigen Tests List & Label jede Nacht bzw. vor einem Release durchlaufen muss.
Statische Codeanalyse
Schon beim Coden versuchen wir, Fehler soweit wie möglich auszuschließen. Je früher im Prozess ein Fehler gefunden wird, desto einfacher (und billiger) ist es, ihn zu beseitigen. Neben den gängigen Analyzer-Bibliotheken von Microsoft verwenden wir Sonarqube für die statische Codeanalyse. Hier ein Einblick in eine aktuelle Analyse des .NET-Codes von List & Label:
Mit Sonarqube decken wir sowohl unseren .NET-Code als auch den TypeScript-Code unserer Webkomponenten ab.
Tests der Webkomponenten
Darüber hinaus werden unsere Webkomponenten – der Web Report Designer und Web Report Viewer – einem gründlichen Test durch Cypress unterworfen. Diese Bibliothek erlaubt es, nahezu alle Frontend- und Backendfunktionalitäten mit Tests abzudecken.
Hierbei werden aktuell 90 verschiedene Testeinheiten ausgewertet, welche wiederum aus bis zu 20 Assertions bestehen.
Unit-Tests der .NET-Komponente mit NUnit
Auf Codeebene werden eine Reihe von Unittests durchgeführt. Wir verwenden hierfür NUnit. Die Tests werden bei jedem Build auf unserem TeamCity-Buildserver automatisch ausgeführt und testen über diverse Assertions das Verhalten der .NET-Programmierschnittstelle:
Die Liste geht natürlich weiter. Bei jeder Abweichung wird der Build als ungültig gekennzeichnet und so auch verhindert, dass die Module z.B. über unseren Support bei Ihnen landen können. Hier wie auch bei allen anderen im folgenden beschriebenen Tests gilt: kein Modul, das nicht alle Tests erfolgreich durchlaufen hat, darf an Kunden weitergegeben werden.
Automatisierte Drucktests
Die Liste der Tests hatte ich ja in meinem oben angelinkten Artikel schon aufgeführt. Inzwischen haben wir noch deutlich mehr Tests. Diese decken sowohl die Druckengine als auch die PDF-Generierung als unser wichtigstes Exportformat ab. Insgesamt werden bei jedem Build aktuell 1236 Druckausgaben erzeugt und mit hinterlegten Referenzen verglichen. Diese Zahl nimmt ständig zu, da wir bei jedem neu entdeckten Fehler einen weiteren Test hinzufügen, der eine Regression genau dieses Problems für die Zukunft ausschließt.
Für die automatisierten Vergleiche nutzen wir je nach Zielformat unterschiedliche Tools: PDF-Dateien werden mit DiffPDF, einem kommerziellen Tool, verglichen. Für die Vorschaudateien nutzen wir unser eigenes Vergleichstool, das „versteckt“ in unseren DLLs integriert ist. Über eine API können wir damit zwei LL-Dateien auf Vektorebene miteinander vergleichen. So entgeht uns auch nicht die kleinste Veränderung. Sobald sich eine beliebige Ausgabe auch nur um 1/1000 mm verschiebt, würden wir dies sofort bemerken. Das kann von Zeit zu Zeit natürlich „normal“ sein, z.B. wenn wir eine neue PDF-Bibliothek einspielen und dort das Rendering minimal angepasst wird. Hier werden die fehlgeschlagenen Tests dann manuell betrachtet, bewertet und ggf. freigegeben.
Ein (leider) ganz aktuelles Beispiel für diese Vorgehensweise: wir hatten für Version 28 die Rendering-Bibliothek für SVG-Dateien auf den neuesten Stand gebracht. Dabei wurde ohne weiteren Hinweis in den Releasenotes der Rückgabewert einer Funktion geändert, sodass die Größenbestimmung für SVG-Dateien falsche Ergebnisse liefert, was sich insbesondere bei stark rechteckigen SVGs deutlich zeigt, sie werden zu klein dargestellt. Ein Kunde wies uns im Forum auf das Problem hin. Selbstverständlich hatten wir die SVG-Ausgabe über eine Reihe von Tests abgedeckt. Ein mehrseitiger Test verwendet einige Dutzend Test-SVGs des W3C, die alle erdenklichen SVG-Features abdecken, die wir unterstützen. Allerdings gab es mit den Tests ein Problem:
Fast alle Bilder sind quadratisch – genau in dieser Konstellation war der Fehler nicht wirklich zu sehen. Links sind die fehlerhaften, rechts die korrigierten Bilder. Mittlerweile gibt es natürlich auch Tests mit rechteckigen SVGs. Die kommen für diesen Fall aber zu spät. So konnten wir nur so schnell wie möglich reagieren und dem Kunden 37 Minuten nach der Problemmeldung eine neue DLL mit einem Fix zusenden.
Automatisierte UI-Tests
Auch die Benutzeroberfläche wird ständig getestet, Hierfür verwenden wir Ranorex, ein weiteres kommerzielles Tool. Über dieses führen wir jede Nacht die komplette Freigabecheckliste für den Designer durch, die bei einem Service Pack zusätzlich auch manuell getestet wird. Darin enthalten ist das Einfügen, Bearbeiten und Löschen verschiedenster Objekttypen, die Ausgabe auf die unterschiedlichsten Exportformate, ein Test der Eigenschaftseditoren, der Hotspot-Funktionalität von Chart und Kreuztabelle usw. Der folgende Screenshot gibt einen guten Eindruck, wie Ranorex in Zusammenarbeit mit TeamCity arbeitet:
Ein voller Testlauf dauert hier aktuell ca. 30 Minuten, was für eine automatisch klickende Engine eine Ewigkeit ist und die Tiefe der abgedeckten Funktionalität zeigt. Auch hier gilt: Kein Modul, das nicht alle Tests besteht, wird an Kunden ausgeliefert.
Manuelle Whitebox- und Blackbox-Tests
Natürlich arbeiten bei combit nicht nur Maschinen, sondern auch echte QA-Profis, die bei manuellen Tests versuchen, auf alle erdenklichen (und auch mal absurden) Ideen zu kommen, um das Feature „kaputt zu machen“. Dies ist ein wesentlicher Teil des Prozesses, den ein Feature durchlaufen muss, bis es eine Release-Freigabe erhält. Vor jedem Service Pack Release werden zudem die wichtigsten Programmteile, zusätzlich zu den o.g. automatisierten Tests, nach detaillierten Testplänen manuell nachgetestet.
Fazit
Wir sind seit 1995 einen weiten Weg gegangen und haben uns auf allen Ebenen professionalisiert. Hätte ich damals selber noch ein Jahr gewartet, bevor ich eine neue Version eingespielt hätte, bin ich mittlerweile überzeugt, dass wir jederzeit die bestmögliche Qualität ausliefern können. Das früher übliche „ich warte mal bis zum zehnten Service Pack“ würde überhaupt nicht mehr funktionieren. In aller Regel geben wir nur noch ein Service Pack pro Quartal frei. Und die gefundenen Fehler werden immer exotischer, wenn sie auch nicht aufhören aufzutauchen. Aber das kennen Sie vermutlich aus Ihrer eigenen Software ebenso. Ich würde mich freuen, wenn hier Ideen für Sie enthalten wären, Ihre eigene QS noch breiter aufzustellen. Und wenn Sie im Gegenzug noch Vorschläge haben, was wir noch umsetzen sollten, freue ich mich über Ihre Kommentare dazu.
Jochen Bartlau leitet als Geschäftsführer die Softwareentwicklung bei combit. Microsoft .NET und Agiles Projektmanagement sind zwei seiner Steckenpferde. Der technikbegeisterte Physiker und Vanlife-Enthusiast verbringt seine Freizeit am liebsten beim Wandern.
