UAT และการตรวจรับระบบ — ด่านสุดท้ายก่อนจ่ายเงินงวดใหญ่ ที่ธุรกิจส่วนมากตรวจผิดวิธี

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

ออกแบบชุดทดสอบจากเดือนที่ยากที่สุด ไม่ใช่จากเมนูของระบบ

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

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

หลังเซ็นรับ — ช่วงประกันผลงานและการวิ่งคู่

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

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

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