การตั้งชื่อและการดูแลรักษา

ทีม QA ของบริษัทประกันภัยภูมิใจมากที่สร้าง automation test ได้ 2,000 เคสภายใน 2 ปี จำนวนเพิ่มขึ้นเรื่อย ๆ ทุก sprint

แต่ปัญหาค่อย ๆ สะสม:

• 30% ของ test (600 เคส) เป็น flaky — fail แบบ random ไม่ใช่เพราะบั๊กจริง
• ทีมต้องใช้เวลา 2-3 ชั่วโมงต่อวัน ในการ re-run และ investigate flaky tests
• ชื่อ test ไม่สื่อ เช่น test_001, test_new, test_flow_A — ไม่รู้ว่าทดสอบอะไร
• ไม่มีใครกล้าลบ test เพราะกลัวว่า "อาจจะยังใช้อยู่"
• คนใหม่ที่เข้ามาในทีมต้องใช้เวลา 2 สัปดาห์กว่าจะเข้าใจว่า test ไหนทำอะไร

ผลลัพธ์: ทีมเสียเวลามากกว่า 50% ของเวลาทำงานในการ maintain test แทนที่จะเพิ่ม test coverage ใหม่

บทเรียน: จำนวน test ไม่ใช่เป้าหมาย — test ที่ maintain ได้คือเป้าหมาย

หลักการตั้งชื่อ

ชื่อ test ที่ดีต้องบอกได้ 3 อย่าง:

1. ทดสอบอะไร (feature/function)
2. สถานการณ์อะไร (condition/input)
3. ผลลัพธ์ที่คาด (expected outcome)

Pattern: [feature] [scenario] [expected result]

Naming Format ในภาษาต่าง ๆ

// English (common format)
"should redirect to dashboard when login with valid credentials"
"should show error when email is not registered"

// Thai (ใช้ในรายงาน)
"ควร redirect ไปหน้า dashboard เมื่อ login ด้วย credentials ที่ถูกต้อง"
"ควรแสดง error เมื่ออีเมลไม่ได้ลงทะเบียน"

ทำไมต้อง tag

เมื่อมี test 500 เคส คุณไม่ต้องการรันทั้งหมดทุกครั้ง:

• ก่อน deploy → รันแค่ @smoke (critical paths)
• หลัง sprint → รันทั้ง @regression
• เฉพาะ feature ที่แก้ → รันแค่ @cart หรือ @payment

ประเภท Tags ที่นิยม

ข้อควรระวัง

• อย่ามี tag มากเกินไป — 5-10 ประเภทก็พอ
• ทุก test ต้องมีอย่างน้อย 1 feature tag + 1 priority tag
• review tags เป็นประจำ — tag ที่ไม่มีใครใช้ให้ลบทิ้ง

ต้นทุนที่ซ่อนอยู่

ทุก test ที่เขียนมี "ค่าบำรุงรักษา" ตลอดชีวิต:

test 1 เคสอาจใช้เวลา maintain 1-3 ชั่วโมงต่อเดือน → 2,000 เคส = 2,000-6,000 ชั่วโมงต่อเดือน

วิธีลด maintenance cost

1. ใช้ Page Object Model — UI เปลี่ยน แก้ที่เดียว
2. ใช้ stable locators — data-testid, semantic locators
3. Test data independence — ไม่พึ่งพา shared data
4. Explicit waits — ไม่ใช้ sleep()
5. ลบ test ที่ไม่จำเป็น — ดีกว่า maintain test ที่ไม่มีค่า

Flaky test คืออะไร

test ที่ให้ผลลัพธ์ไม่คงที่ — บางรอบ pass บางรอบ fail โดยไม่มีการเปลี่ยนแปลง code

สาเหตุหลัก

1. Timing issues — ไม่รอให้ element พร้อม (ใช้ sleep หรือ wait ไม่เพียงพอ)
2. Test data dependency — พึ่งพา data ที่ถูกแก้โดย test อื่น
3. Environment instability — server ช้า, network ไม่เสถียร
4. Order dependency — test ต้องรันเรียงลำดับ
5. Race conditions — หลาย test แข่งกัน access resource เดียวกัน

วิธีจัดการ

ระยะสั้น:

• Tag flaky tests ด้วย @flaky เพื่อ track
• แยก flaky tests ออกจาก main suite — อย่าให้ block deployment
• ตั้ง retry policy (re-run ไม่เกิน 2 ครั้ง)

ระยะยาว:

• วิเคราะห์สาเหตุรากของ flakiness ทีละตัว
• แก้ timing issues ด้วย explicit waits
• แก้ data dependency ด้วย test data independence
• ลบ test ที่ไม่สามารถ stabilize ได้ แล้วเขียนใหม่

สัญญาณว่า test ควรถูกลบ

1. Feature ถูกลบ — test สำหรับ feature ที่ไม่มีแล้ว
2. Duplicate — test หลายตัวทดสอบสิ่งเดียวกัน
3. Permanently flaky — แก้แล้วยังพัง ไม่คุ้มค่า maintain
4. Low value — test ที่ทดสอบสิ่งที่ไม่สำคัญ (เช่น สี font)
5. Covered by other tests — unit test ครอบคลุมแล้ว ไม่จำเป็นต้องมี E2E ซ้ำ
6. ไม่มีใครเข้าใจ — test ที่ไม่มีใครรู้ว่าทำอะไร และไม่มี documentation

การตัดสินใจ

ถามตัวเอง:

• ถ้า test นี้ fail ตอนเช้า มันจะทำให้เราเจอบั๊กจริงไหม?
• ถ้าลบ test นี้ จะมีความเสี่ยงอะไรเพิ่มขึ้น?
• ต้นทุน maintain test นี้ คุ้มค่ากับความเสี่ยงที่มันป้องกันหรือเปล่า?