เทสผ่านฉลุย เขียวทุกเคส ให้ผ่าน พร้อม Release
แต่พอ Deploy ขึ้น Prod เท่านั้นแหละ User ดันเจอบั๊กซะงั้น!!!
เนี่ยแหละชีวิต พี่กิ่งเชื่อว่า QA ทุกคนต้องเคยผ่านเหตุการณ์นี้กันมาบ้างแหละ
บอกเลยว่า มันไม่ได้แปลว่าเราเทสไม่เก่งนะคะ
แต่มันเกิดจากการที่เราอาจจะเผลอเดินตามสิ่งที่เรียกว่า“Happy Path” มากเกินไป
Happy Path คือเส้นทางที่โลกสวยงามที่สุดที่จะเกิดขึ้นได้ค่ะ
User กรอกข้อมูลถูกต้องเป๊ะ กดตามสเต็ป 1-2-3 ไปเรื่อยๆอย่างถูกต้อง
แต่ในโลกความเป็นจริง User มีมากมายหลากหลาย บางทีก็อาจจะทำอะไรที่ “ไม่ปกติ” บ้าง
และบั๊กก็มักจะซ่อนอยู่แถวๆนั้นแหละค่ะ
ไม่ใช่ว่า Happy Path ไม่สำคัญนะคะ มันคือสิ่งที่สำคัญมากๆๆๆๆ และควรจะเทสเป็นลำดับแรก
แต่สิ่งที่นอกเหนือจากนั้นก็สำคัญเช่นกัน และที่สำคัญกว่านั้นคือ เราจะทำยังไง ถึงจะเทสความ “ไม่ปกติ” เหล่านั้นได้ครอบคลุมมากที่สุด โดยไม่เหนื่อยจนเกินไป
วันนี้พี่กิ่งเลยอยากมาแชร์ 2 เทคนิคการทำ Test Case Design ที่จะช่วยให้เราดักจับบั๊กได้ดีขึ้น
ช่วยลดจำนวน Test Case ลง แต่ได้ Coverage ที่ครอบคลุมขึ้นเยอะเลยค่ะ
📦 1. Equivalence Partitioning (EP) – เทคนิค “แบ่งกลุ่มข้อมูล”
หลักการคือ ข้อมูลในกลุ่มเดียวกัน มักจะให้ผลลัพธ์เหมือนกัน
ไม่ต้องเทสทุกตัวให้เสียเวลา!
ตัวอย่าง: ระบบรับสมัครงาน จำกัดอายุ 18-60 ปี
ถ้าเราไม่รู้จักเทคนิคนี้เราจะเทสยังไงคะ
อาจจะสุ่มๆ ตัวเลขขึ้นมา 1, 7, 19, 20, 50, … ไปเรื่อยๆ หรือเทสมันทุกเลขไปเลย
แล้วแบบนั้นเราจะรู้ได้ยังไงว่าเทสเยอะพอหรือยัง และเราจะหยุดเทสได้ตอนไหน
ใครคิดจะทำอย่างนั้น หยุดก่อนนะคะ ให้เราลองมาแบ่งกลุ่มของ Input ดูก่อน
- กลุ่มที่ 1 (น้อยกว่า 18): ระบบต้อง Error
- กลุ่มที่ 2 (18-60): ระบบต้องผ่าน
- กลุ่มที่ 3 (มากกว่า 60): ระบบต้อง Error
แล้วเราก็เลือกตัวแทนมา 1 คนจากแต่ละกลุ่มก็พอค่ะ
อาจจะเป็น 15, 30, 65
แทนที่เราจะเทสเป็น 100 เคส ก็ลดเหลือแค่ 3 เคส ก็ครอบคลุมทุกกลุ่มแล้ว
🚧 2. Boundary Value Analysis (BVA) – เทคนิค “จับผิดค่าขอบ”
ตรงรอยต่อของแต่ละเงื่อนไขนี่แหละค่ะ คือจุดที่เกิดบั๊กบ่อยที่สุด
เพราะเรามักจะสับสนได้ง่าย อย่างเช่น ใช้เครื่องหมาย < กับ <= ไม่ถูกต้อง หรือ เขียนเงื่อนไขไม่ครอบคลุมบางเคส
เพราะฉะนั้นเราก็ควรจะพุ่งไปเทสตรงจุดนั้นก่อนค่ะ
ตัวอย่าง: ใช้เคสอายุ 18-60 ปี เหมือนเดิม
เรามาหาจุดที่เป็น “ค่าขอบ” ของแต่ละเงื่อนไขกันค่ะ
เพราะตัวเลขพวกนั้นจะเป็นจุดที่เปลี่ยนจาก พัง -> ผ่าน หรือ ผ่าน -> พัง
หลังจากได้ค่าขอบแล้ว เราจะเลือก ค่าที่อยู่รอบๆ ตรงนั้นมาเทสอีกอย่างละหนึ่งตัว
อย่างเช่นในเคสนี้ ค่าขอบคือ 18 และ 60
- ขอบล่าง: 17 (ต้อง Error), 18 (ต้องผ่าน), 19 (ต้องผ่าน)
- ขอบบน: 59 (ต้องผ่าน), 60 (ต้องผ่าน), 61 (ต้อง Error)
ถ้าจะเจอบั๊ก ตรงค่าพวกนี้แหละค่ะที่มันจะพัง จากที่จะเทส 100 เคส ก็ลดเหลือ 6 เคส
พอเอาไปรวมกับเรื่อง EP ในข้อแรกที่เราแบ่งกลุ่มมาแล้ว
จะเห็นว่าเราสามารถสร้าง Test Case ที่ครอบคลุมได้แทบจะทั้งหมด โดยที่เทสไม่ถึงสิบข้อ!
QA ร่างทอง จะไม่เทสแบบสุ่มไปเรื่อยนะคะ เราจะเทสอย่างมีหลักการ เราต้องรู้ว่าเทสแค่ไหนถึงจะพอ เทสแค่ไหนถึงจะบอกว่าผ่านหรือไม่ผ่าน
การออกแบบ Test Case ที่ดี จะช่วยประหยัดเวลาให้เราไปโฟกัสกับการทำอย่างอื่น
เช่น Exploratory Testing หรือ Automate ต่อได้อีกเยอะเลย และเรายังสามารถใช้พื้นฐานพวกนี้ใน Automation Test Case ของเราอีกด้วย
📌 สำหรับใครที่อยากปูพื้นฐาน QA ให้แน่นปึ้ก รู้ลึกตั้งแต่วิธีคิดยันเทคนิคการเทสแบบตัวเทพ ที่เอาไปใช้ทำงานได้จริง
รวมทั้งเรื่อง Mindset และ Soft Skill ต่างๆ พี่กิ่งมีสอนแบบเจาะลึกในคลาส Testing the Right Way นะคะ
ใครสนใจสามารถเข้าไปดูรายละเอียด และลงชื่อใน Waitlist ไว้ก่อนได้เลย