อ่านหนังสือเจอเรื่องของ Testing in Production environment (TiP)
สำหรับการพัฒนา software
หลาย ๆ คนอาจจะมองว่ามันเป็นเรื่องตลก
ใครกันจะกล้าทำกันแบบนั้น
นี่มัน Production environment เชียวนะ !!
มันไม่น่าจะเป็นสิ่งที่ถูกต้อง
หรือคนจริงต้องทดสอบบน production กัน
ในการพัฒนา software นั้น
ยิ่งเราเลื่อนการทดสอบไปนานเท่าไร หลังจากที่พัฒนาหรือสร้างมันขึ้นมา
นั่นเป็นสัญญาณที่บ่งบอกว่า
สถานะของระบบงานมันไม่ค่อยดีแน่ ๆ
หรือหนักกว่านั้น มันสะท้อนถึงปัญหาของการพัฒนาและทดสอบระบบ
แสดงผลดังภาพนี้
สิ่งที่น่าสนใจคือ
เมื่อเราทดสอบบ่อย ๆ ไม่ได้
ดังนั้นเรามักจะทดสอบเป็น phase
รอให้การพัฒนาเสร็จก่อน แล้วจึงทดสอบ
ผลที่ได้กลับมาคือ จำนวน bug หรือข้อผิดพลาดเพียบ
จากนั้นก็ทำการแก้ไข และ ทดสอบวนไปเรื่อย ๆ
คำถามคือ ใช้เวลาเยอะไปไหม ?
ยังไม่พอ เนื่องจากการทดสอบระบบงานมีหลายกลุ่ม
ดังนั้นเราจึงมี environment ที่หลากหลาย ยกตัวอย่างเช่น
- Dev สำหรับทีมพัฒนา
- QA/Test สำหรับทีม QA และ Tester
- CI สำหรับระบบ Continuous Integration ซึ่งทำงานแบบอัตโนมัติ
- Pre-prod สำหรับก่อนขึ้น production
- Production นี่แหละของจริง
ปัญหาที่มักพบเจอ หรือ ตลกร้ายที่ไม่ค่อยพูดกัน
หรือพูดแล้วก็ยิ้ม ๆ แต่ไม่แก้ไข (จะมีข้ออ่้างมากมาย เพื่อไม่แก้ไข) คือ
ทุก ๆ environment จะผ่านทั้งหมด ยกเว้น Production !!
คำถามคือ มี environment ต่าง ๆ ไว้ทำไม ?
นี่มันคือการเล่นปาหี่กันชัด ๆ
ใช่ไหมนะ ?
ถ้าเป็นแบบนี้ก็มี Production environment อย่างเดียวก็พอดีไหม ?
ว่าด้วยเรื่องของ Testing in Production นั้น
ทำให้นึกถึงที่มาคือ การทดสอบเสื้อกันกระสุน ว่าสามารถใช้งานได้จริง ๆ ไหม ?
ผลการทดสอบได้ผลเพียง 2 อย่างเท่านั้นคือ
ไม่ตายก็รอด แสดงดังรูป
ลองเทียบกับระบบงานของเราสิว่า
ผลที่ออกมามันจะเป็นอย่างไร ?
ไม่น่าจะออกมาดีใช่ไหม ?
แต่ทำไมถึงมีการพูดถึงเรื่อง Testing in Production กันเยอะ
มันเป็นแนวคิดที่มองทั้งส่วนของการทดสอบ
และส่วนของการส่งมอบระบบงานที่รวดเร็ว
แน่นอนว่าต้องรักษาสมดุลทั้งสองอย่างให้ดี
ไม่ให้การทดสอบมาขัดขวางการส่งมอบ
พร้อมทั้งไม่ส่งมอบสิ่งที่แย่ออกไปด้วย
(แต่ถ้าผิดต้องรู้อย่างรวดเร็ว เพื่อแก้ไขได้อย่างทันที)
นั่นคือ การเน้นที่ความเร็วกับคุณภาพต้องไปพร้อม ๆ กัน
การที่จะส่งมอบระบบงานได้บ่อย ๆ
ขนาดของสิ่งที่ส่งมอบก็ต้องไม่ใหญ่ด้วย
จากนั้นต้องได้ feedback จากผู้ใช้งานจริง ๆ ว่าเป็นอย่างไร
รวมทั้ง operation ต่าง ๆ ที่ต้องจัดการ
แนวทางนี้อาจจะมีปัญหาเกิดขึ้นแน่นอน
แต่มั่นใจได้ว่า มันจะไม่เยอะมากและสามารถเอามันอยู่ได้ !!!
ค่อย ๆ เรียนรู้ และ แก้ไขกันไป
แต่การนำแนวคิดนี้มาใช้ จำเป็นต้องมีกระบวนการทำงานเช่นกัน
ไม่ใช่จะไป deploy และ ทดสอบบน production กันอย่างเดียว
ยกตัวอย่างเช่น
- A/B testing
- Beta testing
- Monitoring as testing
ซึ่งแนวทางนี้จะสำเร็จได้หรือไม่นั้น
ทั้งทีมพัฒนาและ operation ก็ต้องพูดคุย ร่วมมือและทำงานร่วมกันด้วยอย่างดี
ไม่โยนงานกันไปมา
ตรงนี้จะสะท้อนการทำงานขององค์กรนั้น ๆ อย่างมาก
อีกอย่างที่สำคัญมาก ๆ คือ Automated feedback จาก production
เพื่อช่วยให้เรารู้ปัญหาหรือการทำงานในส่วนงานที่เราสนใจ
ทั้งเรื่องของการ monitoring
ทั้งเรื่องของระบบ alert
ทั้งเรื่องของการวิเคราะห์ event หรือเหตุการณ์ต่าง ๆ ที่เกิดขึ้นในระบบ
ทั้งระบบ logging
ซึ่งทั้งหมดนี้จะต้องช่วยทำให้ทีมเห็นว่า
การทำงานของระบบเป็นอย่างไร
ทั้งในมุมมองของผู้ใช้งานและคนดูแลระบบ
จะเห็นได้ว่าเรื่องของ Testing in Production นั้น มันไม่ใช่แค่แนวคิด
แต่มันยังเป็นการสะท้อนการทำงานขององค์กรอีกด้วยว่าเป็นอย่างไร
ต่างคนต่างทำงานใน role หรือ บทบาทของตนเองเพียงอย่างเดียวหรือไม่ ?
มองในภาพรวมของระบบงานหรือไม่ ?
มีการทำงานร่วมกัน แนวทางเดียวกันหรือไม่ ?
มีการนำข้อมูลต่าง ๆ มาวิเคราะห์และใช้ในการตัดสินใจว่าจะทำอะไรต่อไปหรือไม่ ?
สวัสดี !!!
