Các trường hợp kiểm thử phổ biến nhất theo từng Loại Test

Loại này tập trung vào phần nhìn và trải nghiệm của người dùng. Tester ở bước này giống như một nhà thiết kế khó tính.

Các trường hợp kiểm thử (Test Cases) thường gặp:

Kiểm tra tính đồng nhất (Consistency): Font chữ, màu sắc, kích thước nút bấm có đúng với bản thiết kế (Figma/Design Guideline) không?
Kiểm tra hiển thị văn bản: Có bị lỗi chính tả không? Chữ có bị tràn ra ngoài khung hoặc bị che khuất không?
Kiểm tra trên nhiều thiết bị (Responsive): Thu nhỏ màn hình máy tính lại, hoặc mở trên điện thoại, iPad thì bố cục có bị vỡ không?
Kiểm tra các trạng thái của phần tử: Rê chuột (hover) vào nút bấm nó có đổi màu không? Bấm vào (active) có hiệu ứng gì không? Tooltip (chữ nhỏ hiện lên khi đưa chuột vào) có đúng không?
Kiểm tra thông báo rủi ro: Bấm nút "Xóa" hệ thống có hiện popup hỏi lại "Bạn có chắc chắn muốn xóa không?" hay là xóa luôn (lỗi nguy hiểm)?

Đây là phần cốt lõi nhất. Trả lời câu hỏi: "Hệ thống có làm đúng việc nó được sinh ra để làm không?"

Các trường hợp kiểm thử (Test Cases) thường gặp:

Trường hợp luồng chuẩn (Happy Path): Nhập đúng mọi thông tin, làm đúng mọi bước -> Phải ra kết quả thành công (Ví dụ: Thêm mới văn bản đi thành công).
Trường hợp rẽ nhánh/lỗi (Unhappy Path - Rất quan trọng):
- Bỏ trống: Không nhập các ô có dấu sao đỏ (*) -> Phải báo lỗi bắt buộc nhập.
- Nhập sai định dạng: Ô Email mà nhập nguyenvan_a (thiếu @gmail.com), ô Số điện thoại mà nhập chữ cái -> Phải báo lỗi định dạng.
- Vượt quá giới hạn: Ô Tên chỉ cho nhập 50 ký tự, cố tình copy đoạn văn dài 100 ký tự dán vào -> Hệ thống chặn lại không cho nhập hoặc báo lỗi.
- Kiểm tra phân quyền (Authorization): Tài khoản "Nhân viên" có lén nhìn thấy được "Báo cáo lương của Giám đốc" không? (Nút xem báo cáo phải bị ẩn hoặc bấm vào báo lỗi "Không có quyền").

Kiểm tra xem "anh bồi bàn" có mang đúng dữ liệu từ bếp lên không, kể cả khi giao diện (UI) chưa làm xong.

Các trường hợp kiểm thử (Test Cases) thường gặp:

API trả về đúng dữ liệu (Mã 200 OK): Gửi yêu cầu lấy "Chi tiết văn bản đi số 1" -> API trả về đúng file JSON chứa ID = 1 và thông tin tương ứng.
Kiểm tra bảo mật Token (Mã 401 Unauthorized): Cố tình gọi API nhưng không đính kèm thẻ bảo mật (Token), hoặc dùng Token đã hết hạn -> Hệ thống phải đuổi ra, không cho lấy dữ liệu.
Gửi thiếu/sai đầu vào (Mã 400 Bad Request): API yêu cầu ID phải là số, cố tình gửi ID là chữ "abc" -> Báo lỗi dữ liệu không hợp lệ.
Không có quyền truy cập (Mã 403 Forbidden): Token hợp lệ, nhưng Token đó là của nhân viên quèn, cố gọi API của sếp -> Bị chặn.

Bạn làm thao tác trên màn hình, báo "Thành công", nhưng dữ liệu có thực sự được lưu vào "tủ hồ sơ" (Database) một cách chính xác không?

Các trường hợp kiểm thử (Test Cases) thường gặp:

Kiểm tra đối chiếu dữ liệu (Data Mapping): Thêm mới nhân viên A trên màn hình web. Vào database viết lệnh SELECT -> Dữ liệu của nhân viên A phải nằm đúng ở bảng NhanVien, không bị thiếu cột nào, dấu tiếng Việt không bị lỗi font.
Kiểm tra Xóa mềm (Soft Delete): Khi bấm "Xóa" trên web, hệ thống biến mất. Nhưng vào database kiểm tra, dòng đó không bị xóa hẳn (lệnh DELETE) mà chỉ được cập nhật trạng thái IsDeleted = 1 (lệnh UPDATE) để phòng hờ sau này khôi phục lại.
Kiểm tra ràng buộc: Nếu bảng quy định cột Email là duy nhất (Unique), cố tình chạy lệnh INSERT một người mới trùng email với người cũ -> Database phải văng ra lỗi.

Kiểm tra xem khi ráp các mô-đun (bộ phận) lại với nhau, chúng có làm việc ăn ý không.

Các trường hợp kiểm thử (Test Cases) thường gặp:

Luồng dữ liệu qua lại: Khi bộ phận A (Module Dự thảo) duyệt văn bản xong -> Bộ phận B (Module Văn bản đi) có tự động xuất hiện bản ghi đó không?
Tích hợp bên thứ 3: Khi bấm thanh toán VNPay trên web của mình, hệ thống có nhảy đúng sang trang của VNPay không? Thanh toán xong có quay về báo "Thành công" trên web mình không?