เราอยากสอบตกตอน UAT: วิธีที่เราจัดการทดสอบรับมอบกับลูกค้า ให้เจอปัญหาตอนที่มันยังถูก

เราเคยเขียนคู่มือ UAT ฝั่งผู้ว่าจ้างไว้แล้ว — ทำไมต้องมี เกณฑ์รับมอบควรหน้าตาเป็นยังไง บทความนี้คือฝั่งของเรา: ทีมพัฒนาจัดฉากการทดสอบนี้ยังไงให้มันทำหน้าที่ของมันจริง ๆ ก่อนอื่นต้องสารภาพมุมมองที่อาจฟังแปลก: เราไม่ได้อยากให้ UAT ผ่านเรียบร้อยในรอบแรก เราอยากให้มันเจอปัญหา เพราะปัญหาเดียวกันเป๊ะ ๆ มีราคาต่างกันมหาศาลตามเวลาที่มันถูกพบ — บั๊กที่เจอใน UAT คือการแก้หนึ่งวันในสภาพแวดล้อมทดสอบ บั๊กเดียวกันที่รอดไปเจอหลัง go-live คือคิวหน้าร้านที่สะดุด ความเชื่อมั่นของทีมลูกค้าที่เพิ่งเปราะบาง และการแก้ไฟกลางระบบที่มีข้อมูลจริงวิ่งอยู่ UAT ที่ดีจึงไม่ใช่พิธีเซ็นรับ มันคือความพยายามร่วมกันครั้งสุดท้ายที่จะพังระบบให้ได้ ตอนที่การพังยังไม่มีใครเจ็บ และการออกแบบการทดสอบให้พังเป็น คือฝีมือคนละแบบกับการเขียนระบบให้ทำงาน

สคริปต์ทดสอบที่ดีคือหนึ่งวันทำงานจริง ไม่ใช่รายการฟีเจอร์

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

กติกาข้อแรกที่เราขอเสมอ: คนทดสอบต้องเป็นคนที่จะใช้จริง ไม่ใช่หัวหน้าของเขา — แคชเชียร์ตัวจริง คนคลังตัวจริง คนบัญชีตัวจริง — ด้วยเหตุผลเดียวกับด่านทดสอบ UX หน้างานที่เราเขียนไว้: หัวหน้าที่คล่องคอมกดอะไรก็ผ่าน แต่ระบบต้องรอดมือของคนที่จะกดมันวันละแปดชั่วโมง และเราอยากได้อย่างน้อยสองคนต่อบทบาท เพื่อไม่ให้เสียงเดียวกลายเป็นข้อสรุป ระหว่างทดสอบ ทุกสิ่งที่เจอถูกจดลงกระดานเดียวที่ทั้งสองทีมเห็น แล้วแยกด้วยกติกาสามกองที่ผู้อ่านซีรีส์นี้คุ้นแล้ว: บั๊กจริง (ระบบทำงานผิดจากที่ตกลง — คิวแก้ทันที) เรื่องการฝึกหรือความไม่ชิน (จดไว้เป็นหลักสูตรฝึก ไม่ใช่งานแก้โค้ด) และคำขอเพิ่มที่เพิ่งนึกได้ (มีค่ามาก แต่เข้าคิวเฟสถัดไปตามกระบวนการคัดของเรา ไม่ใช่แทรกกลาง UAT) การแยกสามกองต่อหน้ากันนี้คือสิ่งที่ทำให้ UAT จบได้ — เพราะ UAT ที่ไม่แยกกอง จะกลายเป็นสนามขอฟีเจอร์ไม่รู้จบที่เกณฑ์รับมอบเลื่อนหนีไปเรื่อย ๆ

เกณฑ์จบที่ตกลงก่อนเริ่ม และรอบสองที่สั้นกว่าเสมอ

คำถามที่ต้องตอบก่อนเริ่มทดสอบหนึ่งนาที: อะไรคือผ่าน เกณฑ์ของเราเขียนง่าย ๆ สองบรรทัด — สคริปต์ทุกบทต้องเดินจบได้โดยไม่มีบั๊กระดับหยุดงาน และบั๊กย่อยทุกตัวต้องมีเจ้าของกับกำหนดแก้ที่ตกลงกัน ไม่ใช่ศูนย์บั๊ก เพราะระบบจริงไม่มีวันศูนย์บั๊ก แต่คือไม่มีบั๊กที่ขวางการทำงานจริง เมื่อรอบแรกจบ เราแก้ตามคิว แล้วนัดรอบสองที่ทดสอบเฉพาะจุดที่แก้บวกเส้นทางรอบข้างของมัน — รอบสองที่ดีสั้นกว่ารอบแรกมาก และจบด้วยการเซ็นรับที่ทั้งสองฝ่ายรู้ตรงกันว่าเซ็นอะไร บนหลักฐานการทดสอบที่เก็บไว้ครบ ทั้งหมดนี้ฟังเหมือนพิธีการเยอะ แต่จากบันทึกของเราเอง โปรเจกต์ที่ UAT เข้มข้นที่สุด คือโปรเจกต์ที่สัปดาห์ go-live เงียบที่สุดแทบทุกครั้ง — และถ้าคุณกำลังเลือกทีมพัฒนา คำถามที่เราแนะนำให้ถามคือ ขอดูสคริปต์ UAT ของโปรเจกต์ล่าสุดหน่อย: ทีมที่มีของจริงให้ดู กับทีมที่ตอบว่าเดี๋ยวค่อยว่ากันตอนใกล้เสร็จ คือทีมคนละชนิดกัน