ถ้าไม่เขียน SBE จะเกิดอะไรขึ้น Specification by Example (SBE)

หลายทีมบอกว่า requirement ชัดแล้ว

หลาย planning จบด้วยการพยักหน้าเห็นตรงกัน

และหลาย sprint พัง… โดยที่ไม่มีใครตั้งใจให้มันพัง

ปัญหาเหล่านี้มักไม่ได้เกิดจากโค้ด

แต่เกิดจาก Specification ที่ไม่เคยถูกนิยามให้ชัดตั้งแต่ต้น

บทความนี้จะเล่าให้เห็นว่า Specification by Example (SBE) คืออะไร

ใช้ยังไงในชีวิตจริง

และถ้าเรา “ไม่เขียน SBE” จะเกิดอะไรขึ้นกับทีมบ้าง

gen by prompt aoffy

Specification by Example (SBE) คืออะไร

Specification by Example คือการ

กำหนดสเปกของระบบ ผ่านตัวอย่างที่เป็นรูปธรรม

ตัวอย่างเหล่านั้นไม่ใช่เอกสารประกอบ

ไม่ใช่ test case

แต่คือ ข้อตกลงร่วมกันของทีม ว่า

เมื่อเกิดสถานการณ์นี้ ระบบต้องแสดงพฤติกรรมแบบไหน

ถ้าไม่มี example

แปลว่าสเปกยังไม่ถูกนิยาม

ถ้าไม่เขียน SBE จะเกิดอะไรขึ้น

1. Requirement จะลอย และแต่ละคนเข้าใจไม่เหมือนกัน

สิ่งที่มักเกิดขึ้นใน planning:

• PO อธิบายสิ่งที่อยากได้
• Dev แปลเป็นวิธี implement ในหัว
• QA แปลเป็น test ตามประสบการณ์ของตัวเอง

ทุกคนเข้าใจ “คนละแบบ” แต่คิดว่าเข้าใจตรงกัน

จนกระทั่งของเสร็จ

แล้วคำว่า

“ไม่คิดว่ามันจะเป็นแบบนี้”

เริ่มดังขึ้น

ตัวอย่างจริง: ปุ่ม Submit ที่ทุกคนคิดว่าเหมือนกัน

สิ่งที่คุยกันใน planning

“กด submit แล้วบันทึกข้อมูล”

สิ่งที่เกิดขึ้นจริง

• Dev ทำให้กด submit ได้ตลอด
• QA ทดสอบกรณีกรอกครบแล้วผ่าน
• ลูกค้า UAT แล้วถามว่า
• “ถ้ากรอกไม่ครบ ทำไมมัน submit ได้?”

ไม่มีใครผิด เพราะไม่มีใครเคย define สเปกของเคสนี้

ถ้ามี Specification by Example

Given ผู้ใช้กรอกข้อมูลไม่ครบ
When กดปุ่ม Submit
Then ระบบต้องไม่บันทึกข้อมูล
And แสดงข้อความแจ้งเตือน

ตัวอย่างนี้ไม่ใช่ test แต่มันคือ สเปกของระบบ

2. Automation ผ่าน แต่ระบบพังใน Production

หลายทีมมี automation ที่แข็งแรง

pipeline เขียว

coverage ดูดี

แต่ production ยังพัง

เพราะ automation เทสตามสิ่งที่เขียน

ไม่ใช่ตามสิ่งที่ธุรกิจคาดหวัง

ตัวอย่างจริง: ระบบส่วนลด

Automation ที่มี

• ใส่คูปอง
• ตรวจว่ามีส่วนลด

สิ่งที่ไม่เคยถูก define

• คูปองหมดอายุทำยังไง
• ใช้คูปองซ้อนได้ไหม
• ซื้อหลายชิ้นคิดส่วนลดยังไง

ถ้ามี Specification by Example

Given ลูกค้ามีคูปองส่วนลด 10%
And คูปองหมดอายุ
When ทำการชำระเงิน
Then ระบบต้องไม่หักส่วนลด
And แจ้งว่าคูปองใช้ไม่ได้

Automation จะไม่แค่ผ่าน แต่มันจะปกป้อง Business ได้จริง

3. QA กลายเป็นคนรับผิดชอบความไม่ชัดเจนของทีม

ประโยคที่ QA ได้ยินบ่อย:

“ทำไมไม่เทสเคสนี้?”

แต่พอย้อนกลับไปดู planning

• เคสนี้ไม่เคยถูกพูดถึง
• ไม่มี acceptance criteria
• ไม่มี example

QA เทสตามสิ่งที่ถูกเล่า

ไม่ใช่ตามสิ่งที่อยู่ในหัวใครบางคน

Specification by Example เปลี่ยนบทสนทนา

จากการโทษ

เป็นการถามว่า

“เคสนี้เราเคย define เป็น spec หรือยัง?”

ทำไม SBE ถึงไม่ใช่งานของ QA คนเดียว

Specification by Example ไม่ใช่:

• เอกสาร QA
• งานเพิ่ม
• ceremony ใหม่

แต่มันคือ:

• เครื่องมือ alignment
• เครื่องมือออกแบบระบบ
• ภาษากลางของ PO, Dev และ QA

ถ้า example ยังไม่ชัด

แปลว่าสเปกยังไม่พร้อม

ถ้าเราไม่เขียน Specification by Example

เราไม่ได้ออกแบบ behavior ของระบบ

เราแค่หวังว่าทุกคนจะคิดเหมือนกัน

และในโลกของ software ความหวังแบบนั้น มักจบด้วย rework