E2E Testing mit Claude Code

Hintergrund

Wir alle kennen den Moment kurz vor Release: Eigentlich ist das Feature fertig – jetzt müsste es nur noch jemand gründlich testen.

In der Praxis fühlt sich Testing oft nach einer ziemlich unfairen Version des Pareto-Prinzips an: Die ersten 80 % eines Features gehen schnell – die letzten 20 % bestehen plötzlich aus Browser klicken, Edge Cases prüfen und Bugs jagen.

Ein eigenes QA-Team? Außerhalb von Enterprise oft Wunschdenken. Gerade kleinere Teams oder Start-ups haben dafür schlicht weder Budget noch Leute. Ich arbeite meistens in kleineren Teams oder Start-ups – und genau dort begegnet mir dieses Problem ständig.

Als ich dann eines Abends wieder durch die LinkedIn „KI ersetzt alle Entwickler“-Apokalypse scrollte, kam mir schließlich der Gedanke, einfach meinen nicht vorhandenen Testing-Kollegen durch KI zu ersetzen.

Also habe ich beschlossen, meinen imaginären QA-Kollegen einfach zu bauen – beziehungsweise von Claude Code spielen zu lassen.

Konzept

Die Idee: Claude soll sich wie ein echter Tester benehmen. Browser öffnen, Dinge klicken, Flows ausprobieren und dabei idealerweise Fehler finden, die mir selbst längst nicht mehr auffallen. Es geht also darum, die Anwendung als Ganzes zu testen (Ende-zu-Ende)

Dafür brauche ich am Ende nur drei Dinge:

• Claude Code (erfordert ein bezahltes Abo bei Anthropic)
• Playwright CLI, sodass Claude Code aus dem Terminal einen Browser simulieren kann
• einen Claude Code Skill, der über einen Sub-Agenten das Testing bestimmter „Test Suites“ auslöst und deren Spezifikationen versteht

Der Testing-Flow

Installation

Node und NPM müssen installiert sein. Letzteres wird gemeinsam mit Node installiert.

Claude Code

Claude Code ist das CLI-Tool von Claude. Über das Terminal lassen sich Prompts eingeben, Agenten starten usw. Die Installationsschritte je nach Plattform finden sich auf der Anthropic Website.

Beachte: Ein bezahltes Abo-Modell bei Anthropic wird benötigt, um Claude Code zu nutzen.

Playwright-CLI

Für den Browser-Part nutze ich Playwright – Microsofts Tool fürs automatisierte Testen von Websites und Apps. Es bietet dafür eine CLI an, die Claude Code direkt nutzen kann.

Die CLI lässt sich über folgende Befehle installieren:

        npm install -g playwright
npx playwright install

      

Ich nutze hier bewusst die Playwright CLI statt MCP – schlicht weil der Tokenverbrauch in meiner Erfahrung deutlich niedriger ist.

Zum Schluss braucht Claude Code noch den passenden Skill, um die Playwright CLI nutzen zu können.

        npx skills add https://github.com/microsoft/playwright-cli --skill playwright-cli

      

Skills

Ein Skill kapselt wiederkehrende Anweisungen und gibt Claude Code die Möglichkeit diese explizit oder bei Bedarf zu verwenden.

Ich habe einen Testing Skill entwickelt, um meine "Test Suites" bei Bedarf ausführen zu können. Das ist am Ende mit der Anweisung /test <test-name> möglich.

Der Skill lässt sich direkt von Claude Code erstellen (dazu entsprechend prompten) oder manuell anlegen.

Skills werden im Verzeichnis /.claude/skills/<skill-name>.md gespeichert. Diese Markdown-Datei enthält die Anweisungen, die im Rahmen des Skills an Claude Code übergeben werden.

Sub-Agenten

Sub-Agenten sind spezialisierte Assistenten, die spezielle Aufgabenbereiche ausfüllen. Eine Claude Code Session kann auf Anweisung oder bei Bedarf Sub-Agenten erzeugen, um diese speziellen Aufgaben (z. B. Testing, Bug Reporting) zu lösen.

Das eigentliche Testing übernimmt für uns ein spezialisierter Testing Sub-Agent.

Diesen kann Claude Code erstellen. Alternative lässt er sich manuell per /agents Anweisung anlegen.

Test Skill & Agent

Skill

In skills/test/SKILL.md.

        ---
name: test
description: Does real application testing. Reads a natural-language spec, interacts with the applications via the Playwright CLI, produces a findings file, waits for the user to triage it, then optionally hands off to Asana. Use when the user wants to test a flow in one of the apps.
argument-hint: <test-name>
disable-model-invocation: false
---

# Testing workflow orchestrator

Drive the full loop: test → triage → Asana.

## Step 1: Resolve the spec path

`$ARGUMENTS` is a test name (e.g. `customer-creation`): resolve as `claude/tests/$ARGUMENTS/spec.md`

The resolved test name is used throughout the rest of the flow.

## Step 2: Run the tests

Invoke the `testing-agent` subagent, passing only the resolved spec path and test name.
**Do not pre-write or include test scripts in the prompt** — the subagent derives and runs its own
Playwright CLI scripts per requirement. The subagent will:

- Read the spec and credentials independently
- Write and execute small Playwright CLI scripts via Bash to interactively verify each requirement
- Take screenshots only when a bug or suspicious behaviour is found, saved to the findings folder
- Write findings to `claude/tests/<test-name>/findings/<today>.md` using the bug-report skill format

If the subagent reports a setup error (staging unreachable, login broken),
stop and relay the error to the user — do not continue to triage.

## Final report

Summarize the run for the user and highlight the findings

      

Agent

In agents/testing-agent.md.

        ---
name: testing-agent
description: Tests web applications by interacting with them via the playwright CLI and checking provided requirements
tools: Read, Write, Edit, Bash, Glob, Grep
---

You are the testing agent for this project. Your job: understand a natural-language
test spec and interact with the related applications to verify that defined requirements are implemented
and behave as expected.

**Your input**: A spec file at `.claude/tests/<test-name>/spec.md` — labeled requirements
  (A1, A2, …) describing how the flow should behave.

use the credentials from `.env` to authenticate: `TEST_USERNAME`, `TEST_PASSWORD`

## Workflow

1. **Read the spec.** Open `.claude/tests/<test-name>/spec.md`. Identify
   each requirement by its ID (A1, A2, …). Get an understanding of which applications (Admin, B2B, Web) you will need to access.

2. **Conduct the test using `playwright-cli` via Bash.**

3. **Collect artifacts.**
   When you find a bug or suspicious behaviour, run `playwright-cli screenshot claude/tests/<test-name>/findings/<id>.png` before moving on.

4. **Write findings** to
   `.claude/tests/<test-name>/findings/<YYYY-MM-DD>.md` — a markdown table with
   columns `ID | Requirement | Severity | Summary`.

5. **Report back** with a short summary: how many requirements tested, how many findings, and the findings file path.

      

In unserem Beispiel greift der Agent auf die .env zu, um Login Credentials für unsere App abzuholen. Ich empfehle dringend diese nicht im Agenten selbst abzulegen.

Eine Test-Suite

Eine Test-Suite kombiniert zusammengehörige Tests. Für unseren Testing-Agenten konsolidieren wir alle Anforderungen an ein bestimmtes Feature in <test-name>/spec.md und stellen Claude falls nötig weitere Hintergrundinformationen zur Verfügung.

Beispiel: .claude/tests/user-registration/spec.md

        # User Registration

## Scope

End-to-end user registration in our staging environment

* URL: https://staging.i-am-a-dummy.com

## Requirements

- **A1** Login with valid Credentials: Use your dummy credentials to log in, confirm that it works

- **A2** Register with existing email address: When trying to register a new user with an existing email address (like the one you log in with) the message "Email already exists" should be shown

## Notes for the agent

- use your built-in dummy credentials to conduct this test

      

Finale Ordnerstruktur

        .
├── .claude/
│   ├── agents/
│   │   └── testing-agent.md
│   ├── skills/
│   │   └── test/
│   │       └── SKILL.md
│   └── tests/
│       └── user-registration/
│           ├── spec.md
│           └── findings/
│               └── 2026-05-26.md
├── .env
└── ...

      

Ausführen einer Test-Suite

Sobald alles steht, lässt sich eine Test-Suite mit dem folgenden Befehl innerhalb einer Claude Code Session ausführen:

        /test user-registration

      

Daraufhin:

• aktiviert Claude den test Skill unter skills/test/SKILL.md
• dieser liest .claude/tests/user-registration/spec.md ein
• und erzeugt einen neuen Test-Agenten, der via Playwright CLI unsere Ziel-App gegen die formulierten Anforderungen testet.

Ein Ergebnis in findings.md könnte folgendermaßen aussehen:

        | ID | Requirement | Severity | Summary |
|----|-------------|----------|---------|
| A1 | Login with valid credentials | PASSED | User can log in successfully. |
| A2 | Register with existing email | BUG | System shows a generic 500 error instead of "Email already exists". |

      

Ausblick

Ersetzt das menschliche Testing? Natürlich nicht. Spart es mir Stunden an stupidem Durchklicken und findet dabei erstaunlich viele Bugs? Überraschend oft schon.

Der Testing-Skill zeigt, wie KI menschliches Testen simulieren und E2E-Tests auf ein neues Level heben kann.

Besonders mit einem Modell wie Opus können grandiose Ergebnisse entstehen. Mit großen Kontextfenstern testet Claude Code nicht nur die Anforderungen, sondern gibt in Teilen auch tieferes Feedback, beispielsweise über die Sinnhaftigkeit von Eingabefeldern, Buttons oder Formulierungen. In aller Regel wird auch die Browser-Konsole geprüft und auf Fehlermeldungen aufmerksam gemacht (was menschliche Tester in der Regel nicht tun).

Auf der anderen Seite ist das Ganze natürlich sehr token-intensiv (und damit teuer). Immer wenn ein Dritt-Tool benötigt wird, werden deutlich mehr Tokens verbraucht als bei einfachen Abfragen via Prompt. Durch den Verzicht auf die Nutzung einer MCP-Integration sparen wir hier zwar jede Menge Tokens ein (versuche gerne mal den Playwright MCP und vergleiche den Verbrauch), jedoch ist diese Testing-Lösung wohl eher für Enterprise-Pläne geeignet.

Abhilfe schaffen könnte hier das gleichzeitige Generieren von Playwright-Tests nach dem interaktiven Testen, was aber wiederum den Sinn des Test-Agenten untergräbt.