ในปัจจุบันนั้น Mobile application นั้นได้เข้ามามีบทบาทสูงมากๆ
ดังจะเห็นได้จากจำนวนผู้ใช้งาน และ จำนวนการ download application ผ่านมือถือ
ดังนั้นบริษัทไหนไม่สนใจเรื่อง mobile เลย คงแปลกน่าดู
ทั้ง iOS และ Android
แต่สิ่งหนึ่งที่หน่วยงาน และ ทีมพัฒนา มักจะปล่อยปะละเลยก็คือ
คุณภาพของ Mobile application ที่ปล่อยออกไป !!
ดังนั้น เรามาดูวิธีการทดสอบสำหรับ mobile กันหน่อยไหม ?
แน่นอนว่าในการทดสอบที่มีประสิทธิภาพนั้น
ควรต้องยึดตามแนวทางของ Test Pyramid
เพื่อเพิ่มความปลอดภัย และ มั่นใจให้กับ app ที่สร้าง ดังรูป
จากรูปการทดสอบนั้น
จะประกอบไปด้วย Unit test, Service test และ Behavior/Acceptance/UI test
ซึ่งการทดสอบแต่ละอย่าง ล้วนมีวิธีการที่ต่างกันออกไป
แต่การทดสอบที่มักมีปัญหาสุดๆ ก็คือ Behavior/Acceptance/UI test
เนื่องจากมันสามารถเกิดข้อผิดพลาดได้ง่าย และ ดูแลรักษายาก
ยังไม่พอนะ มันยังใช้เวลาในการทดสอบนานด้วยสิ
อาจจะกินเวลาไป 30 – 60 นาทีกันเลย
ซึ่งมันไม่ใช่แนวทางที่ดีอย่างแน่นอน !!
จากบทความเรื่อง Building Better Behavior Tests for Mobile Apps
ได้แนะนำวิธีการทดสอบ behavior test ที่มีประสิทธิภาพ
ให้เราได้เรียนรู้ไว้ดังต่อไปนี้
เริ่มจากให้ทำการแบ่ง behavior test ออกเป็นส่วนๆ
เนื่องจากการทดสอบส่วนนี้ จะเป็นการทดสอบส่วนการใช้งานจริงๆ เช่น
การทดสอบผ่าน User Interface ของมือถือ หรือ emulator
ซึ่งมีการทำงานหลายขั้นตอนมากเช่น
- ทำการเปิดเครื่อง
- ทำการติดตั้ง app
- ทำการทดสอบ
ส่งผลให้ใช้เวลาทดสอบนาน
ดังนั้น ก่อนอื่นเราควรมาดูกันหน่อยไหมว่า
Behaviour test เหล่านั้นมันสามารถแยกออกจากกันได้หรือไม่ อย่างไร ?
Unit test นั้นคือส่วนการทดสอบที่เสถียร และ ทำงานเร็วมากๆ
ส่วน behavior test นั้นมันตรงข้ามกันเลย!!
ดังนั้น เราต้องทำการแยก behavior test ออกเป็นส่วนๆ ดังนี้
- Smoke test
- Regression test
- Everything else
โดยทีมพัฒนาจะต้องรู้ และ เข้าใจ กับกลุ่มต่างๆ ด้วยว่ามัน
คืออะไร หมายถึงอะไร และ ทำงานตอนไหน อย่างไร ?
Smoke test
จะถูกเรียกใช้บนเครื่องของ developer หลังจากที่ทำการ run พวก unit test ผ่านหมดแล้ว
จากนั้นก่อนที่ code จะถูก push ขึ้นไปยัง source control (pre-commit)
จะทำการเรียกชุดการทดสอบนี้ขึ้นมา
โดยชุดการทดสอบจะเป็นพวก happy path ต่างๆ ของระบบ
ที่เกี่ยวข้องกับการเปลี่ยนแปลงในครั้งนั้นๆ ด้วยนะ
Regression test
มีการกำหนดเวลาในการทดสอบไว้
เนื่องจากการทดสอบในแต่ละครั้งใช้เวลานาน
เพราะว่าต้องทดสอบในทุกๆ path/flow ทั้ง happy และ fail path
Everything else
คือ happy path ที่จะช่วยยืนยันว่า และ มั่นใจว่า
ระบบยังสามารถทำงานได้อย่างถูกต้อง สำหรับพวก feature หลักๆ ทั้งหลายนะ
ซึ่งจะถูก run แบบอัตโนมัติในระบบ Continuous Integration Server (CI)
หลังจากที่ code ถูก push มายัง source control
รูปแบบการทำงานของการทดสอบเป็นดังรูป
ข้อสำคัญของวิธีการแบ่งการทดสอบแบบนี้ ก็คือ
การให้ความสำคัญระหว่าง ความเร็วในการทำงาน และ
เนื่องจากมันจะตรงข้ามกันเสมอ
ดังนั้นต้องเลือกให้เหมาะสมครับ
แต่ถ้าสามารถทดสอบด้วย unit test ได้
แนะนำให้ไปเขียน unit test เลยนะครับ
