Phỏng vấn Automation QA: sửa test chập chờn bằng một giả thuyết

Tăng thời gian chờ chưa phải lời giải thích

Trong một bài phỏng vấn giả định, test tìm kiếm thỉnh thoảng thất bại trên CI nhưng luôn đạt khi chạy riêng. Ứng viên được yêu cầu sửa. Thêm vài giây chờ có thể làm lần chạy tiếp theo xanh, nhưng chưa cho thấy đã hiểu nguyên nhân. Bài tập này là cơ hội trình bày cách điều tra, chọn bằng chứng và thiết kế một phép kiểm đáng tin.

Bắt đầu bằng việc diễn đạt mục tiêu: sau khi gửi từ khóa, người dùng phải thấy kết quả của chính yêu cầu ấy. Hỏi dữ liệu có ổn định không, test có dùng chung tài khoản không và lỗi xuất hiện ở bước nào. Nếu chưa được cung cấp log hoặc trace, nêu những gì cần xem. Tránh chọn giải pháp trước khi xác định điều đang thất bại.

Tách lỗi sản phẩm, lỗi test và lỗi môi trường

Đọc mã theo thứ tự: tạo dữ liệu, mở trang, nhập từ khóa, gửi yêu cầu và xác nhận kết quả. Tìm chỗ dùng dữ liệu có thể bị test khác sửa, bộ chọn phụ thuộc thứ tự hoặc kiểm tra quá sớm. Giữ mỗi nhận xét ở mức giả thuyết cho đến khi có bằng chứng. Việc gọi mọi thất bại trên CI là “chậm máy” dễ bỏ qua lỗi thật.

Giả sử bằng chứng cho thấy phép xác nhận đang đọc danh sách cũ trước khi yêu cầu mới hoàn tất. Hãy chọn dấu hiệu sẵn sàng gắn với kết quả cần kiểm tra. Đó có thể là nội dung mong đợi hoặc trạng thái giao diện có nghĩa rõ trong ứng dụng. Chờ một khoảng cố định không chứng minh đúng yêu cầu đã hoàn tất và còn làm chậm những lần vốn đã sẵn sàng.

Kiểm tra bộ chọn có phân biệt đúng vùng kết quả và đúng phần tử không. Bộ chọn ngắn không tự tốt hơn bộ chọn dài; tiêu chí là rõ ý nghĩa, ổn định và tránh khớp nhầm. Nếu trang có nhiều ô tìm kiếm, hãy giới hạn ngữ cảnh. Giải thích vì sao cách chọn phản ánh hành vi sản phẩm thay vì chỉ bám vào cấu trúc tình cờ của giao diện.

Làm dữ liệu và phần xác nhận đủ độc lập

Tạo dữ liệu riêng cho trường hợp đang thử hoặc dùng bộ dữ liệu cố định được quản lý rõ. Ghi cách dọn để lần chạy sau không nhận thêm kết quả ngoài dự kiến. Nếu test dùng API để chuẩn bị, cần kiểm tra bước tạo đã thành công trước khi tiếp tục. Một phần chuẩn bị thất bại nhưng bị bỏ qua có thể xuất hiện thành lỗi tìm kiếm ở bước cuối.

Xem phép xác nhận có bắt được hành vi sai không. Kiểm tra “có kết quả” có thể vẫn đạt khi giao diện hiển thị danh sách cũ hoặc tìm sai từ khóa. Chọn dữ liệu giúp phân biệt kết quả đúng với kết quả dễ nhầm. Có thể thử thay đổi đầu vào để chứng minh phép kiểm sẽ thất bại khi điều kiện nghiệp vụ không còn được đáp ứng.

Khi tổ chức mã, chỉ tách phần dùng chung có trách nhiệm rõ. Một lớp bọc có thể giấu thao tác hoặc nuốt lỗi, khiến bài test ngắn hơn nhưng khó điều tra hơn. Trình bày lựa chọn giữa hàm hỗ trợ, dữ liệu chuẩn bị và phần xác nhận theo quy mô bài toán. Không cần dựng một kiến trúc lớn chỉ để chứng minh biết tên một mẫu thiết kế.

Xác nhận bản sửa trong điều kiện từng gây lỗi

Chạy lại cùng điều kiện, rồi xem khi chạy song song hoặc theo bộ có còn phụ thuộc không. Giữ bằng chứng của lần lỗi và lần kiểm tra sau sửa. Một số lần đạt liên tiếp chỉ tăng độ tin cậy trong phạm vi quan sát; chúng không chứng minh mọi nguyên nhân chập chờn đã biến mất. Nếu chưa đủ điều kiện, nêu rõ phần còn cần xác nhận.

Trong buổi phỏng vấn, giải thích giả thuyết, lý do chọn thay đổi và cách biết thay đổi có tác dụng. Nếu không nhớ cú pháp, có thể nói rõ ý định rồi kiểm tra tài liệu được phép dùng. Người nghe cần thấy khả năng viết phép kiểm đúng và điều tra có căn cứ. Một lần đạt cần được giải thích bằng phép kiểm phù hợp với rủi ro.

Về nguồn tham khảo

Chủ đề tham khảo từ bộ AI Tester Skills. Bài viết và tình huống minh họa được biên soạn lại cho người đọc.