Recap of Sadik Bakiu’s talk at Swiss Testing Day 2026

Playwright scales the compute, but who writes the tests? Sadik Bakiu, CEO of TestResults.io, demonstrated live at Swiss Testing Day 2026 how the Model Context Protocol (MCP) bridges the gap: AI agents that plan, generate, and self-heal tests: controlled in natural language.

 

Key Takeaways

• Two dimensions of scaling: Playwright handles compute (parallelization, sharding, worker isolation), LLMs + MCP handle human capacity (authoring, debugging, maintenance)
• MCP is the USB-C for AI: An open standard connecting AI clients to external systems like the browser:  vendor-neutral
• Three Playwright agents: Planner (plans tests), Generator (writes tests), Healer (fixes failing tests)
• Accessibility tree is the key: Playwright works text-based via the accessibility tree, exactly the domain where LLMs excel
• 32 releases in 6 months: The ecosystem is evolving rapidly:  32 new Playwright MCP Server releases since September 2025

•   

The Problem: Writing Tests Doesn’t Scale

Playwright excels at running tests quickly and reliably. Parallelization on a single machine, sharding across multiple machines, worker isolation for clean test environments & the compute side is solved.

But Playwright doesn’t write tests. It doesn’t debug tests. It doesn’t maintain tests. Human capacity remains the bottleneck: Who writes the tests? Who analyzes failures? Who adapts tests when the code changes?

 

“Playwright itself is not going to write the tests for you. It’s also not going to do the debugging. It’s not going to do the maintenance. And here is where LLMs and MCP actually help us.” — Sadik Bakiu

 

MCP: The USB-C Standard for AI

The Model Context Protocol (MCP), originally developed by Anthropic and now under neutral governance, standardizes communication between AI applications and external systems.

MCP as USB-C for AI: An open standard with plugin architecture connecting AI clients to any server, vendor-independently

 

Without MCP, every AI application builds custom implementations, custom prompt logic, custom tool calls, and custom data access. That means redundancy and wasted effort. With MCP, there’s one standardized interface: an MCP client (Claude, Cursor, Windsurf, or a custom client) connects to any number of MCP servers: Playwright for the browser, Atlassian for JIRA and Confluence, or custom servers for internal systems.

 

With MCP: Any MCP client connects via a standardized interface to Playwright, Atlassian, GitLab, or custom on-prem servers

 

The core primitive is Tools: they define what a server can do. browser_click, browser_close, browser_type, browser_wait_for — the LLM autonomously decides which tool to use and when.

 

Playwright MCP: AI Controls the Browser

Microsoft’s Playwright MCP Server gives AI clients access to the browser. The decisive advantage: Playwright uses the accessibility tree. This means the LLM works with text, not screenshots or pixel data. And text is exactly what LLMs process exceptionally well.

After the MCP server, Microsoft published three specialized agents:

• • Planner: plans test scenarios based on the application

• • Generator: generates Playwright test code from plans

• • Healer: analyzes and repairs failing tests

The end-to-end flow: Natural language → MCP Host → LLM selects tools → Playwright MCP translates to API calls → Browser executes → LLM evaluates the result

  

Live Demo: From Planning to Self-Healing

Bakiu demonstrated the complete cycle using a simple todo application:

Step 1 – Planner: Given the prompt “Use the planner agent to create a plan for one test that adds a todo item,” the AI generated a structured test plan document with an application overview, test steps, and expected results.

Step 2 – Generator: The Generator agent read the plan and produced a complete Playwright test: navigate to page, verify title, fill text field, click button, verify result.

Step 3 – Healer: Bakiu changed the source code. The button text changed from “Add an item” to “Add todo.” The test failed. The Healer agent analyzed the failure, identified the root cause, updated the assertion, and re-ran the test – green.

 

“This is actually the magic in my opinion, because now I don’t have to actually go ahead myself and figure out every little detail that changed in the source code and change the test myself. AI can proactively do this for me.” — Sadik Bakiu

 

Critical insight from the demo: The Healer must be explicitly instructed to adjust the test, not the source code. Without this instruction, the agent would change the production code to make the test pass. Functionally correct in a TDD sense, but not the desired behavior.

 

 

On-Prem and Vendor-Neutral

When asked about on-premises deployments, the answer was clear: MCP doesn’t require a cloud LLM. If you host an LLM locally, you can use the Playwright MCP Server without an internet connection. The standard is vendor-neutral: Claude, Codex, Copilot, Cursor, or a custom client all work equally well.

 

Looking Ahead: A Fast-Moving Ecosystem

Bakiu made the pace of change tangible: between talk planning (September 2025) and presentation (March 2026), 32 new Playwright MCP releases shipped, nearly half of all versions ever published. During that time, Microsoft added the agents and the CLI with skills integration.

The conclusion: anyone experimenting with MCP and Playwright today is early. But the ecosystem is mature enough for productive use, and it’s evolving so fast that waiting may be the riskier strategy.

 

Conclusion: Testers Won’t Become Obsolete — But Collaboration Will Change

When asked whether AI would change the relationship between developers and testers, Bakiu’s answer was nuanced: it will strengthen communication, not replace it. Developers must build testable software. Testers must communicate what’s happening with the tools they’re testing. AI won’t make testers unnecessary — it will make collaboration even more important.

 

 

---

 

 

Test Automation at Scale: Wie MCP und Playwright die Testentwicklung revolutionieren

 

Rückblick auf den Vortrag von Sadik Bakiu am Swiss Testing Day 2026

Playwright skaliert die Rechenleistung, aber wer schreibt die Tests? Sadik Bakiu, CEO von TestResults.io, zeigte am Swiss Testing Day 2026 live, wie das Model Context Protocol (MCP) die Lücke schliesst: KI-Agenten, die Tests planen, generieren und selbständig reparieren, gesteuert in natürlicher Sprache.

 

 

Key Takeaways

• Zwei Dimensionen beim Skalieren: Playwright löst die Compute-Seite (Parallelisierung, Sharding, Worker-Isolation), LLMs + MCP lösen die Human-Capacity-Seite (Schreiben, Debugging, Wartung)
• MCP ist das USB-C für KI: Ein offener Standard, der KI-Clients herstellerunabhängig mit externen Systemen wie dem Browser verbindet
• Drei Playwright-Agenten: Planner (plant Tests), Generator (schreibt Tests), Healer (repariert fehlgeschlagene Tests)
• Accessibility Tree als Schlüssel: Playwright arbeitet textbasiert über den Accessibility Tree, genau die Domäne, in der LLMs stark sind
• 32 Releases in 6 Monaten: Das Ökosystem entwickelt sich rasant: seit September 2025 gab es 32 neue Releases des Playwright MCP Servers

•   

Das Problem: Tests schreiben skaliert nicht

Playwright ist hervorragend darin, Tests schnell und zuverlässig auszuführen. Parallelisierung auf einer Maschine, Sharding über mehrere Maschinen, Worker-Isolation für saubere Testumgebungen. Die Compute-Seite ist gelöst.

Aber Playwright schreibt keine Tests. Es debuggt keine Tests. Es wartet keine Tests. Die menschliche Kapazität bleibt der Engpass: Wer schreibt die Tests? Wer analysiert Fehler? Wer passt Tests an, wenn sich der Code ändert?

 

“Playwright itself is not going to write the tests for you. It’s also not going to do the debugging. It’s not going to do the maintenance. And here is where LLMs and MCP actually help us.” — Sadik Bakiu

 

MCP: Der USB-C-Standard für KI

Das Model Context Protocol (MCP), ursprünglich von Anthropic entwickelt und mittlerweile in neutraler Governance, standardisiert die Kommunikation zwischen KI-Anwendungen und externen Systemen.

 

MCP als USB-C für KI: Ein offener Standard mit Plugin-Architektur, der KI-Clients herstellerunabhängig mit beliebigen Servern verbindet

 

 

Ohne MCP baut jede KI-Anwendung eigene Implementierungen, eigene Prompt-Logik, eigene Tool-Calls und eigenen Datenzugriff. Das bedeutet Redundanz und verschwendeten Aufwand. Mit MCP gibt es eine standardisierte Schnittstelle: Ein MCP-Client (Claude, Cursor, Windsurf oder ein eigener Client) verbindet sich mit beliebig vielen MCP-Servern: Playwright für den Browser, Atlassian für JIRA und Confluence, oder eigene Server für interne Systeme.

 

 

Mit MCP: Ein beliebiger MCP-Client verbindet sich standardisiert mit Playwright, Atlassian, GitLab oder eigenen On-Prem-Servern

 

Das Kernprimitive sind Tools: Sie definieren, was ein Server kann. browser_click, browser_close, browser_type, browser_wait_for — das LLM entscheidet autonom, welches Tool es wann einsetzt.

 

 

Playwright MCP: KI steuert den Browser

Microsofts Playwright MCP Server gibt KI-Clients Zugriff auf den Browser. Der entscheidende Vorteil: Playwright nutzt den Accessibility Tree. Das bedeutet, das LLM arbeitet mit Text, nicht mit Screenshots oder Pixeldaten. Und Text ist genau das, was LLMs hervorragend verarbeiten.

Nach dem MCP-Server veröffentlichte Microsoft drei spezialisierte Agenten:

• • Planner: plant Testszenarien basierend auf der Anwendung

• • Generator: generiert Playwright-Testcode aus den Plänen

• • Healer: analysiert und repariert fehlgeschlagene Tests

Der End-to-End-Flow: Natürliche Sprache → MCP Host → LLM wählt Tools → Playwright MCP übersetzt in API-Calls → Browser führt aus → LLM bewertet das Ergebnis

 

Live-Demo: Von der Planung bis zur Reparatur

Bakiu demonstrierte den kompletten Zyklus anhand einer einfachen Todo-Anwendung:

Schritt 1 – Planner: Auf den Prompt “Use the planner agent to create a plan for one test that adds a todo item”generierte die KI ein strukturiertes Testplan-Dokument mit Application Overview, Testschritten und erwarteten Ergebnissen.

Schritt 2 – Generator: Der Generator-Agent las den Plan und erzeugte einen vollständigen Playwright-Test: Seite aufrufen, Titel prüfen, Textfeld füllen, Button klicken, Ergebnis verifizieren.

Schritt 3 – Healer: Bakiu änderte den Quellcode: der Button-Text wechselte von “Add an item” zu “Add todo”. Der Test schlug fehl. Der Healer-Agent analysierte den Fehler, identifizierte die Ursache, passte die Assertion an und liess den Test erneut laufen – grün.

 

“This is actually the magic in my opinion, because now I don’t have to actually go ahead myself and figure out every little detail that changed in the source code and change the test myself. AI can proactively do this for me.” — Sadik Bakiu

 

Wichtige Erkenntnis aus der Demo: Der Healer muss explizit angewiesen werden, den Test anzupassen, nicht den Quellcode. Ohne diese Anweisung würde der Agent den Produktionscode ändern, um den Test zu bestehen. Funktional korrekt im TDD-Sinne, aber nicht das gewünschte Verhalten.

 

On-Prem und herstellerunabhängig

Auf die Frage nach On-Prem-Deployments war die Antwort klar: MCP braucht kein Cloud-LLM. Wer ein LLM lokal hostet, kann den Playwright MCP Server ohne Internetverbindung nutzen. Der Standard ist vendor-neutral: Claude, Codex, Copilot, Cursor oder ein eigener Client funktionieren gleichermassen.

 

 

Der Blick nach vorn: Schnelllebiges Ökosystem

Bakiu machte die Geschwindigkeit der Veränderung greifbar: Zwischen Talkplanung (September 2025) und Vortrag (März 2026) erschienen 32 neue Playwright MCP Releases, fast die Hälfte aller jemals veröffentlichten Versionen. Microsoft ergänzte in dieser Zeit die Agenten und das CLI mit Skills-Integration.

Die Schlussfolgerung: Wer heute mit MCP und Playwright experimentiert, ist früh dran. Aber das Ökosystem ist reif genug für produktive Nutzung. Und es entwickelt sich so schnell, dass Abwarten die riskantere Strategie ist.

 

 

Fazit: Tester werden nicht überflüssig — aber die Zusammenarbeit ändert sich

Auf die Frage, ob KI die Beziehung zwischen Entwicklern und Testern verändere, antwortete Bakiu differenziert: Es wird die Kommunikation verstärken, nicht ersetzen. Entwickler müssen Software testbar bauen. Tester müssen kommunizieren, was mit den Tools passiert. KI macht Tester nicht überflüssig — sie macht die Zusammenarbeit noch wichtiger.

 

 

---

Konferenz: Swiss Testing Day 2026, 26. März 2026, StageOne Zürich Speaker: Sadik Bakiu, CEO, TestResults.ioLinkedIn: linkedin.com/in/sbakiu | Web: www.testresults.io