Top 40+ câu hỏi phỏng vấn Tester thường gặp nhất

Nội dung bài viết

Bài viết về câu hỏi phỏng vấn Tester sau đây đã tổng hợp 40+ câu hỏi thường gặp nhất trong một buổi phỏng vấn kỹ thuật dành cho Tester, được chia thành nhiều cấp độ. Những câu hỏi này được thu thập sau khi tham khảo ý kiến của các chuyên gia hàng đầu trong ngành trong lĩnh vực kiểm thử thủ công và tự động hóa.

Đọc bài viết này để nắm vững:

Các câu hỏi phỏng vấn Tester dành cho cấp độ Fresher/ Mới ra trường
Các câu hỏi phỏng vấn Tester dành cho cấp độ Junior và Middle
Các câu hỏi phỏng vấn Tester dành cho cấp độ Senior trở lên

Câu hỏi phỏng vấn Tester dành cho Fresher

Kiểm thử đơn vị (unit testing) là gì?

Unit Test là kiểm thử các đơn vị hay thành phần riêng lẻ của phần mềm, được thực hiện trong quá trình phát triển phần mềm.

Đơn vị code có thể là một phương thức, một class hoặc một module. Kiểm thử đơn vị nhằm mục đích tập trung vào các khối code xây dựng nhỏ nhất để cô lập một phần code và xác minh tính chính xác của đơn vị đó và đảm bảo có thể kết hợp chúng sau này nhằm tạo ra một phần mềm hoạt động đầy đủ.

Kiểm thử đơn vị thực thi code và xác minh kết quả với kết quả mong đợi. Nếu kết quả mong đợi và kết quả thực tế khớp nhau thì kiểm thử đơn vị sẽ đạt. Nếu không thì kiểm thử thất bại.

Giải thích test scenario, test script, and test case trong kiểm thử phần mềm

Test case: Test case là một chuỗi các hành động được thực hiện trong quá trình phát triển phần mềm để xác minh một tính năng hoặc chức năng cụ thể có hoạt động như mong đợi hay không. Một test case bao gồm các bước kiểm thử, dữ liệu kiểm thử, điều kiện tiên quyết và kết quả mong đợi được thiết kế để xác minh một yêu cầu cụ thể.
Test scenario: Thông thường, một kịch bản kiểm thử bao gồm một tập hợp các trường hợp kiểm thử để kiểm tra tất cả các chức năng đầu cuối của một ứng dụng phần mềm. Một test scenario cung cấp một cái nhìn tổng quan ở cấp độ cao về những gì cần được kiểm thử.
Test script: Trong kiểm thử phần mềm, test script đề cập đến tập hợp các bước cụ thể sẽ được tuân theo để xác minh rằng hệ thống được kiểm thử có hoạt động như mong đợi hay không. Bạn cần đề ra từng bước cần thực hiện và kết quả mong đợi trong document.

Giải thích Vòng đời kiểm thử phần mềm (Software Testing Life Cycle – STLC)

Vòng đời kiểm thử phần mềm (STLC) là một quy trình có hệ thống mà các nhóm QA tuân theo khi tiến hành kiểm thử phần mềm bao gồm nhiều giai đoạn, mà các nhóm QA theo dõi một cách có hệ thống để đảm bảo hiệu quả và độ phủ của kiểm thử trong suốt quá trình phát triển phần mềm…

Các giai đoạn trong STLC được thiết kế để đạt được độ test coverage cao, đồng thời duy trì hiệu quả kiểm thử.

Có 6 giai đoạn trong STLC:

Phân tích yêu cầu: Trong giai đoạn này, Tester cộng tác với các bên liên quan trong quá trình phát triển (Developer, BA, khách hàng, product owner, v.v.) để xác định và hiểu các yêu cầu kiểm thử. Thông tin thu thập được từ cuộc thảo luận này được tổng hợp thành “Ma trận truy xuất yêu cầu” (Requirement Traceability Matrix – RTM). Tài liệu này là nền tảng của chiến lược kiểm thử.
Lập kế hoạch kiểm thử: Dựa trên chiến lược kiểm thử toàn diện, bạn phát triển một kế hoạch kiểm thử, trong đó ghi lại chi tiết về mục tiêu, cách tiếp cận, phạm vi của dự án kiểm thử, sản phẩm kiểm thử, sự phụ thuộc, môi trường, quản lý rủi ro và lịch trình. Đây có thể xem là phiên bản chi tiết hơn của chiến lược kiểm thử.
Phát triển test case: Tùy thuộc vào việc các bên muốn thực hiện kiểm thử theo cách thủ công (manual) hay tự động (automated), bạn sẽ có các cách tiếp cận khác nhau cho giai đoạn này. Một số test case sẽ phù hợp với cách kiểm thử thủ công, trong khi một số test case nên được tự động hóa để tiết kiệm thời gian. Nói chung, trong kiểm thử thủ công, Tester viết ra các bước cụ thể của test case vào bảng tính và ghi lại kết quả ở đó, trong khi đối với kiểm thử tự động, test case được viết dưới dạng script bằng cách sử dụng framework tự động hóa kiểm thử, như Selenium, hoặc công cụ kiểm thử tự động hóa với tính năng soạn thảo test low-code, như Katalon.
Thiết lập môi trường: Nhóm QA thiết lập và cấu hình môi trường kiểm thử, bao gồm phần cứng, phần mềm, và cấu hình mạng để tiến hành kiểm thử dựa trên kế hoạch của họ. Có nhiều môi trường để chạy kiểm thử như cục bộ, từ xa hoặc trên đám mây.
Thực hiện kiểm thử: Nhóm QA chuẩn bị các test case, test script và dữ liệu kiểm thử dựa trên các mục tiêu rõ ràng. Việc kiểm thử có thể được thực hiện thủ công hoặc tự động. Kiểm thử thủ công được sử dụng khi cần có sự hiểu biết và phán đoán của con người, trong khi kiểm thử tự động hóa sẽ phù hợp với các quy trình lặp đi lặp lại với những thay đổi nhỏ. Các lỗi được tìm thấy trong quá trình kiểm thử sẽ được theo dõi và báo cáo cho nhóm phát triển để họ kịp thời giải quyết.
Kết thúc chu trình kiểm thử: Đây là giai đoạn cuối cùng của quy trình kiểm thử phần mềm. Các Tester sẽ cùng nhau kiểm thử những phát hiện của họ từ các test, đánh giá xem chúng hoạt động tốt như thế nào và ghi lại những bài học quan trọng cần ghi nhớ trong tương lai. Điều quan trọng là phải thường xuyên đánh giá quy trình kiểm thử phần mềm để duy trì quyền kiểm soát tất cả các hoạt động kiểm thử trong suốt các giai đoạn STLC.

Nguyên tắc kiểm thử phần mềm là gì?

Kiểm thử phần mềm được “kiểm soát” bởi bảy nguyên tắc:

Lỗi ngụy biện: Ngay cả khi phần mềm gần như không có lỗi, nó vẫn sẽ không thể sử dụng được nếu không phù hợp với yêu cầu của người dùng. Phần mềm cần phải không có lỗi trong hầu hết thời gian và cũng phải đáp ứng mọi yêu cầu của khách hàng.
Kiểm thử cho thấy sự hiện diện của lỗi: Kiểm thử có thể xác minh sự hiện diện của lỗi trong phần mềm, nhưng kiểm thử không thể đảm bảo rằng phần mềm không có lỗi. Kiểm thử có thể giảm thiểu số lượng lỗi nhưng không thể loại bỏ tất cả.
Không thể kiểm thử toàn diện: Phần mềm không thể được kiểm thử toàn diện, điều đó có nghĩa là không thể phủ tất cả các test case có thể xảy ra. Việc kiểm thử chỉ có thể được thực hiện với một số test case được chọn và người ta giả định rằng phần mềm sẽ tạo ra kết quả phù hợp trong mọi trường hợp. Việc đưa phần mềm qua mọi test case sẽ tốn nhiều chi phí, nhiều công sức hơn, v.v., điều này khiến việc kiểm thử toàn diện là không thực tế.
Phân cụm lỗi: Phần lớn các lỗi thường được tìm thấy ở một số lượng nhỏ các module trong dự án. Theo Nguyên tắc Pareto, 80% lỗi phần mềm phát sinh từ 20% module.
Nghịch lý thuốc trừ sâu: Không thể tìm ra lỗi mới bằng cách chạy đi chạy lại cùng một test case. Vì vậy, việc cập nhật hoặc thêm các test case mới là cần thiết để tìm ra các lỗi mới.
Kiểm thử sớm: Kiểm thử sớm là rất quan trọng để tìm ra lỗi trong phần mềm. Trong giai đoạn đầu của SDLC, các lỗi sẽ được phát hiện dễ dàng hơn và với chi phí thấp hơn.
Kiểm thử phụ thuộc vào ngữ cảnh: Cách tiếp cận kiểm thử khác nhau tùy thuộc vào bối cảnh phát triển phần mềm. Phần mềm cần được kiểm thử khác nhau tùy thuộc vào loại của nó. Ví dụ: một trang web công nghệ giáo dục nên được kiểm thử khác với một ứng dụng Android.

Sự khác biệt giữa kiểm thử chức năng và kiểm thử phi chức năng là gì?

Kiểm thử chức năng	Kiểm thử phi chức năng
Được thực hiện trước kiểm thử phi chức năng	Được thực hiện sau kiểm thử chức năng
Được thực hiện dựa trên yêu cầu của khách hàng	Được thực hiện dựa trên sự mong đợi của khách hàng và yêu cầu của developer và kiến thức kỹ thuật của nhóm phát triển
Rất dễ dàng để xác định được các yêu cầu chức năng	Rất khó để xác định các yêu cầu cho kiểm thử phi chức năng
Xác minh chức năng của hệ thống hoặc cách hoạt động của hệ thống	Xác minh hệ thống đáp ứng tốt như thế nào và hiệu suất của hệ thống
Dễ thực hiện bằng cách kiểm tra thủ công	Rất khó để thực hiện kiểm thử phi chức năng một cách thủ công
Bao gồm các loại kiểm thử: Kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận	Bao gồm các loại kiểm thử: Kiểm tra hiệu suất, kiểm tra bảo mật, kiểm tra khả năng sử dụng, v.v.
Được thực hiện ở nhiều giai đoạn phát triển khác nhau	Thường được thực hiện sau khi thử nghiệm chức năng

Mục đích của dữ liệu kiểm thử là gì? Làm thế nào để bạn tạo một bộ dữ liệu (dataset) kiểm thử hiệu quả?

Thông thường phần mềm đang được kiểm thử sẽ được đặt trong môi trường staging, nơi không có sẵn dữ liệu sử dụng. Một số test case nhất định yêu cầu dữ liệu từ người dùng thực, chẳng hạn như kiểm thử tính năng Đăng nhập, bao gồm việc người dùng nhập một số kết hợp tên người dùng và mật khẩu nhất định.

Trong những trường hợp như vậy, Tester cần chuẩn bị một bộ dữ liệu kiểm thử bao gồm tên người dùng và mật khẩu giả để mô phỏng các tương tác thực tế của người dùng với hệ thống.

Khi tạo tập dữ liệu kiểm thử, cần xem xét một số tiêu chí sau:

Mức độ liên quan của dữ liệu: Dữ liệu có liên quan đến ứng dụng đang được kiểm thử không? Dữ liệu có đại diện cho các kịch bản trong thế giới thực không?
Đa dạng dữ liệu: Có nhiều loại dữ liệu khác nhau không (giá trị hợp lệ/không hợp lệ/ranh giới, ký tự đặc biệt, v.v.)? Các loại dữ liệu này có bao gồm đủ các kết hợp đầu vào để đạt được phạm vi bao phủ tối đa không?
Tính đầy đủ của dữ liệu: Dữ liệu có bao gồm tất cả các yếu tố cần thiết cho trường hợp cụ thể đó không (ví dụ: các trường bắt buộc/tùy chọn).
Kích thước dữ liệu: Nên sử dụng tập dữ liệu nhỏ hay lớn?
Bảo mật dữ liệu: Có thông tin nhạy cảm/bí mật nào trong tập dữ liệu không? Dữ liệu kiểm thử có được quản lý và lưu trữ đúng cách không?
Độc lập dữ liệu: Dữ liệu kiểm thử có độc lập với các test case khác không? Dữ liệu kiểm thử của test case này có can thiệp vào kết quả của test case khác không?

Shift left testing (Kiểm thử dịch chuyển trái) là gì?

Kiểm thử dịch chuyển trái là phương pháp kiểm thử phần mềm tập trung vào việc tiến hành các hoạt động kiểm thử sớm hơn trong quá trình phát triển.

Cách tiếp cận này liên quan đến việc chuyển tất cả các hoạt động kiểm thử sang các giai đoạn phát triển sớm hơn thay vì đợi đến giai đoạn cuối cùng. Mục đích của nó là chủ động xác định và giải quyết các lỗi ở giai đoạn đầu, từ đó ngăn chặn sự lây lan của chúng trong toàn bộ ứng dụng. Bằng cách giải quyết vấn đề sớm hơn, chi phí và công sức cần thiết để khắc phục chúng sẽ giảm xuống.

Mặt khác, shift right testing hay còn gọi là kiểm thử trong production, tập trung vào việc tiến hành các hoạt động kiểm thử sau quá trình phát triển. Nó liên quan đến việc thu thập thông tin chuyên sâu từ phản hồi và tương tác thực tế của người dùng sau khi phần mềm được triển khai. Sau đó, các Developer sử dụng những insight đó để cải thiện chất lượng phần mềm và đưa ra các ý tưởng về tính năng mới.

Kiểm thử dịch chuyển trái khác với kiểm thử dịch chuyển phải như thế nào?

Tiêu chí	Shift Left Testing	Shift Right Testing
Bắt đầu kiểm thử	Bắt đầu kiểm thử sớm trong quá trình phát triển	Bắt đầu kiểm thử sau khi phát triển và triển khai
Mục tiêu	Phát hiện và ngăn ngừa lỗi sớm	Tìm kiếm các vấn đề trong sản xuất và các tình huống thực tế
Hoạt động kiểm thử	Kiểm thử tĩnh, kiểm thử đơn vị, kiểm thử tích hợp liên tục	Kiểm thử thăm dò, kiểm thử khả năng sử dụng, giám sát và phân tích phản hồi
Hợp tác	Sự hợp tác giữa Developer và Tester ngay từ đầu	Phối hợp với các nhóm vận hành và hỗ trợ khách hàng
Phát hiện lỗi	Phát hiện sớm và giải quyết các defect	Phát hiện lỗi trong môi trường production và sử dụng trực tiếp
Tác động về thời gian và chi phí	Giảm thời gian và chi phí phát triển tổng thể	Có thể tăng chi phí do các vấn đề được phát hiện trong production
Thời gian ra mắt	Nhanh hơn do phát hiện lỗi sớm	Có thể ảnh hưởng đến thời gian đưa sản phẩm ra thị trường do các vấn đề sau sản xuất
Tự động hóa kiểm thử	Phụ thuộc đáng kể vào tự động hóa kiểm thử	Tự động hóa kiểm thử có thể được sử dụng để theo dõi và phản hồi liên tiếp
Agile và DevOps	Phù hợp với các phương pháp Agile và DevOps	Bổ sung DevOps bằng cách tập trung vào môi trường production
Vòng lặp thông tin phản hồi	Phản hồi liên tục trong suốt SDLC	Phản hồi liên tục từ người dùng và hoạt động thực tế
Rủi ro và lợi ích	Giảm rủi ro về các defect lớn trong quá trình sản xuất	Xác định các vấn đề có thể không rõ ràng trong quá trình phát triển
Cải tiến liên tục	Cho phép cải tiến liên tục dựa trên phản hồi sớm	Thúc đẩy cải tiến dựa trên việc sử dụng trong thế giới thực và phản hồi của khách hàng

Defect là gì và bạn báo cáo defect như thế nào cho hiệu quả?

Defect là một lỗi trong ứng dụng phần mềm khiến nó hoạt động theo cách không mong muốn. Chúng còn được gọi là bug và thường những thuật ngữ này được sử dụng thay thế cho nhau, mặc dù có một số khác biệt nhỏ giữa chúng.

Để báo cáo defect/ bug một cách hiệu quả, có một số phương pháp như sau:

Cố gắng tái hiện nó một cách nhất quán và mô tả các bước chính xác để kích hoạt vấn đề đó để các developer giải quyết vấn đề dễ dàng hơn.
Sử dụng công cụ theo dõi lỗi như Jira, Bugzilla hoặc GitHub Issues để quản lý lỗi một cách hiệu quả hơn.
Cung cấp tiêu đề rõ ràng và mô tả cho lỗi.
Viết mô tả cụ thể cao bao gồm tất cả thông tin liên quan về lỗi (môi trường, các bước tái tạo, hành vi dự kiến, hành vi thực tế, tần suất, mức độ nghiêm trọng, v.v.).
Thêm ảnh chụp màn hình nếu cần.

Giải thích vòng đời của defect

Vòng đời của defect là một quá trình trong đó defect tiến triển qua nhiều giai đoạn, bao gồm các bước liên quan đến việc xử lý lỗi hoặc lỗi trong quá trình phát triển phần mềm. Chu trình bắt đầu khi một defect được phát hiện và kết thúc khi defect được khắc phục sau khi đã xác minh rằng lỗi đó sẽ không được tái tạo.

Chu trình này cho phép quản lý lỗi hiệu quả, trao quyền cho các nhóm phát hiện và giải quyết vấn đề một cách hiệu quả.

Có 2 cách tiếp cận để mô tả vòng đời lỗi: theo quy trình làm việc và theo trạng thái lỗi.

Biểu đồ ở trên minh họa vòng đời của bug, thực hiện theo các bước sau:

Tester thực hiện các kiểm thử.
Tester báo cáo các lỗi mới được tìm thấy và gửi chúng đến hệ thống quản lý lỗi, đặt trạng thái lỗi thành mới.
Project lead, Project manager và Tester xem xét các lỗi được báo cáo và quyết định xem có nên sửa chúng hay không. Nếu cần, các developer sẽ xử lý chúng, cập nhật trạng thái lỗi thành đang xử lý hoặc đang được điều tra.
Developer điều tra và tái hiện các lỗi.
Developer sửa lỗi nếu tái hiện bug thành công. Mặt khác, họ yêu cầu thêm thông tin từ Tester và cập nhật trạng thái lỗi tương ứng.
Tester cung cấp thêm mô tả hoặc sử dụng các công cụ báo cáo lỗi để giải thích chi tiết về lỗi.
Tester xác minh bản sửa lỗi bằng cách thực hiện các bước được mô tả trong báo cáo lỗi.
Tester sẽ đóng lỗi nếu bản sửa lỗi được xác minh. Nếu không, họ sẽ cập nhật trạng thái lỗi và đưa ra giải thích thêm.

Sự khác biệt giữa kiểm thử thủ công và kiểm thử tự động là gì?

Kiểm thử tự động có hiệu quả cao đối với kiểm thử hồi quy quy mô lớn với hàng nghìn test case cần được thực hiện lặp đi lặp lại. Không giống như con người, máy móc mang lại tính nhất quán và độ chính xác cao, làm giảm khả năng xảy ra “human error”.

Tuy nhiên, kiểm thử thủ công phù hợp đối với các dự án nhỏ hơn, kiểm thử ad-hoc và kiểm thử thăm dò (exploratory testing). Việc tạo tập lệnh kiểm thử tự động hóa cho những trường hợp như vậy đòi hỏi nhiều nỗ lực hơn là chỉ kiểm thử chúng theo cách thủ công, chủ yếu vì hai lý do:

Các test case này không lặp lại: Tự động hóa không phù hợp đối với các nhiệm vụ chỉ thực hiện một lần.
Mục tiêu của các kiểm thử này là để phát hiện các lỗi ẩn, chưa xác định và chúng không dựa trên các test case được xác định trước: Sự sáng tạo của con người đóng một vai trò quan trọng ở đây, thứ mà máy móc còn thiếu.

Hơn nữa, trong các dự án nhỏ hơn, Tester có thể gặp khó khăn trong việc xác định xem test case có đủ lặp lại để được tự động hóa hay không. Ở giai đoạn đầu, việc duy trì các bài kiểm thử tự động có thể đòi hỏi khắt khe hơn so với việc thực hiện chúng theo cách thủ công.

Do đó, quyết định có nên tự động hóa hay không phụ thuộc rất nhiều vào yêu cầu kinh doanh, thời gian, hạn chế về nguồn lực và mục tiêu của dự án phát triển phần mềm.

Đọc thêm: Selenium testing là gì? Các thành phần cơ bản và cách kiểm thử tự động hiệu quả với Selenium

Giải thích Kim tự tháp kiểm thử (Test Pyramid)?

Test Pyramid là một chiến lược kiểm thử thể hiện sự phân bổ của các loại kiểm thử tự động khác nhau dựa trên phạm vi và độ phức tạp của chúng.

Test Pyramid bao gồm ba lớp: kiểm thử đơn vị ở cơ sở, kiểm thử tích hợp ở giữa và kiểm thử giao diện người dùng ở trên cùng.

Kiểm thử đơn vị là nền tảng của kim tự tháp. Kiểm thử đơn vị tập trung vào việc kiểm thử các phần code nhỏ, độc lập một cách riêng biệt. Các kiểm thử này nhanh chóng và tiết kiệm chi phí vì chúng xác minh các đơn vị code riêng lẻ và có thể được thực hiện bởi các developer bằng ngôn ngữ lập trình của họ.

Phần giữa là kiểm thử API và kiểm thử tích hợp, tập trung vào kiểm thử luồng dữ liệu giữa các thành phần phần mềm và hệ thống bên ngoài.

Phần ở trên cùng biểu thị kiểm thử UI (giao diện người dùng). Những kiểm thử này tốn kém và tốn thời gian nhất vì chúng xác minh giao diện người dùng của ứng dụng và sự tương tác giữa các thành phần khác nhau. Chúng được thực hiện muộn hơn trong chu kỳ phát triển và dễ gặp lỗi hơn khi có những thay đổi nhỏ trong code cấp đơn vị gây ra lỗi trên toàn ứng dụng.

Kim tự tháp kiểm thử này khuyến khích số lượng kiểm thử đơn vị cấp thấp nhiều hơn để đảm bảo chức năng cốt lõi hoạt động chính xác, trong khi số lượng kiểm thử giao diện người dùng cấp cao ít hơn sẽ xác minh hành vi ứng dụng tổng thể nhưng với chi phí và độ phức tạp cao hơn. Thực hiện theo phương pháp này giúp các nhóm đạt được phạm vi kiểm thử toàn diện cao với phản hồi nhanh hơn và giảm nỗ lực kiểm thử.

Mô tả sự khác biệt giữa kiểm thử hộp đen, kiểm thử hộp trắng và kiểm thử hộp xám

Kiểm thử hộp đen tập trung vào việc kiểm thử chức năng của phần mềm mà không xem xét cấu trúc code nội bộ hoặc chi tiết triển khai của nó. Tester coi phần mềm như một “hộp đen” – nghĩa là họ không có kiến thức về cách thức hoạt động bên trong của nó. Mục tiêu là xác nhận rằng phần mềm đáp ứng các yêu cầu đã chỉ định và hoạt động như mong đợi từ quan điểm của người dùng cuối.

Kiểm thử hộp trắng bao gồm việc kiểm thử cấu trúc bên trong, logic và cách triển khai code của ứng dụng phần mềm. Tester có quyền truy cập vào mã nguồn và sử dụng kiến thức này để thiết kế các test case. Trọng tâm là xác thực tính chính xác của code, đảm bảo rằng tất cả các câu lệnh, nhánh và đường dẫn đều được thực hiện.

Kiểm thử hộp xám là sự kết hợp giữa các phương pháp kiểm thử hộp đen và hộp trắng. Tester có kiến thức một phần về hoạt động bên trong của phần mềm, chẳng hạn như kiến trúc, thuật toán hoặc cấu trúc cơ sở dữ liệu. Tuy nhiên, mức độ thông tin cung cấp cho tester bị hạn chế, tạo ra sự cân bằng giữa việc hoàn toàn không biết gì của kiểm thử hộp đen và khả năng truy cập đầy đủ vào của kiểm thử hộp trắng.

Giải thích khái niệm CI/CD

CI/CD là viết tắt của Continuous Integration (Tích hợp liên tục) và Continuous Delivery (Phân phối liên tục, hoặc Triển khai liên tục) và nó là một tập hợp các thực tiễn và nguyên tắc được sử dụng trong phát triển phần mềm để hợp lý hóa quy trình xây dựng, kiểm thử và cung cấp các thay đổi phần mềm cho sản xuất.

Mục tiêu cuối cùng của CI/CD là cho phép phân phối các bản cập nhật phần mềm nhanh hơn, đáng tin cậy hơn và thường xuyên hơn cho người dùng cuối trong khi vẫn duy trì các tiêu chuẩn chất lượng cao.

Tích hợp liên tục là hoạt động tích hợp thường xuyên các thay đổi code từ nhiều developer vào kho lưu trữ chung. Các developer commit các thay đổi code của họ đối với kho lưu trữ này nhiều lần trong ngày. Mỗi commit sẽ kích hoạt quá trình xây dựng tự động và một loạt kiểm thử để đảm bảo rằng code mới được thêm vào sẽ tích hợp tốt với codebase hiện có mà không gây ra các lỗi nghiêm trọng.
Phân phối liên tục là phương pháp tự động hóa quy trình phát hành phần mềm để đảm bảo ứng dụng luôn ở trạng thái có thể triển khai. Với CD, mọi thay đổi vượt qua các bài kiểm thử tự động trong giai đoạn CI sẽ được tự động triển khai sang môi trường staging hoặc tiền sản xuất. Quá trình này làm giảm nguy cơ lỗi của con người trong quá trình phát hành và đảm bảo rằng phần mềm luôn sẵn sàng và nhanh chóng để kiểm thử và xác nhận.

Làm thế nào để đảm bảo phạm vi kiểm thử toàn diện trong quá trình kiểm thử?

Để đảm bảo phạm vi kiểm thử toàn diện trong quá trình kiểm thử, bạn có thể xem xét các tiêu chí sau:

Phân tích yêu cầu kỹ lưỡng: Hiểu các yêu cầu của dự án để xác định tất cả các chức năng và tình huống cần kiểm thử.
Kiểm thử tập trung vào rủi ro: Sắp xếp kiểm thử theo hậu quả và khả năng thất bại đối với từng tính năng.
Phát triển test script kỹ lưỡng: Phát triển các test script giải quyết các điều kiện tiêu cực và điều kiện giới hạn.
Kiểm thử thăm dò: Thực hiện test để tìm ra vấn đề.
Đánh giá Code Coverage: Sử dụng các công cụ để theo dõi việc thực thi code trong quá trình kiểm thử, đảm bảo rằng tất cả các lộ trình code đều được đánh giá.
Ma trận truy xuất yêu cầu: Liên kết các test case tới các yêu cầu để theo dõi và đảm bảo tất cả các yêu cầu đều được kiểm thử.
Cải tiến liên tục: Thường xuyên cập nhật các test case để phản ánh các thay đổi, đảm bảo độ coverage theo thời gian.

Kế hoạch kiểm thử là gì và bao gồm những gì?

Kế hoạch kiểm thử lưu trữ tất cả các hoạt động kiểm thử có thể có để đảm bảo chất lượng sản phẩm. Nó thu thập dữ liệu từ tài liệu mô tả sản phẩm, yêu cầu và trường hợp sử dụng.

Kế hoạch kiểm thử bao gồm các nội dung sau:

Mục tiêu kiểm thử
Phạm vi kiểm thử
Môi trường và nguồn lực
Lý do kiểm thử
Tiêu chí đầu vào và đầu ra
Sản phẩm bàn giao
Các yếu tố rủi ro

Báo cáo kiểm thử là gì? Bao gồm những gì?

Báo cáo kiểm thử về cơ bản là một tài liệu bao gồm tổng hợp các mục tiêu, hoạt động và kết quả kiểm thử. Việc phản ánh kết quả kiểm thử là rất cần thiết và tạo cơ hội để ước tính kết quả kiểm thử một cách nhanh chóng. Nó giúp Tester quyết định xem sản phẩm đã sẵn sàng để phát hành hay chưa. Nó còn giúp bạn xác định được hiện trạng của dự án và chất lượng của sản phẩm.

Báo cáo kiểm thử phải bao gồm các chi tiết sau:

Mục tiêu kiểm thử
Thông tin dự án
Defect
Tóm tắt test

Kiểm thử API là gì?

Kiểm thử API là một loại kiểm thử phần mềm đòi hỏi phải đánh giá phương thức kết nối ứng dụng (API) để xem liệu chúng có đáp ứng các yêu cầu về chức năng, độ tin cậy, hiệu suất và bảo mật hay không. Nói một cách đơn giản, kiểm thử API được thiết kế để phát hiện các khiếm khuyết, sự không nhất quán hoặc sai lệch so với hành vi mong đợi của API.

Thông thường, các ứng dụng được chia thành ba lớp:

Giao diện người dùng còn được gọi là lớp trình bày.
Để xử lý logic nghiệp vụ, Lớp nghiệp vụ hoặc giao diện người dùng ứng dụng được sử dụng.
Kiểm thử API được thực hiện ở lớp kiến trúc phần mềm quan trọng nhất, Lớp nghiệp vụ, để lập mô hình và thao tác dữ liệu.

Câu hỏi phỏng vấn Tester dành cho Junior/ Middle

Các phương pháp tốt nhất để viết test case là gì?

Dưới đây là 10 phương pháp viết test case tốt nhất:

Phát triển các test case rõ ràng, ngắn gọn và đi vào trọng tâm.
Đảm bảo rằng các test case thách thức chức năng của phần mềm ở mọi khía cạnh.
Hãy chắc chắn rằng các test case đáp ứng tất cả các yêu cầu.
Phát triển các test case lặp lại có thể được tự động hóa khi cần thiết.
Phát triển các test case độc lập với nhau.
Sử dụng tên mô tả có ý nghĩa và mang tính mô tả cho các test case.
Ghi lại kết quả của các test case để tham khảo trong tương lai.
Đảm bảo rằng các test case có tính module và có thể được tái sử dụng.
Thực hiện đánh giá các test case để đảm bảo tính chính xác và đầy đủ.
Ghi lại các test case ở định dạng tiêu chuẩn.

Bạn sắp xếp mức độ ưu tiên của các test case như thế nào?

Một số test case nhất định cần được ưu tiên thực hiện để các khu vực quan trọng và có rủi ro cao hơn được kiểm thử trước. Đây cũng là một cách thực hành tốt để quản lý tài nguyên kiểm thử hoặc đáp ứng các mốc thời gian của dự án.

Có một số cách tiếp cận để ưu tiên các test case:

Cách tiếp cận dựa trên rủi ro: Xác định các khu vực có rủi ro cao hơn để kiểm thử trước (các chức năng quan trọng, tác động lớn đến kết quả kinh doanh, module phức tạp, module có nhiều phụ thuộc hoặc thành phần có lịch sử lỗi)
Cách tiếp cận chức năng: Xác định các test case cho các tính năng cốt lõi để kiểm thử trước.
Cách tiếp cận tần suất: Ưu tiên các test case cho các thành phần được người dùng sử dụng nhiều.
Điểm tích hợp: Tùy thuộc vào phạm vi của dự án kiểm thử, chúng ta có thể ưu tiên các test case cho các điểm kết nối quan trọng giữa các thành phần phần mềm
Các script quan trọng về hiệu suất: Ưu tiên các test case liên quan đến các script quan trọng đến hiệu suất. Điều này đảm bảo rằng phần mềm đã sẵn sàng cho lưu lượng truy cập lớn
Phương pháp bảo mật: Xác định các khu vực có rủi ro bảo mật cao để kiểm thử trước.
Ưu tiên từ các bên liên quan: Tính đến đầu vào và mức độ ưu tiên của các bên liên quan chính, chẳng hạn như project manager, product owner và người dùng cuối.

Mô hình chữ V trong kiểm thử phần mềm là gì? Nó khác với mô hình thác nước (waterfall) truyền thống như thế nào?

Mô hình chữ V là mô hình kiểm thử phần mềm nhấn mạnh các hoạt động kiểm thử phù hợp với các giai đoạn phát triển tương ứng.

Mô hình chữ V khác với mô hình thác nước truyền thống ở chỗ tích hợp các hoạt động kiểm thử ở từng giai đoạn phát triển, tạo thành hình chữ “V”. Trong mô hình chữ V, các hoạt động kiểm thử diễn ra song song với các giai đoạn phát triển, thúc đẩy việc phát hiện lỗi sớm.

Mô tả khái niệm phát triển dựa trên kiểm thử (Test-driven Development – TDD) và nó ảnh hưởng như thế nào đến quá trình kiểm thử?

TDD là một phương pháp phát triển phần mềm trong đó các test case được viết trước code thực tế.

Lập trình viên tạo các bài kiểm thử đơn vị tự động để xác định chức năng mong muốn. Sau đó, họ viết code để vượt qua các bài kiểm thử này. TDD ảnh hưởng đến quá trình kiểm thử bằng cách đảm bảo phạm vi kiểm thử tốt hơn và phát hiện các lỗi sớm hơn.

Những thách thức phổ biến trong kiểm thử ứng dụng di động là gì?

Phân mảnh thiết bị: Số lượng lớn thiết bị di động với kích thước màn hình, độ phân giải, hệ điều hành và cấu hình phần cứng khác nhau khiến việc kiểm thử trên tất cả các thiết bị với các yếu tố kết hợp trên có thể trở nên khó khăn.
Phiên bản hệ điều hành và nền tảng: Việc kiểm thử trên các phiên bản và nền tảng hệ điều hành khác nhau sẽ gây ra các vấn đề về khả năng tương thích vì các thiết bị cũ hơn có thể không hỗ trợ các bản cập nhật phần mềm mới nhất.
Điều kiện mạng: Ứng dụng dành cho thiết bị di động phụ thuộc nhiều vào kết nối mạng và việc kiểm thử trong các điều kiện mạng khác nhau (3G, 4G, Wi-Fi) là điều cần thiết để xác thực hiệu suất ứng dụng.
Phê duyệt App Store: Các nguyên tắc nghiêm ngặt của App Store và quy trình xem xét có thể dẫn đến sự chậm trễ trong việc phát hành và cập nhật ứng dụng.
Kiểm thử gián đoạn: Việc xử lý các gián đoạn như cuộc gọi đến, tin nhắn hoặc tình huống pin yếu mà không gặp sự cố ứng dụng có thể có độ phức tạp cao.
Tài nguyên hạn chế: Thiết bị di động có tài nguyên hạn chế (CPU, bộ nhớ) và các ứng dụng phải hoạt động hiệu quả dưới những hạn chế này.

Một số số liệu kiểm thử quan trọng là gì?

Các số liệu kiểm thử giúp cung cấp cái nhìn tổng quan cấp cao cho ban quản lý hoặc Developer về cách dự án đang diễn ra và các bước hành động tiếp theo.

Dưới đây là một số số liệu được lấy từ bản ghi các kiểm thử và thất bại:

Tổng số lỗi được tìm thấy, sắp xếp theo mức độ nghiêm trọng của chúng
Tổng số lỗi đã được sửa
Tổng số sự cố do lỗi trong mã nguồn so với cấu hình hoặc các yếu tố môi trường bên ngoài
Tỷ lệ tìm và sửa lỗi theo thời gian
Lỗi theo khu vực sản xuất/tính năng
Thời gian trung bình để xảy ra một lỗi kể từ khi nó được tìm thấy và sửa
Tổng thời gian dành cho việc phát triển tính năng mới so với thời gian dành cho việc giải quyết bug và thất bại
Số lỗi tồn đọng trước khi phát hành
Bug/ thất bại do khách hàng báo cáo so với lỗi do tester tìm thấy

Giải thích về sanity testing trong kiểm thử phần mềm

Thuật ngữ sanity testing đề cập đến một tập hợp con của kiểm thử hồi quy.

Sanity testing đảm bảo rằng những thay đổi được thực hiện đối với code không ảnh hưởng xấu đến hiệu suất của hệ thống. Sau khi nhận được bản dựng phần mềm, quá trình sanity test sẽ được tiến hành để đảm bảo rằng những thay đổi được thực hiện đối với code đang hoạt động chính xác. Là một checkpoint, kiểm thử này được sử dụng để xác định xem liệu bản dựng có thể tiến hành kiểm thử thêm hay không.

Sanity testing tập trung vào việc xác nhận chức năng của ứng dụng hơn là kiểm thử chi tiết.

Đặc trưng của sanity testing:

Tập trung vào một phần nhỏ hơn của ứng dụng và là một tập hợp con của kiểm thử hồi quy.
Quá trình này không được document lại.
Sanity test thường không được script.
Trong phương pháp này, các chức năng hạn chế sẽ được kiểm thử sâu.
Tester thường chịu trách nhiệm thực hiện nhiệm vụ này.

Mối quan hệ giữa thực tế môi trường và các giai đoạn kiểm thử là gì?

Khi các giai đoạn kiểm thử bắt đầu tiến triển, thực tế môi trường trở nên quan trọng hơn.

Ví dụ như trong bảng dưới: Trong khi kiểm thử đơn vị, bạn cần môi trường thực một phần, nhưng ở giai đoạn kiểm thử chấp nhận, bạn nên có môi trường thực 100% hoặc có thể nói đó phải là môi trường trong thực tế.

Biểu đồ bên dưới cho thấy trong quá trình thử nghiệm chấp nhận, nó phải có thật 100%:

Kiểm thử ngẫu nhiên là gì?

Thông thường, trong Kiểm thử ngẫu nhiên, dữ liệu được tạo ngẫu nhiên thường bằng cách sử dụng một công cụ.

Ví dụ: Hình sau đây cho thấy cách dữ liệu được tạo ngẫu nhiên được gửi đến hệ thống.

Dữ liệu này được tạo bằng cách sử dụng một công cụ hoặc một số cơ chế tự động. Với đầu vào được tạo ngẫu nhiên này, hệ thống sẽ được kiểm thử và kết quả sẽ được quan sát tương ứng.

Dựa trên cơ sở nào để bạn có thể đưa ra ước tính cho dự án của mình?

Để ước tính dự án, bạn phải xem xét các điểm sau:

Chia toàn bộ dự án thành các nhiệm vụ nhỏ nhất
Phân công từng nhiệm vụ cho các thành viên trong nhóm
Ước tính nỗ lực cần thiết để hoàn thành mỗi nhiệm vụ
Xác thực ước tính

Giải thích Kiểm thử tải (Load testing) trên trang web

Để truy cập một trang web, người dùng sẽ gửi “yêu cầu” đến máy chủ của trang web đó và máy chủ sẽ gửi lại phản hồi dưới dạng trang web mà bạn muốn truy cập.

Để kiểm thử tải một trang web, QA và kỹ sư tự động hóa chỉ cần nhân số lượng phản hồi được gửi để mô phỏng các tải lưu lượng truy cập khác nhau. Sau đó có thể đo lường được phản ứng của máy chủ web đối với lượng người dùng ảo. Điều này được sử dụng để xác định các vấn đề về hiệu suất và dung lượng máy chủ.

Giải thích phân tích giá trị biên trong kiểm thử phần mềm

Phân tích giá trị biên (Boundary Value Analysis – BVA) là một kỹ thuật thiết kế kiểm thử hộp đen được áp dụng để xem liệu có bất kỳ lỗi nào ở ranh giới của miền đầu vào hay không.

Phân tích giá trị biên cung cấp các test case phù hợp vì nó đảm bảo rằng ranh giới của giá trị đầu vào và đầu ra được kiểm thử, giúp xác định các trường hợp biên dễ dàng hơn. Việc kiểm thử các trường hợp biên này đảm bảo rằng hệ thống của bạn hoạt động mạnh mẽ và có thể xử lý mọi giá trị đầu vào hoặc đầu ra không mong muốn.

Phân biệt Positive Testing và Negative Testing

Positive Testing	Negative Testing
Positive Testing đảm bảo rằng phần mềm hoạt động như mong đợi. Kiểm thử sẽ thất bại nếu xảy ra lỗi trong quá trình Positive Testing.	Negative Testing đảm bảo rằng ứng dụng có thể xử lý các hành vi không mong muốn của người dùng hoặc thông tin đầu vào không chính xác.
Trong loại kiểm thử này, Tester luôn tìm kiếm một bộ dữ liệu hợp lệ.	Tester cần khéo léo và sáng tạo khi thiết kế test case để xử lý dữ liệu đầu vào sai.

Sự khác biệt giữa kiểm thử hệ thống và kiểm thử tích hợp là gì?

Kiểm thử hệ thống là một loại kiểm thử phần mềm nhằm đánh giá một sản phẩm phần mềm hoàn chỉnh và được tích hợp đầy đủ hay chưa. Nó xác minh rằng phần mềm đáp ứng các yêu cầu được chỉ định trong thiết kế và các thông số kỹ thuật cấp hệ thống. Kiểm thử hệ thống cũng xác định bất kỳ điểm yếu, error hoặc bug nào đang tồn tại.

Kiểm thử tích hợp là một loại kiểm thử phần mềm nhằm xác minh sự tương tác giữa hai hoặc nhiều thành phần hệ thống. Nó được thực hiện sau khi kiểm thử đơn vị và trước khi kiểm thử hệ thống. Nó kiểm thử cách các thành phần tương tác với nhau và cách chúng khớp với nhau. Kiểm thử tích hợp là cần thiết để đảm bảo rằng các thành phần của hệ thống hoạt động cùng nhau đúng như mong đợi.

Cách tiếp cận từ trên xuống và từ dưới lên trong kiểm thử là gì?

Cách tiếp cận từ trên xuống và từ dưới lên trong kiểm thử đề cập đến thứ tự kiểm thử.

Kiểm thử từ trên xuống bắt đầu ở mức cao nhất và đi xuống. Do đó, kiểm thử bắt đầu từ các thành phần cấp cao và tiếp tục xuống các thành phần cấp thấp.
Kiểm thử từ dưới lên bắt đầu ở mức thấp nhất và tiến lên phía trên. Do đó, mỗi thành phần cấp thấp hơn được kiểm thử tách biệt với các thành phần cấp cao hơn.

Câu hỏi phỏng vấn Tester dành cho Senior

Điều gì sẽ xảy ra khi một defect có thể được loại bỏ trong giai đoạn đầu lại được loại bỏ ở giai đoạn sau?

Nếu ở giai đoạn đầu xác định được defect thì defect đó cần được loại bỏ ngay trong giai đoạn thay vì đợi đến giai đoạn sau.

Thực tế là nếu một defect bị trì hoãn ở các giai đoạn sau thì việc xử lý defect sẽ trở nên tốn kém hơn. Hình dưới đây cho thấy mức độ tổn thất của một defect khi tiến triển qua các giai đoạn.

Theo hình trên thì bạn có thể thấy là nếu một defect được xác định và loại bỏ trong giai đoạn thiết kế thì đó là cách hiệu quả nhất về mặt chi phí nhưng nếu loại bỏ trong quá trình bảo trì thì nó sẽ tốn kém hơn gấp 20 lần.

Theo bạn, Tester phần mềm cần có những phẩm chất gì?

Mục tiêu của bất kỳ Tester phần mềm nào là tìm ra càng nhiều lỗi và sự cố trong hệ thống để khách hàng không phải tìm ra. Do đó, một Tester phần mềm giỏi phải có con mắt chú ý đến chi tiết. Họ nên biết chi tiết về phần mềm mà họ đang kiểm thử và biết cách kiểm thử mọi khía cạnh của phần mềm cho đến giới hạn của nó nhằm xác định các lỗi khó tìm thấy khi sử dụng phần mềm thường xuyên.

Có kiến thức về lĩnh vực, ngành nghề của ứng dụng là điều cần thiết. Nếu Tester không hiểu các vấn đề cụ thể mà phần mềm đang cố gắng giải quyết, họ sẽ không thể kiểm thử kỹ lưỡng phần mềm đó.

Một Tester giỏi nên lưu ý đến người dùng cuối khi họ đang kiểm thử. Có sự đồng cảm với người dùng cuối giúp Tester đảm bảo rằng phần mềm có thể truy cập và sử dụng được. Sẽ là một điểm cộng nếu Tester có các kỹ năng lập trình cơ bản để suy nghĩ từ góc độ của Developer và cho phép họ nhận thấy các lỗi lập trình phổ biến.

Giao tiếp, cả bằng văn bản và bằng lời nói, là một kỹ năng cần thiết cho Tester. Tester sẽ thường xuyên phải tương tác với cả Developer và Project Manager, Product Owner. Họ phải có khả năng giải thích các lỗi và vấn đề được tìm thấy trong quá trình kiểm thử cho các bên. Đối với mỗi lỗi được tìm thấy, Tester phải cung cấp báo cáo lỗi chi tiết bao gồm tất cả thông tin mà Developer cần để khắc phục vấn đề đó.

Còn đối với QA Lead hoặc Tester Lead thì cần phải có những phẩm chất sau:

Thành thạo các quy trình kiểm thử phần mềm
Khả năng thúc đẩy tốc độ làm việc nhóm để tăng năng suất
Cải thiện sự phối hợp giữa các kỹ sư QA và Dev
Cung cấp ý tưởng để cải tiến quy trình QA
Kỹ năng tiến hành các cuộc họp RCA và đưa ra kết luận
Kỹ năng giao tiếp bằng văn bản và lời nói
Có khả năng học hỏi nhanh và hướng dẫn cho các thành viên trong nhóm

Phát triển dựa trên kiểm thử (Test-Driven-Development – TDD) là gì?

Test-Driven-Development (TDD) là một kỹ thuật phát triển phần mềm phổ biến, được Kent Beck giới thiệu lần đầu tiên trong cuốn sách cùng tên của ông, xuất bản năm 1999.

Trong TDD, trước khi phát triển một tính năng, Developer sẽ viết một test thất bại, sau đó chỉ viết đủ code để vượt qua bài kiểm thử đó. Khi họ vượt qua kiểm thử, họ sẽ viết thêm một test thất bại khác và sau đó sẽ viết code vừa đủ để vượt qua bài test thất bại đó. Chu kỳ này lặp đi lặp lại cho đến khi Developer có đầy đủ tính năng. Nếu code được kiểm thử có các phần phụ thuộc bên ngoài như cơ sở dữ liệu, tệp hoặc mạng, bạn có thể mô phỏng chúng để tách code.

Lợi ích của TDD:

Việc viết test trước buộc bạn phải xác định rõ các yêu cầu về tính năng mà bạn đang cố gắng xây dựng, giúp bạn viết code tốt hơn.
Vì bạn luôn có sẵn một bộ kiểm thử đang hoạt động nên việc kiểm thử không thành công cho thấy rằng vấn đề nằm ở code bạn vừa thêm vào, giúp giảm thời gian debug.
Viết test trước giúp Developer làm rõ các yêu cầu và đặc điểm kỹ thuật. Khá khó để viết các bài test tốt cho một tập hợp các yêu cầu kém.
TDD giúp bạn tự tin thêm code mới vì bạn đã có sẵn test. Cứ sau mỗi lần có thay đổi mới, bạn có thể biết chắc chắn rằng code mới thêm của mình sẽ không làm hỏng phần mềm đang hoạt động.

Các loại mức độ nghiêm trọng khác nhau mà bạn có thể gán cho một lỗi là gì?

Mức độ nghiêm trọng của lỗi còn tùy thuộc vào quy mô và cấu trúc phần mềm, nhưng thông thường, một lỗi có thể được phân loại theo các loại mức độ nghiêm trọng sau, từ thấp đến cao:

Mức độ nghiêm trọng thấp:

Lỗi giao diện người dùng.
Các vấn đề về khả năng tiếp cận.

Mức độ nghiêm trọng trung bình:

Rò rỉ trừu tượng.
Phần mềm bị treo.
Người dùng không thể thực hiện một hành động cụ thể.
Điều kiện biên.

Mức độ nghiêm trọng cao:

Crash khi chịu tải cao.
Lỗi logic kinh doanh và/hoặc lỗi tính toán.
Bất kỳ hành động nào của người dùng khiến phần mềm bị lỗi.
Tiết lộ dữ liệu người dùng.
Vấn đề bảo mật.
Mất dữ liệu.

Ma trận kiểm thử và Ma trận truy xuất yêu cầu là gì?

Ma trận kiểm thử được coi là một công cụ kiểm thử được sử dụng để nắm bắt chất lượng thực tế, nỗ lực, nguồn lực, kế hoạch và thời gian cần thiết bao gồm tất cả các giai đoạn kiểm thử phần mềm. Lưu ý rằng Ma trận kiểm thử chỉ bao gồm các giai đoạn trong vòng đời kiểm thử, không bao gồm cả vòng đời phát triển sản phẩm.

Ma trận truy xuất yêu cầu (Requirement Traceability Matrix – RTM) được coi là một tài liệu, thường có trong bảng biểu mẫu, được sử dụng để theo dõi và chứng minh mối quan hệ giữa các yêu cầu và các thành phần khác của dự án ngay từ đầu đến cuối. Nói một cách đơn giản, nó kết nối các test case với yêu cầu cụ thể của khách hàng để đảm bảo mọi yêu cầu đều được kiểm thử.

Kiểm thử phần mềm tĩnh (static software testing) là gì?

Kiểm thử tĩnh là một kỹ thuật trong đó bạn kiểm thử phần mềm mà không thực sự thực thi nó. Nó liên quan đến việc thực hiện các hướng dẫn code, đánh giá code, đánh giá ngang hàng hoặc sử dụng các công cụ phức tạp như eslint, StyleCop để thực hiện phân tích tĩnh source code. Kiểm thử tĩnh thường được thực hiện trong quá trình phát triển phần mềm.

Kiểm thử phần mềm động (dynamic software testing) là gì?

Ngược lại với kiểm thử tĩnh, kiểm thử phần mềm động sẽ kiểm thử phần mềm khi nó đang thực thi. Tester chạy phần mềm trong môi trường kiểm thử và thực hiện tất cả các bước liên quan, nhập thông tin đầu vào và so sánh đầu ra thực tế với kết quả mong đợi.

Bạn sẽ tiếp cận một chương trình có nhiều lỗi nghiêm trọng như thế nào?

Trong những trường hợp như vậy, cách tốt nhất là Tester nên thực hiện quá trình báo cáo mọi sai sót hoặc các vấn đề phát sinh và tập trung vào các lỗi nghiêm trọng.

Bởi vì các loại lỗi này có thể dẫn đến các vấn đề nghiêm trọng hơn như kiểm thử tích hợp hoặc kiểm thử đơn vị không hiệu quả, thiết kế kém, phương pháp xây dựng hoặc phương pháp phát hành sai, v.v.. Bạn nên liên hệ với Project Manager hoặc Product Owner và cung cấp tài liệu làm bằng chứng cho vấn đề này.

Các kỹ thuật kiểm thử dựa trên kinh nghiệm là gì?

Các kỹ thuật kiểm thử dựa trên kinh nghiệm bao gồm:

Kiểm thử thăm dò (Exploratory Testing)
Đoán lỗi (Error guessing)
Kiểm thử ad-hoc (Adhoc Testing)
Kiểm thử dựa trên danh sách kiểm thử (Checklist-based Testing)
Kiểm thử dựa trên khai thác (Exploit-based Testing)
Kiểm thử dựa trên phiên (Session-based Testing)
Kiểm thử Alpha
Kiểm thử Beta
Kiểm thử sự chấp nhận của người dùng (User Acceptance Testing)
Kiểm thử khả năng sử dụng (Usability Testing)

Thuật ngữ “chất lượng” có nghĩa là gì trong kiểm thử?

“Chất lượng” trong kiểm thử đề cập đến mức độ sản phẩm đáp ứng các yêu cầu dự kiến cũng như mức độ đáp ứng nhu cầu và mong đợi của khách hàng.

“Chất lượng” bao gồm cả khía cạnh chức năng và phi chức năng của sản phẩm. Đảm bảo chất lượng (quality assurance – QA) là đảm bảo rằng sản phẩm đáp ứng được các yêu cầu, trong khi kiểm soát chất lượng (quality control – QC) tập trung vào kiểm thử để đảm bảo rằng sản phẩm đáp ứng được các nhu cầu của người dùng.

Làm thế nào bạn xác định được khi nào nên ngừng kiểm thử?

Khi kiểm thử, điều quan trọng là xác định thời điểm dừng để tránh lãng phí tài nguyên. Để quyết định thời điểm dừng kiểm thử, bạn nên xem xét các tiêu chí sau:

Mức chất lượng mong muốn
Tuân thủ thời gian và ngân sách
Số lượng lỗi được tìm thấy
Số test case đã hoàn thành
Các yếu tố rủi ro liên quan đến dự án

Khi các tiêu chí này đã được đáp ứng, bạn có thể dừng kiểm thử.

Kiểm thử tự động có thể thay thế kiểm thử thủ công không?

Không, kiểm thử tự động không thể thay thế hoàn toàn kiểm thử thủ công.

Kiểm thử tự động được thiết kế để bổ sung cho kiểm thử thủ công chứ không phải thay thế nó. Kiểm thử tự động có thể tự động hóa các trường hợp kiểm thử lặp đi lặp lại, tẻ nhạt và làm cho quá trình kiểm thử hiệu quả hơn. Tuy nhiên, nó không thể thay thế hoàn toàn việc kiểm thử thủ công vì một số kiểm thử chỉ có thể được thực hiện thủ công.

Ví dụ: Kiểm thử thăm dò, kiểm thử khả năng sử dụng và kiểm thử trải nghiệm người dùng đều là các nhiệm vụ yêu cầu kiểm thử thủ công.

Tổng kết

Và trên đây là danh sách 40+ câu hỏi phỏng vấn Tester nhiều cấp độ. Hy vọng bộ 40+ câu hỏi phỏng vấn Tester, kèm câu trả lời, ở trên đã giúp ích cho bạn trong việc bổ sung thêm kiến thức và chuẩn bị cho buổi phỏng vấn kỹ thuật sắp tới!

Đọc thêm: Khóa học Tester: 10+ khóa học Tester cho người mới bắt đầu