Manual & Exploratory Testing
Test Case vs Checklist
Test case คือสคริปต์ทดสอบแบบละเอียด: precondition, ขั้นตอนทำทีละก้าว, expected result ชัดเจนในแต่ละก้าว — เหมาะกับ flow ที่ critical และต้องทวนซ้ำแบบเดิมทุกครั้ง (regression)
Checklist คือรายการหัวข้อที่ต้องตรวจ แต่ไม่ลงรายละเอียดขั้นตอน — เร็วกว่า เหมาะกับ exploratory testing หรือฟีเจอร์ที่เปลี่ยนบ่อยจนเขียน test case ละเอียดไม่ทันความเปลี่ยนแปลง
Test case: "1) เปิดหน้า login 2) กรอก email ผิด format 3) กด submit
→ Expected: แสดง error 'Invalid email format' ใต้ field email"
Checklist: "☑ Validation ของทุก field ใน form login
☑ Error message อ่านเข้าใจและขึ้นตรงตำแหน่ง
☑ ปุ่ม submit disable ขณะ loading"
"Test case เหมือนสูตรอาหารละเอียด, Checklist เหมือนรายการของที่ต้องซื้อ" — สูตรอาหารบอกทุก ขั้นตอนเป๊ะๆ (ทำซ้ำได้เหมือนเดิมทุกรอบ) ส่วนรายการของที่ต้องซื้อให้ freedom เลือกวิธีไปเก็บของ เอง (เร็วกว่า เหมาะกับสถานการณ์ที่เปลี่ยนบ่อย)
ทีมที่เขียน test case ละเอียดทุกฟีเจอร์โดยไม่เลือกว่าควรเขียนตอนไหน มักจบลงที่ "test case maintenance debt" — เมื่อ UI/flow เปลี่ยนบ่อย (เช่น ช่วง early-stage product ที่ยัง pivot ตลอด) ต้นทุนในการอัปเดต test case ละเอียดทุกครั้งที่ feature เปลี่ยนจะสูงกว่าประโยชน์ที่ได้ ทีม QA ระดับ senior จะตัดสินใจ "เขียน test case ละเอียดเฉพาะ flow ที่ stable และ critical จริง (เช่น payment, login) ส่วนฟีเจอร์ที่ยังเปลี่ยนบ่อยใช้ checklist + exploratory testing แทน" — การเลือกระดับความละเอียดให้เหมาะกับ "ความนิ่งของ requirement" คือทักษะที่แยก QA ที่มี experience ออกจาก QA ที่ทำตามขั้นตอนอย่างเดียว
Exploratory Testing
Exploratory testing คือการทดสอบแบบไม่มีสคริปต์ล่วงหน้า — tester ใช้ความรู้เรื่องระบบและ สัญชาตญาณ "คิดแล้วลองไปพร้อมกัน" (simultaneous learning, test design, และ test execution) เพื่อ หาบั๊กที่ test case ที่เขียนไว้ล่วงหน้าไม่ครอบคลุม
เทคนิคที่ใช้บ่อย: session-based testing (จับเวลาเป็น session สั้นๆ เช่น 60-90 นาที มี charter/เป้าหมายกว้างๆ ต่อ session แล้วจด note สิ่งที่เจอ) และ tourist testing (สวมบทบาท ผู้ใช้ประเภทต่างๆ เช่น "นักท่องเที่ยว" ที่ไม่รู้ระบบเลย vs "ผู้เชี่ยวชาญ" ที่รีบและชอบ shortcut)
"Scripted testing หาบั๊กที่คาดไว้แล้ว, Exploratory testing หาบั๊กที่ไม่มีใครคาดถึง" — test case ที่เขียนล่วงหน้าพิสูจน์ได้แค่สิ่งที่คนเขียนคิดถึงตอนเขียน ส่วน exploratory testing อาศัยการ "คิดสดๆ หน้าจอ" ซึ่งมักเจอบั๊กแปลกๆ ที่ไม่มีใครนึกถึงตอนออกแบบเทสต์เคส
Exploratory testing ที่ดีไม่ใช่ "คลิกไปเรื่อยๆ แบบไม่มีจุดหมาย" แต่ใช้โครงสร้าง session-based testing ที่มี charter ชัดเจน (เช่น "สำรวจว่า flow checkout รองรับ network ช้า/ขาดตอน อย่างไร") เพื่อให้ยังคุมทิศทางได้ แต่เปิดช่องให้ "เดินออกนอกเส้นทาง" ตามสัญชาตญาณได้เมื่อเจอ อะไรน่าสงสัย — งานวิจัยและประสบการณ์จริงของทีม QA จำนวนมากชี้ว่า exploratory testing จับบั๊กที่ severity สูงได้ในอัตราต่อเวลาที่สูงกว่า scripted testing ในฟีเจอร์ที่ซับซ้อนและมี interaction หลายจุด เพราะ scripted test เขียนตาม "สิ่งที่คาดว่าจะเกิด" ส่วน exploratory testing จับ "สิ่งที่ ไม่มีใครคาดคิดว่าจะเกิด" ได้ดีกว่ามาก — ทีมระดับ production จึงมักใช้ทั้งสองแบบคู่กัน ไม่ใช่เลือก แบบเดียว
Severity vs Priority
สองคำนี้สับสนกันบ่อยมากแม้ในทีมที่ทำงานมานาน
- Severity = ความรุนแรงทางเทคนิค ของบั๊ก (กระทบระบบมากแค่ไหน) — กำหนดโดย QA
- Priority = ความเร่งด่วนทางธุรกิจ ที่ต้องแก้ (ควรแก้ก่อนอะไร) — กำหนดโดยทีม/PO โดยอิง severity + ผลกระทบธุรกิจ
| กรณี | Severity | Priority | เหตุผล |
|---|---|---|---|
| หน้า "เกี่ยวกับเรา" ตัวอักษรผิด | Low | สูงถ้าใกล้ launch ใหญ่ | กระทบเทคนิคน้อย แต่กระทบภาพลักษณ์ตอน demo สำคัญ |
| ระบบล้มเมื่อ user คนที่ 10,000 login พร้อมกัน | Critical | ต่ำถ้า traffic จริงไม่ถึงระดับนั้นในเร็วๆ นี้ | กระทบเทคนิครุนแรง แต่ยังไม่เร่งด่วนถ้ายังไม่เจอใน production |
"Severity ตอบว่า 'มันพังแค่ไหน', Priority ตอบว่า 'ต้องรีบแก้แค่ไหน'" — บั๊ก severity สูงไม่ จำเป็นต้อง priority สูงเสมอไป (ถ้ายังไม่กระทบธุรกิจตอนนี้) และบั๊ก severity ต่ำก็อาจ priority สูงได้ถ้าจังหวะธุรกิจต้องรีบแก้
Interview มักถามต่อว่า "ยกตัวอย่างบั๊ก severity สูงแต่ priority ต่ำ" — คำตอบที่ดีคือบั๊กที่กระทบ เทคนิครุนแรงจริง (เช่น data corruption) แต่เกิดเฉพาะ edge case ที่ไม่มีทางเกิดใน production จริง ตอนนี้ (เช่น ต้องมี concurrent write 100,000 ครั้งต่อวินาทีถึงจะ trigger ซึ่งระบบปัจจุบันรับ traffic ไม่ถึงระดับนั้นในอีกหลายปี) — การแยกสองมิตินี้ให้ถูกช่วยให้ทีม ไม่เสียเวลาแก้บั๊กที่ severity สูงแต่ไม่กระทบธุรกิจจริงก่อนบั๊กที่ severity ต่ำกว่าแต่กระทบ user จำนวนมากตอนนี้ ซึ่ง เป็นกับดักที่ทีมใหม่มักตกบ่อย (ไล่แก้ตาม severity อย่างเดียวโดยไม่คุยกับ business ก่อน)
Detailed test cases suit stable, critical flows (payment, login); checklists suit fast-changing features, avoiding maintenance debt from scripting flows that keep pivoting. Exploratory testing uses charter-driven, session-based exploration to catch bugs scripted tests can't anticipate, and tends to find higher-severity bugs per hour in complex, interaction-heavy features — mature teams run both approaches together. Severity (technical impact) and priority (business urgency) are distinct and set by different people; a high-severity bug can have low priority if its trigger condition is unreachable in current production load, and conflating the two leads teams to fix the wrong bugs first.