สิ่งที่น่าสนใจอย่างหนึ่งของนักพัฒนา 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 ชุดการทดสอบยิ่งนานเข้าไปใหญ่
ทำให้ต้องรอนานมาก ๆ
ซึ่งเสียเวลาเช่นกัน
บางครั้งทดสอบผ่าน บางครั้งทดสอบไม่ผ่าน
ทำให้ไม่น่าเชื่อถือ
ดังนั้นเลิกเถอะ

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

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