จาก blog เรื่อง Espresso Test Record สำหรับการทดสอบ UI Test บน Android App
ทำให้นึกถึงเรื่อง ทำไมเครื่องมือแบบ Record and Playback
มันถึงทำให้การทดสอบแบบอัตโนมัติมีปัญหาเสมอ
บางคนถึงกับบอกว่า มันไม่ได้ช่วยอะไรเลย
แถมยังกลับมาทำร้ายกันอีก !!
หนักไปกว่านั้นชุดการทดสอบที่ได้มากลับกลายเป็นภาระในการดูแลรักษาอีก
มันจริงหรือเปล่านะ ?
จากประสบการณ์ที่ผ่านมาของการใช้เครื่องมือทดสอบแบบ Record and Playback
พบว่าถ้าระบบงานไม่มีการเปลี่ยนแปลงเลยมันจะดีมาก ๆ
แต่ถ้าระบบมีการเปลี่ยนแปลงบ่อย ๆ
เช่น element ต่าง ๆ ของหน้าจอมีการเปลี่ยนแปลง เพิ่มลบ
สิ่งที่เกิดขึ้นคือ เราจะต้องทำการบันทึกใหม่
บ่อยครั้งเกิดชุดการทดสอบในหน้าเดิม ๆ เยอะมาก ๆ
นั่นคือ เกิด duplication test ขึ้นมามากมาย
บ่อยครั้งพบว่า UI Test นั้นมันพังบ่อยมาก ๆ (Fragile test/Broken test)
ทั้งจากการเปลี่ยนแปลงต่าง ๆ
ทั้งจากความไม่เสถียรของระบบ
ทั้งจากความไม่เสถียรของเครื่องมือทดสอบ
รวมทั้งชอบทำการทดสอบเมื่อระบบงานเสร็จทั้งหมด
งานมันจึงเยอะ
ระบบมันจึงแยะ
ปัญหาก็เพียบสิครับพี่น้อง
แถมคนทดสอบกับคนพัฒนาและคนให้ requirement ไม่คุยกันอีก !!
เมื่อลองไปค้นหาข้อมูลเพิ่มเติม
ก็เจอ Paper เรื่อง Why do Record/Replay Tests of Web Applications Break?
ได้ข้อสรุปที่น่าสนใจว่า
เมื่อ locator ต่าง ๆ บนหน้า UI เปลี่ยนแปลงชุดการทดสอบพังไปมากกว่า 70%
ยังไม่พอนะ locator ต่าง ๆ บนหน้า UI ยังซ้ำกัน หรือ Duplication กันอีกด้วย
ดังนั้นสิ่งที่ควรแก้ไขโดยด่วนสำหรับ Web Application คือ
- อย่าใช้ XPath ในการเข้าถึง locator หรือ element ต่าง ๆ
- ให้ใช้ id หรือ attribute เข้ามาช่วย
- อย่าตั้งชื่อที่ซ้ำซ้อน
ซึ่งเครื่องมือแบบ Record and Playback นั้น
ทำให้เราได้ชุดการทดสอบแบบอัตโนมัติที่พังง่ายมาก ๆ
ดังนั้นจึงมีคำแนะนำว่า อย่าใช้เครื่องมือเหล่านี้เลย
ลด ละ เลิกเถอะนะ !!
ถ้าจะใช้ ก็ให้ใช้เท่าที่จำเป็น
เช่นใช้ตรวจสอบว่า ระบบสุดท้ายแล้วมันทำงานได้อย่างถูกต้อง
และตรงกับสิ่งที่ได้ตกลงกันไว้แล้วเท่านั้น
และใช้ตรวจสอบการทำงานของระบบเมื่อมีการเปลี่ยนแปลง
สุดท้ายแล้ว
ผมมีความเชื่อว่าเครื่องมือเหล่านี้มันดีมีประโยชน์
ถ้าเราใช้อย่างถูกต้องและเหมาะสม
แต่ถ้าเราไม่เข้าใจ และ ใช้ในทางที่ผิด ๆ
ผลที่ตามมามันก็แย่เช่นกัน
ดังนั้นให้คิดก่อนทำเสมอ ว่าสิ่งที่ทำลงไปมันคุ้มค่าต่อการลงทุนหรือไม่ ?
ไม่ใช่เอะอะก็ซื้อเครื่องมือมากองหรือรอไว้
แล้วก็มาบอกว่า ให้ช่วยใช้มันหน่อยนะ ไหน ๆ ก็ซื้อมาแล้ว !!
ผมเชื่อว่าเราต้องทำการสร้างระบบที่ทดสอบได้ง่าย (Testability in your mind)
ซึ่งมันเป็นสิ่งที่ดีกว่าการเลือกหรือสร้างเครื่องมือมาช่วยทดสอบ
ไม่เช่นนั้นเราจะจมไปกับเครื่องมือนั้น ๆ
โดยไม่สนใจ และ ใส่ใจเลยว่า ระบบที่สร้างขึ้นมามันทดสอบได้ง่ายหรือไม่
ถ้ายังงง และ มีข้อสงสัยให้กลับไปอ่านหนังสือเรื่อง The Way of Web Test
Reference Websites
http://www.software-testing.com.au/blog/2016/06/01/why-record-playback-almost-never-works-and-why-almost-nobody-is-using-it-anyway/
https://watirmelon.com/2016/06/01/test-automation-why-record-and-replay-fails/
https://blog.acolyer.org/2016/05/30/why-do-recordreplay-tests-of-web-applications-break/
