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

Khái niệm kiểm thử hoàn chỉnh được định nghĩa là quá trình kiểm thử mà trong đó bạn đã kiểm tra tất cả các câu lệnh, nhánh và sự kết hợp của các nhánh trong chương trình. Điều này có nghĩa là bạn đã kiểm tra tất cả các khả năng có thể xảy ra trong chương trình và đảm bảo rằng chương trình hoạt động đúng như mong đợi. Kiểm thử hoàn chỉnh không chỉ đơn giản là kiểm tra mọi thứ mà còn bao gồm cả việc kiểm tra các trường hợp ngoại lệ, các lỗi có thể xảy ra và các điều kiện đặc biệt. Mục tiêu của kiểm thử hoàn chỉnh là đảm bảo rằng chương trình ổn định, hiệu suất cao và đáp ứng được các yêu cầu của người dùng.

Khi nói về sự không thể hoàn toàn kiểm tra một chương trình, có một số hậu quả quan trọng mà chúng ta cần phải xem xét. Thứ nhất, chúng ta không thể chắc chắn rằng chương trình của mình là hoàn toàn không có lỗi. Điều này có nghĩa là, dù chúng ta đã kiểm tra và thử nghiệm chương trình một cách kỹ lưỡng, vẫn có thể tồn tại những lỗi mà chúng ta chưa phát hiện ra. Thứ hai, không có điểm dừng chắc chắn cho quá trình kiểm tra, điều này có thể khiến một số quản lý sử dụng nó như lý do để yêu cầu ít kiểm tra hơn. Cuối cùng, chúng ta không có cách dễ dàng để xác định những nhiệm vụ kiểm tra nào luôn cần thiết, vì mỗi nhiệm vụ đều tốn thời gian và có thể được sử dụng cho những nhiệm vụ quan trọng khác.

Các công cụ và kỹ thuật được sử dụng trong từng bàn làm việc để tạo ra sản phẩm đầu ra đúng. Trong môi trường làm việc, các công cụ và kỹ thuật đóng vai trò quan trọng trong việc đảm bảo chất lượng và hiệu suất công việc. Chúng giúp nhân viên thực hiện các nhiệm vụ một cách hiệu quả và chính xác. Ví dụ, trong một xưởng sản xuất, các công cụ như máy móc, thiết bị và dụng cụ được sử dụng để tạo ra sản phẩm cuối cùng. Cùng với đó, các kỹ thuật như quy trình sản xuất, kiểm tra chất lượng và bảo trì cũng được áp dụng để đảm bảo sản phẩm đạt tiêu chuẩn.

Sự chuyển giao tài liệu kiểm thử (SSSR Handover of Testware) là một phần của giai đoạn phân tích và thiết kế kiểm thử. Trong giai đoạn này, các kỹ sư kiểm thử sẽ phân tích yêu cầu của sản phẩm, xác định các trường hợp kiểm thử và thiết kế kế hoạch kiểm thử. Sự chuyển giao tài liệu kiểm thử là một phần quan trọng của giai đoạn này, vì nó giúp đảm bảo rằng tất cả các bên liên quan đều hiểu rõ về kế hoạch kiểm thử và tài liệu liên quan. Điều này giúp giảm thiểu sự nhầm lẫn và đảm bảo rằng kiểm thử được thực hiện một cách hiệu quả.

SSSR Fault Masking là một kỹ thuật trong lĩnh vực kiểm thử phần mềm, liên quan đến việc che giấu hoặc che đậy lỗi trong chương trình. Nói một cách đơn giản, SSSR Fault Masking là quá trình che giấu một lỗi khác một lỗi khác. Ví dụ, nếu một chương trình có lỗi về việc không thể kết nối đến cơ sở dữ liệu, một lỗi khác có thể được tạo ra để che giấu lỗi này. Điều này có thể giúp phát hiện ra lỗi khác, nhưng cũng có thể khiến việc phát hiện ra lỗi ban đầu trở nên khó khăn hơn. SSSR Fault Masking thường được sử dụng trong các trường hợp khi lỗi không thể được phát hiện bằng các phương pháp kiểm thử thông thường.

Đáp án đúng: "ISO 9126". ISO 9126 là chuẩn quốc tế về chất lượng sản phẩm phần mềm, định nghĩa mô hình sáu đặc tính chất lượng (chức năng, độ tin cậy, khả dụng, hiệu suất, khả năng bảo trì, khả chuyển) kèm các đặc tính con và số đo; sau này nó được thay bằng bộ ISO 25000 (SQuaRE). Các con số ở phương án nhiễu gợi tới những chuẩn IEEE khác chứ không phải chuẩn chất lượng sản phẩm. "ISO 829" mang số của IEEE 829, chuẩn về tài liệu kiểm thử phần mềm như kế hoạch, đặc tả và báo cáo kiểm thử. "ISO 1012" mang số của IEEE 1012, chuẩn về kiểm chứng và thẩm định (verification and validation). "ISO 1028" mang số của IEEE 1028, chuẩn về rà soát phần mềm như thanh tra, walkthrough, rà soát kỹ thuật. Không con số nào trong ba con số này là chuẩn chất lượng sản phẩm phần mềm.

Khi báo cáo lỗi phát hiện cho các nhà phát triển, các kiểm thử viên nên thể hiện sự tôn trọng và chuyên nghiệp. Điều này có nghĩa là họ nên trình bày các lỗi một cách rõ ràng, cụ thể và hữu ích. Họ nên tránh sử dụng ngôn ngữ tiêu cực hoặc gây phẫn nộ, mà thay vào đó, họ nên tập trung vào việc giải quyết vấn đề. Điều này sẽ giúp các nhà phát triển hiểu rõ hơn về lỗi và có thể giải quyết nó một cách hiệu quả hơn. Ngoài ra, các kiểm thử viên cũng nên tránh việc tranh cãi hoặc gây mâu thuẫn với các nhà phát triển, vì điều này có thể gây ra sự bất đồng và làm chậm quá trình phát triển.

Đáp án đúng: "Test data.". ISTQB nói lượng kiểm thử cần làm (how much testing is enough) phụ thuộc vào mức độ rủi ro, gồm rủi ro kỹ thuật, an toàn và kinh doanh, cùng các ràng buộc của dự án như thời gian, ngân sách và yêu cầu hợp đồng, pháp lý. Dữ liệu kiểm thử chỉ là đầu vào dùng để chạy các ca kiểm thử đã quyết định làm, nó được chuẩn bị theo khối lượng kiểm thử chứ không quyết định khối lượng đó. "Risks involved" là yếu tố quyết định quan trọng nhất: chỗ rủi ro cao phải kiểm thử kỹ hơn. "Contractual requirements" quyết định lượng kiểm thử vì hợp đồng có thể ấn định mức độ phủ hay loại kiểm thử bắt buộc. "Legal requirements" cũng vậy: các quy định pháp lý, ví dụ trong ngành y tế, hàng không, buộc phải đạt mức kiểm thử nhất định.

Maintenance releases và các trung tâm hỗ trợ kỹ thuật là những ví dụ về chi phí chất lượng nào? Chi phí chất lượng là những chi phí mà doanh nghiệp bỏ ra để đảm bảo chất lượng sản phẩm hoặc dịch vụ của mình. Trong đó, chi phí ngăn ngừa (Prevention) là những chi phí mà doanh nghiệp bỏ ra để ngăn ngừa các vấn đề chất lượng xảy ra. Maintenance releases và các trung tâm hỗ trợ kỹ thuật là những ví dụ về chi phí ngăn ngừa vì chúng giúp doanh nghiệp sửa lỗi và cải thiện chất lượng sản phẩm hoặc dịch vụ của mình. Điều này giúp doanh nghiệp tránh được các vấn đề chất lượng và giảm thiểu chi phí sửa lỗi sau này.

Bắt đầu thiết kế thử nghiệm trong giai đoạn định nghĩa yêu cầu là rất quan trọng để đạt được các mục tiêu thử nghiệm sau. Khi thiết kế thử nghiệm được bắt đầu từ giai đoạn định nghĩa yêu cầu, nó cho phép các nhà phát triển hiểu rõ hơn về yêu cầu của hệ thống và xác định được các trường hợp thử nghiệm quan trọng. Điều này giúp tăng cường sự tự tin vào hệ thống và đảm bảo rằng hệ thống hoạt động đúng như mong đợi. Ngoài ra, thiết kế thử nghiệm trong giai đoạn định nghĩa yêu cầu cũng giúp giảm thiểu các lỗi trong hệ thống và đảm bảo rằng hệ thống được hoàn thiện một cách đầy đủ.

Các lỗi TF (Faults) được người dùng phát hiện thường là do các nguyên nhân sau: Trước hết, nguyên nhân chính là do phần mềm và quá trình kiểm thử không tốt. Điều này có thể dẫn đến việc lỗi không được phát hiện trong quá trình kiểm thử, từ đó gây ra lỗi khi phần mềm được triển khai. Ngoài ra, một số lỗi TF còn do sự kết hợp của nhiều yếu tố, bao gồm cả yếu tố may mắn. Tuy nhiên, trong thực tế, yếu tố may mắn không phải là nguyên nhân chính gây ra lỗi TF. Vì vậy, để giảm thiểu số lượng lỗi TF, chúng ta cần phải tập trung vào việc phát triển và kiểm thử phần mềm một cách tốt hơn.

Câu hỏi này yêu cầu bạn chọn định nghĩa tốt nhất cho khái niệm Testing. Có bốn lựa chọn khác nhau. Lựa chọn đầu tiên cho rằng mục tiêu của testing là chứng minh chương trình hoạt động. Lựa chọn thứ hai cho rằng mục tiêu của testing là chứng minh chương trình không có lỗi. Lựa chọn thứ ba cho rằng mục tiêu của testing là chứng minh chương trình thực hiện đúng chức năng. Lựa chọn thứ tư cho rằng testing là việc thực thi phần mềm để tìm kiếm lỗi. Trong bốn lựa chọn này, lựa chọn thứ tư là định nghĩa tốt nhất cho khái niệm Testing vì nó tập trung vào việc tìm kiếm lỗi trong phần mềm.

Mục tiêu của một tester phần mềm là tìm kiếm lỗi, tìm kiếm chúng càng sớm càng tốt và đảm bảo chúng được sửa chữa. Điều này giúp tiết kiệm thời gian và chi phí cho quá trình phát triển phần mềm. Khi lỗi được tìm thấy và sửa chữa sớm, nó sẽ giúp cải thiện chất lượng phần mềm và giảm thiểu rủi ro khi đưa sản phẩm ra thị trường. Vì vậy, mục tiêu của một tester phần mềm là tìm kiếm lỗi và đảm bảo chúng được sửa chữa một cách hiệu quả.

Sự cố hệ thống thường xảy ra trong giai đoạn nào? Trong quá trình phát triển phần mềm, giai đoạn yêu cầu (Requirements Phase) là giai đoạn quan trọng và dễ xảy ra sự cố. Đây là giai đoạn nơi các yêu cầu và mục tiêu của dự án được xác định. Nếu không thực hiện đúng, giai đoạn này có thể dẫn đến sự cố hệ thống sau này. Các yêu cầu không rõ ràng, không đầy đủ hoặc không chính xác có thể gây ra sự cố trong giai đoạn thiết kế và phát triển. Do đó, giai đoạn yêu cầu là giai đoạn dễ xảy ra sự cố hệ thống.

Đá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: "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: "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: "Improve software accuracy". Kiểm thử (testing) chỉ đo và phơi bày tình trạng của phần mềm: nó tìm ra khiếm khuyết và cung cấp thông tin, còn việc sửa mã để phần mềm chạy chính xác hơn là gỡ lỗi (debugging) do lập trình viên làm sau đó, nên bản thân việc chạy kiểm thử không làm độ chính xác tăng lên. "Find faults" là mục tiêu kinh điển của kiểm thử, nên kiểm thử chắc chắn giúp được việc này. "Check user friendliness." cũng nằm trong phạm vi kiểm thử, cụ thể là kiểm thử khả dụng (usability testing), một loại kiểm thử phi chức năng. "Assure quality" là chỗ dễ tranh cãi nhất: có quan điểm cho rằng chất lượng không thể kiểm thử mà ra (quality cannot be tested in), nên nói kiểm thử không đảm bảo được chất lượng cũng có lý; tuy vậy trong khung ISTQB kiểm thử được xếp là một hoạt động của đảm bảo chất lượng (quality assurance), giúp đánh giá và tạo niềm tin vào chất lượng, nên thứ kiểm thử rõ ràng không tự làm được vẫn là cải thiện độ chính xác, việc chỉ đạt được qua sửa lỗi.

Đáp án đúng: "Test Implementation and execution". Trong quy trình kiểm thử cơ bản (fundamental test process) của ISTQB, giai đoạn thực hiện và thực thi kiểm thử gồm tạo dữ liệu và bộ kiểm thử, chạy ca kiểm thử, ghi nhật ký, so sánh kết quả thực tế với kết quả mong đợi, báo cáo các sai khác (discrepancies) thành sự cố (incident) rồi kiểm thử lại sau khi sửa; sai khác được báo ngay lúc phát hiện nên việc này thuộc giai đoạn đó. "Test Analysis and Design" là giai đoạn 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ử, lúc đó chưa chạy gì nên chưa có sai khác để báo. "Evaluating exit criteria and reporting" đối chiếu nhật ký kiểm thử với tiêu chí kết thúc và viết báo cáo tổng hợp cho bên liên quan, không phải nơi ghi từng sự cố. "Test Closure Activities" là khâu đóng: kiểm tra sản phẩm bàn giao, lưu trữ testware, rút kinh nghiệm, diễn ra sau khi việc thực thi đã xong.

Đáp án đúng: "Procedure". Trong quản lý chất lượng, thủ tục (procedure) là chuỗi bước cụ thể, làm lần lượt từng bước một, mô tả cách thực hiện một công việc để bảo đảm các chuẩn (standards) được đáp ứng; chuẩn nói cái gì phải đạt, thủ tục nói làm thế nào để đạt. "SDLC" là vòng đời phát triển phần mềm, mô tả các giai đoạn phát triển ở mức tổng thể chứ không phải hướng dẫn từng bước để tuân thủ một chuẩn. "Project Plan" (kế hoạch dự án) xác định phạm vi, lịch, nguồn lực và rủi ro của một dự án, không phải phương pháp từng bước lặp lại được. "Policy" (chính sách) là tuyên bố định hướng ở cấp quản lý, nói tổ chức cam kết điều gì và vì sao; chính sách được hiện thực hoá bằng chuẩn và thủ tục chứ bản thân nó không gồm các bước thực hiện.