Bei typischen Batch-Programmen handelt es sich in der Regel um umfangreiche, unternehmenskritische Anwendungsfunktionen, die in vordefinierte Batch-Prozesse eingebettet sind. Bei ihnen treten mitunter komplexe Fehler auf, die in der Datenbank-schicht verborgen sind. Diese Verkapselung führt dazu, dass sich derartige Probleme erst in außergewöhnlich langen Debug-Zyklen finden lassen. Eine weitere Heraus-forderung ergibt sich bei der Anonymisierung von Testdaten, um die Vorgaben durch die Europäische Datenschutzgrundverordnung (EU-DSGVO, englisch: GDPR) und andere Compliance-Anforderungen zu erfüllen.

Typische Testprobleme im Bereich der Spool-Dateien, der Datenbank und der Batch-Verarbeitung können wie folgt klassifiziert werden:

  • Eine Batch-Ausführung muss händisch erstellt werden, da ein recht komplexer Datenbank-Code zu schreiben war. Denn nur durch dieses Skripting lässt sich überprüfen, ob nach Abschluss der Batch-Prozesse die richtigen Tabellen in der Testdatenbank korrekt aktualisiert wurden.
  • Es muss sichergestellt werden, dass die Anwendungsfunktionalität gleichbleibt, auch wenn Änderungen am Code vorgenommen werden, der mit Spool- und Datenbank-Komponenten interagiert. Dazu müssen die Programmierer in der Lage sein, komplexe Funktionen, die diese Komponenten betreffen, zu verstehen, zu debuggen, zu korrigieren und sie dann erneut zu testen.
  • Erstellung eines anwendungsspezifischen Test-Frameworks mit zusätzlichen Herausforderungen. Dazu zählen das manuelle Erstellen einer Fehlerberichtsfunktionalität sowie die Aktualisierung der Testdaten mit dem damit verbundenen Risiko, dass die Funktionalität des Test-Frameworks komplexer wird als der Anwendungscode selbst.
  • Bei der Erstellung von Fehlerbehandlungsfunktionen besteht zudem das Risiko, dass sie zu viele zusätzliche Fehler anzeigen (von denen einige zu Fehlern im Test-Framework selbst führen können) und dann noch mehr Arbeit für Entwickler bei der Behebung nach sich ziehen.
  • Generell führen all diese Risiken dazu, dass ein Entwickler viel Zeit damit verbringt, End-to-End-Tests mit der dazugehörigen Dokumentation zu erstellen. Wobei eine einfache „Aufzeichnung“ darüber, wie die Benutzer die Anwendung „tatsächlich“ nutzen, eine echte und aktuelle Sicht auf den End-to-End-Test ergeben würde.

Generell ist es aus Compliance-Gründen wichtig, dass man eines zeigen kann: Alle Anwendungsfunktionen, die sich in der letzten Iteration geändert haben, sind vollständig getestet worden und eine 100-prozentige Abdeckung für sämtliche Code-Modifikationen wurde erreicht. Dabei wird es für die Programmierer immer wichtiger, dass sie die Funktionalität des Rational Developer for i (RDi) IDE nutzen können. Denn nur so lässt sich eine Beschleunigung des DevOps-Zyklus und eine schnelle Einführung von neuen Anwendungsversionen erreichen. Diese Herausforderungen können mit der Lösung ARCAD-Verifier Test Automation nahtlos und vor allem ohne Programmieraufwand bewältigt werden.

Die Grenzen des Funktionstests

Die meisten Unternehmen führen Funktionstests ihrer Anwendungen, die aus Compliance-Gründen erforderlich sind, über die Benutzeroberfläche durch. Da jedoch jeder einzelne Fehler aus der Benutzeroberfläche diagnostiziert werden muss, bringt dieser Ansatz wenig Informationen, die Entwicklern helfen, Probleme tatsächlich zu beheben. Das Ergebnis ist in der Regel ein konstanter Strom von Fehlern, die folgende Klassifizierung zugesprochen bekommen:

  • Das Problem lässt sich nicht reproduzieren.
  • Die Testumgebung ist nicht korrekt eingerichtet.
  • Es sind zusätzliche Informationen nötig.

Jeder dieser Fehler erweist sich als besonders komplex bei Batch-Prozessen und Statusabfragen in der Testumgebung.

Wenn die Informationen für die Entwickler nicht ausreichen, wird die Problembehebung auf später verschoben und Projekte verzögern sich, da das Codeverständnis nur mit viel Zeitaufwand herzustellen ist. Das führt dann auch zu einem nicht optimalen Debugging-Ansatz. Dies schränkt die Möglichkeiten für jedes IBM i-Entwicklungsteam stark ein, die „Liefergeschwindigkeit“ aufrechtzuerhalten, die zur Erreichung der DevOps-Ziele erforderlich ist.

DevOps erfordert Build Verification Testing (BVT)

Um sicherzustellen, dass eine „testbare“ Anwendung von der Entwicklung an das Qualitätssicherungsteam in schnellen Iterationsstufen übergeben wird, erstellen viele Unternehmen eine Reihe von „Build Verification Tests“ (BVT). Dieser Prozess gilt als ein Schlüssel, um sicherzustellen, dass Defektverfolgungssysteme nicht mit Aussagen wie „Testumgebung nicht verfügbar“ oder „falsche Daten in Testumgebung“ gefüllt werden.

Bei einem Smoke Testing (Rauchtest) handelt es sich um eine Art Probelauf nach einer Reparatur oder nach der ersten Implementierung eines neuen Algorithmus. Er soll sicherstellen, dass das Gerät oder die Programmfunktion nicht schon im Ansatz fehlschlägt. Somit decken diese „Rauchversuche“ die meisten der wichtigsten Funktionen der Software ab, aber keine davon ist ausführlich genug. Denn das Ergebnis dieses Tests wird lediglich dazu verwendet, um zu entscheiden, ob mit weiteren Tests fortgefahren werden soll. Wenn der Rauchtest bestanden ist, fahren die Prüfer mit weiteren Tests fort. Wenn der Rauchtest fehlschlägt, stoppen sie weitere Tests und fragen nach einem neuen Build mit den erforderlichen Korrekturen bei den Entwicklern nach. Wenn eine Anwendung viele und eklatante Fehler aufweist, können detaillierte Tests eine Verschwendung von Zeit und Mühe sein.

Testaufgaben auf Batch- und Datenbankebene konzentrieren

Generell empfehlen Spezialisten, dass man sich bei Testaufgaben auf die Batch- und Datenbankebene konzentrieren sollte. Denn die Fehler in Batch-Läufen und Datenbanken sind am schwersten zu finden, sind am kostspieligsten und am riskantesten in die Live-Produktion zu übertragen, ohne dass man End-to-End-Tests ausführt.

Zudem sind Batch-Prozesse per Definition risikoreich und typischerweise ein Höhepunkt einer Reihe von Transaktionen, die in einem Unternehmen zu einer hohen Wertschöpfung führen und ein hohes Wirkungspotenzial haben. Die manuelle Nachbearbeitung von Batch-Prozessen in der Produktion ist in der Regel am schwierigsten und teuersten.