Đáp án đúng: A. Tiêu chí đầu ra (exit criteria) được đặt ra ngay trong kế hoạch kiểm thử để xác định khi nào một MỨC kiểm thử được coi là hoàn tất, thường gồm mức độ bao phủ đạt được, số lỗi còn mở, rủi ro tồn đọng và chi phí. Phương án B chỉ nói tới việc một phép kiểm thử đơn lẻ chạy xong, đó là chuyện thực thi chứ không phải tiêu chí đầu ra của cả mức kiểm thử; phương án C nói về vòng đời sản phẩm (khi nào ngừng sử dụng hệ thống); phương án D là việc so sánh kết quả thực tế với kết quả mong đợi, tức tiêu chí đạt/không đạt của một ca kiểm thử.

Đáp án đúng: C. Không thể kiểm thử vét cạn, nên câu hỏi "kiểm thử bao nhiêu là đủ" không có đáp số cố định: mức độ đủ phụ thuộc vào rủi ro của ngành nghề, các ràng buộc hợp đồng và những yêu cầu đặc thù của sản phẩm. Phần mềm y tế hay hàng không đòi hỏi mức kiểm thử khác hẳn một ứng dụng giải trí. Phương án A quá bi quan vì câu hỏi vẫn trả lời được khi đặt trong bối cảnh rủi ro cụ thể; phương án B ngược lại, quá lạc quan; phương án D chỉ nêu một yếu tố nhỏ, mức trưởng thành của đội phát triển không phải căn cứ chính để xác định khối lượng kiểm thử.

Đáp án đúng: C. Bảo mật, hiệu năng, độ tin cậy và tính khả dụng đều là các thuộc tính CHẤT LƯỢNG, mô tả hệ thống hoạt động TỐT ĐẾN MỨC NÀO chứ không phải hệ thống làm được gì. Việc đánh giá chúng thuộc phạm vi kiểm thử phi chức năng. Kiểm thử chức năng (B) chỉ kiểm tra hệ thống có thực hiện đúng các chức năng đặc tả hay không; tích hợp hệ thống (A) là một mức kiểm thử, quan tâm tới giao tiếp giữa các hệ thống; kiểm thử yêu cầu (D) không phải một loại kiểm thử tiêu chuẩn theo cách phân loại chức năng - phi chức năng - cấu trúc - liên quan đến thay đổi.

Đáp án đúng: D. Kiểm thử hệ thống (system testing) tiến hành trên toàn bộ hệ thống đã tích hợp, kiểm tra mọi yêu cầu chức năng, thông tin, cấu trúc và chất lượng, và dùng một bộ ca kiểm thử đã định trước để chứng minh với ban quản lý rằng hệ thống đáp ứng đặc tả. Kiểm thử tích hợp (B) chỉ tập trung vào giao tiếp giữa các thành phần; kiểm thử chấp nhận người dùng (C) do người dùng thực hiện theo tiêu chí chấp nhận của họ, sau kiểm thử hệ thống; còn kiểm thử thẩm định (A) là khái niệm rộng, trả lời câu hỏi có xây dựng đúng sản phẩm hay không chứ không phải một mức kiểm thử cụ thể như mô tả trong đề.

Đáp án đúng: C. Chi phí sửa một lỗi tăng theo cấp số nhân khi lỗi được phát hiện muộn vì lỗi đó đã bị "xây" vào ngày càng nhiều sản phẩm trung gian: tài liệu thiết kế, mã nguồn, ca kiểm thử, dữ liệu kiểm thử và cả những phần đã dựa trên nó. Sửa lỗi lúc này kéo theo sửa toàn bộ chuỗi sản phẩm ấy rồi kiểm thử hồi quy lại. Phương án A và B nêu những nguyên nhân ngoại vi (tài liệu kém, lương tăng) chỉ có tác động thứ yếu; phương án D bị loại vì C đã nêu đúng nguyên nhân cốt lõi.

Đáp án đúng: D. Phát biểu SAI là "kiểm thử thành phần không liên quan tới kiểm thử hồi quy": khi một thành phần được sửa, chính ở mức thành phần người ta phải chạy lại các ca kiểm thử cũ để bảo đảm thay đổi không phá vỡ hành vi đã đúng - đó là kiểm thử hồi quy ở mức đơn vị, thường được tự động hoá. Các phát biểu còn lại đều đúng: kiểm thử thành phần thường do chính đội phát triển thực hiện (A), còn được gọi là kiểm thử đơn vị, kiểm thử mô-đun hay kiểm thử cô lập (B), và cũng cần được lập kế hoạch với tiêu chí hoàn thành rõ ràng (C).

Đáp án đúng: A. Theo thuật ngữ chuẩn, failure (hỏng hóc) là biểu hiện hành vi sai của chương trình khi thực thi, do một fault (lỗi trong mã) gây ra, và fault lại bắt nguồn từ error (sai sót của con người). Vì vậy failure gắn với hành vi chạy sai chứ không gắn với thời điểm tìm thấy lỗi. Các phương án B, C, D đều định nghĩa theo mốc thời gian phát hiện - trước khi phát hành, sau khi phát hành hay trong pha thiết kế - nên nhầm giữa khái niệm failure với cách phân loại lỗi theo giai đoạn.

Đáp án đúng: B. Tích hợp từ dưới lên (bottom-up integration) bắt đầu từ các mô-đun ở mức thấp nhất, tức các mô-đun lá trong cây gọi hàm, rồi ghép dần lên các mô-đun cấp cao hơn; nó cần các driver để giả lập mô-đun gọi. Ngược lại, tích hợp từ trên xuống (A) bắt đầu từ mô-đun điều khiển cấp cao và dùng stub thay cho các mô-đun chưa có. "Module integration" (D) không phải tên một chiến lược tích hợp chuẩn, còn C bị loại vì B đã đúng.

Đáp án đúng: D. Rủi ro được chia thành rủi ro dự án (project risk) - liên quan tới khả năng quản lý và triển khai dự án - và rủi ro sản phẩm (product risk) - liên quan tới bản thân phần mềm được giao. Vấn đề nhà cung cấp (A), yếu tố tổ chức (B) và vấn đề kỹ thuật (C) đều là rủi ro dự án. Riêng "phần mềm giao ra dễ phát sinh lỗi" (D) mô tả chất lượng của chính sản phẩm nên là rủi ro SẢN PHẨM, không phải rủi ro dự án - đó là phương án cần chọn.

Đáp án đúng: A. Rủi ro dự án là những rủi ro đe doạ khả năng dự án đạt mục tiêu, gồm yếu tố tổ chức (thiếu nhân lực, thiếu kỹ năng, vấn đề giao tiếp, chính trị nội bộ), yếu tố nhà cung cấp và yếu tố kỹ thuật. Vì vậy "Organizational Factors" là câu trả lời. Các phương án B, C, D - đặc tính phần mềm kém, phần mềm giao ra dễ lỗi, phần mềm không thực hiện đúng chức năng - đều mô tả chất lượng của sản phẩm được giao nên thuộc nhóm rủi ro sản phẩm.

Đáp án đúng: B. Các vai trò trong một cuộc rà soát chính thức gồm: Manager (người quyết định tổ chức rà soát, cấp nguồn lực), Moderator (người điều phối, dẫn dắt cuộc họp), Author (tác giả tài liệu), Reviewers (người rà soát) và Scribe/Recorder (người ghi chép). Như vậy i, ii, iii đều đúng, còn "Assistant Manager" (iv) không phải một vai trò được định nghĩa trong quy trình rà soát chính thức, nên iv sai - đúng như phương án B mô tả.

Đáp án đúng: C. Sáu pha của quy trình rà soát chính thức theo đúng thứ tự là: Planning (lập kế hoạch, chọn người, xác định tiêu chí vào ra) → Kick Off (họp mở đầu, phân phát tài liệu, giải thích mục tiêu) → Individual Preparations (mỗi người tự nghiên cứu và ghi nhận vấn đề) → Review Meeting (họp rà soát, thảo luận và ghi nhận lỗi) → Rework (tác giả sửa) → Follow Up (kiểm tra việc sửa và đóng rà soát). Chuỗi này ứng với i, v, iv, ii, iii, vi, tức phương án C. Các phương án còn lại đảo lộn thứ tự, đặc biệt đặt Kick Off và Individual Preparations sai vị trí.