In der Entwicklung von Testautomatisierungstestsuiten mit QF-Test für Kassensoftware (POS – Point of Sale; in der Branche: Handel / Einzelhandel) steht man immer auch vor der Frage, wie wichtig sind eigentlich die sogenannten Poslogs und auch, ob und wann man diese im Entwicklungszeitplan der Testsuiten einplant?
Zuerst die Definition, was mit Poslogs genau gemeint ist: Poslogs stellen das Bindeglied der einzelnen Transaktionen (ein Verkauf) vor Ort, z.B. an einer Kasse und der Meldung dieser Umsatzbewegungen hin auf die zentralen Server bzw. der Import dieser Verkaufszahlen (Anzahl, Umsatz etc.) z. B. in SAP. Poslogs sind Datencontainer im XML-Format. Die Wichtigkeit dieser Datencontainer, also der Poslogs, sollte selbsterklärend sein: An einer Kasse werden Verkäufe generiert, diese Umsatzzahlen sind dann auch die Informationen (Daten: z.B. Umsätze, Abverkäufe usw.) die ein Filialist zwingend benötigt, um z.B. Aktionen u.a. bewerten zu können. Diese Datencontainer bilden im Grunde das “Rückgrat” des Geschäfts. Der Einzelhandel ist längst nicht mehr in der früheren manuellen Welt zu Hause. Umsatzzahlen wurden, als Kassen noch reine lokale “Taschenrechner” waren, händisch pro Filiale per Telefon oder Fax in die Zentralen gesendet. Ohne Poslogs geht heute schlicht gar nichts mehr im digitalen Einzelhandel. Viele Filialisten stellen längst auch auf untertägige Umsatzauswertungen um.
In mehreren Projekten hat sich für mich folgendes strategisches Vorgehen als Vorteilhaft herausgestellt:
Die benötigten Prozesse der Poslogprüfungen sollten direkt mit dem ersten Testall, der an einer Kasse läuft, eingeplant werden in QF-Test. Es sollte eine Standardregel sein: Ohne die Poslogprozesse wird kein einziger Testfall umgesetzt. Wie man hier praktisch vorgehen sollte, beschreibe ich weiter unten. Poslogprüfungen haben mehrere Testdimensionen, die es zu beachten gilt. Der offensichtliche Benefit von Poslogprüfungen ist natürlich das “Überwachen” der XML-Strukturen, die Prüfung der Inhalte, z.B. Artikeltexte, Preise, Mengen, Mwst-Schlüssel, Warengruppenangaben, wie wurde jeder Artikel innerhalb der Transaktion erfasst, also ob durch manuelle Eingabe z.B. der Artikelnummer oder eben durch das Scannen der EAN (GTIN) etc., darüber hinaus gibt es noch viele andere wichtige Einzeldaten. In typischen Automatisierungsprojekten im Einzelhandel, und deren bedingte Testfälle, kommt man hier auf rund 40 wichtige Einzeldaten pro Poslog. Jeder einzelne Datensatz für sich stellt so auch einen Einzeltesterfolg des Testfalls dar. Die 40 Einzeltesterfolge pro Poslog sind ein konservativ gerundeter Durchschnittswert. Die tatsächlichen Zahlen pro Poslog dürften sogar noch darüber liegen, würde man sie in einer Gesamttestphase tatsächlich einzeln zählen. Automatisiert man eine Kassensoftware hat man triviale, mitteltriviale und auch komplexe Testfälle. Die trivialen Testfälle kommen nicht ganz auf die 40 Einzeltestpunkte, die mittleren aber sicher und die komplexen überschreiten das bei weitem. Im Durchschnitt ergibt es eben die rund 40 Einzeltestpunkte.
Als ungefähre “Hausnummer” kann ich folgendes sagen, wenn es darum geht, wie viele Testfälle man am Ende eines Projekts umgesetzt hat: In Deutschland gibt es einen “Big-Player” Softwarehersteller für Kassensoftware. In diesem Bereich habe ich jetzt schon mehrere Automatisierungsprojekte erfolgreich umgesetzt (von A bis Z). Ungefähr bei 1000 Testfällen pro Land kann man sich sicher sein, dass man die Software z.B. in Release-Zyklen bzgl. Fehlern / Problemen etc. mit der QF-Testautomatisierung in den Griff bekommen kann. Ist bei einem Releasetest die QF-Testphase fehlerfrei, dann wird man auch keine großen Themen mehr haben und kann durchaus den Rollout der Versionen planen. Natürlich muss die manuelle Testphase ebenfalls erfolgreich sein. Gehen wir jetzt von den 1000 Testfällen (ein Tesfall = ein Poslog ist hier gemeint!) aus, dann ergibt sich durch 1000 mal 40 gleich 40.000. Es sind pro Land, durch die zusätzlichen Poslogprüfungen, also mal “eben” 40k weitere Einzeltestpunkte automatisiert und reproduzierbar unte Kontrolle gebracht worden. Filialisten, zumindest die großen, so kenne ich das, sind aber häufig international aufgestellt. In Testphase hat man da gerne und schnell 10-20 Länder zu betrachten, d.h. wir haben in einer kompletten automatisierten Release-Testphase 400k bis 800k Einzeltestpunkte erreicht. Hier stellt sich gar nicht mehr die Frage, ob man Poslogs auch automatisiert prüfen sollte. Der “GAU” (Größter Anzunehmender Unfall) für einen Filialisten ist vielen gar nicht klar: Releaseupdates werden zwar in zeitversetzten “Wellen” bis hin zum Point of Sale, also der Kassse, ausgerollt, dennoch können komplette Marktstillstände eine Folge sein. Vor kurzer Zeit gab es ja so einen GAU in Schweden (Quelle: Tagesschau), der sogar mehrere Tage anhielt. Filialisten stehen auch in der Pflicht ihre Filialen verkaufsfähig zu halten, weil sie zur kritischen Infrastruktur gehören. Ein Filialist kann also gar nicht genug Einzeltestpunkte vor Release-Rollout erzielen. Ein Restrisiko ist immer gegeben, kann aber eben durch sorgfältige strategische Planung minimiert werden (z.B. die automatisierten Poslogprüfungen).
Die obigen Punkte wären schon ausreichend für die Begründung, warum man Poslogs zwingend in die Testautomatisierung aufnehmen sollte. Darüber hinaus gibt es aber einen weiteren eher versteckten Zusammenhang, der unbedingt beachtet werden sollte: Meine Erfahrungen in solchen Projekten zeigen, dass gerade Softwareprojekte während ihrer Laufzeit, wenn z.B. eine neue Kassensoftware eingeführt wird, sehr viele Ressourcen eines Filialisten binden. Mitarbeiter müssen, neben dem Tagesgeschäft, eben auch noch zusätzlich das neue Projekt “stemmen”. Hier wird von Seiten der Geschäftsführung häufig auf externe Unterstützung gesetzt. Als Externer kann ich sagen: Hier ist es für jeden Freelancer auch eine Pflicht, das Projekt bestmöglich zu unterstützen und für Entlastung zu sorgen. Als Automatisierungsentwickler weiß man, dass man gerade zu Beginn eines Projekts noch nicht so weit ist mit der Testautomatisierung. Man kann nicht jeden Einzelaspekt einer Kassensoftware instantan umsetzen. Die Testautomatisierung hinkt immer hinterher, weil deren Umsetzung ganz schlicht betrachtet Zeit benötigt.
Genau hier bildet sich auch der wichtigste Grund für eine frühzeitige Einbindung der automatisierten Poslogprüfungen an, denn in den Poslogs werden häufig auch Fehler der Kassensoftware in Einzelthemen entdeckt, die man als solches in der Testfallentwicklung noch gar nicht umgesetzt hat, weil z.B. höher priorisierte Prozesse zuerst anstehen. Die Poslogs “reagieren”, da sie ein Verbund vieler Einzeldaten, also auch Einzelfunktionen der Kasse, sind frühzeitig auf “Änderungen” von einer Version zur nächsten Version. Hat man die Poslog aber bereits gleich von Anfang an mit in Spiel gebracht, sieht man diese “Änderungen” in den Versionen. Natürlich muss dann jede einzelne Änderung vorerst manuell analysiert / bewertet werden, aber man sieht sie eben und kann reagieren und so auch Fehler von Funktionen der Kassensoftware offenlegen, die man längst noch nicht automatisiert hat. Dieser Teil Mehrdimensionalität von Poslogprüfungen kann als zwingender Beitrag für ein erfolgreichen Projekt betrachtet werden. Ist die Testautomatisierung abgeschlossen, erübrigt sich dieser Grund natürlich.
Wie “baut” man denn in QF-Test eine sinnvolle Poslogprüfung ein?
Poslogprüfungen werden am besten so umgesetzt, dass man immer einen Vergleich jeder einzelnen Poslogdatei mit einer bestehenden Referenzdatei durchführt. Unterschieden wird hier zwischen einer Testlaufposlogdatei und der Referenzposlogdatei. Die Testlaufposlogdatei ist die Poslogdatei die während einer aktiven Testphase von den Backendsystemen gebildet werden. Diese liegen meisten irgendwo auf Servern in der Zentrale und/oder vor Ort auf dem Filialserver. Die Referenzdateien sind entweder händisch geschriebene / kopierte XML-Dateien vom Fachbereich und/oder werden im Laufe der Testautomatisierung aus Testlaufposlogdateien gebildet. Wir haben es hier also mit zwei Dateien zu tun, die zeitlich auseinander liegen. Ein Beispiel: In der Releaseversion 1.0.1 wurde die Poslogdateien als Referenzdateien definiert. Mittlerweile ist das Projekt z.B. bei der Release-Ver. 7.2.3 angekommen. Die während dieser Testphase erstellten Poslogdateien der Version 7.2.3, werden dann in einem compare gegen die Referenzdateien aus der Version 1.0.1 gegen geprüft. Jede Veränderung in der Ver. 7.2.3 in der Poslogstruktur und/oder den Inhalten (Artikeldaten, Preise etc.) würde durch QF-Test “entdeckt” werden und entsprechend im Report / Testlaufprotokoll stehen.
Wir benötigen eine Struktur, die mitloggt, welche Referenzdatei denn gegen welche Testlaufdatei zu prüfen ist. Hier hat sich eine einfache Methode als besonders “Ergiebig” herausgestellt: Es wird eine Prozedur erstellt für die Poslogs, in dieser Prozedur wird zuerst eine CSV-Datei erstellt, Spaltennamen “Datum, Uhrzeit, Bonnummer, Referenzdateiname, Testlaufdateiname”. Die Prozedur wird dann an jedes Transaktionsende eines Testfalls gehangen. Hier sollte man so oder so definierte Prozeduren für haben, also für den Bonabschluss. In diese Struktur wird einfach am Ende die spezialisierte Poslogprozedur als Prozeduraufruf einkopiert. Voila! Jeder neue Testfall nimmt automatisch am Poslog-Compare teil, ohne das man als Entwickler auch nur eine Sekunde Zeit dafür aufgewendet hat. Ist diese Struktur direkt zu Beginn des QF-Projekts etabliert, ist eine frühzeitige Kontrolle der Poslogs automatisch gegeben.
Durch die Poslog-Prozedur wird dann pro Testfall Datum usw. In die CSV-Datei geschrieben. Der Referenzdateiname sollte der Testfallname sein (dafür gibt es in QF-Test eine interne Variable, um diesen Namen immer als Wert bekommen zu können). Der Testlaufdateiname sollte aus Datum_Uhrzeit_Bonnummer bestehen. Ein Beispiel: Der Testfallname ist “HK23_V17_U11”. Es ist der 14.10.21 17:00 Uhr. Die Transaktionsnummer, ausgelesen aus der Kassen-GUI ist “0344”. Der Referenzname ist also „HK23_V17_U11.xml”, der Testlaufdateiname wird entsprechend “14102021_1700_0344.xml” werden. Pro Transaktion hat man jetzt eine Zeile in der CSV-Datei mit den eindeutigen Hinweisen stehen.
Die Poslogs holt man gescriptet oder manuell vom Server ab. Kopiert diese z.B. auf eine Kasse in ein definiertes Verzeichnis. Es läuft ein Script und öffnet die Poslogdateien, sucht dann in den Dateien nach dem einmaligen Marker “Transaktionsnummer” ab und benennt diese Dateien dann eben dann wie unsere Testlaufdateien.
Es wird ein Testfall für den Poslog-Compare erstellt, dieser hat als Datenbasis die CSV-Datei. Der Testfall geht jetzt pro Zeile durch und sucht sich die in der CSV-Datei benannte Referenzdatei, die längst in definierten Verzeichnissen abgespeichert wurde (Internationalität beachten, es empfiehlt sich generell eine Länder-Variable für QF-Testsuiten zu definieren, z.B. DE, BE, FR etc.). Der Testfall sucht sich als nächstes die Testlaufdatei, der Name ist ja bekannt in de CSV, ebenfalls der Speicherort dieser Datei. Jetzt kann ein gescripteter Compare der beiden Dateien stattfinden. Für XML-Compare gibt es von QF-Test bereits fertige Prozeduren, diese sind in der qfs.qft zu finden.
Natürlich müssen dynamische Daten, wie Datum, Uhrzeit Bonnummer etc., innerhalb der XML-Dateien, ausgeschlossen werden im Compare. Diese Funktion ist ebenfalls in der QF-Test Prozedur bereits berücksichtigt worden.
Zusammenfassend die Fakten:
Poslogs automatisiert zu prüfen bringt sehr viele Einzeltestpunkte. Das ganze frühzeitig im Automatisierungsprojekt etabliert, stärkt zusätzlich das Projekt, weil auch noch nicht automatisierte Funktionen, Bereiche etc. durch die Poslogprüfungen aus dem Dunkeln schreiten. Weiterhin ist die Umsetzung, geht man strategisch vor, z.B. die zuständige Poslog-Prozedur in die Transaktionsabschluss-Prozeduren als Prozeduraufrufe einkopieren, relativ einfach, kostet kaum was, dennoch hat man ab diesem Zeitpunkt selbst in neu erstellten Testfällen automatisch immer auch die Poslogprüfung etabliert. Es gibt nur positive Gründe dies so umzusetzen.
Falls Sie mit uns über ähnliche Herausforderungen sprechen wollen, kontaktieren Sie uns unter service@die-gute-it.de.