จงเรียนรู้ทุกอย่างแล้วลืมมันไปซะ!

จาก Test Design Workshop ครั้งที่แล้ว มีคำถามนึงที่คนถามเข้ามาเยอะก็คือ EP BVA ไอ้ตัวย่ออะไรพวกนี้เนี่ย มันคืออะไร ซึ่งวันนั้นพี่กิ่งบอกไว้ว่า ยังไม่ต้องสนใจ เพราะจริงๆแล้วเราไม่ควรเริ่มต้นจากสิ่งนี้ค่ะ 

วันนี้เลยจะอยากมาขยายความเพิ่มเติมให้อีกนิด เผื่อว่าจะช่วยตอบคำถามของหลายๆ คนในวันนั้นได้นะคะ

คิดว่าหลายๆ คนน่าจะเจอปัญหาคล้ายกัน ที่ตอนเรียนเราก็เข้าใจดีอยู่หรอกว่ามันคืออะไร แต่พอเจองานจริง เจอ Requirement จริง ก็ไม่รู้จะเอาไปใช้ยังไง หรือบางคนเริ่มมาก็กางตำรา ใส่เทคนิคเข้าไปรัวๆ เสร็จแล้วก็ไม่มั่นใจอยู่ดีว่า Test Case ครบหรือไม่ครบกันแน่

อย่างที่พี่กิ่งย้ำบ่อยๆ ค่ะ สิ่งที่สำคัญที่สุดคือ “วิธีที่เราเริ่มต้นคิด” ต่างหาก 
ที่จะบอกว่าเราเป็น QA ทั่วไป หรือ เป็น QA ร่างทอง

ถึงตรงนี้ถ้าใครยังไม่รู้จักว่า EP BVA คืออะไร 
สามารถเข้าไปดูในโพสเก่าได้นะคะ ในนี้จะมีอธิบายพื้นฐานเอาไว้

แค่คำว่ารักคงยังไม่พอ แค่ Happy Path ก็อาจจะยังไม่พอเหมือนกัน

เดี๋ยวเรามาลองตัวอย่าง Requirement จริงที่จะเจอได้ทั่วไปกันดีกว่าค่ะ
เราจะมาลองดูกันว่าถ้าเราเริ่มต้นด้วยวิธีคิดที่ต่างกัน จะมีอะไรต่างกันบ้าง

ฟีเจอร์สมัครสมาชิกด้วย Email ต้องกด Verify link ใน email ภายใน 24 ชั่วโมง

❌ แบบที่ 1: QA ที่เริ่มจาก “Technique” ก่อน (QA ทั่วไป)

พอเห็นคำว่า “Email” กับ “24 ชั่วโมง” ปุ๊บ เราก็เริ่มเลย

• ใช้ EP แบ่งกลุ่ม Email: Format ถูก, Format ผิด, etc
• ใช้ BVA กับเวลา 24 ชั่วโมง: กดตอน 23:59:59, 24:00:00, 24:00:01
• ผลลัพธ์: ได้เทสเคสประมาณ 6-7 ข้อ ที่ดู ”เหมือนจะ” ครบ

ถามว่าแบบนี้ผิดมั้ย??? ไม่ผิดนะคะ แต่มันเป็นการเทสแค่ “สิ่งที่เราเห็น” ในรายละเอียด Requirement เท่านั้น ซึ่งมักจะทำให้เราพลาดบั๊กตัวใหญ่ที่ซ่อนอยู่ในระบบ

✅ แบบที่ 2: QA ที่เริ่มจาก “Scenario” (QA ร่างทอง)

ทีนี้ถ้าก่อนจะเริ่มต้นด้วยเทคนิค เราลองถามตัวเองก่อนว่า “User จะทำอะไรกับฟีเจอร์นี้ได้บ้าง” แล้วลองแตก Scenario ออกมาก่อนค่ะ

• Scenario 1: สมัครแล้วกด Verify ทันที

• Scenario 2: สมัครแล้วลืมกด ผ่านไป 1 วันค่อยมาเปิดเมล
  • ตรงนี้มี EP ของ Link ที่ Expire กับ ยังไม่ Expire
  • และใช้ BVA ที่เวลา วินาทีที่ 23:59:59 (ต้องผ่าน) vs 24:00:00, 24:00:01 (ต้องโดนเด้ง)

• Scenario 3: สมัครด้วย Email ซ้ำ
  ตรงนี้จะเป็นจุดที่ QA ร่างทอง จะเริ่มเห็น “State ของข้อมูล” ที่ซ่อนอยู่ค่ะ
  จะเห็นว่าเราสามารถใช้ EP ตรงนี้ได้เหมือนกัน
  • Email ที่ยังไม่เคยมี
  • Email ที่เคยสมัครแล้ว แต่ยังไม่ Verify
  • Email ที่สมัครแล้ว และ Verify แล้ว

ถ้าเราไม่ได้เริ่มจาก Scenario เราอาจจะพลาด Test Case ตรงนี้ไปทั้งหมดเลย เพราะไม่ทันคิดเรื่อง Email ซ้ำ

• Scenario 4: กด Resend Verification Email
  เราจะใช้ BVA ได้กับเวลา 24 ชั่วโมงที่ Link ใหม่ตรงนี้อีกก็ได้
  แต่คำถามที่ควรถามตรงนี้คือ ถ้า Link ใหม่ มีอายุ 24 ชั่วโมงเหมือนเดิม แล้ว Link เก่าล่ะ ต้อง Expire ทันทีมั้ย หรือจะยังใช้ได้คู่กัน ถ้าใช้ได้คู่กัน แล้วกดทั้งคู่ จะเกิดอะไรขึ้น

พอจะเห็นความต่างมั้ยคะ ก็ EP BVA เหมือนกัน
แต่แบบแรก เราอ่าน Requirement จบก็เอาเทคนิคเข้าไปใช้ตรงๆ เลย

ส่วนแบบที่สอง ก็ใช้เทคนิคเดิมนั่นแหละ แต่เราเอาไป Apply กับ User Journey ที่เกิดขึ้นจริงอีกที
ถ้าเราเริ่มจาก Scenario จะทำให้เห็นส่วนที่เป็น State หรือ Boundary ของ Business Logic ได้ดีขึ้น

ถ้าใครอยากอัพเกรดการออกแบบ Test Case ของตัวเอง ลองทำตามนี้ดูได้ค่ะ

1. แตก Scenario ก่อน:
ตอบให้ได้ก่อนว่า User จะใช้ฟีเจอร์นี้เพื่ออะไร จะเข้ามาถึงตรงนี้ได้ยังไงบ้าง และมีเคสไหนที่อาจจะเกิดขึ้นได้บ้าง

2. ใส่ Context ให้ Test: 
อย่าเพิ่งโดดลงไปคิดถึงค่าต่างๆ ให้ลองคิดถึงสถานการณ์ที่เกิดขึ้นได้ก่อน เพื่อให้เห็นภาพรวมของ Business

3. ตบด้วย EP+BVA: 
ได้ Scenario แล้ว ค่อยมาดูว่า เราสามารถใช้เทคนิคเข้าไปจับตรงจุดไหนได้บ้าง เพื่อให้ครบถ้วนมากขึ้น

มาถึงตรงนี้ น่าจะพอมองเห็นกันแล้วว่า เทคนิคต่างๆ จะมีประโยชน์มหาศาล ถ้าเราเอาไปใช้ได้ถูกจุด แต่อาจจะไร้ค่าเลยทันที ถ้าเราเอาไปใช้โดยที่ไม่ได้เข้าใจสิ่งที่กำลังทำอยู่จริงๆ

การเป็น QA ที่เก่ง ไม่ใช่คนที่เขียน Test Case ได้เยอะที่สุด หรือเร็วที่สุด แต่คือคนที่เข้าใจว่า “ความเสี่ยงมีอะไรบ้าง” และ ออกแบบ Test ที่สามารถดักจับมันได้เร็วที่สุด

คราวหน้าก่อนจะเริ่มออกแบบ Test Case ด้วยเทคนิคต่างๆกัน อยากให้ลองคิดก่อนว่าเราได้ลองมองในมุมของ User รึยัง แล้วคุณจะพบว่า Test Case ของคุณจะมีคุณค่าเพิ่มขึ้นเยอะเลยค่ะ