อ่าน Requirement ด้วยสายตาของนักทดสอบ

ไม่ได้อ่านแค่ว่า "ต้องทำอะไร" แต่ต้องอ่านว่า "อะไรอาจพังได้บ้าง"

เวลา PM, BA, developer และ QA อ่าน requirement เดียวกัน คนแต่ละบทบาทมักโฟกัสไม่เหมือนกัน:

QA ไม่ได้อ่านเพื่อต้านทีม หรือเพื่อจับผิดคนเขียน requirement แต่กำลังช่วยทีมตอบคำถามสำคัญข้อหนึ่ง:

ถ้าคำตอบคือ "อาจไม่" requirement นั้นยังไม่พร้อมพอ และยิ่งรีบเริ่มทำ โอกาสเกิด defect ก็ยิ่งสูง

ตัวอย่างสั้น ๆ

Requirement:

หลายคนอาจพอเข้าใจภาพรวมแล้ว แต่ในมุม QA ประโยคนี้ยังมีคำถามอีกเยอะ:

• "ผู้ใช้" หมายถึง user ที่ login อยู่แล้วเท่านั้น หรือรวมคนที่ลืมรหัสผ่านด้วย?
• "เปลี่ยน" ทำจากหน้า profile หรือผ่านลิงก์ reset ทางอีเมล?
• "ปลอดภัย" หมายถึงอะไรบ้าง: ต้องกรอกรหัสเดิม, มี OTP, ล็อก session อื่น, บังคับความยาวขั้นต่ำ, จำกัดจำนวนครั้ง?
• ถ้าเปลี่ยนสำเร็จแล้ว session เดิมยังใช้ต่อได้ไหม?
• ถ้าใส่รหัสเดิมผิด 5 ครั้งจะเกิดอะไรขึ้น?

นี่คือหัวใจของบทนี้: requirement ที่ "ฟังดูเข้าใจ" อาจยัง "ทดสอบไม่ได้"

ใช้กรอบคิด 6 ช่องก่อนเสมอ

เวลาคุณเจอ requirement ใหม่ ลองอย่ารีบคิด test case ทันที ให้แยก requirement เป็น 6 ช่องนี้ก่อน:

กรอบนี้ช่วยมาก เพราะ requirement หลายอันมีแค่ actor กับ action แต่ขาด rule, outcome หรือ exception ไปเกือบหมด

ถ้ายังหาช่องไหนไม่เจอ นั่นคือสัญญาณ

ตัวอย่าง:

อ่านรอบแรกอาจรู้สึกว่าโอเค แต่พอแยก 6 ช่องจะเริ่มเห็นช่องว่าง:

• Actor: ลูกค้า
• Action: ใส่คูปอง
• Data: รหัสคูปอง
• Rule: ยังไม่ชัด เช่น คูปองใช้ได้กับสินค้าประเภทไหน, ใช้ซ้ำได้ไหม, ใช้ร่วมกับโปรอื่นได้ไหม
• Outcome: หักส่วนลดจากยอดรวม
• Exception: ยังไม่ชัด เช่น คูปองหมดอายุ, ใช้เกินสิทธิ์, ไม่เข้าเงื่อนไขขั้นต่ำ

ถ้าช่อง Rule กับ Exception ยังเบลอ นั่นคือจุดที่ QA ควรถามต่อ ไม่ใช่เดาแทนทีม

อ่าน requirement ให้ครบทั้งความชัด ความหาย ขอบ และสิ่งที่คนเขียนเผลอสมมติ

เวลาจะหา defect ตั้งแต่ requirement ให้มองอย่างน้อย 4 มุมนี้

วิธีจำแบบสั้น

• Ambiguity = เขียนแล้วแปลได้หลายแบบ
• Missing details = เรื่องสำคัญยังไม่ถูกเขียน
• Edge cases = เรื่องที่ไม่ใช่ happy path
• Assumptions = เรื่องที่ "น่าจะใช่" แต่ยังไม่เคยยืนยัน

ถ้าคุณใช้ 4 มุมนี้จนเป็นนิสัย requirement แทบทุกใบจะเริ่มมีคำถามผุดขึ้นมาเอง

เจอคำพวกนี้เมื่อไร ให้หยุดแล้วถามต่อ

คำบางคำไม่ได้ผิด แต่ถ้าไม่มีบริบทเพิ่ม มันทำให้ dev, QA และ stakeholder จินตนาการคนละแบบได้ง่ายมาก

จาก requirement ที่คลุมเครือ ไปสู่ requirement ที่ทดสอบได้

ดูตัวอย่างนี้:

ในสภาพนี้ QA เทสต์ไม่ได้ เพราะไม่มีเส้นแบ่งว่าช้าเท่าไรถึงถือว่าผิด แต่ถ้าปรับเป็น:

ประโยคหลังเริ่มทดสอบได้ เพราะมี:

• จุดเริ่มต้น: หลัง login สำเร็จ
• สิ่งที่ต้องเห็น: ข้อมูลหลักครบ
• เวลา: ภายใน 3 วินาที
• บริบท: ผู้ใช้ทั่วไปบนเครือข่ายมาตรฐาน

QA ไม่จำเป็นต้องเป็นคน rewrite requirement เองทุกครั้ง แต่ควรรู้ว่าต้องถามอะไรเพื่อทำให้ requirement ชัดขึ้นจนเทสต์ได้

อ่าน user story หนึ่งใบ แล้วค่อย ๆ ขุดให้เห็นสิ่งที่ซ่อนอยู่

ลองดูตัวอย่างนี้

รอบที่ 1: อ่านเพื่อเข้าใจภาพรวม

สิ่งที่เรา "พอรู้" คือ:

• ผู้ใช้สมัครด้วย email
• สมัครสำเร็จแล้วมีอีเมลยืนยัน
• เป้าหมายคือเข้าใช้ feature premium

แค่นี้พอให้เริ่มคุยได้ แต่ยังไม่พอให้พัฒนาและทดสอบอย่างมั่นใจ

รอบที่ 2: แยก 6 ช่อง

รอบที่ 3: ใส่สายตา 4 แบบ

Ambiguity

• "สมัครสำเร็จ" หมายถึง submit ผ่าน หรือหมายถึง verify email ผ่านแล้ว?
• "เร็วที่สุด" คือทันที, ภายใน 5 นาที, หรือภายใน SLA ที่กำหนด?

Missing details

• password policy คืออะไร?
• verification link หมดอายุเมื่อไร?
• ถ้าไม่กดลิงก์ยืนยันในเวลาที่กำหนด บัญชีจะถูกลบไหม?

Edge cases

• สมัครด้วย email เดิมซ้ำ
• กรอก email ที่มีช่องว่างต้น/ท้าย
• ใช้ plus addressing เช่น [email protected]
• กดปุ่มสมัครซ้ำสองครั้งเพราะเน็ตค้าง
• email service ล่มตอนสมัครสำเร็จ

Assumptions

• ทุกคนมี email ที่รับข้อความได้
• ผู้ใช้ยอมรอ email ยืนยัน
• ภาษาในอีเมลเหมาะกับผู้ใช้ทุกประเทศ

รอบที่ 4: แปลงเป็น clarification questions

คำถามที่ดีไม่ใช่คำถามกว้าง ๆ แบบ "ตรงนี้โอเคไหม?" แต่เป็นคำถามที่บังคับให้ทีมตัดสินใจ

ตัวอย่าง:

1. Account จะถือว่า active ตั้งแต่ตอน submit ฟอร์ม หรือหลังจากกดยืนยันอีเมล?
2. ถ้า email ยืนยันส่งไม่สำเร็จ ระบบจะ rollback การสร้าง account หรือสร้างไว้ก่อนแล้วให้ resend?
3. ผู้ใช้สามารถ login ได้ก่อน verify email หรือไม่?
4. verification link มีอายุเท่าไร และหมดอายุแล้วทำอะไรต่อได้?
5. email เดิมที่เคยสมัครแต่ยังไม่ verify สามารถสมัครซ้ำได้หรือไม่?
6. ถ้ากดปุ่มสมัครซ้ำเพราะเน็ตช้า ระบบต้องกัน duplicate account อย่างไร?
7. password ต้องมีความยาวขั้นต่ำและความซับซ้อนระดับไหน?

แค่ story เดียว เราก็เห็นได้แล้วว่า requirement analysis ที่ดีช่วยลด defect ได้ตั้งแต่ก่อนเขียนโค้ด

requirement พังได้มากกว่าที่คิด และพังคนละแบบในแต่ละโดเมน

เพื่อให้เห็นภาพกว้าง ลองดูตัวอย่าง requirement สั้น ๆ หลายแบบ แล้วสังเกตว่าคำถามของ QA จะต่างกันตามบริบท

ตัวอย่าง A: Checkout

สิ่งที่ QA ควรถาม:

• คูปองใช้กับสินค้าทุกประเภทหรือเฉพาะบางหมวด?
• ใช้ได้กี่ครั้งต่อคน?
• ใช้ร่วมกับโปรโมชันอื่นได้ไหม?
• ถ้ายอดซื้อไม่ถึงขั้นต่ำ ให้แสดงข้อความอะไร?
• ถ้าคูปองหมดอายุระหว่างที่ผู้ใช้เปิดหน้าจอค้างไว้ ระบบจะคำนวณอย่างไร?
• ถ้ากดชำระเงินซ้ำหลังใส่คูปอง จะหักส่วนลดซ้ำหรือไม่?

ตัวอย่าง B: File Upload

สิ่งที่ QA ควรถาม:

• "ขนาดใหญ่" คือสูงสุดกี่ MB?
• รองรับ file type อะไรบ้าง?
• บีบอัดบน client หรือ server?
• หลังบีบอัด คุณภาพไฟล์ต้องเหลือประมาณเท่าไร?
• ถ้าไฟล์เสียหรือ extension ปลอม ระบบจะ reject ยังไง?
• ถ้าอัปโหลดหลายไฟล์พร้อมกัน มีกฎเรื่องจำนวนไฟล์ไหม?

ตัวอย่าง C: Search

สิ่งที่ QA ควรถาม:

• "รวดเร็ว" คือภายในกี่วินาที?
• "แม่นยำ" วัดยังไง: exact match, partial match, typo tolerance?
• ค้นหาด้วยภาษาไทยและอังกฤษได้เหมือนกันไหม?
• ตัวพิมพ์ใหญ่เล็กมีผลไหม?
• ถ้าไม่มีผลลัพธ์ ให้แสดง empty state แบบไหน?
• ถ้ามีสินค้าหมดสต็อก จะยังแสดงในผลค้นหาไหม?

ตัวอย่าง D: Notification

สิ่งที่ QA ควรถาม:

• แจ้งใคร: ลูกค้า, แอดมิน, คลังสินค้า, การเงิน?
• ช่องทางอะไร: email, SMS, push, in-app?
• แจ้งเมื่อไร: ทันที, batch ทุก 5 นาที, หรือเฉพาะบางสถานะ?
• เนื้อหาข้อความต่างกันตามสาเหตุที่ยกเลิกไหม?
• ถ้ายกเลิกโดยระบบอัตโนมัติ ต่างจากยกเลิกโดยแอดมินไหม?

ตัวอย่าง E: Security / Login Lock

สิ่งที่ QA ควรถาม:

• หลายครั้งคือกี่ครั้ง?
• นับภายในช่วงเวลากี่นาที?
• นับต่อ account, ต่อ IP, หรือต่อ device?
• ล็อกนานเท่าไร?
• ผู้ใช้ปลดล็อกเองได้ไหม?
• ถ้าเป็น account ที่ไม่มีอยู่จริง ระบบจะเผยข้อมูลหรือไม่?

สิ่งสำคัญคือ QA ไม่ได้ถามเหมือนเดิมทุกเรื่อง แต่จะถามตาม "ความเสี่ยงของฟีเจอร์นั้น"

ถ้าไม่รู้จะเริ่มถามอะไร ให้เริ่มจากรายการนี้

คุณไม่จำเป็นต้องถามทุกข้อทุกครั้ง แต่ลิสต์นี้ช่วยกันหลุดได้ดีมาก

สูตรง่ายสำหรับตั้ง clarification question

ถ้าจะตั้งคำถามให้ทีมตอบง่าย ลองใช้รูปแบบนี้:

ตัวอย่าง:

• "ถ้าผู้ใช้กด submit ซ้ำสองครั้ง ระบบควรสร้าง order แค่ครั้งเดียวใช่ไหม?"
• "ถ้า email ยืนยันหมดอายุ ผู้ใช้ควรขอส่งลิงก์ใหม่ได้ใช่ไหม?"
• "ถ้าคูปองไม่เข้าเงื่อนไขขั้นต่ำ ระบบควรบอกเหตุผลที่ใช้ไม่ได้ใช่ไหม?"

คำถามแบบนี้ช่วยให้ทีมตอบเป็น decision ได้ทันที ไม่ใช่คุยวนอยู่กับคำว่า "น่าจะ"

ฝึกคิดให้ครบก่อนดูเฉลย

ลองอ่าน requirement ต่อไปนี้ แล้วลองระบุอย่างน้อย 3 อย่าง:

1. คำที่คลุมเครือ

2. รายละเอียดที่หายไป

3. edge case หรือ exception ที่ควรถามเพิ่ม

4. "ผู้ใช้สามารถแก้ไขที่อยู่จัดส่งได้ก่อนคำสั่งซื้อถูกจัดส่ง"

   ดูแนวคิดคำตอบ

   คำที่คลุมเครือ: "ก่อนคำสั่งซื้อถูกจัดส่ง" หมายถึงก่อนสถานะไหนกันแน่? packed, shipped, handed to carrier?

   รายละเอียดที่หายไป: แก้ไขได้ทุก field ไหม? แก้ได้กี่ครั้ง? มีค่าจัดส่งเปลี่ยนตามที่อยู่ใหม่ไหม? ถ้าแก้แล้วต้อง re-approve การชำระเงินหรือไม่?

   Edge cases: ถ้าออเดอร์ถูกแพ็กแล้วแต่ยังไม่อัปเดตสถานะ? ถ้าแก้ไขพร้อมกันจากเว็บและแอดมิน? ถ้าเปลี่ยนจากจังหวัดเดิมไปต่างประเทศ?

5. "ระบบควรแนะนำสินค้าใกล้เคียงให้ผู้ใช้อย่างเหมาะสม"

   ดูแนวคิดคำตอบ

   คำที่คลุมเครือ: "ใกล้เคียง" และ "เหมาะสม"

   รายละเอียดที่หายไป: ใช้เกณฑ์อะไรแนะนำ? หมวดเดียวกัน, ราคาคล้ายกัน, พฤติกรรมผู้ใช้อื่น? แสดงกี่ชิ้น? อยู่หน้าไหนบ้าง?

   Edge cases: ถ้าไม่มีสินค้าที่ใกล้เคียง? ถ้าสินค้าที่แนะนำหมดสต็อก? ถ้าผู้ใช้ใหม่ยังไม่มีประวัติ?

6. "เมื่อชำระเงินสำเร็จ ระบบต้องออกเลข order ให้ทันที"

   ดูแนวคิดคำตอบ

   คำที่คลุมเครือ: "ทันที"

   รายละเอียดที่หายไป: ออกเลข order ก่อนหรือหลัง payment confirmation จาก gateway? รูปแบบเลข order เป็นอย่างไร? ต้อง unique ข้ามช่องทางขายไหม?

   Edge cases: ถ้า payment success แต่ callback จาก gateway มาช้า? ถ้ากดชำระซ้ำ? ถ้าออกเลข order สำเร็จแต่ส่งหน้าผลลัพธ์ไม่สำเร็จ?

7. "ฟอร์มสมัครงานต้องใช้งานง่ายบนมือถือ"

   ดูแนวคิดคำตอบ

   คำที่คลุมเครือ: "ใช้งานง่าย"

   รายละเอียดที่หายไป: รองรับขนาดหน้าจอใดบ้าง? ต้องอัปโหลดไฟล์ resume ได้ไหม? ใช้เวลาเฉลี่ยกรอกไม่เกินเท่าไร? มี auto-save หรือไม่?

   Edge cases: เน็ตหลุดระหว่างกรอกฟอร์ม, แนบไฟล์ใหญ่เกิน, หมุนหน้าจอระหว่างกรอก, ใช้คีย์บอร์ดมือถือแล้วปุ่มสำคัญถูกบัง

8. "ระบบควรป้องกันการสั่งซื้อซ้ำ"

   ดูแนวคิดคำตอบ

   คำที่คลุมเครือ: "สั่งซื้อซ้ำ" หมายถึง order เดิมทุกอย่างเหมือนกัน หรือ submit ซ้ำในธุรกรรมเดียว?

   รายละเอียดที่หายไป: ป้องกันที่ UI, API, หรือทั้งสองจุด? ใช้ idempotency key ไหม? หากคำสั่งซื้อแรกไม่สำเร็จ จะให้ retry อย่างไร?

   Edge cases: ผู้ใช้กด submit ซ้ำเพราะหน้าค้าง, network timeout แต่ backend สร้าง order แล้ว, เปิดหลายแท็บพร้อมกัน