ATDD, BDD, SbE มันต่างกันอย่างไร ?

มีคำถามที่น่าสนใจคือ ATDD, BDD และ SbE มันคืออะไร ? เหมือน หรือ แตกต่างกันอย่างไรบ้าง ? มีเป้าหมายเพื่ออะไรบ้าง ? จากนั้นจึงลองไปค้นหาคำตอบ ก็พบว่าเรื่องนี้เขาคุยกันมาตั้งแต่ปี 2010 แล้ว โดยทำการสรุปไว้ในบทความเรื่อง ATDD vs. BDD vs. Specification by Example vs …. จึงทำการแปลและสรุปไว้นิดหน่อย

ATDD ย่อมาจาก Acceptance Test Driven Development BDD ย่อมาจาก Behaviour Driven Development SbE ย่อมาจาก Specification by Examples

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

ทุกคนรู้ว่า Acceptance tests นั้นถูกกำหนดมาจาก ความต้องการของลูกค้า หรือ ทาง business ซึ่งจะเป็นตัวขับเคลื่อนกระบวนการ Test Driven Development (TDD) เพื่อสร้างระบบงานที่ตรงตามความต้องการนั่นเอง แต่คำที่แต่ละคนใช้เรียกต่างกันอย่างมาก เช่น

• Examples
• Scenarios
• Acceptance tests
• Customer tests
• Behaviour
• Business facing tests
• Story tests
• Functional tests
• Acceptance criteria
• Business rules
• Executable specification

รวมทั้งมีคำอธิบายเกี่ยวกับ ATDD เยอะมาก ๆ ซึ่งหนึ่งในนั้นคือคำอธิบายจากคุณ Jennita Andrea ไว้ดังนี้ ATDD เป็นแนวปฏิบัติเพื่อทำให้เราได้ ตัวอย่างที่ชัดเจน ข้อตกลงต่าง ๆ ที่ชัดเจน ความคาดหวังต่าง ๆ ที่ชัดเจน ของแต่ละ function, story หรือ requirement ก่อนเริ่มพัฒนา ซึ่งมันทำให้เกิดกระบวนการทำงานร่วมกันของคนในกลุ่มต่าง ๆ ดังนี้

• การเขียน examples
• การเขียน automated tests ทั้ง unit test และ integration test
• การ run automated test ให้ผ่านทั้งหมด

จนทำให้ function, story หรือ requirement มันเสร็จตามที่ตกลง

ผลจากพูดคุยใน workshop นี้ทำให้คุณ Declan Whelan และ Gojko Adzic และผองเพื่อน

ทำการสรุปขั้นตอนเพื่อสร้างความเข้าใจในเรื่อง Specification by Example (SbE) ขึ้นมาดังรูป

ต่อมาคุณ Dan North ทำการอธิบายเรื่อง Behaviour Driven Development (BDD)

ซึ่งอธิบายในบทความเรื่อง Introducing BDD โดยเน้นไปที่ behaviour หรือพฤติกรรมการทำงาน มากกว่า test หรือการทดสอบ ด้วยการใช้ Given, When, Then เพื่ออธิบายการทำงานต่าง ๆ เช่น

• Precondition
• Action หรือ Trigger
• Post-condition

BDD นั้นมีเป้าหมายเพื่อช่วยให้เราค้นพบสิ่งที่เราไม่รู้ ที่อยู่ในบริบทที่เราสนใจด้วย scenario และ example ต่าง ๆ จึงคำที่ใช้คือ should และ behaviour เนื่องจากคำว่า test มันใช้กับสิ่งที่เรารู้อยู่แล้ว

แต่ไม่ว่าจะเป็น ATDD, BDD, SbE ล้วนมีเป้าหมายและผลเดียวกันคือ

เพื่อแบ่งปันความเข้าใจร่วมกันว่าเรากำลังจะสร้างอะไรตั้งแต่แรก ถึงแม้บางครั้งมันอาจจะไม่ใช่สิ่งที่ถูกต้องก็ตามที แต่อย่างน้อยมันก็ช่วยลดการ rework ซึ่งนั่นคือสิ่งที่ดีกว่า การทำงานแบบต่างคนต่างทำ ต่างคนต่างเข้าใจในแบบของตัวเอง

สิ่งที่น่าสนใจสำหรับ ATDD คือ

เมื่อเราพูดกับลูกค้า หรือ ทาง business แล้ว พบว่าไม่ค่อยเข้าใจเรื่อง Example และ Behaviour เท่าไร แต่เมื่อพูดคำว่า Acceptance tests ของแต่ละ function, story หรือ requirement กลับเข้าใจมากกว่า รวมทั้งยังทำให้ทีมรู้ขอบเขตของการพัฒนาและทดสอบ ซึ่งนั่นคือ เหตุผลสำคัญของการทำ ATDD