softify.pro Flow — Getestet von COCO

Control. Clarity. Flow.

Jedes ernstzunehmende Softwareprodukt entwickelt irgendwann ein zweites Produkt hinter dem Produkt.

Kunden bekommen es vielleicht nie zu sehen. Besucher wissen vielleicht nie, dass es existiert. Aber Administratoren, Betreiber und Entwickler verlassen sich jeden Tag darauf.

Bei softify.pro Flow heißt diese Anwendung Administration — die Betriebskonsole, die Benutzer, Rollen, Zugriffsebenen, Authentifizierungsstatus, Datenbankumgebungen und weitere Konfiguration verwaltet, die eine Flow -Installation unter Kontrolle hält.

Der Anmeldebildschirm trägt drei Worte:
Control. Clarity. Flow.

Sie wurden ursprünglich gewählt, um die Erfahrung zu beschreiben, die Administratoren beim Betrieb des Systems haben sollten.

Aber sie beschreiben überraschend gut auch, wie wir glauben, dass Software getestet werden sollte.

Das machte softify.pro Flow — Administration zu einem naheliegenden Kandidaten für einen realen COCO-Test.

Keine Laborvorführung.
Keine Sammlung isolierter Buttons, die eigens für eine KI-Demo vorbereitet wurde.
Eine echte plattformübergreifende Desktop-Anwendung mit echter Anwendungslogik, mehreren Fenstern, mehreren Datenbank-Backends, Authentifizierung, Berechtigungen, Lokalisierung und genug Zustand, um scheinbar kleine Regressionen manuell schwer erkennbar zu machen.

Für die hier gezeigte öffentliche Demonstration arbeitete COCO ausschließlich mit generierten Demodaten. Die Anwendung war an die fiktive Firma Presentation GmbH lizenziert, und es wurden keine echten Kundendaten, Zugangsdaten oder personenbezogenen Daten verwendet.

Das Ziel war einfach:
COCO sollte die Anwendung so angehen, wie es ein Tester tun würde, und feststellen, ob der komplette administrative Arbeitsablauf sich noch so verhält, wie die Software es verspricht.

Die Herausforderung

Auf den ersten Blick wirkt das Testen einer Administrationsanwendung einfach.

Öffnen.
Anmelden.
Durch mehrere Fenster klicken.
Prüfen, ob alles korrekt aussieht.

Diese Annahme ändert sich schnell, sobald die Anwendung wächst.

softify.pro Flow — Administration ist kein einzelnes statisches Formular. Es ist eine Sammlung miteinander verbundener Betriebsansichten innerhalb einer Anwendungshülle.

Ein Administrator arbeitet unter anderem mit:

• Benutzerkonten
• Rollen und Zugriffsebenen
• Authentifizierungsinformationen
• Zwei-Faktor-Authentifizierungsstatus
• Betriebssysteminformationen
• Netzwerk- und IP-Informationen
• Datenbankkonfiguration
• Sortier- und Anzeigeoptionen
• Live-Sprachauswahl
• Anwendungs- und Lizenzinformationen

Die Oberfläche unterstützt derzeit elf Sprachen. Die Anwendung arbeitet außerdem mit MySQL- und PostgreSQL-Datenbank-Backends. Für sich genommen stellt keines dieser Merkmale ein ungewöhnliches Testproblem dar.

Die Schwierigkeit entsteht aus ihren Kombinationen.
Eine Benutzertabelle mag auf Englisch korrekt funktionieren, aber auf Kroatisch einen veralteten Spaltennamen anzeigen.
Die Sortierung mag mit MySQL korrekt funktionieren, sich aber nach dem Wechsel zu PostgreSQL anders verhalten.

Ein Sprachwechsel mag die meisten Oberflächenelemente aktualisieren, aber eine Statusmeldung unübersetzt lassen. Die Anwendung mag erfolgreich die Datenbank wechseln, aber veraltete Informationen aus der vorherigen Verbindung beibehalten. Ein neues Release mag eine Funktion einführen, während der Info-Dialog noch die vorherige beschreibt. Das Programm muss dafür nicht abstürzen, damit eine dieser Situationen eine Regression ist. Tatsächlich sind einige der unangenehmsten Softwarefehler genau die, bei denen scheinbar alles funktioniert.

Die Anwendung startet.
Das Fenster öffnet sich.
Der Button reagiert.
Aber irgendetwas darunter stimmt nicht mehr ganz.
Deshalb ist wiederholtes Regressionstesten wichtig.

Und es ist genau die Art von Arbeit, bei der Menschen zunehmend schlechter werden, nachdem sie dieselbe Abfolge Dutzende Male wiederholt haben.

Warum manuelles Testen teuer wird

Etwas einmal zu testen ist einfach.
Es nach jedem relevanten Release zuverlässig zu testen ist etwas anderes.

Betrachten Sie nur drei Dimensionen: 11 Oberflächensprachen × 2 Datenbank-Backends × mehrere Anwendungs-Workflows.

Die Anzahl der Kombinationen wächst schnell. Fügt man unterschiedliche Benutzerrollen, Authentifizierungsstatus, Sortierverhalten, Konfigurationsänderungen und Betriebsumgebungen hinzu, wird die Testmatrix zu groß, um sie als gelegentliche manuelle Checkliste zu behandeln.

Genau hier beginnt Regressionstesten oft zu erodieren.
Nicht absichtlich.
Ein Release-Termin rückt näher.
Jemand erinnert sich, dass die Anwendung letzte Woche getestet wurde.
Ein Entwickler prüft schnell den wichtigsten Bildschirm.

Deutsch funktioniert.
Englisch funktioniert.
MySQL funktioniert.
Die Annahme wird:
„Der Rest ist wahrscheinlich in Ordnung."

Meistens stimmt das.
Bis zu dem Release, bei dem es nicht stimmt.
COCO existiert unter anderem, um genau diese Annahme aus dem Prozess zu entfernen.

Was COCO tatsächlich getan hat

COCO startete softify.pro Flow — Administration aus einem kalten Anwendungszustand heraus, ohne sich auf einen vorbereiteten Bildschirm oder einen manuell positionierten Arbeitsablauf zu verlassen.

Die erste Interaktion war dieselbe, die auch einem menschlichen Administrator präsentiert wird: das Anmeldefenster.

COCO identifizierte die Authentifizierungsoberfläche mit:

• Benutzername
• Passwort
• Zwei-Faktor-Authentifizierungscode

und der Zeile direkt unter der softify.pro Flow - Kennzeichnung:
Control. Clarity. Flow.

Von dort aus arbeitete sich COCO durch eine definierte Regressionssitzung. Es ging nicht einfach darum, festzustellen, ob die Anwendung sich öffnen ließ.

Es ging darum, zu überprüfen, ob der Zustand der Anwendung intern konsistent blieb, während COCO mit ihr interagierte.

Authentifizierung ist nur der Anfang

Login-Tests sind einer der naheliegendsten Kandidaten für Automatisierung, aber erfolgreiche Authentifizierung allein sagt sehr wenig über den Rest einer Administrationsanwendung aus.

Einmal drin, wechselte COCO in die eigentliche Betriebsumgebung. Es prüfte die Benutzerverwaltungsoberfläche und verifizierte, dass die erwarteten Informationen vorhanden waren.

Das umfasste Daten wie:

• Benutzernamen
• maskierte Passwörter
• 2FA-Indikatoren
• zugewiesene Rollen
• Betriebssysteminformationen
• IP-Adressen

COCO interagierte dann mit der Tabelle, statt sie nur zu beobachten. Die Benutzerliste wurde nach Benutzername sortiert. Die resultierende Reihenfolge wurde geprüft. Der wichtige Teil war nicht, ob das Klicken auf die Spaltenüberschrift eine sichtbare Änderung erzeugte.

COCO überprüfte, ob der resultierende Tabellenzustand der angeforderten Operation entsprach.

Diese Unterscheidung ist wichtig.
Ein funktionaler Test fragt:
„Hat der Button reagiert?"

Ein nützlicher Regressionstest fragt:
„Ist die Anwendung in den korrekten Zustand gelangt?"

Die Datenbankgrenze testen

softify.pro Flow unterstützt mehr als ein Datenbank-Backend.

Das macht den Datenbankwechsel zu einer besonders wichtigen Regressionsgrenze.
COCO wechselte das aktive Backend von MySQL zu PostgreSQL.

Nach dem Wechsel prüfte es die Benutzerinformationen erneut. Der Test suchte nach mehr als einer erfolgreichen Verbindung. Er prüfte, ob die Anwendung weiterhin die erwarteten Datensätze anzeigte und ob die über die Oberfläche gezeigten Informationen konsistent blieben.

COCO wechselte danach wieder zurück.

Diese Art von Übergang wird leicht unterschätzt.
Die Benutzeroberfläche kann visuell identisch bleiben, während sich die darunterliegende Speicherschicht vollständig ändert.
Aus Sicht eines Administrators sollte sich dieser Übergang fast langweilig anfühlen.
Dieselben Benutzer sollten weiterhin verständlich sein.
Dieselben Rollen sollten weiterhin Sinn ergeben.

Dasselbe Oberflächenverhalten sollte weiterhin gelten.

Genau diese scheinbar ereignislose Kontinuität muss bewiesen werden.

Elf Sprachen, ein Anwendungszustand

Lokalisierung ist ein weiterer Bereich, in dem oberflächliches Testen besonders gefährlich ist.

Es ist relativ einfach zu prüfen, ob eine Anwendung in einer anderen Sprache starten kann. Viel wertvoller ist es zu prüfen, was passiert, wenn sich die Sprache ändert, während die Anwendung bereits läuft und einen Zustand hält.

COCO wechselte die Oberflächensprache live.

Die Sitzung umfasste Übergänge zwischen Sprachen wie:
Deutsch → Englisch → Kroatisch
während die Administrationsansicht aktiv blieb.

COCO beobachtete, ob sich Oberflächenelemente korrekt an Ort und Stelle änderten:

• Tabellenüberschriften
• Steuerelemente
• Buttons
• Beschriftungen
• Statusmeldungen

Auch die darunterliegende Tabelle und der Anwendungszustand mussten diesen Übergang überstehen. Das ist wichtig, weil mehrsprachige Software aus mehr besteht als übersetzten Zeichenketten. Sprachwechsel können Folgendes offenlegen:

• vergessene Ressourcen
• veraltete Beschriftungen
• Layoutprobleme
• unübersetzte Statusmeldungen
• Kodierungsprobleme
• Zustandsrücksetzungen
• Probleme bei der Neuerstellung von Steuerelementen

Ein Fenster, das korrekt aussieht, wenn es direkt auf Kroatisch gestartet wird, kann sich dennoch fehlerhaft verhalten, wenn der Benutzer während einer aktiven Sitzung von Deutsch zu Kroatisch wechselt.

Das ist der Unterschied zwischen der Prüfung eines Screenshots und dem Testen eines Arbeitsablaufs.

Den Anwendungszustand wiederherstellen

Anschließend stellte COCO die Standard-Sortierkonfiguration der Anwendung wieder her.

Auch hier endete der Test nicht mit dem Klick selbst.

Die resultierende Reihenfolge und die über den Anwendungsstatusbereich angezeigte Bestätigung wurden ausgewertet. Diese Art der Überprüfung mag im Vergleich zum Testen von Authentifizierung oder Datenbankzugriff unbedeutend erscheinen.

Ist sie aber nicht.

Enterprise-Anwendungen sammeln Hunderte solcher kleinen Zustandsübergänge an. Benutzer verlassen sich darauf, ohne bewusst darüber nachzudenken. Die Software fühlt sich gerade deshalb zuverlässig an, weil diese Interaktionen vorhersehbar bleiben. Regressionstests existieren, um diese Vorhersehbarkeit zu schützen.

Die Informationen rund um die Software testen

COCO öffnete auch den Info-Dialog der Anwendung.

Warum ein Info-Fenster testen?

Weil Softwaredokumentation innerhalb der Software selbst beginnt. Die Versionsnummer, Funktionsbeschreibung und Lizenzinformationen, die dem Betreiber angezeigt werden, sollten der tatsächlich laufenden Anwendung entsprechen.

Eine Anwendung kann einwandfrei funktionieren und dennoch veraltete Versionsinformationen anzeigen oder Fähigkeiten beschreiben, die nicht mehr dem Release entsprechen.

Das lässt keine Datenbank abstürzen.
Es bewirkt etwas Subtileres:
es untergräbt Vertrauen.

Bei Enterprise-Software gehört operative Genauigkeit auch zu diesen scheinbar kleinen Details. COCO überprüfte daher auch diese.

Control.

Das erste Wort im softify.pro Flow -Slogan ist auch das erste Prinzip der Testumgebung.

Control bedeutet zu wissen, was getestet wird, gegen welchen Zustand und mit welchen Daten.

Die öffentliche COCO-Demonstration verwendet keine Produktivdaten von Kunden.

Sie läuft mit gezielt vorbereiteten Demodaten, deren erwarteter Zustand bekannt ist.

Das macht Ergebnisse reproduzierbar.

Es bedeutet außerdem, dass Unterschiede zwischen Testläufen untersucht statt als zufällige Änderungen in Produktivdaten weggeklärt werden können.

Wichtiger noch: COCO ist als selbst gehostetes KI-Testsystem konzipiert.

Testnachweise, Anwendungs-Screenshots und interne Ablaufinformationen können innerhalb der Infrastruktur unter der eigenen Kontrolle des Kunden oder Betreibers bleiben, statt standardmäßig an einen fremden Cloud-Dienst gesendet zu werden.

Für interne Geschäftsanwendungen ist das nicht bloß eine Infrastrukturpräferenz. Es kann Teil der Testanforderung selbst sein.

Clarity.

Automatisierung ist nicht besonders nützlich, wenn ihr Endergebnis lautet: FAILED
gefolgt von Hunderten Zeilen technischer Ausgabe, die jemand manuell rekonstruieren muss, bevor er versteht, was passiert ist.

COCO ist so konzipiert, dass eine verständliche Beweiskette erhalten bleibt.

Der Bericht beschreibt:

• was getestet wurde
• welche Interaktion stattfand
• in welcher Reihenfolge sie geschah
• was COCO beobachtete
• welcher Zustand erwartet wurde
• wo sich das Verhalten unterschied, wenn etwas fehlschlug

Screenshots und Ausführungsnachweise können diese Abfolge begleiten.
Der Zweck ist nicht, technische Details zu verbergen.

Der Zweck ist, das Ergebnis verständlich zu machen, bevor jemand einen Debugger öffnen muss.

Ein Ingenieur sollte in der Lage sein zu beantworten:
Was ist passiert? bevor er fragt:
Wo im Code ist es passiert?

Diese Unterscheidung verkürzt die Untersuchung dramatisch, wenn eine Regression auftritt.

Flow.

Traditionelle UI-Automatisierung denkt oft in Elementen.

Selektor finden.
Selektor klicken.
Weiteren Selektor finden.
Wert prüfen.

Dieser Ansatz bleibt nützlich, aber Anwendungen werden nicht als Sammlungen von Selektoren erlebt.

Menschen erleben Abläufe.

Anmelden.
Administration öffnen.
Einen Benutzer finden.
Eine Einstellung ändern.
Eine Datenbank wechseln.
Eine Sprache ändern.
Das Ergebnis überprüfen.

Weiterarbeiten.

COCO behandelt die Abfolge daher als Prozess, nicht als zufällige Sammlung von Steuerelementen.

Es verfolgt, was der Benutzer erreichen möchte, und bewertet die Anwendung im Kontext.

Das wird besonders wertvoll beim Testen echter Geschäftssoftware, weil Fehler oft zwischen Bildschirmen oder zwischen Zuständen auftreten, nicht innerhalb eines einzelnen Buttons.

Ein Logistikablauf mag eine Bestellung, eine Lagerreservierung, eine Kommissionierung, einen Lieferschein und eine Versandbestätigung umfassen.
Jeder einzelne Bildschirm kann korrekt erscheinen, während der Gesamtprozess falsch ist.
Dasselbe Prinzip gilt hier in kleinerem Maßstab.
Das Administrationsfenster ist nicht das Produkt.

Der Arbeitsablauf hindurch ist es.

Beweise statt Annahme

Eine der wichtigsten Aufgaben von COCO ist nicht das Klicken. Es ist das Erinnern daran, was passiert ist.

Menschliches Regressionstesten endet häufig mit einer Aussage wie:
„Ich habe es getestet, und alles sah in Ordnung aus."

Das mag völlig zutreffend sein.
Aber Wochen später, wenn ein Problem auftritt, sind die nützlichen Fragen andere:

• Welches Release wurde getestet?
• Welche Datenbank?
• Welche Sprache?
• Welcher Benutzerzustand?
• Was geschah vor dem Problem?
• Was genau war sichtbar?

In welcher Reihenfolge wurden die Aktionen ausgeführt?
Die Testläufe von COCO sind darauf ausgelegt, Beweise zu hinterlassen.

Das verwandelt ein Testergebnis von einer Meinung in etwas Überprüfbares. Ein erfolgreicher Lauf wird dadurch ebenfalls nützlich. Er legt einen bekannten Referenzzustand fest, mit dem späteres Verhalten verglichen werden kann.

COCO trifft nicht die Entscheidung

Es gibt eine wichtige Grenze in der Art, wie wir KI für Softwaretests einsetzen.
COCO soll nicht die technische Verantwortung ersetzen.

Es entscheidet nicht, wie eine Geschäftsregel sein sollte.

Es testet Verhalten gegen Szenarien, Anforderungen und Erwartungen, die für die Anwendung definiert wurden. Bei sensiblen Entscheidungen zu Berechtigungen, Preisen, Beständen, Finanztransaktionen oder anderen kritischen Geschäftszuständen bleibt die Definition korrekten Verhaltens menschliche Verantwortung.

Diese Unterscheidung ist wichtig.
KI ist hervorragend darin, einen detaillierten Test zu wiederholen, ohne die Konzentration zu verlieren. Sie ist hervorragend im Sammeln von Beweisen. Sie kann Bildschirme prüfen, erwartetes mit beobachtetem Verhalten vergleichen und Abweichungen erklären. Aber das Unternehmen definiert weiterhin, was korrekt bedeutet.

COCO macht diese Definition testbar.

Der Test, den niemand wiederholen möchte

Es gibt einen einfachen Grund, warum Automatisierung hier einen Mehrwert bietet.
Ein menschlicher Tester kann diese Regressionssitzung durchaus durchführen.
Die erste Sprache erhält volle Aufmerksamkeit.
Wahrscheinlich auch die zweite.
Dann noch eine.
Dann noch eine.
MySQL wurde bereits geprüft.
PostgreSQL muss noch geprüft werden.
Der Sortiertest wurde bereits mehrfach durchgeführt.
Der Info-Dialog hat sich seit Monaten nicht geändert.

Es ist Freitagnachmittag.

Und menschliche Aufmerksamkeit tut, was menschliche Aufmerksamkeit naturgemäß tut.
Sie beginnt zu optimieren.
COCO nicht.
Im eigenen Geist von COCO:

• Ich werde nicht müde davon, denselben Button in elf Sprachen zu klicken. Ich überspringe den PostgreSQL-Durchgang nicht, nur weil Freitagnachmittag ist. Ich nehme nicht an, dass die Sortierung gehalten hat, nur weil sie im vorherigen Release funktioniert hat.

Für COCO kann jede Regressionssitzung so behandelt werden, als wäre sie die erste.
Das ist keine Intelligenz, die einen menschlichen Tester ersetzt.
Es ist Automatisierung, die den menschlichen Tester vor dem Teil des Testens schützt, in dem menschliche Aufmerksamkeit am wenigsten wert ist.

Vom wiederholten Testen zum technischen Beweis

Der größere Zweck von COCO ist nicht, die Anzahl automatisierter Aktionen zu maximieren. Tausend automatisierte Klicks sind bedeutungslos, wenn niemand versteht, was sie beweisen. Das nützliche Ergebnis ist durch Beweise gestütztes Vertrauen.

Für softify.pro Flow bedeutet das, sagen zu können, dass ein Release über die relevanten Betriebsbereiche hinweg geprüft wurde:

• Authentifizierung
• Benutzerverwaltung
• Rollen- und Zugriffsinformationen
• Zwei-Faktor-Authentifizierungsstatus
• Sortierverhalten
• MySQL-Betrieb
• PostgreSQL-Betrieb
• Live-Lokalisierung
• Statusrückmeldungen
• Anwendungsinformationen
• Lizenzinformationen

und dass das Ergebnis in einer Form aufbewahrt wird, die später überprüft werden kann.

Dasselbe Prinzip skaliert weit über diese Anwendung hinaus.
Ein Login-Prozess kann so getestet werden.
Ein Buchungsablauf kann so getestet werden.
Ein Logistikprozess kann so getestet werden.
Eine plattformübergreifende Desktop-Anwendung kann so getestet werden.
Die Bildschirme ändern sich.
Die Geschäftsregeln ändern sich.
Das Prinzip nicht:
den erwarteten Ablauf definieren, ihn konsistent ausführen, Beweise sammeln und das Ergebnis verständlich machen.

Warum wir unsere eigene Software mit COCO testen

Es gibt einen weiteren Grund, warum softify.pro Flow als COCO-Fallstudie wichtig ist.

Es ist unsere eigene Software.
Das beseitigt die bequeme Distanz, die manchmal zwischen einer Technologievorführung und den Menschen besteht, die sie vorführen.

Wenn COCO Enterprise-Software testen soll, muss es nützlich genug sein, dass wir ihm Software anvertrauen, die wir selbst entwickeln und veröffentlichen.

Flow dient daher sowohl als Produkt als auch als Testfeld.
Neue Testfähigkeiten können an einer echten Anwendung erprobt werden.
Unerwartetes Verhalten kann Schwächen in der Anwendung, im Testplan oder in COCO selbst offenlegen.

Jede Seite verbessert die andere.
Diese Rückkopplungsschleife ist viel wertvoller als der Aufbau künstlicher Demonstrationen, die nur darauf ausgelegt sind, erfolgreich zu sein. Ein Testsystem sollte nicht überzeugend wirken, weil die Demonstration einfach war.
Es sollte überzeugend werden, weil es weiterhin die kleinen Dinge findet, die Menschen irgendwann aufhören würden zu prüfen.

Das Ergebnis

softify.pro Flow — Administration verfügt nun über einen dokumentierten und wiederholbaren Regressionsprozess, den COCO vor relevanten Releases ausführen kann.

Der Test umfasst beide unterstützten Datenbankumgebungen und die elfsprachige Oberfläche der Anwendung, während er der Anwendung so folgt, wie ein Administrator sie nutzen würde, statt jeden Bildschirm als isoliertes Testziel zu behandeln.

COCO erstellt eine Beweiskette, die zeigt, was getestet wurde, was beobachtet wurde und in welcher Reihenfolge die Sitzung ablief.

Diese Beweise können lokal unter Kontrolle bleiben.
Entwickler erhalten bei jeder Änderung einen reproduzierbaren Ausgangspunkt.
Menschliche Tester verbringen weniger Zeit mit dem Wiederholen vorhersehbarer Interaktionen und mehr Zeit mit der Untersuchung von Situationen, die tatsächlich Urteilsvermögen erfordern.

Und softify.pro Flow erhält etwas Wertvolleres als eine grüne PASS-Anzeige.

Es erhält den Beweis, dass die auf dem Anmeldebildschirm versprochene Erfahrung auch dann noch besteht, nachdem sich der zugrunde liegende Code geändert hat.

Control. Wissen, was getestet wird, und die Umgebung unter Kontrolle halten.

Clarity. Verstehen, was passiert ist, ohne ein undurchsichtiges Automatisierungsprotokoll rekonstruieren zu müssen.

Flow. Die Anwendung als Prozess testen, den Menschen tatsächlich nutzen.

Control. Clarity. Flow.

Es wurde für die Software geschrieben.
Es stellte sich heraus, dass es genauso gut die dahinterstehende Testphilosophie beschreibt.