การเขียน Test Case แบบ BDD เป็นแบบไหนกันนะ?
หลายๆคนอาจจะเคยคิดว่า Test Case นั้นมีไว้สำหรับ Tester เท่านั้น… จริงๆแล้วไม่ใช่เลยค่ะ Test Case เป็นอีกส่วนหนึ่งที่จะช่วยให้การพัฒนา Feature เป็นไปได้อย่างราบลื่น ตั้งแต่เริ่มมีการพูดคุยเกี่ยวกับ Business ของ Feature ที่ทีมจะเริ่มพัฒนาได้เลยค่ะ แล้วการเขียน Test Case แบบ BDD คืออะไร แล้วจะช่วยในการพัฒนา Feature ได้ยังไงนั้น เรามาเริ่มกันเลยค่ะ
BDD คืออะไร
BDD (Behavior Driven Development) คือ รูปแบบการพัฒนา Software โดยมีการสร้าง Test ก่อนที่จะเริ่ม Coding โดยจะเป็นการเขียน Test Step แบบง่ายๆของ Application ในรูปแบบมุมมองของผู้ใช้งาน
ซึ่ง BDD นั้นมาจากการที่ Dan North ได้มองเห็นถึงปัญหาของการนำ TDD (Test Driven Development) ในการทำงานแบบ Agile ว่ายังมีบางจุดที่ยังมีอาจเข้าใจยากหรือสับสนเวลา Coding ดังนั้น Dan North เลยได้มีการปรับ TDD ให้เข้ากับ Agile เพื่อแก้ไขปัญหาเหล่านี้
- จะต้องเริ่ม Test จากจุดไหน
- สิ่งที่ที่จำเป็นต้อง Test และสิ่งไหนที่ไม่จำเป็นต้อง Test
- จะต้องใช้เวลาเท่าไหร่ในการ Test
- ยากต่อการเข้าใจว่าจุดไหนเป็นสิ่งที่ทำให้ Test Fail
ก่อนที่เราจะไปดูว่า Test Case แบบ BDD หน้าตาเป็นแบบไหนนั้น เรามาทำความเข้าใจเกี่ยวกับ BDD Process กันก่อนค่ะ
- Discovery คือ Product Owner ได้ทำการสร้าง Story หรือ Feature Acceptance Criteria ไว้
- Formulation คือ การที่นำ Story นั้นมาเขียนให้อยู่ในรูปแบบของโครงสร้าง และสามารถนำไปใช้งานในการ Coding หรือ Test ได้โดยจะเป็นรูปแบบของ Given-When-Then
- Automation คือ การที่สามารถนำมาเป็นการทดสอบ Acceptance Test แบบ Automated ได้
จากรูปด้านบน TDD จะเป็นการเขียน Code จาก Function ที่ง่ายที่สุด เพื่อทดสอบว่ามีจุดไหนที่ยังไม่ครอบคลุม จะทำแบบนี้ไปเรื่อยๆจนกว่า Function การทำงานนั้นจะครอบคลุมพร้อมส่งมอบ ส่วน BDD จะเป็นการเขียนข้อกำหนดในเชิง Business เพื่อตรวจสอบการทำงานของระบบว่ามี Feature ส่วนไหนที่ไม่ครอบคลุม เพื่อการส่งมอบ Feature ที่ครบถ้วน
แล้วใครกันนะที่จะใช้ BDD
ทีม Agile เองสามารถใช้งาน BDD ร่วมกันในการพัฒนาระบบได้ ประกอบด้วย
- Business : PO , BA, UI/UX
- Developer : Backend, Frontend, Mobile developer
- Tester : Manual Test, Automation Test
จะเห็นได้ว่า BDD สามารถนำเข้ามาใช้ตั้งแต่การที่ PO เริ่มสร้าง User Story เลยก็ว่าได้ เมื่อเริ่มการพัฒนา ก็สามารถนำ TDD เข้ามามีส่วนเพื่อตรวจสอบการทำงานของ Feature โดยอิงเพิ่มเติมได้จาก BDD เมื่อมีการส่งงานให้ Tester ทดสอบ การที่จะเกิด Test Fail ก็จะมีได้น้อยลง เพราะเสมือนเป็นการ Test Frist ตั้งแต่กระบวนการที่ PO สร้าง User Story แล้วนั่นเอง
Test Case แบบ BDD
จากที่กล่าวไปข้างต้นว่า การเขียน Test Case แบบ BDD นั้นจะมาในรูปแบบของ Given-When-Then ซึ่ง Keywords เหล่านี้คือ Gherkin
Gherkin คือ Special Keywords ที่จะช่วยให้ Steps ใน Test Case นั้นอ่านง่าย เหมือนเราได้อ่านเรื่องเล่าของใครสักคน ซึ่งจะประกอบไปด้วย
- Feature คือ การแสดงรายละเอียดของ Feature ที่ต้องการจะสร้าง Test Case
- Scenario คือ ชื่อของ Test Case ที่เราระบุว่า Test Case นั้นๆจะเป็นการทดสอบเกี่ยวกับอะไร
- Given คือ Prerequisite step ที่ระบุว่าเราจะต้องทำอะไรเพื่อให้มีข้อมูลที่จะพร้อม Test
- When คือ Action step หลักที่จะทดสอบ Scenario นี้
- Then คือ Expected Result ที่คาดว่าจะได้รับ
หากใน Test Case นั้นมีหลาย Step สามารถใช้ And หรือ But มาเขียนต่อจาก Given, When หรือ Then ได้
ตัวอย่างการเขียน Test Case แบบ BDD
วันนี้จะมายกตัวอย่างของ Feature ที่คิดว่าทุกระบบจะมีคือการ Login โดยจะเป็นการ Test Case เพื่อตรวจสอบการ Login แบบ Success กันนะคะ
จากรูปด้านบนนั้นเราจะเห็นว่า การเขียนนั้นค่อนข้างที่จะเข้าใจได้ง่าน และการอ่านเป็นขั้นตอนนั้น เหมือนกับเราได้เห็นจริงๆว่าผู้ใช้งานระบบเราจะมีการ Action ยังไงบ้างนั้นเอง…
การเขียน Test Case แบบ BDD มี 2 แบบคือ
- Imperative Feature คือ “Giving an authoritative command” เป็นการเขียน Manual Test Case ที่มีการเขียน Test Steps แบบละเอียด ทำให้คนที่ยังไม่เคยมีความีความรู้เกี่ยวกับ Business Background ของ Feature นั้นเข้าใจได้ง่าย แต่… ถ้ามีการแก้ไข เปลี่ยนแปลง Feature หรือ UI จะทำให้ต้องมีการแก้ไข Update Test Step ให้เป็นไปตาม Requirement ใหม่อยู่เสมอ
- Declarative Feature คือ “The nature of making a declaration” เป็นการเขียน Test Case ในมุมมองของ Business ซึ่งจะไม่ได้ระบุ Test Step อย่างละเอียด ทำให้ Code หลังบ้านของ Feature นั้นมีความยืดหยุ่นสูง ถ้ามีการเปลี่ยนแปลงแก้ไข Feature ก็จะไม่กระทบกับ Feature Life
ข้อดีของ BDD คือ
- ช่วยให้การทำงาน การสื่อสารนั้นดียิ่งขึ้น เข้าใจได้ตรงกันว่า Feature นั้นทำงานได้อย่างไร
- สามารถส่งมอบคุณภาพของงานนั้นได้ดีและได้บ่อยมากขึ้น
- สามารถหาและแก้ไข Defect ได้ก่อนตั้งแต่การ Planning หรือ Coding
- ลดความผิดพลาดได้มากขึ้น
- ช่วยหลีกเลี่ยงการพัฒนา Feature ที่ไม่ตรงตาม Requirement
แอบมาสปอยก่อนนะคะ ว่า BDD นอกจากที่จะช่วยให้ทุกคนในทีมเข้าใจการทำงานของ Software ได้ตรงกันแล้ว นอกจากนี้ยังช่วยให้ Tester สามารถนำมาเขียน Automate ได้ง่ายขึ้นด้วยนะคะ
สปอยรูปการทำไปเขียน Automate ให้ดูก่อน อิอิ หากมีโอกาส จะกลับมาเขียนให้ทุกๆได้อ่านกันอีกครั้งนะคะ ว่าจะนำมาใช้กับ Automated ได้ยังไงกันนะ ^_^
แหล่งที่มา
- https://cucumber.io/docs/bdd/
- https://dannorth.net/introducing-bdd/
- https://www.pluralsight.com/blog/software-development/tdd-vs-bdd#:~:text=TDD%20is%20a%20development%20practice,BDD%20are%20effectively%20the%20same.
- https://accenture.github.io/bdd-for-all/
