Dưới đây là một số câu hỏi phỏng vấn mà theo tôi là thường xuất hiện trong các buổi phỏng vấn Manual Tester (Manual QA) hoặc để phỏng vấn nghiệp vụ test của các software Automation Engineer (Automation QA).
Đối với một QA nói chung, thì sự cẩn thận, tỉ mỉ, khả năng "bới lông tìm vết" là yếu tố được đánh giá cao hơn cả. Do đó, các câu hỏi phỏng vấn QA thường thiên về việc liệt kê các test case, scenario có thể để cover được càng nhiều lỗi càng tốt.
Riêng cá nhân tôi, về lý thuyết, tôi thường sử dụng các câu hỏi hoặc kiến thức từ các tài liệu/giáo trình luyện thì ISTQB Foundation. Các câu hỏi thường chỉ xoay quanh về các testing levels và các kỹ thuật để break test cases cũng như cách ứng dụng cụ thể vào các bài tập tình huống.
Bạn test cây bút/chai nước như thế nào?
Đây là một dạng câu hỏi huyền thoại, sử dụng cây bút/chai nước hoặc một vật dụng bất kỳ nào đó để tượng trưng cho một sản phẩm phần mềm.
Đối với các bạn mới ra trường, người phỏng vấn thường mong muốn bạn liệt kê ra được một vài kiểu test cụ thể như: Kiểm tra xem mực ra có đều hay không? Cảm giác cầm nắm cây bút thoải mái hay không? Vị trí đặt logo như thế nào? v.v...
Đối với các bạn tester đã có 1-2 năm kinh nghiệm, người phỏng vấn có thể sẽ expect cao hơn. Do đó sẽ tốt hơn nếu như các bạn có thể liệt kê quy trình test cây bút dưới dạng 4 level test cơ bản (Unit Testing, Integration Testing, System Testing, Acceptance Testing).
Đối với Unit Testing (test đơn vị), chúng ta sẽ tách từng thành phần của cây bút ra để test: như ngòi bút, nắp bút, vỏ bút v.v... Vì trong quy trình sản xuất phần mềm, chúng ta không thể đợi cho tới khi sản phẩm hoàn chỉnh mới test mà phải test ngay ở mức đơn vị, test từng API, method một.
Integration Testing (test tích hợp), chúng ta sẽ ráp 1-2 thành phần đơn vị của cây bút lại và test như một nhóm cụ thể. Ví dụ như gắn ngòi bút vào thân bút và test xem có gắn được hay không, có gì không ổn hay không, có lỗi bất ngờ nào phát sinh hay không. Tương đương đối với sản xuất phần mềm, đó là khi bạn có thể bắt đầu gắn API vào giao diện chẳng hạn, và test thử một vài chức năng cơ bản của hệ thống.
System Testing (test hệ thống), đó là khi chúng ta đã có đầy đủ tất cả các unit, ráp lại thành 1 cây bút (hệ thống) hoàn chỉnh. Đó là lúc test full toàn bộ chức năng của cây bút, end-to-end test này kia.
Acceptance Testing (test chấp nhận), khi đã xong quá trình System Test, chúng ta sẽ giao cây bút cho một bên thứ ba không liên quan tới quá trình sản xuất test trước. Đó có thể là những người trong công ty nhưng ở bộ phận khác. Quy trình này thường gọi là Alpha Testing. Sau đó giao cây bút cho bên khách hàng đặt hàng test (User Acceptance Testing). Hoặc có thể đưa cây bút cho một nhóm nhỏ end-user (người dùng cuối) test thì gọi là Beta Testing.
Một số câu hỏi liên quan:
- Làm sao để test con chuột máy tính?
- Làm sao để test cái bàn?
- Làm sao để test cục xúc sắc?
...
Đọc thêm: Tôi đã tìm việc ở Thái Lan như thế nào?
Làm thế nào để phân biệt giữa testing levels, testing methods và testing types?
Trong thực tế, tôi thấy khá nhiều bạn nhầm lẫn giữa các khái niệm này. Thậm chí có bạn nghĩ regression test là một testing level. Rất nay là chúng ta có một mẹo nhỏ để có thể tránh bị lẫn lộn giữa các định nghĩa này:
- Method = HOW to test (test như thế nào?)
- Level = WHEN to test (test khi nào?)
- Type = WHAT to test (test cái gì?)
Sự khác biệt giữa Regression Test và Smoke Test?
Dựa vào câu trên thì cả hai đều là những testing type. Tuy nhiên:
- Regression test (test hồi quy) là chạy lại toàn bộ các test case trước đó khi có một feature mới hoặc một defect được fix. Việc này nhằm đảm bảo, feature hoặc fix vừa được deploy không gây các lỗi tiềm ẩn cho hệ thống. Rõ ràng, việc chạy lại toàn bộ các test case từ trước đến nay là gần như không thể nếu làm bằng tay, vậy nên automation đóng vai trò cực kỳ quan trọng trong regression test. Các regression test case thường sẽ được chạy ở môi trường thấp (QA, UAT, SUPP) chứ không được chay ở PROD vì chúng thường được thiết kế để test hard core, kiểu như update data, tạo dữ liệu test, thêm/xóa/sửa v.v...
- Smoke test (test khói, test sơ) là chạy lại những happy test case nhằm mục đích đảm bảo các chức năng của hệ thống vẫn hoạt động được ở mức cơ bản. Ví dụ, khi test trang login, chúng ta sẽ chỉ chọn một test case cho phép chương trình nhập vào username/password đúng, yêu cầu chỉ cần login vào được là đủ. Chúng ta sẽ không test các negative cases kiểu như sai username/password, ký tự đặc biệt v.v... những negative cases như vậy sẽ được đảm nhận bởi regression test. Vì ít can thiệp vào dữ liệu, thường chi dừng ở mức đọc (view only) nên Smoke test thường được thiết kế để chạy ở các môi trường cao như PROD.
Cả 3 đều là phương pháp test (testing methods) nhưng giữa chúng có sự khác biệt rõ ràng như sau:
Black Box Testing: Tester test hệ thống nhưng không quan tâm tới cấu trúc/thiết kế/cách viết code bên trong của hệ thống. Black Box thường được ứng dụng vào các level test sau: Integration Testing, System Testing, và Acceptance Testing. Các test case được thực thi từ view của người dùng và chủ yếu được test ở tầng UI, chỉ trên những gì được expose ra tới người dùng. Với phương pháp này, tester không cần phải biết ngôn ngữ lập trình cũng như cách hệ thống được lập trình như thế nào.
White Box Testing: Ngược lại, tester test hệ thống nhưng có sự am hiểu nhất định về cấu trúc/thiết kế/cách viết code bên trong của hệ thống. White Box thường được ứng dụng vào level test sau: Unit Testing, Integration Testing, System Testing. Phương pháp test này đòi hỏi tester phải có kỹ năng cao, có sự hiểu biết nhất định về ngôn ngữ lập trình cũng như kỹ năng viết code nhất định.
Gray Box Testing: Là kết hợp giữa Black Box và White Box. Một ví dụ như khi người tester cần đọc code để hiểu được cách thức hoạt động của các unit/module bên dưới để có thể viết được test case nhưng việc thực thi test case sẽ được tiến hành từ UI (Back Box Testing).
https://softwaretestingfundamentals.com/gray-box-testing/
Bạn tìm thấy bao nhiêu lỗi trong bức hình này?
Một dạng câu hỏi khác thường thấy là người phỏng vấn sẽ đưa cho bạn một bức ảnh chụp lại giao diện của một phần mềm nào đó, và yêu cầu bạn liệt kê ra những điểm mà bạn cho là chưa hợp lý. Đây chính là một cách kiểm tra khả năng "bới lông tìm vết" của ứng viên.
Ví dụ dưới đây là một bức ảnh chụp giao diện của Google Search, bạn nghĩ có bao nhiêu lỗi? Hãy thử suy nghĩ và tìm lỗi trước khi xem đáp án nhé.
1: Icon Google không hiển thị.
2: Phải là "(Untitled)".
3: Icon "X" bị lỗi.
4: Icon "_" trong nút Minimized không được canh giữa.
5: Phải là "I'm Feeling Lucky".
6: Chữ "O" không đổ bóng.
7: Chữ "News" bị xích lên trên.
8: Phải là "Shopping".
9: Phải là "Search Settings" thì mới nhất quán với "Sign In".
10: Phải là "Maps".
11: Phải là "|".
12: Dấu mũi tên phải chỉ xuống.
13: Khung search thiếu border bên trái.
14: Có 2 chữ "Done".
15: Thanh scroll bar bị lỗi.
16: Có 2 icon mũi tên đi xuống.
17: Chữ "Google" sai chính tả.
18: Biểu tượng loading ở sai vị trí.
19: Phải là "Language Tools".
20: Biểu tượng mũi tên bị sai.
21: Không có nút "New Tab".
22: UI của trình duyệt bị lỗi so với thực tế (bạn search hình gốc của trình duyệt Firefox trong XP sẽ thấy).
Các kỹ thuật để break test cases?
Bạn tìm thấy bao nhiêu lỗi trong bức hình này?
Một dạng câu hỏi khác thường thấy là người phỏng vấn sẽ đưa cho bạn một bức ảnh chụp lại giao diện của một phần mềm nào đó, và yêu cầu bạn liệt kê ra những điểm mà bạn cho là chưa hợp lý. Đây chính là một cách kiểm tra khả năng "bới lông tìm vết" của ứng viên.
Ví dụ dưới đây là một bức ảnh chụp giao diện của Google Search, bạn nghĩ có bao nhiêu lỗi? Hãy thử suy nghĩ và tìm lỗi trước khi xem đáp án nhé.
1: Icon Google không hiển thị.
2: Phải là "(Untitled)".
3: Icon "X" bị lỗi.
4: Icon "_" trong nút Minimized không được canh giữa.
5: Phải là "I'm Feeling Lucky".
6: Chữ "O" không đổ bóng.
7: Chữ "News" bị xích lên trên.
8: Phải là "Shopping".
9: Phải là "Search Settings" thì mới nhất quán với "Sign In".
10: Phải là "Maps".
11: Phải là "|".
12: Dấu mũi tên phải chỉ xuống.
13: Khung search thiếu border bên trái.
14: Có 2 chữ "Done".
15: Thanh scroll bar bị lỗi.
16: Có 2 icon mũi tên đi xuống.
17: Chữ "Google" sai chính tả.
18: Biểu tượng loading ở sai vị trí.
19: Phải là "Language Tools".
20: Biểu tượng mũi tên bị sai.
21: Không có nút "New Tab".
22: UI của trình duyệt bị lỗi so với thực tế (bạn search hình gốc của trình duyệt Firefox trong XP sẽ thấy).
Các kỹ thuật để break test cases?
Các kỹ thuật thường thấy nhất làm EP (Equivalent Partitioning), BVA (Boundary Value Analysis), Decision Table, Pairwise v.v... Cụ thể mỗi kỹ thuật như thế nào và cách ứng dụng cụ thể ra sao thì các bạn tự tìm hiểu nhé. Gợi ý: Bạn có thể dễ dàng tìm hiểu về các kỹ thuật trên trong các bộ đề hoặc tài liệu luyện thi ISTQB Foundation.
Một người phụ nữ dùng súng bắn một người đàn ông nhưng ông ta không chết. Hãy liệt kê các tình huống có thể?
Một câu hỏi khá thú vị. Bạn nghĩ ra được bao nhiêu tình huống (scenario)? Những dạng câu hỏi này đòi hỏi bạn phải có những suy nghĩ sáng tạo (out of the box), vượt ra khỏi những tình huống thông thường.
Câu trả lời tham khảo:
1. Khẩu súng bị hư.
2. Khẩu súng không được nạp đạn, bị kẹt đạn, dùng sai đạn, đạn bị ướt v.v...
3. Đó chỉ là một giấc mơ.
4. Người phụ nữ và người đàn ông ở hai nơi quá xa nhau (không gian).
5. Người phụ nữ và người đàn ông tồn tại ở hai thế kỷ khác nhau (thời gian).
6. Người đàn ông chỉ là một tấm ảnh.
7. Người đàn ông mặc áo chống đạn.
8. Đạn bắng trúng chân người đàn ông.
9. Người phụ nữ bắn trượt.
10. Người đàn ông đã du hành vượt thời gian, thấy trước được cái chết của chính mình nên biết đường né =))
11. Đó chỉ là một khẩu súng nước, súng đồ chơi, súng cao su v.v...
12. "Khẩu súng" chỉ là một tên gọi của người phụ nữ dành riêng cho những vật dụng có hình dáng giống khẩu súng như máy sấy tóc chẳng hạn.
13. Người đàn ông là Superman =))
Câu hỏi liên quan:
- Liệt kê những điểm bạn thấy chưa ổn trong căn phòng bạn đang ngồi?
- Hướng dẫn một người ngoài hành tinh cách đánh răng cho đúng?
- Bạn test chức năng login của Facebook như thế nào? Liệt kê các scenario có thể?
- Bạn test chức năng search của Google như thế nào? Liệt kê các scenario có thể?
...
Phân biệt, định nghĩa Test Levels, Test Methods, Test Types
Riêng phần này thì sẽ có rất rất nhiều câu hỏi có thể xảy ra. Cách duy nhất để trả lời được là bạn phải thực sự nghiên cứu định nghĩa của từng khái niệm một. Ví dụ với Test Levels chúng ta có 4 level test cơ bản như tôi đã nói ở phần đầu. Nhưng cụ thể định nghĩa của mỗi level như thế nào, ứng dụng ra sao, có thể kết hợp với những Test Method nào thì bạn phải tự nghiên cứu. Còn nếu liệt kê toàn bộ ở đây thì e không bao giờ hết.
Toàn bộ các kiến thức này bạn có thể tham khảo ở đây: http://softwaretestingfundamentals.com/
Hãy liệt kê 1-2 điểm yếu của bạn?
Đây là một dạng câu hỏi mở, không có đáp án chính xác. Tuy nhiên, người phỏng vấn ưa thích dùng những câu hỏi dạng này để hiểu hơn về tính cách và suy nghĩ của ứng viên. Do đó, bạn không nên quá coi thường mà trả lời một cách thiếu cân nhắc.
Để trả lời câu hỏi này, hãy nói thật, NHƯNG, đừng nên nói về những điểm yếu liên quan trực tiếp tới chuyên môn của bạn. Ví dụ: Bạn xin vào làm kế toán, nhưng lại nói rằng bạn không biết tính toán; Bạn xin vào làm nhập liệu, nhưng bạn lại không biết dùng các phần mềm văn phòng. Nghe sẽ rất mâu thuẫn và khả năng cao bạn sẽ bị loại.
Vậy, hãy nói về những điểm yếu không liên quan trực tiếp tới chuyên môn và cách mà bạn đã cải thiện và vượt qua nó như thế nào. Như vậy, người tuyển dụng sẽ thấy được bạn không những nhận thức được điểm yếu của bản thân mà còn rất cố gắng để vượt qua những điểm yếu đó.
Ví dụ: Điểm yếu của tôi là hay bồn chồn, lo lắng vì những lý do không xác đáng. Đôi lúc thiếu kiên nhẫn và tập trung. Sau đó, tôi quyết định tập chạy bộ mỗi ngày vì chạy bộ giúp tôi giảm căng thẳng hiệu quả, lại còn rèn luyện cho tôi sự kiên nhẫn.
Lời bàn
Nói chung, các câu hỏi phỏng vấn cho dù là về Dev hay QA thì cũng đều rất đa dạng. Tốt nhất vẫn là bạn phải có sự chuẩn bị sẵn sàng lâu dài, không phải ngày một ngày hai. Hãy nghiên cứu, luyện tập, trau dồi kỹ năng, tìm hiểu các câu hỏi phỏng vấn và kiến thức liên quan ngay từ bây giờ. Nhờ vậy bạn sẽ có tự tin để có thể tham dự bất kỳ cuộc phỏng vấn nào.
Một người phụ nữ dùng súng bắn một người đàn ông nhưng ông ta không chết. Hãy liệt kê các tình huống có thể?
Một câu hỏi khá thú vị. Bạn nghĩ ra được bao nhiêu tình huống (scenario)? Những dạng câu hỏi này đòi hỏi bạn phải có những suy nghĩ sáng tạo (out of the box), vượt ra khỏi những tình huống thông thường.
Câu trả lời tham khảo:
1. Khẩu súng bị hư.
2. Khẩu súng không được nạp đạn, bị kẹt đạn, dùng sai đạn, đạn bị ướt v.v...
3. Đó chỉ là một giấc mơ.
4. Người phụ nữ và người đàn ông ở hai nơi quá xa nhau (không gian).
5. Người phụ nữ và người đàn ông tồn tại ở hai thế kỷ khác nhau (thời gian).
6. Người đàn ông chỉ là một tấm ảnh.
7. Người đàn ông mặc áo chống đạn.
8. Đạn bắng trúng chân người đàn ông.
9. Người phụ nữ bắn trượt.
10. Người đàn ông đã du hành vượt thời gian, thấy trước được cái chết của chính mình nên biết đường né =))
11. Đó chỉ là một khẩu súng nước, súng đồ chơi, súng cao su v.v...
12. "Khẩu súng" chỉ là một tên gọi của người phụ nữ dành riêng cho những vật dụng có hình dáng giống khẩu súng như máy sấy tóc chẳng hạn.
13. Người đàn ông là Superman =))
Câu hỏi liên quan:
- Liệt kê những điểm bạn thấy chưa ổn trong căn phòng bạn đang ngồi?
- Hướng dẫn một người ngoài hành tinh cách đánh răng cho đúng?
- Bạn test chức năng login của Facebook như thế nào? Liệt kê các scenario có thể?
- Bạn test chức năng search của Google như thế nào? Liệt kê các scenario có thể?
...
Phân biệt, định nghĩa Test Levels, Test Methods, Test Types
Riêng phần này thì sẽ có rất rất nhiều câu hỏi có thể xảy ra. Cách duy nhất để trả lời được là bạn phải thực sự nghiên cứu định nghĩa của từng khái niệm một. Ví dụ với Test Levels chúng ta có 4 level test cơ bản như tôi đã nói ở phần đầu. Nhưng cụ thể định nghĩa của mỗi level như thế nào, ứng dụng ra sao, có thể kết hợp với những Test Method nào thì bạn phải tự nghiên cứu. Còn nếu liệt kê toàn bộ ở đây thì e không bao giờ hết.
Toàn bộ các kiến thức này bạn có thể tham khảo ở đây: http://softwaretestingfundamentals.com/
Hãy liệt kê 1-2 điểm yếu của bạn?
Đây là một dạng câu hỏi mở, không có đáp án chính xác. Tuy nhiên, người phỏng vấn ưa thích dùng những câu hỏi dạng này để hiểu hơn về tính cách và suy nghĩ của ứng viên. Do đó, bạn không nên quá coi thường mà trả lời một cách thiếu cân nhắc.
Để trả lời câu hỏi này, hãy nói thật, NHƯNG, đừng nên nói về những điểm yếu liên quan trực tiếp tới chuyên môn của bạn. Ví dụ: Bạn xin vào làm kế toán, nhưng lại nói rằng bạn không biết tính toán; Bạn xin vào làm nhập liệu, nhưng bạn lại không biết dùng các phần mềm văn phòng. Nghe sẽ rất mâu thuẫn và khả năng cao bạn sẽ bị loại.
Vậy, hãy nói về những điểm yếu không liên quan trực tiếp tới chuyên môn và cách mà bạn đã cải thiện và vượt qua nó như thế nào. Như vậy, người tuyển dụng sẽ thấy được bạn không những nhận thức được điểm yếu của bản thân mà còn rất cố gắng để vượt qua những điểm yếu đó.
Ví dụ: Điểm yếu của tôi là hay bồn chồn, lo lắng vì những lý do không xác đáng. Đôi lúc thiếu kiên nhẫn và tập trung. Sau đó, tôi quyết định tập chạy bộ mỗi ngày vì chạy bộ giúp tôi giảm căng thẳng hiệu quả, lại còn rèn luyện cho tôi sự kiên nhẫn.
Lời bàn
Nói chung, các câu hỏi phỏng vấn cho dù là về Dev hay QA thì cũng đều rất đa dạng. Tốt nhất vẫn là bạn phải có sự chuẩn bị sẵn sàng lâu dài, không phải ngày một ngày hai. Hãy nghiên cứu, luyện tập, trau dồi kỹ năng, tìm hiểu các câu hỏi phỏng vấn và kiến thức liên quan ngay từ bây giờ. Nhờ vậy bạn sẽ có tự tin để có thể tham dự bất kỳ cuộc phỏng vấn nào.
Loading...