Checklist kiểm thử trước mỗi lần release

Phần lớn sự cố khi release không đến từ những bug khó. Chúng đến từ những thứ không ai kiểm tra: webhook thanh toán vẫn trỏ về tài khoản test, migration chưa từng chạy trên dữ liệu thật, app mobile bản cũ gọi API mới thì lỗi. Checklist không tự làm cho bản release an toàn, nhưng nó giúp bạn không lặp lại những lỗi đáng ra tránh được.

Đây là danh sách chúng tôi đi qua trước và sau mỗi lần release. Bạn cứ lấy về, bỏ những mục không liên quan đến sản phẩm của mình, và thêm vào những chỗ từng làm bạn “dính đòn”.

1. Biết rõ bản release có gì

Không biết bản release gồm những gì thì không thể test cho tử tế.

• Liệt kê mọi thay đổi: tính năng mới, bug đã sửa, thư viện được nâng cấp, cấu hình bị đổi.
• Đánh dấu những thay đổi rủi ro: bất cứ thứ gì đụng đến tiền, phân quyền, cấu trúc dữ liệu hoặc dịch vụ bên thứ ba.
• Thống nhất tiêu chí nghiệm thu cho từng tính năng mới. Chữ “xong” phải mang cùng một nghĩa với developer, tester và khách hàng.
• Chốt bản release candidate. Test một bản build cứ thay đổi liên tục thì coi như chẳng test được gì.

2. Chuẩn bị môi trường test cho đúng

Những bug chỉ xuất hiện trên production thường đến từ sự khác biệt giữa các môi trường.

• Môi trường test chạy cùng phiên bản, cùng cấu hình và cùng các dịch vụ như production, chỉ khác là dùng tài khoản test.
• Có tài khoản test cho từng vai trò: một người dùng thường, một người dùng thứ hai để kiểm tra dữ liệu có bị lẫn không, và một admin.
• Dữ liệu test phải giống dữ liệu thật. Một bản sao database production đã ẩn danh sẽ bắt được những lỗi mà mười bản ghi mẫu gọn gàng không bao giờ bắt được.

3. Test phần mới làm

• Từng tính năng mới theo tiêu chí nghiệm thu, kể cả các trường hợp lỗi, không chỉ luồng chạy đúng.
• Từng bug đã sửa: xác nhận bug đã hết, rồi test cả khu vực xung quanh. Sửa chỗ này hay làm hỏng chỗ bên cạnh.
• Màn hình mới trên điện thoại thật và trên những trình duyệt người dùng của bạn thật sự dùng.

4. Chạy regression test

• Các luồng quan trọng từ đầu đến cuối: đăng ký, đăng nhập, thao tác chính của sản phẩm, thanh toán, đặt lại mật khẩu.
• Bộ regression test tự động phải xanh. Đừng chấp nhận kiểu “test đó lúc nào chẳng đỏ”.
• Những phần bị ảnh hưởng gián tiếp, như component dùng chung, bảng dữ liệu dùng chung, API dùng chung, cũng cần được xem lại.

5. Kiểm tra các tích hợp

Dịch vụ bên thứ ba là nơi câu “trên môi trường test vẫn chạy mà” hay sai nhất.

• Thanh toán ở chế độ test: thành công, thất bại, hủy, hoàn tiền, và cả trường hợp cổng thanh toán gửi xác nhận hai lần hoặc gửi muộn.
• Email, SMS và thông báo đẩy đều đến nơi, đúng nội dung, đúng link.
• Webhook và callback gửi về đúng môi trường.
• Migration database chạy suôn sẻ trên bản sao dữ liệu production, và bạn biết nó mất bao lâu.
• Phiên bản cũ vẫn phải chạy được. Nếu có app mobile, nhiều người dùng sẽ giữ bản cũ thêm vài tuần. API mới vẫn phải phục vụ được bản đó.

6. Những kiểm tra phi chức năng

• Hiệu năng: các trang và API chính không chậm hơn bản trước.
• Bảo mật cơ bản: người dùng này không xem được dữ liệu của người khác, chức năng admin đòi quyền admin, và không có secret key nào nằm trong code phía client.
• Khả năng truy cập cơ bản: các luồng chính dùng được bằng bàn phím, chữ đủ tương phản để đọc.

7. Chuẩn bị cho chính lần release

• Cấu hình và biến môi trường trên production đã được đặt và rà lại. Thiếu một biến môi trường là một trong những lý do release lỗi phổ biến nhất.
• Tính năng rủi ro được bọc trong feature flag, để có thể tắt mà không cần deploy lại.
• Có kế hoạch rollback và có người biết cách chạy nó, kể cả chuyện xử lý dữ liệu đã ghi sau khi migration.
• Monitoring và cảnh báo lỗi đã bật, và có người theo dõi trong lúc và sau khi release.
• Khách hàng đã ký duyệt UAT.

8. Kiểm tra production ngay sau khi deploy

Bản release đã pass mọi test vẫn có thể lỗi trên production. Chỉ vài phút sau khi deploy:

• Đi lại các luồng quan trọng trên sản phẩm thật, bằng tài khoản thật.
• Theo dõi log lỗi và monitoring xem có gì bất thường.
• Xác nhận thanh toán, email và các tích hợp khác chạy được với dịch vụ thật.
• Báo cáo kết quả. Chúng tôi gửi báo cáo sau deploy trong vòng hai giờ kể từ khi có lệnh release, để mọi người biết bản release ổn, hoặc biết chính xác chỗ nào chưa ổn.

Tóm lại

• Biết chính xác bản release có gì và thay đổi nào rủi ro.
• Test trên môi trường và dữ liệu giống production.
• Test phần mới làm, chạy đủ regression test, kiểm tra mọi tích hợp.
• Chạy migration trên dữ liệu thật trước, và giữ cho app bản cũ vẫn chạy được.
• Chuẩn bị feature flag, kế hoạch rollback và monitoring trước khi deploy.
• Kiểm tra production ngay sau khi deploy và báo cáo kết quả.

Đang phân vân nên tự động hóa mục nào trong danh sách này? Đọc bài kiểm thử thủ công hay tự động: khi nào dùng cách nào?