QA ส่ง bug มา 21 ตัว — ผมปิดได้ 16 ตัวใน session เดียว โดยไม่แตะ 4 ตัวที่ไม่ใช่ของผม · บทความ

QA ส่ง bug มา 21 ตัว ก่อน launch

ปกติเจอแบบนี้จะทำยังไง? เปิดทีละตัว แก้ทีละตัว ส่ง PR ทีละตัว

ผมทำแบบนั้นไม่ได้ เพราะ 21 ตัวนี้ไม่เท่ากัน

บาง ticket ชื่อบอกว่า frontend แต่จริงๆ เป็น backend
บาง ticket 3 ตัว root cause เดียวกัน — แก้ตัวเดียวปิดได้ 3
บาง ticket ไม่ใช่ bug เลย — แค่ความเห็นเรื่อง UX

ปัญหาไม่ใช่ bug เยอะ ปัญหาคือ การตัดสินใจเยอะ

วิธีแบ่งที่ใช้จริง

ก่อนจะแตะ code สักบรรทัด ผมแบ่ง 21 ตัวออกเป็น 5 ถัง:

1. แก้ใน code (16 ตัว) — bug จริง root cause ชัด แก้ได้
ไม่ได้แก้ทีละตัว — จัดกลุ่มตาม root cause ก่อน:

5 tickets ที่ error message อ่านไม่รู้เรื่อง → แก้ด้วย pattern เดียว ปิดได้ทีเดียว 5 ตัว
3 tickets ที่ wizard ค้าง → ไล่ตรวจทุกหน้าจอ ปิดได้ 3

จัดกลุ่มตาม root cause ทำให้ 16 tickets เหลือแค่ ~8 การตัดสินใจ

2. ส่งต่อ (4 ตัว) — ไม่ใช่ของผม

2 ตัวเป็น FE rendering bug → ส่งให้ frontend
1 ตัวตั้งชื่อผิด (ชื่อบอก backend แต่จริงๆ เป็น UI copy)
1 ตัวแก้ไปแล้วในรอบก่อน

เขียน comment อธิบายว่าทำไมส่งต่อ + ใครควรรับ แล้ววาง ไม่แตะ code

3. พักไว้ก่อน (3 ตัว) — ยังไม่ถึงเวลา
กฎก่อน launch: ไม่เพิ่ม bug ใหม่เข้า sprint ที่กำลังจะ ship
ถ้า bug ไม่ block launch → comment ไว้ว่า "หลัง launch" แล้วพักไว้

4. ใส่ logging ก่อน (1 ตัว) — ยังไม่รู้ root cause
บาง bug reproduce ไม่ได้ แต่มี signal ว่าเกิดจริง
แทนที่จะเดาแล้วแก้ → ship logging ไปก่อน พอ reproduce ได้ค่อยแก้จริง

5. แก้ได้บางส่วน (2 ตัว)
ปรับให้อ่านง่ายขึ้นทำได้เลย แต่แก้ที่ต้นเหตุจริงๆ ต้องรอ API เปลี่ยน → แก้แค่ส่วนที่ทำได้ comment ส่วนที่เหลือไว้

ทำไมถึงไม่แก้ทั้ง 21 ตัว

เพราะ 4 ตัวที่ส่งต่อ → ถ้าผมแก้เอง จะ:

แก้ FE bug ที่ frontend dev เข้าใจ context ดีกว่า
ใช้เวลา 2 เท่า เพราะไม่รู้ว่า component นั้นมี state ยังไง
สร้างบรรทัดฐานว่า "ส่ง backend ก็ได้ เดี๋ยวเขาแก้ให้"

triage ที่ดี ≠ แก้ทุกอย่าง
triage ที่ดี = แยกให้ได้ว่าอันไหนของใคร แล้วทำแค่ของตัวเอง

ผมสอน Claude Code ให้ triage เป็น — ด้วย markdown ไฟล์เดียว

ผมไม่ได้นั่ง copy ticket ทีละตัวมาให้ AI อ่าน

ผมเขียนไฟล์ skill — markdown ที่สอน Claude Code ว่า triage คืออะไร:

ดึง tickets ทั้งหมดจาก Linear ผ่าน API
download screenshots ก่อน signed URL หมดอายุ (5 นาที)
ตรวจชื่อ ticket กับ codebase จริง — เพราะ 1 ใน 10 ตัวชื่อไม่ตรงกับ bug จริง
จัดกลุ่มตาม root cause ไม่ใช่ตาม severity

พิมพ์ "triage QA-1530" → ภายใน 5 นาทีได้กลุ่ม bug กลับมา:

5 tickets มาจาก error handling pattern เดียวกัน → 1 การตัดสินใจ
3 tickets มาจาก wizard state เดียวกัน → 1 การตัดสินใจ

แต่ skill ทำได้แค่จัดกลุ่ม

มันตัดสินใจไม่ได้ว่าอันไหน "ไม่ใช่ของเรา" — การส่งต่อ 4 ตัวนั้นต้องใช้ context ที่ AI ไม่มี: ใครรับผิดชอบ component ไหน ใครเข้าใจ state ของ FE ดีกว่า

ไฟล์ skill = งานเตรียมข้อมูล / คน = คนตัดสินใจ

ถ้าคุณมี backlog ที่ไม่มีใครอยากอ่าน ลองเขียน skill ที่ยุบรวมการตัดสินใจ แทนที่จะไล่ดู ticket ทีละตัว

สิ่งที่ได้

ก่อน: 21 tickets → ประชุม 2 ชั่วโมง ตัดสินใจไม่จบ
หลัง: 21 tickets → AI จัดกลุ่ม root cause → 8 การตัดสินใจ → 11 releases → ship ได้ภายในวัน

วิธีแบ่ง 5 ถังนี้ใช้ได้กับทุก QA round:

แก้ใน code
ส่งต่อ
พักไว้ก่อน
ใส่ logging ก่อน
แก้ได้บางส่วน

ลอง triage backlog ที่ค้างอยู่ด้วย 5 ถังนี้ดู — ไม่ต้องแก้ทุกตัว แค่แยกให้ถูก ถ้ามี AI ช่วยจัดกลุ่มยิ่งเร็ว แต่ตัดสินใจเรื่องส่งต่อต้องเป็นคุณ