Qualitätssicherung
Die Entwicklung unserer Software erfolgt mit einer Mischung aus Scrum und Rational Team Concert (IBM) als methodisches und strukturiertes Vorgehen. Das koordinierte Arbeiten der Mitarbeiter wird durch das Projektmanagement über unser Issue-Tracking-System (Mantis) und die Source-Verwaltung mit Git ermöglicht. Beides ist in der gemeinsamen Entwicklungsumgebung Eclipse integriert. Unser effizientes und agiles Entwicklungsmodell erzwingt Regression-Tests der Software (Continuous Integration) bei jedem Build (viele kleine Tests) und nach dem Push von Änderungen ins zentrale Repository (alle mittelgroßen Tests). Zusätzlich gibt es Nightly Builds, für die jede Nacht Tests mit längerer Laufzeit automatisiert ausgeführt werden. Dadurch können frühzeitig Fehler und Inkompatibilitäten zu älteren Versionen über alle Platformen hinweg erkannt, behoben und somit Fehlentwicklungen verhindert werden.
Die Qualitätssicherung unserer Software wird durch folgende Werkzeuge unterstützt:
- Statische Codeanalyse mit Cppcheck und scan-build (Clang)
- Dynamische Codeanalyse über Valgrind unter Linux und dem HEAPCHK auf der Host
- Selbst entwickeltes Heap-Speicher Monitoring zur Erkennung von Pufferüberläufen, Double Frees und ähnlichen Problemen
- Selbst entwickeltes Test-Framework für alle Platformen, über das einfach, schnell und effektiv Funktions-, Modul-, Komponenten- und Regression-Tests entwickelt und gewartet werden können.
- Code Coverage Analyse mit Coco von Froglogic als integraler Bestandteil unseres Testframeworks
- Die graphischen Oberflächen unter Unix und Windows werden mit Squish von Froglogic automatisiert im Framework getestet.
- Für die ISPF Panels unter z/OS nutzen wir x3270 mit Phyton-Scripts (py3270) welche wir als Hosttest remote über die FLCL auf einen zentralen Linux-Server starten.
Unser Test-Framework (FLTF) planen wir zu einem eigenen Open Source Produkt analog zum CLEP auszubauen. Mittels C-Code lassen sich schnell und einfach komplexe Massentests abbilden, um einen hohen Testabdeckungsgrad mit wenigen Zeilen Code zu erzeugen. Man kann sehr einfach Regressiontests für die Kundenschnittstellen und Unittests für die einzelnen Komponenten schreiben. Die Tests lassen sich vollautomatisiert ausführen. Alle Testergebnisse werden in HTML-Dateien zusammengefasst, sodass man alle Tests auf allen Plattformen für jeden Entwickler und im Rahmen der Automation im Intranet einsehen kann. Wenn alle Tests erfolgreich waren, stellt das FLTF einen Button für die Veröffentlichung zur Verfügung.
Jeder Entwickler muss vor dem Einchecken von neuem Code diesen für Linux, Windows, USS und z/OS bauen und alle Build-Regressiontests erfolgreich bestehen. Nach dem Einchecken ins zentrale Git-Repository werden weitere Tests ausgeführt. Wird ein Problem erkannt, erhält der betreffende Entwickler eine E-Mail und seine Änderungen werden nicht mit dem Hauptentwicklungszweig zusammengeführt bis das Problem behoben wurde.
Zusätzlich führen wir Cross-Platform Tests durch, um die Interoperabilität zwischen den Plattformen sicherzustellen. Das bedeutet, dass z.B. auf einem Linux System erzeugter Output auf einem z/OS System auf korrekte Lesbarkeit getestet wird und umgekehrt, aber auch, dass kryptographische Hardware – wie PKCS#11-Tokens und IBM-CCA-Devices – mit unseren Software-Implementierungen der Crypto-Algorithmen zusammenarbeiten muss. Bei Standard-Datenformaten wird außerdem die Interoperabilität mit Standard-Tools getestet, z.B. GnuPG, gzip, 7-Zip.
Zusätzlich zur Versionsnummer, die jede FLAM-Auslieferung hat, ist auch jede einzelne Komponente mit einer eigenen Versionsnummer versehen. In Support-Fällen hilft uns dies den genauen Software-Stand der Kunden-Installation festzustellen und so zeitnah Hilfe anzubieten. Außerdem lassen sich inkonsistente Installationen leichter erkennen.