TestMu AI führt den „Assurance Lifecycle" in Kane CLI ein und wandelt Anforderungsdokumente in eine nachweisbare Testabdeckung um

16.09.2026

Neue Assurance-Funktionen leiten Tests direkt aus PRDs und Spezifikationen ab, verknüpfen jeden Test dauerhaft mit der verifizierten Anforderung und messen die Abdeckung anhand gesicherter Nachweise statt auf Basis von Vermutungen.

SAN FRANCISCO und NOIDA, Indien, 16. September 2026 /PRNewswire/ -- TestMu AI (ehemals LambdaTest), die weltweit erste agentenbasierte, KI-gestützte Quality-Engineering-Plattform, hat den Assurance Lifecycle vorgestellt, eine neue Reihe von Befehlen in Kane CLI , die das Tool über das Erstellen und Wiederholen von Browsertests hinaus erweitern. Mit großer Sicherheit beschreiben Teams, was ihr Produkt leisten muss, und Kane CLI entwirft die Tests, die dies nachweisen – wobei jeder Test dauerhaft mit der Anforderung verknüpft ist, die er überprüft, die Testabdeckung anhand gesicherter Nachweise gemessen wird und die Testsuite bei Produktänderungen entsprechend angepasst wird.

TestMu AI (Formerly LambdaTest)

TestMu AI brachte Kane CLI im April 2026 als terminalbasiertes Tool zur Browser-Automatisierung auf den Markt, das sowohl für menschliche Entwickler als auch für KI-Codierungsagenten wie Claude Code, Codex CLI, Cursor und Gemini CLI konzipiert ist. Kane CLI arbeitet mit Absichtsangaben in einfacher Sprache statt mit Selektoren und ermöglicht es Teams, einen Ablauf zu beschreiben und ein Pass/Fail-Ergebnis mit vollständiger Schritt-für-Schritt-Verfolgung und Screenshot zu erhalten, Abläufe in nativen Playwright-Code zu exportieren sowie headless in CI-Pipelines auszuführen. Seit der Einführung wurde die KI-gestützte Testfallgenerierung über „kane-cli generate" hinzugefügt, die eine einzeilige Beschreibung in Szenarien und Testfälle umwandelt. Der Assurance Lifecycle ist der nächste Schritt: Tests, die aus den tatsächlichen Anforderungsdokumenten abgeleitet werden, nicht nur aus einer Eingabeaufforderung.

Die meisten Testsuiten beantworten immer noch die falsche Frage. Sie berichten, wie viele Tests bestanden wurden, nicht welche Anforderungen verifiziert wurden. Tests weichen von den Spezifikationen ab, auf denen sie basieren, die Testabdeckung wird zu einer Vermutung, und wenn sich eine Anforderung ändert, weiß niemand, welche Tests veraltet sind. Der Assurance-Lebenszyklus übernimmt die Schritte vor und nach der Ausführung: die Umwandlung von Anforderungen in konzipierte Tests und die Umwandlung von Testläufen in einen überprüfbaren Nachweis dessen, was nachgewiesen wurde. Erfassung:

So funktioniert der Assurance Lifecycle:

  • Erfassung: kane-cli context ingest speichert Momentaufnahmen von Anforderungsdokumenten – ein PRD, eine Spezifikation, eine Richtlinienseite – in einem lokalen, inhaltsadressierten Speicher.
  • Auszug: Ein Agent liest die Quellen und schlägt Anwendungsfälle vor, wobei er die genauen Zeilen zitiert, die er gelesen hat.
  • Überprüfung: Teams leiten Vorschläge an vertrauenswürdige Personen weiter, bearbeiten sie oder lehnen sie ab. Alles, was ein Agent vorschlägt, gilt zunächst als abgeleitet; nichts wird stillschweigend als vertrauenswürdig angesehen.
  • Design: kane-cli design tests wandelt einen Anwendungsfall in Akzeptanzkriterien, Szenarien und ausführbare Tests um – genau einen Test pro Szenario, wobei jeder mit den Kriterien gekennzeichnet ist, die er verifiziert. Das Design-Ergebnis durchläuft denselben Überprüfungsprozess.
  • Ausführen: Entworfene Tests werden mit „kane-cli testmd run" und „kane-cli testrun run" ausgeführt; jeder Durchlauf erstellt ein Evidenzpaket.
  • Messen: „kane-cli cover" berichtet über zwei Achsen – was ein Durchlauf bewiesen hat und was das Design noch schuldig ist. Fehlende Abdeckung wird als rangierte Lücke erfasst, nicht als Leere.
  • Warten: „kane-cli maintain" gleicht die Testsuite ab, wenn sich ein Quelldokument ändert, und markiert alles, was aus dem alten Snapshot extrahiert wurde, als veraltet, bis es erneut verifiziert wurde.

Jede Phase ist ein separater Befehl, sodass Teams jederzeit anhalten, überprüfen und fortsetzen können; nichts im nachgelagerten Bereich geschieht ohne den vorgelagerten Commit. Der Assurance-Speicher befindet sich im Projektverzeichnis, ist nur für Nachträge zugänglich, verfügt über einen wiederholbaren Verlauf und bleibt lokal: Quellcodes, Anwendungsfälle, Entwürfe und Überprüfungsergebnisse befinden sich auf der Festplatte des Entwicklers, nicht auf einem Server. Der gesamte Lebenszyklus läuft kopflos in der CI oder über einen KI-Agenten ab, sodass ein Agent im selben Workflow eine Funktion erstellen, Tests anhand der Spezifikation entwerfen und die Abdeckung melden kann.

Der Assurance Lifecycle ergänzt „kane-cli generate" und ersetzt ihn nicht. Teams, die in einer Minute zehn gute Testideen benötigen, beginnen mit „generate"; Teams, die über ein PRD verfügen und die Frage „Was genau wird abgedeckt, und woher wissen wir das?" beantworten müssen, beginnen mit „assurance".

„KI-Agenten schreiben Code mittlerweile schneller, als jedes Team ihn verifizieren kann, und die Lücke zwischen beiden ist die Validierungsschuld. Kane CLI hat im April den ersten Teil dieser Lücke geschlossen, indem es Agenten und Entwicklern einen echten Browser und ein „Bestanden"- oder „Nicht bestanden"-Urteil zur Verfügung stellte. „Der Assurance Lifecycle erledigt den Rest", sagte Mudit Singh, Mitbegründer und Leiter der Wachstumsabteilung bei TestMu AI. „Eine grüne Testsuite hat Ihnen noch nie gesagt, was sie tatsächlich bewiesen hat. Jetzt lässt sich jeder Test auf die Anforderung zurückverfolgen, die er verifiziert, jeder Durchlauf sichert seine Nachweise, und die Testabdeckung wird zu einem Nachweis, den Sie prüfen können, anstatt zu einer Zahl, von der Sie hoffen, dass sie stimmt. Wenn sich eine Spezifikation ändert, zeigt die Testsuite an, was veraltet ist, anstatt stillschweigend zu verfallen. Genau das muss Sicherheit bei agentischer Geschwindigkeit bedeuten."

Der Assurance Lifecycle ist ab heute in Kane CLI 0.6.1 und höher verfügbar; bestehende Nutzer können das Upgrade über npm oder Homebrew durchführen. Die Schritte „Extrahieren", „Design" und „Wartung – Abgleich" laufen auf dem KaneAI-Agenten und verbrauchen Credits, während die Vorgänge „Überprüfen", „Abdeckung" und „Speichern" lokal und kostenlos sind.

Dokumentation finden Sie unter testmuai.com/support/docs/kane-cli-assurance/. Weitere Informationen zu Kane CLI finden Sie unter testmuai.com/kane-cli.

Informationen zu TestMu AI

TestMu AI ist die weltweit erste agentenbasierte, KI-gestützte Quality-Engineering-Plattform, die es Unternehmen ermöglicht, Tests auf der Grundlage intelligenter Verfahren zu automatisieren und zu skalieren. Durch die Kombination autonomer Fähigkeiten mit einer nahtlosen Integration in moderne Entwicklungsworkflows versetzt TestMu AI Teams in die Lage, in einer „AI-first"-Welt schnellere, zuverlässigere und sicherere Software bereitzustellen.

Weitere Informationen finden Sie unter https://www.testmuai.com/. 

Medienkontakt

Nikhil Saxena

Leiter Unternehmenskommunikation, TestMu AI

+91 98709 81968

nikhils@testmuai.com 

Cision View original content to download multimedia:https://www.prnewswire.com/news-releases/testmu-ai-fuhrt-den-assurance-lifecycle-in-kane-cli-ein-und-wandelt-anforderungsdokumente-in-eine-nachweisbare-testabdeckung-um-302880029.html

Antisemitismus-Debatte nach ZDF-Sendung: Anwalt spricht von „Falschbehauptung des Innenministers“

08.10.2026

Die Berliner Linken-Politikerin Elif Eralp geht juristisch gegen Bundesinnenminister Alexander Dobrindt (CSU) vor. Eralp und ihr Berliner Landesverband haben nach Angaben ihres Rechtsbeistands Strafanzeige beziehungsweise Strafantrag gegen den Minister gestellt. Hintergrund ist eine Passage in der ZDF-Talkshow „Maybrit Illner“, in der sich die Moderatorin versprochen und Eralp in einem Satz fälschlich als Antisemitin bezeichnet hatte, bevor sie sich sofort korrigierte. Dobrindt kommentierte diese Szene mit den Worten „Na doch“.

Aus Sicht des von Eralp mandatierten Anwalts Jasper Prigge macht sich der Minister damit den Versprecher der Moderatorin zu eigen. In einem Schriftsatz, der mehreren Medien vorliegt, heißt es, Dobrindt stelle durch seine Einlassung eine Tatsachenbehauptung auf, die den Tatbestand der üblen Nachrede erfülle. Zudem liege eine Beleidigung vor, weil die Bezeichnung als Antisemitin „in erheblichem Maße ehrabträglich“ sei. Eralp habe sich nach Darstellung ihres Anwalts selbst nie in einer Weise geäußert, die als antisemitisch zu bezeichnen wäre, vielmehr trete sie öffentlich für den Schutz jüdischen Lebens ein.

Der Anwalt spricht von einer „Falschbehauptung des Innenministers“. Die Äußerung im Fernsehen sei geeignet, das öffentliche Wirken der Berliner Spitzenpolitikerin erheblich zu erschweren. In dem Schriftsatz wird darauf verwiesen, dass die Verbreitung des Eindrucks, Eralp würde selbst sagen, sie sei Antisemitin, ihre Integrität als politische Amtsträgerin infrage stellen und damit auch Auswirkungen auf politische Prozesse in Berlin haben könne. Eralp ist Spitzenkandidatin der Linken für das Rote Rathaus.

Die Auseinandersetzung hatte sich in der ZDF-Sendung an einem Schlagabtausch zwischen Dobrindt und der Linken-Bundestagsfraktionschefin Heidi Reichinnek entzündet. Während der Debatte unterlief Moderatorin Maybrit Illner der Versprecher, sie korrigierte sich jedoch unmittelbar mit dem Hinweis, Eralp sei „keine Antisemitin“. Dobrindts anschließender Kommentar bildet nun den Kern des juristischen Streits. Zu möglichen weiteren Schritten der Strafverfolgungsbehörden und einer Reaktion des Bundesinnenministers lagen zunächst keine näheren Angaben vor.