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

Trong quản lý sự cố, mục tiêu không phải là sửa chữa tất cả các lỗi bất kể mức độ ảnh hưởng. Mục tiêu chính của quản lý sự cố là giảm thiểu sự cố và giảm thiểu thời gian ngừng hoạt động. Điều này bao gồm việc giảm thiểu rủi ro của các lỗi trong tương lai và đảm bảo sự hài lòng của các bên liên quan với sản phẩm. Tuy nhiên, mục tiêu không phải là sửa chữa tất cả các lỗi, vì điều này có thể không cần thiết và có thể không hiệu quả về mặt kinh tế. Thay vào đó, mục tiêu là tập trung vào việc sửa chữa các lỗi quan trọng và ảnh hưởng đến sản phẩm.

Để cấu trúc một đội kiểm thử cho dự án yêu cầu kiến thức chuyên sâu về quy trình kinh doanh và thực thi kỹ thuật, chúng ta cần cân nhắc kỹ lưỡng. Chọn phương án 'Combine business experts with technical testers' là lựa chọn tốt nhất vì nó kết hợp giữa chuyên gia kinh doanh và kiểm thử viên kỹ thuật. Điều này giúp đội kiểm thử có thể hiểu rõ về quy trình kinh doanh và thực thi kỹ thuật, từ đó tạo ra các kịch bản kiểm thử hiệu quả và chính xác. Phương án này cũng giúp giảm thiểu sai sót và đảm bảo chất lượng sản phẩm cuối cùng.

Người quản lý thử nghiệm thường đảm nhiệm các nhiệm vụ liên quan đến việc tổng hợp và báo cáo kết quả thử nghiệm. Họ sẽ sử dụng thông tin thu thập được trong quá trình thử nghiệm để viết báo cáo tóm tắt thử nghiệm. Điều này bao gồm việc tổng hợp và phân tích kết quả thử nghiệm, cũng như việc xác định các vấn đề và lỗi cần được giải quyết. Người quản lý thử nghiệm cũng có thể tham gia vào việc đánh giá và cải thiện quy trình thử nghiệm để đảm bảo rằng nó hiệu quả và chính xác.

Để ước tính thời gian và nguồn lực cần thiết cho một thử nghiệm, yếu tố quan trọng nhất là thời gian và nguồn lực cần thiết để hoàn thành thử nghiệm. Điều này bao gồm cả thời gian và nguồn lực cần thiết để thực hiện các hoạt động thử nghiệm, chẳng hạn như lập kế hoạch, thiết kế, thực hiện và kiểm tra thử nghiệm. Thời gian và nguồn lực cần thiết cũng bao gồm cả thời gian và nguồn lực cần thiết để thực hiện các hoạt động khác liên quan đến thử nghiệm, chẳng hạn như lập báo cáo và phân tích kết quả. Việc ước tính thời gian và nguồn lực cần thiết chính xác là rất quan trọng vì nó giúp đảm bảo rằng thử nghiệm được thực hiện một cách hiệu quả và tiết kiệm nguồn lực.

Rủi ro dựa trên kiểm thử là một phương pháp kiểm thử giúp tối ưu hóa việc kiểm tra bằng cách tập trung vào các khu vực có rủi ro cao. Điều này giúp đảm bảo rằng các khu vực quan trọng nhất của ứng dụng được kiểm tra kỹ lưỡng, giảm thiểu khả năng xảy ra lỗi. Bằng cách tập trung vào các khu vực có rủi ro cao, kiểm thử rủi ro dựa trên giúp tối ưu hóa việc kiểm tra, giảm thiểu thời gian và nguồn lực cần thiết để thực hiện kiểm thử. Điều này cũng giúp đảm bảo rằng các lỗi quan trọng được phát hiện và sửa chữa trước khi ứng dụng được phát hành.

Quản lý sự cố hiệu quả là một phần quan trọng trong việc đảm bảo chất lượng và độ tin cậy của phần mềm. Một trong những lợi ích chính của quản lý sự cố hiệu quả là cải thiện sự hài lòng của khách hàng. Khi các sự cố được xử lý nhanh chóng và hiệu quả, khách hàng sẽ cảm thấy được quan tâm và được hỗ trợ tốt hơn. Điều này có thể dẫn đến sự hài lòng cao hơn và tăng cường độ trung thành của khách hàng. Ngoài ra, quản lý sự cố hiệu quả 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 đề, từ đó cải thiện hiệu suất và độ tin cậy của phần mềm.

Để theo dõi tiến độ thực thi thử nghiệm, cần sử dụng chỉ số phù hợp. Trong số các lựa chọn trên, chỉ số "Số lượng lỗi mở so với lỗi đã đóng" là lựa chọn đúng. Điều này giúp theo dõi số lượng lỗi mới phát hiện và số lượng lỗi đã được sửa trong quá trình thử nghiệm. Điều này cho phép quản lý dự án đánh giá tiến độ thử nghiệm và đưa ra quyết định điều chỉnh phù hợp. Chỉ số này cũng giúp theo dõi hiệu suất của đội ngũ thử nghiệm và xác định khu vực cần cải thiện.

Khi thực hiện kiểm thử, việc dừng kiểm thử phụ thuộc vào nhiều yếu tố. Trước hết, nếu tất cả các thử nghiệm đã được thực hiện và không còn thử nghiệm nào cần thực hiện nữa, thì việc kiểm thử có thể được dừng lại. Tuy nhiên, nếu thời gian đã hết và không thể thực hiện thêm thử nghiệm, thì việc kiểm thử cũng cần được dừng lại. Ngoài ra, nếu tất cả các lỗi đã được sửa chữa chính xác và hệ thống đã được kiểm thử đầy đủ, thì việc kiểm thử cũng có thể được dừng lại. Tuy nhiên, điều quan trọng là phải xem xét đến mức độ rủi ro của hệ thống đang được kiểm thử. Nếu hệ thống có mức độ rủi ro cao, thì việc kiểm thử cần được tiếp tục cho đến khi đảm bảo rằng hệ thống đã được kiểm thử đầy đủ và an toàn.

Đáp án đúng: "To plan when to stop testing". Tiêu chí hoàn thành kiểm thử (test completion criteria, còn gọi tiêu chí kết thúc) được ghi trong kế hoạch kiểm thử để định trước điều kiện nào thì hoạt động kiểm thử được coi là đủ, ví dụ đạt độ phủ yêu cầu, không còn lỗi nghiêm trọng mở, rủi ro còn lại chấp nhận được; nhờ đó việc dừng kiểm thử dựa trên căn cứ đã thống nhất chứ không chỉ vì hết thời gian. "To know when a specific test has finished its execution" nhầm với trạng thái chạy xong của một ca kiểm thử riêng lẻ, việc không cần tiêu chí trong kế hoạch. "To ensure that the test case specification is complete" là việc rà soát tài liệu đặc tả ca kiểm thử. "To set the criteria used in generating test inputs" là việc của kỹ thuật thiết kế ca kiểm thử như phân hoạch tương đương, giá trị biên. "To know when test planning is complete" chỉ nói về việc lập kế hoạch xong, trong khi tiêu chí hoàn thành áp cho toàn bộ hoạt động kiểm thử.

Mô tả về tiêu chuẩn kiểm tra thành phần trong việc đánh giá khả năng trả lời của một hệ thống. Tiêu chuẩn này được sử dụng để xác định các yêu cầu và quy trình kiểm tra để đảm bảo hệ thống đáp ứng được các yêu cầu chức năng và hiệu suất. Trong các lựa chọn trên, tiêu chuẩn IEEE 829 là tiêu chuẩn được sử dụng rộng rãi nhất trong lĩnh vực kiểm thử phần mềm. Tiêu chuẩn này cung cấp các hướng dẫn chi tiết về quy trình kiểm thử, bao gồm việc xác định yêu cầu kiểm thử, thiết kế kiểm thử, thực hiện kiểm thử và đánh giá kết quả kiểm thử. IEEE 610 là tiêu chuẩn về từ vựng và định nghĩa trong lĩnh vực công nghệ thông tin, không liên quan trực tiếp đến kiểm thử phần mềm. BS7925-1 và BS7925-2 là tiêu chuẩn về kiểm thử phần mềm của Anh, nhưng không được sử dụng rộng rãi như IEEE 829.

Về cấu trúc báo cáo sự cố, tiêu chuẩn IEEE 829 cho tài liệu kiểm thử phần mềm (Standard for Software Test Documentation IEEE 829) đề cập đến một phần quan trọng. Cụ thể, tiêu chuẩn này định nghĩa cấu trúc của báo cáo sự cố (incident report) và gọi nó là 'Báo cáo sự cố kiểm thử' (Test Incident Report). Điều này cho thấy tầm quan trọng của việc lập báo cáo sự cố trong quá trình kiểm thử phần mềm để đảm bảo rằng mọi sự cố đều được ghi nhận và xử lý một cách đầy đủ.

Đáp án đúng: "Reducing test time". Khi phương pháp phát triển tốt hơn (rà soát yêu cầu, thiết kế cẩn thận, kiểm thử đơn vị kỹ), phần mềm bàn giao cho các pha kiểm thử chứa ít khiếm khuyết hơn; ít khiếm khuyết nghĩa là ít thất bại (failure) phải điều tra, ít báo cáo sự cố, ít vòng sửa rồi kiểm thử xác nhận (confirmation testing) và kiểm thử hồi quy (regression testing), nên tổng thời gian các pha kiểm thử giảm. "No change" sai vì thời gian kiểm thử không chỉ là chạy bộ ca cố định mà còn gồm các vòng lặp do lỗi sinh ra, và phần này co lại khi chất lượng tăng. "Increasing test time" đi ngược quan hệ trên: chất lượng tốt hơn không tạo thêm việc kiểm thử. "Can’t say" sai vì quan hệ giữa chất lượng đầu vào và công sức kiểm thử là rõ ràng, đây chính là lý do kiểm thử sớm và phòng ngừa khiếm khuyết được khuyến khích trong ISTQB.

Khi chọn phương pháp thử nghiệm, yếu tố quan trọng nhất là sự có sẵn của công cụ hỗ trợ các kỹ thuật đề xuất. Điều này có nghĩa là trước khi quyết định sử dụng một phương pháp thử nghiệm nào đó, bạn cần phải xem xét xem có đủ công cụ, phần mềm và thiết bị cần thiết để hỗ trợ quá trình thử nghiệm hay không. Nếu không có đủ công cụ hỗ trợ, việc triển khai phương pháp thử nghiệm có thể trở nên khó khăn và tốn kém. Vì vậy, việc đánh giá sự có sẵn của công cụ hỗ trợ là bước quan trọng đầu tiên khi chọn phương pháp thử nghiệm.

Lập kế hoạch kiểm thử có các nhiệm vụ chính sau đây. Nhiệm vụ đầu tiên là xác định mục tiêu kiểm thử, bao gồm việc xác định yêu cầu của sản phẩm, xác định các trường hợp sử dụng và xác định các yêu cầu về hiệu suất. Nhiệm vụ thứ hai là lập kế hoạch kiểm thử chi tiết, bao gồm việc xác định các trường hợp kiểm thử, xác định các dữ liệu kiểm thử và xác định các công cụ kiểm thử. Nhiệm vụ thứ ba là lập kế hoạch kiểm thử thực hiện, bao gồm việc xác định các bước kiểm thử, xác định các yêu cầu về môi trường kiểm thử và xác định các yêu cầu về thời gian kiểm thử. Nhiệm vụ thứ tư là đánh giá và cải thiện kế hoạch kiểm thử, bao gồm việc đánh giá hiệu quả của kế hoạch kiểm thử và xác định các điểm cần cải thiện. Theo đó, nhiệm vụ i và nhiệm vụ iv là đúng và nhiệm vụ iii là sai.

Việc triển khai thủ tục quản lý cấu hình nên được thực hiện khi đánh giá các tiêu chí kết thúc. Điều này cho phép đảm bảo rằng các thay đổi được thực hiện trong quá trình thử nghiệm không ảnh hưởng đến kết quả cuối cùng. Khi triển khai thủ tục quản lý cấu hình trong giai đoạn đánh giá các tiêu chí kết thúc, bạn có thể xác định và kiểm soát các thay đổi được thực hiện, từ đó đảm bảo rằng hệ thống hoặc sản phẩm thử nghiệm đáp ứng các yêu cầu và tiêu chuẩn đã được xác định.

Một Test Lead / Leader có nhiều nhiệm vụ quan trọng trong quá trình kiểm thử phần mềm. Dưới đây là một số nhiệm vụ chính của họ: - Lập kế hoạch và quản lý dự án kiểm thử (i): Test Lead / Leader chịu trách nhiệm lập kế hoạch và quản lý dự án kiểm thử, bao gồm việc xác định mục tiêu, phạm vi và thời gian của dự án. - Xây dựng và quản lý đội ngũ kiểm thử (ii): Họ phải xây dựng và quản lý đội ngũ kiểm thử, bao gồm việc tuyển dụng, đào tạo và quản lý nhân viên. - Xác định và quản lý các yêu cầu kiểm thử (iii): Test Lead / Leader phải xác định và quản lý các yêu cầu kiểm thử, bao gồm việc xác định các trường hợp kiểm thử và các tiêu chí đánh giá. - Đánh giá và báo cáo kết quả kiểm thử (iv): Cuối cùng, họ phải đánh giá và báo cáo kết quả kiểm thử, bao gồm việc xác định các vấn đề và đề xuất các giải pháp. Vì vậy, câu trả lời đúng là "ili và iv là đúng và i và ii là sai".

Trong tiêu chuẩn Test Documentation Standard, tài liệu Test Plan bao gồm các nội dung chính như danh sách các mục cần kiểm tra (test items), môi trường kiểm tra, kế hoạch chất lượng và lịch trình. Tuy nhiên, nội dung không được bao gồm trong tài liệu Test Plan là danh sách các mục không được kiểm tra (what is not to be tested). Điều này là vì mục đích của tài liệu Test Plan là xác định các yêu cầu và điều kiện cần thiết cho quá trình kiểm tra, chứ không phải là xác định các hạn chế hoặc ngoại lệ. Vì vậy, danh sách các mục không được kiểm tra thường được bao gồm trong tài liệu khác, chẳng hạn như tài liệu yêu cầu hoặc tài liệu quy trình.

FPA (Function Point Analysis) là một phương pháp đo lường được sử dụng để ước tính kích thước của một hệ thống thông tin. Nó giúp đánh giá các yêu cầu chức năng của dự án và đo lường mức độ phức tạp của hệ thống. FPA tập trung vào việc đo lường các yêu cầu chức năng, bao gồm các yêu cầu nhập, yêu cầu xuất và các yêu cầu xử lý. Mục đích của FPA là cung cấp một cách đo lường khách quan và đáng tin cậy về kích thước của hệ thống, giúp các nhà phát triển dự án có thể lập kế hoạch và quản lý dự án một cách hiệu quả hơn.

Đáp án đúng: "Expected results.". Theo IEEE 829, kế hoạch kiểm thử (test plan) gồm các mục như định danh, hạng mục kiểm thử, tính năng sẽ kiểm và không kiểm, cách tiếp cận, tiêu chí đạt hay không đạt, tiêu chí tạm dừng và điều kiện tiếp tục, sản phẩm bàn giao, nhiệm vụ, nhu cầu môi trường, trách nhiệm, nhân sự và đào tạo, lịch, rủi ro, phê duyệt. Kết quả mong đợi của từng ca kiểm thử là chi tiết ở mức đặc tả ca kiểm thử (test case specification), không nằm trong kế hoạch. "Features to be tested." là mục bắt buộc của kế hoạch, xác định phạm vi kiểm thử. "Environmental needs." cũng là một mục của kế hoạch, mô tả phần cứng, phần mềm, công cụ cần có. "Suspension criteria." thuộc kế hoạch, quy định khi nào tạm dừng kiểm thử và điều kiện để tiếp tục.

Đáp án đúng: "Configuration Control". Quản lý cấu hình (configuration management) gồm các hoạt động nhận diện cấu hình, kiểm soát cấu hình, ghi nhận trạng thái và kiểm toán cấu hình. Kiểm soát cấu hình (configuration control) bao gồm việc cung cấp và quản lý một thư viện có kiểm soát (controlled library) chứa mọi hạng mục cấu hình, cùng việc đánh giá, phê duyệt và thực hiện thay đổi lên các hạng mục đó, bảo đảm không ai sửa phiên bản đã được chấp thuận mà không qua quy trình. "Status Accounting" (ghi nhận trạng thái) là ghi chép và báo cáo tình trạng của các hạng mục cùng các yêu cầu thay đổi, chẳng hạn phiên bản nào đang dùng ở đâu, thay đổi nào đã duyệt, không phải việc quản lý thư viện. "Configuration Identification" (nhận diện cấu hình) là chọn ra các hạng mục cấu hình, đặt tên, đánh số phiên bản và xác lập baseline, tức bước xác định cái gì cần quản lý chứ chưa phải lưu giữ và kiểm soát chúng.