Il Mio QA Engineer è un LLM
Claude può cliccare sui pulsanti.
Sembra banale, ma cambia il modo in cui costruisco le UI. Con Playwright MCP, Claude non si limita a scrivere codice—apre un browser, naviga su localhost e verifica che le cose funzionino davvero. Cattura bug che perderei nelle revisioni del codice.
La Configurazione
Playwright MCP dà a Claude l’automazione del browser. Lo eseguo con Chromium headless:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@anthropic-ai/mcp-server-playwright", "--headless"]
}
}
}
Ora Claude può navigare, cliccare, digitare e fare screenshot. Vede ciò che vedono gli utenti.
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]
Flusso: Claude Code → Playwright MCP → Browser → Screenshot → GitHub Issues → PR
La Matrice dei Viewport
Ogni modifica UI viene testata a tre breakpoint:
| Viewport | Dimensioni | Perché |
|---|---|---|
| Desktop | 1440×900 | Laptop standard |
| Tablet | 1024×768 | iPad verticale |
| Mobile | 390×844 | iPhone 14 |
Claude ridimensiona il browser, fa uno screenshot, lo carica sulla issue di GitHub. Tre screenshot per cambio di stato. Se la navigazione mobile è rotta, lo vedo immediatamente—non dopo il deployment.
Test dei Temi
Stesso schema per modalità chiara e scura:
// Claude cambia il tema
await page.click('[data-testid="theme-toggle"]');
// Screenshot di entrambi gli stati
La coerenza delle variabili CSS conta. Un componente che appare bene in modalità chiara potrebbe avere testo invisibile in modalità scura. Claude lo cattura guardando effettivamente entrambi.
Test Interattivi
Qui diventa interessante. Claude non fa solo screenshot—usa la UI:
- Clicca su ogni link di navigazione, verifica la destinazione
- Apre il drawer mobile, controlla che si animi
- Compila i moduli, li invia
- Passa sopra gli elementi interattivi
- Chiude i modal cliccando sullo sfondo
Quando trova un bug—diciamo, il drawer non si chiude quando tocchi fuori—lo segnala, corregge il codice e ritesta. Il ciclo di feedback è stretto.
La Issue GitHub come Report di Test
Ogni screenshot viene caricato sulla issue di GitHub. Il corpo della issue viene ricostruito ad ogni milestone:
## Stato Attuale
### Desktop (1440×900)
### Tablet (1024×768)
### Mobile (390×844)
## Checklist di Test
- [x] I link di navigazione funzionano
- [x] Il drawer mobile apre/chiude
- [x] Il cambio tema persiste
- [ ] La validazione del modulo mostra errori
La issue diventa un report di test vivente. Chiunque riveda la PR può vedere esattamente cosa è stato testato.
Il Ciclo Completo
Una funzionalità tipica passa attraverso questo ciclo:
- Issue creata: “Aggiungi navigazione sidebar”
- Claude implementa: Scrive il componente
- Verifica visuale: Screenshot di tutti i viewport
- Test interattivi: Clicca attraverso la UI
- Bug trovato: Il drawer non si chiude al clic sullo sfondo
- Fix applicata: Aggiorna il click handler
- Ri-test: Screenshot freschi, tutto passa
- PR creata: Link alla issue con storia visuale completa
Nessun passo di QA manuale. Nessun “sembra buono” senza guardare davvero. Claude verifica il proprio lavoro.
Cosa Cattura Questo
Bug reali che ho visto Claude trovare:
- Navigazione mobile nascosta dietro il contenuto (problema di z-index)
- Testo del pulsante invisibile in modalità scura (variabile CSS sbagliata)
- Modulo che invia due volte con il tasto Enter
- Menu dropdown tagliato da parent con overflow:hidden
- Stato hover bloccato su dispositivi touch
Questi sono i bug che sfuggono alle revisioni del codice perché appaiono solo nel browser. Claude li vede perché esegue effettivamente il codice.
Ogni PR ora arriva con la prova che funziona.