ก่อนให้ลูกค้าเห็น เราพยายามพังระบบตัวเองก่อน: กระบวนการทดสอบภายในของทีม และรายการทรมานระบบที่เราใช้จริง

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

รายการทรมานระบบ: บทเรียนจากบั๊กจริงที่กลายเป็นเช็คลิสต์

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

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

สิ่งที่เรื่องนี้แปลว่าอะไรสำหรับคนจ้าง

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