QA ใน Sprint: ทำอะไรในแต่ละวัน?
ในทีม Agile งาน QA ไม่ได้เริ่มเมื่อ dev บอกว่าเสร็จแล้ว แต่กระจายอยู่ตลอด sprint ตั้งแต่ refinement จนถึง review และ retro บทนี้จะช่วยให้คุณมองเห็นวันทำงานของ QA แบบทั้งรอบ ไม่ใช่แค่ช่วง execute
จบบทนี้แล้วคุณจะ...
- วาด sprint timeline และใส่กิจกรรม QA ลงไปได้เป็นระบบ
- เข้าใจว่าทำไม QA ต้องเริ่มทำงานตั้งแต่วันแรกของ sprint
- เห็นว่าการ feedback เร็วระหว่าง sprint ช่วยลด rework ยังไง
- มองออกว่าเมื่อไรทีมกำลังทำ Agile จริง และเมื่อไรเป็น Waterfall ในเสื้อ Agile
- มีไอเดียปรับวิธีทำงานของทีมแบบทีละขั้น ไม่ต้องเปลี่ยนทั้งระบบในวันเดียว
ถ้า sprint ยาว 2 สัปดาห์ QA ไม่ควรมีวันไหนที่ "ยังไม่มีงาน"
ลองนึกถึง sprint 10 วันทำการ
ถ้าทีมทำงาน healthy กิจกรรมของ QA มักกระจายประมาณนี้
| ช่วงเวลา | สิ่งที่เกิดในทีม | QA ควรทำอะไร |
|---|---|---|
| ก่อน sprint | refinement / backlog prep | clarify stories, flag risk, ช่วยให้ criteria testable |
| Day 1 | sprint planning | ประเมิน test effort, data/env needs, dependency |
| Day 1–3 | dev เริ่ม implement | เขียน test conditions/cases/checklists, เตรียม data |
| Day 4–7 | story เริ่มทยอยเสร็จ | test ทันที, pair กับ dev, report feedback เร็ว |
| Day 8–9 | integration + stabilization | regression, exploratory, triage defects |
| Day 10 | review / retro | สรุปผลทดสอบ, residual risk, process improvements |
ประเด็นสำคัญ
QA ที่ทำงานดีใน Agile จะไม่พูดว่า:
"ยังทำอะไรไม่ได้ รอ dev ส่งมาก่อน"
เพราะก่อนจะมี build ก็ยังมีงานที่ช่วยให้ build แรกมีโอกาสถูกมากขึ้นเสมอ
Refinement
นี่คือช่วงที่ช่วยทีมได้คุ้มที่สุด
ตัวอย่างสิ่งที่ QA ควรถาม:
- success / failure criteria ชัดไหม
- มี edge case อะไรซ่อนอยู่
- มี dependency กับ service อื่นไหม
- ต้องใช้ state หรือ data พิเศษหรือไม่
ถ้า story ยังไม่ชัดพอ การปล่อยเข้า sprint จะสร้าง rework แทบแน่นอน
Planning
ใน planning QA ควรช่วยให้ทีมเห็นว่า:
- story ไหนเสี่ยงกว่าที่คิด
- story ไหนต้องใช้ env/data setup เพิ่ม
- story ไหน test effort สูงและไม่ควรถูกดูถูกว่า "แค่ปุ่มเดียว"
ระหว่าง dev เขียน code
QA ไม่ได้มีหน้าที่รออย่างเดียว
สิ่งที่ทำได้:
- เขียน test artifacts ล่วงหน้า
- เตรียม account / data
- ตรวจ logic กับ dev ใน flow ที่ซับซ้อน
- เตรียม checklist สำหรับ smoke หรือ handoff
ระหว่าง story เริ่มเสร็จ
สิ่งสำคัญคือ test ให้เร็ว
ยิ่ง test หลัง dev ส่งไม่นาน:
- dev ยังจำ context ได้
- bug แก้เร็ว
- story ไม่ค้างถึงท้าย sprint
Review / Retro
QA ควรสรุปให้ทีมเห็น:
- อะไรพิสูจน์แล้ว
- อะไรยังเป็น residual risk
- ปัญหากระบวนการเกิดตรงไหน
ทีมบอกว่า Agile แต่จังหวะงานยังเป็น Waterfall
| อาการ | ความหมายที่ซ่อนอยู่ |
|---|---|
| QA เห็น story จริงตอนปลายสัปดาห์แรก | refinement/hand-off ยังไม่ดี |
| dev ส่งทุกอย่างวันท้าย ๆ | story ใหญ่เกินหรือการ split ไม่ดี |
| QA เทสต์กองเดียวท้าย sprint | feedback loop ช้า |
| bug critical โผล่วัน review บ่อย | continuous testing ไม่เกิดจริง |
| retro ไม่พูดเรื่อง testing process | ทีมมอง QA แยกจาก flow หลัก |
ตัวอย่างคำพูดที่เป็นสัญญาณเตือน
- "เดี๋ยวค่อยให้ QA ดูตอน dev เสร็จหมด"
- "รอบนี้ยังไม่ต้องเทสต์ละเอียด เดี๋ยวค่อยดูท้าย sprint"
- "bug นี้ค้างไว้ sprint หน้าแล้วกัน"
ถ้าได้ยินบ่อย ๆ แปลว่าทีมกำลังสะสมความเสี่ยงไว้ตอนท้าย
งานจำนวนมากไม่ได้อยู่ใน test runner
งานของ QA ระหว่าง sprint อาจรวมถึง:
- ตอบคำถามเรื่อง expected behavior
- ช่วย dev ตรวจว่าควรป้องกัน edge case ไหน
- เตรียม seeded data
- อัปเดต checklist และ regression notes
- triage defect ว่าคือ bug หรือ clarification gap
- สรุป risk ให้ PM เพื่อจัดลำดับงาน
สิ่งเหล่านี้ไม่ได้ทำให้ตัวเลข "test cases executed" เพิ่มทันที แต่ช่วยให้คุณภาพของทั้ง sprint ดีขึ้นมาก
ไม่ใช่ทุก sprint จะมีเวลาเท่าที่อยากได้
เวลาจำกัด ให้ QA ถามก่อนว่า:
- flow ไหนคือ core business flow
- bug แบบไหนรับไม่ได้เด็ดขาด
- story ไหนเพิ่งเปลี่ยนเยอะที่สุด
จากนั้นลงน้ำหนักแบบนี้:
- smoke ก่อน
- test story ใหม่ที่เสี่ยงสูงก่อน
- regression เฉพาะส่วนกระทบก่อน
- exploratory ในพื้นที่ที่ความไม่แน่นอนสูง
นี่คือการคิดแบบ risk-based testing ใน sprint จริง
เปลี่ยนทีละจุดที่คุ้มที่สุดก่อน
คุณไม่จำเป็นต้องทำให้ทีม mature ทั้งระบบในทันที
เริ่มจากจุดที่ impact สูงและเปลี่ยนได้จริง เช่น:
- ดึง QA เข้า refinement ให้ได้ก่อน
- ขอสัญญาว่า story ที่เสร็จแล้วจะส่งให้ test ภายใน 24 ชั่วโมง
- ทำ smoke checklist กลางของทีม
- สรุป bug และ process gap ใน retro สั้น ๆ ทุกครั้ง
การชนะเล็ก ๆ แบบต่อเนื่อง มักเปลี่ยนวัฒนธรรมได้จริงกว่าแผนใหญ่ที่ไม่มีใครทำตาม
ลองวิเคราะห์ sprint ของทีมด้วยมุมมอง QA
ทีมหนึ่งเริ่ม sprint วันจันทร์ แต่ QA ได้ test story แรกจริงวันศุกร์
ดูคำตอบแนะนำ
นี่เป็นสัญญาณว่า QA เข้า flow ช้าเกินไป อาจเกิดจาก story ใหญ่เกิน, dev ส่งงานช้า, หรือไม่มี continuous testing ผลคือ bug จะไปกองท้าย sprint และ feedback loop ช้า
dev บ่นว่า QA ถามเยอะเกินระหว่างวันจนทำงานไม่ต่อเนื่อง
ดูคำตอบแนะนำ
QA ควรปรับจังหวะ เช่น ย้ายคำถามส่วนใหญ่ไป refinement, รวมคำถามเป็นชุด, และแยกให้ชัดว่าอะไรคือ blocker ตอนนี้กับอะไรที่รอได้ ไม่ใช่หยุด dev ทุกชั่วโมง
เจอ bug critical วันสุดท้ายของ sprint ก่อน review
ดูคำตอบแนะนำ
QA ควรรีบสรุป impact และ severity ให้ทีมตัดสินใจ ไม่ใช่ตัดสินคนเดียว จากนั้นใช้ retro วิเคราะห์ว่า bug นี้ควรถูกเจอตรงไหนเร็วกว่านี้
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- QA ใน Agile ควรมีบทบาทตั้งแต่ก่อน sprint เริ่ม จนถึง review และ retro
- งาน QA ไม่ใช่แค่ execute แต่รวมถึง clarify, design, prepare และ summarize risk
- ถ้า testing ไปกองท้าย sprint ทีมกำลังสะสมความเสี่ยงไว้ตอนท้าย
- feedback ที่เร็วช่วยให้ dev แก้ bug ได้ตอนยังมี context อยู่
- อยากให้ทีม mature ขึ้น ให้เริ่มจากจุดที่คุ้มที่สุดก่อน ไม่ต้องเปลี่ยนทุกอย่างพร้อมกัน