อ่านหนังสือเจอเรื่องของ Testing in Production environment (TiP)
สำหรับการพัฒนา software
หลาย ๆ คนอาจจะมองว่ามันเป็นเรื่องตลก
ใครกันจะกล้าทำกันแบบนั้น
นี่มัน Production environment เชียวนะ !!
มันไม่น่าจะเป็นสิ่งที่ถูกต้อง
หรือคนจริงต้องทดสอบบน production กัน

ในการพัฒนา software นั้น

ยิ่งเราเลื่อนการทดสอบไปนานเท่าไร หลังจากที่พัฒนาหรือสร้างมันขึ้นมา
นั่นเป็นสัญญาณที่บ่งบอกว่า
สถานะของระบบงานมันไม่ค่อยดีแน่ ๆ
หรือหนักกว่านั้น มันสะท้อนถึงปัญหาของการพัฒนาและทดสอบระบบ
แสดงผลดังภาพนี้

https://watirmelon.blog/2015/05/04/extensive-post-release-testing-is-sign-of-an-unhealthy-testing-process/

สิ่งที่น่าสนใจคือ 

เมื่อเราทดสอบบ่อย ๆ ไม่ได้
ดังนั้นเรามักจะทดสอบเป็น phase
รอให้การพัฒนาเสร็จก่อน แล้วจึงทดสอบ
ผลที่ได้กลับมาคือ จำนวน bug หรือข้อผิดพลาดเพียบ
จากนั้นก็ทำการแก้ไข และ ทดสอบวนไปเรื่อย ๆ
คำถามคือ ใช้เวลาเยอะไปไหม ?

ยังไม่พอ เนื่องจากการทดสอบระบบงานมีหลายกลุ่ม

ดังนั้นเราจึงมี environment ที่หลากหลาย  ยกตัวอย่างเช่น

  • Dev สำหรับทีมพัฒนา
  • QA/Test สำหรับทีม QA และ Tester
  • CI สำหรับระบบ Continuous Integration ซึ่งทำงานแบบอัตโนมัติ
  • Pre-prod สำหรับก่อนขึ้น production
  • Production นี่แหละของจริง

ปัญหาที่มักพบเจอ หรือ ตลกร้ายที่ไม่ค่อยพูดกัน
หรือพูดแล้วก็ยิ้ม ๆ แต่ไม่แก้ไข (จะมีข้ออ่้างมากมาย เพื่อไม่แก้ไข) คือ
ทุก ๆ  environment จะผ่านทั้งหมด ยกเว้น Production !!
คำถามคือ มี environment ต่าง ๆ ไว้ทำไม ?
นี่มันคือการเล่นปาหี่กันชัด ๆ
ใช่ไหมนะ ?

ถ้าเป็นแบบนี้ก็มี Production environment อย่างเดียวก็พอดีไหม ?

ว่าด้วยเรื่องของ Testing in Production นั้น

ทำให้นึกถึงที่มาคือ การทดสอบเสื้อกันกระสุน ว่าสามารถใช้งานได้จริง ๆ ไหม ?
ผลการทดสอบได้ผลเพียง 2 อย่างเท่านั้นคือ
ไม่ตายก็รอด แสดงดังรูป

https://davidwalsh.name/production-testing

ลองเทียบกับระบบงานของเราสิว่า 
ผลที่ออกมามันจะเป็นอย่างไร ?
ไม่น่าจะออกมาดีใช่ไหม ?

แต่ทำไมถึงมีการพูดถึงเรื่อง 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 หรือ บทบาทของตนเองเพียงอย่างเดียวหรือไม่ ?
มองในภาพรวมของระบบงานหรือไม่ ?
มีการทำงานร่วมกัน แนวทางเดียวกันหรือไม่ ?
มีการนำข้อมูลต่าง ๆ มาวิเคราะห์และใช้ในการตัดสินใจว่าจะทำอะไรต่อไปหรือไม่ ?

สวัสดี !!!