Mijn QA Engineer is een LLM
Claude kan op knoppen klikken.
Dat klinkt triviaal, maar het verandert hoe ik UI’s bouw. Met Playwright MCP schrijft Claude niet alleen code—het opent een browser, navigeert naar localhost en verifieert dat dingen daadwerkelijk werken. Het vangt bugs die ik zou missen in code review.
De Setup
Playwright MCP geeft Claude browserautomatisering. Ik voer het uit met headless Chromium:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@anthropic-ai/mcp-server-playwright", "--headless"]
}
}
}
Nu kan Claude navigeren, klikken, typen en screenshots maken. Het ziet wat gebruikers zien.
flowchart LR
Claude([Claude Code]) -->|browser_snapshot| PW[Playwright MCP]
PW --> Browser[Headless Chrome]
Browser --> App[localhost:1313]
Browser -.->|screenshot| Issue[(GitHub Issue)]
Issue -.->|visual history| PR[Pull Request]
flowchart TB
Claude([Claude Code]) -->|browser_snapshot| PW[Playwright MCP]
PW --> Browser[Headless Chrome]
Browser --> App[localhost:1313]
Browser -.->|screenshot| Issue[(GitHub Issue)]
Issue -.->|visual history| PR[Pull Request]
Flow: Claude Code → Playwright MCP → Browser → Screenshots → GitHub Issues → PR
De Viewport Matrix
Elke UI-wijziging wordt getest op drie breekpunten:
| Viewport | Grootte | Waarom |
|---|---|---|
| Desktop | 1440×900 | Standaard laptop |
| Tablet | 1024×768 | iPad portret |
| Mobile | 390×844 | iPhone 14 |
Claude wijzigt de browsergrootte, maakt een screenshot en uploadt het naar de GitHub issue. Drie screenshots per statuswijziging. Als de mobiele navigatie kapot is, zie ik het onmiddellijk—niet na deployment.
Thema Testen
Hetzelfde patroon voor lichte en donkere modus:
// Claude wisselt het thema
await page.click('[data-testid="theme-toggle"]');
// Screenshots beide staten
De CSS-variabele consistentie is belangrijk. Een component dat er goed uitziet in lichte modus kan onzichtbare tekst hebben in donkere modus. Claude vangt dit door daadwerkelijk naar beide te kijken.
Interactief Testen
Dit is waar het interessant wordt. Claude maakt niet alleen screenshots—het gebruikt de UI:
- Klikt op elke navigatielink, verifieert bestemming
- Opent de mobiele drawer, controleert of het animeert
- Vult formulieren in, verstuurt ze
- Hovert over interactieve elementen
- Sluit modals door op de achtergrond te klikken
Wanneer het een bug vindt—bijvoorbeeld, de drawer sluit niet wanneer je erbuiten tikt—rapporteert het dit, repareert de code en test opnieuw. De feedbackloop is strak.
De GitHub Issue als Testrapport
Elke screenshot wordt geüpload naar de GitHub issue. De issue body wordt opnieuw opgebouwd bij elke mijlpaal:
## Huidige Status
### Desktop (1440×900)
### Tablet (1024×768)
### Mobile (390×844)
## Test Checklist
- [x] Navigatielinks werken
- [x] Mobiele drawer opent/sluit
- [x] Themawisseling blijft behouden
- [ ] Formuliervalidatie toont fouten
De issue wordt een levend testrapport. Iedereen die de PR beoordeelt kan precies zien wat er getest is.
De Volledige Loop
Een typische feature doorloopt deze cyclus:
- Issue aangemaakt: “Voeg sidebar navigatie toe”
- Claude implementeert: Schrijft het component
- Visuele verificatie: Screenshots alle viewports
- Interactief testen: Klikt door de UI
- Bug gevonden: Drawer sluit niet bij achtergrondklik
- Fix toegepast: Werkt de click handler bij
- Re-test: Verse screenshots, allemaal geslaagd
- PR aangemaakt: Linkt naar issue met volledige visuele geschiedenis
Geen handmatige QA-stap. Geen “ziet er goed uit” zonder daadwerkelijk te kijken. Claude verifieert zijn eigen werk.
Wat Dit Vangt
Echte bugs die ik Claude heb zien vinden:
- Mobiele navigatie verborgen achter inhoud (z-index probleem)
- Knoptekst onzichtbaar in donkere modus (verkeerde CSS-variabele)
- Formulier verstuurt twee keer bij Enter-toets
- Dropdownmenu afgesneden door overflow:hidden parent
- Hover-status vastgezet op aanraakapparaten
Dit zijn de bugs die door code review glippen omdat ze alleen in de browser verschijnen. Claude ziet ze omdat het de code daadwerkelijk uitvoert.
Elke PR komt nu met bewijs dat het werkt.