ถ้าใครเคยส่ง Bug Report ไปแล้วโดนถามกลับมาว่า “Reproduce ยังไง” หรือ โดนตีกลับมาว่า “ไม่ใช่บั๊ก” บ่อยๆ
นั่นอาจจะเป็นสัญญาณว่า report ของเรายังไม่สามารถช่วยให้ Dev ทำงานได้
อย่าเพิ่งโทษว่าเป็นความผิดของใครนะคะ
เรามาดูกันดีกว่าว่า Bug Report ที่ดี ควรจะมีอะไรบ้าง
วันนี้พี่กิ่งเอา 3 เคสจริงมาให้ดูกันว่า แบบที่ ✅ ควรทำ และ ❌ ไม่ควรทำ ต่างกันยังไง
ตัวอย่างที่ 1: ระบบคำนวณส่วนลดผิด
❌ แบบนี้งง
Description: ใส่ coupon แล้วราคาไม่ถูก
Expected: แสดงส่วนลดถูกต้อง
Actual: คำนวณส่วนลดผิด
ปัญหาคือ “ไม่ถูก” “ถูกต้อง” “ผิด” คือยังไง คำนวณส่วนลดผิด หรือ แสดงผลไม่ถูก
อ่านแล้วบอกไม่ได้เลยใช่มั้ยคะ dev ต้องเดาเอาว่าจะไปเริ่มดูโค้ดตรงไหน จะลองเทสเองด้วย coupon ไหนกับสินค้าอะไร
✅ แบบนี้ดูต่อง่าย
Title: ใส่ coupon SAVE20 แล้วระบบลดราคาผิด – ลด 20 บาทแทนที่จะลด 20%
Description:
- เพิ่มสินค้าราคา 500 บาทในตะกร้า
- กรอก coupon code SAVE20
- กด Apply
Expected: ราคาลดเป็น 400 บาท (ลด 20% จาก 500 = 100 บาท)
Actual: ราคาลดเป็น 480 บาท (ลด 20 บาท ไม่ใช่ 20%)
Environment: Staging
💡 พอเราระบุ Expected เป็นตัวเลขชัดๆแบบนี้ Dev ก็จะเห็นทันทีว่า logic ตรงไหนผิด
แล้วก็ไปเริ่มดูจากโค้ดส่วนนั้นได้เลย ไม่ต้องเสียเวลาเดาเอาเอง
ตัวอย่างที่ 2: กดชำระเงินแล้วไม่มีอะไรเกิดขึ้น
❌ แบบนี้งง
Description: ระบบ Payment มีปัญหา กดแล้วไม่ผ่าน
เอาอีกแล้วใช่มั้ยคะ “ไม่ผ่าน” “มีปัญหา” คือยังไง กดแล้วขึ้น Error กดแล้วค้าง หรือหน้าขาวไปเลย
ส่งไปแบบนี้ Dev แต่ละคนก็อาจจะตีความต่างกันไป ไม่รู้ต้องไปเริ่มดูจากตรงไหน
✅ แบบนี้ดูต่อง่าย
Title: กดยืนยันชำระเงินแล้วปุ่ม loading ค้าง ไม่มี response
Description: ใส่สินค้าในตะกร้า -> กดชำระเงิน -> กรอกข้อมูลบัตร -> กดยืนยันการชำระเงิน
Expected: ขึ้นหน้าชำระเงินสำเร็จ และส่ง email ยืนยันให้ลูกค้า
Actual: ปุ่มกลายเป็น loading ค้างอยู่มากกว่า 30 วินาที ไม่มีอะไรเกิดขึ้น
/api/payment ได้ response 500 Internal Server Error กลับมา
Environment: Dev
💡 นอกจากเราจะบอกปัญหาและขั้นตอนอย่างชัดเจนแล้ว
การเพิ่มข้อมูลเรื่อง API ว่าเจอ 500 ทำให้ dev รู้ทันทีว่าปัญหาอยู่ที่ backend server และเริ่มหาสาเหตุได้ตรงจุด
ตัวอย่างที่ 3: กด search สินค้าแล้วได้ผลลัพธ์ไม่ตรง
❌ แบบนี้งง
Description: ค้นหาสินค้าในระบบ แล้วได้ผลลัพธ์ว่า “ไม่พบสินค้า”
อันนี้เหมือนจะดี แต่ปรากฏว่า Dev ไป ลอง search ดู อ้าว แสดงผลได้ปกตินี่นา เลยส่งกลับมาว่าไม่ใช่บั๊ก
เพราะเรา search ด้วยคำว่า “รองเท้าผ้าใบ” ส่วน Dev ไปลองด้วยคำว่า “sneaker”
✅ แบบนี้ดูต่อง่าย
Title: Search ด้วย keyword ภาษาไทยแล้วไม่แสดงผล แต่ภาษาอังกฤษปกติ
Description: ไปหน้า Search -> ค้นหาด้วยคำว่า “รองเท้าผ้าใบ” -> กด Enter
Expected: แสดงผลลัพธ์สินค้าที่มีคำว่า “รองเท้าผ้าใบ” หรือ category รองเท้าผ้าใบ
Actual: แสดงผล “ไม่พบสินค้า”
Note:
- API request ส่ง keyword ถูก แต่ response กลับมาเป็น empty array
- ลอง search ด้วยคำว่า sneaker แล้วเจอปกติ
Environment: Dev
💡 การที่เราระบุปัญหาได้เจาะจงมากขึ้น มีการเปรียบเทียบผลระหว่าง “รองเท้าผ้าใบ” และ “sneaker”
ทำให้ dev เห็นทันทีว่า backend น่าจะมีปัญหากับภาษาไทย ทำให้ scope การแก้ปัญหาได้ชัดขึ้น
มีใครสังเกตมั้ยคะ ว่าทุกเคสมีอะไรบางอย่างที่เหมือนกัน
📌 Steps ที่ทำซ้ำได้ ใครอ่านก็ไปลองทำตามได้เลย
📌 Expected vs Actual ชัดเจน ไม่ต้องเดาว่า “ถูก” “ไม่ถูก” “มีปัญหา” คืออะไร
📌 บอก Context ถ้าหาได้ เช่น API response, compare case ที่ใช้ได้และไม่ได้ เพื่อช่วยให้ระบุปัญหาได้เร็วขึ้น
📌 Environment ครบ เกิดที่ไหน
เขียนครบแค่นี้ก็จะช่วยให้ทีม scope ปัญหาได้ชัดเจน และพุ่งตรงไปแก้ตรงนั้นได้เลย โดยที่ไม่ต้องเสียเวลาเดา หรือ เข้าใจไม่ตรงกัน
ถ้าใครยังไม่รู้จะเริ่มยังไง พี่กิ่งมี Bug Report Template ให้ทุกคนไปลองใช้ดูค่ะ
ใน Template นี้จะมี field ที่เราควรจะใส่ ทั้ง Steps, Expected, Actual, Environment
รวมทั้ง context ที่ควรมี พร้อมตัวอย่างให้เอาไปปรับใช้กับทีมได้เลย
👉 แอด LINE OA แล้วพิมพ์ TEMPLATE เพื่อรับฟรีได้เลยค่ะ https://lin.ee/WTnVwbI