Với sự phát triển của công nghệ, nhu cầu tuyển dụng Tester ngày càng cao. Song song, nhà tuyển dụng cũng trở nên khó tính hơn trong việc lựa chọn ứng viên có thái độ và kiên thức chuyên môn phù hợp. Rikkei Academy cung cấp trọn bộ câu hỏi phỏng vấn Tester mới nhất 2023 giúp các bạn ứng viên có sự chuẩn bị tốt nhất.
Câu hỏi khai thác thông tin chung về ứng viên
- Bạn hãy giới thiệu về bản thân mình?
- Điểm mạnh, điểm yếu của bạn là gì?
- Lý do bạn chọn làm Tester là gì?
- Bạn đã từng làm dự án nào? Vai trò của bạn trong dự án là gì?
- Bạn đã đạt chứng chỉ gì về Kiểm thử?
Câu hỏi phỏng vấn Tester Fresher
Với vị trí Fresher thì các câu hỏi phỏng vấn Tester sẽ không quá khó, chủ yếu nhà tuyển dụng sẽ hỏi về các khái niệm và các kiến thức kiểm thử cơ bản.
Kiểm thử phần mềm là gì?
Kiểm thử phần mềm là quá trình đánh giá và kiểm tra các tính năng, hoạt động của phần mềm. Đảm bảo rằng phần mềm đáp ứng được yêu cầu và mong đợi của người dùng. Đồng thời, giúp nâng cao chất lượng của sản phẩm bằng cách ngăn ngừa các lỗi. Từ đó, giảm chi phí phát triển và giảm các vấn đề về hiệu suất.
Đây là câu hỏi khi phỏng vấn tester cơ bản nhất. Vì vậy, hãy nắm chắc khái niệm này!
Có bao nhiêu phương pháp kiểm thử phần mềm?
Hiện tại có nhiều phương pháp kiểm thử phần mềm khác nhau. Một số được thực hiện bởi lập trình viên và một số thì được thực hiện bởi chuyên viên QA (Đảm bảo chất lượng). Dưới đây là một số phương pháp kiểm thử bạn có thể tham khảo:
Phương pháp kiểm thử | Mô tả |
Unit Testing | Kiểm thử một đơn vị phần mềm, như một phương thức hoặc hàm, để đảm bảo tính đúng đắn của nó. |
Integration Testing | Kiểm thử tính tương thích và tính hợp nhất giữa các thành phần phần mềm khi được kết hợp với nhau. |
System Testing | Kiểm thử toàn bộ phần mềm để đảm bảo rằng toàn bộ hệ thống hoạt động như mong đợi. |
Smoke Testing | Kiểm thử nhanh để đảm bảo rằng phần mềm hoạt động ở mức cơ bản và không gây ra lỗi nghiêm trọng. |
Performance Testing | Kiểm thử tính năng hiệu suất của phần mềm, bao gồm tải và môi trường cụ thể để đảm bảo đáp ứng yêu cầu người dùng. |
User-Acceptance Testing | Kiểm thử để đảm bảo rằng phần mềm đáp ứng được yêu cầu của người dùng cuối cùng. |
Nguyên tắc kiểm thử phần mềm Beizer là gì?
Theo Beizer, quá trình kiểm thử phần mềm tuân thủ theo 7 nguyên tắc sau:
- Sai lầm về việc không có lỗi: Dù phần mềm được kiểm thử và không có lỗi, nếu nó không đáp ứng được yêu cầu của người dùng, thì phần mềm đó sẽ là không sử dụng được.
- Kiểm thử chỉ cho thấy sự hiện diện của lỗi: Kiểm thử có thể xác nhận các lỗi trong phần mềm, nhưng không đảm bảo rằng phần mềm hoàn toàn không có lỗi.
- Không thể kiểm thử toàn diện: Không thể kiểm thử toàn diện phần mềm, tức là không thể kiểm thử tất cả các trường hợp có thể xảy ra. Do đó, kiểm thử phải được thực hiện với một số trường hợp được chọn lựa.
- Điểm tập trung các lỗi: Các lỗi trong phần mềm thường tập trung ở một số module nhất định của dự án, theo nguyên tắc Pareto, 80% lỗi phần mềm phát sinh từ 20% module của phần mềm.
- Nguyên tắc thuốc trừ sâu: Không thể tìm ra các lỗi mới bằng cách chạy lại các trường hợp kiểm thử cũ. Do đó, cần phải thêm mới hoặc cập nhật các trường hợp kiểm thử để tìm ra các lỗi mới.
- Kiểm thử sớm: Kiểm thử phải được thực hiện sớm trong quá trình phát triển phần mềm để phát hiện lỗi sớm và giảm thiểu chi phí sửa lỗi.
- Kiểm thử phụ thuộc vào ngữ cảnh: Các phương pháp kiểm thử phải được điều chỉnh phù hợp với ngữ cảnh phát triển phần mềm.
Kiểm thử phần mềm được chia làm bao nhiêu giai đoạn? Kể tên
- Kiểm thử đơn vị (Unit Testing): Kiểm tra các đơn vị nhỏ nhất của phần mềm để đảm bảo chúng hoạt động chính xác.
- Kiểm thử tích hợp (Integration Testing): Kiểm tra tính tương thích và tính hoạt động của các đơn vị phần mềm đã kết hợp với nhau.
- Kiểm thử hệ thống (System Testing): Kiểm tra toàn bộ phần mềm để đảm bảo nó đáp ứng các yêu cầu và mong đợi của khách hàng.
- Kiểm thử chấp nhận (Acceptance Testing): Kiểm tra xem phần mềm đã đáp ứng được các yêu cầu và mong đợi của khách hàng hay chưa.
Môi trường kiểm thử (Test environment) là gì?
Môi trường kiểm thử là bộ khung phần cứng, phần mềm và các cấu hình mạng được thiết kế để kiểm thử các ứng dụng phần mềm mà không ảnh hưởng đến môi trường sản xuất. Môi trường kiểm thử được cấu hình để mô phỏng các kịch bản và điều kiện khác nhau, giúp đảm bảo rằng phần mềm được kiểm thử một cách chính xác và toàn diện trước khi được triển khai vào môi trường cục bộ (production environment).
Test Coverage là gì? Phân loại Test Coverage
Test coverage là một số đo lường để đánh giá mức độ phủ sóng của các ca kiểm thử đối với phần mềm được kiểm thử. Nó cho biết tỷ lệ phần trăm của các thành phần của phần mềm (ví dụ: dòng mã, hàm, module, chức năng) đã được kiểm thử trong tổng số các thành phần đó. Phân loại của test coverage:
- Statement coverage: Đo lường số lượng câu lệnh trong mã nguồn đã được thực thi trong quá trình kiểm thử.
- Branch coverage: Đo lường số lượng đường dẫn hoặc điều kiện khác nhau trong mã nguồn đã được thực thi trong quá trình kiểm thử.
- Path coverage: Đo lường số lượng đường đi khác nhau qua các điểm điều khiển trong mã nguồn đã được thực thi trong quá trình kiểm thử.
- Function coverage: Đo lường số lượng hàm hoặc phương thức đã được kiểm thử trong phần mềm.
- Boundary coverage: Đo lường số lượng giá trị cực đại, cực tiểu hoặc giá trị lỗi đã được kiểm thử.
- Error handling coverage: Đo lường số lượng các kịch bản xử lý lỗi đã được kiểm thử.
Giải thích black-box testing, white-box testing và grey-box testing.
- Black-box testing: Là phương pháp kiểm thử phần mềm dựa trên đầu vào và đầu ra của phần mềm, không cần biết chi tiết về cấu trúc bên trong.
- White-box testing: Là phương pháp kiểm thử dựa trên kiến thức về cấu trúc bên trong của phần mềm
- Grey-box testing: Là sự kết hợp của black-box testing và white-box testing.
Trong kiểm thử phần mềm, “bug” là gì?
“Bug” ( lỗi, vấn đề hoặc defect) là một sai sót hoặc lỗi trong phần mềm có thể dẫn đến hành vi không mong muốn hoặc không đáp ứng đúng yêu cầu chức năng. Tester là người có nhiệm vụ tìm ra bug.
So sánh “bug” và “error” trong kiểm thử phần mềm?
- Bug: Là sai sót hoặc lỗi trong mã nguồn của phần mềm có thể dẫn đến hành vi không mong muốn hoặc không đáp ứng đúng yêu cầu chức năng. Bug thường được phát hiện trong quá trình kiểm thử và cần được sửa trước khi phần mềm được triển khai.
- Error: Là sai sót hoặc lỗi do con người gây ra trong quá trình phát triển phần mềm. Error có thể dẫn đến việc phát hiện ra bug.
Kế hoạch kiểm thử là gì? Nó bao gồm những phần nào?
Kế hoạch kiểm thử là một tài liệu quan trọng trong quá trình kiểm thử phần mềm, mô tả chi tiết các hoạt động, phương pháp, tài nguyên và lịch trình của quá trình kiểm thử.
Một kế hoạch kiểm thử cần có những thông tin sau:
- Phương pháp kiểm thử
- Mục tiêu và kết quả mong đợi
- Phạm vi kiểm thử
- Lý do cho việc kiểm thử
- Tiêu chí đầu vào và tiêu chí kết thúc
- Tài nguyên cần thiết để thực hiện kiểm thử
- Tài liệu, báo cáo phát sinh trong quá trình kiểm thử
Một số công cụ, framework kiểm thử phổ biến là gì? Giới thiệu khái quát
- Selenium: là một công cụ tự động hóa trình duyệt web để tự động hóa các bộ kiểm thử bạn cần chạy trên trình duyệt web.
- Protractor: là một framework kiểm thử end-to-end dành cho các ứng dụng Angular và AngularJS.
- Cypress: là một công cụ kiểm thử front-end hiện đại được xây dựng cho web hiện đại.
- Jasmine: là một framework kiểm thử mã nguồn mở cho JavaScript, cho phép bạn viết các bộ kiểm thử behavior-driven (BDD) (kiểm thử dựa trên hành vi).
- JUnit và NUnit: Là các framework kiểm thử đơn vị cho các ngôn ngữ lập trình Java và C# tương ứng.
SPICE trong kiểm thử là gì?
SPICE (Software Process Improvement and Capability dEtermination) là một tiêu chuẩn quốc tế được phát triển bởi tổ chức ISO (International Organization for Standardization) với mục đích đánh giá và cải thiện quy trình phát triển phần mềm trong các tổ chức.
- Giải thích test scenarios, test scripts, and test cases.
- Test scenario (kịch bản kiểm thử): Là một tập hợp các bước hoặc hướng dẫn định sẵn để thực hiện kiểm thử trên một tính năng hoặc một phần của phần mềm.
- Test script (kịch bản kiểm thử mã hóa): Là một bộ mã hoặc kịch bản được viết bằng một ngôn ngữ lập trình để thực hiện tự động hóa các bước kiểm thử.
- Test case (trường hợp kiểm thử): Là một bộ mô tả chi tiết về các bước kiểm thử cần thực hiện để kiểm tra tính năng hoặc chức năng của phần mềm. Test case bao gồm các thông tin như tiêu đề, mô tả, bước kiểm thử, kết quả mong đợi và kết quả thực tế.
Kiểm thử A/B là gì?
Kiểm thử A/B là kỹ thuật so sánh hiệu quả của hai phiên bản khác nhau của một tính năng hoặc trang web bằng cách chia ngẫu nhiên người dùng thành hai nhóm và thu thập dữ liệu về hành vi của họ. Sau đó, dữ liệu được phân tích để xác định phiên bản nào tốt hơn.
Câu hỏi phỏng vấn Tester đã có kinh nghiệm
Khi bạn đã có kinh nghiệm, nhà tuyển dụng sẽ khai thác kiến thức của bạn bằng các câu hỏi phỏng vấn Tester sâu hơn, có thể đặt tình huống để xem cách bạn giải quyết vấn đề ra sao. Tham khảo các câu hỏi khi phỏng vấn tester sau để có sự chuẩn bị tốt nh:
Vòng đời kiểm thử là gì?
Vòng đời kiểm thử (test life cycle) là quá trình lập kế hoạch, thiết kế, thực hiện và báo cáo các hoạt động kiểm thử trong quá trình phát triển phần mềm. Vòng đời kiểm thử bao gồm các bước sau:
- Lập kế hoạch kiểm thử
- Thiết kế kiểm thử
- Thực hiện kiểm thử
- Đánh giá kết quả kiểm thử
- Hoàn thiện kiểm thử
Vòng đời lỗi (Bug Life Cycle) là gì?
Vòng đời lỗi (Bug Life Cycle) là quá trình quản lý và theo dõi các lỗi phần mềm từ khi được phát hiện đến khi được khắc phục hoàn toàn. Các giai đoạn trong vòng đời lỗi gồm:
Phát hiện->Ghi nhận-> Phân loại-> Phân tích-> Xác nhận -> Sửa lỗi-> Kiểm thử-> Đóng lỗi-> Theo dõi
Sự khác biệt giữa Functional testing và non functional testing là gì?
Functional testing | Non functional testing |
Thường được thực hiện trước khi kiểm thử phi chức năng | Thường được thực hiện sau khi kiểm thử chức năng |
Tập trung vào kiểm thử chức năng của phần mềm | Tập trung vào kiểm thử các khía cạnh phi chức năng như hiệu suất, bảo mật, khả năng mở rộng,… |
Dựa trên yêu cầu của khách hàng và thông số kỹ thuật | Dựa trên kỳ vọng của khách hàng và mục tiêu hiệu suất |
Kiểm thử tĩnh (static testing) là gì?
Kiểm thử tĩnh (static testing) là một phương pháp kiểm thử phần mềm được thực hiện bằng cách kiểm tra tài liệu, mã nguồn và các thành phần khác của phần mềm mà không cần thực thi chương trình.
Kiểm thử động (dynamic testing) là gì?
Kiểm thử động (dynamic testing) là một phương pháp kiểm thử phần mềm được thực hiện bằng cách thực thi chương trình và đưa ra các đầu vào (input) và đo lường kết quả đầu ra (output).
Kiểm thử nhiều trình duyệt ( cross-browser testing) là gì?
Kiểm thử nhiều trình duyệt (cross-browser testing) là quá trình kiểm thử phần mềm để đảm bảo rằng ứng dụng web hoặc trang web hoạt động đúng đắn trên nhiều trình duyệt khác nhau như Google Chrome, FireFox hoặc Safari.
Trường hợp kiểm thử nào được viết trước: white-box hay black-box?
Các trường hợp kiểm thử black-box thường được viết trước. Để viết các trường hợp kiểm thử black-box, cần có một phác thảo về thiết kế hoặc kế hoạch dự án và tài liệu yêu cầu. Các tài liệu như vậy thường sẵn có ở đầu dự án. Trong khi đó, kiểm thử white-box thường yêu cầu làm rõ kiến trúc mà trong giai đoạn đầu của dự án chưa có sẵn. Do đó, các trường hợp kiểm thử hộp trắng thường được viết sau khi các trường hợp kiểm thử hộp đen đã được phát triển.
TTD trong kiểm thử là gì?
TTD là viết tắt của Test-Driven Development, một phương pháp phát triển phần mềm mà trong đó các bài kiểm thử được viết trước khi bất kỳ mã nguồn nào được phát triển.
Có nên chỉ thực hiện kiểm thử sau khi giai đoạn xây dựng và thực thi hoàn tất?
Kiểm thử luôn được thực hiện sau các giai đoạn xây dựng và thực thi. Việc phát hiện lỗi sớm sẽ giúp tiết kiệm chi phí hơn. Ví dụ, việc sửa lỗi trong giai đoạn bảo trì có chi phí gấp đôi so với việc sửa lỗi trong giai đoạn thực thi.
Trường hợp nào có thể áp dụng kiểm thử tự động?
- Smoke test (kiểm thử khói)
- Regression test (kiểm thử hồi quy)
- Complex calculation test
- Data-driven test (kiểm thử hướng dữ liệu)
- Non-functional test (kiểm thử phi chức năng)
Một lỗi nên được được loại bỏ ở giai đoạn trước nhưng phải đến giai đoạn sau mới được xử lý. Điều này ảnh hưởng thế nào đến chi phí?
Nếu trì hoãn việc sửa lỗi đến giai đoạn sau trong chu kỳ phát triển sẽ tăng chi phí đáng kể. Điều này bởi vì lỗi có thể đã gây ra các vấn đề khác hoặc ảnh hưởng đến các phần khác của phần mềm, làm cho việc sửa chữa khó khăn và tốn thời gian hơn.
Các câu hỏi phỏng vấn Tester khác
- TestNG là gì?
- Làm thế nào để đặt ưu tiên cho các trường hợp kiểm thử trong TestNG?
- API là gì?
- Mô hình V trong kiểm thử là gì?
- Kiểm thử dựa trên rủi ro (Risk-based testing)?
- Tại sao chúng ta chia kiểm thử thành các giai đoạn khác nhau?
- Kiểm thử tải (Load testing) trên các trang web là gì?
- Các loại lỗi phần mềm phổ biến là gì?
- Khi nào có thể dừng kiểm thử?
- Verification (xác nhận) và Validation (xác thực) trong kiểm thử phần mềm là gì?
- Lợi ích của kiểm thử tự động (automation testing ) là gì?
- Khi nào thì sử dụng kiểm thử hồi quy (Regression Testing)?
- Dựa trên cơ sở nào bạn có thể đánh giá kiểm thử tự động thành công?
- Mối quan hệ giữa môi trường kiểm thử và các giai đoạn kiểm thử là gì?
- Đâu là thông tin đầu vào của người dùng cuối (end user) để bắt đầu kiểm thử đúng cách?
- Sự khác nhau giữa Selenium và QTP (Quick Test Professional) là gì?
- Object Repository là gì? Làm thế nào để tạo Object Repository trong Selenium?
- Bạn đã sử dụng các phần mềm kiểm thử tự động như Selenium hay Appium chưa? Bạn sử dụng chúng như thế nào?
- Boundary value analysis có nghĩa là gì?
- Quá trình bạn phân tích rủi ro như thế nào?
Kết luận
Trên đây là trọn bộ câu hỏi phỏng vấn tester mới nhất được tổng hợp bởi Rikkei Academy. Hy vọng với bộ câu hỏi này đã giúp bạn có sự chuẩn bị kỹ lưỡng. Chúc bạn thành công trong cuộc phỏng vấn sắp tới!
Để trở thành tester thì việc hiểu ngôn ngữ lập trình và cách vận hành cũng rất quan trọng. Nếu bạn đang muốn tìm khóa học lập trình ngắn hạn, tham khảo Rikkei Academy nhé!