ปัญหาของการทดสอบที่ช้า …

เมื่อเริ่มทำการทดสอบระบบ
ไม่ว่าด้วยการกดปุ่ม
หรือ พิมพ์คำสั่งใน command line
หรือ สั่งให้ทำผ่าน e-mail ก็ตาม

คำถาม
ต้องรอนานเท่าไร กว่าจะได้ผลการทดสอบกลับมา ?
คำตอบ
ถ้าเวลาที่รอหน่วยเป็นนาทีขึ้นไป นั่นแสดงว่า การทดสอบของคุณมีปัญหาแล้วนะ !!

ใครมีประสบการณ์กับการทดสอบที่มันช้าๆ บ้าง ?

ไม่ว่าจะเป็นการทดสอบจากใครก็ตาม เช่น
จากทางทีมพัฒนา
จากทางทีม QA
จาก …

ความเจ็บปวดที่ได้รับเหมือนกันก็คือ
รอนานมากๆ บางคนถึงกับนอนรอกันเลยทีเดียว
ผลที่ตามมาคือ เราไม่สามารถทดสอบได้บ่อยๆ
จึงไม่แปลกเลยว่า ทำไมเรามักจะทดสอบ
ก็ต่อเมื่อมีคนบอกว่า พัฒนาเสร็จแล้วนะ (มี bug เมื่อไร ก็ส่งกลับมา 24×7 !!)

นั่นแสดงว่า
เราได้ทำลายประโยชน์ของการทดสอบไปโดยสิ้นเชิง
รวมทั้งเราจะได้รับ feedback กลับมาช้ามาก
ทำให้การแก้ไขก็เป็นไปได้ช้าเช่นกัน !!
ทำให้ feedback ที่ได้กลับมาแต่ละครั้ง มันใหญ่ เยอะแยะไปหมด !!
ซึ่งมันคือ ปัญหา classic ของการพัฒนา software เลยใช่ไหม ?
แต่เราก็ยังก้มหน้าก้มตาทำมันต่อไป …

คำถาม
แล้วเราจะทำอย่างไรดีล่ะ ?

การทดสอบที่ช้าคืออะไร ?

โดยจะเน้นที่ Automated test เป็นหลักนะ

ส่วน manual test ก็คงได้ไปจัดการ หรือ เตรียมตัวการทดสอบให้ดีขึ้น
เช่น แบ่งการทดสอบย่อยๆ และ ทดสอบบ่อยๆ แทน
แต่ถ้าทนไม่ได้ คงต้องวิ่งมาหา Automated test เข้าสักวัน

จากหนังสือ Working Effectively with Legacy code บอกไว้ว่า

A unit test that takes 1/10th of a second to run is a slow unit test.

มันไม่ใช่เรื่องตลกเลยนะ
ลองคิดดูสิว่า
ถ้าคุณมี 1,000 tests แล้วจะใช้เวลาถึง 15 นาทีเลยนะ !!
ซึ่งมันช้ามากๆ ส่งผลต่อ feedback เยอะ

ดังนั้นถึงเวลาที่ต้องจัดการแก้ไขได้แล้ว ..

คำถาม
แล้วเราจะทำอย่างไรดีล่ะ ?

เริ่มต้นด้วยการหาจุดที่ทำให้การทดสอบช้านะสิ

หาง่ายๆ จากรายงานของการทดสอบนั่นแหละ
เนื่องจากแต่ละ test case มันจะมีเวลาการทำงานให้ชัดเจน

ตัวอย่างจาก IntelliJ IDEA

คำอธิบาย
ใน Test HelloTest3 นั้นใช้เวลาไป 0.5 วินาที ซึ่งคือ Slow test นั่นเอง

หลังจากที่ทำการดูรายงานต่างๆ แล้ว มักพบว่าปัญหาของความช้า

ประกอบไปด้วย

• ทำการทดสอบกับ Database
• ทำการทดสอบผ่าน Network
• ทำการทดสอบกับ external system/component ที่เราไม่สามารถควบคุมได้
• มีการทำงานแบบ Aynchronous
• มี test ซ้ำๆ กันมากเกินไป

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

เราจะทำการแก้ไขปัญหาอย่างไรดี ?

เริ่มจากการแยกกลุ่มของการทดสอบที่ช้าๆ ออกมาก่อน
อาจจะตั้งชื่อว่า

• Slow test
• Network test
• Database test
• Acceptance test

แนะนำว่า
อย่าทำการลบการทดสอบเหล่านี้ออกไปนะ !!
หรือทำการ ignore มันล่ะ !!

จากนั้นให้ทำการแก้ไขการทดสอบเหล่านั้นให้มันทำงานเร็วขึ้น
โดยในฝั่งนักพัฒนาจะเรียกว่าการ refactor code นั่นเอง
ส่วนมากจะนำแนวคิด Test double และ Fake database มาใช้

ถ้าไม่มีระบบ Continuous Integration .. ถึงเวลาที่ต้องมีแล้วนะ !!

เพราะว่า เมื่อเรามีกลุ่มการทดสอบหลายกลุ่ม เช่น

• Fast test
• Slow test
• Database test

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

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

ระบบนี้มันคือ Social ของ Developer
ที่จะแอบบังคับให้ developer ทุกๆ คนต้องทำการทดสอบทุกๆ กลุ่ม
ก่อนที่จะ check in code เข้ามายัง repository กลางนั่นเอง

สุดท้ายแล้ว

ต้องทำให้การทดสอบมันเร็วอยู่ตลอดเวลาครับ
เพื่อให้เรารู้สุขภาพของ software ที่สร้างอยู่อย่างเสมอว่าเป็นอย่างไร

ในหน้าที่ความรับผิดชอบของ developer นั้น
ไม่ใช่เพียงแค่เขียน code เท่านั้น
คุณยังต้องทำการทดสอบด้วยนะครับ

ปัจจุบัน การทดสอบของคุณใช้เวลานานเท่าไรกันนะ ?