ทำไม Developer ไม่เขียนชุดการทดสอบ

สิ่งที่น่าสนใจอย่างหนึ่งของนักพัฒนา software คือ มักจะพัฒนาให้มันเสร็จตามเวลา ส่วนเรื่องของความถูกต้องและคุณภาพก็ให้ความสำคัญนะ แต่ไม่ค่อยเน้นมากเท่าไร !! บ่อยครั้งกลับพบว่า จำนวนข้อผิดพลาดจำนวนมากจากการพัฒนา จากสิ่งที่บอกว่าเสร็จแล้ว เป็นประเด็นที่น่าสนใจคือ สิ่งที่นักพัฒนาบอกว่า เสร็จมันคืออะไรกันแน่ ? บางครั้งสิ่งที่มีปัญหากลับไม่ใช่สิ่งที่นักพัฒนาสร้าง แต่กว่าจะหาจุดหรือต้นเหตุของปัญเจอ ต้องใช้เวลานานมาก ๆ (Debugging) ส่วนเวลาในการแก้ไขก็เยอะตามเวลาที่กว่าจะหาเจอ (Mean Time To Recover/Detection)

พอไปพูดคุยกับนักพัฒนาว่า

ไม่ทดสอบกันหรือไง ? นักพัฒนาก็บอกว่า เราทดสอบนะ ทดสอบแบบบ้าน ๆ แต่ถามว่าทดสอบใหม่ทั้งหมดไหม ก็ตอบว่าไม่ รู้หรือไม่ว่า แต่ละ function/method ทำงานถูกต้องหรือไม่ ? คำตอบที่ได้คือ ก็น่าจะทำงานถูกนะ แต่ขอลองไป run หรือ deploy ระบบก่อน เพื่อจะดูว่ามีการทำงานถูกต้องหรือไม่ !!

จากที่เห็นพบว่า การพัฒนาของนักพัฒนาเพื่อให้งานเสร็จว่ายากแล้ว การตามมาหาข้อผิดพลาดและแก้ไขยากยิ่งกว่า ดังนั้นเราควรทำอย่างไรดี

นักพัฒนาหลาย ๆ คนก็บอกว่า เขียน test หรือทดสอบสิครับ !! แต่ก็มีหลากหลายเหตุผลว่าทำไมไม่เขียน มาดูเหตุผลเหล่านั้นกัน

1. หัวหน้าและฝ่าย management ไม่ให้ทำ

ปัญหาหลักคือ ส่วนใหญ่คนที่บอกไม่ให้ทำนั้น มักจะมาจาก non-technical ซึ่งมักมีความเข้าใจว่า การทดสอบนั้นคือหน้าที่ของ QA/Tester สิ ถ้านักพัฒนาจะมาทำ น่าจะเป็นงานที่ซ้ำซ้อน ดังนั้นไม่ต้องทำ แต่ ... เป้าหมายของนักพัฒนาคือ การส่งมอบ software ที่มีคุณค่าและคุณภาพสูงไปยังลูกค้า ดังนั้นไม่ว่าจะอย่างไร เรื่องการทดสอบมันคือสิ่งที่ต้องทำเสมอ ประเด็นหลัก ๆ คือ เขาไม่ให้ทำ หรือคุณต่างหากที่ไม่เคารพในงานของตัวเอง หรือคุณต่างหากที่ทำไม่เป็น หรือคุณต่างหากที่ไม่ทำเอง

2. เวลาไม่พอที่จะเขียนชุดการทดสอบนะ

ส่วนใหญ่นักพัฒนาจะถูกบังคับด้วย deadline เสมอ เป้าหมายหลัก ๆ คือ ต้องทำให้เสร็จ ดังนั้นก็มักจะตัดการทดสอบออกไปก่อนเสมอ คำถามคือ ตัดไปแล้วงานเสร็จจริง ๆ ไหม ?

3. ทีมตกลงกันแล้วว่าจะไม่เขียนการทดสอบ

เรื่องนี้น่าสนใจมาก ๆ ถ้าสมาชิกส่วนใหญ่ในทีมตกลงกันว่าจะไม่ทำ เราจะทำอย่างไรดี ? ไม่ทำด้วยเลย ทำแบบเงียบ ทำและพยายามอธิบายหรือแสดงคุณค่าของมันให้ทีม ไปหาทีมอื่น ไปหาบริษัทอื่น

4. ทำไปแล้ว ROI (Return On Investment) ดีขึ้นไหม

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

5. นักพัฒนาลองพยายามทำแล้ว แต่ไม่สำเร็จ

บางครั้งไปเขียนการทดสอบกับ Legacy code ที่ใหญ่มาก ๆ บางครั้งไปเขียนการทดสอบกับ God object บางครั้งไปเขียนในส่วนที่ไม่จำเป็น บางครั้งมีการตั้งเป้าหมายที่สูงหรือเกินความจำเป็น สุดท้ายสิ่งที่ทำไปก็เปล่าประโยชน์ ดังนั้นเลิกทำดีกว่า

6. เขียนชุดการทดสอบแล้ว ทำให้ช้าลง

เขียนว่าใช้เวลามากแล้ว ในช่วงการ run ชุดการทดสอบยิ่งนานเข้าไปใหญ่ ทำให้ต้องรอนานมาก ๆ ซึ่งเสียเวลาเช่นกัน บางครั้งทดสอบผ่าน บางครั้งทดสอบไม่ผ่าน ทำให้ไม่น่าเชื่อถือ ดังนั้นเลิกเถอะ

สุดท้ายคือ ไม่รู้จะเขียนอะไร ?

วันนี้นักพัฒนาเขียนชุดการทดสอบแล้วหรือยัง ?