Câu hỏi: SWT301 - Phần 1: Nền tảng và nguyên tắc kiểm thử

Đáp án đúng: "Viability". Chất lượng phần mềm được mô tả bằng các thuộc tính chất lượng trong các mô hình như McCall hay ISO/IEC 9126 (nay là ISO/IEC 25010), chẳng hạn tính đúng đắn, tính dùng được, tính tin cậy, tính bảo trì, tính tái sử dụng, tính khả chuyển. Viability (tính khả thi, khả năng tồn tại về mặt kinh doanh) là khái niệm đánh giá dự án hay sản phẩm có đáng đầu tư, có sinh lời hay không, không phải một thuộc tính chất lượng của bản thân phần mềm. "Correctness" là tính đúng đắn, mức phần mềm thoả đặc tả và đáp ứng mục tiêu người dùng, là một yếu tố chất lượng cốt lõi. "Usability" là tính dùng được, phần mềm dễ học, dễ thao tác đến đâu, thuộc nhóm đặc tính chất lượng trong ISO 9126. "Reusability" là tính tái sử dụng, mức thành phần có thể dùng lại ở hệ thống khác, có mặt trong nhóm yếu tố chất lượng của McCall.

Đáp án đúng: "A failure". Trong chuỗi thuật ngữ của ISTQB, con người phạm sai lầm (error hay mistake), sai lầm đó tạo ra khiếm khuyết nằm trong mã hoặc tài liệu (defect, fault, bug), và khi đoạn mã khiếm khuyết được thực thi thì hệ thống có thể lệch khỏi hành vi mong đợi, sự lệch quan sát được ấy là thất bại (failure); câu hỏi nhấn vào thứ người dùng cuối nhìn thấy nên đó là failure. "An error" là hành động sai của con người, xảy ra trong đầu người viết chứ không phải thứ người dùng thấy. "A mistake" là từ đồng nghĩa với error nên bị loại cùng lý do. "A fault" là khiếm khuyết nằm tĩnh trong mã, có thể tồn tại mà chưa bao giờ lộ ra. "A defect" cũng là khiếm khuyết trong sản phẩm, nguyên nhân của thất bại chứ không phải biểu hiện bên ngoài.

Đáp án đúng: "Poor software and poor testing". Lỗi mà người dùng gặp phải là lỗi đã lọt qua toàn bộ quá trình phát triển và kiểm thử: nó tồn tại vì phần mềm được làm ra có khuyết tật (yêu cầu, thiết kế, mã chưa tốt), và nó lọt tới tay người dùng vì kiểm thử chưa đủ tốt để phát hiện, do thiết kế ca kiểm thử yếu, độ phủ thấp hay ưu tiên sai rủi ro. Hai yếu tố này cùng đúng nên phương án gộp cả hai là đầy đủ nhất. "Insufficient time for testing" có thể là một nguyên nhân góp phần, nhưng thiếu thời gian chỉ dẫn tới kiểm thử kém, và dù đủ thời gian mà phần mềm kém, kiểm thử kém thì lỗi vẫn lọt, nên nó chỉ là một khía cạnh hẹp. "Bad luck" không phải lời giải thích kỹ thuật; lỗi là hệ quả của sai sót con người trong phát triển và kiểm thử, có thể phòng ngừa và phát hiện bằng quy trình tốt.

Đáp án đúng: "Requirement Analysis". Quy trình kiểm thử cơ bản (Fundamental Test Process) trong ISTQB gồm năm nhóm hoạt động: lập kế hoạch và kiểm soát, phân tích và thiết kế, triển khai và thực thi, đánh giá tiêu chí thoát và báo cáo, kết thúc kiểm thử. Phân tích yêu cầu là hoạt động của vòng đời phát triển phần mềm do người phân tích nghiệp vụ thực hiện để xác định hệ thống phải làm gì; kiểm thử có thể rà soát tài liệu yêu cầu nhưng đó là rà soát cơ sở kiểm thử chứ không phải một pha mang tên phân tích yêu cầu. "Test Planning and Control" là pha đầu tiên, đặt mục tiêu và theo dõi tiến độ. "Test implementation and Execution" là pha xây quy trình kiểm thử và chạy kiểm thử. "Evaluating Exit criteria and reporting" là pha đối chiếu kết quả với tiêu chí thoát và báo cáo cho các bên liên quan.

Đáp án đúng: "Uncover software errors". Mục tiêu căn bản của kiểm thử phần mềm là tìm ra lỗi: chạy chương trình với ý định phát hiện khuyết tật, qua đó cung cấp thông tin về chất lượng và giảm rủi ro. ISTQB nhấn mạnh kiểm thử chỉ cho thấy có lỗi, không chứng minh được là không còn lỗi. "Determine the productivity of programmers" sai vì kiểm thử đánh giá sản phẩm chứ không đánh giá con người; dùng số lỗi để chấm năng suất còn làm hỏng quan hệ giữa người kiểm thử và lập trình viên. "Eliminate the need for future program maintenance" sai vì bảo trì luôn cần do yêu cầu thay đổi, môi trường thay đổi và lỗi còn sót, kiểm thử không loại bỏ được nhu cầu đó. "Eliminate every error prior to release" trái với nguyên tắc kiểm thử vét cạn là không thể và kiểm thử không chứng minh được sự vắng mặt của lỗi.

Đáp án đúng: "Debugging defects". ISTQB phân biệt rõ kiểm thử với gỡ lỗi (debugging): kiểm thử làm lộ ra thất bại do khiếm khuyết gây ra, còn gỡ lỗi là hoạt động phát triển nhằm tìm nguyên nhân, phân tích và sửa khiếm khuyết, thường do lập trình viên làm, nên gỡ lỗi không phải mục tiêu của kiểm thử. "Finding defects" là mục tiêu kinh điển của kiểm thử. "Gaining confidence about the level of quality and providing information" cũng là mục tiêu được nêu rõ: kiểm thử tạo niềm tin vào mức chất lượng và cung cấp thông tin cho việc ra quyết định. "Preventing defects." là mục tiêu đạt được nhờ tham gia kiểm thử sớm, rà soát yêu cầu và thiết kế để chặn khiếm khuyết trước khi nó được viết vào mã.

Đáp án đúng: "Faults in requirements are the most expensive to fix". Chi phí sửa lỗi tăng theo thời gian lỗi tồn tại trong vòng đời phát triển: lỗi trong yêu cầu được đưa vào sớm nhất rồi lan sang thiết kế, mã, tài liệu và ca kiểm thử, nên nếu chỉ phát hiện ở kiểm thử chấp nhận hay khi vận hành thì phải sửa lại mọi sản phẩm dựng trên nó; đó là lý do ISTQB nhấn mạnh kiểm thử sớm và rà soát yêu cầu. "Faults in program specifications are the most expensive to fix" sai vì đặc tả chương trình được viết sau yêu cầu, lỗi ở đó lan qua ít tầng hơn. "Faults in designs are the most expensive to fix." cũng vậy: thiết kế đứng sau yêu cầu nên lỗi thiết kế tốn kém nhưng vẫn ít hơn. "Faults in code are the most expensive to fix." sai vì lỗi mã thường chỉ cần sửa trong mã rồi chạy lại kiểm thử, phạm vi ảnh hưởng hẹp nhất trong bốn loại.

Đáp án đúng: "False". Phát biểu rằng kiểm thử kỹ lưỡng có thể loại bỏ mọi lỗi khỏi chương trình trước khi giao cho khách hàng là sai, vì nó trái với hai nguyên tắc kiểm thử trong ISTQB Foundation. Thứ nhất, kiểm thử cho thấy sự hiện diện của lỗi chứ không chứng minh được không còn lỗi (testing shows presence of defects): dù không tìm thấy lỗi nào, ta cũng không thể kết luận phần mềm đúng hoàn toàn. Thứ hai, kiểm thử vét cạn là bất khả thi (exhaustive testing is impossible): số tổ hợp đầu vào, trạng thái và đường đi quá lớn để thử hết, nên luôn phải chọn mẫu theo rủi ro và ưu tiên. Kiểm thử làm giảm xác suất lỗi còn sót và tăng niềm tin vào chất lượng, nhưng không bảo đảm loại bỏ tất cả. Vì vậy "True" sai: nó đòi hỏi một điều kiểm thử không thể đạt được dù làm kỹ tới đâu.

Đáp án đúng: "Supportability". Chuẩn ISO 9126 về chất lượng sản phẩm phần mềm định nghĩa sáu đặc tính chất lượng: chức năng (functionality), độ tin cậy (reliability), tính khả dụng (usability), hiệu suất (efficiency), khả năng bảo trì (maintainability) và tính khả chuyển (portability). Khả năng hỗ trợ (supportability) không có trong danh sách này; nó là chữ S trong mô hình FURPS của Hewlett-Packard, một cách phân loại khác. "Functionality" là đặc tính thứ nhất của ISO 9126, gồm tính phù hợp, độ chính xác, khả năng tương tác, bảo mật. "Usability" là đặc tính về mức dễ hiểu, dễ học, dễ vận hành. "Maintainability" là đặc tính về mức dễ phân tích, dễ thay đổi, ổn định và dễ kiểm thử của phần mềm. Ba đặc tính này đều thuộc chuẩn nên không phải đáp án.

Đáp án đúng: "Designed by a person from a different organization". ISTQB sắp mức độc lập của kiểm thử từ thấp tới cao: chính tác giả tự kiểm thử, một người khác trong cùng nhóm, một người từ nhóm hay bộ phận khác trong tổ chức, rồi tới người từ tổ chức khác như công ty kiểm thử thuê ngoài hay đơn vị chứng nhận; người ngoài tổ chức ít chịu ảnh hưởng của áp lực nội bộ và thiên kiến của tác giả nhất, nên độc lập cao nhất. "Designed by persons who write the software under test" là mức thấp nhất vì tác giả dễ mù với lỗi của chính mình. "Designed by another person" chỉ là mức độc lập kế tiếp, vẫn có thể cùng nhóm, cùng chịu áp lực tiến độ. "Designed by a person from a different section" độc lập hơn vì khác bộ phận, nhưng vẫn cùng tổ chức nên chưa đạt mức cao nhất.