เคยเป็นเหมือนกันมั้ยคะ
เขียน Test Case ไปเป็น 100 ข้อ เช็คครบทุกอย่างแล้ว แต่พอ Release ไปจริงๆ
ลูกค้าดันเจอบั๊กที่เราไม่เคยคิดถึงเลย 🫠
ปัญหาไม่ได้อยู่ที่เราเทสน้อยเกินไปค่ะ แต่เราอาจจะกำลังเทสไม่ตรงจุด
เพราะเราแตก task ย่อยเกินไป
อย่างสมมติว่าเราต้องเทสหน้า Login พอเห็นปุ๊บเราก็จะคิดทันทีว่า
มี Username / มี Password / มีปุ่ม Login → เช็คไปทีละอัน พอครบก็ผ่าน
มันไม่ได้ผิดค่ะ แค่… ไม่พอ
เพราะ User จริงๆ เค้าใช้งานระบบค่ะ
เค้าอาจจะ Login ผิดซ้ำ 2-3 รอบเพราะจำ password ไม่ได้
เค้าอาจจะปิดแท็บไป แล้วกลับมาใหม่
หรือเค้าอาจจะเปิดค้างไว้จน session หมด
บั๊กที่หลุดไปส่วนใหญ่ ไม่ได้หลุดเพราะแต่ละ field ทำงานไม่ถูก
แต่มันหลุดเพราะ ช่วงรอยต่อระหว่างแต่ละส่วนที่เราไม่ได้คิดถึงค่ะ
ลองดูตัวอย่างต่อจากหน้า Login กันค่ะ
❌ แบบที่คนมักทำ (เช็ค field ทีละอัน):
TC1: Username valid
TC2: Username blank
TC3: Password valid
TC4: Password blank
TC5: Password wrong
เทสเสร็จทุกอย่างผ่านหมด
แต่ก็ยังมีบั๊กหลุดอยู่ดี เพราะเราไม่ได้มองว่า user จะทำอะไรจริงๆ
✅ แบบ Scenario-Based (มองจาก user journey ก่อน):
ลองเปลี่ยนเป็นเราเริ่มจาก user journey ก่อน ว่าเค้าจะทำอะไรที่หน้านี้ได้บ้าง
SC1: Login สำเร็จ → redirect ไป dashboard
SC2: Password ผิด → error ขึ้น + ไม่บอกว่า username ถูกไหม
SC3: ผิด 5 ครั้ง → account ถูก lock + แจ้ง user
SC4: Session หมด → login ซ้ำ → กลับ page เดิมได้
SC5: เปิด Remember me → ปิด browser แล้วเปิดใหม่ → ยัง login อยู่
Scenario 3-5 อาจจะไม่เจอเลยจาก Test Case แบบแรกที่เราไล่เช็คทีละ field
แล้วเราจะเริ่มคิด Test Case แบบ Scenario-Based ได้ยังไง
ลองตอบ 2 คำถามนี้ให้ได้ ก่อนจะเปิด spreadsheet เริ่มเขียน Test Case กันค่ะ
1️⃣ Feature นี้มีไว้เพื่ออะไร? User ที่ใช้คือใคร?
เข้าใจในมุมของ Business ก่อน ไม่ใช่แค่ทำตาม Requirement อย่างเดียว
2️⃣ Happy Path ของ user เป็นยังไง? แล้วถ้า… จะเกิดอะไร?
คิด scenario จาก user journey ก่อน แล้ว test case จะตามมาเองค่ะ.
ลองมาดูอีกตัวอย่าง กับการ Checkout ตะกร้าสินค้า เพื่อให้เห็นภาพมากขึ้นนะคะ
❌ แบบที่คนมักทำ (เช็ค field ทีละอัน):
TC1: กรอกที่อยู่ถูกต้อง
TC2: กรอกที่อยู่ไม่ครบ
TC3: เลือก payment method ได้
TC4: กด confirm แล้ว order สร้าง
TC5: ของใน cart แสดงถูกต้อง
อ่านดูก็เหมือนจะครบใช่มั้ยคะ แต่จะเห็นว่าเรากำลังเทสแยกเป็นส่วนๆอยู่
ถ้าเราลองตอบคำถาม 2 ข้อข้างบนดู
1️⃣ Feature นี้มีไว้เพื่ออะไร? User ที่ใช้คือใคร?
การ Checkout มีไว้เพื่อให้ลูกค้าจ่ายเงิน และ ได้รับของ
ไม่ใช่ กรอกฟอร์มแล้ว submit
User ที่ใช้คือ คนที่ตัดสินใจซื้อของแล้ว และกำลังจะจ่ายเงิน
💡 สังเกตมั้ยคะ พอเราตอบได้แบบนี้ เราจะเปลี่ยนความคิดทันทีว่าต้องเช็คว่าลูกค้า checkout แล้วจ่ายเงินสำเร็จและได้ของไป
ไม่ใช่เช็คว่ากด Submit แล้ว success หรือ ฟอร์มถูกมั้ย
2️⃣ Happy Path ของ user เป็นยังไง? แล้วถ้า… จะเกิดอะไร?
Happy Path คือ ลูกค้าเลือกของ → กดใส่ตะกร้า → Checkout → เลือกที่อยู่ → จ่ายเงิน → ได้ order confirmation
ถ้าเราถามต่อจากตรงนี้ไปอีก
แล้วถ้า…
❓ ออกไปดูของก่อน แล้วค่อยกลับมา checkout → ของยังอยู่ใน cart ไหม?
❓ ของเหลือชิ้นเดียว แต่มีคนกด checkout พร้อมกัน → ใครได้ของ?
❓ payment หลุดระหว่างจ่าย → เงินถูกตัดไปแล้วหรือเปล่า?
❓ กด confirm แล้ว back → จะ checkout ซ้ำได้ไหม?
เราก็จะได้ scenario ที่ต่อออกมาจาก Happy Path ที่เราตั้งไว้
Scenario เราก็จะกลายเป็นแบบนี้
✅ แบบ Scenario-Based (มองจาก user journey ก่อน):
SC1: เพิ่มของในตะกร้า → checkout → จ่ายเงินสำเร็จ
SC2: จ่ายเงินไม่สำเร็จ → Order รอจ่ายเงิน → สามารถกลับมาจ่ายได้
SC3: กด checkout → เปลี่ยนใจ → ออกไปดูของอื่น → ของในตะกร้ายังอยู่
SC4: ของในตะกร้าเหลือ 1 ชิ้น → มีลูกค้าเพิ่ม 2 คน และ checkout ทั้งคู่
SC5: Order สำเร็จแล้ว → ลูกค้าต้องไม่เห็นของในตะกร้า → กด checkout ซ้ำไม่ได้
พอเราได้ scenario แล้ว ค่อยแตก test case ย่อยไปจากตรงนี้อีกทีค่ะ
จะทำให้เราได้ Test Case ที่ครอบคลุม Business จริงๆ มากกว่าการเทสเป็นจุดย่อยๆ
—
ถ้าใครอยากลองเอาไปปรับใช้ดู
สามารถรับ Test Case Design Checklist ได้ฟรี
มี 4 ขั้นตอน พร้อมคำถามที่ใช้ก่อนเขียน Test Case ทุกครั้งให้เอาไปใช้ได้เลยค่ะ
เพิ่มเพื่อนใน LINE แล้วพิมพ์ CHECKLIST เพื่อรับฟรีได้เลยนะคะ 👇
https://lin.ee/PI9jnYm หรือแอด LINE @withnatsiree (ต้องมีเครื่องหมาย @)