Khách hàng là nền tảng giáo dục trực tuyến với bài học tương tác, bài tập về nhà, tài khoản riêng cho học viên và phụ huynh, cùng thanh toán trực tuyến. Hoạt động kinh doanh có tính mùa vụ cao: tháng Chín là thời điểm thu hút nhiều học viên mới nhất, và nền tảng ngừng hoạt động trong những tuần đầu năm học có thể khiến khách hàng rời đi vĩnh viễn. Công ty không có đội QA nội bộ; lập trình viên tự kiểm thử giữa các đầu việc khác, kiểm thử hồi quy trước khi phát hành mất ba ngày nhưng vẫn bỏ sót các kịch bản nghiêm trọng như thanh toán, đăng ký buổi học và vào lớp. Khách hàng tìm đến chúng tôi sau một sự cố khác, khi lỗi thanh toán khiến trường học mất một phần yêu cầu đăng ký đã thu thập trong mùa hè.
Xây dựng quy trình đảm bảo chất lượng từ đầu, ưu tiên theo rủi ro kinh doanh, tự động hóa các kịch bản chính, tích hợp
cổng kiểm tra vào CI và kiểm thử tải trước cao điểm tháng Chín. Ràng buộc là không dừng phát triển: các đợt phát hành vẫn diễn ra hằng tuần, còn tháng Chín thì không thể chờ.
Chúng tôi bắt đầu bằng phân tích rủi ro chứ không phải viết kiểm thử tự động: xác định kịch bản nào thường lỗi nhất và lỗi ở đâu gây thiệt hại lớn nhất. Việc tự động hóa tuân thủ đúng danh sách đó.
- Đánh giá chất lượng: xem xét lỗi trong sáu tháng gần nhất, phỏng vấn các nhóm và lập bản đồ những kịch bản gây vấn đề nhiều nhất — thanh toán, đăng ký buổi học, vào lớp và thông báo cho phụ huynh.
- Soạn chiến lược kiểm thử: các cấp độ kiểm thử, phạm vi trách nhiệm, định nghĩa hoàn tất cho tính năng và quy trình báo lỗi, áp dụng thống nhất cho cả ba nhóm phát triển.
- Tự động hóa luồng quan trọng: kịch bản E2E bằng Playwright cho nền tảng web, kiểm thử API cho backend và bộ smoke trước mỗi lần phát hành.
- Tích hợp cổng QA vào CI: không thể phát hành nếu bộ smoke chưa đạt; kiểm thử hồi quy đầy đủ chạy hằng đêm, kết quả được hiển thị cho mọi nhóm trong GitLab.
- Kiểm thử tải bằng k6: mô phỏng lưu lượng cao điểm tháng Chín, tìm điểm nghẽn và phối hợp với nhóm backend khắc phục trước mùa cao điểm.
- Bàn giao quy trình cho khách hàng: tài liệu, quy định làm việc và hướng dẫn kỹ sư QA vận hành kiểm thử tự động cùng pipeline.
Quyết định then chốt là ưu tiên theo rủi ro kinh doanh thay vì chạy theo độ «đẹp» của tỷ lệ bao phủ. Chúng tôi chủ ý không theo đuổi tự động hóa 100%: bao phủ 75% kịch bản quan trọng đã tạo ra phần lớn hiệu quả vì bảo vệ đúng các luồng giúp nền tảng có doanh thu hoặc mất khách. Những phần còn lại được xử lý bằng kiểm thử khám phá thủ công trước các đợt phát hành quan trọng.
Hiệu quả kinh tế chính là phát hiện lỗi sớm hơn trong quy trình: một lỗi được kiểm thử tự động bắt ở CI có chi phí thấp hơn hàng chục lần so với lỗi mà phụ huynh phát hiện trên production. Nền tảng bước vào mùa cao điểm với độ an toàn cao hơn, còn các nhóm có thể phát hành thay đổi thường xuyên mà không lo «hiệu ứng ngày thứ Sáu». Lợi ích khác là niềm tin của doanh nghiệp: đội ngũ bán hàng có thể cam kết trung thực với các trường đối tác rằng nền tảng sẽ ổn định trong thời gian tuyển sinh cao điểm.
| Chỉ số | Kết quả |
|---|---|
| Lỗi nghiêm trọng trên production | 5–7 lỗi mỗi tháng → 1–2 lỗi mỗi quý |
| Kiểm thử hồi quy trước phát hành | 3 ngày thủ công → 4 giờ bằng kiểm thử tự động |
| Cao điểm tải tháng Chín | Năm nào cũng có sự cố → 0 sự cố, không suy giảm |
| Thời điểm phát hiện lỗi | Thường là trên production → Kiểm thử tự động phát hiện trước khi phát hành |
Các chỉ số được chuyển từ tài liệu gốc của case study. Khoảng thời gian được ghi khi nguồn có nêu.
- lỗi nghiêm trọng mỗi quý (trước đây là 5–7 lỗi mỗi tháng)
- 1–2
- kiểm thử hồi quy bằng kiểm thử tự động (trước đây mất 3 ngày thủ công)
- 4 giờ
- kịch bản chính được bao phủ bởi kiểm thử tự động
- 75%
- sự cố trong cao điểm tháng Chín
- 0
Thang đo minh họa: 3 ngày được quy đổi thành 72 giờ. Để xác định độ dài thanh, khoảng lỗi theo tháng được quy đổi sang một quý bằng cách nhân ba; các cận trên được đem so sánh.
- 01Commit
- 02Bộ smokeSmoke chưa đạt thì không phát hành
- 03Phát hànhhằng tuần
- 04Chạy hằng đêmkiểm thử hồi quy đầy đủ
Các bước tiếp theo chúng tôi đề xuất cho nền tảng:
- Kiểm thử hồi quy trực quan — tự động kiểm tra bố cục bài học, email và tài khoản cá nhân.
- Xưởng dữ liệu kiểm thử — tạo dữ liệu học viên, nhóm và giao dịch thanh toán thực tế cho mỗi lần chạy.
- QA trên production — dùng feature flag và phát hành canary để bật tính năng mới từng bước.
Chúng tôi không còn sợ các đợt phát hành. Trước đây, bất kỳ thứ Sáu nào cũng có thể biến thành buổi xử lý khiếu nại; giờ đây, đưa bản phát hành lên production chỉ là quy trình thường lệ mất mười lăm phút.
— CTO của trường học trực tuyến