Section 05 · Module 06 · Lesson 02 · ~20–24 นาที

หา Pattern ของ Flaky Tests ด้วย AI

บทนี้สอนใช้ AI วิเคราะห์ test history หลายร้อยรอบเพื่อหา pattern ของ flaky test ที่มนุษย์มองข้าม จัดกลุ่มสาเหตุ และเสนอวิธีแก้

เวลาเรียน: 20–24 นาที ต้องรู้มาก่อน: Section 4 - Debugging Flaky Tests และ Lesson 01 ของ M06 รูปแบบ: อ่าน + ตัวอย่าง dataset + แบบฝึก analyze pattern

จบบทนี้แล้วคุณจะ...

ใช้ AI วิเคราะห์ flaky test ระดับ suite (ไม่ใช่ทีละ test)
จัดกลุ่ม flaky test ตามสาเหตุร่วม (timing, state, env, data)
ระบุ "test ที่ flaky จริง" vs "test ที่ผิดเป็นครั้งคราว"
ตัดสินใจได้ว่า test ไหน fix, quarantine, หรือ delete

1 · ทำไม flaky ทีละ test ไม่ scale

ทีมใหญ่ต้องวิเคราะห์ระดับ suite

ทีมเล็ก: test fail → engineer ดู → แก้

ทีมใหญ่ที่มี 1000+ test, run หลายร้อย run ต่อวัน:

มี test ที่ flaky 30+ ตัว
แต่ละตัวอาจ fail 5% ของ run
ถ้าแก้ทีละตัว ใช้เวลาเป็นเดือน
ระหว่างแก้ มี test ใหม่ flaky เพิ่ม

วิธี scale ได้:

รวบรวม test history หลายสัปดาห์
ให้ AI หา pattern ที่ไม่เห็นจากการดูทีละตัว
จัดกลุ่มแก้พร้อมกันตาม root cause ร่วม

2 · เก็บ data ที่ใช้ analyze

CI ส่วนใหญ่ export ได้

ข้อมูลที่ต้องการ:

Field	ใช้ทำอะไร
test_id	track test เดียวกัน
run_timestamp	หา time-of-day pattern
status (pass/fail)	คำนวณ flaky rate
error_message	clustering สาเหตุ
duration	หา timeout pattern
browser	บาง flaky เกิดเฉพาะ browser
os	บาง flaky เกิดเฉพาะ OS
commit_sha	mapping ไป code change
ci_runner_id	บาง flaky จาก specific runner
retries	test ที่ผ่านหลัง retry

ส่วนใหญ่ดึงได้จาก Playwright report, GitHub Actions API, หรือ test analytics platform (Currents, BuildPulse)

3 · Prompt วิเคราะห์ pattern ระดับ suite

ส่ง dataset → ขอ insight

You are a test reliability engineer. Analyze this Playwright test history
to find flaky test patterns.

Dataset (CSV, last 30 days):
[PASTE 200-500 rows]

Context:
- Total tests in suite: 800
- CI runs per day: ~50
- Browser matrix: chromium, firefox, webkit
- OS matrix: ubuntu-latest, macos-latest

Questions:
1. Which tests have failure rate > 2% (true flaky vs occasional)?
2. Group flaky tests by suspected root cause:
   - timing / async issue
   - shared state
   - environment-specific
   - data-dependent
   - network-dependent
3. Are there time-of-day patterns? (e.g., mornings flaky more than afternoons)
4. Are there cross-test dependencies? (test A passes only after test B)
5. Top 5 actions to reduce flaky rate by the largest amount

หลักสำคัญ:

ส่ง data จริง > 100 row, ไม่ใช่ summary
ขอ ranking ของ "highest impact fix" — ทีมแก้ priority สูงก่อน
ขอ pattern ที่มนุษย์ไม่ได้คิด (time-of-day, cross-test dependency)

4 · ตัวอย่าง pattern ที่ AI หาเจอบ่อย

case ที่ทีมมักไม่เห็นจากการดูทีละตัว

Time-of-day pattern:

"Tests in e2e/checkout/* fail 3x more between 02:00-04:00 UTC. Hypothesis: nightly DB backup on shared environment causes intermittent slow query."

Browser-specific cluster:

"All flaky tests in e2e/forms/* are WebKit-only. Hypothesis: WebKit handles <input type='date'> differently — date picker tests need browser-specific timing."

Cross-test dependency:

"Test cart.add-multiple fails 80% when run after cart.bulk-import. Hypothesis: cleanup hook of bulk-import doesn't fully reset cart state."

Data-dependent:

"Tests using user fixture testuser-3 have 5% higher fail rate. Hypothesis: this fixture has email conflict with another fixture in some runs."

CI runner-specific:

"10 of last 30 failures occurred on runner ubuntu-latest-2-large. Hypothesis: this runner has hardware variance affecting timing."

แต่ละ pattern แก้ได้เฉพาะที่ ไม่ต้องไล่ทีละ test

5 · ตัดสินใจ: fix, quarantine, หรือ delete

ใช้ matrix ตัดสินใจ

Failure rate	Business value	ตัดสินใจ
> 10%	สูง	quarantine ทันที + fix priority สูง
> 10%	ต่ำ	delete (ไม่คุ้ม)
2-10%	สูง	fix ใน sprint ปัจจุบัน
2-10%	ต่ำ	quarantine + fix ใน backlog
< 2%	สูง	monitor 2 สัปดาห์ ถ้ายัง flaky → quarantine
< 2%	ต่ำ	delete

หลัก: test ที่ flaky จริง ๆ ไม่ควรอยู่ใน blocking suite

ตั้ง quarantine = run แต่ไม่ block CI, แสดงในรายงานสัปดาห์ละครั้ง — ทีมเห็นและตัดสินใจได้

6 · ป้องกัน flaky ก่อนเกิด

Pattern ที่เกิดบ่อยและวิธีกัน

สาเหตุ	วิธีกัน
`waitForTimeout`	ห้ามใช้, ใช้ `expect().toBeVisible()`
Shared test data	แต่ละ test สร้าง data ของตัวเอง + cleanup
External network call	mock external API
Time-dependent	freeze time ใน test
Random data	ใช้ seed คงที่
Browser-specific	run ทุก test บนทุก browser ตั้งแต่ commit
Order-dependent	randomize test order ใน CI

ใช้ AI ช่วย scan codebase หา anti-pattern เหล่านี้:

Scan our Playwright test files for these anti-patterns:
- waitForTimeout calls
- new Date() inside tests
- Math.random() inside tests
- Tests that share fixture state without cleanup

Output: list of files + line numbers + suggested fix.

Practice

แบบฝึก: วิเคราะห์ flaky pattern จาก data

ดู failure summary ด้านล่างจาก suite 30 วัน ระบุ pattern และเสนอ 3 action priority สูง:

Test ID                              | Runs | Failures | Browsers fail | Time pattern
-------------------------------------|------|----------|---------------|-------------
e2e/login/sso                        | 450  | 12       | webkit (10/12) | spread
e2e/login/standard                   | 450  | 2        | mixed          | spread
e2e/checkout/payment                 | 450  | 35       | all            | 02-04 UTC heavy
e2e/cart/add                         | 450  | 8        | all            | spread
e2e/cart/bulk-add                    | 450  | 18       | all            | runs after cart/add
e2e/cart/remove                      | 450  | 22       | all            | runs after cart/bulk-add
e2e/profile/upload                   | 450  | 3        | all            | spread
e2e/search/filter                    | 450  | 1        | chromium       | spread

ดูคำตอบแนะนำ

Pattern ที่เห็น:

e2e/login/sso — WebKit-specific (83% ของ fail). Hypothesis: SSO popup handling ต่างใน WebKit
e2e/checkout/payment — time-of-day pattern (02-04 UTC). Hypothesis: shared environment / nightly job
e2e/cart/* — cross-test dependency. bulk-add fail แล้วทำให้ remove fail. Hypothesis: cleanup ไม่ครบ

3 action priority สูง:

แก้ cart suite cleanup — แก้ที่เดียวลด failure ของ 2 test (40 fails/30d)
ตรวจ environment ตอน 02-04 UTC สำหรับ checkout — อาจต้องย้าย run นอก backup window
แยก SSO test เป็น WebKit-specific suite พร้อม browser-specific waiting

e2e/login/standard, profile/upload, search/filter failure rate < 1% — monitor

สิ่งที่ต้องเอาติดตัวไปจากบทนี้

ทีมใหญ่ต้องวิเคราะห์ flaky ระดับ suite ไม่ใช่ทีละ test
AI หา pattern (time, browser, cross-test) ที่มนุษย์ดูทีละตัวไม่เห็น
Matrix failure rate × business value ตัดสินใจ fix / quarantine / delete
ป้องกันก่อนเกิดด้วย rule (no waitForTimeout, no shared data, mock external)
Quarantine ดีกว่าปล่อย flaky test block CI ทำให้ทีมเริ่มเลิกเชื่อ test

← บทเรียนก่อนหน้า บทเรียนถัดไป →