Bug Management

Bug Lifecycle

บั๊กมีสถานะที่เปลี่ยนไปตามขั้นตอนมาตรฐาน — การเข้าใจ lifecycle ช่วยให้สื่อสารกับทีมชัดเจนว่า "ตอนนี้บั๊กอยู่ขั้นไหน ใครต้องทำอะไรต่อ"

New → Open (triage แล้ว ยืนยันว่าเป็นบั๊กจริง) → Assigned → In Progress
  → Fixed (dev แก้แล้ว รอ verify) → Retest (QA ทดสอบซ้ำ)
    → Closed (ยืนยันแก้ได้จริง)         [เส้นทางปิดบั๊ก]
    → Reopened (ยังพังอยู่/แก้ไม่หมด)   [กลับไป In Progress]
  → Rejected (ไม่ใช่บั๊ก/ตามออกแบบ) หรือ Duplicate (ซ้ำกับ ticket อื่น) [เส้นทางปิดโดยไม่ต้องแก้]

🧠 จำง่ายๆ

"บั๊กที่ Fixed แล้วยังไม่ใช่ Closed จนกว่า QA retest ผ่าน" — dev บอกว่า "แก้แล้ว" ไม่เท่ากับ "แก้ได้จริง" ต้องมีคนอื่น (ideally ไม่ใช่คนเขียนโค้ดเอง) verify ซ้ำก่อนปิด ticket เสมอ

🎯 Beyond: จุดที่ชาวบ้านไม่ค่อยรู้

Retest ที่ทำแค่ "ลองสิ่งที่ dev บอกว่าแก้แล้ว" ไม่พอ — QA ที่มี experience จะทำ regression testing รอบๆ fix ด้วย เพราะการแก้บั๊กหนึ่งจุด (โดยเฉพาะการแก้แบบรีบๆ ใต้ pressure deadline) มีโอกาสสร้างบั๊กใหม่ในส่วนที่เกี่ยวข้องได้สูง (เรียกว่า regression) ยิ่งโค้ดส่วนนั้นถูกแก้ บ่อยและซับซ้อน ยิ่งควรขยาย scope การ retest ให้กว้างกว่าแค่ scenario เดิมที่ report บั๊กไว้ — นี่ คือเหตุผลที่ทีม production มักมี regression test suite (อัตโนมัติเป็นส่วนใหญ่) รันซ้ำทุกครั้ง ที่มีการแก้โค้ด ไม่ใช่พึ่งการ retest เฉพาะจุดอย่างเดียว

Severity/Priority Matrix สำหรับ Triage

การ triage บั๊กใหม่ควรตอบสองคำถามแยกกัน (ดู Severity vs Priority) แล้ว plot ลง matrix เพื่อจัดลำดับคิวแก้

	Priority สูง	Priority ต่ำ
Severity สูง	แก้ก่อนทุกอย่าง (เช่น payment ล่มตอน high-traffic)	แก้แต่ไม่ด่วน (เช่น data corruption ที่ trigger ยากมาก, ยังไม่เจอจริง)
Severity ต่ำ	แก้เร็วๆ นี้ (เช่น ตัวอักษรผิดบนหน้าที่ลูกค้าดูตอน demo สำคัญ)	เก็บ backlog (เช่น สี button เพี้ยนนิดหน่อยบนหน้าที่ไม่มีคนเข้า)

🧠 จำง่ายๆ

"Severity สูง + Priority สูง = ไฟไหม้ตอนนี้, Severity ต่ำ + Priority ต่ำ = เก็บไว้ว่างๆ ค่อยทำ" — สองแกนนี้ช่วยแยกคิวแก้บั๊กโดยไม่ต้องเถียงกันทุกครั้งว่า "บั๊กนี้สำคัญแค่ไหน"

🎯 Beyond: จุดที่ชาวบ้านไม่ค่อยรู้

Triage meeting ที่มีประสิทธิภาพต้องมีคนจากทั้ง technical (QA/Dev กำหนด severity) และ business (PO/PM กำหนด priority ร่วมกับ severity) อยู่ในห้องพร้อมกัน — ทีมที่ให้ QA เป็นคน ตัดสินทั้ง severity และ priority เองฝ่ายเดียวมักจบลงที่การจัดลำดับที่ไม่ตรงกับความจริงทางธุรกิจ (เช่น ให้ priority บั๊กที่ QA คิดว่าสำคัญทางเทคนิค แต่ธุรกิจมองว่ายังไม่กระทบรายได้ตอนนี้) และ ในทางกลับกัน ทีมที่ให้ business ตัดสินทั้งสองแกนเองก็มักประเมิน severity ผิดเพราะไม่เข้าใจความ เสี่ยงทางเทคนิคจริง (เช่น มองว่าบั๊ก security เล็กน้อยเพราะ "ยังไม่มีคนโจมตี" โดยไม่เข้าใจว่า ความเสี่ยงไม่ได้อยู่ที่ "เกิดแล้วหรือยัง" แต่อยู่ที่ "เกิดได้ง่ายแค่ไหนถ้ามีคนตั้งใจทำ")

การเขียน Bug Report ที่ดี

Bug report ที่ดีควรให้ dev reproduce บั๊กได้โดยไม่ต้องถามอะไรเพิ่ม — ยิ่งต้องไปๆ มาๆ ถาม รายละเอียดเพิ่มหลายรอบ ยิ่งเสียเวลาทั้งสองฝ่าย

องค์ประกอบที่ต้องมี:

• Title สั้นแต่บอกปัญหาจริง (ไม่ใช่ "มันพัง" — ต้องบอกว่าพังยังไง ที่ไหน)
• Steps to reproduce ทีละก้าว เริ่มจาก state ตั้งต้นที่ชัดเจน
• Expected result vs Actual result แยกให้ชัด
• Environment (browser/OS/version, user role, feature flag ที่เปิดอยู่)
• Evidence: screenshot/video/log/network request ที่เกี่ยวข้อง
• Severity ที่ประเมินไว้เบื้องต้น (priority ให้ทีม triage ตัดสินร่วมกัน)

แย่:  Title: "login พัง"
      Body:  "กด login แล้วไม่เข้า"

ดี:   Title: "Login ล้มเหลวด้วย error 500 เมื่อ email มีตัวพิมพ์ใหญ่ปนตัวพิมพ์เล็ก"
      Steps: 1) เปิดหน้า /login (build staging v2.4.1)
             2) กรอก email เป็น "User@Test.com" (มีตัวพิมพ์ใหญ่)
             3) กรอก password ที่ถูกต้อง
             4) กด submit
      Expected: Login สำเร็จ, redirect ไปหน้า dashboard
      Actual:   แสดง error 500, console log แสดง "duplicate key" (ดู attached log)
      Environment: Chrome 131, staging, user role = customer
      หมายเหตุ: เกิดเฉพาะเมื่อมี account เดิมที่สมัครด้วย email ตัวพิมพ์เล็กล้วนอยู่แล้ว

🧠 จำง่ายๆ

"Bug report ที่ดีคือใบสั่งยาที่หมอคนอื่นอ่านแล้วรักษาต่อได้ทันที ไม่ใช่แค่บอกว่า 'ป่วย'" — ยิ่ง ให้ข้อมูลเฉพาะเจาะจงเท่าไหร่ dev ยิ่งแก้เร็วขึ้นเท่านั้น

🎯 Beyond: จุดที่ชาวบ้านไม่ค่อยรู้

รายละเอียดที่แยก bug report ระดับ "ดี" จาก "ดีมาก" คือการใส่ "สิ่งที่ลองแล้วไม่ใช่สาเหตุ" ด้วย (เช่นในตัวอย่างข้างบน การสังเกตว่า "เกิดเฉพาะเมื่อมี account เดิมที่ email ตัวพิมพ์เล็กล้วน อยู่แล้ว") ข้อมูลนี้ช่วย dev ตัดทางเดาผิดๆ ออกไปได้เร็วมาก (ในตัวอย่างนี้ชี้ไปที่ปัญหา case sensitivity ของ unique constraint ใน database แทบจะทันที โดย dev ไม่ต้องเสียเวลาไล่ debug ตั้งแต่ชั้น UI) QA ที่มี experience มักทำ mini-investigation ก่อน submit bug report (ลอง เปลี่ยนตัวแปรทีละตัวเพื่อแยกว่าอะไรคือเงื่อนไขจริงที่ trigger บั๊ก) ซึ่งเป็นทักษะที่ใกล้เคียงกับ debugging ของ dev มากกว่าการ "รายงานอาการ" เฉยๆ — เป็นสิ่งที่ interviewer มักมองหาเมื่อถามว่า "อธิบายกระบวนการ investigate บั๊กที่ซับซ้อนที่สุดที่เคยเจอ"

English Summary

A bug's lifecycle (New → Open → Assigned → In Progress → Fixed → Retest → Closed/Reopened, or Rejected/Duplicate) isn't complete until QA retests — and good retesting includes regression testing around the fix, since fixes made under deadline pressure often introduce new bugs nearby. Severity (technical impact) and priority (business urgency) should be set by technical and business stakeholders together in triage, not by either side alone. A strong bug report lets a developer reproduce the issue without follow-up questions: clear title, numbered repro steps, expected vs. actual, environment, evidence, and severity — the mark of an excellent report is including what was ruled out during a mini-investigation, which narrows the developer's debugging path dramatically.