กลยุทธ์การจัดลำดับความสำคัญของ Test Cases
พอรู้แล้วว่าอะไรเสี่ยง ขั้นต่อไปคือการเปลี่ยนความเสี่ยงนั้นให้กลายเป็นลำดับการลงมือจริง บทนี้จะพาคุณจัดคิวการทดสอบอย่างมีเหตุผล ไม่ใช่เลือกตามความสะดวกหรือความคุ้นเคย
จบบทนี้แล้วคุณจะ...
- อธิบายได้ว่าทำไม “อะไรควรทดสอบก่อน” เป็นคำถามสำคัญพอ ๆ กับ “ต้องทดสอบอะไรบ้าง”
- ใช้ปัจจัยอย่าง business criticality, change impact และ usage frequency มาช่วยจัดลำดับได้
- แยกการจัดลำดับสำหรับ smoke, regression และ release verification ได้ชัดขึ้น
- พูดคุยกับทีมเมื่อเวลาจำกัดได้อย่างมีเหตุผล แทนการบอกแค่ว่า “เทสต์ไม่ทัน”
- รู้จักข้อผิดพลาดที่ทำให้ทีมใช้เวลาผิดจุด แม้จะมี test case เยอะก็ตาม
เพราะ test case ที่ดี ถ้ารันผิดลำดับ ก็ยังพลาดสิ่งสำคัญได้
สมมติคุณมี test case 80 ข้อก่อน release และเวลาเหลือ 2 ชั่วโมง
ถ้าคุณเริ่มจาก:
- เปลี่ยนรูปโปรไฟล์
- sort ตาราง
- export CSV
แต่ยังไม่ได้รัน:
- login
- checkout
- payment callback
- order creation
ต่อให้คุณ “รันได้หลายข้อ” ก็ไม่ได้แปลว่าคุณลดความเสี่ยงได้มาก
การจัดลำดับความสำคัญจึงไม่ใช่เรื่องของความสวยงามในเอกสาร แต่คือการตัดสินใจว่าเวลาที่เหลือควรถูกใช้ตรงไหนก่อน เพื่อเพิ่มความมั่นใจของทีมให้ได้มากที่สุด
อย่าดูแค่ความเสี่ยงอย่างเดียว ต้องดูบริบทการเปลี่ยนแปลงด้วย
ปัจจัยที่ใช้บ่อยมีดังนี้:
| ปัจจัย | คำถามที่ควรถาม | ถ้าค่าสูง มักควรไปก่อน |
|---|---|---|
| Business Criticality | ฟีเจอร์นี้กระทบเป้าหมายหลักของธุรกิจไหม | ใช่ |
| User Frequency | คนใช้ฟีเจอร์นี้บ่อยแค่ไหน | บ่อย |
| Change Impact | ส่วนนี้เพิ่งแก้เยอะไหม หรือกระทบส่วนอื่นไหม | เพิ่งแก้เยอะ |
| Failure Cost | ถ้าพังแล้วเสียเงิน เสียข้อมูล หรือเสียชื่อเสียงแค่ไหน | สูง |
| Dependency / Integration | พึ่ง third-party หรือ service อื่นไหม | พึ่งเยอะ |
| Past Defect History | จุดนี้เคยพังบ่อยไหม | เคย |
สังเกตว่าการจัดลำดับความสำคัญมักเกิดจาก “หลายปัจจัยรวมกัน” ไม่ใช่ตัวใดตัวหนึ่งเดี่ยว ๆ
ถามให้จบว่า “ถ้ามีเวลาได้แค่ 30 นาที เราจะรันอะไร”
วิธีง่ายที่สุดคือจัด test cases หรือ scenarios เป็นชั้น ๆ
| ชั้น | ความหมาย | ตัวอย่าง |
|---|---|---|
| P0 / Must Run | ไม่รันไม่ได้ก่อนปล่อย | login, checkout, create order, core permission |
| P1 / Should Run | ควรรันถ้ามีเวลาเพียงพอ | alternate payment, coupon rules, resend email |
| P2 / Nice to Run | รันเมื่อยังมีเวลาเหลือ | low-risk settings, niche filters, cosmetic paths |
การแบ่งชั้นแบบนี้ช่วยให้ทีมคุยกันง่ายมากขึ้น โดยเฉพาะเวลามีแรงกดดันจาก deadline
Smoke, sanity, regression และ pre-release ไม่ควรใช้ลำดับเดียวกัน
Smoke Test
เป้าหมายคือเช็กว่า build “ยังหายใจอยู่ไหม”
สิ่งที่ควรไปก่อน:
- เปิดระบบได้
- login ได้
- flow หลักเข้าได้
- ไม่มี crash / broken navigation
Regression
เป้าหมายคือเช็กว่าของเดิมที่สำคัญยังไม่พัง
สิ่งที่ควรไปก่อน:
- flow หลักของธุรกิจ
- จุดที่เคยพังบ่อย
- พื้นที่ที่ได้รับผลจาก code change
Release Verification
เป้าหมายคือสร้างความมั่นใจก่อนปล่อยจริง
สิ่งที่ควรไปก่อน:
- flow ที่ถ้าพังแล้วปล่อยไม่ได้
- integration กับ external systems
- data correctness
- security / permission ที่สำคัญ
ดังนั้น test case เดียวกันอาจมี priority ไม่เท่ากันในแต่ละบริบท
ไม่ใช่ทุกเคสของ checkout ต้องรันพร้อมกันเสมอไป
สมมติ release นี้แตะ:
- coupon logic
- shipping fee calculation
- payment callback
ตัวอย่างการจัดลำดับ:
| ลำดับ | รายการ | ทำไมต้องมาก่อน |
|---|---|---|
| 1 | login + add to cart + checkout happy path | ถ้าพัง ปล่อยไม่ได้ |
| 2 | payment success → order created | กระทบเงินโดยตรง |
| 3 | payment fail / retry / duplicate submit | จุดเสี่ยงสูงและมักพังยากต่อการจับ |
| 4 | coupon valid / invalid / expired | release นี้แตะตรงนี้โดยตรง |
| 5 | shipping fee boundary | เพิ่งแก้ logic |
| 6 | email confirmation | สำคัญแต่ไม่ critical เท่า order creation |
| 7 | low-priority UI polish | ตัดได้ถ้าเวลาไม่พอ |
สังเกตว่าเราไม่ได้ไล่ตามเอกสารจากบนลงล่าง แต่ไล่ตาม “ระดับความเจ็บถ้าพลาด”
ของที่เพิ่งแตะ มักควรได้ attention มากขึ้น
ต่อให้ฟีเจอร์หนึ่งไม่ใช่ core flow ที่สุด แต่ถ้า release นี้เพิ่งเปลี่ยน logic ตรงนั้นจำนวนมาก มันควรถูกยก priority ขึ้น
ตัวอย่าง:
- search ไม่ใช่ payment แต่ถ้า sprint นี้ refactor search backend ทั้งก้อน ก็เสี่ยงขึ้น
- profile page ปกติอาจ priority ต่ำ แต่ถ้าเพิ่งเปลี่ยน permission model ก็ต้องรันเพิ่ม
นี่คือเหตุผลที่ priority ที่ดีควรมาจากทั้ง:
- risk assessment
- scope การเปลี่ยนแปลง
- defect history
หลายทีมมี test case เยอะ แต่ยังใช้เวลาไม่คุ้ม
1. รันตามลำดับที่เอกสารถูกเขียน
เอกสารอาจเรียงตาม flow การอธิบาย ไม่ได้เรียงตามความเสี่ยง
2. ให้ priority ตามความง่ายในการรัน
เคสที่รันง่ายไม่จำเป็นต้องสำคัญกว่าเคสที่ยุ่งกว่า
3. เอา UI cosmetic ขึ้นมาก่อน logic สำคัญ
เพราะเห็นง่ายและจับง่าย แต่ไม่ได้ลด risk หลักของ release
4. ไม่บอกเหตุผลของ priority
ถ้าคนอื่นไม่รู้ว่าทำไมเคสนี้เป็น P0 การจัดลำดับจะกลายเป็นเรื่องความเห็นส่วนตัวทันที
อย่าพูดแค่ว่า “เทสต์ไม่ทัน” ให้พูดว่า “เราเลือกจะคุ้มครองอะไร”
ประโยคแบบนี้ช่วยทีมตัดสินใจได้ดีกว่า:
- “ในเวลาที่เหลือ เราจะปิด P0 ของ login, checkout และ payment callback ให้ครบก่อน”
- “coupon edge cases บางส่วนยังไม่รัน ถ้าจะปล่อย ขอให้รับ risk จุดนี้ร่วมกัน”
- “ส่วน export report ยังไม่ได้ลงลึก เพราะ release นี้ไม่ได้แตะโค้ดส่วนนั้น”
ภาษาลักษณะนี้ทำให้ QA ไม่ได้ดูเหมือนแค่รายงานข้อจำกัด แต่กำลังช่วยทีมบริหารความเสี่ยง
แบบฝึก: ถ้ามีเวลาเหลือแค่ครึ่งเดียว จะเลือกอย่างไร
release นี้มี 3 ส่วนคือ login UI redesign, coupon refactor, และหน้า about us ใหม่ คุณจะจัดลำดับอย่างไร
ดูคำตอบแนะนำ
โดยทั่วไป coupon refactor ควรขึ้นก่อน เพราะกระทบ business rule และยอดเงิน จากนั้น login UI redesign เพราะเป็น flow หลักของผู้ใช้ทุกคน ส่วนหน้า about us ใหม่มักอยู่ท้ายสุดเพราะ impact ต่ำกว่า
ฟีเจอร์ search ใช้บ่อยมาก แต่รอบนี้ไม่ได้แก้โค้ด ส่วน export report ใช้ไม่บ่อยแต่เพิ่งเปลี่ยน logic ทั้งก้อน อะไรควรได้ priority สูงกว่า
ดูคำตอบแนะนำ
export report อาจได้ priority สูงขึ้นเพราะ change impact สูง แม้ usage frequency ต่ำกว่า search นี่คือเหตุผลที่ priority ควรดูทั้ง “ใช้บ่อยไหม” และ “เพิ่งเปลี่ยนหรือไม่”
ถ้าทีมบอกว่า “เทสต์ทุกอย่างเลย จะได้ไม่ต้องเถียง” คุณจะตอบอย่างไร
ดูคำตอบแนะนำ
ในทางปฏิบัติเราแทบไม่มีเวลาและทรัพยากรพอให้ทุกอย่างลึกเท่ากัน การบอกว่าจะเทสต์ทุกอย่างจึงอาจทำให้ทีมรู้สึกอุ่นใจเกินจริง ทางที่ดีกว่าคือบอกให้ชัดว่าอะไรคือ P0, P1, P2 และอะไรคือ risk ที่ยังเหลือ
คุณมี test case 30 ข้อสำหรับ payment แต่มีเวลาแค่รัน 8 ข้อ คุณจะเลือกจากอะไรบ้าง
ดูคำตอบแนะนำ
เริ่มจาก happy path, payment success → order created, failure path ที่สำคัญ, duplicate submit, callback mismatch, boundary ของยอดเงิน และเคสที่เพิ่งถูกแก้ในรอบนี้ จากนั้นค่อยเลือกเคสรองลงมาตาม defect history และเวลาที่เหลือ
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- การจัดลำดับความสำคัญคือการเปลี่ยน risk ให้กลายเป็น action plan ในเวลาจำกัด
- อย่าดูแค่ความสำคัญทางธุรกิจ แต่ให้ดู change impact, defect history และ integration risk ด้วย
- แยก P0, P1, P2 หรือ Must / Should / Nice to Run จะช่วยให้คุยกับทีมง่ายขึ้นมาก
- ลำดับของ test cases ควรเปลี่ยนตามบริบทของ smoke, regression และ release verification
- QA ที่สื่อสาร priority เป็น จะช่วยทีมตัดสินใจได้ดีกว่าการพูดเพียงว่า “ยังเทสต์ไม่ครบ”