50+ Câu hỏi phỏng vấn Tester phổ biến nhất hiện nay
Mức độ cơ bản:
1. Kiểm thử phần mềm là gì?
Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm kiếm và phát hiện lỗi trong phần mềm, đảm bảo rằng nó hoạt động chính xác và đầy đủ theo yêu cầu của khách hàng. Quá trình này bao gồm các việc như thực thi các trường hợp kiểm thử, đánh giá tài liệu, thiết kế, mã nguồn và các yếu tố khác liên quan đến sản phẩm,...
2. Có những loại kiểm thử phần mềm nào?
Có nhiều loại kiểm thử phần mềm, mỗi loại phục vụ cho những mục đích khác nhau trong quá trình phát triển và đảm bảo chất lượng phần mềm. Dưới đây là một số loại kiểm thử phần mềm cơ bản:
● Kiểm thử chức năng (Functional Testing): Kiểm thử chức năng tập trung vào việc xác định xem phần mềm có thực hiện đúng các chức năng theo yêu cầu hay không.
● Kiểm thử phi chức năng (Non-Functional Testing): Loại kiểm thử này xem xét các yếu tố không liên quan đến chức năng, như hiệu suất, khả năng sử dụng, và tính bảo mật.
● Kiểm thử lại (Re-Testing): Đây là quá trình xác nhận rằng các lỗi đã được sửa chữa hoạt động đúng như mong đợi. Nó thường được thực hiện sau khi sửa lỗi để đảm bảo rằng vấn đề đã được khắc phục.
● Kiểm thử hồi quy (Regression Testing): Loại kiểm thử này nhằm đảm bảo rằng các chức năng cũ vẫn hoạt động đúng sau khi có sự thay đổi trong mã nguồn hoặc môi trường.
3. Các giai đoạn khác nhau của vòng đời kiểm thử phần mềm là gì?
Vòng đời kiểm thử phần mềm (Software Testing Life Cycle - STLC) bao gồm nhiều giai đoạn khác nhau, mỗi giai đoạn đóng vai trò quan trọng trong việc đảm bảo chất lượng sản phẩm phần mềm.
Các giai đoạn của vòng đời kiểm thử phần mềm gồm có:
● Phân tích yêu cầu: Phân tích yêu cầu chức năng và phi chức năng để xác định các trường hợp kiểm thử.
● Lập kế hoạch kiểm thử: Xác định phạm vi, nguồn lực và thời gian cho quy trình kiểm thử.
● Phát triển kịch bản kiểm thử: Thiết kế các kịch bản và trường hợp kiểm thử chi tiết.
● Thiết lập môi trường kiểm thử: Cấu hình phần cứng, phần mềm và dữ liệu cần thiết cho việc kiểm thử.
● Thực thi kiểm thử: Thực hiện các kịch bản kiểm thử và ghi lại kết quả, báo cáo lỗi.
● Kiểm tra & kết thúc chu kỳ kiểm thử: Tổng hợp kết quả, đánh giá hiệu quả và chuẩn bị báo cáo kết thúc.
4. Các cấp độ kiểm tra khác nhau là gì?
Các cấp độ kiểm tra phần mềm là những giai đoạn khác nhau trong quy trình kiểm thử, mỗi giai đoạn tập trung vào một phần cụ thể của phần mềm để đảm bảo rằng sản phẩm hoạt động đúng như mong đợi và đáp ứng các yêu cầu đã đặt ra. Dưới đây là bốn cấp độ kiểm thử chính:
Kiểm thử đơn vị (Unit Testing)
● Mục đích: Để xác nhận rằng từng thành phần nhỏ nhất của phần mềm (module) hoạt động đúng với thiết kế.
● Thực hiện bởi: Thường do các lập trình viên thực hiện.
● Đặc điểm: Kiểm thử từng module riêng lẻ mà không cần tích hợp với các module khác. Điều này giúp phát hiện lỗi sớm trong quá trình phát triển.
Kiểm thử tích hợp (Integration Testing)
● Mục đích: Để kiểm tra sự tương tác giữa các module đã được tích hợp lại với nhau.
● Thực hiện bởi: Các tester hoặc lập trình viên.
● Đặc điểm: Tập trung vào việc xác minh rằng dữ liệu có thể truyền tải đúng giữa các module và phát hiện lỗi khi các module tương tác với nhau. Có thể sử dụng nhiều phương pháp như top-down, bottom-up hoặc big bang để thực hiện kiểm thử này.
Kiểm thử hệ thống (System Testing)
● Mục đích: Đánh giá toàn bộ hệ thống để đảm bảo rằng nó đáp ứng tất cả các yêu cầu chức năng và phi chức năng đã được đề ra.
● Thực hiện bởi: Thường do một nhóm kiểm thử độc lập thực hiện.
● Đặc điểm: Bao gồm việc kiểm tra toàn bộ hệ thống sau khi tất cả các module đã được tích hợp, nhằm phát hiện lỗi trong thiết kế hoặc trong quá trình hoạt động của hệ thống.
Kiểm thử chấp nhận (Acceptance Testing)
● Mục đích: Để xác nhận rằng phần mềm đáp ứng yêu cầu của khách hàng và sẵn sàng cho việc triển khai.
● Thực hiện bởi: Khách hàng hoặc đại diện của khách hàng.
● Đặc điểm: Có hai loại chính là Alpha Testing (thực hiện trong môi trường phát triển) và Beta Testing (thực hiện trong môi trường thực tế với người dùng cuối). Giai đoạn này nhằm đảm bảo rằng sản phẩm cuối cùng phù hợp với nhu cầu sử dụng thực tế của người dùng.
5. Kiểm thử trường hợp sử dụng là gì?
Kiểm thử trường hợp sử dụng là một khái niệm quan trọng trong lĩnh vực kiểm thử phần mềm, được định nghĩa là một tập hợp các điều kiện, thông số đầu vào, hành động thực hiện, và kết quả mong đợi nhằm kiểm tra một chức năng cụ thể của phần mềm. Mục tiêu chính của test case là đảm bảo rằng phần mềm hoạt động đúng theo yêu cầu và tiêu chuẩn đã được đặt ra.
6. Ma trận truy xuất nguồn gốc là gì?
Ma trận truy xuất nguồn gốc (Requirement Traceability Matrix - RTM) là một công cụ quan trọng trong quản lý yêu cầu, đặc biệt trong lĩnh vực phát triển phần mềm và kỹ thuật. Ma trận truy xuất nguồn gốc giúp theo dõi và xác minh rằng tất cả các yêu cầu của dự án đều được thực hiện và kiểm tra trong suốt vòng đời phát triển.
7. Tại sao kiểm thử phần mềm lại quan trọng?
Kiểm thử phần mềm là một giai đoạn thiết yếu trong quy trình phát triển phần mềm, với nhiều vai trò quan trọng:
● Phát hiện lỗi sớm: Kiểm thử giúp phát hiện và sửa chữa lỗi ngay từ giai đoạn đầu, giảm thiểu chi phí sửa chữa sau này và đảm bảo phần mềm hoạt động đúng như mong đợi.
● Tăng cường bảo mật: Quy trình kiểm thử giúp loại bỏ các lỗ hổng bảo mật, từ đó nâng cao độ tin cậy và an toàn cho người sử dụng.
● Đảm bảo chất lượng sản phẩm: Kiểm thử đảm bảo rằng sản phẩm đáp ứng đủ các yêu cầu về hình thức, giao diện và tính năng, giúp mang lại trải nghiệm tốt nhất cho người dùng.
● Tiết kiệm thời gian và chi phí: Việc kiểm thử hiệu quả không chỉ tiết kiệm thời gian trong quá trình phát triển mà còn giảm thiểu rủi ro và chi phí liên quan đến việc khắc phục lỗi sau khi sản phẩm đã được phát hành.
● Cải thiện quy trình phát triển: Kiểm thử là một phần không thể thiếu trong vòng đời phát triển phần mềm (SDLC), giúp xác định các vấn đề và cải tiến quy trình phát triển liên tục.
8. Trường hợp kiểm thử là gì?
Trường hợp kiểm thử được định nghĩa là một kịch bản mô tả các bước cần thực hiện để kiểm tra tính năng của phần mềm, gồm một tập hợp các điều kiện, thông số đầu vào, hành động thực hiện và kết quả mong đợi nhằm xác minh rằng một chức năng cụ thể của phần mềm hoạt động đúng như yêu cầu.
9. Kế hoạch kiểm tra bao gồm những gì?
Các thành phần chính trong kế hoạch kiểm thử gồm có:
● Mục tiêu và phạm vi kiểm thử: Xác định rõ ràng các mục tiêu của quá trình kiểm thử và những phần nào của sản phẩm sẽ được kiểm tra.
● Chiến lược kiểm thử: Định nghĩa các phương pháp và kỹ thuật sẽ được sử dụng trong quá trình kiểm thử.
● Tài nguyên cần thiết: Liệt kê phần cứng, phần mềm và các công cụ cần thiết cho việc thực hiện kiểm thử.
● Nhân sự và đào tạo: Xác định số lượng nhân viên tham gia kiểm thử và nhu cầu đào tạo nếu cần thiết.
● Môi trường kiểm thử: Mô tả môi trường mà các trường hợp kiểm thử sẽ được thực hiện, bao gồm cấu hình hệ thống và các điều kiện cần thiết.
● Lịch trình kiểm thử: Lập lịch cụ thể cho từng giai đoạn của quá trình kiểm thử, bao gồm thời gian bắt đầu và kết thúc cho từng hoạt động.
● Tiêu chí đầu vào và tiêu chí dừng: Xác định các điều kiện cần đạt được để bắt đầu và kết thúc quá trình kiểm thử.
● Quản lý rủi ro: Nhận diện các rủi ro có thể ảnh hưởng đến quá trình kiểm thử và lập kế hoạch giảm thiểu chúng.
● Kênh thông tin liên lạc: Thiết lập cách thức giao tiếp giữa các thành viên trong nhóm kiểm thử để đảm bảo thông tin luôn được cập nhật và rõ ràng.
10. Đảm bảo chất lượng (QA) có nghĩa là gì?
Đảm bảo chất lượng (Quality Assurance - QA) là một tập hợp các hoạt động có kế hoạch và hệ thống nhằm ngăn ngừa lỗi hoặc khuyết tật trong sản xuất và hạn chế các vấn đề khi cung cấp sản phẩm hoặc dịch vụ đến tay khách hàng. Theo tiêu chuẩn ISO 9000, QA được định nghĩa là một phần trong quản lý chất lượng, tập trung vào việc đảm bảo rằng các yêu cầu về chất lượng sẽ được đáp ứng.
11. So sánh Mô hình thác nước và Mô hình Agile
Đặc điểm | Waterfall | Agile |
Phương pháp | Tuần tự, tuyến tính | Chu kỳ, linh hoạt |
Lập kế hoạch | Chi tiết từ đầu | Tối thiểu, điều chỉnh liên tục |
Tham gia của khách hàng | Giới hạn, chủ yếu ở giai đoạn đầu | Liên tục trong suốt quá trình |
Kiểm thử | Thực hiện sau khi hoàn thành phát triển | Tích hợp trong từng vòng lặp |
Giao hàng | Giao hàng một lần khi hoàn tất | Giao hàng từng phần trong mỗi sprint |
Quản lý rủi ro | Quản lý từ đầu | Quản lý liên tục |
12. Câu chuyện người dùng là gì?
Câu chuyện người dùng (user story) là một công cụ quan trọng trong phát triển phần mềm, đặc biệt trong các phương pháp Agile như Scrum và Kanban. Câu chuyện người dùng được sử dụng để mô tả ngắn gọn các yêu cầu chức năng từ góc nhìn của người dùng cuối hoặc khách hàng.
13. Môi trường thử nghiệm là gì?
Môi trường thử nghiệm (Test Environment) là một hệ thống được thiết lập để thực hiện các hoạt động kiểm thử phần mềm. Test Environment gồm cả phần cứng và phần mềm, nhằm tạo ra một không gian làm việc cho các nhóm kiểm thử để tiến hành các trường hợp kiểm thử trên ứng dụng đang phát triển.
14. Kiểm tra Cookie là gì?
Kiểm tra cookie là một loại kiểm tra phần mềm nhằm xác minh các cookie được tạo ra trong trình duyệt web của người dùng nhằm đảm bảo rằng cookie được tạo ra và quản lý đúng cách trong trình duyệt của người dùng.
15. Kiểm thử từ dưới lên là gì?
Kiểm thử từ dưới lên (Bottom-Up Testing) là một phương pháp trong kiểm thử tích hợp, nơi các mô-đun cấp thấp hơn được kiểm tra trước, sau đó tích hợp vào các mô-đun cấp cao hơn. Phương pháp này giúp phát hiện lỗi ngay từ những phần cơ bản nhất của hệ thống trước khi tiến hành kiểm thử các phần phức tạp hơn.
16. Kiểm thử động là gì?
Kiểm thử động (Dynamic Testing) là một phương pháp kiểm tra phần mềm được thực hiện trong quá trình chạy chương trình. Trong loại kiểm thử này, mã nguồn được thực thi và các đầu vào được cung cấp để kiểm tra hành vi của phần mềm, từ đó so sánh kết quả đầu ra với kết quả dự kiến. Mục tiêu chính của kiểm thử động là xác nhận rằng phần mềm hoạt động như mong đợi và đáp ứng các yêu cầu chức năng và phi chức năng.
17. Kiểm tra dựa trên rủi ro là gì?
Kiểm thử dựa trên rủi ro là một kỹ thuật trong kiểm thử phần mềm mà trong đó các điều kiện kiểm thử được xác định dựa trên đánh giá rủi ro của sản phẩm. Mục tiêu chính của kiểm thử rủi ro là giảm thiểu rủi ro chất lượng đến mức chấp nhận được, thông qua việc ưu tiên kiểm tra các tính năng và chức năng có khả năng gây ra lỗi cao nhất.
18. Kiểm tra Fuzz là gì?
Kiểm tra Fuzz, hay còn gọi là Fuzzing, là một kỹ thuật kiểm thử phần mềm được sử dụng để phát hiện lỗi mã hóa và lỗ hổng bảo mật trong các ứng dụng. Phương pháp này hoạt động bằng cách gửi vào hệ thống các dữ liệu không hợp lệ hoặc ngẫu nhiên, được gọi là FUZZ, nhằm kiểm tra phản ứng của hệ thống đối với các đầu vào này.
19. Test Harness là gì?
Test Harness là một tập hợp các thành phần được thiết kế để tạo ra một môi trường kiểm thử tự động, hiệu quả và có khả năng mở rộng. Test Harness giúp các nhà phát triển và kiểm thử thực hiện các bài kiểm tra phần mềm một cách dễ dàng hơn, từ việc phát hiện lỗi đến việc đảm bảo rằng phần mềm hoạt động như mong đợi trong các điều kiện thực tế.
20. Kiểm thử đồng thời là gì?
Kiểm thử song song được thực hiện khi một tổ chức chuyển từ hệ thống cũ sang hệ thống mới, với mục đích xác thực rằng dữ liệu cũ được chuyển đổi thành công và ứng dụng mới hoạt động hiệu quả. Khi thực hiện, các nhân viên kiểm thử sẽ chạy hai phiên bản khác nhau của phần mềm đồng thời với cùng một đầu vào để so sánh kết quả, từ đó phát hiện ra những khác biệt giữa hai hệ thống.
Mức độ trung bình:
21. Age testing là gì?
Age Testing là một loại kiểm thử phần mềm nhằm đánh giá khả năng hoạt động của hệ thống trong tương lai, đặc biệt là sự suy giảm hiệu suất khi phần mềm trở nên cũ hơn. Phương pháp này được thực hiện bởi đội ngũ tester và tập trung vào việc đo đạc mức độ hao hụt về hiệu suất của hệ thống khi thời gian trôi qua.
22. Kiểm tra khi gỡ cài đặt là gì?
Kiểm tra khi gỡ cài đặt là một quy trình quan trọng trong quản lý phần mềm, nhằm đảm bảo rằng việc gỡ bỏ ứng dụng diễn ra suôn sẻ và không để lại các tệp tin hoặc thông tin không cần thiết trong hệ thống.
23. Phân vùng lớp tương đương (ECP) là gì?
Phân vùng lớp tương đương (Equivalence Class Partitioning - ECP) là một kỹ thuật trong kiểm thử phần mềm, đặc biệt trong kiểm thử hộp đen, nhằm tối ưu hóa quá trình thiết kế các ca kiểm thử. Kỹ thuật này liên quan đến việc chia các điều kiện đầu vào của một hệ thống thành các nhóm hoặc phân vùng, trong đó các giá trị trong mỗi phân vùng được coi là tương đương về hành vi hoặc tác động của chúng đối với hệ thống.
24. Quản lý cấu hình phần mềm là gì?
Quản lý cấu hình phần mềm là quá trình đảm bảo rằng các thành phần của hệ thống, bao gồm phần mềm, phần cứng và tài liệu, được duy trì một cách nhất quán và đáng tin cậy qua thời gian. Quản lý cấu hình phần mềm giúp tăng năng suất phát triển phần mềm với số lượng lỗi tối thiểu, đồng thời đảm bảo rằng mọi thay đổi đều được theo dõi và kiểm soát một cách có hệ thống.
25. Kịch bản kiểm thử là gì?
Kịch bản kiểm thử, hay còn gọi là Test Scenario, là một khái niệm quan trọng trong kiểm thử phần mềm. Đây là một mô tả tổng quát về một tình huống cụ thể mà phần mềm cần phải được kiểm tra, nhằm đảm bảo rằng các chức năng và yêu cầu của hệ thống hoạt động đúng như mong đợi.
26. Test Bed là gì?
Test Bed là một môi trường phát triển phần mềm, bao gồm cả phần cứng và phần mềm, nơi mà các mô-đun hoặc ứng dụng có thể được kiểm tra. Mục tiêu chính của Test Bed là tạo ra một không gian an toàn để thử nghiệm mà không làm gián đoạn hoặc gây hại cho hệ thống đang hoạt động.
27. Kiểm tra tính hợp lệ là gì?
Kiểm tra tính hợp lệ là quá trình đánh giá xem một tài liệu hoặc giao dịch có đáp ứng đầy đủ các tiêu chí và quy định pháp luật hay không. Quá trình kiểm tra tính hợp lệ gồm có việc xác minh thông tin, xác thực chữ ký, và đảm bảo rằng tất cả các yêu cầu liên quan đã được thực hiện.
28. Test Closure là gì?
Test Closure, hay còn gọi là "Đóng chu trình kiểm thử," là giai đoạn cuối cùng trong quy trình kiểm thử phần mềm (Software Testing Life Cycle - STLC). Giai đoạn này có vai trò quan trọng trong việc tổng kết và đánh giá toàn bộ quá trình kiểm thử đã thực hiện.
29. Stub là gì?
Stub là một chương trình hoặc thành phần giả lập, thay thế cho một module hoặc chức năng chưa hoàn thiện trong quá trình kiểm thử. Stub cung cấp dữ liệu đầu vào cần thiết để thực hiện các bài kiểm tra mà không cần phải phụ thuộc vào các thành phần khác đang trong quá trình phát triển.
30. Test drivers là gì?
Test drivers, hay còn gọi là drivers, là các đoạn mã giả được sử dụng trong quá trình kiểm thử phần mềm, đặc biệt là trong kiểm thử tích hợp. Chúng có vai trò quan trọng trong việc kiểm tra các module chưa được phát triển hoặc không có sẵn.
31. Giải thích biểu đồ nguyên nhân - kết quả
Biểu đồ nguyên nhân - kết quả, còn được gọi là biểu đồ xương cá (Fishbone Diagram) hoặc sơ đồ Ishikawa, là một công cụ phân tích mạnh mẽ được sử dụng để xác định và tổ chức các nguyên nhân gốc rễ của một vấn đề cụ thể.
Biểu đồ nhân quả thể hiện mối quan hệ giữa một vấn đề (kết quả) và các nguyên nhân có thể dẫn đến vấn đề đó. Biểu đồ giúp phân loại các yếu tố ảnh hưởng thành các nhóm, từ đó dễ dàng nhận diện nguyên nhân cốt lõi.
32. Chiến lược kiểm thử là gì?
Chiến lược kiểm thử (Test Strategy) là một phần quan trọng trong quy trình phát triển phần mềm, đóng vai trò như một kế hoạch tổng thể để xác định cách thức và phương pháp kiểm thử sẽ được thực hiện.
33. Kịch bản kiểm thử là gì?
Kịch bản kiểm thử, hay còn gọi là Test Scenario, là một khái niệm quan trọng trong lĩnh vực kiểm thử phần mềm. Nó đại diện cho một tình huống hoặc trạng thái cụ thể trong hệ thống mà cần được kiểm tra, bao gồm các bước thực hiện và điều kiện để tiến hành kiểm thử. Kịch bản kiểm thử giúp xác định các tình huống cần kiểm tra và hướng dẫn quá trình thực hiện kiểm thử một cách có hệ thống.
34. Code coverage là gì?
Code coverage (độ bao phủ mã) là tỷ lệ phần trăm của mã nguồn được thực thi khi chạy các trường hợp kiểm thử. Code coverage đảm bảo rằng tất cả các dòng mã, nhánh điều kiện và chức năng của ứng dụng đều được kiểm tra ít nhất một lần. Điều này giúp phát hiện lỗi và cải thiện chất lượng mã.
35. Giải thích vai trò của kiểm thử trong phát triển phần mềm
Kiểm thử phần mềm là một phần thiết yếu trong quy trình phát triển phần mềm, đóng vai trò quan trọng trong việc đảm bảo chất lượng và độ tin cậy của sản phẩm.
● Kiểm thử giúp phát hiện các lỗi và khiếm khuyết trong phần mềm, đảm bảo rằng sản phẩm hoạt động đúng theo yêu cầu ban đầu của khách hàng.
● Quá trình này đảm bảo sản phẩm đạt tiêu chuẩn chất lượng cao, từ đó tạo ra trải nghiệm tốt cho người dùng và tăng cường độ tin cậy của sản phẩm.
● Kiểm thử giúp giảm thiểu rủi ro liên quan đến việc phát hành sản phẩm chưa hoàn thiện, từ đó tránh được tổn thất tài chính và danh tiếng cho doanh nghiệp.
● Thông qua kiểm thử hiệu suất, các vấn đề về tốc độ và khả năng chịu tải của phần mềm được xác định và giải quyết.
● Kiểm thử cũng đóng vai trò quan trọng trong việc bảo trì sản phẩm, giúp phát hiện lỗi trong các phiên bản cập nhật hoặc thay đổi yêu cầu.
● Kiểm thử bảo mật giúp xác định và khắc phục các lỗ hổng có thể bị khai thác, từ đó tăng cường an toàn cho phần mềm trước khi ra mắt.
36. Báo cáo lỗi là gì?
Báo cáo lỗi là một tài liệu hoặc thông điệp được tạo ra để thông báo về sự tồn tại của một lỗi trong phần mềm. Báo cáo lỗi được sử dụng trong quy trình kiểm thử phần mềm và phát triển sản phẩm để ghi lại thông tin chi tiết về lỗi, giúp đội ngũ phát triển khắc phục vấn đề một cách hiệu quả.
Mức độ cao cấp:
37. Mục đích của kiểm thử dựa trên rủi ro
● Giảm thiểu rủi ro chất lượng: Mục đích chính của kiểm thử dựa trên rủi ro là xác định và giảm thiểu các rủi ro về chất lượng sản phẩm, nhằm đảm bảo rằng sản phẩm đáp ứng các tiêu chí chất lượng mà người dùng và các bên liên quan mong đợi. Việc đạt được mức độ rủi ro bằng không gần như là không thể, do đó, việc quản lý và giảm thiểu rủi ro đến mức chấp nhận được là rất quan trọng.
● Tập trung vào các khu vực có nguy cơ cao: Kiểm thử dựa trên rủi ro cho phép nhóm kiểm thử tập trung vào các tính năng và chức năng có khả năng xảy ra lỗi cao nhất, từ đó tối ưu hóa quy trình kiểm thử và phân bổ nguồn lực một cách hiệu quả3. Điều này giúp phát hiện sớm các lỗi nghiêm trọng trước khi sản phẩm được phát hành.
● Cải thiện sự hài lòng của người dùng: Bằng cách tập trung vào các đặc điểm và hành vi có thể ảnh hưởng đến sự hài lòng của người dùng, kiểm thử dựa trên rủi ro giúp nâng cao chất lượng tổng thể của sản phẩm, từ đó làm tăng sự hài lòng của khách hàng và các bên liên quan khác.
38. Có những loại số liệu kiểm thử nào?
Trong lĩnh vực tester - kiểm thử, bạn cần quan tâm đến 4 loại số lượng sau:
1. Số liệu định lượng: Đây là những chỉ số có thể đo lường được, cung cấp thông tin cụ thể về các khía cạnh của quá trình kiểm thử. Ví dụ:
● Số lượng lỗi phát hiện: Cho biết tổng số lỗi được tìm thấy trong quá trình kiểm thử.
● Tỷ lệ phần trăm test cases thành công: Tính bằng công thức nhau sau: Số lượng test case thành công/ Tổng số test case)x100
● Thời gian thực hiện trên mỗi test case: Tổng thời gian thực hiện chia cho số lượng test cases đã thực hiện.
2. Số liệu định tính: Những chỉ số này thường không thể đo lường một cách trực tiếp mà dựa vào đánh giá chủ quan. Ví dụ:
● Chất lượng của các test cases: Đánh giá xem các test cases có đủ khả năng kiểm tra các kịch bản quan trọng hay không.
● Mức độ nghiêm trọng của các lỗi phát hiện: Phân loại lỗi theo mức độ ảnh hưởng đến sản phẩm cuối cùng.
3. Dữ liệu kiểm thử (Test Data): Là dữ liệu đầu vào được sử dụng trong quá trình kiểm thử, bao gồm:
● Dữ liệu dùng cho positive testing: Để xác minh rằng phần mềm hoạt động đúng với đầu vào hợp lệ.
● Dữ liệu dùng cho negative testing: Để kiểm tra khả năng xử lý của phần mềm với đầu vào không hợp lệ hoặc bất thường.
4. Chỉ số kiểm thử (Testing Metrics): Các chỉ số này giúp đánh giá hiệu quả và chất lượng của quy trình kiểm thử, bao gồm:
● Chỉ số bao phủ (Test Coverage): Đo lường mức độ mà các yêu cầu hoặc chức năng đã được kiểm thử.
● Chỉ số phân phối bug: Theo dõi và phân tích sự phân bố của các lỗi trong phần mềm.
39. Defect Cascading là gì?
Defect Cascading là một thuật ngữ trong kiểm thử phần mềm, mô tả hiện tượng khi một lỗi (defect) dẫn đến sự phát hiện của nhiều lỗi khác. Hiện tượng này thường xảy ra khi lỗi ban đầu không được khắc phục đúng cách, gây ra chuỗi các vấn đề mới trong quá trình phát triển phần mềm.
40. Phát triển theo hướng kiểm thử là gì?
Phát triển theo hướng kiểm thử, hay còn gọi là Test-Driven Development (TDD), là một phương pháp phát triển phần mềm trong đó việc viết mã được thực hiện dựa trên các bài kiểm tra tự động. Đây là một quy trình lặp đi lặp lại, bắt đầu bằng việc lập kế hoạch và viết các bài kiểm tra cho chức năng mới trước khi viết mã thực tế để thực hiện chức năng đó.
41. Sự khác biệt giữa xác minh và xác thực trong kiểm thử
Tiêu chí | Xác minh (Verification) | Xác thực (Validation) |
Mục đích | Kiểm tra xem phần mềm có đáp ứng thông số kỹ thuật không | Kiểm tra xem phần mềm có đáp ứng nhu cầu người dùng không |
Phương pháp | Đánh giá, kiểm tra tài liệu, không thực thi mã | Thực thi mã, kiểm thử hộp đen, hộp trắng |
Thời điểm | Trước khi sản phẩm hoàn thiện | Sau khi xác minh |
Người thực hiện | Nhóm QA | Nhóm kiểm thử và nhóm QA |
42. Sự khác nhau giữa Bug, Defect, Error, Fault và Failure là gì?
Trong lĩnh vực phát triển phần mềm, các thuật ngữ Bug, Defect, Error, Fault, và Failure thường được sử dụng để mô tả các vấn đề khác nhau liên quan đến chất lượng phần mềm.
1. Bug
Bug là một khiếm khuyết trong một thành phần hoặc hệ thống mà có thể khiến cho thành phần hoặc hệ thống đó không thực hiện đúng chức năng yêu cầu của nó. Ví dụ, một thông báo sai hoặc định nghĩa dữ liệu không đúng có thể được coi là bug. Nếu bug này được phát hiện trong quá trình hoạt động của hệ thống, nó có thể dẫn đến Failure.
2. Defect
Defect thường được hiểu là lỗi trong quá trình phát triển hoặc lỗi logic (coding or logic) làm cho chương trình hoạt động sai so với yêu cầu đã đề ra. Về cơ bản, định nghĩa này rất giống với bug. Một ví dụ về defect là khi một developer lấy dữ liệu từ nguồn không đúng để hiển thị trên màn hình.
3. Error
Error là hành động của con người dẫn đến kết quả sai. Điều này có thể xảy ra khi một developer thực hiện sai cú pháp trong mã nguồn hoặc khi chuẩn bị dữ liệu không chính xác. Error thường là nguyên nhân gây ra các bug hoặc defect trong mã.
4. Fault
Fault được định nghĩa là lỗi xảy ra khi có sự khác biệt giữa kết quả thực tế và kết quả mong đợi của một thành phần, hệ thống hoặc dịch vụ nào đó. Fault thường xuất hiện khi một chức năng không hoạt động như mong muốn do bug hoặc defect gây ra.
5. Failure
Failure là sự thất bại của hệ thống khi nó không đáp ứng được yêu cầu chức năng đã định nghĩa. Failure có thể xảy ra do nhiều nguyên nhân khác nhau, không chỉ do bug mà còn có thể do cấu hình sai hoặc môi trường thử nghiệm không chính xác. Ví dụ, nếu một server được yêu cầu hoạt động tốt với 1000 người dùng nhưng chỉ hoạt động tốt với 900 người dùng, thì đây là một failure.
43. Cần xác minh điều gì trong white-box testing?
Kiểm thử hộp trắng nhằm đảm bảo rằng tất cả các câu lệnh, điều kiện và đường dẫn trong mã nguồn được thực hiện đúng cách, dẫn đến kết quả đầu ra như mong đợi. Xác định điều kiện kiểm tra để đảm bảo rằng tất cả các mã đường đi, điều kiện và dữ liệu được kiểm tra kỹ lưỡng, bao gồm:
● Kiểm tra mã dòng (phạm vi bảo hiểm mã)
● Kiểm tra nhánh (phạm vi bảo hiểm nhánh)
● Kiểm tra điều kiện (phạm vi bảo hiểm điều kiện)
● Kiểm tra dữ liệu (phạm vi bảo hiểm dữ liệu)
44. Sự khác biệt cơ bản giữa kiểm thử chức năng và phi chức năng
Trong khi kiểm thử chức năng xác minh rằng ứng dụng phần mềm thực hiện đúng các chức năng mong muốn, tập trung vào các tính năng và tương tác, thì kiểm thử phi chức năng đánh giá hiệu suất tổng thể, khả năng sử dụng và các thuộc tính chất lượng như tốc độ và bảo mật.
Trong khi thử nghiệm chức năng đảm bảo tính chính xác của tính năng thì thử nghiệm phi chức năng đảm bảo các tiêu chuẩn rộng hơn về độ tin cậy và trải nghiệm của người dùng.
Các tham số | Kiểm tra chức năng | Kiểm tra phi chức năng |
Tập trung | Xác thực các chức năng cụ thể của phần mềm. | Đánh giá hiệu suất, khả năng sử dụng và các thuộc tính chất lượng khác. |
Mục đích | Đảm bảo phần mềm thực hiện được các chức năng mong muốn. | Đảm bảo phần mềm đáp ứng các tiêu chuẩn về hiệu suất, bảo mật và khả năng sử dụng. |
Phạm vi | Kiểm tra từng chức năng hoặc tính năng riêng lẻ một cách riêng biệt. | Kiểm tra hành vi tổng thể của hệ thống và các thuộc tính chất lượng. |
Ví dụ | Xác thực đầu vào, logic kinh doanh và tương tác của người dùng. | Kiểm tra hiệu suất, tải, bảo mật và khả năng sử dụng. |
Loại thử nghiệm | Nói chung bao gồm thử nghiệm đơn vị, tích hợp và hệ thống. | Bao gồm thử nghiệm ứng suất, khả năng mở rộng và độ tin cậy. |
Số liệu | Đo độ chính xác của đầu ra và chức năng của tính năng. | Đo tốc độ, độ ổn định và trải nghiệm của người dùng. |
Thực hiện | Thường được tự động hóa và thực hiện trong giai đoạn phát triển. | Thường liên quan đến các công cụ chuyên dụng và có thể yêu cầu môi trường cụ thể. |
Kết quả | Xác nhận rằng phần mềm đáp ứng các yêu cầu chức năng đã chỉ định. | Đảm bảo phần mềm có thể xử lý hiệu quả các điều kiện dự kiến và bất ngờ. |
45. Sự khác biệt giữa Kiểm thử theo dữ liệu và Kiểm thử lại là gì?
Kiểm tra lại | Kiểm tra hồi quy |
Là các bài kiểm tra được thiết kế rõ ràng để kiểm tra xem các lỗi đã biết đã được sửa hay chưa. | Là kiểm thử có mục tiêu để tìm ra những lỗi đã biết. |
Không tập trung vào chức năng của phiên bản trước. Thay vào đó, nó nhằm mục đích kiểm tra xem chức năng có được khôi phục sau khi sửa lỗi hay không. | Hướng đến sự thay đổi và chủ yếu nhằm kiểm tra xem chức năng của phiên bản trước có được duy trì sau khi ứng dụng có thay đổi/cập nhật hay không. |
Vì việc kiểm tra lại nhằm mục đích tìm ra lỗi cụ thể nên không thể tự động hóa được. | Tự động hóa là phổ biến cho thử nghiệm hồi quy. Kiểm tra thủ công mỗi khi có thay đổi hoặc cập nhật cho ứng dụng sẽ rất phi lý. Tự động hóa bổ sung nhiều hơn cho việc thực hiện các thử nghiệm chung cho các lỗi không mong muốn. |
Kiểm tra lại không nhất thiết phải là một phần của quá trình kiểm tra trừ khi lỗi được tìm thấy và sửa; Do đó, kiểm tra lại không phải là một phần được đảm bảo của quá trình kiểm tra. | Kiểm thử hồi quy là chuẩn mực và luôn là một phần của quy trình kiểm thử. Mỗi khi mã của ứng dụng bị thay đổi, thực hiện kiểm thử hồi quy là một hoạt động tốt. |
Việc kiểm tra lại được ưu tiên hơn vì việc kiểm tra này tập trung vào việc sửa các lỗi đã biết . | Kiểm thử hồi quy có mức độ ưu tiên thấp hơn Kiểm thử lại vì nó chỉ thực hiện quét ứng dụng để kiểm tra các lỗi tiềm ẩn không lường trước được. |
Vì chỉ có một số khiếm khuyết nhất định được phát hiện khi kiểm tra lại nên sẽ tiết kiệm thời gian hơn nhiều. | Kiểm thử hồi quy thường khám phá phần lớn ứng dụng để phát hiện lỗi và có thể tốn nhiều thời gian hơn so với kiểm thử lại. |
46. Tại sao các lập trình viên không nên tự kiểm thử phần mềm mà họ xây dựng?
Các lập trình viên không nên tự kiểm thử phần mềm mà họ xây dựng do:
● Mất tính khách quan: Lập trình viên thường có cái nhìn chủ quan về mã nguồn của mình, dẫn đến việc bỏ sót lỗi. Họ có thể tin tưởng vào sản phẩm và không nhận ra những vấn đề tiềm ẩn. Đội ngũ kiểm thử độc lập có khả năng nhìn nhận từ nhiều góc độ khác nhau, giúp phát hiện lỗi mà lập trình viên có thể không thấy.
● Khó phát hiện do lỗi: Kiểm thử đơn vị chỉ kiểm tra từng phần nhỏ của mã và không đủ để phát hiện lỗi trong sự tương tác giữa các thành phần. Những người kiểm thử chuyên nghiệp sử dụng các kỹ thuật và công cụ khác nhau để phát hiện lỗi tiềm ẩn.
● Chuyên môn hóa kiểm thử: Kiểm thử là một lĩnh vực chuyên môn riêng, đòi hỏi kiến thức và kỹ năng đặc thù. Những người làm kiểm thử thường có tư duy "phá hoại", tìm kiếm lỗi một cách quyết liệt hơn.
47. Phẩm chất quan trọng của một Tester hàng đầu
Nếu bạn muốn trở thành một tester hàng đầu, ngoài kiến thức chuyên môn vững vàng, bạn còn cần sở hữu những phẩm chất sau:
● Chú ý đến chi tiết: Người kiểm thử giỏi có khả năng nhận diện và ghi lại những vấn đề nhỏ nhất, từ lỗi đến sự không nhất quán.
● Tò mò và sáng tạo: Họ luôn tìm kiếm cách thức mới để kiểm thử phần mềm và phát hiện vấn đề tiềm ẩn, không ngại thử nghiệm các phương pháp sáng tạo.
● Kỹ năng phân tích và giải quyết vấn đề: Có khả năng phân tích hệ thống phức tạp, xác định vấn đề và xây dựng chiến lược kiểm thử hiệu quả.
● Kỹ năng giao tiếp và cộng tác: Làm việc hiệu quả với các thành viên trong nhóm, từ nhà phát triển đến quản lý, truyền đạt vấn đề một cách rõ ràng.
● Kiên nhẫn và bền bỉ: Kiểm thử thường tốn thời gian và có thể gây nản lòng; cần sự kiên nhẫn để theo đuổi đến cùng.
● Niềm đam mê chất lượng: Cam kết đảm bảo sản phẩm đạt tiêu chuẩn cao, tự hào về công việc để đáp ứng kỳ vọng của khách hàng.
48. Lợi ích của kiểm thử chấp nhận
Kiểm thử chấp nhận (Acceptance Testing) là một phần quan trọng trong quy trình phát triển phần mềm, nhằm đảm bảo rằng sản phẩm cuối cùng đáp ứng các yêu cầu và mong đợi của người dùng. Dưới đây là một số lợi ích chính của kiểm thử chấp nhận:
● Đảm bảo chất lượng phần mềm đúng theo các yêu cầu chức năng và phi chức năng đã được xác định. Điều này không chỉ cải thiện chất lượng sản phẩm mà còn giảm thiểu số lượng lỗi và vấn đề phát sinh trong quá trình sử dụng.
● Nâng cao sự hài lòng của người dùng thông qua việc kiểm tra sản phẩm với sự tham gia của người dùng cuối. Sự tham gia này không chỉ tạo ra niềm tin mà còn giúp người dùng cảm thấy hài lòng hơn với sản phẩm cuối cùng.
● Phát hiện lỗi và vấn đề sớm trong quá trình kiểm thử chấp nhận có thể giúp tiết kiệm đáng kể thời gian và chi phí liên quan đến việc sửa chữa sau khi sản phẩm đã được triển khai.
● Kiểm thử chấp nhận đánh giá xem người dùng có thể sử dụng phần mềm một cách hiệu quả và thuận tiện hay không.
● Xác định các yêu cầu chưa được đáp ứng hoặc những tính năng cần được điều chỉnh trước khi sản phẩm ra mắt chính thức nhằm đảm bảo rằng sản phẩm cuối cùng thực sự phù hợp với nhu cầu của khách hàng.
● Người dùng sẽ có cơ hội phản hồi trực tiếp về sản phẩm, từ đó giúp nhóm phát triển hiểu rõ hơn về những gì cần cải thiện hoặc thay đổi để đáp ứng tốt hơn nhu cầu của thị trường.
49. Giải thích vòng đời của Bug
Vòng đời của bug (bug life cycle) trong kiểm thử phần mềm là quy trình mà một lỗi (bug) trải qua từ khi được phát hiện cho đến khi được giải quyết và đóng lại. Vòng đời của Bug có các trạng thái như sau:
● NEW (Mới): Khi tester phát hiện một bug trong quá trình kiểm thử, bug sẽ được đánh dấu là "New". Đây là trạng thái ban đầu khi bug vừa được phát hiện.
● ASSIGNED (Đã gán): Bug sẽ được chuyển giao cho một lập trình viên (developer) để sửa chữa. Trạng thái này cho biết rằng bug đã được phân công cho người chịu trách nhiệm khắc phục.
● OPEN (Đang mở): Khi lập trình viên bắt đầu làm việc để sửa lỗi, trạng thái của bug sẽ chuyển sang "Open". Điều này cho thấy rằng bug đang trong quá trình xử lý.
● FIXED (Đã sửa xong): Sau khi lập trình viên hoàn thành việc sửa lỗi, bug sẽ được đánh dấu là "Fixed". Lúc này, mã nguồn đã được cập nhật để khắc phục vấn đề.
● RE-TESTING (Kiểm tra lại): Tester sẽ thực hiện kiểm tra lại để xác nhận rằng lỗi đã được sửa. Nếu các test case liên quan đều passed, bug sẽ chuyển sang trạng thái tiếp theo.
● CLOSED (Đã đóng): Nếu bug đã được xác nhận là không còn tồn tại và hoạt động đúng như mong đợi, tester sẽ đánh dấu nó là "Closed". Điều này có nghĩa là bug đã được giải quyết hoàn toàn.
● REOPENED (Mở lại): Trong trường hợp tester phát hiện rằng lỗi vẫn còn tồn tại sau khi đã được sửa hoặc lỗi đã xuất hiện trở lại sau khi đã đóng, bug sẽ được mở lại và gán cho lập trình viên để xử lý tiếp.
● REJECTED (Đã từ chối): Nếu bug không hợp lệ hoặc không phải là một lỗi thực sự (ví dụ: do hiểu nhầm chức năng), quản lý dự án có thể đánh dấu nó là "Rejected".
● DUPLICATE (Trùng lặp): Nếu một bug đã được báo cáo trước đó và có cùng bản chất, nó sẽ được đánh dấu là "Duplicate".
● DEFERRED (Hoãn lại): Nếu bug không nằm trong phạm vi của phiên bản hiện tại nhưng cần phải sửa ở phiên bản tiếp theo, nó sẽ được đánh dấu là "Deferred".
50. Vai trò của kiểm thử khả năng sử dụng là gì?
Kiểm thử khả năng sử dụng (Usability Testing) đóng vai trò quan trọng trong việc cải thiện trải nghiệm người dùng và đảm bảo rằng sản phẩm hoặc dịch vụ đáp ứng tốt nhu cầu của người sử dụng. Dưới đây là một số vai trò chính của kiểm thử khả năng sử dụng:
Cải thiện trải nghiệm người dùng
Kiểm thử khả năng sử dụng giúp xác định các vấn đề trong giao diện và tương tác của sản phẩm, từ đó cải thiện sự dễ hiểu và khả năng sử dụng. Một trải nghiệm người dùng tốt không chỉ tạo ra sự hài lòng mà còn khuyến khích người dùng quay lại và sử dụng sản phẩm nhiều hơn.
Tăng tính hiệu quả và giảm chi phí
Bằng cách phát hiện sớm các lỗi và vấn đề trong quá trình phát triển, kiểm thử khả năng sử dụng có thể giảm thiểu chi phí sửa chữa sau khi sản phẩm được phát hành. Điều này giúp tiết kiệm thời gian và nguồn lực cho doanh nghiệp.
Đánh giá thiết kế
Quá trình kiểm thử cho phép các nhà phát triển và thiết kế nhận diện điểm mạnh và điểm yếu của sản phẩm. Thông qua việc thu thập phản hồi từ người dùng, nhóm phát triển có thể điều chỉnh thiết kế để tối ưu hóa tính năng và giao diện.
Tăng cường sự chấp nhận của người dùng
Sản phẩm được kiểm thử kỹ lưỡng sẽ dễ dàng hơn để người dùng chấp nhận, từ đó nâng cao uy tín của thương hiệu và tăng doanh thu do sự hài lòng của khách hàng.
Cung cấp thông tin định lượng và định tính
Kiểm thử khả năng sử dụng không chỉ thu thập dữ liệu định tính về cảm nhận của người dùng mà còn cung cấp thông tin định lượng như thời gian hoàn thành nhiệm vụ, tỷ lệ thành công, v.v. Điều này giúp các nhà phát triển có cái nhìn rõ ràng về hiệu suất của sản phẩm.
Việc nắm vững các câu hỏi phỏng vấn Tester không chỉ giúp ứng viên chuẩn bị tốt hơn cho cuộc phỏng vấn mà còn nâng cao cơ hội thành công trong việc tìm kiếm việc làm trong lĩnh vực công nghệ thông tin. Hãy xem đây là cơ hội để chứng minh bản thân và thể hiện đam mê với nghề Tester, đồng thời không quên chuẩn bị những câu hỏi để đặt ra cho nhà tuyển dụng, từ đó tạo ấn tượng tốt và thể hiện sự chủ động của bạn trong quá trình ứng tuyển.