Câu hỏi: SWT301 - Phần 5: Quản lý kiểm thử

Đáp án đúng: "Error-prone software delivered". ISTQB Foundation phân biệt rủi ro dự án (project risk), ảnh hưởng tới khả năng dự án đạt mục tiêu, với rủi ro sản phẩm (product risk), liên quan trực tiếp tới chất lượng của phần mềm. Phần mềm giao đi có nhiều khả năng chứa lỗi là ví dụ điển hình của rủi ro sản phẩm, nên nó không phải rủi ro dự án. "Supplier issues" là rủi ro dự án: bên thứ ba giao trễ, không giao được hoặc hợp đồng có vấn đề. "Organization factors" là rủi ro dự án: thiếu kỹ năng, thiếu nhân sự, vấn đề chính trị nội bộ, giao tiếp kém giữa các nhóm. "Technical issues" là rủi ro dự án: yêu cầu không rõ, khó định nghĩa đúng, môi trường kiểm thử chưa sẵn sàng, chất lượng thiết kế hay mã chưa đạt khiến kế hoạch bị ảnh hưởng.

Đáp án đúng: "Organizational Factors". ISTQB chia rủi ro thành rủi ro dự án (project risk), liên quan tới khả năng dự án đạt mục tiêu như yếu tố tổ chức (thiếu người, thiếu kỹ năng, chính trị nội bộ), vấn đề kỹ thuật, vấn đề nhà cung cấp; và rủi ro sản phẩm (product risk), liên quan tới chất lượng của chính phần mềm. Yếu tố tổ chức nằm đúng trong nhóm rủi ro dự án. "Poor Software characteristics" là rủi ro sản phẩm: phần mềm kém về độ tin cậy, khả dụng, hiệu năng. "Error Prone software delivered." là rủi ro sản phẩm vì nói về phần mềm dễ hỏng được bàn giao. "Software that does not perform its intended functions" cũng là rủi ro sản phẩm, đúng như ví dụ trong ISTQB về phần mềm không làm đúng chức năng dự định.

Đáp án đúng: "Needs configuration management just like requirements, design and code". Testware là mọi sản phẩm tạo ra trong quá trình kiểm thử như kế hoạch, ca kiểm thử, dữ liệu kiểm thử, kịch bản, kết quả mong đợi; theo ISTQB nó phải được quản lý cấu hình (configuration management) như yêu cầu, thiết kế và mã, tức có định danh, phiên bản, kiểm soát thay đổi và truy vết được tới phiên bản phần mềm mà nó kiểm. "Should be newly constructed for each new version of the software" sai vì testware được tái sử dụng và bảo trì qua các phiên bản, nhất là cho kiểm thử hồi quy. "Is needed only until the software is released into production" sai vì sau phát hành vẫn cần testware cho kiểm thử bảo trì khi sửa lỗi hay nâng cấp. "Does not need to be documented and commented, as it does not form part" sai vì testware không có tài liệu thì người khác không hiểu, không bảo trì và không tái dùng được.

Đáp án đúng: "Interim Test report". Ma trận chức năng và kiểm thử (Function/Test Matrix) ánh xạ từng chức năng của hệ thống với các ca kiểm thử phủ nó và trạng thái chạy của chúng. Trong khung kiến thức CSTE, nó được trình bày trong nhóm báo cáo kiểm thử tạm thời (interim test reports), là những báo cáo phát hành trong lúc kiểm thử còn đang diễn ra để cho thấy chức năng nào đã được kiểm thử, chức năng nào còn lỗi. Cần nói thẳng là một số bộ ôn tập ghi "Project status report"; báo cáo trạng thái dự án đúng là có thể dùng số liệu từ ma trận, nhưng nó là báo cáo cấp dự án về tiến độ, chi phí, rủi ro nói chung, còn bản thân ma trận được xếp vào báo cáo kiểm thử tạm thời. "Final test report" là báo cáo tổng kết khi kiểm thử kết thúc, trong khi ma trận được cập nhật liên tục trong quá trình. "Management report" là tên gọi chung cho báo cáo gửi quản lý, không phải loại tài liệu mà ma trận này được phân vào.

Đáp án đúng: "Auditing conformance to ISO9001". Câu hỏi tìm mục không thuộc quản lý cấu hình. Quản lý cấu hình (configuration management) gồm bốn hoạt động chuẩn: định danh cấu hình, kiểm soát thay đổi, kế toán trạng thái (status accounting) và kiểm tra cấu hình (configuration audit) xem các hạng mục có khớp với mô tả đã duyệt. Đánh giá sự tuân thủ ISO 9001 là đánh giá hệ thống quản lý chất lượng của cả tổ chức, thuộc đảm bảo chất lượng, không phải hoạt động của quản lý cấu hình. Các mục kia đều thuộc quản lý cấu hình nên không được chọn. "Status accounting of configuration items" là ghi nhận và báo cáo trạng thái các hạng mục cấu hình. "Identification of test versions" thuộc định danh cấu hình. "Record of changes to documentation over time" là lưu vết thay đổi, phục vụ kiểm soát thay đổi. "Controlled library access" là kiểm soát quyền truy cập thư viện lưu các phiên bản.

Đáp án đúng: "i, ii, iii is true and iv is false". Theo ISTQB Foundation, trưởng nhóm kiểm thử (test leader) phụ trách các việc mang tính quản lý: lập và điều chỉnh kế hoạch, làm việc với nhà cung cấp và chọn công cụ hỗ trợ kiểm thử (mục i), quyết định cái gì nên tự động hoá, đến mức nào và bằng cách nào (mục iii), theo dõi tiến độ và viết báo cáo tổng kết kiểm thử từ thông tin thu được (mục ii). Còn tạo đặc tả kiểm thử (test specifications) là việc của người kiểm thử (tester), người phân tích, thiết kế và hiện thực ca kiểm thử, nên mục iv sai. "ii,iii,iv is true and i is false" sai vì coi việc làm việc với nhà cung cấp công cụ không thuộc trưởng nhóm và gán nhầm việc viết đặc tả. "i is true and ii,iii,iv are false" bỏ sót việc viết báo cáo tổng kết và quyết định tự động hoá. "iii and iv is correct and i and ii are incorrect" vừa gán nhầm mục iv vừa bác hai việc vốn là trách nhiệm trưởng nhóm.

Đáp án đúng: "ii,iii,iv is true and i is false". ISTQB Foundation liệt kê nhiệm vụ điển hình của người kiểm thử (tester): rà soát và góp ý kế hoạch kiểm thử, phân tích và đánh giá yêu cầu về khả năng kiểm thử, tạo đặc tả kiểm thử (test specifications), thiết lập môi trường, chuẩn bị và thu thập dữ liệu kiểm thử (prepare and acquire test data), triển khai kiểm thử ở mọi cấp, thực thi và ghi nhật ký (implement tests on all test levels, execute and log), dùng công cụ và tự động hoá. Như vậy mục ii, iii, iv đều là việc của tester. Mục i, làm việc với nhà cung cấp công cụ để tìm cách khai thác công cụ tốt nhất cho dự án, thuộc nhiệm vụ của trưởng nhóm kiểm thử (test leader) vì gắn với quyết định quản lý và lựa chọn công cụ. "i, ii, iii is true and iv is false" sai vì nhận nhầm mục i và loại mục iv. "i is true and ii,iii,iv are false" đảo ngược hoàn toàn sự phân vai. "iii and iv is correct and i and ii are incorrect" bỏ sót mục ii, trong khi chuẩn bị dữ liệu kiểm thử là việc tester trực tiếp làm.

Đáp án đúng: "Done by an Entity Outside the Project’s sphere of influence". Thẩm định và xác nhận độc lập (Independent Verification and Validation, IV&V) là việc kiểm tra sản phẩm có làm đúng đặc tả (verification) và có đáp ứng nhu cầu sử dụng (validation) hay không, do một bên độc lập với dự án về kỹ thuật, quản lý và tài chính thực hiện; theo thang mức độc lập của ISTQB, mức cao nhất là người kiểm thử đến từ bên ngoài tổ chức, giúp tránh định kiến của người làm ra sản phẩm. "Done by the Developer" là mức độc lập thấp nhất, tác giả tự kiểm tra sản phẩm của chính mình. "Done by the Test Engineers" chỉ độc lập một phần khi họ vẫn thuộc dự án, chịu cùng áp lực tiến độ và báo cáo cho cùng quản lý dự án. "Done By Management" không đúng vì ban quản lý dự án là bên chịu trách nhiệm tiến độ và chi phí, chính là thứ IV&V phải đứng ngoài để giữ khách quan.

Đáp án đúng: "Suggestions as to how to fix the problem.". Báo cáo sự cố (incident report) theo IEEE 829 mô tả điều đã quan sát được để người khác tái hiện và phân tích: ai báo, khi nào, phiên bản phần mềm và môi trường, các bước, kết quả mong đợi và kết quả thực tế, mức nghiêm trọng; còn chẩn đoán nguyên nhân và cách sửa là việc của lập trình viên khi gỡ lỗi, nên đề xuất cách sửa thường không có trên báo cáo. "The name and/or organisational position of the person raising the problem." là thông tin chuẩn để biết ai phát hiện và liên hệ lại. "Version of the Software Under Test." là bắt buộc vì không biết phiên bản thì không tái hiện được lỗi. "Actual and expected results." là phần cốt lõi, chính độ lệch giữa hai kết quả này làm nên sự cố.

Đáp án đúng: "1 -b, 2-c, 3-a". Ước lượng kiểm thử (test estimation) là dự tính công sức, thời gian cần cho các hoạt động kiểm thử, nên 1 ghép với b; giám sát kiểm thử (test monitoring) là thu thập và theo dõi các số đo tiến độ như số ca đã chạy, số lỗi tìm thấy, độ phủ đạt được, nên 3 ghép với a; điều khiển kiểm thử (test control) là hành động khắc phục khi giám sát thấy lệch kế hoạch, chẳng hạn phân bổ lại nguồn lực hay đổi thứ tự ưu tiên, nên 2 ghép với c. "1 -b, 2-a, 3-c" đảo vai giám sát và điều khiển: coi điều khiển là đo đếm còn giám sát là phân bổ lại nguồn lực. "1 -c, 2-a, 3-b" sai cả ba cặp, gán việc phân bổ lại nguồn lực cho ước lượng và công sức cho giám sát. "1 -a, 2-b, 3-c" cũng sai cả ba vì coi ước lượng là đo tiến độ, trong khi ước lượng diễn ra từ lúc lập kế hoạch, khi chưa có tiến độ nào để đo.

Đáp án đúng: "Eliminate some of the requirements that have not yet been implemented.". Dự án bị ràng buộc cả ngày giao lẫn chuẩn chất lượng, nên trong tam giác phạm vi, thời gian, chất lượng thì chỉ còn phạm vi là được phép điều chỉnh; cắt bớt các yêu cầu chưa hiện thực (thường là yêu cầu ưu tiên thấp, thoả thuận lại với khách hàng) là cách khả thi để kịp hạn mà không hạ chất lượng. "Add more engineers to the project to make up for lost work." vấp phải định luật Brooks: thêm người vào dự án đang trễ còn làm nó trễ hơn, vì người mới cần thời gian làm quen và chi phí giao tiếp tăng. "Ask the current developers to work overtime until the lost work is recovered." không bền: bù sáu tuần trong bốn tháng đòi tăng ca kéo dài, gây mệt mỏi và sinh thêm lỗi, trái với yêu cầu giữ chất lượng. "Hire more software quality assurance personnel." không tăng năng lực phát triển, nên không lấy lại được khối lượng mã còn thiếu.

Đáp án đúng: "i,ii,iii are correct and iv is incorrect". Theo ISTQB Foundation, theo dõi tiến độ kiểm thử (test progress monitoring) dùng các số đo như tỉ lệ công việc chuẩn bị ca kiểm thử, tỉ lệ công việc chuẩn bị môi trường kiểm thử, tỉ lệ ca kiểm thử đã thực thi (đạt, không đạt, chưa chạy), thông tin về lỗi như mật độ lỗi (defect density), số lỗi tìm thấy và đã sửa, độ phủ, mốc thời gian và chi phí. Mục i, ii, iii đều thuộc danh sách đó. Mục iv, quy mô đội kiểm thử và kỹ năng của kỹ sư, là đầu vào của lập kế hoạch và ước lượng nhân lực, không cho biết công việc đã tiến tới đâu. "iv is correct and i,ii,iii are incorrect" đảo ngược hoàn toàn. "i,ii are correct and iii,iv are incorrect" bỏ sót thông tin lỗi, vốn là chỉ số tiến độ quan trọng. "i,iv are correct and ii , iii are incorrect" nhận nhầm mục iv và bỏ sót tiến độ chuẩn bị môi trường cùng thông tin lỗi.

Đáp án đúng: "ii & iii are true, i, iv & v are false.". Lập kế hoạch kiểm thử (test planning) xác định phạm vi, rủi ro, mục tiêu, cách tiếp cận tổng thể, lịch, tiêu chí thoát và phân bổ nguồn lực, nên mục ii (xác định cách tiếp cận tổng thể) và mục iii (phân công nguồn lực) thuộc kế hoạch. Viết điều kiện kiểm thử và phát triển ca kiểm thử thuộc pha phân tích và thiết kế (rồi hoàn thiện ở pha triển khai), còn dựng môi trường kiểm thử thuộc pha triển khai và thực thi, nên mục i, iv, v không thuộc kế hoạch. "i, ii & iv are true, iii & v are false." sai vì coi phát triển ca kiểm thử và dựng môi trường là lập kế hoạch, lại loại việc phân công nguồn lực. "iv & v are true, i, ii & iii are false." đảo ngược hoàn toàn, loại cả hai hoạt động lập kế hoạch thật. "i, ii & iii are true iv & v are false." đúng hai mục nhưng gộp nhầm việc phát triển ca kiểm thử.

Đáp án đúng: "Sign the system off for release". Quyết định phát hành thuộc về các bên liên quan như quản lý dự án, chủ sản phẩm hay khách hàng; trưởng nhóm kiểm thử (test manager) cung cấp thông tin về chất lượng và rủi ro còn lại để họ quyết định, chứ không tự ký cho hệ thống phát hành, vì như thế vừa vượt thẩm quyền vừa làm mất tính độc lập của kiểm thử. "Report on deviations from the project plan" là việc đúng vai trò, thuộc hoạt động giám sát và kiểm soát kiểm thử. "Re-allocate resource to meet original plans" cũng là hành động kiểm soát kiểm thử (test control) mà trưởng nhóm được phép làm khi tiến độ lệch. "Rise incidents on faults that they have found" là trách nhiệm của bất kỳ ai phát hiện khiếm khuyết. "Provide information for risk analysis and quality improvement" là đóng góp quan trọng của kiểm thử cho quản lý rủi ro và cải tiến quy trình.

Đáp án đúng: "i,ii,iii are true and iv is false.". ISTQB liệt kê các yếu tố bối cảnh khi chọn cách tiếp cận kiểm thử gồm: rủi ro thất bại của dự án, mối nguy với sản phẩm và rủi ro sản phẩm hỏng gây hại cho con người (mục i), kỹ năng và kinh nghiệm của con người với kỹ thuật, công cụ, phương pháp đề xuất (mục ii), mục tiêu của nỗ lực kiểm thử và sứ mệnh của nhóm kiểm thử (mục iii), cùng quy định pháp lý và bản chất sản phẩm; quy mô nhóm kiểm thử (mục iv) không nằm trong danh sách này, nó ảnh hưởng tới lịch và phân bổ công việc chứ không quyết định cách tiếp cận. "i,ii,iii,iv are true" sai vì coi cả quy mô nhóm là yếu tố chọn cách tiếp cận. "ii,iii,iv are true and i is false." sai vì loại rủi ro, yếu tố quan trọng nhất của kiểm thử dựa trên rủi ro. "i,iv are true and ii, iii are false." sai vì loại kỹ năng và mục tiêu kiểm thử, hai yếu tố được nêu rõ.

Đáp án đúng: "De-bugging.". Quản lý kiểm thử (test management) bao gồm lập kế hoạch và ước lượng, giám sát và điều khiển, quản lý rủi ro, quản lý sự cố và quản lý cấu hình; gỡ lỗi (debugging) là hoạt động phát triển, do lập trình viên tìm nguyên nhân lỗi, sửa mã và kiểm tra bản sửa, không phải trách nhiệm của quản lý kiểm thử nên kém quan trọng nhất trong bối cảnh này. "Estimating test duration." là ước lượng thời gian kiểm thử, phần cốt lõi của lập kế hoạch giúp bố trí lịch và nguồn lực. "Incident Management" theo dõi sự cố từ lúc phát hiện tới khi đóng, cung cấp số liệu cho giám sát tiến độ và quyết định phát hành. "Configuration Management." bảo đảm biết chính xác phiên bản phần mềm và testware đang được kiểm thử, để kết quả kiểm thử truy vết và tái lập được.

Đáp án đúng: "i,iii,iv are true and ii is false". Dàn ý kế hoạch kiểm thử (test plan outline) theo IEEE 829 gồm các mục: định danh kế hoạch, giới thiệu, hạng mục kiểm thử (test items), tính năng được và không được kiểm thử, cách tiếp cận, tiêu chí đạt/không đạt, tiêu chí tạm dừng và tiếp tục, sản phẩm bàn giao của kiểm thử (test deliverables), nhiệm vụ kiểm thử, nhu cầu môi trường, trách nhiệm (responsibilities), nhân sự và đào tạo, lịch, rủi ro và phê duyệt. Vậy mục i, iii, iv đều có. Kịch bản kiểm thử (test scripts) là mức chi tiết thực thi, thuộc đặc tả thủ tục kiểm thử (test procedure specification) chứ không nằm trong kế hoạch. "i,ii,iii are true and iv is false" sai vì nhận kịch bản và bỏ trách nhiệm. "ii,iii are true and i and iv are false" sai vì bỏ hạng mục kiểm thử, mục cốt lõi của kế hoạch. "i,ii are false and iii , iv are true" bỏ sót hạng mục kiểm thử.

Đáp án đúng: "Define when to stop testing". Tiêu chí kết thúc (exit criteria) là tập điều kiện thống nhất với bên liên quan, như độ phủ phải đạt, số lỗi nghiêm trọng còn mở, mức rủi ro còn lại, để quyết định một hoạt động hay một cấp kiểm thử được coi là xong; mục đích của nó là xác định khi nào dừng kiểm thử. "End of test level" chỉ mô tả thời điểm kết thúc một cấp, tức kết quả khi tiêu chí đã được thỏa, không phải mục đích của tiêu chí. "When a set of tests has achieved a specific pre condition" lẫn với tiêu chí đầu vào (entry criteria), vốn là điều kiện tiên quyết để bắt đầu một hoạt động chứ không phải để kết thúc. "All of the others" sai vì hai mô tả kia không phải mục đích của tiêu chí kết thúc.

Đáp án đúng: "Improvements suggested by users". Sự cố (incident) là bất kỳ sự kiện nào xảy ra trong kiểm thử cần được điều tra, thường là chênh lệch giữa kết quả thực tế và kết quả mong đợi. Theo ISTQB Foundation, sự cố có thể được ghi nhận đối với bất kỳ sản phẩm công việc nào có thể chứa lỗi, như yêu cầu, tài liệu, ca kiểm thử hay mã. Góp ý cải tiến của người dùng thì không phải sai lệch so với điều mong đợi mà là đề xuất thay đổi, thường được quản lý như yêu cầu thay đổi hay yêu cầu nâng cấp (change request, enhancement request), nên thông thường không mở sự cố cho nó. "Requirements" có thể bị ghi sự cố khi yêu cầu mâu thuẫn, mơ hồ hay sai. "Documentation" như hướng dẫn sử dụng có thể bị ghi sự cố khi mô tả không khớp hệ thống. "Test cases" cũng có thể bị ghi sự cố khi chính kết quả mong đợi trong ca kiểm thử bị sai.

Đáp án đúng: "Even though the numbers you look at appear better, to achieve these numbers, people are doing other aspects of their work much less well.". Rối loạn đo lường (measurement dysfunction) là hiện tượng khi một chỉ số được dùng để đánh giá con người, họ điều chỉnh hành vi cho chỉ số đẹp lên, nhưng cái giá là những phần việc không được đo bị làm kém đi; ví dụ chấm điểm người kiểm thử theo số lỗi tìm được thì họ báo nhiều lỗi vặt và né lỗi khó, con số tốt hơn mà chất lượng thực giảm. "We don't know how to measure a variable (our measurement is dysfunctional)" mô tả việc không biết cách đo, đó là vấn đề độ tin cậy của phép đo chứ không phải sự biến dạng hành vi do bị đo. "You are measuring the wrong thing and thus reaching the wrong conclusions." là lỗi chọn sai đại lượng dẫn tới kết luận sai, không nói tới việc con người làm tệ đi phần việc khác. "All of the others" sai vì hai mô tả kia không phải bản chất của rối loạn đo lường.