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

Đáp án đúng: "False". Phát biểu mô tả việc so sánh chất lượng sản phẩm với tiêu chuẩn áp dụng và hành động khi phát hiện không phù hợp; đó là định nghĩa của kiểm soát chất lượng (Quality Control) theo QAI, hoạt động hướng vào sản phẩm, mang tính phát hiện. Đảm bảo chất lượng (Quality Assurance) là hoạt động phòng ngừa ở cấp quy trình: thiết lập và cải tiến quy trình, tiêu chuẩn để sản phẩm làm ra đạt chất lượng ngay từ đầu. Nhiều tài liệu ôn tập chép nhau ghi phát biểu này là đúng vì gộp hai khái niệm làm một, nhưng chính chỗ gán định nghĩa QC cho QA là chỗ sai của phát biểu. "True" vì vậy không được chọn: nó chấp nhận sự nhầm lẫn giữa QA phòng ngừa và QC phát hiện mà khung chất lượng phân biệt rõ.

Đáp án đúng: "Exhaustive testing". ISTQB Foundation nêu bảy nguyên tắc kiểm thử (testing principles), trong đó có nguyên tắc "exhaustive testing is impossible": kiểm thử vét cạn mọi tổ hợp đầu vào và điều kiện tiền đề là bất khả thi trừ ca rất tầm thường, nên phải dùng phân tích rủi ro và mức ưu tiên để khoanh vùng. Bản thân "Exhaustive testing" (kiểm thử vét cạn) vì vậy không phải nguyên tắc mà là điều nguyên tắc phủ nhận. "Early testing" (kiểm thử sớm) là nguyên tắc thật: bắt đầu kiểm thử càng sớm càng tốt trong vòng đời để lỗi được phát hiện khi sửa còn rẻ. "Defect clustering" (lỗi tập trung theo cụm) là nguyên tắc thật: phần lớn lỗi nằm trong một số ít mô-đun. "Pesticide paradox" (nghịch lý thuốc trừ sâu) cũng là nguyên tắc thật: chạy lặp lại cùng một bộ ca kiểm thử sẽ dần không tìm thêm lỗi mới, nên phải rà soát và bổ sung ca kiểm thử thường xuyên.

Đáp án đúng: "Implementation and execution.". Trong quy trình kiểm thử cơ bản của ISTQB, giai đoạn thực hiện và thực thi bắt đầu bằng việc hoàn thiện ca kiểm thử thành thủ tục kiểm thử (test procedure), chuẩn bị dữ liệu, viết kịch bản tự động và gom các thủ tục thành bộ kiểm thử (test suite) để thực thi hiệu quả, sau đó mới chạy và ghi kết quả. "Planning and control." xác định mục tiêu, phạm vi, cách tiếp cận, nguồn lực và theo dõi tiến độ, lúc đó chưa có ca kiểm thử cụ thể nào để gom. "Analysis and design." rà soát cơ sở kiểm thử, xác định điều kiện kiểm thử, thiết kế ca kiểm thử mức cao và môi trường kiểm thử, còn việc xếp chúng thành bộ để chạy diễn ra ở bước sau. "Test closure." diễn ra khi đã kiểm thử xong: kiểm tra sản phẩm bàn giao, lưu trữ testware, rút kinh nghiệm.

Đáp án đúng: "Test Closure Activities". Theo quy trình kiểm thử cơ bản của ISTQB Foundation, hoạt động đóng kiểm thử (test closure activities) gồm kiểm tra sản phẩm bàn giao đã đủ chưa, đóng báo cáo sự cố, lập tài liệu chấp nhận hệ thống, hoàn thiện và lưu trữ testware, bàn giao testware cho bộ phận bảo trì (handover of testware), và rút kinh nghiệm cho các dự án sau. Bàn giao testware nằm đúng ở giai đoạn này vì chỉ diễn ra khi kiểm thử đã kết thúc. "Test Analysis and Design" là lúc rà soát cơ sở kiểm thử, xác định điều kiện kiểm thử và thiết kế ca kiểm thử. "Test Planning and control" là lúc xác định mục tiêu, phạm vi, cách tiếp cận và theo dõi tiến độ, điều chỉnh khi lệch kế hoạch. "Evaluating exit criteria and reporting" là lúc so kết quả thực thi với tiêu chí thoát và viết báo cáo tóm tắt, chưa phải lúc bàn giao.

Đáp án đúng: "Test Analysis and Design". Trong quy trình kiểm thử cơ bản (Fundamental Test Process) của ISTQB, nhiệm vụ đầu tiên của pha phân tích và thiết kế kiểm thử là rà soát cơ sở kiểm thử (test basis) như yêu cầu, kiến trúc, thiết kế, giao diện, đánh giá khả năng kiểm thử của chúng, rồi xác định điều kiện kiểm thử và thiết kế ca kiểm thử. "Test Implementation and execution" diễn ra sau đó, khi ca kiểm thử đã có: xây quy trình kiểm thử, chuẩn bị dữ liệu, môi trường, chạy kiểm thử và ghi kết quả. "Test Closure Activities" là pha kết thúc: lưu trữ testware, bàn giao, rút kinh nghiệm, không quay lại đọc cơ sở kiểm thử. "Evaluating exit criteria and reporting" là đối chiếu kết quả chạy với tiêu chí thoát và viết báo cáo tổng kết, cũng không phải lúc rà soát tài liệu đầu vào.

Đá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: "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: "To give information for a risk based decision about release". Theo ISTQB, kiểm thử không chứng minh được phần mềm hết lỗi; giá trị chính của nó trước khi phát hành là cung cấp thông tin về chất lượng và mức rủi ro còn lại để người có thẩm quyền (chủ sản phẩm, quản lý) ra quyết định phát hành dựa trên rủi ro. "To show that system will work after release" sai vì kiểm thử chỉ cho thấy sự có mặt của lỗi chứ không chứng minh được hệ thống chắc chắn chạy đúng. "To decide when the software is of sufficient quality to release" sai vì quyết định phát hành thuộc về bên liên quan; kiểm thử cung cấp dữ liệu cho quyết định đó chứ không tự quyết. "To find as many bugs as possible before release" là một mục tiêu của kiểm thử nhưng không phải lý do chính trước phát hành: tìm thật nhiều lỗi vẫn không cho biết rủi ro còn lại có chấp nhận được hay không, và kiểm thử vét cạn là không thể.

Việc kiểm tra sớm trong quá trình phát triển phần mềm mang lại nhiều lợi ích. Khi phát hiện lỗi sớm, các nhà phát triển có thể sửa lỗi một cách nhanh chóng và hiệu quả hơn. Điều này giúp giảm thiểu thời gian và chi phí cần thiết để sửa lỗi. Ngoài ra, việc kiểm tra sớm cũng giúp đảm bảo chất lượng của phần mềm và giảm thiểu rủi ro phát sinh lỗi trong quá trình sử dụng. Điều này giúp tăng cường sự tin tưởng của khách hàng và cải thiện uy tín của công ty.

Trong giai đoạn đánh giá các tiêu chí thoát và báo cáo, mục tiêu chính là đưa ra quyết định liên quan đến việc tiếp tục hoặc dừng thử nghiệm phần mềm. Điều này đòi hỏi phải đánh giá kỹ lưỡng các tiêu chí thoát đã được thiết lập và đảm bảo rằng chúng phù hợp với mục tiêu thử nghiệm. Sau khi đánh giá, các nhà phát triển và quản lý dự án cần phải đưa ra quyết định về việc liệu phần mềm đã sẵn sàng để được phát hành hay cần phải tiếp tục thử nghiệm. Nếu phần mềm đã sẵn sàng, thì giai đoạn thử nghiệm sẽ được kết thúc và phần mềm sẽ được phát hành. Ngược lại, nếu phần mềm cần phải tiếp tục thử nghiệm, thì giai đoạn thử nghiệm sẽ được tiếp tục cho đến khi phần mềm đã sẵn sàng.

Để cải thiện chất lượng phần mềm, cách hiệu quả nhất để sử dụng thử nghiệm là tập trung vào các khu vực của phần mềm có khả năng có lỗi cao. Điều này có nghĩa là bạn nên ưu tiên thử nghiệm các khu vực có nhiều khả năng xảy ra lỗi, chẳng hạn như các chức năng phức tạp hoặc các khu vực có lịch sử lỗi. Bằng cách tập trung vào các khu vực này, bạn có thể phát hiện và sửa lỗi sớm, từ đó cải thiện chất lượng phần mềm. Ngoài ra, việc thử nghiệm này cũng giúp bạn tiết kiệm thời gian và nguồn lực, vì bạn không cần phải thử nghiệm toàn bộ phần mềm.

Khi hiểu được các yếu tố tâm lý trong quá trình kiểm thử, nó giúp tăng cường tương tác và hiệu quả của nhóm kiểm thử. Điều này có nghĩa là các thành viên trong nhóm có thể hiểu rõ được những yếu tố tâm lý ảnh hưởng đến quá trình kiểm thử, từ đó có thể điều chỉnh và tối ưu hóa quá trình kiểm thử để đạt được kết quả tốt nhất. Điều này cũng giúp tăng cường sự hợp tác và giao tiếp giữa các thành viên trong nhóm, từ đó giúp nâng cao hiệu quả của quá trình kiểm thử.

Để duy trì mối quan hệ tốt giữa các tester và developer, chúng ta cần chọn phương pháp phù hợp. Phương pháp đầu tiên, "Giảm thiểu sự tương tác giữa tester và developer", không phải là lựa chọn tốt vì sự tương tác giữa các thành viên trong nhóm là cần thiết để đảm bảo chất lượng sản phẩm. Phương pháp thứ hai, "Khuyến khích cạnh tranh trong việc tìm kiếm lỗi", cũng không phải là lựa chọn tốt vì nó có thể tạo ra môi trường cạnh tranh không lành mạnh và không khuyến khích sự hợp tác. Phương pháp thứ ba, "Cung cấp phản hồi xây dựng về lỗi", là lựa chọn tốt nhất vì nó giúp các tester và developer hiểu rõ về lỗi và cách khắc phục nó. Phương pháp này giúp xây dựng mối quan hệ tốt giữa các thành viên trong nhóm và đảm bảo chất lượng sản phẩm.

Môi trường thử nghiệm được thiết lập bao gồm trong thực hiện thử nghiệm vì lý do rất quan trọng. Trước khi thực hiện thử nghiệm, môi trường thử nghiệm cần được chuẩn bị sẵn sàng để đảm bảo rằng tất cả các yếu tố cần thiết cho thử nghiệm đều sẵn có. Điều này bao gồm cả phần cứng, phần mềm và các tài nguyên khác cần thiết để thực hiện thử nghiệm. Nếu môi trường thử nghiệm không được chuẩn bị sẵn sàng, nó có thể dẫn đến sự thất bại của thử nghiệm hoặc thậm chí là ảnh hưởng đến kết quả thử nghiệm. Vì vậy, việc thiết lập môi trường thử nghiệm là một phần quan trọng của thực hiện thử nghiệm và cần được thực hiện trước khi bắt đầu thử nghiệm.

Pesticide Paradox là một khái niệm trong lĩnh vực kiểm thử phần mềm. Nó mô tả tình huống khi các thử nghiệm được lặp lại nhiều lần trong thời gian dài, nhưng lại phát hiện ra ít vấn đề hơn. Điều này có thể xảy ra do các vấn đề thường tập trung ở các mô-đun cụ thể, và việc lặp lại các thử nghiệm giống nhau không thể phát hiện ra được những vấn đề này. Ngoài ra, việc thử nghiệm tất cả các kết hợp là không thể, vì số lượng kết hợp có thể rất lớn. Vì vậy, Pesticide Paradox là một thách thức trong việc kiểm thử phần mềm, đòi hỏi phải có chiến lược thử nghiệm hiệu quả để phát hiện ra được các vấn đề.

Thử nghiệm toàn diện là thử nghiệm tất cả các trường hợp có thể xảy ra của một phần mềm. Tuy nhiên, thử nghiệm toàn diện là không thể thực hiện được, đặc biệt là khi phần mềm có nhiều tính năng và yêu cầu phức tạp. Điều này là vì số lượng các trường hợp thử nghiệm có thể xảy ra là vô cùng lớn, và không thể thử nghiệm tất cả chúng. Thay vào đó, chúng ta sử dụng rủi ro và ưu tiên để tập trung vào các trường hợp thử nghiệm quan trọng nhất. Ngoài ra, thử nghiệm có thể chỉ ra rằng các lỗi đã tồn tại, nhưng không thể chứng minh rằng không có lỗi nào tồn tại. Thử nghiệm chỉ giảm thiểu khả năng tồn tại các lỗi chưa được phát hiện trong phần mềm, nhưng ngay cả khi không tìm thấy lỗi nào, cũng không thể chứng minh được rằng phần mềm là chính xác.

Early testing là một phần quan trọng trong vòng đời phát triển phần mềm. Nó giúp bắt đầu các hoạt động kiểm tra sớm nhất có thể trong vòng đời phát triển phần mềm và tập trung vào các mục tiêu được xác định rõ ràng. Điều này cho phép phát hiện và sửa lỗi sớm, giảm thiểu rủi ro và tăng cường chất lượng phần mềm. Early testing cũng giúp đảm bảo rằng phần mềm đáp ứng được nhu cầu và kỳ vọng của người dùng. Nó không chỉ giúp phát hiện lỗi mà còn giúp xác định xem phần mềm có đáp ứng được yêu cầu của người dùng hay không. Vì vậy, Early testing là một phần quan trọng trong vòng đời phát triển phần mềm và giúp đảm bảo rằng phần mềm được phát triển là chất lượng cao và đáp ứng được nhu cầu của người dùng.

Hoạt động đóng test trong một dự án phần mềm có mục đích đánh giá và phân tích kết quả của quá trình kiểm thử. Mục đích chính là phân tích những gì đã được thực hiện và những gì có thể được cải thiện cho các dự án tương lai. Điều này giúp các nhà phát triển và quản lý dự án nhận ra những điểm mạnh và điểm yếu của quá trình kiểm thử, từ đó có thể điều chỉnh và cải thiện quy trình kiểm thử cho các dự án tiếp theo. Ngoài ra, hoạt động đóng test cũng giúp xác định những gì đã đạt được và những gì còn cần cải thiện, giúp cho việc lập kế hoạch và quản lý dự án trở nên hiệu quả hơn.

Khi chúng ta kiểm tra hoặc đánh giá một sản phẩm, mục tiêu chính là tìm kiếm các lỗi hoặc khuyết tật trong sản phẩm. Điều này có nghĩa là chúng ta sẽ đánh giá sản phẩm một cách nghiêm ngặt và tìm kiếm các điểm yếu hoặc vấn đề cần cải thiện. Việc này giúp chúng ta hiểu rõ hơn về sản phẩm và có thể đưa ra các đề xuất hoặc giải pháp để khắc phục các lỗi hoặc khuyết tật đó. Mục tiêu của việc kiểm tra hoặc đánh giá sản phẩm là đảm bảo rằng sản phẩm đáp ứng được các yêu cầu và tiêu chuẩn đã được đặt ra.

Trong ngữ cảnh của kiểm thử, từ 'failure' thường được hiểu là một lỗi hoặc một điểm yếu trong phần mềm được phát hiện trong quá trình kiểm thử. Nó không chỉ giới hạn ở một lỗi được tạo ra bởi nhà phát triển, mà còn bao gồm cả những điểm yếu hoặc lỗi trong thiết kế phần mềm. Lỗi này có thể được phát hiện trong quá trình kiểm thử đơn vị, kiểm thử tích hợp hoặc kiểm thử hệ thống. Khi một lỗi được phát hiện, nó sẽ được coi là một trường hợp 'failure' và sẽ được xử lý để đảm bảo rằng phần mềm hoạt động đúng và đáp ứng được các yêu cầu của người dùng.