ปัญหาหนึ่งที่เกิดขึ้นบ่อยและเยอะมาก ๆ คือ
ในขั้นตอนการส่งมอบระบบงานมีการทดสอบเยอะมาก ๆ
ทั้งแบบ manual และ automation
แต่เมื่อ deploy ระบบงานขึ้น production แล้ว
กลับพบว่าผู้ใช้งานเจอปัญหาเยอะมาก ๆ
หรือส่วนต่าง ๆ ของระบบงานมักจะเจอปัญหาบ่อยครั้ง
โดยนักพัฒนาอาจจะบอกว่า
code ที่พัฒนานั้นมีคุณภาพที่ดีมาก ๆ
code ที่พัฒนานั้นมี unit test ที่ครอบคลุมมาก ๆ
นั่นเป็นเรื่องที่ดีในแต่ละส่วนการทำงาน
แต่สิ่งที่ต้องสนใจมากขึ้นคือ integration test
เนื่องจากในระบบของเรานั้นมักจะประกอบด้วยส่วนการทำงานจำนวนมาก
ทั้ง ui, api, database, service 1, 2, 3 … อื่น ๆ อีกมากมาย
การ integrate หรือ การทำงานร่วมกันแต่ละส่วนเป็นไปตามที่คาดหวังหรือไม่ ?
เพื่อลดการ mock หรือ จำลองส่วนต่าง ๆ ลงไป
ยังไม่พอในแต่ละ feature นั้น
ต้องผ่านการทำงานกี่ส่วน
ต้องผ่านการทำงานกี่ระบบ
ได้ทำงานทดสอบ และ monitoring ดูหรือไม่ ?
ในส่วนนี้จะเรียกว่า feature/function test
และใน level บนสุดคือ End-to-End test
เป็นการทดสอยในมุมมองของผู้ใช้งานต่อระบบ
และทดสอบสิ่งที่เกี่ยวข้องต่อระบบแบบ end-to-end นั่นเอง
เพื่อเป็นมุมมองของผู้ใช้งานอย่างแท้จริง (เฉพาะ feature ที่สำคัญต่อผู้ใช้งาน)
ง่าย ๆ คือ ผู้ใช้งานต่าง ๆ ที่เข้ามายังระบบของเรา เขาจะใช้ feature อะไรบ้าง ?
นั่นคือ end-to-end ของการทดสอบนั่นเอง
ต้องทำการ balance หรือ หาจุดที่สมดุลของการทดสอบ
ทั้ง Pyramid testing
ทั้ง Trophy testing
เพื่อให้ทีมสามารถทำงานร่วมกันได้ง่ายขึ้น มีความเข้าใจร่วมกัน
ลงมือทำ และ วัดผลของการทำงานอย่างต่อเนื่อง
และใช้ตัววัดเดียวกัน เช่น ทำไปแล้วลดปัญหาบน production หรือไม่ เท่าไร ?
ยังไม่พอ เรื่องของ environment ในการทดสอบนั้น
เหมือนหรือคล้ายกับ production หรือไม่
บ่อยครั้งพบว่ามันเหมือนอยู่กันคนละโลก !!
ดังนั้นควรต้องปรับปรุงให้ใกล้เคียงกันในแง่โครงสร้าง
เพราะว่า เรากำลังทดสอบ function การทำงาน
ดังนั้นสามารถใช้แนวทางของ virtualization และ containerization มาช่วยได้
เพื่อทำให้การสร้าง environment สำหรับการทดสอบง่าย และ ราคาถูกลงได้
รวมทั้งยังคล้ายกับ production มากที่สุด
ซึ่งจะช่วยให้เราเจอปัญหาได้รวดเร็วมากขึ้น
หรือต้องปรับเอาแนวคิด Test in Production (TiP) เข้ามาช่วยก็ดี
ต้อง balance การทดสอบในส่วนต่าง ๆ ให้ดี
เพราะว่า มันคือการสร้างความมั่นใจ
ที่มีต่อ code
ที่มีต่อ function
ที่มีต่อ service
ที่มีต่อ product หรือ ระบบงานนั่นเอง
และยังต้องมีการทดสอบอย่างต่อเนื่อง เพื่อให้ได้รับบ feedback ที่รวดเร็ว
ไม่ใช่ต้องมารอทดสอบ เมื่อไม่ใครบอกว่าพร้อมทดสอบแล้ว (แบบนี้มันต้องรอกัน เสียเวลามาก ๆ)
ลองคิดดูว่า ถ้าเรามีความมั่นใจต่อระบบมาก ๆ คงไม่มีการทดสอบแน่ ๆ
ดังนั้น หมั่นตรวจสอบ feedback จาก process การส่งมอบระบบงานอยู่อย่างเสมอ
ว่าช่วยแก้ไขปัญหา ลดปัญหา หรือ สร้างปัญหากันแน่
เพื่อทำการปรับปรุงให้ดียิ่งขึ้นอย่างต่อเนื่อง (Continuous Improvement)
และเราจะไม่ผิดซ้ำที่เดิม
และปริมาณบ่อยครั้งไม่ได้บอกถึงคุณภาพ ถ้าทำการวางแผนไม่ดี
นี่เป็นแนวคิดหลักของ Continuous Integration และ Continuous Delivery
