SDLC คืออะไร และ QA อยู่ตรงไหนในวงจรนั้น?
หลายคนยังนึกว่า QA เข้ามาเมื่อ dev ทำงานเสร็จแล้ว แต่ถ้ามองผ่านกรอบของ SDLC จริง ๆ คุณจะเห็นว่า QA เพิ่มคุณค่าได้ตั้งแต่ requirement วันแรก ไปจนถึงวันที่ระบบขึ้น production และหลังจากนั้น
จบบทนี้แล้วคุณจะ...
- อธิบายได้ว่า SDLC คืออะไรและทำไมทีมต้องมองงานเป็นวงจร
- เปรียบเทียบ Waterfall, Agile และ hybrid ได้จากมุมมองของ QA
- เห็นชัดว่า QA เพิ่มคุณค่าได้ในแต่ละเฟสอย่างไร ไม่ใช่แค่ตอน test execution
- รู้จักสัญญาณของทีมที่ทำงานแบบ "รอส่งให้ QA" และรู้ว่าควรแก้อย่างไร
- เริ่มวิเคราะห์ทีมของตัวเองได้ว่า QA เข้าไปเร็วพอแล้วหรือยัง
มันไม่ใช่แค่ลำดับขั้น แต่เป็นภาพรวมของการส่งมอบซอฟต์แวร์
SDLC ย่อมาจาก Software Development Lifecycle หรือวงจรการพัฒนาซอฟต์แวร์ พูดง่าย ๆ คือกรอบที่ช่วยให้ทีมตอบคำถามว่า:
- เราเริ่มจากอะไร
- เราต้องผ่านขั้นไหนบ้าง
- ใครมีส่วนร่วมตรงไหน
- เมื่อไรถือว่างานพร้อมส่งต่อ
ถึงแต่ละทีมจะตั้งชื่อเฟสต่างกัน แต่ภาพรวมมักใกล้เคียงกันแบบนี้
| เฟส | จุดประสงค์ | Output ที่มักได้ |
|---|---|---|
| Requirement | เข้าใจปัญหาและความต้องการ | user story, acceptance criteria, business rules |
| Design | วางโครงสร้างและ flow ของระบบ | wireframe, architecture, API contract |
| Implementation | ลงมือสร้างระบบ | code, unit test, config |
| Testing | ตรวจสอบพฤติกรรมและลดความเสี่ยง | defect list, test results, risk notes |
| Release | ส่งมอบให้ผู้ใช้จริง | deployment, release notes |
| Maintenance | ดูแลหลังขึ้น production | hotfix, monitoring, incident review |
จุดที่คนเข้าใจผิดบ่อย
พอเห็นคำว่า Testing เป็นหนึ่งเฟส หลายคนเลยสรุปเร็วเกินไปว่า:
"งั้น QA ก็คงมีหน้าที่อยู่เฟสนี้"
แต่นั่นเป็นภาพที่แคบเกินจริง เพราะ defect จำนวนมากเริ่มจาก requirement, design หรือ handoff ที่คลุมเครือก่อน code จะเริ่มด้วยซ้ำ
ดังนั้น QA ที่มีประสิทธิภาพจึงไม่ได้รอให้ทีม "ส่ง build มาให้เทสต์" แต่เข้าไปช่วยตั้งแต่ก่อนหน้านั้น
Waterfall กับ Agile ต่างกันตรงไหนในชีวิตจริง
คุณไม่จำเป็นต้องท่องทฤษฎีทุกโมเดล แต่ควรแยกอย่างน้อย 2 แบบนี้ให้ออก
| Waterfall | Agile |
|---|---|
| ทำงานเป็นลำดับ เฟสหนึ่งค่อยส่งต่ออีกเฟส | ทำงานเป็นรอบสั้น ๆ และรับ feedback เร็ว |
| requirement มักนิ่งก่อนเริ่ม dev | requirement อาจค่อย ๆ ชัดขึ้นระหว่างทาง |
| testing มักไปอยู่ช่วงท้าย | testing กระจายอยู่ตลอดรอบ |
| เอกสารและ sign-off มีน้ำหนักมาก | การคุยกันบ่อยและปรับตัวเร็วมีน้ำหนักมาก |
| เปลี่ยนกลางทางยาก | เปลี่ยนได้ แต่ต้องจัดการ scope และ priority ให้ดี |
มองจากมุม QA
ใน Waterfall
- QA มักมีเวลาออกแบบ test จากเอกสารค่อนข้างชัด
- แต่ feedback loop ยาว ถ้า requirement ผิด จะรู้ช้าและแก้แพง
- ความเสี่ยงหลักคือ "ทุกอย่างมาชนกันตอนท้าย"
ใน Agile
- QA ต้องคุยกับทีมบ่อยขึ้น
- requirement อาจยังไม่สวยหรือยังไม่ครบในวันแรก
- ความเสี่ยงหลักคือถ้า QA ไม่เข้า refinement ตั้งแต่ต้น จะกลายเป็นคนมารับของท้าย sprint เหมือน Waterfall ปลอม ๆ
แล้ว hybrid ล่ะ?
หลายทีมไม่ได้เป็น Waterfall แท้หรือ Agile แท้ แต่เป็น hybrid เช่น:
- วาง roadmap แบบ quarterly
- ทำงานเป็น sprint ภายใน quarter
- มี sign-off บางส่วนก่อน release
สิ่งสำคัญคือไม่ต้องสนใจป้ายชื่อมากเกินไป ให้ดูว่า:
- feedback กลับมาเร็วไหม
- requirement เปลี่ยนได้ยังไง
- QA เข้าไปตั้งแต่ต้นหรือถูกใช้ตอนท้าย
ถ้ารู้จังหวะที่ควรเข้า คุณจะช่วยทีมได้ก่อน defect เกิด
| เฟส | QA ช่วยอะไรได้จริง |
|---|---|
| Requirement | หา ambiguity, ถาม edge case, ตรวจว่า criteria ทดสอบได้หรือไม่ |
| Design | ถามเรื่อง error handling, state change, observability, testability |
| Implementation | เตรียม test data, ออกแบบ test conditions, pair กับ dev ใน flow เสี่ยงสูง |
| Testing | execute tests, exploratory testing, triage defects, re-test |
| Release | smoke test, summarize risk, support go/no-go discussion |
| Maintenance | วิเคราะห์ defect ที่หลุด, ปรับ regression suite, feedback กลับ requirement รอบถัดไป |
ตัวอย่างเพื่อเห็นภาพ
สมมติทีมกำลังทำฟีเจอร์สมัครสมาชิก
ถ้า QA เข้าเฉพาะช่วง Testing
- จะเจอว่า email ซ้ำ, password policy, verify email ยังไม่ชัด ตอน build มาแล้ว
- dev ต้องย้อนกลับไปถาม BA
- บาง bug แก้ไม่ทัน sprint
ถ้า QA เข้าเร็วตั้งแต่ Requirement
- จะถามเรื่อง email ซ้ำก่อน dev เริ่ม code
- จะช่วยให้ acceptance criteria ชัดขึ้น
- dev ทำถูกมากขึ้นตั้งแต่แรก
นี่คือความต่างระหว่าง QA ที่ "รับงานมาทดสอบ" กับ QA ที่ "ช่วยทีมลดความเสี่ยง"
ถ้าทีมคุณมีอาการแบบนี้ ให้สงสัยว่าการมีส่วนร่วมของ QA มาไม่ทัน
| อาการ | สิ่งที่มักซ่อนอยู่ข้างหลัง |
|---|---|
| QA เจอคำถามสำคัญหลัง build มาแล้ว | QA ไม่ได้เข้า requirement/refinement |
| story เสร็จตอนท้าย sprint แล้วค่อยโดนทดสอบ | testing ถูกบีบไปท้ายรอบ |
| bug เดิม ๆ กลับมาซ้ำ | ไม่มี feedback loop ย้อนกลับไปต้นทาง |
| ทีมชอบพูดว่า "เดี๋ยวให้ QA ไปดู" | quality ownership ยังไม่ shared |
| release ตึงทุกครั้ง | risk ถูกสะสมไว้จนท้ายกระบวนการ |
วิธีแก้ที่ใช้ได้จริง
ไม่จำเป็นต้องปฏิวัติทั้งทีมในครั้งเดียว ลองเริ่มจาก:
- ให้ QA เข้า refinement อย่างน้อยสัปดาห์ละ 1 รอบ
- ให้ QA เห็น story ก่อนเข้า sprint ไม่ใช่วันรับงาน
- ให้ dev ส่งงานเป็นชิ้นเล็กลงเพื่อ test ได้ระหว่าง sprint
- ใช้ defect ที่หลุดเป็นข้อมูลย้อนกลับ ไม่ใช่ใช้เพื่อโทษคน
ทักษะเดียวกัน แต่จังหวะและวิธีใช้ต่างกัน
| ถ้าอยู่ใน Waterfall | ถ้าอยู่ใน Agile |
|---|---|
| ต้องอ่านเอกสารเก่งและออกแบบ test ล่วงหน้าได้ดี | ต้องคุยเก่ง ถามเก่ง และช่วยทีม clarify ให้เร็ว |
| ต้องเก่งเรื่อง traceability ระหว่าง requirement-design-test | ต้องเก่งเรื่อง prioritization และ feedback loop |
| มักวาง regression และ execution เป็นรอบใหญ่ | มักทดสอบเป็นชิ้นเล็กและต่อเนื่อง |
| ระวัง defect ระดับ integration และ late discovery | ระวัง scope change, rushed testing, sprint-end crunch |
QA มืออาชีพจึงไม่ยึดติดกับพิธีกรรม แต่รู้ว่าในบริบทนี้ตัวเองต้องเข้าไปเติมอะไรให้ทีม
Defect ที่หลุดไม่ได้จบที่ "แก้แล้ว"
เวลามี defect หลุด production หลายทีมแก้เสร็จแล้วจบ แต่ทีมที่เก่งกว่าจะถามต่อว่า:
- bug นี้ควรถูกเจอตรงไหนเร็วกว่านี้?
- requirement พลาด หรือ design พลาด?
- test level ไหนควรจับมันได้?
- regression ควรเพิ่มตรงไหน?
เมื่อมองแบบนี้ SDLC จะไม่ใช่เส้นตรงจาก requirement ไป release แล้วจบ แต่เป็นวงจรที่ข้อมูลจากปลายทางย้อนกลับไปทำให้ต้นทางดีขึ้น
นี่คือเหตุผลที่ QA มีบทบาทสำคัญหลัง release ด้วย ไม่ใช่แค่ก่อน release
ลองวิเคราะห์ทีมจากมุม SDLC
ทีมหนึ่งมี requirement ค่อนข้างนิ่ง มีเอกสารเยอะ เปลี่ยนแปลงกลางทางยาก และ QA ได้รับ test document ก่อนเริ่ม execute หลายสัปดาห์
ดูคำตอบแนะนำ
ทีมนี้มีลักษณะใกล้กับ <strong>Waterfall</strong> หรืออย่างน้อยก็ heavy-process มาก จุดแข็งคือวางแผนล่วงหน้าได้ชัด แต่จุดเสี่ยงคือ feedback loop ช้า ถ้า requirement พลาดจะรู้ช้าและแก้แพง
ทีมหนึ่งทำ sprint 2 สัปดาห์ แต่ QA ได้เห็น story จริงวันที่ 8 ของ sprint เพราะ dev อยากทำให้เสร็จก่อนค่อยส่ง
ดูคำตอบแนะนำ
แม้ทีมจะเรียกตัวเองว่า Agile แต่การทำงานแบบนี้ยังเป็น <strong>Waterfall ในเสื้อ Agile</strong> QA เข้าช้าเกินไป ทำให้ feedback loop ไม่สั้นอย่างที่ควรเป็น และ bug จะไปกองช่วงท้าย sprint
ถ้าคุณเพิ่งเข้าทีมใหม่และอยากรู้ว่า QA ควรเข้าไปจุดไหนเป็นอย่างแรก คุณจะเลือกประชุมอะไร?
ดูคำตอบแนะนำ
เริ่มจาก <strong>refinement / requirement discussion</strong> ก่อน เพราะเป็นจุดที่ QA ช่วยลด defect ได้ตั้งแต่ต้นทาง และยังทำให้คุณเข้าใจ flow, business rule, dependency และ risk ของระบบเร็วที่สุด
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- SDLC คือกรอบของการสร้างและส่งมอบซอฟต์แวร์ทั้งระบบ ไม่ใช่แค่ลำดับเอกสาร
- QA เพิ่มคุณค่าได้ในทุกเฟส โดยเฉพาะก่อน code จะเริ่ม
- Waterfall กับ Agile ต่างกันที่จังหวะและ feedback loop แต่ทั้งคู่ยังต้องการ QA ที่เข้าใจ risk
- ถ้า QA เข้าช้า ทีมจะไปสะสม defect และความคลุมเครือไว้ตอนท้าย
- ยิ่ง defect ถูกเจอเร็วเท่าไร ต้นทุนการแก้ยิ่งต่ำ และทั้งทีมยิ่งทำงานลื่นขึ้น