Acceptance​ ​Criteria​ ​คือ​อะไร​ ​และ​ช่วย​ลด​ความ​คลุมเครือ​ของ​ ​Requirement​ ​ได้​อย่างไร

Acceptance Criteria คือเงื่อนไขที่บอกว่างานหนึ่งตอบความต้องการตามที่ตกลงแล้วหรือยัง ช่วยให้คนขอ ทีมออกแบบ ทีมพัฒนา และผู้ทดสอบมีคำตอบร่วมกันว่า “เสร็จ” หมายถึงอะไร เกณฑ์ที่ดีเน้นผลที่ผู้ใช้เห็นหรือระบบต้องรักษา ไม่ใช่สั่งเพียงว่าต้องใช้ปุ่มสีใดหรือเขียนโค้ดแบบไหน

จากคำคลุมเครือสู่สิ่งที่ตรวจได้

Requirement ว่า “ระบบค้นหางานได้เร็ว” ยังมีหลายความหมาย ควรถามว่าค้นจากข้อมูลใด ผลลัพธ์ควรแสดงอะไร และกรณีไม่พบข้อมูลต้องเกิดอะไรขึ้น หากประสิทธิภาพเป็นข้อสำคัญ ต้องกำหนดปริมาณข้อมูลและสภาพแวดล้อมที่ใช้วัดก่อนตั้งตัวเลข เพราะ “เร็ว” บนเครื่องทดสอบที่มีสิบรายการไม่บอกผลบนข้อมูลจริง

ภาพที่ 1: เกณฑ์รับงานควรครอบคลุมผลที่คาดและขอบเขตที่ไม่อนุญาต เพื่อให้ตรวจซ้ำได้

ตัวอย่างสมมติ: ดูสถานะคำขอ

Story คือ “ผู้ยื่นดูสถานะคำขอของตน” เกณฑ์อาจเป็น: เมื่อผู้ใช้เปิดรายการ ระบบแสดงคำขอของตนพร้อมสถานะล่าสุด; เมื่อไม่มีคำขอ ระบบแสดงข้อความว่างที่เข้าใจได้; เมื่อผู้ใช้ขอรหัสคำขอของคนอื่น ระบบไม่เปิดข้อมูลนั้น แม้เปลี่ยน URL เอง เกณฑ์สุดท้ายเป็นข้อกำหนดด้านสิทธิ์ที่มองไม่เห็นจากหน้าจอปกติ แต่สำคัญต่อการยอมรับงาน

ทีมอาจเขียนในรูป “กำหนดให้–เมื่อ–แล้ว” (Given–When–Then) เพื่อให้เห็นเงื่อนไขก่อนทำ การกระทำ และผลที่คาด แต่ไม่จำเป็นต้องใช้รูปแบบนี้กับทุกข้อ หากประโยคธรรมดาชัดกว่า ควรเลือกวิธีที่ทีมและผู้ตรวจอ่านเข้าใจ

เกณฑ์รับงานต่างจาก Test Case อย่างไร

Acceptance Criteria บอก อะไรต้องเป็นจริง ส่วน Test Case ระบุ จะทดสอบอย่างไร พร้อมข้อมูล ขั้นตอน และผลที่คาด หนึ่งเกณฑ์อาจต้องมีหลาย Test Case เช่น ตรวจสิทธิ์ด้วยบัญชีเจ้าของ บัญชีเพื่อนร่วมทีม และบัญชีต่างองค์กร อย่าเขียนเกณฑ์เป็นรายการคลิกทุกปุ่มจนผูกกับหน้าจอมากเกินไปเมื่อผลลัพธ์ทางธุรกิจไม่ได้เปลี่ยน

สำหรับรายงานและการตรวจรับ

เลือก Requirement จริงหนึ่งข้อ เขียนเกณฑ์กรณีสำเร็จ กรณีข้อมูลผิด และกรณีสิทธิ์ไม่ผ่าน แล้วแสดงว่าผู้เกี่ยวข้องยอมรับถ้อยคำเดียวกันหรือยัง หากยังไม่ตรวจกับผู้ใช้ ให้ระบุว่าเป็นเกณฑ์เสนอ ไม่อ้างว่าเป็นข้อตกลงจริง งานที่ยังไม่ผ่านเกณฑ์ควรถูกบันทึกชัดเจน แม้หน้าจอจะดูเสร็จแล้ว

อ่าน User Story และ Test Case หรือดู บริการพัฒนา Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

ลองกำหนดกรณีศึกษาเป็น ระบบปฏิเสธคำขอเมื่อแนบเอกสารไม่ครบ และเขียนขอบเขตให้ชัดว่ามีผู้ใช้กลุ่มใด ข้อมูลใดเข้าสู่ระบบ และต้องการผลลัพธ์อะไร เริ่มจากสภาพก่อนพัฒนา แล้วอธิบายการตัดสินใจที่บทความนี้เกี่ยวข้องโดยใช้ตัวอย่างข้อมูลหรือเหตุการณ์ที่สมมติขึ้นอย่างระบุว่าเป็นตัวอย่าง การกำหนดขอบเขตเช่นนี้ช่วยให้ผู้อ่านแยกหลักการทั่วไปออกจากข้อเท็จจริงของโครงการได้

หลักฐานที่ควรแสดงคือ เงื่อนไขก่อนทำ การกระทำ และผลที่คาดทั้งกรณีผ่านและไม่ผ่าน ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

เกณฑ์ประเมินตัวอย่างคือ ผู้ทดสอบตรวจผลได้โดยไม่ต้องเดาเจตนาผู้เขียน ส่วนข้อจำกัดที่ต้องระบุคือ เกณฑ์รับงานไม่แทนกฎความปลอดภัยหรือรายละเอียด UX ทั้งหมด หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน

แหล่งข้อมูลประกอบ

• Atlassian: User stories — บริบทของ Story และเกณฑ์รับงาน
• ISO/IEC/IEEE 29148: Requirements engineering — หลักการเขียนข้อกำหนดที่ตรวจสอบได้