Viết Test Case Chuẩn: Template Đơn Giản Cho Tester Không Kinh Nghiệm

6 tháng trước · 13 phút đọc

Test case là gì - và tại sao viết sai lại nguy hiểm

Mình nhớ lần đầu được giao viết test case cho tính năng đăng nhập. Nghĩ đơn giản: nhập đúng email + password thì vào được, sai thì báo lỗi. Xong. Submit.

Kết quả? Dev hỏi: "Bạn có test trường hợp password có khoảng trắng ở đầu không?" Mình không biết trả lời gì.

Bug đó lên production. Người dùng nhập password có khoảng trắng - app đăng nhập thành công dù sai. Security issue nhỏ nhưng đủ để team mất 1 buổi chiều fix.

Test case là tài liệu mô tả: bạn sẽ kiểm tra tính năng nào, làm thế nào, và kết quả mong đợi là gì. Nó không chỉ để bạn nhớ mình cần test gì - mà để người khác đọc vào cũng reproduce được, dev đọc vào hiểu bug xảy ra ở đâu, và QA Lead dùng để track tiến độ.

343006 Test case kém = bug lọt production, team mất thêm ngày fix

Nếu test case viết mơ hồ - "test chức năng đăng nhập" không kèm bước cụ thể - thì người làm sau bạn sẽ test theo cách của họ, không phải theo cách bạn nghĩ. Gap đó là nơi bug trốn.

Viết test case kỹ không phải để làm màu. Mà vì đó là lưới chặn bug trước khi user thấy.

Cấu trúc một test case chuẩn gồm những gì?

Nhiều bạn mới hỏi: "Test case cần bao nhiêu cột?" Câu trả lời là: đủ để người đọc hiểu và thực hiện được, không thừa không thiếu.

Dưới đây là cấu trúc mình dùng cho mọi dự án web app - đơn giản, đủ dùng:

Trường	Giải thích	Ví dụ
Test Case ID	Mã định danh duy nhất	TC_LOGIN_001
Tên test case	Mô tả ngắn mục đích	Đăng nhập thành công với email hợp lệ
Module	Phần chức năng đang test	Authentication
Điều kiện tiên quyết	Cần chuẩn bị gì trước khi test	Có tài khoản đã đăng ký, đang ở trang login
Bước thực hiện	Làm từng bước một, đánh số	1. Mở trình duyệt Chrome...
Dữ liệu đầu vào	Input cụ thể	Email: [email protected] / Pass: Test@123
Kết quả mong đợi	Expected result	Chuyển hướng sang /dashboard, hiển thị tên user
Kết quả thực tế	Điền sau khi chạy test	(để trống, điền khi test)
Trạng thái	Pass / Fail / Blocked	Pass
Ghi chú	Thông tin thêm nếu có	Đã test trên Chrome 124

343007 Cấu trúc này đủ dùng cho 90% dự án web app fresher sẽ gặp

Một lưu ý quan trọng: "Kết quả mong đợi" là cột quan trọng nhất. Đây là nơi người mới hay viết chung chung nhất - kiểu "hệ thống hoạt động bình thường" hay "đăng nhập được". Sai.

Kết quả mong đợi phải cụ thể đến mức: URL đổi thành gì, màn hình hiển thị gì, toast notification nói gì, response trả về mã HTTP bao nhiêu. Mình từng bị QA Lead trả lại 5 test case chỉ vì cột này quá mơ hồ.

Đọc requirement như thế nào để không bỏ sót test case?

Phần này ít ai dạy. Hầu hết tutorial nhảy thẳng vào viết test case mà không nói bạn phân tích requirement như thế nào. Kết quả: bạn viết được 3 test case, QA Lead hỏi "tại sao không test trường hợp này" - bạn mới giật mình.

Khi nhận requirement, mình đọc theo 4 câu hỏi:

1. Ai dùng tính năng này? - Xác định actor (người dùng thường, admin, khách chưa đăng nhập). Mỗi actor có thể có luồng khác nhau.

2. Happy path là gì? - Luồng chính khi mọi thứ đúng. Đây là test case đầu tiên bạn viết.

3. Có thể sai ở đâu? - Input sai, thiếu dữ liệu, điều kiện biên. Đây là nguồn gốc của negative test case.

4. Requirement nói gì nhưng không nói? - Những điều ngầm hiểu. Ví dụ: requirement nói "user đăng nhập bằng email" nhưng không nói phải xử lý email có chữ hoa/thường. Đây là nơi bug ẩn.

343008 4 câu hỏi này giúp mình không bỏ sót test case quan trọng

Mình lấy ví dụ thực tế: requirement cho chức năng đăng nhập web app viết là "Người dùng nhập email và password, nhấn Login, hệ thống xác thực và cho vào hệ thống".

Nghe có vẻ đủ. Nhưng nếu áp 4 câu hỏi trên:

"Có thể sai ở đâu?": email sai format, password sai, account bị khóa, hết session, server down
"Requirement không nói?": giới hạn số lần login sai, có remember me không, thời gian session bao lâu

Chỉ từ 1 câu requirement, bạn đã có thể ra 8-10 test case. Test kỹ từ đầu, không phải fix bug cuối.

Positive vs negative test case - sự khác biệt mà người mới hay nhầm

Bạn từng nghĩ: "Test positive xong là xong"? Mình cũng từng vậy. Cho đến khi nhận bug report từ user: họ nhập email không có @ và hệ thống vẫn gửi email reset password. Negative case mình đã bỏ qua.

Positive test case là khi bạn cung cấp đúng input, đúng điều kiện, và kiểm tra hệ thống làm đúng việc phải làm. Đây là "happy path".

Negative test case là khi bạn cố tình cung cấp input sai, thiếu, hoặc không hợp lệ để kiểm tra hệ thống xử lý lỗi có đúng không.

Nhìn ví dụ cụ thể cho tính năng đăng nhập:

Positive cases:

Đăng nhập với email hợp lệ + password đúng → redirect về dashboard
Email hợp lệ + password đúng + tick "Remember Me" → session giữ sau khi đóng tab

Negative cases:

Email hợp lệ + password sai → hiển thị "Mật khẩu không đúng", không vào được
Email sai format (thiếu @) → hiển thị "Email không hợp lệ" ngay lập tức
Email đúng format nhưng chưa đăng ký → hiển thị "Tài khoản không tồn tại"
Bỏ trống email → hiển thị "Vui lòng nhập email"
Đăng nhập sai 5 lần → khóa tài khoản 15 phút (nếu có feature này)
Password có khoảng trắng ở đầu → xử lý thế nào? Trim hay báo sai?

343009 Negative case thường nhiều hơn positive - đó là dấu hiệu bạn test đủ kỹ

Tỉ lệ thực tế: với một chức năng trung bình, mình thường có 2-3 positive case và 5-8 negative case. Nếu số negative của bạn ít hơn positive - hãy ngồi lại phân tích thêm.

Ngoài positive và negative, còn có boundary value testing (kiểm thử giá trị biên) - ví dụ: password yêu cầu 8-20 ký tự, thì bạn phải test 7 ký tự (dưới min), 8 ký tự (đúng min), 20 ký tự (đúng max), 21 ký tự (vượt max). Đây là nơi bug hay xuất hiện nhất.

Viết test case thực tế: ví dụ đầy đủ cho chức năng đăng ký

Lý thuyết xong rồi. Mình sẽ viết trực tiếp 3 test case hoàn chỉnh cho chức năng đăng ký tài khoản - loại tính năng gần như app nào cũng có và thường xuất hiện trong bài test đầu vào.

Requirement giả định: "Người dùng đăng ký bằng email và password. Email phải hợp lệ, chưa được dùng. Password tối thiểu 8 ký tự, có chữ hoa và số. Sau đăng ký, gửi email xác nhận."

TC_REG_001 - Đăng ký thành công với dữ liệu hợp lệ

Module: Registration
Điều kiện tiên quyết: Mở trang /register, email [email protected] chưa tồn tại trong hệ thống
Bước thực hiện:
1. Nhập email: [email protected]
2. Nhập password: Test@1234
3. Nhập confirm password: Test@1234
4. Nhấn nút "Đăng ký"
Kết quả mong đợi: Hiển thị thông báo "Đăng ký thành công! Vui lòng kiểm tra email để xác nhận.", URL chuyển về /register/success, email xác nhận gửi đến [email protected] trong vòng 2 phút
Trạng thái: (chưa test)

TC_REG_002 - Đăng ký với email đã tồn tại

Module: Registration
Điều kiện tiên quyết: Email [email protected] đã có trong hệ thống
Bước thực hiện:
1. Nhập email: [email protected]
2. Nhập password: Test@1234
3. Nhập confirm password: Test@1234
4. Nhấn nút "Đăng ký"
Kết quả mong đợi: Hiển thị lỗi inline ngay dưới trường email: "Email này đã được đăng ký. Vui lòng dùng email khác.", form không submit, user vẫn ở trang /register
Trạng thái: (chưa test)

TC_REG_003 - Password không đủ 8 ký tự

Module: Registration
Điều kiện tiên quyết: Đang ở trang /register
Bước thực hiện:
1. Nhập email: [email protected]
2. Nhập password: Ab@1234 (7 ký tự, dưới mức tối thiểu)
3. Nhập confirm password: Ab@1234
4. Nhấn nút "Đăng ký"
Kết quả mong đợi: Hiển thị lỗi validation: "Mật khẩu phải có ít nhất 8 ký tự", form không submit
Trạng thái: (chưa test)

343010 3 test case này đủ để bạn hiểu cấu trúc - áp dụng tương tự cho các tính năng khác

Bạn thấy không - mỗi test case chỉ test một kịch bản duy nhất. Đừng nhồi nhiều trường hợp vào một test case. Lý do: khi fail, bạn cần biết chính xác bước nào sai. Nếu test case ôm 3 kịch bản, fail rồi bạn phải ngồi đoán.

5 sai lầm phổ biến khi viết test case lần đầu

Mình tổng hợp từ kinh nghiệm review test case của các bạn mới - đây là 5 lỗi xuất hiện nhiều nhất.

Sai lầm 1: Bước thực hiện quá mơ hồ

Viết "mở trang đăng nhập" không đủ. Phải là: "Mở trình duyệt Chrome, truy cập https://demo.app.vn/login". Lý do: environment khác nhau có thể cho kết quả khác nhau. Tester khác cần biết chính xác họ đang test ở đâu.

Sai lầm 2: Kết quả mong đợi chung chung

"Hệ thống xử lý đúng" không phải kết quả mong đợi. Phải viết: "Hiển thị toast notification màu đỏ: 'Mật khẩu không đúng', nút Login không bị disable, cursor focus về trường password."

Sai lầm 3: Một test case ôm nhiều kịch bản

Viết "test email sai, password sai, bỏ trống" vào cùng một test case. Khi fail không biết cái nào gây ra. Tách ra 3 test case riêng.

Sai lầm 4: Quên điều kiện tiên quyết

Test case "đăng nhập tài khoản admin" mà không ghi rõ tài khoản admin đó là gì, đang ở trạng thái nào. Người test sau phải tự đoán.

Sai lầm 5: Chỉ viết positive case

Đây là lỗi phổ biến nhất. Mình hay hỏi bạn mới: "Bạn có test trường hợp user nhập xong rồi xóa đi không? Nhập toàn dấu cách không? Copy-paste từ Word vào không?" Thường là chưa.

343011 Fix 5 lỗi này trước khi nộp bài test đầu vào - sẽ tạo ra khác biệt lớn

Một mẹo nhỏ: sau khi viết xong test case, thử nhờ bạn khác đọc và thực hiện theo đúng những gì bạn viết - không giải thích thêm. Nếu họ làm sai hoặc hỏi nhiều → test case bạn chưa đủ rõ.

Đây không phải tiêu chuẩn cao. Đây là mức tối thiểu để test case có ích.

Template Excel miễn phí và cách dùng ngay hôm nay

Đủ lý thuyết rồi. Phần này mình đưa thẳng vào tool.

Mình đã chuẩn bị sẵn template Excel cho bạn - có đầy đủ các cột cần thiết, ví dụ mẫu điền sẵn để bạn hiểu format, và tab hướng dẫn ngắn. Tải về và dùng luôn, không cần tạo từ đầu.

Tải Template Test Case Excel Miễn Phí

343012 Template này đủ dùng cho bài test đầu vào và 3-6 tháng làm việc đầu tiên

Ngoài template, nếu bạn muốn học bài bản về kiểm thử phần mềm từ đầu - từ test case, bug report đến manual testing thực chiến - khóa Kiểm thử phần mềm có thể giúp bạn đi nhanh hơn nhiều so với tự mày mò. Khóa được thiết kế cho người chuyển ngành, không yêu cầu kiến thức IT trước.

Cách dùng template ngay hôm nay:

Bước 1: Tải template về, mở bằng Excel hoặc Google Sheets.

Bước 2: Chọn 1 tính năng của bất kỳ app nào bạn đang dùng - Shopee, Facebook, ứng dụng ngân hàng. Thực hành trên app thật hiệu quả hơn app demo.

Bước 3: Viết ít nhất 5 test case - 2 positive, 3 negative. Không cần nhiều, cần kỹ.

Bước 4: Nhờ người khác đọc và "chạy" theo test case bạn viết. Xem họ có hiểu không.

Bước 5: Sửa lại những chỗ họ bị hỏi hoặc làm sai.

Lặp lại 3-5 lần với các tính năng khác nhau. Đó là cách mình luyện khi mới vào nghề.

Testing không khó. Phần khó nhất là giữ tỉ mỉ trong từng test case, không rush để xong nhanh. Nhưng nếu bạn đọc đến đây - mình tin bạn đã hiểu tại sao kỹ quan trọng hơn nhanh.

Test kỹ 1 lần > fix lỗi nhiều lần. Comment bên dưới nếu bạn có câu hỏi - mình trả lời từng bạn.