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

Trong nguyên tắc kiểm thử, ngữ cảnh đóng vai trò quan trọng. Nó chỉ ra rằng các phương pháp kiểm thử nên thay đổi dựa trên ngữ cảnh cụ thể. Điều này có nghĩa là, khi kiểm thử một sản phẩm hoặc hệ thống, chúng ta cần xem xét ngữ cảnh mà sản phẩm hoặc hệ thống đó sẽ được sử dụng. Ví dụ, một ứng dụng di động có thể cần được kiểm thử trên các thiết bị di động khác nhau, trong khi một ứng dụng web có thể cần được kiểm thử trên các trình duyệt khác nhau. Ngữ cảnh giúp chúng ta xác định các yêu cầu và điều kiện kiểm thử cụ thể, từ đó đảm bảo rằng sản phẩm hoặc hệ thống đáp ứng được nhu cầu của người dùng.

Kết quả kiểm thử cho thấy sự hiện diện của các lỗi. Kiểm thử có thể cho thấy các lỗi đang tồn tại, nhưng không thể chứng minh rằng không có lỗi nào. Kiểm thử giảm khả năng có các lỗi chưa được phát hiện còn tồn tại trong phần mềm, nhưng ngay cả khi không tìm thấy lỗi nào, nó không phải là bằng chứng về sự chính xác. Kiểm thử không thể chứng minh rằng phần mềm hoàn toàn không có lỗi, nhưng nó có thể giúp giảm thiểu số lượng lỗi còn tồn tại. Điều này có nghĩa là, ngay cả khi phần mềm đã được kiểm thử kỹ lưỡng, vẫn có thể có các lỗi chưa được phát hiện. Vì vậy, kiểm thử không phải là một công cụ để chứng minh sự chính xác của phần mềm, mà là một công cụ để giảm thiểu số lượng lỗi và đảm bảo rằng phần mềm hoạt động đúng như mong đợi.

Mục đích chính của việc kiểm thử phần mềm là xác định các lỗi trong phần mềm. Khi phần mềm được phát triển, các lỗi thường không được phát hiện ngay lập tức. Kiểm thử phần mềm giúp phát hiện ra các lỗi này, từ đó giúp nhà phát triển sửa lỗi và cải thiện chất lượng phần mềm. Việc kiểm thử phần mềm cũng giúp đảm bảo rằng phần mềm hoạt động đúng như mong đợi, giảm thiểu rủi ro khi triển khai phần mềm vào sản xuất.

Câu hỏi này hỏi về mức độ đủ của việc kiểm thử. Có ba lựa chọn: Kiểm thử đầy đủ là có thể, Kiểm thử mọi thứ (tất cả các kết hợp của đầu vào và điều kiện tiền đề), Sử dụng rủi ro và ưu tiên để tập trung vào nỗ lực kiểm thử. Tuy nhiên, trong thực tế, kiểm thử đầy đủ không phải lúc nào cũng có thể thực hiện được do chi phí và thời gian cao. Vì vậy, lựa chọn đúng là Sử dụng rủi ro và ưu tiên để tập trung vào nỗ lực kiểm thử. Điều này có nghĩa là chúng ta sẽ tập trung vào các trường hợp kiểm thử quan trọng nhất dựa trên mức độ rủi ro và ưu tiên của chúng. Điều này giúp chúng ta tối ưu hóa thời gian và nguồn lực cho việc kiểm thử.

Khi giao tiếp giữa các tester và nhà phát triển không tốt, có thể dẫn đến hiểu lầm và giảm chất lượng phần mềm. Điều này xảy ra khi các tester và nhà phát triển không thể hiểu rõ được yêu cầu và mục tiêu của nhau, dẫn đến việc phát triển phần mềm không đúng như mong đợi. Ngoài ra, giao tiếp kém cũng có thể dẫn đến việc chậm trễ trong quá trình phát triển và thử nghiệm, gây ra sự lãng phí thời gian và nguồn lực. Vì vậy, giao tiếp hiệu quả giữa các tester và nhà phát triển là rất quan trọng để đảm bảo chất lượng phần mềm và giảm thiểu các vấn đề phát sinh.

Để giảm thiểu xung đột tâm lý giữa các tester và developer, chúng ta có thể áp dụng các chiến lược sau đây. Trước hết, chúng ta cần tạo ra một môi trường làm việc tích cực, nơi mà cả tester và developer đều được tôn trọng và đánh giá cao. Điều này có thể được thực hiện thông qua việc tạo ra một văn hóa làm việc thân thiện và tôn trọng lẫn nhau. Thứ hai, chúng ta cần đảm bảo rằng mục tiêu và yêu cầu của quá trình kiểm thử được rõ ràng và dễ hiểu. Điều này sẽ giúp giảm thiểu sự nhầm lẫn và xung đột giữa các bên. Cuối cùng, chúng ta cần khuyến khích sự hợp tác và làm việc cùng nhau trong việc giải quyết các lỗi và vấn đề. Điều này sẽ giúp tăng cường sự hiểu biết và tôn trọng lẫn nhau giữa các tester và developer.

Dynamic testing là một phương pháp kiểm thử phần mềm, trong đó phần mềm được thực hiện (chạy) với một bộ giá trị đầu vào và kết quả được kiểm tra và so sánh với kết quả mong đợi. Phương pháp này cho phép phát hiện ra các lỗi hoặc vấn đề trong phần mềm một cách nhanh chóng và hiệu quả. Trong dynamic testing, phần mềm được chạy với các trường hợp thử nghiệm khác nhau, bao gồm các giá trị đầu vào khác nhau, các điều kiện ngoại lệ, và các tình huống sử dụng thực tế. Kết quả của phần mềm được so sánh với kết quả mong đợi để xác định xem phần mềm hoạt động đúng hay không. Phương pháp này giúp phát hiện ra các lỗi hoặc vấn đề trong phần mềm một cách nhanh chóng và hiệu quả, từ đó giúp cải thiện chất lượng phần mềm.

Đá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ố.

Các phương pháp trả lời là IL. Phương pháp nào không phải là nguyên tắc kiểm thử là: Trong kiểm thử phần mềm, có nhiều nguyên tắc được áp dụng để đảm bảo chất lượng của sản phẩm. Các nguyên tắc này bao gồm Early testing (Kiểm thử sớm), Defect clustering (Tập trung lỗi), Pesticide paradox (Paradox thuốc trừ sâu) và Exhaustive testing (Kiểm thử đầy đủ). Tuy nhiên, trong số các phương pháp này, Exhaustive testing không phải là một nguyên tắc kiểm thử. Nguyên tắc này đề cập đến việc kiểm thử tất cả các khả năng của sản phẩm, điều này không thể thực hiện được trong thực tế do số lượng khả năng quá lớn. Nguyên tắc kiểm thử thực sự bao gồm Early testing, Defect clustering và Pesticide paradox. Early testing đề cập đến việc kiểm thử sớm trong quá trình phát triển phần mềm để phát hiện và sửa lỗi sớm. Defect clustering đề cập đến việc tập trung lỗi vào các khu vực cụ thể của sản phẩm. Pesticide paradox đề cập đến việc việc kiểm thử trở nên hiệu quả hơn khi sử dụng các công cụ và kỹ thuật kiểm thử khác nhau.

Khi thiết kế thử nghiệm sớm trong chu kỳ sống của sản phẩm, lợi ích chính là ngăn chặn các lỗi được đưa vào mã nguồn. Việc này giúp giảm thiểu đáng kể số lượng lỗi cần phải sửa chữa trong quá trình thử nghiệm sau này. Thiết kế thử nghiệm sớm cũng cho phép phát hiện và sửa chữa các lỗi ngay từ đầu, giúp tiết kiệm thời gian và công sức trong quá trình thử nghiệm. Ngoài ra, thiết kế thử nghiệm sớm còn giúp đảm bảo rằng sản phẩm đáp ứng được các yêu cầu và tiêu chuẩn của khách hàng, từ đó tăng cường độ tin cậy và chất lượng của sản phẩm.

Có nhiều loại kiểm thử trong quá trình phát triển phần mềm. Kiểm thử thành phần (Component testing) và kiểm thử hệ thống (System testing) là hai loại kiểm thử quan trọng. Kiểm thử thành phần thường được thực hiện bằng cách kiểm thử hộp đen (Black box), trong khi kiểm thử hệ thống thường được thực hiện bằng cách kiểm thử hộp trắng (White box). Điều này có nghĩa là kiểm thử thành phần tập trung vào việc kiểm thử các thành phần riêng lẻ của phần mềm, trong khi kiểm thử hệ thống tập trung vào việc kiểm thử toàn bộ hệ thống phần mềm. Ngoài ra, nếu bạn tìm thấy nhiều lỗi trong quá trình kiểm thử, điều đó không có nghĩa là phần mềm không tốt. Thay vào đó, nó có nghĩa là phần mềm cần được cải thiện thêm. Tương tự, số lượng lỗi ít hơn không phải là dấu hiệu tốt nhất cho quá trình kiểm thử. Điều quan trọng là phải chạy nhiều thử nghiệm để đảm bảo phần mềm hoạt động đúng cách. Vì vậy, câu trả lời đúng là "The fewer bugs you find, the better your testing was" không hoàn toàn chính xác.

Phân tích thử nghiệm phần mềm thường chiếm khoảng 5-10% chi phí phát triển phần mềm. Điều này có thể khác nhau tùy thuộc vào quy mô dự án và mức độ phức tạp của phần mềm. Tuy nhiên, trong nhiều trường hợp, việc thử nghiệm phần mềm được coi là một phần quan trọng của quá trình phát triển phần mềm và thường chiếm một tỷ lệ nhỏ so với tổng chi phí phát triển. Việc thử nghiệm phần mềm giúp đảm bảo chất lượng phần mềm, phát hiện và sửa lỗi sớm, từ đó tiết kiệm thời gian và chi phí trong dài hạn.

Đáp án đúng: "Reporting discrepancies as incidents.". Thực hiện và thực thi kiểm thử (test implementation and execution) là giai đoạn hoàn thiện thủ tục 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, và khi có sai khác thì báo cáo thành sự cố (incident) để phân tích nguyên nhân; đó là nhiệm vụ chính của giai đoạn này theo quy trình kiểm thử cơ bản của ISTQB. "Measuring and analyzing results." thuộc lập kế hoạch và điều khiển kiểm thử, nơi người quản lý đo tiến độ và phân tích kết quả để điều chỉnh kế hoạch. "Identifying test conditions or test requirements." thuộc phân tích và thiết kế kiểm thử, diễn ra trước khi có ca kiểm thử để chạy. "Assessing if more tests are needed." thuộc giai đoạn đánh giá tiêu chí kết thúc và báo cáo, khi đối chiếu kết quả với tiêu chí để quyết định có cần kiểm thử thêm không.

Hoạt động đóng gói thử nghiệm là một phần quan trọng của chu trình phát triển phần mềm. Trong hoạt động này, các kỹ sư phần mềm sẽ thực hiện các bước để đảm bảo rằng sản phẩm đã được kiểm tra và thử nghiệm một cách đầy đủ. Các hoạt động đóng gói thử nghiệm bao gồm: - i. Xác định các yêu cầu đóng gói thử nghiệm: Đây là bước đầu tiên trong hoạt động đóng gói thử nghiệm, trong đó các kỹ sư phần mềm sẽ xác định các yêu cầu cần thiết để đóng gói sản phẩm. - ii. Xây dựng kế hoạch đóng gói thử nghiệm: Sau khi xác định các yêu cầu đóng gói thử nghiệm, các kỹ sư phần mềm sẽ xây dựng kế hoạch để thực hiện các hoạt động đóng gói thử nghiệm. - iii. Thực hiện hoạt động đóng gói thử nghiệm: Đây là bước thực hiện các hoạt động đóng gói thử nghiệm theo kế hoạch đã xây dựng. - iv. Đánh giá và cải thiện hoạt động đóng gói thử nghiệm: Cuối cùng, các kỹ sư phần mềm sẽ đánh giá và cải thiện hoạt động đóng gói thử nghiệm để đảm bảo rằng sản phẩm đã được kiểm tra và thử nghiệm một cách đầy đủ. Vì vậy, câu trả lời đúng là "i, ii, iv are true và iii là false".

Khi một người đang thống trị cuộc họp cải tiến quy trình phần mềm, người dẫn cuộc họp cần sử dụng các kỹ thuật phù hợp để khuyến khích các thành viên khác tham gia thảo luận. Kỹ thuật phù hợp trong trường hợp này là chuyển chủ đề sang vấn đề mà người đó không có ý kiến mạnh mẽ. Điều này cho phép người dẫn cuộc họp tạo cơ hội cho các thành viên khác thể hiện ý kiến của mình, đồng thời giúp ngăn chặn việc một người duy trì quyền kiểm soát cuộc họp. Bằng cách chuyển chủ đề, người dẫn cuộc họp có thể tạo ra một môi trường thảo luận tích cực và đa dạng, nơi mà mọi người đều có cơ hội thể hiện ý kiến của mình.

Chất lượng phần mềm không liên quan đến việc trả lời câu hỏi này vì phần mềm chất lượng cao không nhất thiết phải có tính đúng đắn. Tuy nhiên, tính đúng đắn là một yếu tố quan trọng trong việc đảm bảo phần mềm hoạt động đúng như mong đợi. Tính khả dụng và tính tái sử dụng cũng là những yếu tố quan trọng trong việc đánh giá chất lượng phần mềm. Tính khả dụng liên quan đến khả năng sử dụng phần mềm một cách dễ dàng và hiệu quả, trong khi tính tái sử dụng liên quan đến khả năng sử dụng lại phần mềm trong các dự án khác. Tính khả dụng và tính tái sử dụng là những yếu tố quan trọng trong việc đảm bảo phần mềm có thể được sử dụng rộng rãi và hiệu quả.

Fault Masking là một kỹ thuật trong kiểm thử phần mềm, liên quan đến việc che giấu hoặc ẩn đi lỗi trong hệ thống. Trong câu hỏi này, chúng ta đang được hỏi về định nghĩa của Fault Masking. Câu trả lời đúng là "Error condition hiding another error condition", có nghĩa là việc che giấu một lỗi khác. Điều này có thể xảy ra khi một lỗi được ẩn đi bởi một lỗi khác, khiến cho lỗi ban đầu không được phát hiện. Ví dụ, một lỗi về dữ liệu có thể được che giấu bởi một lỗi về giao diện người dùng. Fault Masking có thể xảy ra do nhiều nguyên nhân, bao gồm cả lỗi của nhà phát triển và lỗi của người kiểm thử. Tuy nhiên, mục tiêu của Fault Masking là để đảm bảo rằng hệ thống hoạt động đúng và không bị lỗi.

Đáp án đúng: "Lack of Objectivity". ISTQB Foundation nhấn mạnh tâm lý học kiểm thử: người viết ra sản phẩm thường mang sẵn giả định về cách nó hoạt động và có tâm lý muốn chứng minh nó đúng, nên khó nhìn ra lỗi của chính mình. Sự thiếu khách quan (lack of objectivity) này là lý do chính để cần kiểm thử độc lập (independent testing). "Lack of technical documentation" không phải lý do then chốt, vì chính lập trình viên là người hiểu mã rõ nhất, thiếu tài liệu ảnh hưởng tới người khác nhiều hơn tới họ. "Lack of test tools on the market for developers" sai vì có rất nhiều công cụ cho lập trình viên như khung kiểm thử đơn vị, công cụ đo độ phủ. "Lack of training" có thể xảy ra ở từng người nhưng không phải nguyên nhân cốt lõi, vì kể cả lập trình viên được đào tạo kiểm thử tốt vẫn bị điểm mù khi tự kiểm thử sản phẩm của mình.

Các phương pháp trả lời được sử dụng trong các bàn làm việc cá nhân để sản xuất các sản phẩm đầu ra đúng. Các phương pháp này giúp đảm bảo rằng các sản phẩm đầu ra được tạo ra một cách chính xác và hiệu quả. Ví dụ, các công cụ và kỹ thuật được sử dụng để thực hiện các tác vụ cụ thể, trong khi các thủ tục và tiêu chuẩn được sử dụng để đảm bảo rằng các tác vụ được thực hiện theo đúng quy trình. Các quá trình và kiểm tra được sử dụng để đảm bảo rằng các sản phẩm đầu ra đáp ứng các yêu cầu và tiêu chuẩn. Cuối cùng, các đánh giá và cập nhật được sử dụng để đánh giá và cải thiện các phương pháp trả lời.

Hoạt động nào trong quá trình thử nghiệm cơ bản tạo ra bộ thử nghiệm để thực hiện thử nghiệm một cách hiệu quả? Trong quá trình thử nghiệm cơ bản, có bốn hoạt động chính: Planning và Control, Analysis và Design, Implementation và Execution, Test Closure. Trong đó, Analysis và Design là hoạt động tạo ra bộ thử nghiệm để thực hiện thử nghiệm một cách hiệu quả. Hoạt động này bao gồm việc phân tích yêu cầu của sản phẩm, thiết kế bộ thử nghiệm và xác định các trường hợp thử nghiệm cần thực hiện.