คราวก่อนผมบล็อกเรื่อง Bug : Track มันไปทำไม? มีผู้อ่านท่านหนึ่งได้กรุณา ถามมาว่า
“มันก็ไม่ได้หมดความจำเป็นไปซะทีเดียวหรือเปล่าครับ? เพราะถ้าสมมติให้ไม่มีทีม dev/test แยกกันชัดเจนก็จริง แต่ถ้า user รายงาน bug กลับมาในปริมาณมากขนาดหนึ่ง จะบอกให้เก็บ bug ทันทีเดี๋ยวนั้นทุกตัวก็เป็นไปไม่ได้ สุดท้ายก็ต้องมาวางแผนว่า bug ไหนที่มีผลกระทบสูงและควรถูกจัดการก่อนหรือเปล่า”
เป็นเรื่องประหลาดที่พวกเรามักจะวางแผนให้ซอฟแวร์ของเราจะต้องมี bug ?”
ผมคิดถึงโฆษณาบริการของธนาคารแห่งที่หนึ่งที่พี่ดู๋สัญญาบอกว่า “คุณเลือกที่จะไม่จ่ายค่าธรรมเนียมได้นะครับ” ผมจึงอยากบอกบ้างว่า
“คุณเลือกที่จะไม่มี bug ได้นะครับ”
“มันเป็นไปไม่ได้หรอก” หลายคนคงคิดเช่นนั้น แต่ความจริงแล้ว ถ้าเรารู้ล่วงหน้าว่า tester หรือแม้แต่ user จะ test ระบบอย่างไรบ้าง เราก็จะสามารถปัองกันสิ่งที่เรียกว่า bug ทั้งหมดได้ เปรียบเหมือนถ้าเรารู้ข้อสอบล่วงหน้า เราก็คงจะสามารถทำคะแนนเต็มได้ไม่ยาก สิ่งที่น่าประหลาดคือ ในสมัยเรียน อาจารย์คงไม่บอกข้อสอบเรา แต่สำหรับโลกการทำงานแล้ว tester และ user ของเราพร้อมจะบอกข้อสอบ หรือ test case แก่เราทั้งหมดอย่างแน่นอน แต่พวกเรากลับไม่เคยคิดที่จะถามพวกเขาเลยว่า จะ test ระบบเราอย่างไร บ้าง อาจจะเป็นเพราะเราติดนิสัยสมัยเรียนที่คิดว่า อาจารย์คงไม่บอกข้อสอบแน่ๆ แล้วนั่งเดากันไปว่า ข้อสอบจะออกอย่างไร
ผมเห็นหลายคนเริ่มสนใจหลักการ ATDD (Acceptance Test Driven Development) แล้วมัวแต่ไปสนใจตัว framework พวก “แตงกวา” บ้าง “หุ่นยนต์” บ้าง อื่นๆ อีกหลากหลายตัว ซึ่งสามารถทำ automate test ได้ดี แต่ปัญหาของการทำซอฟแวร์ไม่ได้อยู๋ที่ technology การทำ autmate test แต่อยู่ที่ ที่มาของ test case ต่างหาก ถ้าหากว่า ยังคงนั่งเดาข้อสอบกันอยู่ สุดท้ายแล้ว ก็คงไม่พ้น มี bug ท่วมจนต้องมานั่ง track มันอยู่ดี
“คุณเลือกที่จะไม่ต้อง track bug โดยไม่ต้องมี bug ได้นะครับ”
