การเขียน Bug Report ที่ Dev อ่านแล้วแก้ได้เลย

เพราะ defect ที่รายงานไม่ชัด เท่ากับทีมยังแก้ปัญหาไม่ถูก

สมมติ QA ส่งข้อความแบบนี้:

สิ่งที่ dev ต้องถามกลับมีทันที:

• พังตรงไหน
• ทำอะไรอยู่ก่อนหน้า
• ใช้ browser / device อะไร
• เกิดทุกครั้งไหม
• มีข้อมูลหรือเงื่อนไขพิเศษหรือไม่

ทุกคำถามที่ต้องถามกลับคือเวลาที่เสียไป และบั๊กยิ่ง critical เท่าไร เวลาที่เสียนี้ยิ่งแพง

bug report ที่ดีจึงไม่ใช่เอกสารที่ยาวที่สุด แต่คือเอกสารที่ทำให้คนอ่าน:

• เข้าใจปัญหาเร็ว
• ทำซ้ำได้
• ประเมินผลกระทบได้
• เริ่มแก้ได้โดยไม่ต้องเดา

เขียนให้ครบเท่าที่จำเป็น ไม่ใช่ครบทุกช่องแบบไม่มีคุณภาพ

คุณไม่จำเป็นต้องมี template ยาวมาก แต่ข้อมูลเหล่านี้คือแกนกลางที่ช่วยให้ report ใช้งานได้จริง

สรุป “อาการ + เงื่อนไขสำคัญ + ผลกระทบ” ให้มากที่สุดในประโยคเดียว

เปรียบเทียบ:

ตัวอย่างที่ดีขึ้น:

• “Order ไม่ถูกสร้างหลังชำระเงินผ่าน PromptPay สำเร็จ”
• “ผู้ใช้ reset password ไม่ได้เมื่อเปิดลิงก์เกิน 1 ชั่วโมง”
• “ระบบคำนวณส่วนลด 10% ผิดเมื่อใช้คูปองร่วมกับ shipping promotion”

Title ที่ดีช่วยให้คนสแกน defect list แล้วเข้าใจภาพรวมได้เร็วมาก

อย่าใช้สองคำนี้แทนกัน

Severity คือความรุนแรงของปัญหาในเชิงพฤติกรรมของระบบ

Priority คือความเร่งด่วนที่ทีมควรแก้ในเชิงธุรกิจหรือแผนงาน

ตัวอย่างให้เห็นภาพ

• logo หน้าแรกผิด: severity อาจต่ำ แต่ priority อาจสูง ถ้าต้อง demo ให้ผู้บริหารวันนี้
• crash เมื่อพิมพ์ emoji ในช่องเฉพาะที่คนแทบไม่ใช้: severity อาจสูง แต่ priority อาจไม่สูงเท่า payment bug

การแยกสองอย่างนี้ออกจะช่วยให้ triage คุยกันง่ายขึ้น

ถ้าคนอื่นทำซ้ำไม่ได้ เขาก็แก้ไม่ได้

steps ที่ดีควรมีลักษณะดังนี้:

• เริ่มจากจุดตั้งต้นที่ชัด
• แต่ละข้อมี 1 action หลัก
• ระบุข้อมูลที่กรอกหรือเงื่อนไขที่ใช้
• บอกจุดที่ต้องสังเกตอาการ

ตัวอย่าง:

ยังไม่ดี

1. สั่งอาหาร
2. จ่ายเงิน
3. ไม่มี order

ดีขึ้น

1. เปิดแอปด้วย account qa_user_01
2. ค้นหาร้าน “ข้าวมันไก่ลุงชัย”
3. เพิ่มเมนู “ข้าวมันไก่พิเศษ” ลงตะกร้า
4. กด “สั่งอาหาร”
5. เลือกชำระเงินแบบ PromptPay
6. ชำระเงินจนหน้าจอแสดง “สำเร็จ”
7. ไปที่หน้า “คำสั่งซื้อของฉัน”
8. สังเกตว่าไม่มี order ที่เพิ่งสร้าง

steps ลักษณะนี้ช่วยลดการตีความและทำให้ dev หรือ QA คนอื่นทำซ้ำได้ใกล้เคียงกัน

บางบั๊กแก้เร็วขึ้นมากถ้าเราให้ hint ที่ถูก

ข้อมูลที่มักช่วยมาก:

• เกิดทุกครั้งหรือบางครั้ง
• เกิดเฉพาะ browser / device / payment method ไหน
• เริ่มเกิดหลัง build ไหน
• มี workaround หรือไม่
• เทียบกับกรณีที่ทำงานปกติได้ไหม

ตัวอย่างเช่น:

• “เกิดเฉพาะเมื่อใช้ PromptPay; credit card ปกติ”
• “เกิดเมื่อมีสินค้าเกิน 5 ชิ้น; 1-5 ชิ้นไม่เกิด”
• “เจอบน Safari iOS แต่ Chrome desktop ปกติ”

ข้อมูลเหล่านี้ไม่ได้แทน root cause แต่ช่วยให้ dev narrow down เร็วขึ้นมาก

เห็นความต่างจากผลลัพธ์ที่ทีมได้รับ

แบบแย่

ปัญหา:

• ไม่รู้เงื่อนไข
• ไม่รู้ expected / actual
• ไม่รู้ env
• ไม่รู้ reproduce ได้ไหม

แบบดี

ผลต่างคือแบบหลังทำให้ dev เริ่ม investigate ได้ทันที

bug report ที่ดูเหมือนครบ แต่ยังใช้งานจริงไม่ดี

1. เขียน title กว้างเกิน

ทำให้ defect list อ่านยาก และ triage ยาก

2. steps กระโดดข้าม context

เช่นเริ่มจาก “กด submit” โดยไม่บอกว่ามาถึงหน้านี้อย่างไร

3. expected result ไม่ชัด

ถ้าไม่รู้ว่าควรเกิดอะไร ก็ยากจะคุยว่าอะไรผิด

4. actual result เป็นความเห็นมากกว่าข้อเท็จจริง

เช่น “ระบบงงมาก” ดีกว่าที่จะเขียนว่า “ปุ่ม Save ไม่ตอบสนองหลังคลิก 10 วินาที”

5. ไม่มี evidence เมื่อ bug ไม่เกิดทุกครั้ง

บั๊ก intermittent จะยิ่งต้องมี screenshot, video, logs หรือ request id ช่วย