Behavior Driven Development(BDD) คืออะไร

Behavior Driven Development(BDD) เป็นเทคนิคที่ใช้ในการพัฒนาซอฟต์แวร์แบบ Agileโดยเน้นการสร้าง Test Case ขึ้นมาก่อนการ Code คล้าย TDD แต่มีการต่อยอดเพิ่มเติมจาก TDD โดยจะยึด Concept ที่ว่า Test Case นี้ใครๆที่ไม่ใช่โปรแกรมเมอร์เองก็สามารถเข้าใจได้อย่างง่ายดาย เป็นภาษาธรรมชาติหรือภาษาพูดให้มากที่สุด BDD เองยังสามารถแก้ปัญหาในเรื่องของการสื่อสารได้ดีเพราะบทบาทหน้าที่ของคนในทีมก็แตกต่างกัน มุมมองก็อาจจะไม่เหมือนกันเช่น PO BA QA และ Developer เป็นต้น การสร้าง BDD ขึ้นมาสามารถลดช่องว่างการสื่อสารภายในทีมได้เป็นอย่างดี
     ในการพัฒนาซอฟต์แวร์โดยใช้ Agile จะนิยมใช้ User Story ซึ่งเป็นสิ่งที่สามารถใช้บอกความต้องการของลูกค้า(Requirement) และความสามารถของระบบได้ว่าจะต้องทำงานอย่างไร ซึ่งภายใน User Story เองจะมีองค์ประกอบหนึ่งที่สำคัญคือ Acceptance Criteria ที่เอาไว้ใช้อธิบายว่าระบบต้องสามารถทำงานได้แบบไหนถึงจะส่งมอบและตรงตามความต้องการของผู้ใช้งานหรือเป็นเกณฑ์ในการทดสอบว่าหากผ่านเกณฑ์หมดถึงบอกได้ว่างานเสร็จ ในเทคนิคของ BDD นั้นจึงมีแนวความคิดว่าจะเอา Acceptance Criteria มาเขียนเป็น Code ที่อยู่ในรูปแบบที่ทุกคนสามารถเข้าใจได้เพื่อจะใช้เป็น Unit Testing หรือ Automated Test ไปเลย

User Story

     ก่อนอื่นต้องขยายความ User Story ก่อนว่ามีส่วนประกอบอะไรบ้าง User Story เองเป็นการเขียน Requirement อย่างหนึ่งที่จะเป็นการเล่าเรื่องราวว่าผู้ใช้งานต้องการอะไรบ้างโดยมีส่วนประกอบคือ User Story และ Acceptance Criteria 

• User Story นั้นจะเป็นข้อความสั้นๆอ่านแล้วสามารถเข้าใจได้ทันทีว่า Story นั้นต้องการทำอะไรซึ่งจะถูกกำหนดไว้ในรูปแบบ 

          As a.....[role]..... 

          I want.....[feature].....

          so that.....[benefit].....

• Acceptance Criteria ปกติแล้วจะเป็นข้อความระบุเป็นหัวข้อๆ เพื่อกำหนดถึงเงื่อนไขที่ระบบต้องทำงานได้สำเร็จตามความต้องการของลูกค้า

     ในแนวความคิดแบบ BDD นั้นแทนที่จะเขียน Acceptance Criteria เป็นลักษณะของข้อความ ก็เปลี่ยนมาเขียนในรูปแบบ Given-When-Then ซึ่งจะทำให้ Developer เองสามารถนำไปเขียน Unit-test ส่วน Tester เองก็สามารถนำไปสร้าง Automated test ที่อยู่ในรูปแบบของภาษาธรรมชาติหรือภาษาที่เข้าใจได้ง่ายที่สุด

          Given เป็นการกำหนดเงื่อนไขก่อนเริ่มทำงาน (Context)

          When เหตุการณ์ที่เกิดขึ้น (Event)

          Then ผลของเหตุการณ์นั้น (Outcome)

การพัฒนาซอฟต์แวร์ทั่วไป	การพัฒนาซอฟต์แวร์แบบ BDD
1. ลูกค้าบอก Requirement ให้ Product Owner	1. ลูกค้าและProduct Owner พูดถึง Business ที่จะเกิดขึ้น
2. Product Owner เขียน Requirement	2. Product Owner, Developer และ Tester ร่วมเขียน Requirement โดยกำหนดในรูปแบบ Given When Then
3. Developer เริ่มเขียน Code ตาม Requirement ที่กำหนด	3. Developer เริ่มเขียน Code และเขียน Unit test ตาม Scenarios ที่กำหนด
4. Tester เริ่มเขียน Test Case จาก Requirement	4. Tester เริ่ม Test ตาม Scenarios และเขียน Automated tests
5. จัดทำ Document	5. ลดการทำ Document เพราะ BDD อยู่ในภาษาที่เข้าใจอยู่แล้ว

     จากตารางด้านบนจะสังเกตเห็นว่า BDD จะให้ความสำคัญกับทุกคนใน Role การทำงานมาร่วมกำหนด Requirement และเป็น Format ที่ทุกคนสามารถเข้าใจได้ง่ายเพราะหลังจากนั้นทุกคนในทีมถึงแม้จะแตกต่าง Role กันออกไปเช่น Developer, Tester ก็จะใช้ Requirement ใน Format เดียวกันไปทำงานในส่วนของตัวเอง ทำให้เป็นการทำงานที่สร้างความเข้าใจร่วมกันได้เป็นอย่างดี ซึ่งจะแตกต่างจากการพัฒนาซอฟต์แวร์ทั่วไปที่ Product Owner, Developer หรือ Tester แยกกันทำงาน ทำให้เวลาอ่าน Requirement ก็อาจตีความที่แตกต่างกันออกไป

     ปัจจุบัน Cucumber เป็นซอฟต์แวร์ยอดนิยมที่สร้างโดยภาษา Ruby ใช้สำหรับสร้าง Test Script ตามหลักการของ BDD โดยใช้ Syntax การสร้างแบบ Gherkin (Given, When, Then) สามารถทำงานได้ทั้ง Web Application และ API อีกทั้งยังสามารถ Plugin กับภาษา Ruby, Java, Scalr, Groovy เป็นต้น