พอดีเพิ่งคุยเรื่องการเขียน test ที่เป็นทำงานแบบอัตโนมัติ
จะเน้นที่การเขียน test code และ production code ไปด้วยกัน
มีคำถามที่น่าสนใจคือ เหตุผลที่บอกว่าจะไม่เขียน test
มันมีเยอะจนทำการสรุปได้ดังนี้
มาดูกันว่ามีเหตุผลอะไรบ้าง
เหตุผลที่ 1 คือ ไม่มีเวลา หรือ เวลาไม่เพียงพอ
เนื่องจากในการวางแผนไม่มีเรื่องของการเขียน test เข้ามาด้วย
ดังนั้นถ้าจะทำจริง ๆ ต้องขอเวลาเพิ่ม
สรุปได้เลยว่า เขียน code ให้เสร็จก่อนดีกว่า
คำถามที่น่าสนใจ จากเหตุผลนี้คือ ปกติไม่ทดสอบหรือไง ?
อีกเรื่องคือ มีเวลาแก้ไข bug แต่กลับไม่มีเวลา test มันแปลก ๆ ไหม ?
เหตุผลที่ 2 คือ code มันก็ทำงานได้ปกติดีนะ เขียนไปทำไม
น่าสนใจมาก ๆ นะ เพราะว่า code ดีและทำงานดีอยู่แล้วจะเขียน test ไปทำไม
สิ่งที่น่าคิดคือ ถ้ามีการเปลี่ยนแปลงใด ๆ เข้ามาแล้ว
การทำงานของ code ที่มันเคยดี มันยังทำงานดีทั้งหมดอยู่หรือไม่ ?
เหตุผลที่ 3 คือ code ที่เป็นอยู่มัน test ยาก ดังนั้นต้องแก้ไขหรือ refactor code
ก่อนฟังดูเหมือนจะดีเลย ก่อนจะทดสอบได้ต้องปรับปรุง code ให้ง่ายต่อการ test ก่อน
คำถามคือ มั่นใจได้อย่างไรว่า การปรับปรุง code จะไม่ทำให้การทำงานเดิมเปลี่ยนไป
หรือแก้ไขไปแล้วมันดีขึ้นนะ แต่ bug ตามมาเพียบ
แบบนี้ไม่น่าจะดีหรือเปล่า
ดังนั้นก่อนจะทำการปรับปรุง code ให้ดีขึ้น
ควรมี test เพื่อบอกว่าปัจจุบันมันทำงานถูกหรือผิดอย่างไร
เพื่อให้ตรวจสอบหลังจากที่ปรับปรุงไปแล้ว
เหตุผลที่ 4 คือ ไม่รู้จะ test อะไร
ต้องทดสอบทั้งหมดเลยไหม เป็นเหตุผลที่ดีนะ
เพราะว่า อยากจะ test แต่ไม่รู้จะ test อะไร
ดังนั้น test ให้หมดเลย เหมาะมากสำหรับการเริ่มต้น
เพราะว่าเป็นฝึกวินัยว่า ในการพัฒนาต้องมีการ test อยู่ในการทำงานเสมอ
หรือ coding === coding + testing
เหตุผลที่ 5 คือ requirement ไม่ดี หรือ ไม่ชัด หนักกว่านั้นคือ เปลี่ยนบ่อยมาก ๆ
Requirement ไม่ดี ไม่ควรนำมาเป็นข้ออ้าง
คำถามคือ requirement ไม่ดี แล้วเขียน code หรือพัฒนามาได้อย่างไร ?
อีกอย่างก็ต้องคุยกับทีมด้วย ว่ามันมีอะไรที่เยอะกว่าใน requirement หรือไม่
ยิ่ง requirement ไม่ดี เรายิ่งต้องเขียน test
เพื่อบันทึกว่า เราทำอะไรไปบ้าง จะทำให้เรารู้สถานะปัจจุบันได้ดียิ่งขึ้น
หรือถ้ามีการเปลี่ยนแปลงมา เราจะได้รู้ผลกระทบที่ชัดเจนขึ้น
เหตุผลที่ 6 คือ ทดสอบแบบ manual ง่ายและเร็วกว่า
เหตุผลนี้เจอเยอะมาก ๆ
คำถามคือ คนเราสามารถทดสอบซ้ำ ๆ
จาก test case แรกไปจนถึง test case ล่าสุดได้ไหม
ถ้าได้ใช้เวลาเท่าไร บ่อยเพียงใด
รวมทั้งยังไม่คุณภาพเช่นเดิม ไม่เปลี่ยนแปลง
แน่นอนว่า manual test ไม่สามารถตอบได้เลย ใช่ไหมนะ ?
เหตุผลที่ 7 คือ ลูกค้าไม่จ่ายเงินสำหรับการเขียน test
เป็นเหตุผลจากคนที่ดูแลเรื่องของค่าใช้จ่ายเลย
เพราะว่าลูกค้าจ่ายการพัฒนา ไม่ได้จ่ายให้กับการเขียน test
ดังนั้นก็ไม่จำเป็นต้องเขียน เป็นเหตุผลที่ดีมาก ๆ
แต่คำถามคือ
จำนวน bug จากการส่งมอบเยอะไหม ?
ค่าใช้จ่ายในการแก้ไข bug และ maintain มันสูงหรือไม่ ?
แก้ไขครั้งหนึ่ง ๆ มีผลกระทบต่อการส่วนอื่น ๆ เยอะหรือไม่
หรือไม่รู้เลย จนกว่าลูกค้าจะแจ้งกลับมา
เหตุผลที่ 8 คือ code ชุดนี้นิดเดียวเอง ไม่ต้อง test ก็ได้
ผ่าน ๆ ไปก่อน หรือบางครั้งอาจจะบอกว่า
เดี๋ยวกลับมาเขียนก็ได้
มั่นใจได้เลยว่า ไม่มีทางกลับมาเขียนแน่นอน จนกว่าจะมีปัญหาเกิดขึ้น
เหตุผลที่ 9 คือ เรามี Tester/QA อยู่แล้ว ให้เขาทำหน้าที่ของเขาไป ไม่ใช่หน้าที่ของเรา
แบบนี้เป็นปัญหาทั้งระดับตัวบุคคล ทีมและองค์กรเลย
ว่าเราจะทำงานกันแบบนี้จริง ๆ หรือ ?
เหตุผลที่ 10 คือ เขียนไม่เป็น
เป็นเหตุผลที่ดี ที่ทีมควรจะต้องมีการฝึกและแบ่งปันความรู้กัน
เพื่อให้สามารถเริ่มเขียนได้
เริ่มจากบอกว่า เราไม่รู้อะไร จะเป็นการเริ่มต้นการเรียนรู้ที่ดีมาก ๆ
วันนี้คุณเขียน test แล้วหรือยัง ?
อย่าสร้างภาระให้แก่คนอื่นเลย
