Test Hard vs. Test Smart

I Don’t Believe When You Say “We Need To Test Them All”.

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

ผ่านไปสองชั่วโมง น้องคนนั้นก็ส่งบทความฉบับแก้ไขกลับมาให้ผมอ่านอีกรอบ ถึงตรงนี้ผมมีคำถามล่ะว่า “แก้ตรงไหนไปหว่า? … แล้วผมควรจะอ่านตรงไหนบ้าง?” เลยเดินไปถามน้องเค้าที่โต๊ะ “อ๋อ ก็อ่านทั้งหมดแหละค่ะ”

ด้วยเวลาที่เร่งเข้ามาแล้ว ผมต้องส่งต้นฉบับบทความทั้งหมดให้โรงพิมพ์ในอีก 15 นาที … ต้องอ่านหมดจริงหรอเนี่ยะ ก็ได้วะ!!! ด้วยเวลาที่มีผมทำดีที่สุดได้แค่นี้ครับ

เวลาหมดแล้ว … ส่งโรงพิมพ์ไปแบบนี้เลยแล้วกัน (บั๊กบานหนักกว่าเก่า ดูเส้นสีแดงสิ)


ถ้าเรามองเรื่องสมมตินี้ให้เป็นงาน Software Development และ Testing มันก็เปรียบได้กับการที่ผมในฐานะ Tester เจอบั๊กเล็กๆมาตัวนึง ส่งกลับไปให้น้องนักเขียนในฐานะ Developer แก้ แล้วพอผมไปถามว่า “แก้อะไรไปบ้าง พี่จะได้รู้ว่าควรต้องเทสอะไรบ้าง” น้องเค้าก็ตอบกลับมาอย่างเต็มปากว่า “เทสหมดนั่นแหละค่ะ” ไอ้ผมก็บ้าจี้เทสพยายามมันใหม่หมด แต่ด้วยเวลาที่จำกัดจึงเทสได้แค่ผิวเผิน ไม่ได้เทสตรงจุดที่น้องเค้าแก้มาเลย จึงได้ข้อสรุปผิดๆว่า งานนี้ไม่มีบั๊กแล้วทั้งที่ความจริงคือบั๊กบานกว่าเดิม ฮ่าๆๆ

ทำเป็นขำไปเถอะ นี่เป็นเหตุการณ์ที่เกิดขึ้นเป็นประจำในการทำ Software Development และ Testing นะครับ ผมขอเรียกกระบวนการนี้ว่า Test Hard But Not Smart — เทสหนักแต่ไม่ฉลาด

ถ้าอยากเทสให้ฉลาด ผมคิดว่าเราอย่าไปเชื่อ Developer ง่ายๆว่าต้องเทสทั้งหมด คือที่พูดว่าเทสทั้งหมดมันง่ายไง ไม่ได้มาเทสเองนี่หว่า มันเยอะนะเว้ย ถ้าอยากทำงานให้ฉลาดเราต้องใช้สมองและเวลาเพิ่มกว่านี้นิดนึง แนวทาง

  1. เรา (Tester) ต้องรู้ให้ได้ก่อนว่า Root Cause ของบั๊กนี้คืออะไร ถ้าเราไม่รู้ เราต้องไปถาม Developer ให้รู้ ถ้าเค้าก็ไม่รู้ … ทั้งสองคนก็ต้องเอาให้รู้ให้ได้ว่าสาเหตุที่ทำให้เกิดบั๊กนี้คืออะไร
  2. เรา (Tester) ต้องรู้ให้ได้ว่า Developer แก้อะไรไปบ้าง ผมหมายถึงในโค๊ดเลย บางครั้งถามปากเปล่าเค้าอาจจะตอบได้ไม่ครบ ไม่คลุม ทางที่ดีเอาโค๊ดเวอร์ชั่นเก่ามาเทียบกับเวอร์ชั่นใหม่เลย ให้เห็นชัดๆว่าแก้อะไรไปบ้างแล้วผลกระทบจากการแก้ครั้งนี้มีอะไรบ้าง ช่วยกันคิด ช่วยกันวิเคราะห์ ถ้าอ่านโค๊ดแล้วหาคำตอบไม่ได้ก็ลอง Debug ดู ลองเทสเล่นๆดู ลงทุนหน่อย มันคุ้มค่ามากนะ

จากเดิมที่เราต้องเทส 1000 เทสเคส อาจจะเหลือแค่ 20 เทสเคสชุดเดิมและเพิ่มเทสเคสใหม่ไปอีก 10 ข้อ รวมเป็น 30 ข้อที่สามารถบอกเราได้อย่างมั่นใจว่าการแก้บั๊กครั้งนี้ผ่านหรือไม่ผ่าน

Test Smart คือการเทสที่น้อยที่สุดที่การันตีคุณภาพที่สูงที่สุดด้วยเวลาที่สั้นที่สุด

ใน Microsoft Word มี Track Changes ในโค๊ดเราก็ควรจะมี Track Changes ด้วยเช่นกัน … สู้ๆ Tester ทุกท่าน ☺


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

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ

Show your support

Clapping shows how much you appreciated Piyorot’s story.