เกณฑ์การยอมรับที่เขียนขึ้นหลังการพัฒนาเสร็จสิ้นไม่ใช่เกณฑ์การยอมรับ แต่เป็นความคิดเห็นที่เกิดขึ้นระหว่างการดูผลลัพธ์ และไม่สามารถใช้ตัดสินชี้ขาดเรื่องใด ๆ ได้
การเขียนเกณฑ์ก่อนเริ่มพัฒนา
เกณฑ์การยอมรับระบุว่าคุณจะตัดสินอย่างไรว่าฟีเจอร์หนึ่งเสร็จสมบูรณ์ และเกณฑ์เหล่านี้ต้องมีอยู่ก่อนสร้างฟีเจอร์ด้วยเหตุผลสองประการ ได้แก่ นักพัฒนาต้องทราบว่ากำลังพัฒนาไปสู่เป้าหมายใด และลูกค้าต้องมีมาตรฐานที่ไม่ได้รับอิทธิพลจากผลลัพธ์ที่เกิดขึ้น
เกณฑ์ที่นำไปใช้ได้ต้องมีความเฉพาะเจาะจงและทดสอบได้:
- อ่อน: "การค้นหาควรทำงานได้ดี"
- นำไปใช้ได้: "การค้นหาด้วยชื่อลูกค้าจะแสดงระเบียนที่ตรงกันภายในสองวินาที รองรับชื่อบางส่วน และไม่คำนึงถึงตัวพิมพ์เล็กใหญ่"
ข้อที่สองสามารถทดสอบได้โดยใครก็ตาม ส่วนข้อแรกไม่สามารถทดสอบได้เลย
การทำ UAT ที่ค้นพบปัญหาจริง
การทดสอบการยอมรับโดยผู้ใช้ที่ทำในลักษณะ "ลองดูแล้วบอกเราว่าคิดอย่างไร" มักพบปัญหาด้านรูปลักษณ์ แต่พลาดปัญหาที่สำคัญกว่า การจัดโครงสร้างที่ดีช่วยปรับปรุงกระบวนการนี้ได้อย่างมาก
- ทดสอบตามเวิร์กโฟลว์ ไม่ใช่ตามหน้าจอ ดำเนินงานทั้งหมดที่ผู้ใช้จริงทำตั้งแต่ต้นจนจบ ปัญหามักอยู่ตรงจุดเชื่อมระหว่างหน้าจอ ไม่ใช่บนหน้าจอเอง
- ใช้ข้อมูลที่สมจริง ชื่อยาว อักขระที่มีเครื่องหมายกำกับ ช่องข้อมูลเสริมที่เว้นว่าง ปริมาณจำนวนมาก และวันที่ตรงรอยต่อของเดือนและปี ข้อมูลทดสอบที่สะอาดเกินไปจะซ่อนปัญหาการจัดการข้อมูลนำเข้าส่วนใหญ่
- ตั้งใจทดสอบเส้นทางเมื่อเกิดข้อผิดพลาด ส่งแบบฟอร์มซ้ำสองครั้ง ป้อนรหัสผ่านผิดห้าครั้ง ตัดการเชื่อมต่อระหว่างกระบวนการ เส้นทางเหล่านี้คือสถานการณ์ที่ผู้ใช้จริงมักพบ แต่เป็นจุดที่การทดสอบมักไม่ครอบคลุม
- ให้ผู้ใช้จริงเป็นผู้ทดสอบ บุคคลที่จะใช้งานระบบทุกวันจะพบปัญหาที่ผู้สนับสนุนโครงการไม่มีทางพบ เพราะพวกเขารู้ว่างานจริงต้องทำอะไรบ้าง
- บันทึกทุกประเด็นที่พบไว้ในที่เดียว พร้อมขั้นตอนการทำให้เกิดซ้ำและภาพหน้าจอ ประเด็นที่ไม่สามารถทำให้เกิดซ้ำได้ก็ไม่สามารถแก้ไขได้
ข้อบกพร่องหรือการเปลี่ยนแปลง
UAT ทุกครั้งย่อมพบประเด็นที่ไม่ใช่ข้อบกพร่อง และการจัดประเภทอย่างเป็นธรรมคือสิ่งที่ช่วยไม่ให้กระบวนการกลายเป็นการเผชิญหน้ากัน
ข้อบกพร่อง คือความแตกต่างระหว่างสิ่งที่ตกลงกันไว้กับสิ่งที่พัฒนาขึ้นมา โดยนักพัฒนารับผิดชอบค่าใช้จ่ายในการแก้ไข
การเปลี่ยนแปลง คือสิ่งที่ทำงานได้ตามที่ตกลงกันไว้ แต่ไม่ใช่สิ่งที่ลูกค้าต้องการในขณะนี้ โดยมีการเสนอราคาแยกต่างหาก
ลูกค้ามักมองกรณีที่สองว่าเป็นข้อบกพร่อง เพราะซอฟต์แวร์ทำงานในแบบที่พวกเขาไม่ได้คาดไว้ คำตอบที่ตรงไปตรงมาคือไม่ใช่การโต้เถียงเรื่องป้ายกำกับ แต่ควรชี้ไปยังเกณฑ์ที่ตกลงกันไว้ แล้วถามว่าการเปลี่ยนแปลงนั้นคุ้มค่าที่จะทำหรือไม่ หลายกรณีพบว่าไม่คุ้ม
ระดับความรุนแรง ซึ่งเป็นตัวกำหนดว่าอะไรจะบล็อกการเปิดตัว
ไม่ใช่ข้อบกพร่องทุกข้อที่ต้องแก้ก่อนเปิดใช้งาน และการถือว่าทุกข้อเป็นอุปสรรคจะทำให้การเปิดใช้งานล่าช้าโดยไม่เกิดประโยชน์ การแบ่งประเภทแบบสามระดับอย่างง่ายที่ตกลงกันไว้ล่วงหน้า:
- ระดับบล็อกการเปิดตัว — ไม่สามารถทำเวิร์กโฟลว์หลักให้เสร็จสมบูรณ์ ข้อมูลสูญหายหรือเสียหาย หรือมีปัญหาด้านความปลอดภัย ต้องแก้ไขก่อนเปิดใช้งาน
- ระดับร้ายแรง — ฟีเจอร์ทำงานไม่ถูกต้อง แต่มีวิธีแก้ไขชั่วคราว หากมีเวลาให้แก้ไขก่อนเปิดใช้งาน มิฉะนั้นให้กำหนดแผนพร้อมวันที่
- ระดับเล็กน้อย — ปัญหาด้านรูปลักษณ์ การใช้ถ้อยคำ และความไม่สอดคล้องเล็ก ๆ น้อย ๆ รวบรวมไว้ในรุ่นหลังเปิดใช้งาน
การตกลงเรื่องการแบ่งประเภทนี้ก่อนเริ่ม UAT จะเปลี่ยนข้อโต้แย้งเรื่องความเร่งด่วนให้กลายเป็นการประเมินร่วมกัน
สิ่งที่การลงนามรับรองผูกมัดทั้งสองฝ่าย
การลงนามรับรองควรมีความหมายที่ชัดเจน ได้แก่ มีการปฏิบัติตามเกณฑ์ที่ตกลงกันไว้ มีการระบุรายการเล็กน้อยที่ยังค้างอยู่พร้อมวันที่ และมีการอนุมัติการจ่ายเงินตามงวด การดำเนินการนี้จะเริ่มระยะเวลารับประกัน ซึ่งในช่วงดังกล่าวข้อบกพร่องที่พบภายหลังจะได้รับการแก้ไขโดยไม่คิดค่าใช้จ่าย
ไม่ได้หมายความว่าลูกค้าจะไม่สามารถรายงานปัญหาได้อีก และสัญญาที่สื่อความหมายเช่นนั้นถือว่าไม่สมเหตุสมผล ระยะเวลารับประกันคือสิ่งที่ครอบคลุมข้อบกพร่องที่การทดสอบ UAT อย่างสมเหตุสมผลคงไม่พบ
เวลาที่ควรเผื่อไว้
UAT มักได้รับการวางแผนเวลาไว้น้อยเกินไปอย่างสม่ำเสมอ สำหรับโครงการขนาดเล็ก ควรเผื่อเวลาหนึ่งถึงสองสัปดาห์ — เพียงพอให้ผู้ใช้จริงทดสอบควบคู่ไปกับงานจริงของตน ให้แก้ไขประเด็นที่พบ และทดสอบซ้ำ
การลดเวลาเหลือสองวันทำให้การลงนามรับรองไม่มีความหมายที่ใช้ได้ และปัญหาจะไปปรากฏในสัปดาห์แรกของการใช้งานจริงแทน ซึ่งขณะนั้นมีค่าใช้จ่ายสูงกว่าและมองเห็นได้ชัดเจนกว่ามาก
บริการ Manboo ที่เกี่ยวข้อง
- การพัฒนาแอป Flutter สำหรับ MVP บน iOS และ Android
- การพัฒนาซอฟต์แวร์ธุรกิจ สำหรับระบบ CRM ระบบจอง ระบบคลังสินค้า และระบบเวิร์กโฟลว์
- การพัฒนาแผงผู้ดูแลระบบ สำหรับแดชบอร์ดการดำเนินงานและการจัดการระบบแบ็กเอนด์
- การผสานรวม AI API เมื่อผลิตภัณฑ์ของคุณพร้อมสำหรับการค้นหาอัจฉริยะ แชต หรือระบบอัตโนมัติ
- ขอให้ตรวจสอบขอบเขตงานและประเมินราคาโครงการ เมื่อคุณพร้อมวางแผนเวอร์ชันแรก