BDD ไม่ใช่แค่ Cucumber – การเข้าใจผิดที่อาจทำให้ทีมพัง

ทีมใครใช้ BDD กันอยู่บ้างคะ

ตอนที่พี่กิ่งได้ยินคำว่า BDD ครั้งแรก
มันมาคู่กับคำว่า Cucumber ค่ะ 🥒

แล้วทุกคนก็บอกว่าเราจะเริ่มเขียน Test และ Acceptance Criteria แบบนี้กันนะ
ทุกคนก็ไปเริ่มทำตาม รวมทั้งพี่กิ่งด้วย ทั้งที่ตอนนั้นยังไม่รู้เลยว่า BDD คืออะไร
รู้แค่ว่า Cucumber มันเขียน Given-When-Then แล้วเราก็เริ่ม ทำ BDD กัน

จนผ่านมาซักพักนั่นแหละค่ะถึงได้รู้ว่าเราไม่ได้เข้าใจอะไรมันจริงๆ เลยสักนิด 😅

.

🤔 Cucumber ≠ BDD

นี่คือความเข้าใจผิดที่เจอบ่อยที่สุดในวงการ QA เลยค่ะ

BDD ไม่ใช่ Cucumber
BDD ไม่ใช่ Gherkin
BDD ไม่ใช่ Given-When-Then

ไม่ใช่อะไรซักอย่าง แล้วมันคืออะไรกันแน่

จริงๆ แล้วทุกอย่างที่พูดไปมันคือคนละเรื่องกันเลยค่ะ

.

💡 BDD คือ วิธีคิดและวิธีทำงานของทีม

Behavior-Driven Development เป็น practice ที่ให้ทุกคน (Business + Dev + QA) มาตกลง behavior ของระบบร่วมกัน และทำความเข้าใจตรงกันให้ชัดเจนที่สุด ในทุกๆกระบวนการพัฒนาซอฟท์แวร์ ตั้งแต่ก่อนจะเริ่ม code จนไปถึงตอน test

💡 Gherkin คือ ภาษา

ให้มองว่า Gherkin เป็นภาษาที่ใช้ในการเขียน behavior scenarios ที่มี syntax คือ Given / When / Then ก็ได้ค่ะ
แทนที่เราจะเขียน code เราก็มาเขียนในรูปแบบที่เป็นภาษาคนธรรมดา แค่มี structure มากขึ้นนิดนึง

💡 Cucumber คือ tool

Cucumber คือเครื่องมือชิ้นนึงที่ใช้อ่าน feature file และมีความสามารถในการทำความเข้าใจภาษา Gherkin และ run automation test ได้

BDD (วิธีคิด) -> Gherkin (ภาษา) -> Cucumber (tool)

ถ้ามองแบบนี้ Cucumber เป็นแค่ปลายทาง ไม่ใช่ตัว BDD เอง

.

❌ แล้วทีมจะพังได้ยังไงถ้าเข้าใจผิด

ลองคิดดูว่าถ้าเราบอกจะทำ BDD แล้วก็โดดไปเขียน Cucumber เลย

สมมติว่าเรากำลังทำแอพช็อปปิ้ง

QA เขียน feature file คนเดียว
Dev Implement เสร็จ เทสผ่านหมด

แต่พอ deploy ขึ้นไปจริงๆ
ปรากฏว่าพอลูกค้าสั่งของเสร็จ ไม่มีอีเมลยืนยันส่งไป

เป็น Bug มั้ยคะ? เป็นแน่นอน
แต่มีเทสข้อไหนเฟลมั้ย… ไม่มีเลย ผ่านหมด!
เพราะเราไม่ได้คุยกันเรื่องนี้ให้ชัดเจนตั้งแต่แรก

Requirement อาจจะเขียนว่า “สั่งสำเร็จ”

เราคิดว่า มี Order ID ถูกต้อง ก็สำเร็จแล้ว
แต่ Business บอกว่า “สั่งสำเร็จ” หมายถึง ได้รับอีเมลยืนยันออเดอร์ด้วย

เพราะเรานิยามคำว่า “สั่งสำเร็จ” ไม่ตรงกันตั้งแต่แรก
แล้วเราก็ได้ feature file ที่รันผ่านหมด แต่หาบั๊กจริงไม่ได้เลย

นี่แหละค่ะ สิ่งที่อาจจะพังได้ ถ้าเราไม่ได้เริ่มจาก BDD ที่แท้จริง

.

✅ แล้ว BDD ที่แท้จริง ช่วยได้ยังไง?

ลืมเรื่อง syntax ไปก่อนนะคะ
ลองมาดูกันก่อนว่าเราทำ BDD ไปเพื่ออะไร

🎯 1. ทำให้ objective ของแต่ละ test ชัดเจน

เวลาเขียน scenario ที่มาจาก behavior จริงๆ ที่ทีมคุยกันมาชัดเจนแล้ว
แต่ละ test จะมีเหตุผลว่าทำไมต้องมีมันอยู่

ไม่ใช่แค่ “test ที่มีเพราะต้อง test)

Average QA: เขียน test case เยอะ แต่ตอบไม่ได้ว่า test นี้กำลังป้องกันปัญหาอะไร
QA ร่างทอง: เขียน scenario ที่ทุกคนรู้ว่าสำคัญยังไงกับ business

🫂 2. ลดความเข้าใจผิดระหว่าง Dev-QA-Business

เคยเจอกันมั้ยคะ requirement ที่ QA เข้าใจแบบนึง Dev เข้าใจอีกแบบนึง
แต่จริงๆแล้ว Business หมายความว่าอีกแบบ

BDD จะช่วยแก้ปัญหานี้ได้ตั้งแต่ต้น
เพราะทุกคนจะต้องตกลง behavior ร่วมกันก่อนตั้งแต่แรก

🚀 3. ต่อยอดไป automation ที่มีคุณค่าต่อทีมจริงๆ

Scenario ที่ดี ที่มาจาก BDD ที่แท้จริง จะกลายไปเป็น Automation Test ที่ดี และ เทสสิ่งที่สำคัญจริงๆ
ไม่ใช่แค่ script ที่รันผ่านทุกวัน แต่ไม่ได้ป้องกันปัญหาอะไรได้จริง

ถ้าเคยเจอ automation test suite ที่รันผ่านทั้งหมด แต่ยังเจอบั๊กหลุด
นี่แหละค่ะปัญหาที่มาจาก scenario ที่ไม่ได้มาจาก BDD จริงๆ

🎯 Test รันอยู่ทุกวัน แต่ไม่ได้เช็คสิ่งที่ Business ต้องการเลย

.

BDD ไม่ใช่ tool ไม่ใช่ syntax ไม่ใช่ cucumber
แต่มันคือ วิธีที่ทีมคุยกัน เพื่อให้ทุกคนเข้าใจตรงกันว่า software ของเราควรจะมี behavior ยังไง

นี่แหละค่ะ คือสิ่งที่ทำให้ BDD มีคุณค่าจริงๆ
ไม่ใช่แค่ feature file ที่สวยงามอย่างเดียว
แต่มันคือสิ่งที่เราพูดคุยกันก่อนจะเขียน feature file นั้น

.

ไว้เราจะมาดูกันต่อว่า Gherkin ที่ดี กับ ไม่ดี ต่างกันยังไง
แล้วมันเกี่ยวกับ behavior ยังไงได้บ้าง

รอติดตามกันได้นะคะ