วงจรชีวิตของ Defect

เพราะ “เจอบั๊ก” ยังไม่ใช่ “ปัญหาถูกจัดการแล้ว”

หลายทีมพอ QA เจอบั๊กก็คิดว่างานเสร็จไปครึ่งหนึ่งแล้ว แต่จริง ๆ หลังจาก report แล้ว ยังมีคำถามอีกเยอะ:

• ใครจะเป็นคนตัดสิน severity/priority?
• Dev รับไปเมื่อไร?
• fixed แล้ว QA จะ retest เมื่อไร?
• ถ้าแก้ไม่ตรง จะ reopen ยังไง?
• ถ้า bug นี้ไม่แก้ตอนนี้ จะ defer หรือ accept risk อย่างไร?

ถ้าทีมไม่มีภาพร่วมกัน defect จะวนอยู่ในสถานะต่าง ๆ แบบไม่สร้างความชัดเจน เช่น:

• QA คิดว่า dev ยังไม่รับ
• dev คิดว่า QA ยังไม่ได้ให้ข้อมูลครบ
• PM คิดว่าบั๊กนี้ไม่สำคัญ
• release day มาถึง แต่ยังไม่มีใครชัดว่าบั๊กไหนปิดได้จริง

defect lifecycle จึงช่วยให้ทีมตอบว่า “ตอนนี้ปัญหานี้อยู่ตรงไหนของกระบวนการแล้ว”

ชื่ออาจต่างกันตามเครื่องมือ แต่ความหมายหลักมักคล้ายกัน

บางทีมมีสถานะมากกว่านี้ เช่น Ready for QA, Blocked, Won't Fix แต่แนวคิดหลักยังเหมือนเดิม

เห็นภาพทีละก้าวจะเข้าใจมากกว่าท่องชื่อสถานะ

สมมติ QA พบว่า:

วงจรอาจเป็นแบบนี้:

1. QA รายงาน defect พร้อม evidence → สถานะ New
2. ทีม triage ตอนเช้า เห็นตรงกันว่าเป็น critical → Accepted
3. assign ให้ dev ที่ดู payment callback → Assigned
4. dev แก้โค้ดและ merge ไป staging → Fixed
5. QA retest ซ้ำด้วยเงื่อนไขเดิม → Retest
6. ถ้า order ถูกสร้างถูกต้องแล้ว และไม่มี side effect → Closed
7. ถ้าอาการเดิมหาย แต่ไปเกิดปัญหา “สร้าง order ซ้ำ” แทน → อาจเปิด defect ใหม่ หรือ Reopened ตามบริบท

การเห็น defect lifecycle เป็น flow แบบนี้ช่วยให้ทีมไม่ใช้สถานะมั่ว ๆ

ไม่ใช่แค่เปิด defect แล้วรอ

บทบาทของ QA ใน defect lifecycle มักมีอย่างน้อย 4 เรื่อง:

1. Report ให้ชัด

ถ้า defect ตั้งต้นไม่ชัด วงจรถัดไปทั้งหมดจะช้าลง

2. ช่วย triage ด้วยบริบทการใช้งานจริง

QA มักเป็นคนอธิบายได้ว่า:

• เจอในเงื่อนไขไหน
• กระทบผู้ใช้อย่างไร
• มี workaround หรือไม่
• เกิดซ้ำได้แค่ไหน

3. Retest อย่างมีวินัย

QA ไม่ได้เช็กแค่ว่า “อาการเดิมหายไหม” แต่ควรมองด้วยว่า:

• fix ครอบคลุมจริงหรือไม่
• มี regression ใกล้เคียงไหม
• พฤติกรรมใหม่ยังสมเหตุสมผลไหม

4. ติดตาม defect ให้จบจริง

บางครั้ง defect ไม่ได้ติดที่การแก้ แต่ติดที่:

• ยังไม่มีข้อมูลเพิ่ม
• deploy ยังไม่ถึง env ที่ QA ใช้
• เจ้าของงานไม่ชัด

QA ที่ดีจะช่วยตามเรื่องโดยไม่ปล่อยให้ defect ค้างแบบเงียบ ๆ

ไม่ใช่ทุกอย่างที่ยังไม่พอใจต้อง reopen ทันที

ให้ลองแยกแบบนี้:

ควร Reopen

• อาการเดิมยังเกิดซ้ำ
• แก้ไปบางส่วน แต่เงื่อนไขสำคัญยังพัง
• expected result ที่ตกลงกันไว้ยังไม่ผ่าน

อาจไม่ควร Reopen แต่ควรเปิด defect ใหม่

• fix ตัวเดิมหายแล้ว แต่ก่อ regression คนละอาการ
• พบ issue ใหม่ที่มี root cause คนละจุด

อาจไม่ควร Reopen

• สิ่งที่ QA เห็นเป็น expected behavior ตามที่ทีมตกลงใหม่
• ปัญหาเกิดจาก test data หรือ environment ไม่พร้อม

การ reopen อย่างมีเหตุผลจะช่วยให้ทีมไม่รู้สึกว่า defect tracking เป็นเกมจับผิด

สถานะเหล่านี้ช่วยเก็บความจริงของงาน

Deferred

ใช้เมื่อทีมรับรู้ว่าเป็น defect จริง แต่ตัดสินใจเลื่อนไปก่อน เพราะ:

• release ใกล้มาก
• impact ต่ำ
• fix เสี่ยงต่อ regression สูง

Rejected / Not a Bug

ใช้เมื่อ:

• พฤติกรรมตรงตาม requirement ที่ตกลงกัน
• เป็น misunderstanding
• report ยังพิสูจน์ไม่ได้ว่าเป็น defect จริง

Duplicate

ใช้เมื่อมี defect เดิมอยู่แล้ว และ issue ใหม่นี้ควรถูก trace ไปที่ตัวเดิม ไม่ใช่สร้าง noise เพิ่ม

สถานะเหล่านี้ไม่ได้ทำให้ defect “หายไป” แต่ช่วยให้ backlog ของปัญหาสะอาดขึ้นและสื่อสารได้ตรงขึ้น

หลายปัญหาไม่ได้อยู่ที่บั๊ก แต่อยู่ที่วิธีทีมจัดการกับบั๊ก

1. ใช้สถานะไม่ชัด

เช่น dev เปลี่ยนเป็น Fixed ทั้งที่ deploy ยังไม่ถึง env ที่ QA ใช้จริง

2. ปิด defect เร็วเกินไป

แค่ merge code แล้วรีบปิด ทั้งที่ QA ยังไม่ retest

3. ไม่มี triage ที่ชัด

defect ถูกเปิดเรื่อย ๆ แต่ไม่มีใครตัดสิน priority หรือ owner

4. Reopen โดยไม่อธิบาย

ถ้า QA reopen โดยไม่มีข้อมูลเพิ่ม dev จะไม่รู้ว่าต้องแก้อะไรต่อ