Test Artifact ไหนที่เหมาะกับสถานการณ์?
Test plan, test scenario, test case, checklist ไม่ได้เป็นเอกสารคนละชื่อเฉย ๆ แต่เป็นเครื่องมือที่ตอบคำถามคนละระดับ การเลือกใช้ให้ถูกช่วยให้ทีมสื่อสารพอดี: ไม่เบาเกินจนคนเดาเอง และไม่หนักเกินจนไม่มีใครอ่าน
จบบทนี้แล้วคุณจะ...
- อธิบายบทบาทของ test plan, scenario, case และ checklist ได้แบบไม่สับสน
- เลือก artifact ที่เหมาะกับระดับความเสี่ยง คนอ่าน และเป้าหมายของงานได้
- เห็นว่าปัญหาไม่ได้อยู่ที่ "ต้องเขียนเยอะไหม" แต่คือ "เขียนพอดีกับงานไหม"
- มองออกว่าเอกสารแบบไหนช่วยทีมจริง และแบบไหนเป็นภาระโดยไม่สร้างค่า
- เตรียมพร้อมสำหรับบทถัดไปที่เราจะลงมือเขียน scenario และ checklist จริง
คุณกำลังเขียนเพื่ออะไร และเขียนให้ใคร
หลายครั้งทีมเสียเวลาเขียนเอกสารเพราะเริ่มจากคำถามผิด เช่น:
- "ปกติทีม QA ต้องเขียนอะไรบ้าง?"
- "Manager อยากได้เอกสารอะไร?"
- "เครื่องมือมี template อะไรให้กรอก?"
คำถามที่ถูกกว่าคือ:
- เรากำลังพยายามแก้ปัญหาอะไร?
- ใครจะใช้เอกสารชิ้นนี้?
- เขาต้องรู้ละเอียดแค่ไหนถึงจะทำงานต่อได้?
- งานนี้เสี่ยงสูงแค่ไหน?
ถ้าคุณตอบ 4 ข้อนี้ได้ การเลือก artifact จะง่ายขึ้นมาก
ตัวอย่าง
สถานการณ์ A:
"ต้องสื่อสารกับ 4 ทีมว่า release นี้จะทดสอบอะไรบ้าง อะไรไม่ทดสอบ และมีความเสี่ยงอะไร"
เอกสารที่เหมาะน่าจะเป็น test plan เพราะต้องสื่อสารภาพรวม
สถานการณ์ B:
"QA คนใหม่ต้องเทสต์ payment flow ก่อนขึ้น production"
เอกสารที่เหมาะน่าจะเป็น test case แบบละเอียด
สถานการณ์ C:
"ทุกเช้าต้องเช็กเร็ว ๆ ว่าระบบยังใช้งานได้หลัง deploy"
เอกสารที่เหมาะน่าจะเป็น checklist
artifact ที่ดีจึงไม่ได้วัดจากความสวยหรือความครบในเชิงพิธีกรรม แต่วัดจากว่า ช่วยให้คนทำงานต่อได้จริงหรือไม่
แต่ละอันตอบคำถามคนละระดับ
| Artifact | ตอบคำถามหลัก | ระดับความละเอียด | ใครมักใช้ |
|---|---|---|---|
| Test Plan | "เราจะทดสอบอะไร อย่างไร เมื่อไร และมีความเสี่ยงอะไร?" | ภาพรวมเชิงกลยุทธ์ | QA lead, PM, manager, stakeholder |
| Test Scenario | "ผู้ใช้หรือระบบจะผ่าน flow อะไรบ้าง?" | ระดับ use case / flow | QA, BA, dev |
| Test Case | "ต้องทำทีละขั้นอย่างไร และคาดหวังอะไรในแต่ละขั้น?" | ละเอียดระดับ step | QA ที่ execute, auditor, คนใหม่ในทีม |
| Checklist | "มีอะไรที่ต้องเช็กให้ครบอย่างรวดเร็ว?" | เบาและสั้น | QA, dev, support, release owner |
เปรียบเทียบให้เห็นภาพ
- Test Plan เหมือนแผนการเดินทางทั้งทริป
- Test Scenario เหมือนรายการสถานที่ที่ต้องไป
- Test Case เหมือนเส้นทางทีละก้าวพร้อมจุดสังเกต
- Checklist เหมือนรายการของที่ต้องเช็กก่อนออกจากบ้าน
ไม่มีอันไหน "ดีกว่า" กันในทุกสถานการณ์ มีแค่ว่า เหมาะกว่า หรือ ไม่เหมาะ
เมื่อทีมต้องการ "ภาพรวมการทดสอบ" ไม่ใช่รายละเอียดการกดปุ่ม
Test plan มีไว้ตอบเรื่องเชิงกลยุทธ์ เช่น:
- scope อะไรอยู่ใน/นอกการทดสอบ
- test approach ของแต่ละระดับ
- environment และ data ที่ต้องใช้
- resource, owner, timeline
- risk และ assumption สำคัญ
ตัวอย่างหัวข้อใน test plan
| หัวข้อ | ตัวอย่าง |
|---|---|
| Scope | ทดสอบ checkout, coupon, payment callback |
| Out of Scope | ระบบ recommendation และ wishlist |
| Approach | unit โดย dev, integration โดย dev+QA, regression โดย QA |
| Environment | staging + payment sandbox |
| Test Data | test card, mock order, user หลาย role |
| Major Risks | third-party gateway ไม่เสถียร, callback ดีเลย์, test data ไม่ครบ |
| Entry / Exit | build ผ่าน smoke ก่อนเริ่ม, critical defect ต้องปิดก่อน release |
เมื่อไรควรใช้ Test Plan
- โปรเจกต์ใหม่
- release ใหญ่ที่มีหลายทีมเกี่ยวข้อง
- งานที่มี stakeholder ต้องการเห็น risk และ scope
- งานที่การสื่อสารผิด 1 ครั้งอาจทำให้เสียเวลาทั้ง sprint
เมื่อไรไม่จำเป็นต้องเขียนยาว
ถ้าเป็น change เล็ก ๆ ใน sprint เดียว บางครั้ง test plan อาจเหลือแค่:
- scope 3 บรรทัด
- risk หลัก 2 ข้อ
- approach สั้น ๆ
สาระสำคัญคือ ความชัดของกลยุทธ์ ไม่ใช่จำนวนหน้า
ทั้งสามอย่างมักอยู่ใกล้กัน แต่ไม่ควรแทนกันแบบมั่ว ๆ
Test Scenario
ใช้เมื่อคุณต้องการมองงานในระดับ flow หรือ business behavior เช่น:
- ผู้ใช้สมัครสมาชิกและยืนยันอีเมลสำเร็จ
- ผู้ใช้เพิ่มสินค้าและ checkout สำเร็จ
- admin อนุมัติคำขอและผู้ใช้ได้รับแจ้งเตือน
Scenario ไม่ควรติดกับ UI มากเกินไป เพราะ UI เปลี่ยนได้ แต่ flow หลักมักยังอยู่
Test Case
ใช้เมื่อคุณต้องการ:
- step ที่รันซ้ำแล้วได้ผลเหมือนเดิม
- ลดความคลาดเคลื่อนระหว่าง tester
- มีหลักฐานสำหรับ audit, UAT, compliance หรือ high-risk flow
ตัวอย่าง flow ที่มักเหมาะกับ test case ละเอียด:
- payment
- permission / access control
- identity verification
- tax / pricing / calculation
Checklist
ใช้เมื่อคุณต้องการ:
- run เร็ว
- coverage เบื้องต้น
- ของที่ใช้ซ้ำบ่อย
- เอกสารที่ dev หรือ support ก็ช่วยใช้ได้
ตัวอย่างที่เหมาะกับ checklist:
- smoke หลัง deploy
- sanity check ก่อน demo
- release verification
- regression บางชุดที่ทีมคุ้นเคยดีแล้ว
ใช้ 4 ปัจจัยนี้ช่วยตัดสิน
| ปัจจัย | ถ้าค่านี้สูง มักโน้มไปทาง |
|---|---|
| Risk สูง | Test case หรือ plan ที่ชัดขึ้น |
| คนอ่านยังไม่มี context | Test case / plan |
| ต้องรันซ้ำบ่อยและเร็ว | Checklist |
| อยากเห็น coverage ระดับ flow | Scenario |
Decision guide แบบง่าย
| สถานการณ์ | Artifact ที่เหมาะ | เพราะอะไร |
|---|---|---|
| โปรเจกต์ใหม่ มีหลายทีม | Test Plan | ต้อง align scope, strategy, risk |
| ฟีเจอร์ payment ให้ QA ใหม่รัน | Test Case | ลดการตีความไม่ตรงกัน |
| ฟีเจอร์ search ที่ทีมคุ้นแล้ว | Scenario + exploratory notes | เน้น flow และการสำรวจ |
| เช็กระบบหลัง deploy | Checklist | เร็วและใช้ซ้ำได้ |
| ฟีเจอร์ที่กำลังจะ automate | Scenario หรือ case ที่ชัด | ช่วยแปลงต่อเป็น automation ได้ |
สูตรจำง่าย
Risk สูง + Context ต่ำ = เขียนละเอียดขึ้น
Risk ต่ำ + Context สูง + ต้องรันเร็ว = เขียนเบาขึ้น
ฟีเจอร์เดียวกัน แต่ artifact ต่างกันเพราะเป้าหมายต่างกัน
สมมติ requirement คือ:
"ผู้ใช้สามารถขอ refund สำหรับ order ที่ชำระเงินแล้วได้ภายใน 7 วัน"
ถ้าเขียนเป็น Test Plan
คุณอาจเขียนเรื่อง:
- scope: refund request, approval, payment reversal
- out of scope: accounting reconciliation
- risk: double refund, late approval, gateway delay
ถ้าเขียนเป็น Test Scenario
- ผู้ใช้ยื่นขอ refund ภายใน 7 วันและสำเร็จ
- ผู้ใช้ยื่นขอ refund หลัง 7 วันและถูกปฏิเสธ
- ผู้ใช้ยื่นขอ refund สำหรับ order ที่ยังไม่ชำระ
- admin อนุมัติ refund แล้วสถานะ order เปลี่ยน
ถ้าเขียนเป็น Test Case
คุณจะลง step เช่น:
- login ด้วย account ลูกค้า
- เปิด order history
- เลือก order ที่ชำระแล้ว
- กดขอ refund
- กรอกเหตุผล
- ส่งคำขอ
- ตรวจว่าระบบแสดงสถานะ
refund requested
ถ้าเขียนเป็น Checklist
- ☐ ลูกค้าขอ refund ได้จาก order ที่ชำระแล้ว
- ☐ ระบบปฏิเสธ order ที่เกิน 7 วัน
- ☐ สถานะ order เปลี่ยนหลังส่งคำขอ
- ☐ admin เห็นคำขอ refund ในหลังบ้าน
นี่คือฟีเจอร์เดียวกัน แต่ artifact ต่างกันเพราะจุดประสงค์ต่างกัน
เขียนหนักเกินความจำเป็น
เช่น เขียน test case 40 step สำหรับ smoke test ที่ต้องรันทุกวัน แบบนี้ทีมจะเริ่มข้ามเอกสารในที่สุด
เขียนเบาเกินไปสำหรับงานเสี่ยงสูง
เช่น ใช้ checklist สั้น ๆ กับ payment reversal ที่ต้องมีหลักฐานชัด แบบนี้เสี่ยงหลุด logic สำคัญ
ใช้ artifact ผิดคนอ่าน
- manager ไม่ต้องการ 80 test cases เพื่อเข้าใจ risk
- tester ใหม่อาจใช้ scenario อย่างเดียวไม่พอ
เขียนเพราะเครื่องมือบังคับ ไม่ใช่เพราะงานต้องใช้
ถ้า template ทำให้คนกรอกไปโดยไม่คิด เอกสารจะยาวแต่ไม่ช่วยทีม
เริ่มจากขั้นต่ำที่พอ แล้วค่อยเพิ่มเมื่อจำเป็น
หลักที่ใช้งานได้จริงมากคือ:
- เริ่มจาก artifact ที่เบาที่สุดซึ่งยังช่วยให้ทีมทำงานต่อได้
- ถ้ายังไม่พอ ค่อยเพิ่มรายละเอียด
- เพิ่มเฉพาะส่วนที่ช่วยลดความเสี่ยงหรือความคลุมเครือจริง
ตัวอย่าง:
- เริ่มจาก scenario สำหรับฟีเจอร์ใหม่
- ถ้าพบว่า payment flow ซับซ้อนมาก ค่อยแตกบาง scenario เป็น test case
- ตอน release วันจริง สรุปบางส่วนเป็น checklist สำหรับ run เร็ว
นี่คือวิธีใช้หลาย artifact ร่วมกันอย่างมีเหตุผล ไม่ใช่เลือกอย่างเดียวทั้งโลก
แบบฝึก: เลือก artifact ให้เหมาะกับสถานการณ์
"QA คนใหม่เพิ่งเข้าทีม และต้องทดสอบ feature payment ก่อน release สัปดาห์หน้า"
ดูคำตอบแนะนำ
เหมาะกับ: Test case ละเอียด
เหตุผล: payment เป็น high-risk flow, tester ใหม่ยังไม่มี context, และทีมต้องการผลลัพธ์ที่รันซ้ำได้สม่ำเสมอ
"ทีมต้องเช็กว่า staging ใช้งานได้ทุกเช้าก่อนเริ่มงาน"
ดูคำตอบแนะนำ
เหมาะกับ: Checklist
เหตุผล: งานนี้ต้องเร็ว, ใช้ซ้ำทุกวัน, และไม่ได้ต้องการ step ละเอียดมาก
"Manager ขอภาพรวมการทดสอบสำหรับโปรเจกต์ใหม่ที่มี stakeholder หลายฝ่าย"
ดูคำตอบแนะนำ
เหมาะกับ: Test Plan
เหตุผล: สิ่งที่ต้องสื่อสารคือ scope, risk, timeline, owner และ approach ไม่ใช่ step ในการกดหน้าจอ
"ทีมต้องคุยกันว่า feature reset password ครอบคลุม flow หลักครบหรือยัง"
ดูคำตอบแนะนำ
เหมาะกับ: Test Scenario
เหตุผล: ทีมกำลังคุยระดับ flow และ coverage ไม่ได้ต้องการ execution detail ในทุกข้อ
"release คืนนี้ต้องมีรายการเช็กสั้น ๆ ให้ dev on-call ช่วย run ได้ด้วย"
ดูคำตอบแนะนำ
เหมาะกับ: Checklist
เหตุผล: คนใช้ไม่ใช่ QA อย่างเดียว, เวลาจำกัด, ต้องอ่านแล้วทำตามได้ทันที
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- ไม่มี artifact ชิ้นไหนเหมาะกับทุกสถานการณ์
- เลือกจาก 4 อย่าง: risk, คนอ่าน, เป้าหมาย, ความถี่ในการใช้งาน
- Test Plan ใช้สื่อสารกลยุทธ์, Scenario ใช้สื่อสาร flow, Case ใช้สื่อสาร execution detail, Checklist ใช้เช็กเร็ว
- เริ่มจากเอกสารที่เบาที่สุดซึ่งยังพอ แล้วค่อยเพิ่มเมื่อจำเป็น
- QA มืออาชีพไม่ได้เขียนเยอะที่สุด แต่เขียน พอดีที่สุดสำหรับทีม