ลูกค้าเป็นแพลตฟอร์มการศึกษาออนไลน์ที่มีบทเรียนแบบโต้ตอบ การบ้าน บัญชีส่วนตัวของนักเรียนและผู้ปกครอง และการชำระเงินออนไลน์ ธุรกิจมีฤดูกาลชัดเจน เดือนกันยายนมีนักเรียนใหม่มากที่สุด หากแพลตฟอร์มหยุดในสัปดาห์แรก ๆ ของปีการศึกษา ก็อาจสูญเสียลูกค้าไปถาวร ไม่มีทีม QA ภายใน นักพัฒนาทดสอบงานระหว่างทำภารกิจอื่น การทดสอบรีเกรสชันก่อนปล่อยเวอร์ชันใช้เวลาสามวัน แต่ยังพลาดสถานการณ์สำคัญ เช่น การชำระเงิน การจองบทเรียน และการเข้าห้องเรียน ลูกค้ามาหาเราหลังเกิดเหตุอีกครั้ง เมื่อข้อผิดพลาดในการชำระเงินทำให้โรงเรียนเสียคำขอสมัครเรียนบางส่วนที่รวบรวมไว้ตลอดฤดูร้อน
สร้างกระบวนการประกันคุณภาพจากศูนย์:
กลยุทธ์ทดสอบที่จัดลำดับตามความเสี่ยงทางธุรกิจ ทำสถานการณ์สำคัญให้เป็นอัตโนมัติ ผสานการตรวจสอบเข้ากับ CI และทดสอบโหลดก่อนช่วงพีกในเดือนกันยายน ข้อจำกัดคือห้ามหยุดการพัฒนา การปล่อยเวอร์ชันยังคงเป็นรายสัปดาห์ และรอเดือนกันยายนไม่ได้
เราไม่ได้เริ่มด้วยการทำการทดสอบอัตโนมัติ แต่เริ่มจากวิเคราะห์ความเสี่ยง: สถานการณ์ใดพังบ่อยที่สุด และข้อผิดพลาดจุดไหนมีต้นทุนสูงที่สุด การทำอัตโนมัติดำเนินตามรายการนี้อย่างเคร่งครัด
- ตรวจสอบคุณภาพ: ทบทวนบั๊กในช่วงหกเดือนที่ผ่านมา สัมภาษณ์ทีม และทำแผนที่สถานการณ์ที่มีปัญหามากที่สุด ได้แก่ การชำระเงิน การจองบทเรียน การเข้าห้องเรียน และการแจ้งเตือนผู้ปกครอง
- เขียนกลยุทธ์การทดสอบ ครอบคลุมระดับการทดสอบ ขอบเขตความรับผิดชอบ definition of done สำหรับฟีเจอร์ และกฎการรายงานบั๊ก ซึ่งใช้ร่วมกันโดยทีมพัฒนาทั้งสามทีม
- ทำเส้นทางสำคัญให้เป็นอัตโนมัติ: สถานการณ์ e2e ด้วย Playwright สำหรับแพลตฟอร์มเว็บ ทดสอบ API สำหรับแบ็กเอนด์ และชุด smoke ก่อนปล่อยทุกเวอร์ชัน
- เพิ่ม QA gate เข้าใน CI ห้ามปล่อยเวอร์ชันหาก smoke test ยังไม่ผ่าน การรีเกรสชันเต็มทำงานทุกคืน และทุกทีมเห็นผลได้ใน GitLab
- ทดสอบโหลดด้วย k6 จำลองทราฟฟิกช่วงพีกในเดือนกันยายน ค้นหาจุดคอขวดและแก้ร่วมกับทีมแบ็กเอนด์ก่อนเริ่มฤดูกาล
- ส่งมอบกระบวนการให้ลูกค้า ทั้งเอกสาร ขั้นตอน และฝึกวิศวกร QA ให้ทำงานกับการทดสอบอัตโนมัติและ pipeline
การตัดสินใจหลักคือจัดลำดับตามความเสี่ยงทางธุรกิจ ไม่ใช่ตามความ “สวยงาม” ของ coverage เราตั้งใจไม่ไล่ตามการทำอัตโนมัติให้ครบ 100% การครอบคลุม 75% ของสถานการณ์สำคัญให้ผลลัพธ์ส่วนใหญ่ เพราะปกป้องเส้นทางที่แพลตฟอร์มใช้หาลูกค้าและสูญเสียลูกค้า ส่วนที่เหลือทดสอบเชิงสำรวจด้วยมือก่อนปล่อยเวอร์ชันสำคัญ
ผลทางเศรษฐกิจหลักคือการเลื่อนเวลาตรวจพบข้อบกพร่องให้เร็วขึ้น บั๊กที่การทดสอบอัตโนมัติใน CI พบมีต้นทุนต่ำกว่าบั๊กที่ผู้ปกครองของนักเรียนพบในโปรดักชันหลายสิบเท่า แพลตฟอร์มเข้าสู่ฤดูกาลด้วยความแข็งแกร่งมากขึ้น และทีมสามารถปล่อยการเปลี่ยนแปลงได้บ่อยโดยไม่กลัว “ผลกระทบวันศุกร์” อีกประโยชน์คือความเชื่อมั่นของธุรกิจ ทีมขายรับปากโรงเรียนพันธมิตรได้อย่างตรงไปตรงมาว่าแพลตฟอร์มจะเสถียรในช่วงรับสมัครสูงสุด
| ตัวชี้วัด | ผลลัพธ์ |
|---|---|
| บั๊กวิกฤตในโปรดักชัน | 5–7 ต่อเดือน → 1–2 ต่อไตรมาส |
| รีเกรสชันก่อนปล่อยเวอร์ชัน | ทำด้วยมือ 3 วัน → ทดสอบอัตโนมัติ 4 ชั่วโมง |
| ช่วงโหลดสูงสุดในเดือนกันยายน | เกิดเหตุทุกปี → 0 เหตุ ไม่มีประสิทธิภาพลดลง |
| ช่วงเวลาที่ตรวจพบข้อบกพร่อง | ส่วนใหญ่พบในโปรดักชัน → การทดสอบอัตโนมัติพบก่อนปล่อย |
ตัวชี้วัดนำมาจากเอกสารต้นฉบับของกรณีศึกษา ระบุช่วงเวลาไว้เมื่อแหล่งข้อมูลระบุ
- บั๊กวิกฤตต่อไตรมาส (เดิม 5–7 ต่อเดือน)
- 1–2
- รีเกรสชันด้วยการทดสอบอัตโนมัติ (เดิมทำมือ 3 วัน)
- 4 ชม.
- ของสถานการณ์สำคัญมีการทดสอบอัตโนมัติครอบคลุม
- 75%
- เหตุขัดข้องในช่วงพีกเดือนกันยายน
- 0
มาตราส่วนเพื่อการอธิบาย: แปลง 3 วันเป็น 72 ชั่วโมง ความยาวแท่งของช่วงบั๊กต่อเดือนคูณสามเพื่อเทียบเป็นรายไตรมาส โดยเปรียบเทียบค่าขอบบน
- 01คอมมิต
- 02ชุด smoke testไม่ผ่านสีเขียวก็ไม่ปล่อย
- 03ปล่อยเวอร์ชันทุกสัปดาห์
- 04ทุกคืนรีเกรสชันเต็มรูปแบบ
ขั้นตอนถัดไปที่เราแนะนำให้แพลตฟอร์ม:
- การทดสอบ visual regression เพื่อตรวจเลย์เอาต์ของบทเรียน อีเมล และบัญชีส่วนตัวโดยอัตโนมัติ
- โรงงานข้อมูลทดสอบ เพื่อสร้างนักเรียน กลุ่ม และการชำระเงินที่สมจริงสำหรับการทดสอบแต่ละครั้ง
- QA ในโปรดักชัน: ใช้ feature flag และ canary release เพื่อทยอยเปิดใช้ฟังก์ชันใหม่
เราเลิกกลัวการปล่อยเวอร์ชันแล้ว เมื่อก่อนทุกวันศุกร์อาจกลายเป็นวันที่ต้องไล่ตรวจคำร้องเรียน ตอนนี้การปล่อยขึ้นโปรดักชันเป็นงานประจำที่ใช้เวลาสิบห้านาที
— CTO ของโรงเรียนออนไลน์