मेरा QA इंजीनियर एक LLM है

2026-01-09 · 4 min read

Claude बटन क्लिक कर सकता है।

यह तुच्छ लगता है, लेकिन यह बदलता है कि मैं UI कैसे बनाता हूं। Playwright MCP के साथ, Claude सिर्फ कोड नहीं लिखता—यह एक ब्राउज़र खोलता है, localhost पर नेविगेट करता है, और सत्यापित करता है कि चीजें वास्तव में काम करती हैं। यह उन बग्स को पकड़ता है जिन्हें मैं कोड रिव्यू में चूक जाऊंगा।

सेटअप

Playwright MCP Claude को ब्राउज़र ऑटोमेशन देता है। मैं इसे हेडलेस Chromium के साथ चलाता हूं:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@anthropic-ai/mcp-server-playwright", "--headless"]
    }
  }
}

अब Claude नेविगेट, क्लिक, टाइप और स्क्रीनशॉट कर सकता है। यह वही देखता है जो यूज़र्स देखते हैं।

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]

फ्लो: Claude Code → Playwright MCP → ब्राउज़र → स्क्रीनशॉट्स → GitHub Issues → PR

व्यूपोर्ट मैट्रिक्स

प्रत्येक UI परिवर्तन तीन ब्रेकपॉइंट्स पर टेस्ट किया जाता है:

व्यूपोर्टसाइज़क्यों
Desktop1440×900स्टैंडर्ड लैपटॉप
Tablet1024×768iPad पोर्ट्रेट
Mobile390×844iPhone 14

Claude ब्राउज़र का आकार बदलता है, एक स्क्रीनशॉट लेता है, इसे GitHub Issue पर अपलोड करता है। प्रति स्टेट चेंज तीन स्क्रीनशॉट्स। अगर मोबाइल नेव टूटा हुआ है, तो मैं इसे तुरंत देखता हूं—डिप्लॉयमेंट के बाद नहीं।

थीम टेस्टिंग

लाइट और डार्क मोड के लिए समान पैटर्न:

// Claude थीम टॉगल करता है
await page.click('[data-testid="theme-toggle"]');
// दोनों स्टेट्स के स्क्रीनशॉट्स

CSS वेरिएबल कंसिस्टेंसी मायने रखती है। एक कम्पोनेन्ट जो लाइट मोड में अच्छा दिखता है, डार्क मोड में अदृश्य टेक्स्ट हो सकता है। Claude इसे वास्तव में दोनों को देखकर पकड़ता है।

इंटरएक्टिव टेस्टिंग

यहां यह दिलचस्प हो जाता है। Claude सिर्फ स्क्रीनशॉट नहीं लेता—यह UI का उपयोग करता है:

जब इसे एक बग मिलता है—मान लीजिए, ड्रॉअर बाहर टैप करने पर बंद नहीं होता—यह इसकी रिपोर्ट करता है, कोड ठीक करता है, और फिर से टेस्ट करता है। फीडबैक लूप टाइट है।

टेस्ट रिपोर्ट के रूप में GitHub Issue

हर स्क्रीनशॉट GitHub Issue पर अपलोड होता है। Issue बॉडी हर माइलस्टोन पर पुनर्निर्मित होती है:

## वर्तमान स्थिति

### Desktop (1440×900)
![desktop](https://user-images.githubusercontent.com/...)

### Tablet (1024×768)
![tablet](https://user-images.githubusercontent.com/...)

### Mobile (390×844)
![mobile](https://user-images.githubusercontent.com/...)

## टेस्टिंग चेकलिस्ट
- [x] नेविगेशन लिंक्स काम करते हैं
- [x] मोबाइल ड्रॉअर खुलता/बंद होता है
- [x] थीम टॉगल बना रहता है
- [ ] फॉर्म वैलिडेशन एरर्स दिखाता है

Issue एक जीवंत टेस्ट रिपोर्ट बन जाता है। PR की समीक्षा करने वाला कोई भी व्यक्ति वास्तव में देख सकता है कि क्या टेस्ट किया गया था।

पूर्ण लूप

एक विशिष्ट फीचर इस साइकिल से गुजरता है:

  1. Issue बनाया गया: “साइडबार नेविगेशन जोड़ें”
  2. Claude इम्प्लीमेंट करता है: कम्पोनेन्ट लिखता है
  3. विज़ुअल वेरिफिकेशन: सभी व्यूपोर्ट्स के स्क्रीनशॉट्स
  4. इंटरएक्टिव टेस्टिंग: UI के माध्यम से क्लिक करता है
  5. बग मिला: बैकड्रॉप क्लिक पर ड्रॉअर बंद नहीं होता
  6. फिक्स लागू किया गया: क्लिक हैंडलर अपडेट करता है
  7. रि-टेस्ट: फ्रेश स्क्रीनशॉट्स, सभी पास
  8. PR बनाया गया: पूर्ण विज़ुअल हिस्ट्री के साथ Issue से लिंक करता है

कोई मैनुअल QA स्टेप नहीं। वास्तव में देखे बिना कोई “अच्छा लग रहा है” नहीं। Claude अपने स्वयं के काम को सत्यापित करता है।

यह क्या पकड़ता है

वास्तविक बग्स जो मैंने Claude को खोजते देखा है:

ये वे बग्स हैं जो कोड रिव्यू में चूक जाते हैं क्योंकि वे केवल ब्राउज़र में दिखाई देते हैं। Claude उन्हें देखता है क्योंकि यह वास्तव में कोड चलाता है।

अब हर PR इस बात के प्रमाण के साथ आता है कि यह काम करता है।