Bài test đầu vào Tester dạng gì? Cách xử lý test case và SQL trong 30 phút

Bài in-test của tester trông như thế nào?

Nhiều bạn chuẩn bị kỹ lý thuyết, luyện trả lời câu hỏi phỏng vấn, rồi đến vòng làm bài test thì... lúng túng vì không biết đề dạng gì. Mình hiểu cảm giác đó, vì mình cũng từng không biết mình sẽ phải viết gì trong 45 phút đó.

Bài test đầu vào cho vị trí tester fresher thường gồm 3 phần chính:

Phần 1 - Viết test case (chiếm nhiều điểm nhất): Cho một tính năng hoặc trang web cụ thể, yêu cầu bạn viết test case. Ví dụ: "Viết test case cho trang đăng nhập" hoặc "Viết test case cho chức năng thêm sản phẩm vào giỏ hàng".

Phần 2 - SQL cơ bản: Cho sẵn cấu trúc bảng dữ liệu, yêu cầu viết câu query để lấy dữ liệu theo điều kiện. Thường 3-5 câu, không phức tạp.

Phần 3 - Câu hỏi lý thuyết ngắn: Định nghĩa một số khái niệm testing, phân biệt các loại testing, hoặc mô tả quy trình báo cáo bug.

Phân bổ thời gian hợp lý là chìa khóa để hoàn thành đủ 3 phần

Thời gian thường là 30-60 phút. Công ty nhỏ hay startup thường cho 30 phút. Công ty lớn hơn có thể 45-60 phút. Mình sẽ hướng dẫn theo mốc 30 phút để bạn luyện tập trong điều kiện chặt nhất.

Một điểm quan trọng: không có đề thi nào yêu cầu bạn hoàn hảo. Họ muốn xem bạn tư duy có logic không, có bỏ sót điều kiện quan trọng không, và có trình bày rõ ràng không. Bạn không cần 10/10, bạn cần cho thấy bạn biết cách nghĩ như một tester.

Phần viết test case: đừng lao vào viết ngay

Đây là phần chiếm nhiều điểm nhất và cũng là phần nhiều bạn mắc lỗi nhất - không phải vì không biết viết, mà vì đọc đề qua loa rồi viết thẳng.

Mình khuyên bạn dành 3-5 phút đầu chỉ để đọc và phân tích yêu cầu. Đọc kỹ xem:

• Tính năng này làm gì? (Mục đích)
• Input là gì? (Người dùng nhập/chọn gì)
• Output mong đợi là gì? (Hệ thống phản hồi gì)
• Có điều kiện đặc biệt không? (Giới hạn ký tự, định dạng, quyền truy cập)

Ví dụ thực tế: Đề bài yêu cầu "Viết test case cho trang đăng nhập". Trước khi viết, bạn cần xác định: trang đăng nhập có những trường nào? (email + password), có nút "Quên mật khẩu" không?, có giới hạn số lần đăng nhập sai không?

Nếu đề không nói rõ, bạn có thể giả định hợp lý và ghi chú "Giả định: password tối thiểu 8 ký tự". Người chấm bài đánh giá cao sự chủ động này.

Đọc kỹ requirement 3 phút tiết kiệm được 10 phút sửa test case

Cấu trúc test case chuẩn

Mỗi test case cần có:

Đừng quên 3 nhóm test case này

Bài test fresher thường bị thiếu 2 nhóm cuối:

Positive test case - Đầu vào đúng, kết quả đúng:

• Đăng nhập với email + password hợp lệ → thành công

Negative test case - Đầu vào sai, hệ thống phải xử lý đúng:

• Email không tồn tại → thông báo lỗi phù hợp
• Password sai → thông báo lỗi, không tiết lộ "email đúng, password sai"
• Để trống email hoặc password → thông báo yêu cầu nhập

Edge case - Ranh giới, trường hợp đặc biệt:

• Password đúng số ký tự tối thiểu (8 ký tự)
• Email chứa ký tự đặc biệt hợp lệ (tên+địa.chỉ@domain.com)
• Copy-paste khoảng trắng vào email
• Nhấn Enter thay vì nhấn nút Đăng nhập

Mình từng bỏ qua edge case "copy-paste khoảng trắng" và bug đó nổ production. Từ đó mình thêm vào checklist mặc định của mình. Không cần viết đủ 20 test case nếu không kịp, nhưng ít nhất phải có đủ 3 nhóm với 2-3 case mỗi nhóm.

Phần SQL: 5 câu query cần nhớ trước khi vào phòng thi

Bạn không cần biết code để làm tester, nhưng SQL thì khác. Tester cần SQL để kiểm tra dữ liệu sau khi thực hiện các thao tác - ví dụ sau khi đăng ký tài khoản, bạn cần query vào database xem dữ liệu có được lưu đúng không.

Bài test fresher thường cho sẵn cấu trúc bảng như này:

-- Bảng users
users (id, name, email, created_at, status)

-- Bảng orders
orders (id, user_id, total_amount, status, created_at)

Rồi yêu cầu bạn viết query theo điều kiện. Đây là 5 dạng câu hỏi phổ biến nhất:

Nắm 5 dạng này là đủ cho 90% bài SQL trong bài test fresher

Dạng 1: Lấy tất cả hoặc theo điều kiện

-- Lấy tất cả user đang active
SELECT * FROM users
WHERE status = 'active';

-- Lấy tên và email của user tạo sau ngày 1/1/2024
SELECT name, email FROM users
WHERE created_at > '2024-01-01';

Dạng 2: Sắp xếp kết quả

-- Lấy 10 đơn hàng gần nhất
SELECT * FROM orders
ORDER BY created_at DESC
LIMIT 10;

-- Lấy đơn hàng sắp xếp theo tổng tiền từ cao xuống thấp
SELECT * FROM orders
ORDER BY total_amount DESC;

Dạng 3: Đếm và tính tổng

-- Đếm số user đang active
SELECT COUNT(*) FROM users
WHERE status = 'active';

-- Tính tổng doanh thu từ đơn hàng đã hoàn thành
SELECT SUM(total_amount) FROM orders
WHERE status = 'completed';

Dạng 4: Kết hợp 2 bảng (JOIN)

Đây là phần nhiều bạn ngại nhất. Hiểu đơn giản: JOIN như việc ghép 2 tờ danh sách lại với nhau theo một cột chung.

-- Lấy tên user kèm số đơn hàng của họ
SELECT u.name, COUNT(o.id) AS total_orders
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id, u.name;

LEFT JOIN nghĩa là: lấy tất cả user, kể cả user chưa có đơn hàng nào. Ngược lại INNER JOIN chỉ lấy user có ít nhất 1 đơn hàng.

Dạng 5: Tìm theo nhiều điều kiện

-- User active VÀ tạo trong năm 2024
SELECT * FROM users
WHERE status = 'active'
AND created_at >= '2024-01-01';

-- Đơn hàng đang pending HOẶC processing
SELECT * FROM orders
WHERE status = 'pending'
OR status = 'processing';

-- Viết gọn hơn với IN
SELECT * FROM orders
WHERE status IN ('pending', 'processing');

Nếu SQL vẫn còn mơ hồ, đừng lo. Phần này trong bài test thường chỉ chiếm 20-30% tổng điểm. Làm được 3/5 câu SQL đã tốt hơn rất nhiều so với để trống.

Phần lý thuyết: ngắn nhưng đừng bỏ qua

Phần này thường 3-5 câu hỏi ngắn, mỗi câu trả lời 2-4 dòng là đủ. Không cần viết dài, cần viết đúng và trình bày được ví dụ cụ thể.

Đây là những câu hỏi xuất hiện thường xuyên nhất:

Smoke testing là gì? Kiểm tra nhanh các chức năng cơ bản nhất của ứng dụng sau khi build mới, như bật điện thoại lên xem có sáng không. Ví dụ: sau khi deploy bản mới, chạy test nhanh xem app mở được không, đăng nhập được không, trang chủ hiển thị không. Nếu smoke test fail thì không cần test tiếp, trả lại dev fix.

Regression testing là gì? Kiểm thử hồi quy - tức là test lại các tính năng cũ sau khi có thay đổi, để đảm bảo thay đổi mới không làm hỏng thứ đang chạy tốt. Như kiểm tra lại toàn bộ căn nhà sau khi sửa một phòng.

Bug severity vs bug priority khác nhau thế nào?

• Severity (độ nghiêm trọng): mức độ ảnh hưởng của bug đến hệ thống. Bug crash app = critical. Bug lỗi chính tả = minor.
• Priority (độ ưu tiên): mức độ cần fix gấp. Bug ảnh hưởng VIP client = priority cao dù severity thấp.

Test case vs test scenario khác nhau thế nào?

• Test scenario: mô tả tình huống cần test ở mức cao. Ví dụ: "User đăng nhập thành công"
• Test case: chi tiết từng bước thực hiện, input cụ thể, expected output. Cụ thể hóa test scenario.

Hiểu đúng định nghĩa giúp bạn trả lời mạch lạc, không bị lạc đề

Nếu gặp câu hỏi không chắc, cứ viết theo hiểu biết của mình và thêm ví dụ cụ thể. Người chấm bài thích câu trả lời có ví dụ thực tế hơn định nghĩa học vẹt từ sách.

Quản lý 30 phút: mình làm theo thứ tự này

Đây là thứ tự mình khuyên bạn làm, dựa trên tỷ lệ điểm số thực tế:

Phút 0-2: Đọc toàn bộ đề Đừng làm ngay. Đọc hết đề một lần để biết mình có bao nhiêu câu, phần nào nặng điểm nhất. Nếu đề không ghi điểm, ưu tiên theo thứ tự: test case → SQL → lý thuyết.

Phút 2-18: Viết test case (16 phút) Dành 3 phút phân tích requirement, 13 phút viết. Mục tiêu: 8-12 test case đủ 3 nhóm (positive, negative, edge case). Thà ít mà đủ nhóm hơn nhiều mà chỉ có positive.

Phút 18-27: Làm SQL (9 phút) Đọc cấu trúc bảng, viết query theo thứ tự từ dễ đến khó. Câu nào không chắc thì viết gì đó - không để trống. Viết sai còn được điểm một phần.

Phút 27-29: Câu lý thuyết (2 phút) Viết ngắn, đúng trọng tâm, có ví dụ. Không cần dài.

Phút 29-30: Review nhanh Kiểm tra: test case có kết quả mong đợi chưa? SQL có thiếu dấu chấm phẩy không? Tên bảng có đúng không?

Đừng sa lào một phần quá lâu - bỏ phần khác không điểm rất tiếc

Nếu làm bài 45-60 phút, phân bổ thêm thời gian cho test case và SQL tương ứng. Nguyên tắc vẫn vậy: test case trước, SQL sau, lý thuyết cuối.

5 bài test mẫu để luyện tập ở nhà

Đọc hiểu lý thuyết là một chuyện, làm quen với áp lực thời gian là chuyện khác. Mình khuyên bạn in hoặc mở file này ra, đặt đồng hồ 30 phút và làm thật sự.

Sau khi làm xong, tự review: mình đã viết đủ 3 nhóm test case chưa? SQL có chạy đúng logic không? Câu lý thuyết mình trả lời có ví dụ không?

Đề luyện tập 1 - Mức cơ bản: Viết test case cho tính năng đăng ký tài khoản (họ tên, email, mật khẩu, xác nhận mật khẩu). Viết 3 câu SQL cho bảng users(id, name, email, password, created_at, status): (1) Lấy tất cả user tạo trong tháng này; (2) Đếm số user đang active; (3) Lấy 5 user mới nhất.

Đề luyện tập 2 - Mức cơ bản: Viết test case cho ô tìm kiếm sản phẩm trên trang thương mại điện tử (nhập từ khóa, lọc kết quả). Viết 2 câu SQL cho bảng products(id, name, price, category, stock): (1) Lấy sản phẩm có giá dưới 500,000đ; (2) Lấy sản phẩm còn hàng sắp theo giá từ thấp đến cao.

Đề luyện tập 3 - Mức trung bình: Viết test case cho tính năng đặt hàng (chọn sản phẩm, nhập địa chỉ, chọn thanh toán, xác nhận). Viết SQL cho 2 bảng users và orders(id, user_id, total, status, created_at): Lấy tên user kèm tổng số đơn hàng đã hoàn thành.

Đề luyện tập 4 - Mức trung bình: Viết test case cho API đăng nhập (POST /login nhận email + password, trả về token hoặc lỗi). Viết 3 câu SQL lấy dữ liệu kết hợp từ bảng users và orders.

Đề luyện tập 5 - Mức nâng cao hơn: Viết test case cho tính năng quên mật khẩu (nhập email → nhận link reset → đặt mật khẩu mới). Câu hỏi lý thuyết: phân biệt functional testing và non-functional testing, cho ví dụ mỗi loại.

Thực hành có đồng hồ đếm ngược gần với môi trường thi thật nhất

Bạn tải file bên dưới để luyện tập đề 1-5 có đáp án gợi ý: Tải 5 đề luyện tập kèm đáp án gợi ý

Thấy khó ở bài 3, 4, 5 là bình thường. Mình cũng cần luyện nhiều lần mới quen với áp lực thời gian. Bạn không cần làm đúng hoàn toàn - cần là sau mỗi lần làm, bạn biết mình thiếu gì.