ใช้ AI วิเคราะห์ Root Cause ของ Test Failure
บทนี้สอนใช้ AI ช่วยอ่าน failure log, stack trace, screenshot, และ trace file เพื่อ shortcut เวลา debug จากเป็นชั่วโมงให้เหลือเป็นนาที
จบบทนี้แล้วคุณจะ...
- ใช้ AI สรุป failure log ยาวให้เหลือ root cause ในประโยคเดียว
- รวม artifact หลายอย่าง (log + screenshot + DOM) ให้ AI ช่วยวิเคราะห์
- คัดกรอง suggestion ของ AI ที่อาจชี้ผิดทาง
- สร้าง bug report ที่มีคุณภาพจาก analysis ของ AI
Test fail 1 ครั้ง = อ่าน log 5-50 หน้า
เมื่อ E2E test fail ใน CI สิ่งที่ engineer ต้องอ่าน:
- console log ของ test runner
- network log (HTTP requests + responses)
- browser console error
- screenshot ของหน้าตอน fail
- video / trace file
- application log ของ backend
- diff ของ code ที่ commit ล่าสุด
รวม artifact 100-1000 บรรทัด ใช้เวลาอ่านมัธยฐาน 15-30 นาทีต่อ failure
ทีมที่มี 50 failures ต่อสัปดาห์ = 25 ชั่วโมง engineer time แค่ "อ่านให้เข้าใจปัญหา" — ยังไม่นับเวลาแก้
Prompt ที่ได้คำตอบที่ใช้งานได้จริง
You are a senior test engineer debugging a Playwright test failure.
Test that failed:
[PASTE TEST CODE]
Error message:
[PASTE FROM CONSOLE]
Recent stack trace (last 20 lines):
[PASTE]
Network log (failed requests only):
[PASTE]
Browser console errors:
[PASTE]
Recent code changes (last 5 commits):
[PASTE git log]
Question:
1. What is the most likely root cause?
2. Confidence level (high / medium / low) and why
3. What additional info would increase confidence?
4. Suggested next step for the engineer
หลักสำคัญ:
- ใส่ artifact หลายแบบ — AI cross-reference ได้
- ขอ confidence level → กัน hallucination
- ขอ "additional info" → ทำให้ AI บอกตรง ๆ ว่ายังขาดอะไร
ดูว่าได้ output ที่ใช้งานได้แค่ไหน
Test:
test('user can submit order', async ({ page }) => {
await page.goto('/cart');
await page.getByRole('button', { name: 'Checkout' }).click();
await page.getByLabel('Card').fill('4242424242424242');
await page.getByRole('button', { name: 'Pay' }).click();
await expect(page).toHaveURL(/\/order\/success/);
});
Error:
TimeoutError: page.waitForURL: Timeout 30000ms exceeded
at /tests/checkout.spec.ts:7:21
Network log:
POST /api/payment → 500 Internal Server Error
{ "error": "stripe_token_invalid" }
Console:
Error: Payment failed
at PaymentForm.handleSubmit (PaymentForm.tsx:42)
Recent commits:
abc123 - Update Stripe SDK to v14
def456 - Refactor PaymentForm component
AI analysis:
Most likely root cause: Stripe SDK v14 upgrade (commit abc123) likely changed the test card token format or API. Card number 4242424242424242 is the standard Stripe test card and should work — suggesting the request format changed (e.g., now requires explicit token creation step before submit).
Confidence: Medium-High. The 500 with "stripe_token_invalid" + recent SDK upgrade is a strong signal, but I can't confirm without seeing the migration notes.
Additional info needed: Stripe SDK v14 changelog, full request body sent to /api/payment, and whether dev/staging Stripe key was updated.
Next step: Check Stripe v14 migration guide for breaking changes in card tokenization. Verify with backend log whether the request payload matches v14 expected format.
นี่คือ output ที่ engineer สามารถใช้ตัดสินใจ next action ได้ทันที — ประหยัดเวลา 20+ นาทีของการ trace ผ่าน source หลายจุด
red flag ที่ต้องระวัง
สัญญาณ AI กำลังเดา:
- ตอบโดยไม่ขอ artifact เพิ่ม ทั้งที่ข้อมูลให้น้อย
- คำตอบดู generic: "อาจเป็น network issue, อาจเป็น race condition, อาจเป็น..."
- อ้างอิง class / function / line ที่ไม่อยู่ใน input
- ไม่บอก confidence level
วิธีจัดการ:
- บังคับให้ AI ระบุ confidence ทุกครั้ง
- ถาม "ถ้าให้ข้อมูลเพิ่ม ต้องการอะไร?"
- ห้ามเชื่อ analysis ที่อ้างถึงสิ่งที่คุณไม่ได้ใส่
- run hypothesis ที่ AI suggest ก่อน commit แก้
4 ขั้นที่ทำซ้ำได้
- Collect artifact: log, trace, screenshot, recent commits — รวมในที่เดียว
- Initial analysis: prompt AI ขอ root cause + confidence
- Verify hypothesis: ลอง reproduce, อ่าน source ที่ AI ชี้ ตรงกับที่ AI บอกไหม
- Fix or escalate: ถ้า confidence สูงและ verify แล้ว → fix; ถ้าไม่ → ถาม dev เจ้าของ feature
ใช้ AI เป็น "ผู้ช่วย first responder" ไม่ใช่ "ผู้ตัดสินใจสุดท้าย"
AI gen draft, คุณ polish
Based on the analysis above, write a bug report following our template.
Template:
- Title (clear, < 80 chars)
- Severity (Blocker / Critical / Major / Minor)
- Steps to reproduce (numbered)
- Actual result
- Expected result
- Environment (browser, OS, build)
- Attachments (list trace file paths)
- Suspected root cause
- Suggested next action
จะได้ draft ที่ใส่ใน Jira ได้ทันที — engineer แค่อ่าน, ปรับ severity ตาม business judgment, และ submit
ประหยัดเวลาเขียน bug report จาก 10-15 นาทีเหลือ 2-3 นาที
แบบฝึก: analyze failure ด้วย AI
ใช้ failure ด้านล่างกับ AI ของคุณ ขอ root cause + confidence + next step:
Test:
test('search returns results', async ({ page }) => {
await page.goto('/search?q=laptop');
await expect(page.getByTestId('result-item')).toHaveCount(10);
});
Error:
expect(received).toHaveCount(expected) // count
Expected: 10
Received: 0
Network log:
GET /api/search?q=laptop → 200 OK
Response: { "results": [], "total": 0 }
Recent commits:
xyz789 - Update search index pipeline
abc456 - Add geolocation filter to search
Console: (no errors)
DOM at failure:
<div data-testid="search-empty">No results found</div>
ดูคำตอบแนะนำ (สิ่งที่ analysis ที่ดีควรชี้)
- Root cause: API ตอบ
total: 0แสดงว่าไม่ใช่ frontend bug — ปัญหาอยู่ฝั่ง backend - Suspect: "Add geolocation filter to search" (commit abc456) อาจเพิ่ม filter ที่ require user location ที่ test environment ไม่มี → no result
- Confidence: สูง (network log ตอบ 200 + empty result + recent change ที่เกี่ยวข้องชัดเจน)
- Next step:
- ตรวจ commit abc456 ว่า geolocation filter mandatory หรือ optional
- ถ้า mandatory: test ต้อง mock geolocation หรือเปลี่ยน query ให้ skip filter
- ถ้า optional: backend อาจมี bug ที่ filter ทำงานเสมอ
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- AI ลดเวลาอ่าน log + cross-reference จากชั่วโมงเหลือเป็นนาที
- ใส่ artifact หลายแบบใน prompt และขอ confidence level เสมอ
- จับ AI hallucinate ด้วยการ verify ทุก reference ที่ AI ชี้
- AI = first responder ไม่ใช่ผู้ตัดสินใจสุดท้าย — verify ก่อน commit fix
- AI gen draft bug report จาก analysis ได้เร็ว — engineer แค่ polish + submit