Bài viết này sẽ gửi đến bạn những câu hỏi và gợi ý câu trả lời phỏng vấn giúp cho các bạn tự tin hơn trước buổi phỏng vấn ứng tuyển vào vị trí Tester, nhân viên kiểm thử... Đọc ngay nhé.
1. Giới thiệu bản thân
Gợi ý: Bạn nên giới thiệu ngắn gọn về tên, tuổi của mình. Kinh nghiệm đã từng tham gia vào các dự án.
2. Mô tả về dự án/ hệ thống bạn đang làm ?
Gợi ý: Nên trả lời theo một luồng như dưới đây:
- Dự án/ hệ thống làm về gì? (thuộc domain nào?) mục đích sử dụng cho user
- Dự án có chức năng chính nào (mô tả cụ thể chi tiết theo Flow, luồng xử lý) ? Ứng viên đảm nhiệm tính năng nào, mô tả cụ thể.
- Bài học kinh nghiệm sau khi làm dự án
Ví dụ: Luồng xử lý trong online payment: Chọn hàng cho vào giỏ -> Nhập thông tin thẻ, địa chỉ giao hàng -> Check thông tin hiển thị về giá sản phẩm theo điều kiện Click Thanh toán -> Chuyển giao dịch đến payment provider -> Xác nhận và chuyển thông tin đến payment gateway tương ứng Payment gateway chuyển đến giao dịch payment processor -> Xử lý giao dịch -> Trả kết quả về payment gateway -> Cập nhật tài khoản người mua và người bán -> Trả kết quả cho website bán hàng
- Giao dịch thành công: Tài khoản người bán, bên vận chuyển được cộng tiền, tài khoản người mua bị trừ tiền, Trả về thông báo thành công trên website bán hàng
- Giao dịch thất bại: Trả về kết quả cho payment gateway và website bán hàng
- Giao dịch pending: Hiển thị loading icon, trả về thông báo sự cố cho người dùng
3. Test plan gồm những thông tin gì?
Gợi ý: Test plan sẽ có những mục chính sau:
- Testscope: Xác định những gì sẽ được test (UI/Function/Validation/Security/Performance,...)
- Test requirement: Refer đến các tài liệu test, file mô tả yêu cầu khách hàng, video call, meeting note, image, ...
- Risk: Mô tả các rủi ro mà quá trình test có thể gặp (ví dụ: khó tạo data test, time gấp, trao đổi gặp khó khăn,...)
- Strategy: Chiến lược test được sử dụng trong dự án, test type, test method, test priority,..
- Test tool: Tool quản lý (Jira, Redmine, Trello,..)
- Resource: Nhân lực phân bổ trong team
- Schedule: Lịch trình test, estimate thời gian, công việc tương ứng cho từng Sprint, function, module.
4. Đã từng estimate task chưa, dựa vào dữ liệu nào để lên estimate hiệu quả cho các task làm việc?
Gợi ý: Đầu tiên để estimate CV hiệu quả nhất, chúng ta cần clarify yêu cầu của khách hàng và chia thành những mục nhỏ. Để estimate test 1 function thì cần estimate time investigate yêu cầu, tạo testcase, testdata (dựa trên năng suất (productivity) của nhân lực hiện tại), độ khó của function, thời gian execute test thường sẽ dùng Function point method flow như sau:
- Xác định mức độ của funtion: Complex (phức tạp) - weight: 5, Medium (trung bình) - weight: 3, Simple (đơn giản) - weight: 1
- Liệt kê chức năng và đánh số point tương ứng:
| STT | Function | Point |
|---|---|---|
| 1 | Sign Up | 1 |
| 2 | Login | 1 |
| 3 | Reset password | 1 |
| 4 | Book an order | 5 |
| 5 | History | 3 |
| 6 | Payment | 5 |
- Nếu đặt giá trị 1 point = 3 man-hour, ta sẽ có: Function point = 40+15+10 = 65 , Estimate man-hour per point = 3 , Total Estimate Effort = 3*65 = 195 (man-hour)
5. Khi report bug cần những thông tin gì? Phân biệt Severity và Priority ?
Gợi ý: Thông tin cần có của 1 bug:
- Subject : phải mô tả ngắn gọn, dễ hiểu và súc tích
- Description: Mô tả bug đầy đủ "step by step" cụ thể, để bất cứ ai khác đọc có thể hiểu được cách tái hiện bug như thế nào.
- Expected Result: phải chính xác, cụ thể, chủ yếu dựa trên requirement của khách hàng
- Actual Result: phải mô tả chi tiết hiện trạng bug xảy ra trên sản phẩm
- Môi trường test: Bug được tái hiện trên những hệ máy nào (laptop/mobile)? kích cỡ màn hình, độ phân giải bao nhiêu? hệ điều hành nào? trình duyệt nào, version cụ thể của trình duyệt ? Trên ipa/ apk nào? server test gì?
- Priority/Serverity: Cần đánh giá đúng để dev dựa vào đó đưa ra plan ưu tiên fix bug, Bug Severity để đánh giá mức độ ảnh hưởng của bug đối với toàn hệ thống? khả năng degrade khi fix bug sẽ như thế nào
- Due Date: Deadline fix bug
- Evidence: Đính kèm hình ảnh, video để có thể nhìn bug trực quan và dễ hiểu hơn.
6. Khi tạo Testcase cần có những thông tin gì?
Gợi ý: Testcase bao gồm: Test Case ID, Test Items, Pre-condition, Test Data, Test Steps, Expected results, Result, BugID (Link report bug), Comments/Remark
7. Liệt kê testcase cho màn hình Đăng nhập gồm 2 field Username (3-50 ký tự) , Password (8-30 ký tự) và Button Đăng nhập
Gợi ý: List testcase:
- Kiểm tra UI form với design, bố trí các component trên form, màu sắc, kích cỡ khi zoom-in, zoom-out
- Kiểm tra validate trường [Username]: Nhập [Username] có ít hơn 3 kí tự, có 3 kí tự, có 50 kí tự, có lớn hơn 50 kí tự, nhập kí tự đặc biệt vào [Username], khoảng trắng 2 đầu, có dấu gạch ngang,dấu nháy đơn, dấu nháy kép
- Kiểm tra validate trường [Password]: Nhập [Password] nhỏ hơn 8 kí tự, có 8 kí tự, có 30 kí tự, quá 30 kí tự, nhập [Password] có khoảng trắng 2 đầu
- Kiểm tra dữ liệu hiển thị trong textbox Password sau khi nhập phải encode thành là dấu sao hoặc dấu chấm
- Kiểm tra chức năng Đăng nhập thất bại: Không nhập trường nào
- Kiểm tra chức năng Đăng nhập thất bại: chỉ nhập trường [Username] mà không nhập [Password] OR chỉ nhập trường [Password] mà không nhập [Username]
- Kiểm tra chức năng Đăng nhập thất bại: nhập [Username] và [Password] đúng nhưng account đã bị lock or inactive OR nhập sai [Username] và [Password] sai 3 lần sau đó nhập đúng
- Kiểm tra chức năng Đăng nhập thất bại: nhập sai [Username] và [Password] sai
- Kiểm tra chức năng Đăng nhập thành công: nhập [Username] và [Password] đúng và hiển thị thông tin tài khoản
8. Bug không tái hiện được thì sẽ sử lý ra sao?
Gợi ý: Bug không tái hiện được cần take note lại một cách chi tiết quá trình xảy ra bug nếu có thể và nhờ các bên điều tra
9. Dev báo không phải bug thì xử lý như thế nào?
Gợi ý: Trước tiên phải tìm hiểu lý do vì sao Dev báo không phải bug có phải do dev không tái hiện được bug hoặc do dev phán đoán đây là tính năng
-
TH Dev không tái hiện được or không hiểu bug thì cần cập nhật lại thông tin bug
-
TH Dev phán đoán là tính năng cần có sự confirm BA, KH, PM
10. Đã từng sử dụng câu lệnh SQL để test database chưa? Phân biệt Having và Group By. Làm bài tập SQL thực tế: Tính top 10 Lương của nhân viên trong tháng sắp xếp theo thứ tự tăng dần
Gợi ý: Một số lưu ý khi sử dụng SQL:
- Mệnh đề SELECT chỉ định các cột mà bạn muốn truy xuất từ bảng.
- Mệnh đề ORDER BY được sử dụng để sắp xếp kết quả của câu lệnh, ASC -sắp xếp theo thứ tự tăng dần, DESC -sắp xếp theo thứ tự giảm dần
- Mệnh đề LIMIT được sử dụng để hạn chế số lượng bản ghi được trả về
- Mệnh đề GROUP BY được sử dụng để nhóm các kết quả của câu lệnh SELECT dựa trên một hoặc nhiều cột. Nó thường được sử dụng cùng với các hàm tổng hợp như SUM, AVG, MAX, MIN và COUNT để tính giá trị cho từng nhóm.
- Mệnh đề HAVING để chỉ định điều kiện cho các nhóm. Mệnh đề HAVING hoạt động giống như mệnh đề WHERE, nhưng nó được áp dụng cho các nhóm chứ không phải cho các hàng riêng lẻ.
- Mệnh đề TOP được sử dụng để lấy dữ liệu của TOP N số hoặc X phần trăm bản ghi từ một bảng
Mong rằng bài viết sẽ giúp ích cho các bạn ứng viên chuẩn bị phỏng vấn, rất mong mọi người có thể góp ý thêm cho mình để mình có thể hoàn thiện hơn. Rất cảm ơn các bạn đã dành thời gian để đọc bài.