จากบทความเรื่อง System tests have failed ที่เขียนโดย DHH หรือ คุณ David Heinemeier Hansson
ทำการเขียนเรื่อง System test ของระบบ HEY.com
ซึ่งมีมากกว่า 300 ตัวพบว่า
ผลลัพธ์ที่ได้มันช่วยทดสอบระบบได้ดี มีความมั่นใจ
แต่เมื่อมีเยอะ ๆ แล้ว มันช้า พังง่าย (broken test)
ผลลัพธ์การทดสอบไม่ถูกต้อง (false negative เยอะ)
ดังนั้นการทดสอบด้วย System test เพียงอย่างเดียว ไม่น่าเป็นคำตอบที่ถูกต้อง
ดังนั้นเรามาดูในรายละเอียดกัน
ปัญหาการทดสอบนี้ ก็มีคำถามมาจาก course Fullstack Automation Software Testing ที่ Skooldio เช่นกัน
จึงคิดว่าบทความนี้น่าจะตอบได้ดีทีเดียวครับ
ก่อนอื่นทำความรู้จักกับ System test ของ RoR (Ruby on Rail) กันก่อน
เป็นการทดสอบที่เพิ่มเข้ามา ประกอบไปด้วย
เราอาจจะเรียกได้ว่าเป็น UI testing นั่นเอง หรือเป็นการทดสอบแบบ black box
เป็นการทดสอบในมุมมองของผู้ใช้งานทั่วไป
จึงทำให้เรามีความมั่นใจต่อการทดสอบสูงมาก ๆ
และที่สำคัญคือ ถ้ามีการเปลี่ยน logic หรือ business process ภายในแล้ว
จะไม่กระทบต่อการทดสอบมากนัก หรือ ไม่กระทบเลย
นั่นก็เป็นอีกหนึ่งข้อดีของ System test นั่นเอง
แต่เมื่อจำนวนการทดสอบเยอะมากขึ้น ความซับซ้อนสูงขึ้น
ปัญหาที่ตามมาคือ ความช้า และ พังง่าย
เพราะว่าในฝั่งของ UI ที่พัฒนาด้วยภาษา JavaScript มีปัญหาหลายเรื่อง
ทั้งเรื่องรูปแบบการทำงาน การ load ต่าง ๆ ว่าครบหรือพร้อมหรือไม่
ตรงนี้จากที่ใช้งานมา Selenium จะเจอปัญหาเหล่านี้เยอะมาก ๆ
ทำให้เป็นที่มาของ Flaky test มาอีก
จากประสบการณ์ที่ใช้งานของผมเอง
โดยที่เครื่องมือใหม่ ๆ ของการทดสอบเช่น Cypress และ Playwright มาช่วยลดปัญหานี้ลงไป
จากเป้าหมายหรือหัวใจของ Automated testing คือ
Fast feedback จากการเปลี่ยนแปลงต่าง ๆ
แต่ผลที่ได้กลับตรงกันข้าม
ดังนั้นแนวทางนี้ไม่น่าจะถูกต้อง
จากบทความมีการพูดถึงว่า System test จะ work มาก ๆ สำหรับ Smoke test
ดังนั้นก็ต้องเข้าใจก่อนว่ามันคืออะไรอีก
ตามหลักการแล้ว Smoke test มันคือชุดการทดสอบที่
- ทดสอบ function ที่สำคัญ ๆ ของระบบเป็นหลัก ไม่ใช่ทั้งหมดเหมือน regression test
- ใช้เวลาการทดสอบไม่นาน
- ใช้สำหรับหา critical issue สำหรับ version ใหม่ ๆ ที่ update เข้ามา
ดังนั้น System test ไม่ได้เหมาะกับการทดสอบให้ครอบคลุมการทำงานภายใน
เพราะว่า มันคือ Black box testing
เนื่องจาก System test ที่ทำกันนั้น มีทั้ง Controller test, Domain test เป็นต้น
ตามโครงสร้างของ RoR project ที่เป็น MVC (Model-View-Controller)
ดังนั้นควรแยกออกไปทดสอบใน level อื่น ๆ บ้างจะดีกว่า
ส่งผลให้การทดสอบมีหลาย ๆ แบบ ทั้ง unit และ integration test เป็นต้น
ส่งผลทำให้การทดสอบเป็นไปตามเป้าหมาย คือ เร็ว และ น่าเชื่อถือ
แต่แน่นอนว่า การทดสอบยังไม่ครอบคลุม และ ความน่าเชื่อถือยังไม่มากนัก
นั่นหมายความว่า การทดสอบด้วยคนจริง ๆ ยังคงจำเป็นในขั้นตอนสุดท้ายอยู่ดี
เพราะว่ายังมีอีกหลายเรื่องที่ต้องใช้คน เช่นความรู้สึกต่อระบบเป็นต้น
แต่ก่อนจะให้คนทดสอบ เราก็ต้องมีความมั่นใจในระดับหนึ่งแล้วเสมอ
จะเห็นได้ว่า การทดสอบของระบบนั้นมีหลายรูปแบบ
ต่างมีข้อดีและข้อเสีย
ดังนั้นเราจำเป็นต้องกำหนดเป้าหมายร่วมกันว่าจะทดสอบแบบไหน
สนใจเรื่องความเร็วและน่าเชื่อถือหรือไม่
ต้องมีการ monitor performance อย่างต่อเนื่อง
จากนั้นนำ feedback เหล่านั้นมาปรับปรุงให้ดีขึ้นอย่างต่อเนื่อง
Reference Websites สำหรับคนแก่ !!