Test case là gì?

Test case là một tập hợp gồm điều kiện tiền đề, các bước thực hiện và kết quả mong đợi, được thiết kế để kiểm tra xem một chức năng có hoạt động đúng yêu cầu hay không. Theo ISTQB, test case được phát triển từ các điều kiện test (test condition) trong bước thiết kế test của quy trình kiểm thử, nhằm kiểm chứng một mục tiêu cụ thể, đo lường được.

Nói nôm na, test case giống một "kịch bản thử" rất chi tiết: làm gì, ở trạng thái nào, và mong đợi hệ thống phản hồi ra sao. Viết tốt thì người khác cầm lên chạy được ngay mà không cần hỏi lại bạn câu nào — đó mới là test case đạt chuẩn.

Các trường bắt buộc trong một test case

Dưới đây là các cột theo đúng template IT LEARN dùng. Mỗi test case khai báo ở dòng đầu (ID, Description, Pre-condition), sau đó liệt kê từng bước:

Cột trong template Ý nghĩa / cách điền
ID Mã định danh duy nhất, gắn theo ticket (VD: TC_FCQ12-81_001)
Test Case Description Mô tả mục tiêu test trong 1 câu, đọc là hiểu test cái gì
Pre-condition Trạng thái cần có TRƯỚC khi chạy (VD: user chưa đăng nhập)
Step Các bước thực hiện, đánh số — mỗi bước một dòng
Expected output Kết quả mong đợi tương ứng cho từng bước
Expected result Kết quả mong đợi (theo bước/tổng thể) — nhiều đội điền trùng output
Actual Output Kết quả thực tế quan sát được khi chạy
Result Passed / Failed / Blocked / Pending
Test date Ngày thực thi test
Note Link bug, ảnh chụp, lưu ý đặc biệt

Ngoài bảng test case, phần đầu sheet còn có khối thông tin chung cần điền: Function Name (chức năng đang test), Created By (người viết), Environment và Screen resolution (môi trường, độ phân giải). Các ô Passed / Failed / Number of Test cases tự đếm bằng công thức, bạn không cần điền tay.

Cách viết test case từng bước

Đây là quy trình tôi vẫn dạy học viên, khớp với cách điền template ở trên:

  1. Điền khối thông tin chung trước. Function Name, Created By, Environment, Screen resolution — để người đọc biết test cho chức năng nào, trên môi trường nào.
  2. Hiểu yêu cầu cần test. Đọc kỹ user story/đặc tả, làm rõ chỗ mơ hồ với BA. Không hiểu "đúng" là gì thì không test đúng được.
  3. Xác định các điều kiện test. Liệt kê những gì cần kiểm tra: hợp lệ, không hợp lệ, biên, ngoại lệ — mỗi điều kiện sẽ thành một test case.
  4. Đặt ID và Description. Mỗi test case một ID theo quy luật (ticket + số thứ tự), Description tóm tắt mục tiêu trong một câu.
  5. Ghi Pre-condition và liệt kê Step. Mỗi bước một dòng, đánh số, mỗi dòng một hành động duy nhất để người chạy không nhầm.
  6. Viết Expected output cho từng bước. Đây là phần quan trọng nhất: nêu cụ thể hệ thống phải hiển thị/chuyển hướng/báo lỗi gì ở mỗi bước, tránh viết chung chung "chạy đúng".
  7. Review chéo, rồi cập nhật khi thực thi. Nhờ đồng nghiệp đọc lại để bắt lỗi thiết kế; lúc chạy thật thì điền Actual Output, Result và Test date — nếu phát hiện lỗi, ghi nhận theo vòng đời bug & cách viết bug report.

Mẹo nhỏ: phủ đủ ba nhóm — hợp lệ (positive), không hợp lệ (negative) và biên (boundary) — là tránh được phần lớn lỗi sót. Gặp thuật ngữ lạ thì tra nhanh ở thuật ngữ kiểm thử.

Ví dụ test case thực tế (form đăng nhập)

Lấy luôn màn hình đăng nhập của một "Hệ thống đặt phòng họp nội bộ" làm ví dụ. Để ý cách mỗi Step có một Expected output tương ứng:

ID Description Pre-condition Step Expected output Result
TC_FCQ12-81_002 Đăng nhập với email & mật khẩu đúng Đã có tài khoản hợp lệ; user chưa đăng nhập 1. Mở màn hình đăng nhập
2. Nhập email đúng
3. Nhập mật khẩu đúng
4. Click "Đăng nhập"		 1. Form hiển thị, focus ở Email
2. Email hiển thị giá trị
3. Mật khẩu dạng masked (••••)
4. Xác thực thành công, chuyển sang Dashboard		 Pending
TC_FCQ12-81_006 Đăng nhập với email đúng, mật khẩu sai Đã có tài khoản hợp lệ; user chưa đăng nhập 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. Click "Đăng nhập"		 1. Form hiển thị
2. Email hiển thị giá trị
3. Mật khẩu masked
4. Hiện alert đỏ "Email hoặc mật khẩu không đúng", vẫn ở LoginScreen		 Pending
TC_FCQ12-81_011 Bỏ trống trường Email User chưa đăng nhập, đang ở LoginScreen 1. Mở màn hình đăng nhập
2. Để trống Email
3. Nhập mật khẩu
4. Click "Đăng nhập"		 1. Form hiển thị
2. Email rỗng
3. Mật khẩu masked
4. Trình duyệt báo lỗi inline required, form không submit		 Pending

Hai dấu hiệu của bộ test case chuyên nghiệp: ID đặt theo quy luật và Expected output luôn cụ thể, kiểm chứng được ở từng bước.

Template test case tải về

Để bạn khỏi mất công kẻ bảng từ đầu, dùng luôn template chuẩn của IT LEARN (đã có sẵn khối thông tin chung, công thức tự đếm Passed/Failed và bộ ví dụ màn hình đăng nhập):

👉 Tải template test case (.xlsx)

Cách dùng nhanh:

  • Mỗi chức năng/màn hình nên là một sheet riêng (sheet mẫu tên "Đăng nhập").
  • Điền khối thông tin chung ở đầu sheet (Function Name, Created By, Environment…).
  • Với mỗi test case: ghi ID + Description + Pre-condition ở dòng đầu, rồi liệt kê Step mỗi bước một dòng, kèm Expected output tương ứng.
  • Khi chạy test: điền Actual Output, chọn Result (Passed/Failed/Blocked/Pending) và Test date — ô tổng kết sẽ tự cập nhật.

Lỗi thường gặp khi viết test case

Qua 18 năm review test case, đây là những lỗi tôi gặp nhiều nhất ở người mới:

  • Expected output mơ hồ. Viết "hệ thống chạy đúng" thay vì mô tả cụ thể hiển thị/chuyển hướng/thông báo gì. Người khác không biết lấy gì để kết luận Pass/Fail.
  • Gộp nhiều hành động vào một Step. Một dòng nhồi 3-4 thao tác khiến người chạy dễ nhầm. Mỗi Step nên là một hành động, và có Expected output riêng.
  • Chỉ test trường hợp hợp lệ. Quên các tình huống sai/biên (mật khẩu sai, bỏ trống, sai định dạng) — vốn là nơi lỗi hay ẩn nấp nhất.
  • Thiếu Pre-condition. Người chạy không biết phải chuẩn bị trạng thái gì trước, dẫn đến kết quả không nhất quán.
  • Test case quá lớn hoặc trùng lặp. Một test case nên kiểm chứng một mục tiêu rõ ràng, không "ôm" cả luồng dài.

Sửa được năm lỗi này thôi là chất lượng test case của bạn đã hơn hẳn rồi. 💪