“It’s not a bug, It’s a feature”
“ไม่ใช่บั๊กนะ มันเป็นฟีเจ้อ”
คลาสสิค!! เป็นประโยคที่ QA ทุกคนเคยได้ยินกันมาแน่ๆ ใช่มั้ยคะ 😅
บางทีเราแน่ใจสุดๆ ว่ามันพังแน่ๆ กด reproduce ซ้ำได้ทุกรอบ
แต่พอ report ไปปุ๊บ โดนสวนกลับทันที “อันนี้ตั้งใจทำแบบนี้แหละ”
แล้วเราจะทำยังไงต่อดีล่ะ!?.
ก่อนอื่นเลย อยากให้ทุกคนเข้าใจก่อนนะคะ ว่าเราไม่ได้จะมาหาว่าใครผิดใครถูก ไม่ได้จะบอกว่าใครดีกว่าใคร
เพราะ “Bug” หรือ “Not a Bug” มันมี grey area อยู่เยอะมาก
ลองนึกตามดูค่ะ ใครเคยเจอสถานการณ์เหล่านี้บ้าง
❌ Requirement ไม่ได้เขียนไว้ชัดเจน
ระบบทำงานตรงตาม spec แต่ user งงมาก แบบนี้เป็นบั๊กมั้ย?
❌ Dev กับ QA ตีความ Requirement ต่างกัน
บางทีอาจจะมี edge case ที่เราไม่ได้ระบุ expected result ไว้อย่างชัดเจน
❌ มันพังจริง แต่ Dev บอก “by design”
อาจจะเพราะเราไม่รู้ว่าจริงๆแล้ว Business ต้องการอะไร.
ลองมาดูเคสตัวอย่างที่เกิดขึ้นบ่อยๆ ในชีวิตจริงกันค่ะ
🐛 เคส: กดปุ่ม Submit แล้วไม่มีอะไรเกิดขึ้นเลย
QA: “พี่คะ กดปุ่ม Submit แล้วมันนิ่งไปเลย ตรงนี้ตั้งใจให้เป็นแบบนี้มั้ย”
Dev: “อ๋อ ตั้งใจให้รอ background process ก่อนนะ”
QA: “เข้าใจค่ะ แต่ AC ข้อ 3 เขียนว่าต้องขึ้น Spinner ทันทีที่กดนะคะ ช่วยเช็คให้อีกทีได้มั้ยคะ ถ้าเป็นแบบตอนนี้ user อาจจะเผลอกดซ้ำก็ได้”
Dev: “อ้าวจริงด้วย เดี๋ยวดูให้นะ”
จบ ไม่ต้องตีกัน ไม่มีใครแพ้ ไม่มีใครชนะ แก้ปัญหาด้วยกัน ✅
สิ่งที่สำคัญคือ เราพูดด้วย “Evidence” ชี้ให้เห็น requirement และ ผลกระทบอย่างชัดเจน
ไม่ได้ใช้ความคิดเห็นส่วนตัว หรืออารมณ์นำ และที่สำคัญคือไม่เบลมว่าเป็นความผิดใคร
ถ้าเราไปบอกว่า
“พี่คะ ตรงนี้กด Submit แล้วไม่ขึ้น spinner ช่วยแก้ให้หน่อยค่ะ พี่ได้อ่าน AC มั้ยเนี่ย”
คิดว่าจะเกิดอะไรขึ้นคะ…
จะไปชวนเค้าตีทำไม แบบนี้ไม่เอานะคะ
🔑 วิธีรับมือแบบ QA ร่างทอง
1. กลับไปที่ Requirement ก่อนเสมอ
ถ้าจะต้องเถียงกัน ก็เถียงด้วย evidence ค่ะ อย่าเถียงด้วย opinion เพราะมันจะจบยาก
ถ้า spec บอกว่าต้องทำ A แต่ระบบทำ B ยังไงก็ต้องแก้ค่ะ
“พี่คะ ลองเช็ค Acceptance Criteria ใน ticket หน่อยได้มั้ยคะ
ข้อ 2 เขียนว่าต้องขึ้น error message ถ้า field ว่างค่ะ แต่ตอนนี้ไม่ขึ้นอะไรเลย”
เคลียร์ ชัดเจน
2. ถ้า Requirement ไม่ชัด ให้ escalate ไปให้ PO/BA เลย ตัดสินใจร่วมกันดีที่สุด
ถ้ากลับไปเช็ค Requirement แล้ว ไม่มีคำตอบเคลียร์ๆ พยายามอย่าให้ Dev กับ QA ต้องมานั่งเดากันเองค่ะ
ชวนฝั่ง PO (หรือใครที่ดูฝั่ง Business) มาตัดสินใจร่วมกันเลย เราจะได้ไม่คิดไปเอง แล้วอาจจะเกิดความเข้าใจผิดได้
“พี่คะ ตรงนี้ ticket ไม่มีระบุไว้ ขอนัด PO มาคุยด้วยทีเดียวเลยได้มั้ยคะ จะได้เข้าใจตรงกันทุกฝ่าย”
3. วัด Impact ก่อนจะคุยกัน
ถ้า Dev บอกไม่ใช่บั๊ก ลองถามตัวเองก่อนว่า ถ้าปล่อยแบบนี้ขึ้น Production จะกระทบ User มากน้อยแค่ไหน
กระทบ Business ยังไง Impact สูงหรือไม่สำคัญเท่าไหร่ ก่อนที่จะไปคุยทำความเข้าใจกัน
บางทีถ้า Impact ไม่สูง เราอาจจะปล่อยผ่านก็ได้ แต่ก็อย่าลืมตกลงกับทีมให้ชัดเจน
⚠️ ระวังด้วย ถ้าเราผิดจริง ก็ต้องรับมืออย่างถูกต้อง
พูดตรงๆ เลยค่ะ บางครั้งมันก็ไม่ใช่ Bug จริงๆ เราอาจจะเปิดบั๊กไปด้วยความเข้าใจผิด หรือเป็น Data ที่มีความผิดพลาด หรือมองข้ามอะไรบางอย่างไปเอง
สถานการณ์ที่อาจจะเกิดได้ เช่น:
1. อ่าน Requirement ไม่ครบเอง
อาจจะมี edge case บางกรณีที่ต้องจัดการต่างไป แล้วเราดันอ่าน Requirement ข้ามส่วนนั้นไป
2. ตีความ Expected Result ไปเอง
คิดไปเองว่า “ควรจะทำแบบนี้” แต่จริงๆ ไม่ได้มีเขียนไว้ใน Ticket เลย
3. ผิด Environment, config ผิด
แล้วก็บอกว่า “พัง” ทั้งที่จริงๆทำงานได้ปกติ
🧘♀️ ถ้าแบบนั้นจะรับมือยังไงดี
1. ยอมรับอย่างเปิดใจ ไม่ต้องเกร็ง
พูดตรงๆ ไปเลย อย่าเฉไฉไม่ยอมรับผิดนะคะ
“อ๋อ จริงด้วย เข้าใจผิดไปเองค่ะ ขอบคุณที่อธิบายนะคะ”
แค่นี้ก็ใช้ได้แล้ว ไม่ต้องแก้ตัว ไม่ต้องโทษคนอื่น
การยอมรับผิดคือความ mature อย่างหนึ่งนะคะ (แต่ก็ไม่ควรผิดซ้ำเรื่องเดิมบ่อยๆ นะคะ)
2. เรียนรู้จาก pattern ที่เกิดขึ้น
ถ้าเราผิดซ้ำๆ แบบเดิมบ่อยๆ ต้องกลับมาถามตัวเองแล้วค่ะ ว่าเราข้ามขั้นตอนอะไรไปมั้ย
อ่าน AC ครบทุกข้อก่อน report มั้ย หรือ ทำความเข้าใจ Business Requirement ดีพอหรือยัง
3. ป้องกันด้วย “Pre-flight Check” ก่อน report ทุกครั้ง
ก่อนจะบอกว่าเจอบั๊ก ลองเช็ค 3 ข้อนี้ดูก่อนค่ะ
✅ มี Requirement หรือ AC ลองรับมั้ยว่าตรงนี้ “ควรจะ” เป็นแบบอื่น
✅ Reproduce ซ้ำได้มั้ย ใน Environment ที่ถูกต้อง
✅ ถามตัวเองว่า “มีโอกาสมั้ยที่นี่คือ “สิ่งที่ระบบตั้งใจทำ”
ถ้าตรงไหนไม่แน่ใจ เราสามารถตรวจสอบกับ Dev หรือ PO ก่อนจะเปิดบั๊กได้เสมอค่ะ
ถ้าผ่านครบ 3 ข้อ ก็ report ได้เลย
ใครเคยเจอสถานการณ์แบบนี้บ้าง แล้วสุดท้ายเป็นยังไง คอมเมนต์มาเล่าให้ฟังกันได้เลยค่ะ 👇