You can’t stop the waves, but you can learn how to surf

กราบสวัสดีบ่ายวันอังคารที่ 3 กันยายน พ.ศ. 2556 (-/\-) สืบเนื่องจากเช้าวันนี้เจอภาพนี้บน Timeline ของเพื่อนใน Facebook ผมนั่งมองนิ่งๆ อยู่ 10 วินาที พร้อมกับมีรอยยิ้มบนใบหน้าปลวกๆ ของตัวเอง 555 พร้อมกับ Post ขึ้นไปทั้ง Timeline ของตัวเอง Facebook Group WeLoveBug และ FanPage WeLoveBug (เข้าขั้นบ้า) ดูจากรูปภาพแล้วน่าจะเป็นหน้าบริษัทอะไรสักอย่าง แต่ข้อความบนกระจกมันโดนใจผม 10 วินาทีที่มองอย่างนิ่งๆ ทุกๆ เหตุการณ์ที่เกิดขึ้นระหว่างทางของการตั้งทีม Test กระบวนการการทดสอบ (Test Process) รวมทั้งทั้งผลักทั้งดันให้เรื่องของคุณภาพ (Quality) เกิดขึ้นในองค์กรที่ผมเองเคยอยู่ มันวิ่งกลับเข้ามาในสมองทันทีกับประโยค “You can’t stop the waves, but you can learn how to surf”

You can’t stop the waves

สิ่งมีชีวิตนามว่า Tester ที่คิดว่าตัวเองมีคุณภาพที่สุดในโลก มักจะบ่น บ่น บ่น และบ่น กับ สิ่งมีชีวิตนามว่า Programmer ที่คิดว่าตัวเองฉลาดที่สุดในโลก ว่า “เธอ เขียน Code ยังไงเนี่ย มี Bug มาตลอดเลย” และก็จะเกิด สงครามศักดิ์สิทธิ์ ขึ้นตลอด จนสุดท้ายก็ ลาออก กันไป (ไว้จะเขียนเรื่อง สงครามศักดิ์สิทธิ์)

You can’t stop the waves ผมสนใจคำว่า waves แล้วนำมันไปเปรียบกับ Bug หรือ Defect ที่มีผลโดยตรงกับ คุณภาพของงาน ณ ตรงนี้เราพูดกันอยู่ในส่วนของ Software ซึ่งไม่ว่าคุณจะเป็นใครหน้าไหน จะเก่งกล้ามาจากไหน จะเทพมาจากไหน จงจำใส่ หัวกบาล (ใช้เรียกศีรษะ แต่ไม่สุภาพ) ไว้ว่า

มีโอกาสเสมอที่ Software จะมี Bug หรือ Defect, กระบวนการทดสอบ (Software Testing) ช่วยลดความเสี่ยง เพิ่มคุณภาพ เพิ่มความมั่นใจ และไม่มี Software ไหน ไม่ว่าจะถูกพัฒนาโดย เทพพระเจ้า หน้าไหน ที่จะไม่มี Bug หรือ Defect

ดังนั้น สิ่งมีชีวิตนามว่า Tester ที่คิดว่าตัวเองมีคุณภาพที่สุดในโลก ที่กำลัง เบื่อๆ หน่ายๆ กับจำนวน Bug หรือ Defect ที่พบเจอมากขึ้นจนคิดอยากจะลาออก เพื่อย้ายที่ทำงานใหม่ ไปเป็น สิ่งมีชีวิตนามว่า Tester ที่คิดว่าตัวเองมีคุณภาพที่สุดในโลก ในบริษัทอื่นๆ ผมบอกเลยว่า ก็จะไปเจอปัญหาเดิมๆ นะจ๊ะ

ทำไมไม่ลองมาสนุกกับการจับ Bug หรือ Defect ที่เรา พบ เจอ และบันทึกเก็บไว้ ไม่ว่าจะในระบบ Defect Managmenet หรือ Excel หรือ Word หรือ อื่นๆ มา ชำแหละ ผ่าตัด ดูสิว่า

สาเหตุของ Bug หรือ Defect พวกนั้นมาจากไหน?

เพื่อนำพาไปสู่

การลดจำนวนประชากร Bug หรือ Defect ที่จะเกิดขึ้น (ละม้ายคล้ายๆ กับ การคุมกำเนิด)

but you can learn how to surf

อ่านมาถึงตรงบรรทัดนี้ สิ่งมีชีวิตนามว่า Tester ที่คิดว่าตัวเองมีคุณภาพที่สุดในโลก อาจจะรู้สึกว่าพี่เพ้อเจ้อไปป่ะกับ

การลดจำนวนประชากร Bug หรือ Defect ที่จะเกิดขึ้น (ละม้ายคล้ายๆ กับ การคุมกำเนิด) เนี่ยมันทำไม่ได้หรอก หนูเป็นแค่ Tester ตัวน้อยๆ ทีมลงทีมหลีด เขายังไม่สนใจจะทำเลย

ก็ถ้าคิดแบบนั้นจริงๆ ก็ นั่งหา Bug หรือ Defect แล้วก็รอเวลาเลิกงาน เก็บกระเป๋ากลับบ้านเถอะจ้า

but you can learn how to surf ผมสนใจคำว่า learn นะครับ สำหรับผม Bug หรือ Defect ที่เราเก็บสะสมไว้ในระบบ Defect Management หรือ Excel หรือ Word หรือ อื่นๆ เป็นเหมือน ขุมทรัพย์ ที่เราสามารถนำออกมาจัดกลุ่มดูสิว่า สาเหตุของ Bug หรือ Defect พวกนี้เกิดจากอะไร แล้วเราจะคุมกำเนิดมันได้อย่างไรบ้าง

เท่าที่ประสบพบเจอมา รวมทั้งอ่านจากเอกสาร และบทความต่างๆ จาก Website พอจะสรุปได้ว่า Bug หรือ Defect เกิดมาจากอะไรได้บ้าง

Requirement Definition

การตีความ Requirement ที่ไปคนละทิศละทาง ไม่รู้ ไม่ถาม คิดเอง มักจะเจอ สิ่งมีชีวิตนามว่า Tester ที่คิดว่าตัวเองมีคุณภาพที่สุดในโลก และสิ่งมีชีวิตนามว่า Programmer ที่คิดว่าตัวเองฉลาดที่สุดในโลก บ่นว่า Requirement ไม่ชัด อันนี้เตือนไว้นะครับว่า ถ้าเจอคนอย่างผม ผมจะให้เขียนหน่อยว่า หน้าตาของ Requirement แบบชัดๆ ที่เอาไปทำงานได้ต่อ หน้าตาเป็นยังไงให้เขียนให้ดูหน่อย ประเด็นไม่ใช่ผมจะอวดเก่ง หรือข่มน่ะ แต่ ถ้าแค่บ่นๆ ออกมาว่า Requirement มันไม่ชัดทำงานไม่ได้ โน้นนี่นั่น แสดงว่าคุณทั้ง 2 เคยเห็น Requirement ชัดๆ ที่เอาไปทำงานต่อได้ ดังนั้นก็ต้องเขียนให้ดูได้ว่าจาก Requirement ที่ไม่ชัด ให้เป็น Requirement แบบชัดๆ ที่ทำงานต่อได้ ทำอย่างไร

เรื่องการตีความ Requirement นี้แหละครับ หลายๆ สำนักเก็บตัวเลขสะสมมา แล้วพบว่า เกิน 50% ของ Bug หรือ Defect ที่ พบ มาจากเรื่องนี้เลย ดังนั้น ถ้าสงสัยจง ถาม และสำหรับคนให้ Requirement จงเปิดรับฟัง ทีมทำงานช่วยกันทำให้ Requirement ชัดเจนขึ้น พร้อมกับสรุปออกมาว่า Requirement ข้อนี้จะ ทดสอบ (Test) และ ตรวจรับ (Acceptance) กันแบบไหนบ้าง

System Design

ผมขอเรียกว่า ความไม่เก๋าพอ ของ สิ่งมีชีวิตนามว่า System Analyst ชั่วโมงบิน ประสบการณ์ รวมทั้งความเข้าใจตัว Software และเรื่องราวความเป็นมา ไม่มากพอ การออกแบบระบบก็เป็นสาเหตุของการเกิด Bug หรือ Defect ได้ด้วยเช่นกัน ดังนั้นควรร่วมด้วยช่วยกันคิด ตรวจสอบ เพื่อให้ได้ Solution ออกมาได้ค่อนข้างตรง ทีมพัฒนาเป็นกลุ่มสิ่งมีชีวิตที่ช่วยได้นะจ๊ะ

Inadequate Testing of Software

ผมแปลแบบเกรียนๆ ว่า “กระบวนการทดสอบแบบ กาก กาก” สิ่งมีชีวิตนามว่า Tester ที่คิดว่าตัวเองมีคุณภาพที่สุดในโลก ตัวเธอทั้งหลายเองก็เป็น 1 ใน ผู้ให้กำเนิด Bug หรือ Defect นะจ๊ะ อย่าได้คิดว่า ตัวเองมีคุณภาพคับแก้ว จนชี้นิ้ว จิกกัด สิ่งมีชีวิตอื่นๆ ในทีมพัฒนาว่า พวกแกคุณภาพห่วย

• วิเคราะห์ Requirement ไม่ครบ
• ออกแบบการทดสอบไม่ได้
• เขียน Test Case หยาบๆ
• เตรียม Test Data แบบขอไปที
• ชั่วโมงบินไม่พอ
• อื่นๆ

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

• ไม่เข้าใจ Requirement ที่จะทดสอบ
• ออกแบบ และเขียน Test Cases ไม่ครอบคลุม
• เตรียม Test Data ผิด

ดังนั้นจงกล้าที่จะ ร้องขอความช่วยเหลือ จากทีม ทีม และทีม

การนำ Bug หรือ Defect ที่ เราได้ เก็บสะสม ไว้ มาเพื่อแยกสาเหตุต้นกำเนิดของ Bug หรือ Defect นั้น สำหรับผมนับว่าเป็นการ learn how to surf ครับ คุณภาพของ Software ควรจะเกิดขึ้นในทุกๆ ขั้นตอนของการพัฒนา ไม่ใช่ฝากมันไว้กับ สิ่งมีชีวิตนามว่า Tester ที่คิดว่าตัวเองมีคุณภาพที่สุดในโลก เท่านั้น

ไม่ว่าทีมพัฒนาของคุณจะ มี หรือ ไม่มี สิ่งมีชีวิตนามว่า Tester ที่คิดว่าตัวเองมีคุณภาพที่สุดในโลก ร่วมทีมอยู่ การทดสอบ (Testing) ถือเป็น สิ่งที่สิ่งมีชีวิตในทีม จะต้องร่วมด้วยช่วยกัน นะจ๊ะ

ไม่มี Requirement แบบสมบูรณ์ 100% ห้ามเปลี่ยนแปลง

ไม่มี Software ใดๆ เลยที่ไม่มี Bug หรือ Defect

ไม่มี สิ่งมีชีวิตนามว่า Tester ที่มีคุณภาพที่สุดในโลก

ดังนั้น จงเรียนรู้จาก Bug หรือ Defect เรามีอยู่ในมือ แต่ไม่เคยชายตาไปมองมันเลย หยิบมันมา ชำแหละ ดู ว่า เราจะคุมกำเนิดมันได้อย่างไร แล้วค่อยๆ ปรับปรุง ปรับเปลี่ยน วิธีการทำงาน วิธีการทดสอบ ไปเรื่อยๆ ให้เหมาะสมกับ แต่ละช่วงเวลา เพราะ You can’t stop the waves, but you can learn how to surf