Lời mở đầu: làm test không chỉ là bấm thử theo kịch bản
Nhiều người ngoài ngành hình dung công việc tester là mở một kịch bản có sẵn rồi lần lượt bấm qua từng nút. Đó chỉ là bề mặt của nghề. Khi sản phẩm ra mắt và người dùng gặp sự cố, người đầu tiên bị hỏi vẫn là tester: vì sao lỗi này lọt qua?
Tôi viết bài này sau vài năm làm QA qua các dự án fintech, thương mại điện tử và SaaS. Mười hai bài học dưới đây không phải lý thuyết giáo trình. Tôi đã trả giá cho chúng bằng thời gian, bằng những buổi tranh luận căng thẳng và bằng những lần xin lỗi khách hàng.
Kiểm thử chương trình có thể chứng minh sự hiện diện của lỗi, nhưng không bao giờ chứng minh được sự vắng mặt của chúng.
Edsger W. Dijkstra, Notes on Structured Programming, 1970
Mười hai bài học trong một bảng
| # | Bài học | Tóm tắt một dòng |
|---|---|---|
| 1 | Hỏi, đừng đoán | Mọi điểm mơ hồ trong spec phải thành câu hỏi, không phải giả định. |
| 2 | Happy path trước | Một nửa thời gian dành cho luồng đa số người dùng đi. |
| 3 | Hai tầng thị giác | Cảm nhận như người dùng, rồi soi như kỹ sư. |
| 4 | Bốn trạng thái dữ liệu | Rỗng, đang tải, quá tải, báo lỗi. Không chỉ trường hợp đẹp. |
| 5 | Đề xuất cải tiến | Đừng dừng ở sai lệch, hãy nêu giải pháp cụ thể. |
| 6 | Severity và Priority | Ảnh hưởng kỹ thuật và cấp bách kinh doanh là hai trục khác nhau. |
| 7 | Bằng chứng, không cảm tính | Báo cáo lỗi là hồ sơ giám định, không phải lời phàn nàn. |
| 8 | Mở F12 trước | Không có request là Frontend; 500 hoặc timeout là Backend. |
| 9 | Database là chân lý | Thông báo xanh không chứng minh dữ liệu đúng. |
| 10 | Hiệu ứng cánh bướm | Retest mọi luồng dùng chung mã vừa sửa. |
| 11 | Người dùng không ngăn nắp | Nhấp đúp, nút Back, dán văn bản, tên dài. |
| 12 | Dev là đồng minh | Đặt cả hai bên cùng một phía của vấn đề. |
Phần 1: Tư duy với yêu cầu nghiệp vụ
Bài học 1: Đọc spec để đặt câu hỏi, không phải để đoán mò
Cái bẫy: Đọc lướt tài liệu rồi lấp mọi chỗ trống bằng cảm tính, vì ngại hỏi BA và Dev.
- Đọc với cây bút và gạch chân mọi điểm mơ hồ.
- Hỏi theo kiểu giả định: Nếu mạng ngắt giữa lúc trừ tiền thì sao? Nếu người dùng Hủy ở bước cuối thì sao? Nếu hai người cùng thanh toán một đơn thì sao?
- Biến mỗi câu trả lời thành một tiêu chí kiểm thử rõ ràng.
Đúc kết: Một lỗi cú pháp tốn vài phút. Một yêu cầu hiểu sai tốn hàng trăm giờ.
Bài học 2: Giữ happy path trước khi tìm lỗi dị thường
Cái bẫy: Lao vào các ca biên hóc búa trên bản dựng mới trong khi luồng đăng ký hoặc thanh toán cốt lõi vẫn gãy.
- Khoảng 50% thời gian cho happy path mà đa số người dùng đi.
- Khoảng 30% cho các lỗi nhập liệu phổ biến.
- 20% cuối cho ca biên và tình huống khắc nghiệt.
Đúc kết: Không ai test 100% mọi trường hợp. Hãy ưu tiên luồng mà một lỗi nhỏ gây mất tiền hoặc mất niềm tin.
Phần 2: Góc nhìn trải nghiệm
Bài học 3: Hai tầng thị giác
Cái bẫy: Hai thái cực sai. Một là soi lệch pixel mà quên cảm xúc hành trình. Hai là bấm lướt mà không thấy bố cục vỡ ở kích thước màn hình khác.
- Năm phút đầu: đóng vai khách hàng mới đang vội, chỉ dùng chuột.
- Sau đó mở công cụ responsive và soi nút bấm, khoảng cách, thứ tự ưu tiên ở từng độ rộng.
Đúc kết: Hãy cảm nhận như người dùng, rồi soi như kỹ sư.
Bài học 4: Tư duy bốn trạng thái dữ liệu
Cái bẫy: Chỉ test với dữ liệu mẫu đẹp và quên trải nghiệm lần đầu, mạng chậm, dữ liệu nặng và lúc thất bại.
- Rỗng: có hình minh họa, lời giải thích ngắn và nút tạo mới.
- Đang tải: khóa nút và hiển thị loading nội tại để chống nhấp đúp.
- Quá tải: thử tên dài trên 100 ký tự, danh sách rất dài và trường tùy chọn bị thiếu.
- Báo lỗi: giải thích chuyện gì xảy ra và cách khắc phục.
Đúc kết: Bốn trạng thái là mức tối thiểu cho mọi màn hình.
Bài học 5: Đừng chỉ tìm lỗi, hãy đóng góp cải tiến
Cái bẫy: Bỏ qua một tính năng rườm rà với lý do spec viết sao thì làm vậy.
- Ghi đề xuất cải tiến kèm giải pháp cụ thể, không chỉ nêu sai lệch.
- Ví dụ: gộp hai trường địa chỉ và tự điền từ mã bưu chính, thay vì nói form rườm rà.
Đúc kết: Đề xuất có giải pháp thì được lắng nghe.
Báo cáo lỗi là hồ sơ giám định, không phải lời phàn nàn.
Phần 3: Bắt lỗi bằng bằng chứng khách quan
Bài học 6: Phân định rạch ròi Severity và Priority
Cái bẫy: Gắn mác khẩn cấp cho mọi lỗi, tạo căng thẳng và che khuất những lỗi thật sự nghiêm trọng.
- Severity đo ảnh hưởng kỹ thuật: sập hệ thống, mất dữ liệu, hỏng chức năng cốt lõi.
- Priority đo cấp bách kinh doanh: sai logo không làm sập web nhưng phải sửa ngay.
Đúc kết: Hai trục độc lập. Khi mọi thứ đều đỏ thì không còn gì nổi bật.
Bài học 7: Nói bằng bằng chứng khách quan
Cái bẫy: Báo rằng màn hình thỉnh thoảng lỗi hoặc giao diện chậm.
- Các bước tái hiện được đánh số.
- Kết quả thực tế đặt cạnh kết quả kỳ vọng.
- Ảnh chụp hoặc video có khoanh vùng.
- Mã HTTP và trace ID từ bảng Network.
Đúc kết: Đủ bằng chứng biến nửa ngày điều tra thành vài phút sửa.
Bài học 8: Mở F12 trước khi báo lỗi
Cái bẫy: Đổ lỗi cho Backend trước khi kiểm tra giao diện có gửi request hay chưa.
- Bấm mà không có request: lỗi Frontend, thường do thiếu sự kiện hoặc bị validation chặn.
- Trả về 200 nhưng không vẽ dữ liệu: lỗi hiển thị Frontend.
- Trả về 500 hoặc timeout: lỗi Backend.
Đúc kết: Ba nhánh này tiết kiệm cho đội nhiều vòng đi lại.
Hình 1. Phân loại lỗi ngay trong bảng Network trước khi gán cho ai.
Bài học 9: Giao diện chỉ là lớp vỏ, database mới là chân lý
Cái bẫy: Thấy thông báo thành công là đánh dấu đạt.
- Truy vấn trực tiếp bản ghi theo ID.
- Kiểm tra trường phụ, múi giờ và lịch sử thay đổi.
- Với thanh toán, phân quyền và cấu hình hệ thống, đối soát database là bắt buộc.
Đúc kết: Thông báo xanh không phải bằng chứng. Một dòng dữ liệu đúng mới là bằng chứng.
Thông báo xanh không phải bằng chứng. Một dòng dữ liệu đúng mới là bằng chứng.
Phần 4: Tư duy hệ thống và thấu cảm
Bài học 10: Hiệu ứng cánh bướm
Cái bẫy: Chỉ kiểm tra đúng ô Dev vừa sửa rồi đóng vé.
- Retest mọi luồng dùng chung component, bộ validate hoặc lớp dịch vụ vừa chạm.
- Coi regression là một phần của việc sửa, không phải bước phụ.
Đúc kết: Một hàm dùng chung có thể làm hỏng ba màn hình.
Bài học 11: Người dùng thật không ngăn nắp như kịch bản
Cái bẫy: Test chậm rãi, tuần tự rồi cho rằng người dùng cũng làm vậy.
- Bấm xác nhận liên tục và kiểm tra đơn trùng.
- Bấm nút Back của trình duyệt giữa lúc thanh toán.
- Nhập dấu tiếng Việt phức tạp, dán từ Word, tải tệp có tên dài.
Đúc kết: Những thao tác không ngăn nắp phơi ra lỗi mà kịch bản gọn gàng không chạm tới.
Bài học 12: Đừng biến Dev thành đối thủ
Cái bẫy: Thái độ bắt bẻ biến đồng nghiệp thành đối thủ.
- Thay "code của anh bị lỗi rồi" bằng "khi em gửi dữ liệu này, hệ thống phản hồi thế này, anh xem giúp em nhé".
- Đặt cả hai bên cùng một phía của vấn đề.
Đúc kết: Tôn trọng và thấu cảm kỹ thuật giúp công việc trôi nhanh hơn mọi công cụ.
Phụ lục: bộ ba công cụ thực chiến
Công cụ 1: Biểu mẫu báo cáo lỗi pháp y kỹ thuật
Một báo cáo lỗi chuẩn có năm phần. Tiêu đề theo cấu trúc module, tần suất 100% hoặc ngẫu nhiên, và sự cố khi điều kiện kích hoạt.
- Môi trường: thiết bị và hệ điều hành, trình duyệt và phiên bản, môi trường và số hiệu bản dựng, tài khoản thử nghiệm kèm vai trò.
- Các bước tái hiện tối thiểu: đánh số và đủ ngắn để người khác làm lại chính xác.
- Kết quả thực tế: chuyện gì xảy ra, thời gian chờ và thông báo hiển thị nguyên văn.
- Kết quả kỳ vọng: hành vi đúng theo nghiệp vụ, gồm cảnh báo tại chỗ và nút Lưu bị khóa sau lần bấm đầu.
- Bằng chứng kỹ thuật: ảnh hoặc video khoanh vùng, URL request, mã HTTP, thời gian phản hồi, payload gửi đi, body trả về và trace ID.
Công cụ 2: Ma trận Severity và Priority
Chỉ số rủi ro là trọng số Severity nhân trọng số Priority, giúp đội ngũ sắp thứ tự khắc phục một cách khách quan.
Hình 2. Severity đo ảnh hưởng kỹ thuật, Priority đo mức độ cấp bách kinh doanh.
| Mức độ | Severity 1: Thảm họa | Severity 2: Nghiêm trọng | Severity 3: Trung bình | Severity 4: Nhẹ hoặc thẩm mỹ |
|---|---|---|---|---|
| Priority 1: Khẩn cấp, sửa trong 2 đến 4 giờ | Sập cổng thanh toán, rò rỉ dữ liệu thẻ, mất kết nối database chính. | Mã giảm giá không áp được trong giờ vàng, email xác thực tài khoản mới không gửi được. | Sai logo đối tác lớn trên trang chủ, sai tên thương hiệu trong thông cáo. | Lệch icon trên màn hình chờ của bản dựng sự kiện báo chí. |
| Priority 2: Ưu tiên cao, sửa trong sprint hiện tại | Báo cáo thuế của kế toán tính sai, có thể xử lý thủ công tạm thời. | Lọc đơn theo ngày sai múi giờ với nhóm tài khoản phụ. | Nút đóng bảng thông báo lệch trên iPad Safari. | Font tiêu đề trang Liên hệ lệch 2px so với design system. |
| Priority 3: Bình thường, đưa vào backlog | Rò rỉ bộ nhớ ở job sao lưu dữ liệu cũ chạy mỗi quý. | Không đổi được ảnh đại diện với tệp webp. | Menu bên không có hiệu ứng chuyển cảnh. | Nền footer tối hơn mã màu quy định. |
| Priority 4: Thấp, sửa khi có thời gian | Xung đột tiến trình trong công cụ xuất dữ liệu sẽ được thay thế tháng sau. | Lỗi định dạng khi in báo cáo nội bộ chỉ hai nhân viên IT dùng. | Một từ sai không ảnh hưởng ngữ nghĩa trong trang Điều khoản. | Lề dưới trang 404 hơi rộng ở màn hình 300px. |
Công cụ 3: Bảng kiểm bốn trạng thái dữ liệu
Hình 3. Bốn trạng thái mà mọi màn hình đều phải vượt qua.
1. Trạng thái rỗng.
- ☐ Không để màn hình trắng hoặc bảng trống không có lời giải thích.
- ☐ Có hình minh họa phù hợp ngữ cảnh.
- ☐ Có tiêu đề ngắn và lời giải thích thân thiện.
- ☐ Có nút hành động chính dẫn tới việc tạo dữ liệu đầu tiên.
2. Trạng thái đang tải.
- ☐ Dùng khung xương mô phỏng đúng bố cục sắp xuất hiện.
- ☐ Khóa nút xác nhận và hiển thị loading nội tại.
- ☐ Trên Slow 3G, bố cục không vỡ sau 5 giây và tác vụ dài phải báo tiến độ.
3. Quá tải và dữ liệu khuyết thiếu.
- ☐ Dán 500 ký tự không dấu cách, bố cục phải xuống dòng hoặc cắt bớt kèm tooltip.
- ☐ Với 1.000 đến 10.000 bản ghi, dùng ảo hóa hoặc phân trang.
- ☐ Khi thiếu trường tùy chọn, bố cục vẫn cân đối.
4. Trạng thái báo lỗi.
- ☐ Mất mạng: hiển thị banner và nút thử lại.
- ☐ Lỗi 5xx: xin lỗi kèm trace ID, không phơi stack trace hay lỗi database.
- ☐ Lỗi xác thực: viền đỏ, chỉ dẫn ngay dưới trường và tự cuộn tới trường lỗi đầu tiên.
Tài liệu tham khảo
- ISTQB Glossary, định nghĩa severity và priority: glossary.istqb.org
- Chứng chỉ ISTQB Certified Tester Foundation Level: istqb.org
- Ham Vocke, The Practical Test Pyramid, martinfowler.com: martinfowler.com
- Nielsen Norman Group, thiết kế giao diện trạng thái rỗng: nngroup.com
- MDN, tổng quan công cụ dành cho nhà phát triển trên trình duyệt: developer.mozilla.org
- W3C, Web Content Accessibility Guidelines 2.2: w3.org
- OWASP, Web Security Testing Guide: owasp.org
Lời kết
Kiểm thử không phải cuộc đua xem ai bắt được nhiều lỗi hơn. Đó là cách cả đội giữ gìn niềm tin của người dùng. Nếu chỉ mang theo một thói quen, hãy mang theo điều này: hỏi trước khi giả định, và kiểm tra dữ liệu thật trước khi tin vào thông báo trên màn hình.