Test scenario vs test case khác nhau ở mức độ chi tiết: test scenario là tình huống/luồng cần kiểm thử ở mức tổng quát ("kiểm thử cái gì"), còn test case là các bước cụ thể kèm điều kiện tiền đề và kết quả mong đợi ("kiểm thử như thế nào"). Một scenario thường sinh ra nhiều test case. Đây là cặp khái niệm hay bị hỏi khi phỏng vấn, và hiểu đúng nó là nền tảng kỹ năng của mọi Manual Tester.

Bài này tôi phân biệt rõ hai khái niệm bằng bảng và ví dụ thực tế, làm rõ quan hệ scenario → case → step, rồi điểm lại các kỹ năng cốt lõi giúp bạn viết tốt cả hai.

Test scenario vs test case — bảng phân biệt

Để dễ nhớ, hãy nhìn cạnh nhau theo từng tiêu chí:

Tiêu chí Test Scenario Test Case
Trả lời câu hỏi Kiểm thử cái gì Kiểm thử như thế nào
Mức độ chi tiết Tổng quát, một câu mô tả luồng Chi tiết: bước, dữ liệu, kết quả mong đợi
Thành phần Tên/mô tả tình huống ID, pre-condition, step, expected output, result
Số lượng Ít, bao quát Nhiều (1 scenario → nhiều case)
Thời điểm tạo Sớm, ngay sau khi đọc yêu cầu Sau khi đã có scenario
Ai cũng chạy được? Cần suy luận thêm Chạy y hệt, không cần hỏi lại
Ví dụ "Kiểm thử chức năng đăng nhập" "Đăng nhập với email đúng + mật khẩu sai → báo lỗi đỏ"

Nói ngắn gọn: scenario cho bạn bức tranh tổng thể, test case cho bạn từng bước để thực thi và kết luận Pass/Fail.

Test scenario là gì? (ví dụ)

Test scenario (kịch bản kiểm thử) là một tình huống hoặc luồng chức năng cần được kiểm thử, mô tả ở mức tổng quát — nó chỉ ra "cần test cái gì" mà chưa đi vào từng bước. Scenario thường được rút ra trực tiếp từ yêu cầu/user story, giúp đội kiểm thử bao quát đủ các luồng quan trọng trước khi đi vào chi tiết.

Ví dụ, với màn hình đăng nhập, vài test scenario tiêu biểu:

  • Kiểm thử đăng nhập với thông tin hợp lệ.
  • Kiểm thử đăng nhập với mật khẩu sai.
  • Kiểm thử bỏ trống các trường bắt buộc.
  • Kiểm thử chức năng "Quên mật khẩu".

Mỗi dòng trên là một scenario — ngắn gọn, dễ rà soát xem đã phủ đủ tình huống chưa. Nếu gặp thuật ngữ lạ trong quá trình này, bạn có thể tra nhanh ở thuật ngữ kiểm thử.

Test case là gì? (nhắc lại, ví dụ)

Test case là phần chi tiết hóa một scenario thành các bước cụ thể, gồm điều kiện tiền đề (pre-condition), các bước thực hiện (step) và kết quả mong đợi (expected output). Test case viết tốt thì ai cầm lên cũng chạy được y hệt và kết luận Pass/Fail rõ ràng.

Lấy scenario "Kiểm thử đăng nhập với mật khẩu sai" ở trên, ta chi tiết hóa thành một test case:

Thành phần Nội dung
ID TC_LOGIN_006
Pre-condition Đã có tài khoản hợp lệ; user chưa đăng nhập
Step 1. Mở màn hình đăng nhập → 2. Nhập email tồn tại → 3. Nhập mật khẩu sai → 4. Bấm "Đăng nhập"
Expected output Hiện thông báo đỏ "Email hoặc mật khẩu không đúng", vẫn ở màn hình đăng nhập
Result Passed / Failed / Pending

Một scenario như vậy có thể sinh ra nhiều test case (mật khẩu sai, email không tồn tại, để trống, sai định dạng…). Muốn nắm đầy đủ các trường và quy trình điền, xem hướng dẫn cách viết test case chi tiết kèm template tải về.

Quan hệ scenario → case → step

Ba cấp độ này lồng vào nhau như một cái phễu, từ tổng quát đến chi tiết:

  1. Test scenario — tình huống cần kiểm thử (1 dòng). VD: Kiểm thử đăng nhập.
  2. Test case — chi tiết hóa scenario thành tình huống cụ thể có kết quả mong đợi. VD: Đăng nhập sai mật khẩu → báo lỗi.
  3. Test step — từng hành động bên trong một test case. VD: Nhập email → nhập mật khẩu → bấm Đăng nhập.

Hiểu cái phễu này giúp bạn làm việc có hệ thống: phủ scenario trước cho khỏi sót luồng, rồi mới "xuống" case và step. Nó cũng là cách kiểm thử được tổ chức trong quy trình kiểm thử phần mềm (STLC) ở bước thiết kế test.

Đôi khi bạn sẽ nghe thêm khái niệm test script — thường chỉ một test case đã được viết thành các bước rất tường minh để thực thi (thủ công hoặc tự động hóa). Với Manual Tester, có thể hiểu test script gần như test case ở dạng "sẵn sàng chạy".

Kỹ năng cốt lõi của Manual Tester

Viết tốt scenario và test case không phải chuyện kỹ thuật cao siêu — nó là tập hợp các kỹ năng tư duy mà ai cũng luyện được:

  • Đọc hiểu yêu cầu. Bóc tách user story/đặc tả, làm rõ chỗ mơ hồ với BA trước khi test. Không hiểu "đúng" là gì thì không thể test đúng.
  • Tư duy bao phủ. Nghĩ đủ ba nhóm: hợp lệ (positive), không hợp lệ (negative) và biên (boundary) — đây là nơi lỗi hay ẩn nấp nhất.
  • Diễn đạt mạch lạc. Viết step và expected output cụ thể, kiểm chứng được; tránh kiểu "hệ thống chạy đúng".
  • Tư duy phản biện & tò mò. Luôn hỏi "nếu… thì sao?", thử phá vỡ luồng bình thường để lộ ra lỗi.
  • Tỉ mỉ và kiên nhẫn. Để ý chi tiết "sai sai" mà người dùng thật sẽ gặp, không bỏ qua.
  • Giao tiếp. Báo lỗi rõ ràng, phối hợp với dev/BA để tái hiện và xử lý.

Tin vui: những kỹ năng này không đòi hỏi biết code, phù hợp cả người mới và người trái ngành. Nếu muốn luyện bài bản trên dự án thật và được mentor review từng scenario, test case, bạn có thể tham khảo khóa Manual Testing của IT LEARN, hoặc xem trước lộ trình học tester từ con số 0.