ถ้าทุกคนเป็นเจ้าของคุณภาพ แล้ว QA มีไว้ทำไม?
นี่คือคำถามที่หลายทีมติดอยู่กลางทาง ถ้าบอกว่าคุณภาพเป็นของ QA คนเดียว ก็แปลว่าทีมที่เหลือสามารถปล่อยมือได้ แต่ถ้าบอกว่าคุณภาพเป็นของทุกคน เราก็ต้องตอบให้ได้ว่าแต่ละบทบาทรับผิดชอบอะไรจริง ๆ
จบบทนี้แล้วคุณจะ...
- อธิบาย shared quality ownership ได้แบบไม่คลุมเครือ
- เห็นว่าทำไมการโยนคุณภาพให้ QA คนเดียวถึงใช้ไม่ได้ในระบบจริง
- เข้าใจหน้าที่ด้านคุณภาพของ PM, BA, Dev, QA, DevOps และ Designer มากขึ้น
- มองบทบาท QA เป็น quality advocate แทนการเป็นคนตรวจงานปลายทาง
- เริ่มเปลี่ยนบทสนทนาในทีมจากการโทษคน ไปเป็นการปรับกระบวนการ
"QA เทสต์แล้ว ทำไมยังมีบั๊กหลุด?"
ประโยคนี้ฟังเหมือนปกติ แต่จริง ๆ มันซ่อนวิธีคิดที่อันตรายมาก:
ทีมกำลังเชื่อว่าคุณภาพเป็นหน้าที่ของ QA คนเดียว
ถ้าทีมเชื่อแบบนั้น ผลลัพธ์ที่ตามมามักเป็นแบบนี้:
- BA เขียน requirement ไม่ชัดก็ไม่เป็นไร เพราะ QA จะไปเจอเอง
- Dev ไม่เทสต์ของตัวเองละเอียดก็ไม่เป็นไร เพราะ QA จะดักให้
- PM รีบ push release ก็ได้ เพราะยังมี QA เป็นด่านสุดท้าย
ปัญหาคือในโลกจริงไม่มี QA คนไหนตรวจทุกกรณีได้หมดคนเดียว โดยเฉพาะเมื่อระบบใหญ่ขึ้นเรื่อย ๆ
เปรียบเทียบให้เห็นภาพ
QA เหมือนผู้รักษาประตูในทีมฟุตบอล
- ผู้รักษาประตูสำคัญมาก
- แต่ถ้ากองหลังไม่ช่วย
- midfield เสียบอลง่าย
- และกองหน้าปล่อยให้คู่แข่งสวนกลับตลอด
ต่อให้ผู้รักษาประตูเก่งแค่ไหน ทีมก็เสียประตูอยู่ดี
คุณภาพของซอฟต์แวร์ก็เหมือนกัน
ไม่ได้แปลว่า "ทุกคนทำทุกอย่าง" แต่แปลว่า "ทุกคนรับผิดชอบในจุดที่ตัวเองควบคุมได้"
คำว่า shared quality ownership ไม่ได้หมายความว่า:
- Dev ต้องทำงาน QA ทั้งหมด
- QA ต้องเขียน code ทั้งหมด
- PM ต้องมานั่งรัน regression เอง
ความหมายที่ถูกคือ:
ทุกคนในทีมต้องรับผิดชอบคุณภาพในมุมที่ตัวเองมีอิทธิพลมากที่สุด
แปลเป็นภาษาง่าย ๆ
- PM / PO คุมว่าเรากำลังสร้างสิ่งที่มีคุณค่าจริงไหม
- BA คุมว่าความต้องการชัดพอให้ทีมทำตรงกันไหม
- Developer คุมว่า implementation ถูกและ maintainable ไหม
- QA คุมว่าความเสี่ยงถูกมองครบหรือยัง และทีมมีข้อมูลพอตัดสินใจไหม
- DevOps / SRE คุมว่าระบบพร้อมรันจริงและมีการมองเห็นปัญหาไหม
- Designer คุมว่าผู้ใช้เข้าใจและใช้งานได้จริงไหม
ถ้าแยกความรับผิดชอบชัด การคุยกันจะไม่กลายเป็นการโยนงาน
| บทบาท | มุมคุณภาพที่ควบคุมได้ | ตัวอย่างงาน |
|---|---|---|
| PM / PO | business value, scope, priority | เลือกว่าอะไรสำคัญ, อะไรเลื่อน, risk ไหนรับได้ |
| BA | requirement quality | เขียน criteria ชัด, หา edge case, clarify flow |
| Developer | code quality และ technical correctness | unit test, code review, input validation, error handling |
| QA | test strategy, coverage, risk visibility | test design, exploratory testing, release risk summary |
| Designer | usability, accessibility, flow clarity | interaction design, copy, accessibility review |
| DevOps / SRE | operability, deployment safety, monitoring | CI/CD, observability, rollback, alerting |
จุดสำคัญที่ต้องจำ
QA ไม่ได้ "เป็นเจ้าของคุณภาพทั้งหมด"
QA เป็นเจ้าของ มุมมองด้านความเสี่ยงและการทดสอบ
หน้าที่หลักของ QA คือทำให้ทีมเห็นว่า:
- ยังมีอะไรไม่ชัด
- ยังมีอะไรยังไม่ถูกพิสูจน์
- ยังมี risk อะไรค้างอยู่ก่อน release
จากผู้ตรวจงาน สู่ Quality Advocate
ในทีมที่คุณภาพเป็น shared ownership จริง บทบาท QA จะเปลี่ยนจาก:
- คนรับงานตอนท้าย
- คนที่ถูกถามตอนมี bug
- คนที่คอย block release
ไปเป็น:
- คนที่ถามคำถามยากตั้งแต่ต้น
- คนที่ช่วยทีมมอง risk รอบด้าน
- คนที่ช่วยให้ทีมตัดสินใจจากข้อมูล ไม่ใช่ความรู้สึก
| QA แบบเดิม | QA แบบที่ทีมต้องการมากขึ้น |
|---|---|
| รอ build แล้วค่อยเริ่ม | เข้า refinement และ planning |
| โฟกัสแค่ bug finding | ช่วย bug prevention ด้วย |
| วัดตัวเองด้วยจำนวนเคสที่รัน | วัดผลด้วยคุณภาพของ feedback และ risk coverage |
| คุยกับ dev ตอนมี defect | คุยกับ dev ตั้งแต่ก่อน defect จะเกิด |
ทีมที่แข็งแรงจะถามว่า "process พลาดตรงไหน" ไม่ใช่ "ใครผิด"
เวลา defect หลุด production คุณมี 2 ทางเลือก
ทางแรก
- ใครเป็นคนเขียน?
- QA เทสต์หรือยัง?
- ทำไมไม่เจอ?
ผลลัพธ์คือคนในทีมป้องกันตัวเอง และไม่มีใครอยากเปิดปัญหาจริง
ทางที่สอง
- bug นี้ควรถูกเจอเร็วกว่าเดิมตรงไหน?
- requirement ชัดพอไหม?
- dev มี test coverage ตรงนี้หรือยัง?
- regression suite ควรเพิ่มอะไร?
ผลลัพธ์คือทีมได้เรียนรู้และลดโอกาสเกิดซ้ำ
ตัวอย่าง
ถ้า signup flow พังเพราะ email ที่มี whitespace ผ่าน validation ได้
คนที่มีส่วนอาจมีทั้ง:
- BA ที่ไม่ได้ระบุ rule เรื่อง trim
- Dev ที่ไม่ได้ validate
- QA ที่ไม่ได้คิด whitespace case
แต่เป้าหมายไม่ใช่การชี้นิ้วว่าใครผิดที่สุด เป้าหมายคือ:
ครั้งหน้าจะทำยังไงให้ทีมเจอเรื่องแบบนี้เร็วกว่านี้
| สัญญาณ | ความหมายที่ซ่อนอยู่ |
|---|---|
| "เดี๋ยว QA ไปเช็กเอา" | คนอื่นปล่อยมือเรื่องคุณภาพ |
| Dev ไม่ค่อยรันของตัวเอง | quality ถูกโยนปลายทาง |
| QA ไม่เข้า requirement discussion | ทีมมอง QA เป็น executor ไม่ใช่ partner |
| เวลา bug หลุด ทุกคนมองหน้า QA | ownership กระจุกอยู่คนเดียว |
| usability issue ถูกมองว่าไม่ใช่ bug | ทีมยังมองคุณภาพแค่มิติ functional |
วิธีขยับทีมแบบไม่ชนเกินไป
- เริ่มพูดเรื่อง quality เป็นภาษาของ risk
- ใช้ตัวอย่าง defect จริงเป็น case study
- ชวน dev review test conditions ก่อน execute
- ชวน BA ดูคำถาม clarification ก่อน story เข้า sprint
ค่อย ๆ เปลี่ยนบทสนทนา จะได้ผลดีกว่าการบอกว่าทีมทำผิดทั้งหมด
ลองวิเคราะห์ว่าใครควรรับผิดชอบหลักในสถานการณ์นี้
acceptance criteria ไม่ชัด ทำให้ dev ทำ flow ผิด และ QA มาเจอตอนท้าย sprint
ดูคำตอบแนะนำ
คนหลักคือ <strong>BA / PM</strong> ในด้าน requirement quality แต่ QA ก็มีบทบาทถ้าไม่ได้ตั้งคำถามตั้งแต่ refinement และ dev ก็มีบทบาทถ้าเริ่มลงมือทั้งที่ยังไม่เข้าใจ จุดสำคัญคือทุกคนมีส่วน ไม่ใช่โยนให้คนเดียว
ระบบล่มตอน traffic พุ่ง เพราะไม่มี monitoring เตือนก่อน
ดูคำตอบแนะนำ
<strong>DevOps / SRE</strong> เป็นคนหลักในด้าน operability แต่ QA ก็มีคุณค่าถ้าเคย flag เรื่อง performance risk ก่อน release แล้ว จุดนี้สะท้อน shared ownership ชัดมาก
feature ใช้งานได้ครบตาม requirement แต่ผู้ใช้บ่นว่าใช้งานยากและไม่เข้าใจข้อความบนหน้าจอ
ดูคำตอบแนะนำ
<strong>Designer + PM</strong> มีบทบาทหลักด้าน usability และ product fit แต่ QA ก็ควรยก usability concern ขึ้นมา ไม่ใช่เงียบเพราะ "มันไม่ใช่ functional bug"
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- คุณภาพเป็นของทั้งทีม ไม่ใช่ของ QA คนเดียว
- shared ownership ไม่ได้แปลว่าทุกคนทำทุกอย่าง แต่แปลว่าทุกคนรับผิดชอบในจุดที่ตัวเองควบคุมได้
- QA ที่ทีมต้องการมากที่สุดคือ quality advocate ไม่ใช่แค่คนตรวจงาน
- เวลามี defect หลุด ให้ถามหาช่องโหว่ของกระบวนการ ไม่ใช่หาแพะ
- ทีมที่คุณภาพดีจริง จะไม่มีใครพูดว่า "เรื่องคุณภาพไม่ใช่งานฉัน"