QA Best Practices & Checklist
Shift-Left Testing
Shift-left testing คือการขยับกิจกรรมประกันคุณภาพให้เร็วขึ้นในวงจรพัฒนา (ไปทาง "ซ้าย" ของ timeline) แทนที่จะรอให้โค้ดเสร็จก่อนค่อยคิดเรื่องเทสต์ — รวมถึงการให้ QA ร่วมรีวิว requirement/ design ตั้งแต่ก่อนเริ่มเขียนโค้ด (ดู Three Amigos)
Shift-right (แบบดั้งเดิม): Requirement → Design → Code → [QA เริ่มทำงานตรงนี้] → Release
Shift-left: Requirement → [QA ร่วมรีวิวตรงนี้] → Design → Code (เขียนคู่กับเทสต์) → Release
"จับบั๊กที่ต้นน้ำถูกกว่าปลายน้ำเสมอ" — บั๊กที่จับได้ตอนรีวิว requirement แก้แค่เปลี่ยนคำในเอกสาร บั๊กเดียวกันถ้าหลุดไป production อาจต้อง hotfix, แจ้งลูกค้า, และเสียความน่าเชื่อถือ ต้นทุนต่างกัน หลายสิบเท่า
Shift-left ที่ทำถูกไม่ได้แปลว่า "QA เขียนเทสต์เร็วขึ้น" เฉยๆ แต่หมายถึง QA เปลี่ยนบทบาทจาก "คนตรวจงานหลังเสร็จ" เป็น "คนช่วยออกแบบให้ testable ตั้งแต่แรก" เช่น ตอนรีวิว design ของ feature ใหม่ QA ที่ดีจะถามคำถามอย่าง "feature นี้จะรู้ได้ยังไงว่าทำงานถูกใน production" หรือ "ถ้า third-party service ที่ feature นี้พึ่งพาล่ม ระบบควร behave ยังไง" ซึ่งคำถามเหล่านี้มักทำให้ ทีมออกแบบ feature ที่มี observability (log/metric ที่เพียงพอ) และ graceful degradation (ไม่ล่มทั้งระบบเมื่อ dependency ล่ม) ตั้งแต่ต้น แทนที่จะมาคิดเพิ่มทีหลังหลังเจอปัญหาจริงใน production
Code Review / Test Plan Review Checklist
เช็คลิสต์ที่ใช้รีวิว test plan หรือ PR ที่มีเทสต์แนบมาด้วย ก่อนอนุมัติ
- Test level ถูกเลือกเหมาะสม (ไม่ใส่ unit test logic ไปทดสอบซ้ำที่ E2E — ดู Automation Pyramid)
- ครอบคลุม happy path + negative case + boundary value (ดู Test Design Techniques)
- Priority การทดสอบสอดคล้องกับความเสี่ยงจริงของฟีเจอร์ (risk-based)
- API test เช็ค status code ให้ตรงความหมาย ไม่ใช่เช็คแค่ 2xx/ไม่ 2xx (ดู API Testing)
- E2E test ใช้ locator ที่ทนทาน (role/label/
data-testid) ไม่ใช่ CSS selector ที่ผูกกับ DOM structure ลึกๆ - ไม่มี hardcoded test data ที่เสี่ยงชนกันเมื่อรัน parallel
- มีแผนจัดการ flaky test (ไม่ใช่แค่ "ใส่ retry ไว้ก่อน")
- Bug report ที่แนบมา (ถ้ามี) reproduce ได้โดยไม่ต้องถามเพิ่ม
ความร่วมมือระหว่าง QA, Dev, และ PO
QA ที่ทำงานแบบ "silo" (รับงานตอนโค้ดเสร็จแล้วเท่านั้น ไม่คุยกับใครก่อนหน้านั้น) มักเจอปัญหา requirement กำกวมที่ค้นพบช้าเกินไป — แนวทางที่ดีคือทำให้คุณภาพเป็น ความรับผิดชอบร่วม (shared ownership) ไม่ใช่ "หน้าที่ของ QA คนเดียว"
"คุณภาพไม่ใช่ประตูที่ QA เฝ้าอยู่คนเดียวปลายทาง แต่เป็นสิ่งที่ทุกคนช่วยกันสร้างตลอดทาง" — ทีมที่ มองว่า "QA คือคนสุดท้ายที่จะจับบั๊กได้" มักมีคุณภาพแย่กว่าทีมที่มอง QA เป็นส่วนหนึ่งของกระบวนการ ตั้งแต่ต้น
Metric ที่ใช้วัด "สุขภาพ" ของความร่วมมือนี้ได้ดีกว่าการนับจำนวนบั๊กที่ QA เจอ คือ "escape rate" — สัดส่วนของบั๊กที่หลุดไปถึง production เทียบกับบั๊กที่จับได้ก่อนนั้น (ใน dev/staging/ UAT) escape rate ที่สูงขึ้นเรื่อยๆ ทีละ sprint มักบ่งบอกว่า process กำลังมีช่องโหว่ที่ลึกกว่า "QA ทำงานไม่ละเอียด" เช่น requirement ไม่ชัดตั้งแต่ต้น, environment staging ไม่ตรงกับ production จริง (เช่น data volume น้อยกว่ามากจนไม่เจอ performance bug), หรือทีมเร่ง release จนข้าม regression suite บางส่วน — การ track escape rate แยกตามสาเหตุ (root cause category) ทำให้ทีมแก้ปัญหาที่ ต้นเหตุของกระบวนการ ไม่ใช่โทษ QA ว่า "ตรวจไม่ละเอียดพอ" ซึ่งมักไม่ใช่สาเหตุจริง
Shift-left testing moves QA involvement earlier — reviewing requirements and design, asking questions about observability and graceful degradation before code exists — rather than treating QA as a post-development gate. A solid test-plan review checklist spans correct test-level choice, happy/negative/boundary coverage, risk-aligned priority, precise API status-code checks, resilient locators, parallel-safe test data, a real flaky-test plan, and reproducible bug reports. Quality should be shared ownership across QA, dev, and PO rather than QA's sole job; tracking escape rate (bugs reaching production vs. caught earlier), broken down by root cause, reveals process gaps — like unclear requirements or unrepresentative staging environments — that simply blaming QA for insufficient thoroughness would miss.