Univer-AI-Agent-Integration: Abnahme-Checkliste vor dem Go-live – Mac-Browser-Regression 2026

Das WCAG-Erfolgskriterium 2.4.3 behandelt die nachvollziehbare Fokusreihenfolge interaktiver Elemente (W3C-Erläuterung zur Fokusreihenfolge). Für die Abnahme einer Univer-AI-Agent-Integration folgt daraus eine klare Regel: Ein erfolgreicher Demo-Durchlauf reicht nicht. Vor dem Go-live sind Bearbeitungszustand, Aktionsgrenzen, Browserinteraktion, Fehlerwiederherstellung und prüfbare Nachweise getrennt zu testen. Mac-Browser-Regressionen müssen sich auf die tatsächlich unterstützten und getesteten Umgebungen beschränken.

Für Univer-Entwicklungsteams: Sie prüfen, welche Änderungen ein Agent im Editor auslösen darf und wie diese erkennbar bleiben.
Für QA-Teams: Sie benötigen reproduzierbare Mac-Browser-Testfälle und eine nachvollziehbare Fehlerdokumentation.
Für technische Produktverantwortliche: Sie müssen vor der Freigabe Berechtigungen, Wiederherstellung und Abnahmenachweise beurteilen können.

Univer-AI-Agent-Abnahme nach realen Arbeitsabläufen planen

Beginnen Sie nicht mit einer Liste beliebiger Agent-Funktionen, sondern mit den Abläufen, die das Produkt tatsächlich anbietet. Ein Beispiel wäre: Eine Person markiert einen Tabellenbereich, fordert eine Zusammenfassung an, prüft den Vorschlag und übernimmt ihn oder verwirft ihn. Bei einem Dokument könnte die Person eine Formulierung anfordern, den Änderungsvorschlag begutachten und die Übernahme ausdrücklich bestätigen.

Erfassen Sie für jeden Ablauf, welche Schritte ein Mensch anstößt und welche der Agent ausführt. Halten Sie außerdem fest, an welcher Stelle der Editor den Zustand sichtbar macht. Die Univer-Dokumentation beschreibt Funktionen des Tabelleneditors und den Einstieg in die Entwicklung; daraus folgt jedoch nicht automatisch, dass eine bestimmte Agent-Aktion integriert, sicher oder in jedem Produkt unterstützt ist. Prüfen Sie die konkrete Implementierung gegen die Univer-Dokumentation zu Tabellenfunktionen und den offiziellen Univer-Quellcode, statt angenommene Fähigkeiten als Produktgarantie zu behandeln.

Für jeden ausgewählten Ablauf sollten Sie mindestens folgende Angaben notieren:

• Ausgangsdokument und relevanter Inhalt,
• auslösende Nutzeraktion,
• erwartete Agent-Aktion und deren zulässiger Umfang,
• sichtbare Rückmeldung während und nach der Verarbeitung,
• erwarteter Zustand bei Bestätigung, Abbruch und Fehler,
• Nachweis, mit dem sich das Ergebnis unabhängig überprüfen lässt.

So wird „Der Agent hat etwas geändert“ zu einer überprüfbaren Aussage: Welche Zellen oder Inhalte waren betroffen, welche Änderung wurde vorgenommen, und blieb der übrige Dokumentzustand unverändert?

Welche Univer-Funktionen sind nach der AI-Agent-Integration zu testen?

Testen Sie nicht nur die Funktion, die in einer Produktpräsentation gezeigt wird. Wählen Sie repräsentative, tatsächlich implementierte Aufgaben aus Tabellen, Dokumenten oder Präsentationen und prüfen Sie auch die angrenzenden Editoraktionen: Auswahl, Eingabe, Formatierung, Speichern und Abbruch. Welche dieser Aufgaben in der konkreten Installation unterstützt werden, muss das Team anhand seiner Implementierung und der offiziellen Produktdokumentation festlegen.

Bei einer Tabellenauswertung sollte die Abnahme beispielsweise feststellen, ob der Agent den vorgesehenen Bereich verwendet, ob die Ausgabe am erwarteten Ort erscheint und ob die Quelldaten unverändert bleiben, wenn nur eine Zusammenfassung gewünscht war. Für eine Textänderung ist zu prüfen, ob der Vorschlag als Vorschlag erkennbar ist oder unmittelbar den bestehenden Inhalt ersetzt. Das sind projektspezifische Erwartungen, keine pauschale Aussage über Univer oder jede AI-Agent-Integration.

Bearbeitungszustand und Datenkonsistenz sichtbar machen

Bevor Sie einen Agent-Aufruf starten, dokumentieren Sie den Ausgangszustand. Das kann je nach Produkt ein Screenshot, ein exportierter Dokumentzustand, ein protokollierter Zellbereich oder eine Kombination daraus sein. Wichtig ist, dass die Methode für den geprüften Ablauf geeignet und unter den Datenschutzvorgaben des Projekts zulässig ist. Enthalten Testdaten personenbezogene oder vertrauliche Informationen, verwenden Sie geeignete Testdaten und beschränken Sie den Zugriff auf die Nachweise.

Prüfen Sie nach der Aktion getrennt, ob Inhalt, Position, Format und Speicherzustand dem erwarteten Ergebnis entsprechen. Ein inhaltlich plausibler Text beweist nicht, dass die richtige Zelle geändert oder die Änderung gespeichert wurde. Umgekehrt beweist eine sichtbare Änderung im Editor nicht, dass sie nach erneutem Laden erhalten bleibt. Die Univer-Schnellstartdokumentation ist hilfreich, um den grundsätzlichen Editor-Einstieg einzuordnen; die konkrete Speicherung und der Umgang mit Agent-Ergebnissen müssen dennoch in der eigenen Anwendung verifiziert werden (Univer-Schnellstart für Tabellen).

Führen Sie für jede repräsentative Aktion drei Varianten aus:

• Erfolgreiche Ausführung: Der Agent liefert ein Ergebnis, die Person prüft es, und das Ergebnis wird entsprechend dem Produktablauf übernommen.
• Abbruch oder Ablehnung: Die Person verwirft den Vorschlag oder beendet den Vorgang. Prüfen Sie, ob der vorherige Dokumentzustand bestehen bleibt.
• Wiederholte Ausführung: Derselbe Auftrag wird erneut angestoßen. Prüfen Sie, ob eine zweite Aktion unbeabsichtigt Inhalte dupliziert oder bereits bestätigte Änderungen nochmals anwendet.

Halten Sie bei jeder Variante Ausgangszustand, erwartetes Ergebnis und tatsächlichen Zustand fest. Wenn die Anwendung Änderungen über individuelle Befehle oder Erweiterungen auslöst, prüfen Sie deren implementiertes Verhalten statt von einer bestimmten Univer-Standardintegration auszugehen. Die Dokumentation zu benutzerdefinierten Befehlen beschreibt einen Erweiterungsweg; sie ist kein Nachweis dafür, dass der eigene Agent-Befehl korrekt begrenzt oder idempotent ist.

Hinweis: Eine Bildschirmaufnahme kann einen Ablauf anschaulich belegen, ersetzt aber nicht den Vergleich des tatsächlichen Dokumentzustands. Wo der Inhalt sensibel ist, müssen Aufzeichnung, Ablage und Zugriff mit den Datenschutzanforderungen des Projekts vereinbar sein.

Aktionsrechte und Schutz vor Fehlbedienung prüfen

Die Rechteprüfung gehört in die Abnahme, auch wenn der Agent nur auf ausdrückliche Anfrage arbeitet. Die technische Umsetzung kann je nach Produkt unterschiedlich sein; deshalb sollten Testende nicht voraussetzen, dass ein Agent automatisch nur die sichtbare Auswahl ändern kann. Prüfen Sie, welche Daten und Befehle über die Anwendung erreichbar sind, welche Nutzerrechte weitergegeben werden und ob der Agent Aktionen außerhalb des freigegebenen Umfangs ablehnt.

Nutzen Sie mindestens diese Prüffragen:

• Kann der Agent nur die Dokumente und Bereiche bearbeiten, die für den aktuellen Ablauf freigegeben sind?
• Werden Aktionen, die Daten löschen, größere Bereiche überschreiben oder Inhalte außerhalb der Auswahl ändern könnten, im Produkt kenntlich gemacht?
• Benötigt eine riskante Änderung eine ausdrückliche Bestätigung, sofern das Produkt dies vorsieht?
• Stoppt der Ablauf nach einem Berechtigungsfehler, oder werden weitere Aktionen trotzdem ausgeführt?
• Kann die Person erkennen, ob ein Ergebnis nur vorgeschlagen, bereits angewendet oder gespeichert wurde?

Dokumentieren Sie die Trennung zwischen implementierter Schutzmaßnahme und geprüftem Verhalten. „Eine Bestätigung ist im Entwurf vorgesehen“ ist kein Abnahmeergebnis. Als bestanden sollte ein Fall erst gelten, wenn die tatsächliche Anwendung im vorgesehenen Testkonto die definierte Grenze einhält und der Nachweis den Ablauf nachvollziehbar macht. Falls das Produkt keine Bestätigung für riskante Aktionen anbietet, formulieren Sie dies als offenes Produktrisiko, nicht als erfüllte Anforderung.

Mac-Browser-Regressionen passend zum Einsatzgebiet auswählen

Ein Mac-Browser-Test ist nur aussagekräftig, wenn er zur realen Zielumgebung passt. Erfassen Sie das verwendete macOS, den Browser samt Version, die Bereitstellungsumgebung und relevante Einstellungen zum Testzeitpunkt. Ziehen Sie aus einem erfolgreichen Lauf keine allgemeine Aussage wie „läuft auf Mac“: Das Ergebnis gilt zunächst nur für die dokumentierte Kombination.

Prüfen Sie insbesondere Tastaturfokus, Tastenkombinationen, Bildlauf, Dialoge und Layoutänderungen bei den tatsächlichen Arbeitsabläufen. Bei einem Dialog sollte beispielsweise erkennbar sein, wo sich der Fokus beim Öffnen befindet, ob er in sinnvoller Reihenfolge durch die interaktiven Elemente läuft und ob er nach dem Schließen an eine erwartbare Stelle zurückkehrt. Die W3C-Erläuterung zur Fokusreihenfolge bei interaktiven Inhalten bietet dafür einen überprüfbaren Bezugspunkt, ohne die notwendige Prüfung in der eigenen Oberfläche zu ersetzen.

Die nachstehende Matrix hilft, Testziele von Testergebnissen zu trennen. Wählen Sie nur Browser und Umgebungen, die Ihr Team tatsächlich unterstützen oder für die Zielgruppe zugesagt hat.

Testansatz	Was sich damit prüfen lässt	Grenze der Aussage
Mac mit einem unterstützten Zielbrowser	Editorbedienung, Fokus, Dialoge, Layout und Agent-Ablauf in der vorgesehenen Nutzerumgebung	Gilt nur für die dokumentierte Kombination und den ausgeführten Testumfang
Automatisierte Browserläufe	Wiederholbare Abläufe, Zustandsprüfungen und Fehlerfälle in der festgelegten Testkonfiguration	Ein automatisierter Lauf belegt keine vollständige Bedienbarkeit oder allgemeine Mac-Kompatibilität
Zusätzliche manuelle Regression	Tastaturbedienung, visuelle Auffälligkeiten und schwer automatisierbare Übergänge	Ergebnisse hängen von dokumentierten Schritten und der getesteten Umgebung ab

Playwright dokumentiert die Browser, die sich mit dem Werkzeug testen lassen, darunter Chromium, Firefox und WebKit (Playwright: unterstützte Browser). Das ist eine Aussage zu den verfügbaren Playwright-Browserprojekten, kein Nachweis dafür, dass WebKit in einem automatisierten Test die native Safari-Umgebung auf jedem Mac vollständig abbildet. Für Safari-spezifische Fehler sollten Sie die konkrete Zielumgebung prüfen und Browser- beziehungsweise Systemversion im Testprotokoll festhalten. Apples Beschreibung der Web-Inspektionswerkzeuge ist eine geeignete Referenz für die Untersuchung von Webinhalten in Safari.

Was gehört in einen Mac-Browser-Regressionstest?

Wählen Sie pro relevantem Ablauf die Interaktionen aus, von denen die Aufgabe abhängt. Dazu gehören:

• Fokus und Tastatur: Lässt sich der Ablauf ohne unerwarteten Fokusverlust fortsetzen? Funktionieren die für das Produkt vorgesehenen Tastenkombinationen?
• Maus und Auswahl: Bleibt die Auswahl bestehen, wenn der Agent arbeitet oder ein Dialog geöffnet wird?
• Scrollen und Ansichtswechsel: Bleiben Zielbereich und Bedienelemente nach Bildlauf oder Größenänderung erreichbar?
• Dialoge und Pop-ups: Werden Dialoge korrekt geöffnet, geschlossen und fokussiert? Gibt es eine sichtbare Rückmeldung, während der Agent verarbeitet?
• Layout und Fehlerhinweise: Sind Statusmeldungen, Bestätigung und Fehlermeldungen in der getesteten Fenstergröße auffindbar?
• Seitenwechsel und Hintergrund: Was geschieht, wenn die Seite den Fokus verliert oder wieder sichtbar wird?

Wenn eine Anwendung auf den Sichtbarkeitszustand der Seite reagiert, notieren Sie den konkreten Übergang im Testfall. Die Page Visibility API stellt der Anwendung Informationen über die Sichtbarkeit einer Seite bereit; ob und wie die Integration diese Information nutzt, ist anhand des eigenen Codes und tatsächlichen Verhaltens zu prüfen.

Fehler, Unterbrechungen und Wiederholung gezielt durchspielen

Eine belastbare Abnahme beschränkt sich nicht auf den fehlerfreien Normalfall. Simulieren Sie die Unterbrechungen, die im vorgesehenen Produktbetrieb realistisch auftreten können, ohne dabei reale Kundendaten zu gefährden. Entscheidend ist nicht, dass jeder Fehler automatisch wiederhergestellt wird, sondern dass das Verhalten verständlich, begrenzt und entsprechend den Produktanforderungen nachvollziehbar ist.

Fehlerszenario	Beobachtung während des Tests	Erforderlicher Nachweis
Verbindung bricht während einer Agent-Aktion ab	Bleibt der Bearbeitungsstatus erkennbar? Wird eine Teiländerung angezeigt oder gespeichert?	Protokoll, Bildschirmnachweis und Vergleich des Dokumentzustands
Seite wird aktualisiert oder verlassen	Ist nach Rückkehr erkennbar, ob die Aktion abgeschlossen, fehlgeschlagen oder noch offen ist?	Vorher-Nachher-Zustand und dokumentierte Wiederaufnahme
Derselbe Auftrag wird erneut gesendet	Entstehen doppelte Inhalte oder zusätzliche Änderungen?	Vergleich der Zustände nach erstem und erneutem Aufruf
Dokumentzustand verändert sich während der Verarbeitung	Wird der Agent gestoppt, neu bewertet oder mit veralteten Daten fortgesetzt?	Aufzeichnung der Ausgangslage, Änderung und Reaktion
Berechtigung oder Befehl schlägt fehl	Stoppt der Ablauf, oder werden nachfolgende Aktionen trotzdem ausgeführt?	Fehlerprotokoll und Bestätigung, dass keine unzulässigen Folgeänderungen erfolgten

Wenn die Anwendung bei einem Wiederholungsversuch automatisch erneut anfragt, prüfen Sie, wie sie Mehrfachaktionen verhindert oder erkennt. Verlassen Sie sich nicht allein darauf, dass ein Testframework einen Fehler erneut ausführt: Die Playwright-Dokumentation zu Testwiederholungen beschreibt das Verhalten von Test-Retries, nicht die fachliche Sicherheit eines erneut gesendeten Agent-Auftrags. Ebenso können getrennte Playwright-Browserkontexte Testzustände isolieren; daraus folgt nicht, dass serverseitige Dokumentzustände automatisch zurückgesetzt werden.

Wie lässt sich das Ergebnis einer Agent-Aktion verlässlich prüfen?

Prüfen Sie den Effekt an der Ressource, die der Ablauf verändern soll, nicht nur an der Rückmeldung des Agents. Vergleichen Sie vor und nach der Aktion den betroffenen Inhalt sowie die relevanten Eigenschaften: beispielsweise Zielbereich, Format, Änderungsstatus und Verhalten nach einem erneuten Laden, sofern dieses zum Produktablauf gehört. Bei einem abgelehnten Vorschlag muss die Prüfung außerdem zeigen, dass die Ablehnung tatsächlich keine unbeabsichtigte Änderung hinterlassen hat.

Wo sich der vollständige Zustand nicht einfach vergleichen lässt, legen Sie die zulässigen Nachweisarten vor dem Test fest. Das können kontrollierte Testdaten, ein geeigneter Zustandsvergleich oder ein nachvollziehbares Aktionsprotokoll sein. Entscheidend ist, dass eine andere Person den Test anhand von Ausgangslage, Schritten und Ergebnis wiederholen oder beurteilen kann.

Abnahmeprotokoll und Freigabe nachvollziehbar führen

Verknüpfen Sie jeden Test mit einem eindeutigen Fall und einer klaren Erwartung. Ein fehlgeschlagener Fall braucht genug Kontext, damit Entwicklung und QA die Ursache eingrenzen können. Dabei sollten sensible Inhalte in Screenshots, Logs und Fehlerberichten minimiert oder geschützt werden; Anforderungen der DSGVO und die internen Regeln zur Datenaufbewahrung bleiben auch in Testumgebungen relevant.

Ein vollständiger Eintrag sollte mindestens enthalten:

• Testfall-ID und kurze Beschreibung des Nutzerablaufs,
• Zielumgebung mit macOS-, Browser- und Anwendungsstand,
• Voraussetzungen, Testkonto und Ausgangszustand,
• ausgeführte Schritte und erwartetes Verhalten,
• tatsächliches Ergebnis mit Verweis auf geeignete Nachweise,
• Status, Fehlerbeschreibung und verknüpften Defekt,
• verantwortliche Person sowie Zeitpunkt der Ausführung.

Legen Sie die Freigabekriterien projektbezogen fest. Eine einheitliche Anzahl erfolgreicher Tests oder eine allgemeingültige Fehlerschwelle lässt sich für jede Univer-AI-Agent-Integration nicht seriös vorgeben. Entscheidend ist, ob die für das jeweilige Risiko relevanten Abläufe bestanden wurden und ob offene Fehler, Workarounds sowie Einschränkungen vor dem Go-live ausdrücklich bewertet sind. Nach Änderungen an Univer, dem Agent-Code, dem Browser oder der Bereitstellung sollten die davon betroffenen Fälle erneut ausgeführt werden. Eine bestandene Regression für einen dokumentierten Stand ist kein Nachweis für eine spätere, ungeprüfte Kombination.

Wenn ein Fehler reproduzierbar nur in einer bestimmten Umgebung auftritt, ergänzen Sie den Eintrag um einen möglichst kleinen Reproduktionsablauf. Halten Sie fest, ob der Fehler nach einem erneuten Laden, in einer isolierten Testsitzung oder mit einem anderen Testkonto ebenfalls auftritt. Bei automatisierten Tests können getrennte Browserkontexte Sitzungszustände voneinander isolieren; die Protokollierung muss trotzdem zeigen, welche Daten oder serverseitigen Zustände gemeinsam genutzt werden.

Für echte Mac-Regressionen die Umgebung passend auswählen

Ein Team, das bereits geeignete Macs und die relevanten Browserstände verwaltet, kann die Regression lokal durchführen. Das ist oft sinnvoll, wenn Tests dauerhaft auf derselben Hardware laufen, physische Schnittstellen benötigt werden oder die Umgebung unter eigener Kontrolle bleiben muss. Der Aufwand liegt dann unter anderem in Pflege, Zugriffsschutz, Systemaktualisierungen und der Verfügbarkeit der Testgeräte.

Für einen begrenzten Freigabelauf kann eine gemietete Mac-Umgebung dagegen eine passende Ergänzung sein: Sie ermöglicht einen gezielten Mac-Test, ohne dass das Team dafür dauerhaft zusätzliche Testhardware vorhalten muss. Das ersetzt weder die Prüfung der konkreten Zielbrowser noch die Dokumentation der tatsächlich verwendeten Umgebung. Wer die Abläufe vorab vergleichen möchte, findet bei nuvcloud Informationen zum Bestellablauf sowie zur Bestellung einer Umgebung in den USA West.

Windows- oder Linux-Tests bleiben für ihre jeweiligen Zielumgebungen nützlich, belegen aber keine Mac-Browser-Kompatibilität. Auch eine einmalige erfolgreiche Vorführung reicht dafür nicht aus. Wenn nur temporär ein echter Mac für die dokumentierte Browser-Regression benötigt wird, kann eine Mac-Miete von nuvcloud geeigneter sein als ein Hardwarekauf, der laufende Pflege und Bereitstellung voraussetzt. Bei dauerhaftem, regelmäßigem Testbetrieb, besonderen physischen Anforderungen oder strengen Vorgaben zur eigenen Infrastruktur sollte das Team dagegen zuerst prüfen, ob lokal verwaltete Hardware besser passt. Entscheidend für die Freigabe bleibt in beiden Fällen derselbe Maßstab: dokumentierte Umgebung, reproduzierbare Testfälle und ein Ergebnis, das nicht über die tatsächlich geprüfte Kombination hinaus verallgemeinert wird.