Câu hỏi: SWT301 Software Testing – Bộ ôn tập thi lại số 3

Đáp án đúng: "1&2 are true and 3 is false". Khi nhận một phần mềm với thời gian và nguồn lực có hạn, không thể kiểm thử vét cạn, nên ISTQB khuyên kiểm thử dựa trên rủi ro (risk-based testing): ưu tiên các vùng quan trọng nhất với quy trình nghiệp vụ, nơi hỏng hóc gây tác động lớn, và các vùng nhiều khả năng chứa lỗi nhất theo nguyên lý lỗi tụ thành cụm (defect clustering). Vì thế mệnh đề 1 và 2 đúng, còn kiểm thử các chức năng dễ nhất là sai vì dễ kiểm thử không có nghĩa là rủi ro cao. "1,2&3 are true." sai vì nhận cả tiêu chí dễ nhất, vốn không phản ánh tác động hay khả năng hỏng. "1 is true, 2&3 are false." bỏ mất vùng nhiều lỗi, trái với nguyên lý lỗi tụ thành cụm. "1&2 are false, 3 is true" đảo ngược hoàn toàn, chọn việc dễ thay vì việc quan trọng.

Đáp án đúng: "Cultural difference". Khi kiểm thử phần mềm do nhà thầu bên ngoài phát triển (outsourced, contracted software), các rủi ro như mất quyền kiểm soát, khó điều chuyển nguồn lực, sản phẩm có thể không đáp ứng nhu cầu đều có mặt bất kể nhà thầu ở trong hay ngoài nước. Điểm khác biệt riêng khi nhà thầu ở nước ngoài là khác biệt văn hoá: ngôn ngữ, cách hiểu yêu cầu, thói quen làm việc, múi giờ, chuẩn mực giao tiếp, khiến yêu cầu dễ bị hiểu lệch và cần kiểm thử, đối chiếu kỹ hơn. "Does not meet people needs" là rủi ro chung của mọi phần mềm mua hoặc thuê làm, không phân biệt vị trí nhà thầu. "Loss of control over reallocation of resources" cũng xảy ra với nhà thầu trong nước, vì nguồn lực nằm ở phía nhà thầu. "Relinquishments of control" là việc từ bỏ quyền kiểm soát quy trình phát triển, đặc điểm chung của mọi hình thức thuê ngoài.

Đáp án đúng: "Plan, Do, Check, Act". PDCA là chu trình cải tiến liên tục, gắn với tên Deming (còn gọi là vòng Deming hay Shewhart), gồm bốn bước: Plan (lập kế hoạch, đặt mục tiêu và cách làm), Do (thực hiện), Check (kiểm tra, đo kết quả so với mục tiêu) và Act (hành động điều chỉnh, chuẩn hoá cái tốt rồi bắt đầu vòng mới). Trong kiểm thử, chu trình này là nền cho cải tiến quy trình kiểm thử. "Plan, Do, Correct, Act" sai ở bước thứ ba: chu trình cần kiểm tra, đánh giá trước rồi mới điều chỉnh, sửa chữa thuộc về bước Act. "Plan, Debug, Check, Act" sai vì gỡ lỗi (debug) là hoạt động của lập trình viên, không phải bước của chu trình quản lý chất lượng. "Plan, Do, Check, Accept" sai ở bước cuối: Act là hành động cải tiến, không phải chấp nhận kết quả.

Đáp án đúng: "When the test completion criteria have been met". Tiêu chí hoàn thành (test completion criteria, hay exit criteria) được đặt từ lúc lập kế hoạch, chẳng hạn mức độ phủ, số khiếm khuyết còn mở, rủi ro còn lại chấp nhận được, và chính chúng là căn cứ khách quan để dừng kiểm thử. "When time for testing has run out." là điều hay xảy ra trong thực tế nhưng là dừng vì áp lực, không bảo đảm chất lượng đạt yêu cầu; thời gian chỉ hợp lệ khi đã được ghi vào tiêu chí. "When all planned tests have been run" chưa đủ vì có thể còn nhiều ca thất bại hay khiếm khuyết nghiêm trọng chưa sửa. "When no faults have been found by the tests run" sai vì kiểm thử chỉ chứng minh có khiếm khuyết chứ không chứng minh được không còn khiếm khuyết; không tìm thấy lỗi có thể chỉ do bộ ca yếu.

Đáp án đúng: "To define when a test level is complete.". Tiêu chí thoát (exit criteria) là các điều kiện được thống nhất với các bên liên quan, như mức độ phủ đạt được, số khiếm khuyết nghiêm trọng còn mở, rủi ro còn lại, để quyết định một cấp kiểm thử hay một hoạt động kiểm thử đã có thể coi là hoàn thành; chúng được đặt khi lập kế hoạch và được đánh giá ở pha đánh giá tiêu chí thoát và báo cáo. "To determine when a test has completed." nhầm phạm vi: một ca kiểm thử chạy xong là khi các bước được thực hiện hết, không cần tiêu chí thoát. "To identify when a software system should be retired." thuộc quyết định bảo trì và vòng đời sản phẩm, không liên quan tới tiêu chí thoát của kiểm thử. "To determine whether a test has passed." là việc so kết quả thực tế với kết quả mong đợi của từng ca, khác với việc quyết định dừng cả cấp kiểm thử.

Đáp án đúng: "The answer depends on the risk for your industry, contract and special requirements". Kiểm thử vét cạn là không thể, nên ISTQB trả lời câu hỏi bao nhiêu kiểm thử là đủ bằng rủi ro: mức rủi ro của ngành và sản phẩm, ràng buộc hợp đồng, yêu cầu đặc biệt như quy định pháp lý, cùng thời gian và ngân sách, quyết định phải kiểm thử sâu tới đâu và ưu tiên chỗ nào. "This question is impossible to answer" sai vì tuy không có con số tuyệt đối, ta vẫn trả lời được bằng tiêu chí dựa trên rủi ro và tiêu chí thoát. "This question is easy to answer" sai vì câu trả lời đòi hỏi phân tích rủi ro cho từng bối cảnh, không có công thức chung. "This answer depends on the maturity of your developers" chỉ đúng một phần: lập trình viên trưởng thành có thể sinh ít khiếm khuyết hơn, nhưng đó không phải căn cứ chính để quyết định mức kiểm thử, rủi ro mới là căn cứ.

Đáp án đúng: "To plan when to stop testing". Tiêu chí hoàn thành kiểm thử (test completion criteria, còn gọi tiêu chí kết thúc) được ghi trong kế hoạch kiểm thử để định trước điều kiện nào thì hoạt động kiểm thử được coi là đủ, ví dụ đạt độ phủ yêu cầu, không còn lỗi nghiêm trọng mở, rủi ro còn lại chấp nhận được; nhờ đó việc dừng kiểm thử dựa trên căn cứ đã thống nhất chứ không chỉ vì hết thời gian. "To know when a specific test has finished its execution" nhầm với trạng thái chạy xong của một ca kiểm thử riêng lẻ, việc không cần tiêu chí trong kế hoạch. "To ensure that the test case specification is complete" là việc rà soát tài liệu đặc tả ca kiểm thử. "To set the criteria used in generating test inputs" là việc của kỹ thuật thiết kế ca kiểm thử như phân hoạch tương đương, giá trị biên. "To know when test planning is complete" chỉ nói về việc lập kế hoạch xong, trong khi tiêu chí hoàn thành áp cho toàn bộ hoạt động kiểm thử.

Đáp án đúng: "Is unlikely to cause a failure". Độ tin cậy (reliability) là khả năng phần mềm thực hiện chức năng yêu cầu trong điều kiện xác định trong một khoảng thời gian hoặc số thao tác xác định, thường diễn đạt bằng xác suất hoạt động không có thất bại (failure). Vì vậy hệ thống tin cậy là hệ thống ít có khả năng gây ra thất bại khi vận hành. "Is unlikely to be completed on schedule" nói về tiến độ dự án, không liên quan tới chất lượng sản phẩm. "Is likely to be fault-free" sai vì một hệ thống vẫn có thể chứa khiếm khuyết (fault) mà vẫn tin cậy nếu các khiếm khuyết đó nằm ở chỗ hiếm khi được thực thi; ngược lại không hệ thống thực tế nào chứng minh được là không có lỗi. "Is likely to be liked by the users" thuộc về sự hài lòng, tính khả dụng; người dùng có thể thích một hệ thống dù nó thỉnh thoảng gặp sự cố.

Đáp án đúng: "Non-functional testing.". Bảo mật, hiệu năng, độ tin cậy và khả năng sử dụng là các đặc tính chất lượng mô tả hệ thống hoạt động tốt tới mức nào chứ không phải hệ thống làm gì; kiểm thử phi chức năng (non-functional testing) là loại kiểm thử đánh giá chính các đặc tính đó, ví dụ hệ thống ngân hàng trực tuyến phải chịu được nhiều người đăng nhập cùng lúc và chống được truy cập trái phép. "Functional testing" kiểm tra các chức năng như chuyển khoản, tra số dư có cho kết quả đúng không, không đo thuộc tính chất lượng. "System integration" là kiểm thử tích hợp hệ thống, xét tương tác với hệ thống bên ngoài như cổng thanh toán, là một cấp kiểm thử chứ không phải loại kiểm thử hướng vào thuộc tính chất lượng. "Requirements testing" là kiểm thử dựa trên yêu cầu, một cách lấy cơ sở kiểm thử, không gắn riêng với nhóm thuộc tính nào.

Đáp án đúng: "Confirmation testing". Kiểm thử xác nhận (confirmation testing, còn gọi re-testing, kiểm thử lại) là chạy lại đúng những ca kiểm thử đã thất bại sau khi khiếm khuyết được sửa, để xác nhận khiếm khuyết gốc thật sự đã được loại bỏ; đây chính là tình huống câu hỏi mô tả. "Regression testing" là kiểm thử hồi quy: chạy lại các ca kiểm thử trên phần đã kiểm thử trước đó để phát hiện khiếm khuyết mới bị đưa vào hoặc bị lộ ra do thay đổi, tức là tìm tác dụng phụ ở chỗ khác chứ không kiểm tra lỗi gốc đã hết chưa. "Maintenance testing" là kiểm thử bảo trì, áp dụng khi hệ thống đang vận hành bị sửa đổi, chuyển đổi môi trường hoặc ngừng sử dụng; nó là một bối cảnh kiểm thử chứ không phải tên của việc chạy lại ca thất bại. "None of the above" sai vì đã có thuật ngữ khớp chính xác với mô tả.

Đáp án đúng: "System Testing". Kiểm thử hệ thống (system testing) là cấp kiểm thử trên toàn bộ hệ thống đã tích hợp, kiểm tra cả yêu cầu chức năng lẫn phi chức năng như hiệu năng, bảo mật, tính dùng được, và thường chạy một bộ ca kiểm thử định sẵn để chứng minh với ban quản lý rằng hệ thống đáp ứng đặc tả. Mô tả trong câu hỏi khớp đúng định nghĩa này: toàn hệ thống, mọi loại yêu cầu, đối chiếu với specifications. "Validation Testing" là khái niệm rộng, hỏi xem sản phẩm có đúng là thứ người dùng cần hay không, không gắn riêng với việc kiểm toàn hệ thống theo đặc tả. "Integration Testing" chỉ kiểm giao diện và tương tác giữa các thành phần khi ghép lại, chưa phải toàn bộ hệ thống. "User Acceptance Testing" do người dùng thực hiện để quyết định có chấp nhận hệ thống hay không, căn cứ vào nhu cầu nghiệp vụ chứ không phải để kiểm đủ mọi yêu cầu cấu trúc và chất lượng trước ban quản lý.

Đáp án đúng: "The fault has been built into more documentation, code, tests, etc". Một lỗi sinh ra ở pha đầu, ví dụ trong yêu cầu, sẽ lan sang thiết kế, mã nguồn, tài liệu người dùng và cả ca kiểm thử được viết theo yêu cầu đó; càng phát hiện muộn thì càng nhiều sản phẩm công việc phải sửa lại và kiểm lại, nên chi phí sửa tăng theo cấp số qua từng pha. Đây là lý do ISTQB đặt nguyên tắc kiểm thử sớm (early testing). "The documentation is poor, so it takes longer to find out what the software is doing." chỉ là một tình huống riêng của dự án có tài liệu kém, không giải thích quy luật chung áp dụng cho mọi dự án. "Wages are rising" không liên quan: chi phí tăng vì khối lượng sửa chữa lan rộng chứ không vì lương tăng theo thời gian. "None of the others" sai vì đã có một phương án nêu đúng nguyên nhân là lỗi bị nhúng vào ngày càng nhiều sản phẩm công việc.

Đáp án đúng: "ii is true and i,iii,iv are false". Xác nhận (validation) trả lời câu hỏi "chúng ta có xây đúng sản phẩm không", tức sản phẩm có đáp ứng nhu cầu và mục đích sử dụng thật của người dùng, nên mục ii đúng. Mục i, kiểm chất lượng của sản phẩm đã làm ra so với đặc tả, gần với kiểm định (verification), trả lời câu hỏi "chúng ta có xây sản phẩm đúng cách không". Mục iii sai vì validation là hoạt động đánh giá, không trực tiếp phát triển sản phẩm; mục iv về theo dõi hao mòn, lỗi thời của công cụ không liên quan. "Options i,ii,iii,iv are true" sai vì nhận cả những mục không thuộc validation. "i,ii,iii are true and iv is false" sai vì gộp verification và việc phát triển vào validation. "iii is true and i,ii,iv are false." sai vì phủ nhận đúng mục định nghĩa validation và nhận mục phát triển sản phẩm.

Đáp án đúng: "Component testing does not involve regression testing". Câu hỏi tìm phát biểu không đúng. Kiểm thử thành phần (component testing) hoàn toàn có kiểm thử hồi quy: mỗi khi thành phần bị sửa, các ca kiểm thử đơn vị được chạy lại, thường tự động trong unit test framework, để chắc thay đổi không làm hỏng chức năng cũ; hồi quy áp dụng ở mọi cấp kiểm thử. Các phát biểu kia đúng nên không được chọn. "Component testing should be performed by development" đúng vì kiểm thử thành phần thường do lập trình viên viết mã thực hiện, cần truy cập mã và môi trường phát triển. "Component testing is also known as isolation or module testing" đúng vì thành phần được kiểm cô lập với phần còn lại bằng stub và driver, và còn được gọi là module testing hay unit testing. "Component testing should have completion criteria planned" đúng vì như mọi cấp kiểm thử, nó cần tiêu chí hoàn thành, chẳng hạn mức độ phủ, được lập kế hoạch trước.

Đáp án đúng: "Incorrect program behaviour due to a fault in the program". Thất bại (failure) là sự lệch quan sát được của thành phần hay hệ thống khỏi hành vi hoặc kết quả mong đợi, xảy ra khi đoạn mã chứa khiếm khuyết (fault) được thực thi; nó được định nghĩa bằng biểu hiện khi chạy chương trình chứ không bằng thời điểm phát hiện. "Bug found before product Release" và "Bug found after product Release" đều định nghĩa theo thời điểm, trong khi thất bại có thể xảy ra cả trước lẫn sau phát hành; ngoài ra từ bug thường chỉ khiếm khuyết trong mã, tức nguyên nhân chứ không phải biểu hiện. "Bug found during Design phase" là khiếm khuyết trong tài liệu thiết kế, thường tìm qua rà soát khi chưa có mã chạy, nên chưa thể có thất bại nào.

Đáp án đúng: "Bottom-up integration". Tích hợp từ dưới lên (bottom-up integration) bắt đầu kiểm thử các mô-đun lá ở tầng thấp nhất, rồi ghép dần lên các mô-đun gọi chúng cho tới mô-đun điều khiển chính; vì mô-đun cấp trên chưa có nên phải viết driver để gọi các mô-đun cấp dưới và truyền dữ liệu kiểm thử. "Top-down integration" đi chiều ngược lại, bắt đầu từ mô-đun điều khiển cao nhất và dùng stub thay cho các mô-đun cấp dưới chưa hoàn thành. "Module integration" không phải tên một chiến lược tích hợp cụ thể, chỉ là cách nói chung về việc ghép mô-đun, không xác định thứ tự từ dưới lên hay từ trên xuống. "None of the others" sai vì tích hợp từ dưới lên khớp đúng mô tả của câu hỏi.

Đáp án đúng: "i , iii , iv are true and ii is false". Theo ISTQB Foundation, hoạt động đóng kiểm thử (test closure activities) gồm kiểm tra sản phẩm bàn giao theo kế hoạch đã được giao chưa (mục i), đóng các báo cáo sự cố hoặc chuyển chúng thành yêu cầu thay đổi, lập tài liệu chấp nhận hệ thống, hoàn thiện và lưu trữ testware (mục iii), bàn giao testware cho bộ phận bảo trì và phân tích bài học kinh nghiệm (mục iv). Phân tích báo cáo lỗi (mục ii) thuộc theo dõi và kiểm soát kiểm thử, khi thông tin lỗi được dùng để đánh giá tiến độ và chất lượng; nó không nằm trong danh sách chuẩn của đóng kiểm thử, vốn chỉ yêu cầu đóng báo cáo sự cố. "i , ii , iv are true and iii is false" sai vì loại hoàn thiện và lưu trữ testware, một hoạt động cốt lõi của giai đoạn này. "i , ii , iii are true and iv is false" sai vì loại phân tích bài học. "All of them are true" sai vì tính cả phân tích báo cáo lỗi.

Đá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: "i,ii,iii are true and iv is false.". Theo ISTQB, một cuộc rà soát hình thức (formal review) có các vai trò: quản lý (manager) quyết định thực hiện rà soát, cấp thời gian và nguồn lực; người điều phối (moderator) dẫn dắt quy trình và chủ trì cuộc họp; tác giả (author) của tài liệu; người rà soát (reviewer) tìm lỗi; người ghi chép (scribe, recorder) ghi lại lỗi và vấn đề. Vì vậy i, ii, iii đều đúng, còn trợ lý quản lý (assistant manager) không phải vai trò được định nghĩa trong rà soát nên iv sai. "i,ii,iii,iv are true" sai vì nhận cả trợ lý quản lý. "ii,iii,iv are true and i is false." sai vì loại quản lý, trong khi quản lý là vai trò chính thức quyết định và cấp nguồn lực cho rà soát. "i,iv are true and ii, iii are false." sai nặng nhất vì bác cả người điều phối lẫn người ghi chép, hai vai trò cốt lõi của cuộc họp rà soát.