Đọc ngắn. Thử ngay. Sửa có lý do.

01 · TESTING CƠ BẢN · CẬP NHẬT 10/2026

Từ yêu cầu đến câu hỏi làm rõ

Mục tiêu: phát hiện thông tin còn thiếu trước khi viết test case. Giả sử sản phẩm ghi: “Người dùng đăng nhập bằng email và mật khẩu hợp lệ.” Câu này chưa cho biết email nào được xem là hợp lệ, lỗi được hiển thị ra sao, tài khoản chưa kích hoạt xử lý thế nào hay có giới hạn số lần thử không.

Tester ghi mỗi điểm chưa rõ thành một câu hỏi có thể được trả lời. Sau khi có câu trả lời, biến nó thành điều kiện đầu vào và kết quả mong đợi. Điều chưa được xác nhận phải được đánh dấu là giả định.

02 · TESTING CƠ BẢN · CẬP NHẬT 10/2026

Viết test case để người khác chạy lại được

Mục tiêu: nối một điều kiện với một kết quả có thể kiểm tra. Ví dụ sau khi xác nhận hệ thống từ chối email trống, test case nên có tiền điều kiện, dữ liệu, thao tác và kết quả mong đợi. “Kiểm tra đăng nhập” là tên quá rộng; “Email trống hiển thị thông báo bắt buộc” nói rõ hành vi.

Không gộp nhiều nguyên nhân thất bại vào một test case nếu khi test sai bạn không biết nguyên nhân nào gây lỗi. Đặt tên theo hành vi người dùng, không theo thứ tự click.

03 · TESTING CƠ BẢN · CẬP NHẬT 10/2026

Chọn dữ liệu quanh giá trị biên

Mục tiêu: tập trung vào điểm hành vi có thể đổi. Giả sử tuổi hợp lệ từ 18 đến 60, bao gồm cả hai đầu. Bộ dữ liệu nhỏ có giá trị là 17, 18, 19, 59, 60 và 61. Các điểm 17/18 và 60/61 giúp kiểm tra điều kiện loại trừ và chấp nhận.

Giá trị biên không thay thế các loại dữ liệu khác: ô trống, ký tự chữ, số thập phân và giá trị rất lớn cần được xét theo đặc tả của sản phẩm.

04 · TESTING CƠ BẢN · CẬP NHẬT 10/2026

Báo lỗi để đồng đội tái hiện

Mục tiêu: tách kết quả thực tế khỏi kết quả mong đợi. Một bug report tốt ghi môi trường, trạng thái trước khi chạy, dữ liệu dùng, bước tái hiện, kết quả thực tế, kết quả mong đợi và bằng chứng. Mức độ nghiêm trọng là nhận định có căn cứ; tránh tự gán “critical” cho mọi lỗi.

Ví dụ: form nhận tuổi 17 dù quy tắc đã xác nhận là từ 18. Kết quả thực tế phải nêu form đã lưu và hiển thị thành công; kết quả mong đợi là form từ chối và giải thích lỗi.

05 · WEB & API · CẬP NHẬT 10/2026

Kiểm tra API ngoài mã trạng thái 200

Mục tiêu: đọc hợp đồng API và kiểm tra hành vi, không chỉ nhìn HTTP status. Một yêu cầu tạo tài khoản có thể trả 201, nhưng tester vẫn cần xem cấu trúc phản hồi, dữ liệu đã được lưu đúng chưa, thông tin nhạy cảm có bị trả lại không và yêu cầu lặp có tạo bản ghi trùng không.

Với lỗi đầu vào, kiểm tra mã trạng thái phù hợp, thông báo có ích, và trạng thái hệ thống sau yêu cầu. Chỉ dùng môi trường cùng dữ liệu bạn được phép kiểm thử.

06 · AUTOMATION · CẬP NHẬT 10/2026

Chọn locator ổn định cho Selenium C#

Mục tiêu: tìm đúng phần tử theo dấu hiệu ít thay đổi. Thuộc tính định danh được sản phẩm duy trì, như id hoặc data-testid, thường dễ hiểu hơn XPath dựa trên vị trí. CSS selector và XPath vẫn có ích khi cần mô tả quan hệ giữa các phần tử.

var submit = driver.FindElement(By.CssSelector("[data-testid='login-submit']"));
submit.Click();

Không dùng FindElement để kiểm tra sự vắng mặt mà không xử lý ngoại lệ; nếu muốn đếm kết quả, dùng FindElements và kiểm tra số lượng.

07 · AUTOMATION · CẬP NHẬT 10/2026

Assertion kiểm tra hành vi, không chỉ thao tác

Mục tiêu: một test chỉ có click và nhập liệu chưa chứng minh sản phẩm chạy đúng. Với form tuổi, sau khi gửi giá trị 17, assertion cần kiểm tra thông báo hoặc trạng thái bị từ chối theo yêu cầu. Chờ điều kiện hiển thị thay vì ngủ cố định rồi đoán.

var error = wait.Until(d =>
    d.FindElement(By.Id("age-error")));
Assert.That(error.Text, Does.Contain("18"));

Đây là ví dụ minh họa. Locator và câu chữ phải thay theo ứng dụng demo được phép kiểm thử.