Bài test đầu vào tester gồm những gì? Luyện tập với case thực tế

Vì sao bài test đầu vào làm khó nhiều bạn

Mình nhớ lần đầu nhận đề viết test case đăng nhập, nghĩ chỉ cần đúng-sai. Kết quả? Bỏ sót ký tự khoảng trắng đầu-cuối và server từ chối. Lỗi nhỏ nhưng đủ trượt.

Đi tuyển, bài test hiếm khi đánh đố. Họ kiểm tra cách bạn suy nghĩ, viết rõ ràng, và ưu tiên rủi ro. Làm kỹ một lần, bạn qua vòng này nhẹ nhàng.

Đừng nhầm "chạy được" với "đúng" - khác nhau xa

Bài này mình tóm các dạng đề phổ biến, rồi đưa case thực tế để bạn luyện. Thấy khó ở vài chỗ là bình thường, mình cũng từng mất 2-3 ngày mới quen nhịp.

Dạng bài test tuyển dụng thường gặp

Trọng tâm thường rơi vào 2 nhóm: viết test case từ yêu cầu và tìm lỗi để viết bug report. Nhiều công ty thêm SQL cơ bản, đọc hiểu tiếng Anh, hoặc test API trên Postman, nhưng cốt lõi vẫn là hai nhóm này.

• Viết test case từ mô tả tính năng hoặc UI cụ thể
• Tìm bug từ ảnh chụp/sandbox prototype, viết bug report có steps, expected, actual
• Phụ: SQL cơ bản, API testing với Postman, ưu tiên-severity-priority

Theo quan sát JD junior tại VN, mục "viết test case" và "lập bug report" xuất hiện trong khoảng đa số JD. Tham khảo JD thực: Mẫu JD Junior QA - ITviec và Mẫu JD Manual/Junior - TopCV.

Hai dạng chính quyết định điểm: test case và bug report

Bạn đọc kỹ JD sẽ thấy từ khóa lặp lại như: viết test case, log bug trên Jira, giao tiếp với dev, regression testing. Đây là dấu hiệu đề thi xoay quanh kỹ năng nền tảng chứ không phải mẹo vặt.

Viết test case từ yêu cầu: case đăng ký tài khoản

Đề bài thường cho mô tả ngắn. Ví dụ: Form đăng ký gồm Email, Mật khẩu, Xác nhận mật khẩu. Yêu cầu: Email hợp lệ; mật khẩu 8-20 ký tự, có chữ và số; xác nhận phải trùng; nút Đăng ký chỉ bật khi hợp lệ. Hết.

Cách làm rõ ràng:

1. Chốt phạm vi và dữ liệu - phân lớp tương đương và mép biên (equivalence, boundary).
2. Thiết kế happy path, negative và edge. 3) Viết expected cụ thể, có thông điệp lỗi.

Quy trình 4 bước đủ dùng cho đề thi viết test case

Ví dụ test case, viết gọn, expected cụ thể:

TC01 - Email hợp lệ, mật khẩu hợp lệ, xác nhận khớp
Steps: Mở trang → nhập email hợp lệ → mật khẩu 10 ký tự có chữ+số → xác nhận trùng → bấm Đăng ký
Expected: Nút bật, gửi request, điều hướng trang chào mừng

TC02 - Email sai định dạng
Steps: Nhập "abc@" → mật khẩu hợp lệ → xác nhận trùng → bấm Đăng ký
Expected: Hiện lỗi "Email không hợp lệ", nút Đăng ký tắt

TC03 - Mật khẩu dưới 8 ký tự
Steps: Email hợp lệ → password 7 ký tự → xác nhận trùng
Expected: Lỗi "Mật khẩu 8-20 ký tự, gồm chữ và số"

TC04 - Mật khẩu thiếu số
Steps: Email hợp lệ → password chỉ chữ → xác nhận trùng
Expected: Lỗi "Mật khẩu cần chữ và số"

TC05 - Xác nhận mật khẩu không khớp
Steps: Password hợp lệ → confirm khác 1 ký tự
Expected: Lỗi "Mật khẩu không khớp"

TC06 - Trim khoảng trắng
Steps: Email có khoảng trắng cuối "[email protected]  " → mật khẩu hợp lệ → xác nhận trùng
Expected: Email được trim, nếu còn sai báo lỗi

Thấy khó ở đoạn phân lớp và mép biên là bình thường. Mẹo nhỏ: bọc dữ liệu ở ngưỡng 7-8-9 và 19-20-21 ký tự để bắt gọn mép. Tải template kèm đáp án gợi ý: Tải bộ đề luyện (Excel).

Tìm bug từ giao diện: case giỏ hàng mini

Đề bài dạng này thường cho ảnh hoặc sandbox. Kịch bản mẫu: Giỏ hàng trên web di động có tên sản phẩm, ảnh, giá, tăng giảm số lượng, tổng tiền, nút Thanh toán. Hãy tìm lỗi và viết bug report rõ ràng.

Cách tiếp cận: quét từ trên xuống, trái sang phải; thay đổi state tăng-giảm-xóa; thử dữ liệu lạ; kiểm tra tính nhất quán giá và đơn vị. Ghi trọng tâm vào tính tái hiện và mức độ ảnh hưởng.

Nhóm lỗi song song giúp không bỏ sót khi rà từng hạng mục

Mẫu bug report ngắn gọn, đủ tái hiện:

BUG01 - Nút Giảm cho về -1
Steps: Mở giỏ hàng có 1 sản phẩm → bấm "-" hai lần
Expected: Min = 1, nút "-" disabled khi =1
Actual: Số lượng = -1, tổng tiền âm
Severity: High | Priority: P1

BUG02 - Giá hiển thị khác giá tính tổng
Steps: Sản phẩm giá 99.900 → tăng số lượng 2
Expected: Tổng = 199.800
Actual: Tổng = 199.900
Severity: High | Priority: P1

BUG03 - VND không có phần thập phân
Steps: Xem giá
Expected: '99.900 ₫'
Actual: '99.900,00 ₫'
Severity: Medium | Priority: P2

BUG04 - Nút Thanh toán không bật khi hợp lệ
Steps: Có sản phẩm hợp lệ
Expected: Nút bật
Actual: Nút vẫn disabled
Severity: High | Priority: P1

BUG05 - Ảnh vỡ trên màn 320px
Steps: Mở thiết bị 320px
Expected: Ảnh co giãn, không tràn
Actual: Ảnh tràn viền
Severity: Medium | Priority: P2

Bạn có thể mở file HTML có sẵn lỗi để luyện tay và đo thời gian như thi thật: Tải trang HTML buggy để luyện. Tham khảo mẫu bug trên Jira: Mẫu bug trên Jira - Atlassian.

Chấm điểm và cách trả lời để ăn điểm

Giám khảo chấm gì? Trước hết là độ rõ ràng. Câu ngắn, expected cụ thể, không mơ hồ. Tiếp theo là mức bao phủ: có đủ happy path, negative, edge. Thứ ba là ưu tiên đúng: P0-P1 cho rủi ro ảnh hưởng tới người dùng và doanh thu. Cuối cùng là tính tái hiện và tính đúng nghiệp vụ.

Trade-off: viết thật nhiều case không bằng chọn đúng case quan trọng. Nếu thời gian hạn chế, chốt 8-12 case chất lượng, đánh dấu Priority, rồi bổ sung nếu còn thời gian. Với bug report, giữ mẫu cố định: Title ngắn gọn, Steps đánh số, Expected đối chiếu sát nghiệp vụ, Actual trung lập không phán xét.

Một mẹo nhỏ: sau khi hoàn tất, đọc lại như người chưa biết gì. Bạn có thể tái hiện 100% theo Steps không? Nếu không, thêm dữ liệu test, trạng thái ban đầu, hoặc ảnh chụp.

Rõ ràng và ưu tiên đúng thường quyết định kết quả chấm điểm

Takeaway: viết cho người khác hiểu ngay. Tester giỏi là người làm cho người khác tái hiện được lỗi nhanh nhất.

Lộ trình 7 ngày luyện tập để pass ngay

Ngày 1: Ôn thuật ngữ cốt lõi, đặc biệt severity và priority, phân lớp tương đương và mép biên. Viết lại định nghĩa bằng lời của bạn, ví dụ 1 dòng cho mỗi thuật ngữ.

Ngày 2: Luyện đọc yêu cầu. Chọn 1 form phổ biến như đăng ký, thêm địa chỉ. Gạch chân điều kiện ràng buộc, ghi rõ expected theo nghiệp vụ.

Ngày 3: Viết 10-12 test case cho form đã chọn. Rà soát bằng checklist: có happy path, negative, edge, dữ liệu ngưỡng.

Ngày 4: Luyện bug finding trên trang HTML buggy. Bấm giờ 30-45 phút, viết tối thiểu 5 bug report có Steps-Expected-Actual. File ở đây: Trang buggy luyện bug finding.

Ngày 5: Rà soát và chấm chéo. Nhờ bạn khác tái hiện theo Steps của bạn. Nếu không làm được, bổ sung dữ liệu, trạng thái ban đầu.

Ngày 6: Thử 1 bài API đơn giản trên Postman, như đăng nhập trả token và lỗi 400 khi sai định dạng. Ghi lại 4-6 test case và 1 bug giả lập.

Ngày 7: Thi thử. 60 phút: 50 phút làm, 10 phút soát. Quy tắc 4 kiểm: tên rõ, steps đánh số, expected đo được, ưu tiên đánh dấu.

Nguồn thực hành và cộng đồng hỏi đáp: Group Testing VN (Facebook). Muốn theo dõi tiến độ, tải checklist gọn để tick từng ngày: Tải checklist 7 ngày (Markdown).

Giữ nhịp 7 ngày liên tục giúp tạo thói quen tốt

Tóm lại, để bắt đầu vững vàng:

• Luyện viết 10 test case cho 1 form quen thuộc mỗi ngày
• Luyện bug report với 1 trang buggy có chủ đích
• Đánh dấu Priority, lý do chọn P0-P1
• Soát 10 phút cuối trước nộp bài