หนึ่งในเรื่องที่ร้อนแรงที่สุดของชาว Tech ในช่วงนี้น่าจะหนีไม่พ้นเรื่องระบบไอทีของหน่วยงานระดับประเทศแห่งหนึ่งที่เกิดปัญหาหลังการ Go Live ขึ้นระบบใหม่
ล่าสุด 9arm ก็เพิ่งปล่อยคลิปเกี่ยวกับเรื่องนี้ออกมา
พอดูจบแล้วก็รู้สึกว่านี่คือ Case Study อันล้ำค่ามากสำหรับคนทำงานสาย Quality อย่างพวกเรา
(ล้ำค่าในรูปแบบที่ว่าอย่าไปทำตามนะคะ!)
ทำไมงบประมาณมหาศาลขนาดนี้ ถึงยังเกิดความผิดพลาดในระดับที่กระทบกับชีวิตคนจริงๆ
ในฐานะคนที่ทำงานในสาย Quality อย่างยาวนาน วันนี้พี่กิ่งอยากจะขอสรุปให้ทุกคนฟังว่ามีตรงไหนที่ชวนเอ๊ะบ้าง
เพื่อที่เราจะได้กลับมาถามตัวเองและทีม จะได้ไม่พลาดแบบเดียวกันค่ะ
1️⃣ Functional Test Pass ไม่ได้แปลว่า Go Live ได้!
ในคลิปมีการระบุว่าระบบใหม่ผ่านการเทสมาแล้ว แต่พอเปิดใช้จริง “ล่ม” ซะงั้น
เพราะ “ไม่ได้เทสตอนเอาไปต่อกับ API Gateway ตัวเดิม” และเกิด “คอขวด” ที่รับโหลดไม่ไหว…
ตรงนี้มีสองจุดที่เอ๊ะเลยค่ะ “ไม่ได้เทส” กับ “คอขวด”
- Integration & E2E Test: ในฐานะ QA เราต้องมองภาพกว้างกว่าแค่ Feature ในมือค่ะการทำ Integration Test และ End-to-End Test ในสภาพแวดล้อมที่เหมือนจริงที่สุดคือสิ่งที่จำเป็น
- Test Pyramid: ต่อให้เราทำ Unit Test มาเป็นพันเป็นหมื่นข้อ ได้ระบบที่ทำงานถูกต้องทุกอย่าง แต่ “ไม่ได้เทส” การต่อกับระบบอื่น ก็แปลว่าเราเทสไม่ครบค่ะ เพราะไม่มีอะไรมายืนยันได้เลยว่าเราต่อได้ถูกต้องหรือยัง ซึ่งตรงนี้ถ้าเราออกแบบการเทสได้ดี เราจะเทสที่ระดับ Layer ล่างๆ มามากพอแล้ว และตามหลัก Test Pyramid แล้วเนี่ย เราไม่ควรจะต้องเสียเวลาเทส Logic เดิมซ้ำซ้อนอีกค่ะ แต่สิ่งที่ “ต้องทำ” คือการโฟกัสว่าระบบเชื่อมกันได้อย่างถูกต้องเมื่อนำมาประกอบร่างกันก็พอ (ใครยังไม่รู้จัก Test Pyramid รอก่อนนะคะ เดี๋ยวพี่กิ่งจะมาเล่าให้ฟังในโพสต่อๆ ไป)
- Load Test: ในระบบที่ต้องรองรับผู้ใช้งานเป็นหลักล้านคน การทำ Load Test หรือ Performance Test เป็นเรื่องที่สำคัญมากๆ เพราะระบบที่ทำงานถูกต้อง แต่ทำงานไม่ได้เมื่อเจอ Traffic จริง ก็ถือว่าเทสไม่ผ่านอยู่ดี
2️⃣ Data Migration: ความผิดพลาดที่กลายเป็นความทุกข์ของคนจริง
ประเด็นเรื่องข้อมูลผู้ประกันตนผิดพลาดหลังจาก Migration เช่น เลขบัตรประชาชนไม่ตรง หรือ ข้อมูลหาย เป็นเรื่องที่ไม่ควรเกิดขึ้นที่สุดเลยค่ะ เพราะนี่ไม่ใช่แค่บั๊กของแอพ แต่มันคือสิทธิการรักษาพยาบาล หรือเงินที่ใช้ประทังชีวิตของคนคนหนึ่ง
- Data Validation: การเขียนโค้ด Data Migration ควรจะมีกระบวนการ Data Validation ที่เข้มข้นในทุกขั้นตอน เพราะนี่คือสิ่งที่ “ผิดพลาดไม่ได้” ความผิดพลาดอาจจะหมายถึงข้อมูลของผู้ประกันตนสลับกัน ทำให้คนเห็นข้อมูลของคนอื่นซึ่งควรจะเป็นความลับ หรืออาจจะหมายถึงตัวเลขเงินสมทบของคนบางคนที่หายไป
- Data Integrity: เราต้องตรวจสอบ Data Integrity ทั้งก่อนและหลังย้ายข้อมูล และด้วยปริมาณมหาศาลของข้อมูล ควรต้องมีสคริปต์ตรวจสอบแบบอัตโนมัติด้วยค่ะ อัตโนมือไม่เอานะคะ ไม่รู้จะต้องใช้แรงงานคนมากมายขนาดไหนถึงจะตรวจสอบเสร็จ
3️⃣ Parallel Run แบบใด ทำไม Data คนละชุด!!
การ Migrate ระบบที่มีอยู่แล้วไประบบใหม่ เลี่ยงไม่ได้ที่จะต้องมีช่วงที่รันระบบเก่าคู่ไปกับระบบใหม่ เพราะเป็นวิธีที่จะช่วยลดความเสี่ยงได้ดีที่สุด
แต่ในเคสนี้กลับใช้ไม่ได้ เพราะระบบใหม่ใช้ Database ที่มีข้อมูลเก่าย้อนไปถึงเดือนสิงหาคม (เพราะจะ Migrate อีกรอบก็ใช้เวลานาน) ส่วนระบบเก่ามีข้อมูลอัพเดตถึงปัจจุบัน
- คำถามคือ “แล้วพี่เทสอะไร” นี่คือการเทส Functional เฉยๆ ที่ตรวจสอบไม่ได้ว่าผลลัพธ์ออกมาถูกต้องหรือไม่
- Expected Result: เทสเคสที่ดีจะต้องสามารถระบุ Expected Result ที่ชัดเจนได้ด้วยนะคะ ไอ้ประเภทที่เขียน Expected ว่า “ระบบใช้งานได้ถูกต้อง” เราจะไม่ทำแบบนั้นนะคะ!
- Input/Output: เพราะฉะนั้นการทำ Parallel Run ควรจะต้องเทสด้วยชุดข้อมูลที่เหมือนกัน Input เดียวกัน Output ควรจะออกมาเหมือนกันทั้ง 2 ระบบ
ถ้าข้อมูลมีขนาดใหญ่เกินกว่าที่จะ Sync ทุกวัน ก็ควรจะมีระบบที่ดึงเฉพาะข้อมูลใหม่เข้ามา และทำ Automation Test เพื่อยืนยันความถูกต้องของข้อมูลชุดนั้น
จริงๆแล้ว ปัญหาเหล่านี้ป้องกันได้ด้วยคำถามของ QA ตั้งแต่เริ่มออกแบบระบบเลยค่ะว่า “เราจะเทสตรงนี้ได้ยังไง”
ถ้ามีใครซักคนถามขึ้นมาก็อาจจะเกิดการพูดคุยกันเพื่อแก้ปัญหานี้การ Sync Data ที่เกิดใหม่ไปแล้ว
4️⃣ Root Cause Analysis คือสิ่งที่สำคัญมากกกกกกกกกกก
อีกประเด็นที่น่ากังวลที่สุดคือ เมื่อเจอข้อมูลผิดพลาด ทีมงานกลับต้องรอให้มีคนแจ้งเข้ามาแล้วค่อย “เข้าไปแก้ Manual ทีละราย” โดยที่ยังไม่รู้ว่าสาเหตุที่แท้จริงมาจากตรงไหน
- Stop The Loop: พอเราไม่รู้ว่าปัญหาเกิดจากตรงไหน เราก็จะไม่รู้ว่าจะแก้มันยังไงเช่นกัน และก็จะบอกไม่ได้ด้วยว่าข้อมูลที่พังมีอีกเยอะแค่ไหน หรือถ้าต้อง Migrate ใหม่อีกรอบปัญหาเดิมจะเกิดซ้ำมั้ย
- RCA Process: เมื่อเกิด Issue (โดยเฉพาะ Production Issue) ต้องทำ Root Cause Analysis (RCA) เสมอ เราจะต้องรู้ว่าปัญหานี้เกิดมาจากตรงไหน ไม่ใช่แค่โค้ดบรรทัดไหน แต่ต้องรู้ว่ามันหลุดออกมาได้ยังไง เกิดจาก Process ที่ผิดพลาด หรือเกิดจากความเข้าใจที่ไม่ตรงกัน และที่สำคัญคือตอนทำเทสเราพลาดตรงไหนไปถึงไม่เจอปัญหานี้
- Blameless Culture: เราทำ RCA เพื่อที่เราจะได้รู้ถึงสาเหตุและป้องกันไม่ให้เกิดขึ้นอีกนะคะ ไม่ใช่เพื่อหาตัวคนที่ทำพลาด แบบนั้นห้ามทำเด็ดขาด! 🙅♀️
✨ การสร้างระบบที่มีคุณภาพ ไม่ใช่เรื่องของงบประมาณเพียงอย่างเดียว
แค่ทุ่มงบไปเยอะๆ ไม่ได้แปลว่าจะได้ของดีเสมอไป
แต่มันคือเรื่องของ “ความใส่ใจในคุณภาพ” ในทุกกระบวนการ
และทุกจุดของการเชื่อมต่อทั้งระหว่างระบบและระหว่างคน รวมไปถึงการมีกระบวนการเทสที่รัดกุม
งบ 850 ล้านอาจซื้อซอฟต์แวร์ราคาแพงมาได้ แต่ซื้อ “ความไว้วางใจ” จากผู้ใช้งานคืนมาไม่ได้แน่ๆ ถ้าเราไม่ให้ความสำคัญกับ Quality ตั้งแต่วันแรก
แล้วทุกคนล่ะคะ เคยเจอเหตุการณ์ลุ้นระทึกตอน Go Live กันบ้างมั้ย (เชื่อว่ามีทุกคน!)
ใครมีเรื่องอยากแชร์สามารถมาแลกเปลี่ยนกันได้นะคะ