Câu hỏi phỏng vấn Selenium

Bạn từng viết test chạy được ở local nhưng lại fail trên pipeline, và bạn nghi ngờ câu trả lời liên quan đến wait nhưng không thể diễn đạt rõ ràng. Người phỏng vấn biết điều này, nên wait thường mở đầu hầu hết các vòng phỏng vấn Selenium. Phần này nói rõ một câu trả lời đầy đủ nghe như thế nào.

• Implicit wait so với explicit wait. Implicit wait là một cài đặt toàn cục, liên tục kiểm tra sự tồn tại của phần tử mỗi lần tìm kiếm. Explicit wait nhắm vào một phần tử và một điều kiện, chẳng hạn có thể click hoặc hiển thị. Explicit được ưu tiên vì nó nói rõ bạn đang chờ điều gì.
• Vì sao không nên trộn hai loại wait này? Kết hợp cả hai có thể khiến timeout cộng dồn theo cách khó đoán trước, đó là lý do hầu hết các team đặt implicit wait về không và chỉ dùng explicit wait.
• Fluent wait là gì? Một explicit wait có thể cấu hình khoảng thời gian polling và bỏ qua một số loại exception nhất định.
• Vì sao Thread.sleep là sai lầm? Vì nó vô điều kiện. Nó làm chậm một test đáng lẽ sẽ pass và vẫn khiến một test chậm bị fail.
• Nên dùng CSS selector hay XPath? Ưu tiên một thuộc tính định danh ổn định dành riêng cho test, sau đó là CSS vì tính dễ đọc. XPath phát huy tác dụng khi bạn cần đi lên phần tử cha hoặc khớp theo văn bản.
• Điều gì khiến locator dễ vỡ? Tên class được sinh tự động, XPath tuyệt đối, và chọn theo index. Hãy nói bạn sẽ yêu cầu developer thêm gì thay vào đó.

Người phỏng vấn muốn nghe lý do đằng sau mỗi lựa chọn. Chỉ nêu sở thích mà không nói đến cái giá phải trả nghe giống một câu trả lời học thuộc lòng.

Test không ổn định mới là chủ đề thực sự của hầu hết các vòng phỏng vấn automation senior, vì một bộ test mà không ai tin tưởng còn tệ hơn là không có bộ test nào.

• Điều gì gây ra StaleElementReferenceException? Tham chiếu phần tử trỏ đến một node không còn gắn vào trang nữa, thường vì framework đã render lại phần đó của trang. Hãy tìm lại phần tử thay vì tái sử dụng tham chiếu đã lưu.
• Còn ElementNotInteractableException thì sao? Phần tử tồn tại nhưng không thể thao tác được: bị ẩn, bị vô hiệu hóa, bị một lớp phủ che khuất, hoặc nằm ngoài màn hình.
• Xử lý NoSuchElementException như thế nào? Phân biệt vấn đề về thời gian với một phần tử thực sự không tồn tại, và đừng che giấu nó bằng cách kéo dài thời gian chờ.
• Vì sao test chỉ fail trên pipeline? Kích thước viewport khác nhau, môi trường chậm hơn, thiếu dữ liệu test, animation hoàn tất muộn hơn, và các test song song tranh chấp trạng thái dùng chung.
• Sửa một test không ổn định như thế nào? Trước tiên chẩn đoán loại vấn đề, sau đó sửa nguyên nhân. Auto-retry che giấu lỗi và nên được gọi đích danh là biện pháp cuối cùng.
• Xử lý frame, cửa sổ mới và alert như thế nào? Chuyển đổi context một cách tường minh, rồi chuyển lại sau đó.

Một kỹ sư QA ứng tuyển vị trí automation cấp trung bị hỏi vì sao một bộ test fail hai lần mỗi tuần dù không có thay đổi code nào. Câu trả lời được đánh giá cao không phải là chi tiết về API của Selenium, mà là việc các test dùng chung một tài khoản được tạo sẵn duy nhất và cạnh tranh lẫn nhau. Người phỏng vấn đánh giá cao đúng thứ tự chẩn đoán này: môi trường và dữ liệu trước, API sau.

Thêm nhiều bộ câu hỏi theo vai trò và công cụ tại câu hỏi phỏng vấn theo vai trò.

Ngoài API, hội đồng phỏng vấn muốn biết bạn có thể làm chủ một bộ test hay không. Những câu hỏi này có trọng số lớn nhất với vị trí senior.

• Giải thích Page Object Model. Các class Page phơi bày hành động và ẩn locator, nên một thay đổi UI chỉ chạm vào một file. Hãy nói rõ nó giải quyết vấn đề gì; chỉ mô tả cấu trúc thư mục là bỏ lỡ trọng tâm.
• Page Object có thể gặp vấn đề gì? Chúng phình to thành các class hàng nghìn dòng và bắt đầu assertion ngay trong các method của page. Assertion nên thuộc về test.
• Framework của bạn chạy test song song như thế nào? Quản lý driver an toàn với thread để các instance không bị chia sẻ giữa các thread, cộng với dữ liệu test độc lập cho từng test.
• Selenium Grid dùng để làm gì? Để phân phối test trên nhiều máy và phiên bản trình duyệt khác nhau, với một hub và các node, hoặc một nhà cung cấp cloud đảm nhận vai trò tương tự.
• Selenium 4 đã thay đổi những gì? Giao thức W3C WebDriver trở thành chuẩn và JSON wire protocol cũ bị loại bỏ, locator tương đối xuất hiện, và quyền truy cập Chrome DevTools Protocol được mở ra.
• Khi nào không nên dùng Selenium? Kiểm tra ở cấp độ API, logic có thể unit test, và mọi thứ ngoài trình duyệt. Biết được ranh giới này chính là dấu hiệu của một người senior.
• Bạn quyết định automate cái gì như thế nào? Những luồng ổn định, giá trị cao, lặp lại thường xuyên. Không phải tất cả, và không phải một màn hình vẫn đang được thiết kế lại.

Các câu trả lời về Selenium là kiểu bất thường: biết thì dễ mà nói ra thì khó. Đặc biệt câu hỏi về wait có câu trả lời gồm hai phần, định nghĩa và lý do, và những ứng viên chỉ mới đọc qua thường chỉ nói được nửa đầu rồi đuối dần.

Hãy chọn năm câu hỏi ở đây mà bạn ngại đối mặt nhất và trả lời từng câu thành tiếng trong chín mươi giây mà không mở bất kỳ editor nào. Sau đó nhờ ai đó hỏi tiếp câu tiếp theo, gần như luôn luôn là vì sao. Luyện tập cùng những câu hỏi này trước một AI phỏng vấn biết truy vấn ngược lại gần với một vòng phỏng vấn thật hơn nhiều so với việc đọc lại danh sách, và đó chính là lý do tồn tại của chế độ phỏng vấn thử.

Aaron Cao, nhà sáng lập SubcueAI, xây dựng việc luyện tập xoay quanh khoảng cách khi nói ra đó thay vì xoay quanh việc cung cấp thêm câu hỏi. Trong một buổi phỏng vấn thực, ứng dụng desktop và Side Panel của tiện ích trình duyệt có thể hiển thị cấu trúc ngay khi người phỏng vấn đang nói, điều này hữu ích nhất với nội dung bạn đã luyện tập từ trước. Sản phẩm làm được gì, và những giới hạn nó không bao giờ vượt qua, được nêu rõ trên trang bảo mật.