ATDD

## ความแตกต่างจาก TDD ในขณะที่ TDD มุ่งขับเคลื่อนการออกแบบโค้ดของนักพัฒนา ATDD มีจุดประสงค์เพื่อให้ทีมทั้งหมดมีความเข้าใจตรงกันในข้อกำหนดทางธุรกิจ เช่นเดียวกับที่ TDD มีวงจร "RED→GREEN→Refactor" ATDD ก็มีวงจรที่ชัดเจนเช่นกัน 1. **Discuss（การอภิปราย）**: Product Owner, นักพัฒนา และ QA ร่วมกันอภิปรายข้อกำหนด และตกลงเกณฑ์การยอมรับด้วยตัวอย่างที่เป็นรูปธรรม 2. **Distill（การกลั่น）**: นำเกณฑ์ที่ตกลงกันไว้มาแปลงเป็นรูปแบบที่มีโครงสร้าง เช่น Given-When-Then 3. **Develop（การพัฒนา）**: ทำให้ Acceptance Test เป็นแบบอัตโนมัติ และเริ่มต้นการพัฒนาจากสถานะที่ Test เป็น RED 4. **Demo（การสาธิต）**: เมื่อ Test เป็น GREEN แล้ว ให้สาธิตแก่ Stakeholder ## Three Amigos（การประชุมสามฝ่าย） แก่นของ ATDD อยู่ที่ "การประชุมสามฝ่าย" ก่อนการพัฒนา การอภิปรายเกณฑ์การยอมรับจากมุมมองของสามฝ่าย ได้แก่ ฝ่ายธุรกิจ นักพัฒนา และผู้ทดสอบ ช่วยขจัดความคลุมเครือของข้อกำหนดและความเข้าใจที่คลาดเคลื่อนได้ตั้งแต่เนิ่นๆ ส่งผลให้ลดการทำงานซ้ำที่เกิดจากความเข้าใจผิด เช่น "ไม่ได้หมายความแบบนั้น" หลังจากเริ่มเขียนโค้ดไปแล้วได้อย่างมีประสิทธิภาพ ## อุปสรรคในการนำไปใช้ เนื่องจาก ATDD ส่งผลกระทบต่อกระบวนการพัฒนาทั้งหมด จึงไม่ใช่สิ่งที่เริ่มต้นได้เพียงแค่นำเครื่องมือมาใช้ ทีมทุกคนจำเป็นต้องคุ้นเคยกับวิธีการเขียนเกณฑ์การยอมรับ และการมีส่วนร่วมอย่างแข็งขันของ Product Owner ก็เป็นสิ่งที่ขาดไม่ได้ แนวทางที่เป็นจริงคือการเริ่มทดลองกับ User Story เพียงหนึ่งรายการก่อน แล้วจึงขยายขอบเขตออกไปหลังจากได้สัมผัสกับประสิทธิผลที่เกิดขึ้น