Câu hỏi: SWT301 - Phần 5: Quản lý kiểm thử

Đáp án đúng: "None of the others". Theo mô hình quản lý lỗi của QAI, quy trình quản lý lỗi (defect management process) gồm các bước phòng ngừa lỗi (defect prevention), thiết lập đường cơ sở cho sản phẩm bàn giao (deliverable baselining), phát hiện lỗi (defect discovery), giải quyết lỗi (defect resolution), cải tiến quy trình (process improvement) và báo cáo quản lý (management reporting); cả ba mục được nêu đều nằm trong quy trình nên không có mục nào bị loại. Chỗ dễ tranh cãi là "Deliverable base-lining": nhiều tài liệu ôn tập chọn nó vì nghe giống việc quản lý cấu hình, nhưng trong mô hình này nó là một bước chính thức, xác định thời điểm một sản phẩm được coi là hoàn tất để từ đó mọi sai lệch mới tính là lỗi. "Defect prevention" thuộc quy trình vì là bước đầu, giảm rủi ro lỗi xuất hiện. "Management reporting" thuộc quy trình vì là bước cuối, đưa số liệu lỗi lên quản lý để ra quyết định.

Đáp án đúng: "i, ii and iv.". Theo ISTQB Foundation, quản lý cấu hình (configuration management) phục vụ kiểm thử ở chỗ giúp xác định duy nhất, kiểm soát phiên bản và theo dõi thay đổi của mọi hạng mục: phần mềm được kiểm (nhờ đó biết đang kiểm phiên bản nào, mục i) và testware như kế hoạch, ca kiểm thử, kịch bản, dữ liệu (kiểm soát phiên bản ở mục ii, theo dõi thay đổi ở mục iv), để kết quả kiểm thử truy vết được về đúng phiên bản. Mục iii, phát triển testware mới, là việc thiết kế và hiện thực kiểm thử; mục v, phân tích nhu cầu testware mới, là việc phân tích và lập kế hoạch kiểm thử; cả hai không phải mục đích của quản lý cấu hình. "ii, iv and v." sai vì có mục v và thiếu mục i. "ii, iii and iv." sai vì có mục iii và thiếu mục i. "i, iii and v." sai vì chứa hai mục không thuộc quản lý cấu hình và bỏ sót kiểm soát phiên bản, theo dõi thay đổi testware.

Đáp án đúng: "The likelihood of an adverse event and the impact of the event.". Theo ISTQB, rủi ro là khả năng một sự kiện bất lợi xảy ra kèm hậu quả của nó, và mức rủi ro được xác định bởi hai yếu tố: khả năng xảy ra (likelihood) và tác động (impact) nếu nó xảy ra, thường được ước bằng cách kết hợp hai đại lượng này. "The probability that an adverse event will occur." chỉ có một nửa: sự kiện rất dễ xảy ra nhưng hậu quả không đáng kể thì rủi ro vẫn thấp. "The cost of dealing with an adverse event if it occurs." là nửa còn lại, phần tác động, thiếu khả năng xảy ra. "The amount of testing planned before release of a system." là hệ quả chứ không phải nguyên nhân: lượng kiểm thử được lên kế hoạch dựa trên mức rủi ro, chứ không quyết định mức rủi ro.

Đáp án đúng: "Stop when scheduled time for testing expires". Về nguyên tắc, ISTQB khuyên dừng kiểm thử theo tiêu chí kết thúc (exit criteria) dựa trên rủi ro và độ phủ đã đặt ra từ khi lập kế hoạch, vì kiểm thử vét cạn là không thể. Tuy vậy, trong các điều kiện cụ thể được nêu, chỉ hết thời gian theo lịch (hạn kiểm thử hoặc hạn phát hành) là điều kiện dừng được dùng thật trong dự án, và đây là cách trả lời kinh điển của câu hỏi này; đó cũng là chỗ dễ tranh cãi vì có người cho rằng không điều kiện nào đủ chuẩn. "Stop if 75% of the pre-defined number of errors is detected." không phải tiêu chí chuẩn: số lỗi tồn tại không biết trước nên một tỷ lệ phần trăm trên con số định sẵn không có cơ sở. "Stop when all the test cases execute with detecting few errors." cũng sai vì ít lỗi có thể chỉ do bộ ca kiểm thử yếu, không chứng tỏ phần mềm tốt. "None of the others" không được chọn vì điều kiện hết thời gian theo lịch vẫn là một điều kiện dừng hợp lệ trên thực tế.

Đáp án đúng: "Is a valuable source of project information during testing if it contains all incidents". Hệ thống ghi nhận sự cố (incident logging) lưu mọi sự kiện bất thường cần điều tra; khi nó đầy đủ, dữ liệu trong đó cho biết số khiếm khuyết theo mức độ, mật độ lỗi theo thành phần, tốc độ tìm và đóng lỗi, giúp quản lý theo dõi tiến độ, đánh giá rủi ro và quyết định phát hành, nên là nguồn thông tin dự án quý giá với điều kiện mọi sự cố đều được ghi. "Only records defects" sai vì sự cố gồm cả lỗi môi trường, lỗi ca kiểm thử, hiểu sai yêu cầu, không phải sự cố nào cũng là khiếm khuyết của phần mềm. "Is of limited value" sai vì nó là một trong những nguồn số đo quan trọng nhất của kiểm thử. "Should be used only by the test team." sai vì lập trình viên, trưởng dự án và các bên liên quan cũng dùng nó để sửa lỗi và ra quyết định.

Một ví dụ không phải là rủi ro là khi dự án phải loại trừ ngày nghỉ và ngày lễ. Điều này không phải là rủi ro vì nó là một phần quan trọng của việc lập kế hoạch và quản lý dự án. Việc lập kế hoạch dự án phải bao gồm cả ngày nghỉ và ngày lễ để đảm bảo rằng mọi người có thể nghỉ ngơi và phục hồi sức khỏe. Điều này không chỉ giúp họ trở lại làm việc với tinh thần tốt hơn mà còn giúp họ tránh được những rủi ro có thể xảy ra do kiệt sức. Ngoài ra, việc loại trừ ngày nghỉ và ngày lễ cũng giúp dự án được thực hiện một cách có kế hoạch và hiệu quả hơn.

Một tổ chức kiểm thử trong dự án thường chịu ảnh hưởng bởi nhiều yếu tố khác nhau. Tuy nhiên, yếu tố chính ảnh hưởng đến cấu trúc của tổ chức kiểm thử là mức độ rủi ro và độ phức tạp của dự án. Khi dự án có mức độ rủi ro và độ phức tạp cao, tổ chức kiểm thử sẽ cần phải có cấu trúc phức tạp hơn để đảm bảo rằng tất cả các khía cạnh của dự án đều được kiểm thử một cách đầy đủ. Điều này bao gồm việc phân chia công việc, giao tiếp giữa các thành viên, và việc sử dụng các công cụ và kỹ thuật kiểm thử phù hợp. Ngoài ra, tổ chức kiểm thử cũng cần phải có khả năng thích nghi và linh hoạt để đáp ứng các thay đổi trong dự án.

Xác định phạm vi trong kế hoạch kiểm thử là một bước quan trọng để đảm bảo rằng các thử nghiệm được thực hiện một cách hiệu quả và tập trung vào các yếu tố quan trọng. Nó giúp làm rõ những gì được bao gồm và không được bao gồm trong quá trình kiểm thử, từ đó giúp giảm thiểu thời gian và nguồn lực cần thiết. Bằng cách xác định phạm vi, bạn có thể tập trung vào các tính năng và yêu cầu chính của sản phẩm, đồng thời loại bỏ những yếu tố không cần thiết. Điều này giúp đảm bảo rằng sản phẩm được kiểm thử một cách toàn diện và chính xác, từ đó giúp cải thiện chất lượng và giảm thiểu rủi ro khi phát hành.

Một người quản lý thử nghiệm (test manager) có vai trò quan trọng trong quá trình phát triển phần mềm. Họ chịu trách nhiệm quản lý toàn bộ quy trình thử nghiệm và các nguồn lực liên quan. Điều này bao gồm lập kế hoạch, phân bổ nguồn lực, giám sát tiến độ và đảm bảo rằng các thử nghiệm được thực hiện một cách hiệu quả và chính xác. Người quản lý thử nghiệm cũng phải có khả năng giao tiếp tốt để phối hợp với các thành viên khác trong đội ngũ phát triển phần mềm, bao gồm cả các nhà phát triển, nhà thiết kế và khách hàng.

Các tiêu chí nhập cảnh phổ biến cho thử nghiệm thường bao gồm sẵn sàng của môi trường thử nghiệm và sự chấp thuận từ người quản lý dự án. Môi trường thử nghiệm sẵn sàng là điều cần thiết để thực hiện các thử nghiệm, vì nó cung cấp môi trường để chạy các thử nghiệm và kiểm tra kết quả. Sự chấp thuận từ người quản lý dự án cũng là một tiêu chí quan trọng, vì nó đảm bảo rằng dự án đang được thực hiện theo kế hoạch và các thử nghiệm được thực hiện một cách có hệ thống.

Một người lãnh đạo thử nghiệm (test leader) và một người thử nghiệm (tester) đều đóng vai trò quan trọng trong quá trình thử nghiệm. Người lãnh đạo thử nghiệm chịu trách nhiệm quản lý toàn bộ quá trình thử nghiệm, bao gồm lập kế hoạch, quản lý và kiểm soát tiến độ thử nghiệm. Họ cũng đảm bảo rằng các thử nghiệm được thực hiện một cách hiệu quả và đạt được mục tiêu đã đề ra. Ngược lại, người thử nghiệm tập trung vào việc thực hiện các thử nghiệm đã được lập kế hoạch, bao gồm việc thực hiện các thử nghiệm, thu thập dữ liệu và báo cáo kết quả. Họ cũng có thể tham gia vào việc lập kế hoạch thử nghiệm và cung cấp ý kiến về các vấn đề kỹ thuật.

Bước cuối cùng trong quá trình quản lý sự cố là đóng góp cho báo cáo sự cố. Sau khi khắc phục sự cố, nhân viên IT sẽ đóng góp cho báo cáo sự cố để xác nhận rằng sự cố đã được giải quyết và không còn tồn tại. Điều này giúp đảm bảo rằng sự cố đã được xử lý một cách đầy đủ và hiệu quả. Ngoài ra, việc đóng góp cho báo cáo sự cố cũng giúp cho việc theo dõi và phân tích sự cố trong tương lai trở nên dễ dàng hơn. Điều này giúp cho việc cải thiện quy trình quản lý sự cố và ngăn chặn sự cố tương tự xảy ra trong tương lai.

Mức độ nghiêm trọng của một lỗi trong quy trình kiểm thử phần mềm thường được sử dụng để đánh giá mức độ ảnh hưởng của lỗi đó đến hệ thống. Điều này có nghĩa là mức độ nghiêm trọng của một lỗi sẽ phụ thuộc vào mức độ ảnh hưởng của nó đến hệ thống, bao gồm cả các chức năng quan trọng và các dữ liệu nhạy cảm. Ví dụ, một lỗi có thể gây ra sự cố nghiêm trọng cho hệ thống nếu nó ảnh hưởng đến các chức năng chính hoặc gây ra mất dữ liệu quan trọng. Ngược lại, một lỗi có thể được coi là nhẹ nếu nó không gây ra bất kỳ ảnh hưởng nào đến hệ thống. Do đó, mức độ nghiêm trọng của một lỗi là một yếu tố quan trọng trong quy trình kiểm thử phần mềm, giúp đảm bảo rằng các lỗi nghiêm trọng được ưu tiên và giải quyết trước.

Các chiến lược kiểm thử quan trọng trong giai đoạn lập kế hoạch vì chúng giúp xác định phương pháp, kỹ thuật và ưu tiên cho nỗ lực kiểm thử. Điều này đảm bảo rằng quá trình kiểm thử được thực hiện một cách hiệu quả và hiệu quả, giúp phát hiện ra các lỗi và vấn đề sớm. Chiến lược kiểm thử cũng giúp xác định phạm vi kiểm thử, giúp tập trung vào các khu vực quan trọng và giảm thiểu thời gian và nguồn lực. Ngoài ra, chiến lược kiểm thử còn giúp xác định các công cụ và công nghệ cần thiết để thực hiện kiểm thử, giúp đảm bảo rằng quá trình kiểm thử được thực hiện một cách chính xác và đáng tin cậy.

Mục tiêu chính của việc đánh giá rủi ro trong thử nghiệm phần mềm là xác định, phân tích và ưu tiên các rủi ro có thể xảy ra. Quá trình này giúp các nhà phát triển phần mềm hiểu rõ về các rủi ro tiềm ẩn và có thể đưa ra các biện pháp phòng ngừa hoặc giảm thiểu rủi ro. Việc đánh giá rủi ro giúp các nhà phát triển tập trung vào các khu vực cần cải thiện và đảm bảo rằng phần mềm cuối cùng được phát hành là an toàn và đáng tin cậy. Quá trình này cũng giúp các nhà phát triển lập kế hoạch và phân bổ nguồn lực một cách hiệu quả hơn.

Việc ưu tiên các sự cố là rất quan trọng trong quy trình phát triển phần mềm. Khi chúng ta ưu tiên các sự cố, chúng ta có thể tập trung nguồn lực vào việc giải quyết các vấn đề nghiêm trọng nhất trước. Điều này giúp đảm bảo rằng các vấn đề quan trọng được giải quyết trước khi chúng trở nên tồi tệ hơn. Ngoài ra, việc ưu tiên các sự cố cũng giúp giảm thiểu thời gian và chi phí cần thiết để giải quyết các vấn đề. Điều này giúp tăng hiệu suất và giảm thiểu rủi ro trong quy trình phát triển phần mềm.

Mục tiêu của phần tóm tắt trong báo cáo sự cố là cung cấp thông tin tổng quan về sự cố, bao gồm cả mô tả và tác động. Điều này giúp người đọc hiểu rõ về sự cố và có thể đưa ra quyết định phù hợp. Ngoài ra, việc mô tả các bước lặp lại để tái tạo sự cố cũng rất quan trọng, vì nó cho phép người đọc hiểu rõ về nguyên nhân của sự cố và có thể thực hiện các biện pháp khắc phục. Các thông tin này thường được bao gồm trong phần tóm tắt của báo cáo sự cố.

Mô tả về câu trả lời đúng và sai trong câu hỏi này là như sau: Câu trả lời đúng là 'Tests by a person from a different organizational group, such as an independent test team.' Câu trả lời sai là 'Tests by the person who wrote the item under test.', 'Tests by another person within the same team, such as another programmer.', và 'Tests by the person who wrote the source code.' Vì trong quá trình kiểm thử độc lập, người kiểm thử độc lập không phải là người viết mã nguồn hoặc người trong cùng nhóm, mà là một cá nhân độc lập từ nhóm khác.

Báo cáo lỗi/bug là một tài liệu kỹ thuật được sử dụng để mô tả các triệu chứng của một lỗi. Nó thường bao gồm thông tin chi tiết về lỗi, bao gồm cả các bước để tái tạo lỗi và các ảnh chụp màn hình để minh họa. Báo cáo lỗi/bug giúp cho các nhà phát triển hiểu rõ về lỗi và có thể sửa lỗi một cách hiệu quả. Nó cũng giúp cho các nhà quản lý dự án theo dõi tiến độ và đảm bảo rằng lỗi được sửa chữa một cách kịp thời. Báo cáo lỗi/bug thường được sử dụng trong suốt vòng đời kiểm thử phần mềm (STLC) để đảm bảo rằng phần mềm được kiểm thử một cách đầy đủ và hiệu quả.

Vai trò chịu trách nhiệm lãnh đạo nỗ lực kiểm thử là vai trò của người quản lý kiểm thử. Người quản lý kiểm thử là người có trách nhiệm toàn diện về quá trình kiểm thử, bao gồm lập kế hoạch, tổ chức, thực hiện và theo dõi tiến độ kiểm thử. Họ phải đảm bảo rằng quá trình kiểm thử được thực hiện một cách hiệu quả và hiệu quả, đồng thời đảm bảo rằng các yêu cầu kiểm thử được thực hiện một cách chính xác. Người quản lý kiểm thử cũng phải có khả năng giải quyết vấn đề và đưa ra quyết định sáng suốt trong quá trình kiểm thử.