แตก Requirement ออกเป็นส่วนย่อย
ก่อนจะเทสต์อะไรได้ คุณต้องเข้าใจสิ่งที่จะเทสต์ให้ชัดเสียก่อน — และนั่นเริ่มจากการแตก requirement
จบบทนี้แล้วคุณจะ...
- แตก requirement ขนาดใหญ่ออกเป็น testable conditions ย่อยๆ ได้
- แยกแยะ functional vs non-functional requirements
- ระบุ implicit requirements ที่ไม่ได้เขียนไว้ในเอกสารได้
- อธิบายได้ว่าทำไม requirement decomposition ถึงสำคัญต่องาน QA
Requirement ที่ดูง่ายอาจซ่อนความซับซ้อนไว้มหาศาล
ลองนึกภาพว่าคุณได้รับ requirement แบบนี้จาก PM:
"ระบบต้องให้ผู้ใช้สามารถชำระเงินได้"
ฟังดูง่ายใช่ไหม? แต่ถ้าคุณเริ่มเทสต์จาก requirement นี้เลย คุณจะตกหลุมพรางทันที เพราะมันซ่อนคำถามไว้อีกนับสิบข้อ:
- ชำระเงินด้วยอะไรบ้าง? บัตรเครดิต, บัตรเดบิต, โอนผ่านธนาคาร, PromptPay?
- ต้องรองรับสกุลเงินอะไรบ้าง?
- ถ้าชำระไม่สำเร็จต้องแสดง error อะไร?
- ต้องบันทึก transaction history ไหม?
- มีจำนวนเงินขั้นต่ำหรือสูงสุดไหม?
- ต้องรองรับ partial payment ไหม?
นี่คือเหตุผลที่ QA ต้อง "แตก" requirement ก่อนจะเริ่มออกแบบ test case — เพราะถ้าไม่แตก คุณจะเทสต์ไม่ครบ และบั๊กจะหลุดไปถึง production
สองประเภทที่คุณต้องแยกให้ออก
Functional Requirements คือสิ่งที่ระบบ "ต้องทำ" — พฤติกรรมที่ผู้ใช้เห็นได้โดยตรง:
- ผู้ใช้สามารถเพิ่มสินค้าลงตะกร้าได้
- ระบบส่ง email ยืนยันคำสั่งซื้อหลังชำระเงินสำเร็จ
- ผู้ใช้สามารถค้นหาสินค้าด้วยชื่อได้
Non-Functional Requirements คือ "คุณลักษณะ" ที่ระบบต้องมี — มักเป็นเรื่อง performance, security, usability:
- หน้าค้นหาต้องโหลดภายใน 2 วินาที (Performance)
- รหัสผ่านต้องเข้ารหัสด้วย bcrypt (Security)
- ระบบต้องรองรับผู้ใช้พร้อมกัน 10,000 คน (Scalability)
- ระบบต้องทำงานได้บน Chrome, Firefox, Safari (Compatibility)
| ประเภท | ตอบคำถาม | ตัวอย่าง |
|---|---|---|
| Functional | ระบบทำอะไร? | "ผู้ใช้ลงทะเบียนได้" |
| Non-Functional | ระบบทำได้ดีแค่ไหน? | "ลงทะเบียนเสร็จภายใน 3 วินาที" |
สิ่งที่ QA มักพลาดคือการไม่เทสต์ non-functional requirements เลย — เพราะมันไม่ได้อยู่ใน user story แบบชัดๆ แต่ถ้าระบบช้าหรือไม่ปลอดภัย ลูกค้าก็ไม่ใช้อยู่ดี
สิ่งที่เขียนไว้ vs สิ่งที่ "ทุกคนน่าจะรู้"
Explicit Requirements คือสิ่งที่เขียนไว้ชัดเจนในเอกสาร:
"ผู้ใช้ต้องกรอก email และ password เพื่อลงทะเบียน"
Implicit Requirements คือสิ่งที่ไม่ได้เขียนไว้ แต่ "ถือว่าต้องมี" โดยพฤตินัย:
- email ต้องมีรูปแบบที่ถูกต้อง (มี @ และ domain)
- password ไม่ควรแสดงเป็น plain text
- กด Enter ที่ฟอร์มแล้วต้อง submit ได้
- ข้อความ error ต้องเป็นภาษาที่ผู้ใช้เข้าใจ
- ระบบไม่ควรยอมรับ email ซ้ำ
เรื่องเล่า: ทีมพัฒนาแอปจองตั๋วหนังแห่งหนึ่งเทสต์ functional requirements ผ่านหมด — จองได้ จ่ายเงินได้ ได้ตั๋ว แต่วันเปิดตัว ลูกค้าจองที่นั่งเดียวกันได้พร้อมกัน 2 คน เพราะไม่มีใครเทสต์ implicit requirement เรื่อง concurrency lock ของที่นั่ง เอกสารไม่ได้เขียนว่า "ที่นั่งเดียวกันจองซ้ำไม่ได้" เพราะทุกคนคิดว่า "มันก็ต้องเป็นแบบนั้นอยู่แล้ว"
QA ที่เก่งจะไม่อ่านแค่สิ่งที่เขียนไว้ แต่จะถามว่า "มีอะไรที่ไม่ได้เขียนไว้แต่ต้องมี?"
4 ขั้นตอนที่ใช้ได้กับทุก Requirement
ขั้นตอนที่ 1: อ่านและทำความเข้าใจ (Read & Understand)
- อ่าน requirement ทั้งหมดให้จบก่อน
- ขีดเส้นใต้คำที่คลุมเครือ เช่น "เร็ว", "ง่าย", "ปลอดภัย"
- จดคำถามที่ยังตอบไม่ได้
ขั้นตอนที่ 2: แยกเป็น Features (Break into Features)
- แบ่ง requirement ใหญ่ออกเป็นฟีเจอร์ย่อย
- แต่ละฟีเจอร์ควรเป็นหน่วยที่ทดสอบได้อิสระ
ขั้นตอนที่ 3: ระบุ Testable Conditions
- แต่ละฟีเจอร์ ถามว่า "อะไรบ้างที่ต้องจริง (true) เพื่อให้ฟีเจอร์นี้ทำงานถูกต้อง?"
- นี่คือ testable conditions หรือ test conditions
ขั้นตอนที่ 4: หา Edge Cases และ Negative Scenarios
- ถ้าผู้ใช้ทำสิ่งที่ไม่คาดคิดล่ะ?
- ถ้า input เป็นค่าว่าง? ค่าติดลบ? ค่ามหาศาล?
- ถ้าเน็ตหลุดกลางทาง?
ตัวอย่าง: แตก Requirement ของฟอร์มลงทะเบียน
Requirement: "ผู้ใช้สามารถลงทะเบียนบัญชีใหม่ได้โดยกรอกชื่อ, email, และ password"
| Feature ย่อย | Testable Conditions |
|---|---|
| กรอกชื่อ | - ชื่อต้องไม่ว่าง · ชื่อมีความยาวสูงสุดกี่ตัวอักษร? · รองรับภาษาไทยไหม? · อนุญาตตัวเลขในชื่อไหม? |
| กรอก email | - รูปแบบ email ถูกต้อง · email ไม่ซ้ำกับที่มีในระบบ · case sensitive ไหม? |
| กรอก password | - ต้องยาวอย่างน้อยกี่ตัว? · ต้องมีตัวพิมพ์ใหญ่/เล็ก/ตัวเลข/อักขระพิเศษไหม? · ไม่แสดงเป็น plain text |
| Submit ฟอร์ม | - สำเร็จแล้วไปหน้าไหน? · ส่ง email ยืนยันไหม? · ถ้ากรอกไม่ครบแสดง error อะไร? |
คำถามที่ QA ต้องถามเสมอ
เมื่อคุณได้รับ requirement ใหม่ ให้ถามคำถามเหล่านี้:
- ใคร ใช้ฟีเจอร์นี้? (user roles)
- อะไร คือ happy path? (main flow)
- อะไร จะเกิดขึ้นถ้าล้มเหลว? (error handling)
- ข้อมูล อะไรต้องใช้? (input/output)
- ขอบเขต อยู่ที่ไหน? (boundaries)
- เงื่อนไข อะไรต้องเป็นจริงก่อน? (preconditions)
- หลัง ทำเสร็จแล้วเกิดอะไร? (postconditions)
- ไม่ได้เขียนไว้ แต่ต้องมีอะไรบ้าง? (implicit requirements)
แบบฝึก: แตก Requirement ของ E-Commerce Checkout
สมมติว่าคุณได้รับ requirement นี้:
"ระบบ e-commerce ต้องให้ผู้ใช้สามารถ checkout สินค้าในตะกร้าได้ โดยเลือกที่อยู่จัดส่ง เลือกวิธีชำระเงิน และได้รับหมายเลข order หลัง checkout สำเร็จ"
จงแตก requirement นี้ออกเป็น features ย่อยอย่างน้อย 4 features
ดูคำตอบแนะนำ
Features ย่อย:
- ตะกร้าสินค้า: แสดงรายการสินค้า, จำนวน, ราคา, ราคารวม
- ที่อยู่จัดส่ง: เลือกที่อยู่ที่มี / เพิ่มที่อยู่ใหม่ / แก้ไขที่อยู่
- วิธีชำระเงิน: เลือกช่องทาง (บัตร, โอน, COD) / กรอกข้อมูลการชำระ
- สรุปคำสั่งซื้อ: แสดงรายละเอียดก่อนยืนยัน / ค่าจัดส่ง / ส่วนลด (ถ้ามี)
- ยืนยันคำสั่งซื้อ: สร้าง order / ออกหมายเลข order / ส่ง email/SMS ยืนยัน
จงระบุ non-functional requirements ที่ไม่ได้เขียนไว้แต่ควรมี อย่างน้อย 3 ข้อ
ดูคำตอบแนะนำ
- Performance: หน้า checkout ต้องโหลดภายใน 3 วินาที
- Security: ข้อมูลบัตรเครดิตต้องเข้ารหัส (PCI-DSS compliance)
- Reliability: ถ้าชำระเงินสำเร็จแต่ระบบ error ต้องไม่หักเงินซ้ำ
- Usability: ขั้นตอนไม่ควรเกิน 3-4 หน้า
- Compatibility: ใช้งานได้ทั้งบน desktop และ mobile
จงระบุ implicit requirements ที่ "ทุกคนน่าจะรู้" แต่ไม่ได้เขียนไว้ อย่างน้อย 3 ข้อ
ดูคำตอบแนะนำ
- สินค้าในตะกร้าต้องยังมี stock อยู่ ณ เวลา checkout
- ราคาต้องเป็นราคาล่าสุด (ไม่ใช่ราคาตอนที่เพิ่มลงตะกร้า ถ้ามีการเปลี่ยนแปลง)
- ถ้าผู้ใช้ยังไม่ได้ login ต้อง login ก่อน checkout
- ต้องมีปุ่ม "กลับ" หรือ "แก้ไข" ให้ผู้ใช้แก้ข้อมูลก่อนยืนยันได้
- ต้องแสดง error ที่ชัดเจนเมื่อชำระเงินไม่สำเร็จ
- ไม่ควรสร้าง order ซ้ำถ้ากด submit ซ้ำ (double submit prevention)
สำหรับ feature "วิธีชำระเงิน" จงระบุ testable conditions อย่างน้อย 5 ข้อ
ดูคำตอบแนะนำ
- เลือกชำระด้วยบัตรเครดิต → ระบบแสดงฟอร์มกรอกหมายเลขบัตร, วันหมดอายุ, CVV
- กรอกหมายเลขบัตรไม่ครบ → แสดง error validation
- เลือกชำระด้วยการโอนผ่านธนาคาร → แสดง QR code หรือเลขบัญชี
- ชำระเงินสำเร็จ → ระบบเปลี่ยนสถานะ order เป็น "ชำระแล้ว"
- ชำระเงินไม่สำเร็จ (บัตรถูกปฏิเสธ) → แสดง error และให้ลองใหม่ได้
- เลือก COD → ไม่ต้องกรอกข้อมูลชำระเงิน, order สถานะ "รอชำระ"
- ยอดเงินในบัตรไม่พอ → แสดง error ที่เข้าใจง่าย ไม่เปิดเผยข้อมูลทางการเงิน
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- Requirement ที่ดูง่ายมักซ่อนความซับซ้อน — ต้องแตกก่อนเทสต์
- แยก functional (ระบบทำอะไร) กับ non-functional (ทำได้ดีแค่ไหน) ให้ชัด
- Implicit requirements คือแหล่งบั๊กที่ QA ต้องขุดออกมาเอง
- ใช้เทคนิค 4 ขั้นตอน: อ่าน → แยก features → หา testable conditions → หา edge cases
- QA ที่เก่งจะ ถามคำถามเก่ง มากกว่าเขียน test case เก่ง