เคยเจอมั้ยคะ ได้ Ticket มาแล้ว Requirement เขียนเอาไว้ว่า
“ระบบต้องทำงานได้ถูกต้อง”
“ระบบต้องคำนวณส่วนลดได้ถูกต้อง”
ถูกต้อง ถูกต้อง ถูกต้อง
BA อาจจะเข้าใจแบบนึง
QA อ่านแล้วตีความไปอีกแบบนึง
Dev ก็ตีความไปคนละแบบ
พอได้ของออกมา ทุกคน “งง” ทำไมไม่มีใครเข้าใจตรงกันเลย
ทั้งๆ ที่ทุกคนทำตาม Requirement ทั้งหมด
เนี่ยแหละค่ะ บางทีสิ่งที่เราคิดว่าทุกคนน่าจะเข้าใจอยู่แล้ว
มันตีความได้ต่างกันหลายแบบ และแต่ละคนก็อาจจะเข้าใจไม่ตรงกัน
Requirement ที่ไม่มี Example มันตีความได้หลายแบบ
.
📌 มาลองดูตัวอย่างว่าทำไมตัวอย่างจริงถึงสำคัญ
Requirement บอกว่า “ระบบต้องคำนวณส่วนลดและ VAT ให้ถูกต้อง”
Dev อาจจะเข้าใจว่า คำนวณ VAT จากยอดสั่งซื้อก่อน แล้วค่อยหักคูปองส่วนลด
(1000 + 0.07*1000) – 50 = 1020 บาท
แต่สิ่งที่ business ต้องการคือ ให้หักส่วนลดก่อน ค่อยบวก VAT
(1000 – 50) + (1000 – 50) * 0.07 = 1016.50 บาท
ส่วน QA ก็ไปคุยกับ Dev แล้วก็เขียน automate ขึ้นมา โดยการเอา logic เดียวกันมาคำนวณ expected result อยู่ใน test script
สรุปได้ expected result 1020 บาท ในระบบก็โชว์ 1020 ผ่าน
พอรันเทสก็ผ่านหมด แต่จริงๆ เป็นบั๊ก
แล้ว automation test ของเราไม่เคยจับได้เลย เพราะดันมีบั๊กตัวเดียวกันอยู่ใน test script ด้วย
นี่แหละค่ะ “ถูกต้อง” ของแต่ละคนมันไม่เหมือนกัน
.
📌 Specification by Example คืออะไร และ จะแก้ปัญหานี้ได้ยังไง
วันนี้จะพามารู้จักคำนี้กันค่ะ อธิบายง่ายๆ คือ ให้ยกตัวอย่างไปเลย จะได้เข้าใจตรงกันทุกคน
แทนที่เราจะเขียนว่า
❌ “ระบบต้องคำนวณส่วนลดและ VAT ให้ถูกต้อง”
ให้เขียนแบบนี้แทน
✅ Given สินค้าราคา 1,000 บาท
✅ And ลูกค้ามีคูปองส่วนลด 50 บาท
✅ When ลูกค้ากรอกคูปองส่วนลดที่มี
✅ Then ยอดรวม = (1000 – 50) + VAT 7% of 950 = 1016.5 บาท
แค่นี้ทุกคนก็เห็นภาพเดียวกันว่า คำว่า “ถูกต้อง” มันคืออะไร
เพราะเรายกตัวอย่างให้ดูจริงๆ โดยการใส่ตัวเลขเข้าไปเลย
พอ scenario เรามีตัวเลขจริงตั้งแต่ต้น
แล้วระบบคำนวณออกมาได้ 1020 บาท เราก็จะรู้ทันทีว่าผิด
Test scenario นี้ก็จะเฟลทันที
.
แล้วลองคิดดูนะคะ ยิ่ง Requirement ที่มันซับซ้อนมากขึ้นกว่านี้
อย่างพวกเรื่อง Report หรือ Accounting ทั้งหลาย ที่มีการดึงข้อมูลมาเยอะๆ มีหลาย component
การมี Example ใส่ลงไปใน Test Scenario เลย จะยิ่งทำให้ทุกคนเห็นภาพตรงกันมากขึ้นค่ะ
✅ Given มี transaction 3 รายการ: 1000 / 2500 / 750 บาท
✅ And VAT = 7%, Fee = 1.5%
✅ When user generates Montly Report
✅ Then report shows Gross = 4250 บาท / VAT = 297.50 บาท / Fee = 63.75 บาท / Net = 3888.75 บาท
เท่านี้ก็ไม่ต้องไปตีความกันเองแล้ว ไม่ว่าจะ Dev, QA, BA หรือจะ user ฝ่ายบัญชีที่ต้องมาทำ UAT
.
เห็นมั้ยคะว่ามันไม่ใช่แค่คำศัพท์หรูๆ แต่มันเป็นหนึ่งวิธีที่ทำให้ทุกคนเห็นภาพตรงกันตั้งแต่ต้น
QA ทั่วไป อาจจะรอได้ Requirement มาแล้วค่อยเขียน Test Case แล้วก็ถาม logic จาก Dev มาเขียน expected result ใน automation test อีกที
แต่ QA ร่างทอง จะมีส่วนร่วมในการเขียน example ร่วมกับทีม เพื่อให้เข้าใจตรงกันตั้งแต่ต้น แล้วมันจะช่วยลดความเข้าใจผิดไปได้ตั้งแต่แรกเลย กลายเป็นเราป้องกันบั๊กที่จะเกิดขึ้นไปแล้ว โดยที่ยังไม่ได้เขียนโค้ดหรือเทสเลยสักข้อ
🙂 นี่แหละค่ะ คือ QA ร่างทอง ที่มีส่วนร่วมในการ Shift-Left อย่างแท้จริง