Bắt đầu thiết kế thử nghiệm trong giai đoạn định nghĩa yêu cầu là rất quan trọng để đạt được các mục tiêu thử nghiệm sau. Khi thiết kế thử nghiệm được bắt đầu từ giai đoạn định nghĩa yêu cầu, nó cho phép các nhà phát triển hiểu rõ hơn về yêu cầu của hệ thống và xác định được các trường hợp thử nghiệm quan trọng. Điều này giúp tăng cường sự tự tin vào hệ thống và đảm bảo rằng hệ thống hoạt động đúng như mong đợi. Ngoài ra, thiết kế thử nghiệm trong giai đoạn định nghĩa yêu cầu cũng giúp giảm thiểu các lỗi trong hệ thống và đảm bảo rằng hệ thống được hoàn thiện một cách đầy đủ.

Khi một phần mềm đã được cấp giấy phép, bạn sẽ thực hiện các kiểm tra sau. Trước hết, bạn cần xác định giấy phép đã cấp cho phần mềm có phải là giấy phép mở (Open-source) hay không. Nếu là giấy phép mở, bạn sẽ kiểm tra xem phần mềm có tuân thủ các điều khoản của giấy phép hay không. Điều này bao gồm việc kiểm tra xem phần mềm có được sử dụng miễn phí hay không, có được chia sẻ mã nguồn hay không, và có được sử dụng cho mục đích thương mại hay không. Ngoài ra, bạn cũng cần kiểm tra xem phần mềm có chứa bất kỳ mã độc (malware) nào hay không. Nếu phần mềm không phải là giấy phép mở, bạn sẽ kiểm tra xem phần mềm có được sử dụng hợp pháp hay không, và có được sử dụng cho mục đích thương mại hay không. Cuối cùng, bạn sẽ kiểm tra xem phần mềm có tuân thủ các quy định về bảo mật và bảo vệ thông tin cá nhân hay không.

Các lỗi TF (Faults) được người dùng phát hiện thường là do các nguyên nhân sau: Trước hết, nguyên nhân chính là do phần mềm và quá trình kiểm thử không tốt. Điều này có thể dẫn đến việc lỗi không được phát hiện trong quá trình kiểm thử, từ đó gây ra lỗi khi phần mềm được triển khai. Ngoài ra, một số lỗi TF còn do sự kết hợp của nhiều yếu tố, bao gồm cả yếu tố may mắn. Tuy nhiên, trong thực tế, yếu tố may mắn không phải là nguyên nhân chính gây ra lỗi TF. Vì vậy, để giảm thiểu số lượng lỗi TF, chúng ta cần phải tập trung vào việc phát triển và kiểm thử phần mềm một cách tốt hơn.

Câu hỏi này yêu cầu bạn chọn định nghĩa tốt nhất cho khái niệm Testing. Có bốn lựa chọn khác nhau. Lựa chọn đầu tiên cho rằng mục tiêu của testing là chứng minh chương trình hoạt động. Lựa chọn thứ hai cho rằng mục tiêu của testing là chứng minh chương trình không có lỗi. Lựa chọn thứ ba cho rằng mục tiêu của testing là chứng minh chương trình thực hiện đúng chức năng. Lựa chọn thứ tư cho rằng testing là việc thực thi phần mềm để tìm kiếm lỗi. Trong bốn lựa chọn này, lựa chọn thứ tư là định nghĩa tốt nhất cho khái niệm Testing vì nó tập trung vào việc tìm kiếm lỗi trong phần mềm.

Mục tiêu của một tester phần mềm là tìm kiếm lỗi, tìm kiếm chúng càng sớm càng tốt và đảm bảo chúng được sửa chữa. Điều này giúp tiết kiệm thời gian và chi phí cho quá trình phát triển phần mềm. Khi lỗi được tìm thấy và sửa chữa sớm, nó sẽ giúp cải thiện chất lượng phần mềm và giảm thiểu rủi ro khi đưa sản phẩm ra thị trường. Vì vậy, mục tiêu của một tester phần mềm là tìm kiếm lỗi và đảm bảo chúng được sửa chữa một cách hiệu quả.

Một trường hợp lỗi xảy ra khi nhiều người dùng truy cập vào hệ thống. Điều này có nghĩa là một yêu cầu không chức năng quan trọng đã không được chỉ định và kiểm tra. Trong khi các yêu cầu chức năng thường tập trung vào các tính năng và chức năng của hệ thống, các yêu cầu không chức năng lại tập trung vào các tính chất của hệ thống như hiệu suất, độ tin cậy, khả năng mở rộng, bảo mật, v.v. Trong trường hợp này, trường hợp lỗi xảy ra khi nhiều người dùng truy cập vào hệ thống là một yêu cầu không chức năng quan trọng mà không được chỉ định và kiểm tra. Điều này có thể dẫn đến hệ thống không thể xử lý được số lượng người dùng lớn, gây ra sự cố và ảnh hưởng đến hiệu suất của hệ thống.

Sự cố hệ thống thường xảy ra trong giai đoạn nào? Trong quá trình phát triển phần mềm, giai đoạn yêu cầu (Requirements Phase) là giai đoạn quan trọng và dễ xảy ra sự cố. Đây là giai đoạn nơi các yêu cầu và mục tiêu của dự án được xác định. Nếu không thực hiện đúng, giai đoạn này có thể dẫn đến sự cố hệ thống sau này. Các yêu cầu không rõ ràng, không đầy đủ hoặc không chính xác có thể gây ra sự cố trong giai đoạn thiết kế và phát triển. Do đó, giai đoạn yêu cầu là giai đoạn dễ xảy ra sự cố hệ thống.

Khái niệm re-testing và regression testing thường được sử dụng trong lĩnh vực kiểm thử phần mềm. Re-testing là quá trình chạy lại các thử nghiệm đã thực hiện trước đó để đảm bảo rằng các vấn đề đã được sửa chữa. Trong khi đó, regression testing là quá trình kiểm tra lại các phần mềm đã được sửa chữa để đảm bảo rằng các thay đổi không gây ra các tác động phụ không mong muốn. Cụ thể, re-testing là chạy lại các thử nghiệm một lần nữa, trong khi regression testing tìm kiếm các tác động phụ không mong muốn. Điều này cho thấy rằng re-testing và regression testing có mục đích và phạm vi khác nhau trong quá trình kiểm thử phần mềm.

Mục tiêu thoát (Exit criteria) là một phần quan trọng trong quá trình kiểm thử phần mềm. Nó xác định điều kiện để kết thúc kiểm thử và đảm bảo rằng phần mềm đã đạt được yêu cầu. Một số nhiệm vụ chính của mục tiêu thoát bao gồm: kiểm tra nhật ký kiểm thử so với mục tiêu thoát đã được chỉ định trong kế hoạch kiểm thử, ghi lại kết quả thực hiện kiểm thử, đánh giá xem có cần thêm kiểm thử hay không. Tuy nhiên, viết báo cáo tóm tắt kiểm thử cho các bên liên quan không phải là một nhiệm vụ chính của mục tiêu thoát. Mục tiêu thoát được thiết kế để xác định khi nào kiểm thử nên kết thúc, chứ không phải để tạo ra báo cáo cho các bên liên quan.

Mỗi giai đoạn trong vòng đời phát triển phần mềm cần được khớp với vòng đời kiểm thử như sau: - Giai đoạn thu thập yêu cầu kinh doanh (Business requirements) nên được kiểm thử bằng các bài kiểm thử chấp nhận (Acceptance tests). - Giai đoạn thiết kế tổng quan (High-level design) nên được kiểm thử bằng các bài kiểm thử tích hợp (Integration tests). - Giai đoạn thiết kế chi tiết (Low-level design) nên được kiểm thử bằng các bài kiểm thử đơn vị (Unit tests). - Giai đoạn viết mã (Code) nên được kiểm thử bằng các bài kiểm thử đơn vị (Unit tests). Vậy đáp án đúng là: Integration tests i-c, ii-a, iii-d, iv-b.

Đáp án đúng: A. Khi thời gian và nguồn lực có hạn, kiểm thử phải được ưu tiên theo rủi ro. Hai định hướng đúng là kiểm thử những vùng trọng yếu nhất với quy trình nghiệp vụ (1) và những vùng có khả năng chứa nhiều lỗi nhất (2) - nguyên lý "defect clustering" cho biết lỗi thường dồn vào một số ít mô-đun. Định hướng (3), kiểm thử những chức năng dễ nhất, là sai vì nó tiêu tốn công sức vào phần ít rủi ro và bỏ sót phần nguy hiểm. Vì vậy 1 và 2 đúng, 3 sai, tức phương án A; các phương án còn lại hoặc công nhận (3) hoặc phủ nhận (1), (2) nên đều không đạt.

Đáp án đúng: C. Kiểm thử chỉ nên dừng khi các tiêu chí hoàn thành (test completion criteria / exit criteria) đã được thoả mãn, bởi đó là thước đo khách quan đã thống nhất từ khi lập kế hoạch. Hết thời gian (A) hay chạy xong toàn bộ ca kiểm thử đã lập (B) chỉ là điều kiện hành chính, không nói lên chất lượng sản phẩm. Không tìm thấy lỗi nào (D) càng nguy hiểm vì có thể do bộ ca kiểm thử yếu chứ không phải phần mềm tốt - kiểm thử không chứng minh được sự vắng mặt của lỗi.