การทดสอบการยอมรับ

"ทำงานได้" กับ "ใช้งานได้จริง" คือคนละเรื่องกัน

ในขณะที่ unit test และ functional test ทำหน้าที่ตรวจสอบว่า "โค้ดทำงานได้ถูกต้องหรือไม่" แต่ acceptance test นั้นตรวจสอบว่า "ผลลัพธ์ตรงกับสิ่งที่ธุรกิจต้องการหรือไม่" แม้จะไม่มีบัก แต่หากพฤติกรรมของระบบไม่ตรงกับ requirement ก็ไม่สามารถ release ได้

การเขียน acceptance test มักอยู่ในรูปแบบที่ใกล้เคียงกับภาษาธรรมชาติ เช่น "เมื่อ admin ล็อกอินแล้วเปิดรายชื่อพนักงาน ระบบจะแสดงเฉพาะพนักงานในเทนแนนต์ของตนเองเท่านั้น" โดยอธิบายพฤติกรรมของผู้ใช้และผลลัพธ์ที่คาดหวังในรูปแบบ scenario ไวยากรณ์ Gherkin (Given-When-Then) คือรูปแบบที่เป็นตัวแทนของแนวทางนี้

ระดับของการทำ Automation

acceptance test บางส่วนดำเนินการด้วยมือ ในขณะที่บางกรณีก็ทำ automation ด้วยเครื่องมืออย่าง Playwright ใน ATDD (Acceptance Test-Driven Development) นั้น จะกำหนด acceptance criteria ไว้ก่อน จากนั้นจึง implement เป็น automated test แล้วค่อยเริ่มพัฒนา เนื่องจากการพึ่งพา manual test มักทำให้ความถี่ในการรันลดลง การทำ automation สำหรับ scenario ที่มีความสำคัญสูงจึงกลายเป็นแนวปฏิบัติมาตรฐานในการทำงานจริง

ความสัมพันธ์กับ Sprint Review

ในการพัฒนาแบบ Scrum มักมีการตรวจสอบผลลัพธ์ของ acceptance test ใน sprint review เนื่องจากผลลัพธ์เหล่านี้เป็นข้อมูลสำคัญที่ Product Owner ใช้ตัดสินใจว่า "ฟีเจอร์นี้ยอมรับได้หรือไม่" จึงเป็นสิ่งที่ดีที่สุดหากทีมสามารถตกลงกันเรื่อง test scenario ได้ตั้งแต่ช่วง sprint planning