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

Đáp án đúng: "Preventative tests are designed early; reactive tests are designed after the software has been produced.". ISTQB Foundation phân loại cách tiếp cận kiểm thử theo thời điểm thiết kế ca kiểm thử: cách tiếp cận phòng ngừa (preventative) thiết kế kiểm thử càng sớm càng tốt, ngay từ khi có yêu cầu và thiết kế, để ngăn lỗi lọt vào sản phẩm; cách tiếp cận phản ứng (reactive) chỉ thiết kế kiểm thử sau khi phần mềm đã được làm ra, phản ứng với sản phẩm thực tế, ví dụ kiểm thử thăm dò. Khác biệt then chốt vì vậy là thời điểm. "Preventative tests and reactive tests are designed as early as possible." sai vì xoá mất khác biệt, gán cả hai vào thiết kế sớm. "Preventative testing is always analytical; reactive testing is always heuristic." sai vì phân tích (analytical) hay dựa kinh nghiệm (heuristic) là một trục phân loại chiến lược khác, không gắn cứng với phòng ngừa hay phản ứng. "Preventative tests are designed after the software has been produced; reactive tests are designed early in response to review comments." đảo ngược hai định nghĩa.

Để theo dõi tiến độ kiểm thử, có nhiều yếu tố quan trọng cần xem xét. Đầu tiên, phần trăm thực thi các trường hợp kiểm thử (i) giúp chúng ta đánh giá hiệu suất và tốc độ thực hiện các trường hợp kiểm thử. Thứ hai, phần trăm công việc đã hoàn thành trong việc chuẩn bị môi trường kiểm thử (ii) cho chúng ta biết tiến độ của dự án. Thứ ba, thông tin về lỗi, chẳng hạn như mật độ lỗi, số lỗi đã tìm thấy và sửa chữa (iii) giúp chúng ta đánh giá chất lượng sản phẩm. Cuối cùng, kích thước của đội kiểm thử và kỹ năng của kỹ sư (iv) cũng rất quan trọng vì nó ảnh hưởng đến hiệu suất và chất lượng của quá trình kiểm thử.

Đáp án đúng: "Available skills and experience in the proposed techniques.". Theo ISTQB, khi chọn cách tiếp cận kiểm thử (test approach) phải xét bối cảnh: rủi ro thất bại của dự án và sản phẩm, kỹ năng và kinh nghiệm của con người với kỹ thuật, công cụ, phương pháp đề xuất, mục tiêu kiểm thử, quy định pháp lý và bản chất sản phẩm; trong các yếu tố được nêu ở đây, kỹ năng và kinh nghiệm sẵn có quyết định trực tiếp việc kỹ thuật có áp dụng được hiệu quả hay không. "Availability of tools to support the proposed techniques." là yếu tố phụ: công cụ chỉ hỗ trợ, thiếu người biết dùng kỹ thuật thì công cụ không cứu được. "The budget allowed for training in proposed techniques." chỉ là cách bù đắp khi thiếu kỹ năng, không phải tiêu chí trung tâm. "The willingness of the test team to learn new techniques." là thái độ đáng quý nhưng không bảo đảm năng lực thực hiện ngay trong dự án hiện tại.

Đáp án đúng: "Cultural difference". Khi kiểm thử phần mềm do nhà thầu bên ngoài phát triển (outsourced, contracted software), các rủi ro như mất quyền kiểm soát, khó điều chuyển nguồn lực, sản phẩm có thể không đáp ứng nhu cầu đều có mặt bất kể nhà thầu ở trong hay ngoài nước. Điểm khác biệt riêng khi nhà thầu ở nước ngoài là khác biệt văn hoá: ngôn ngữ, cách hiểu yêu cầu, thói quen làm việc, múi giờ, chuẩn mực giao tiếp, khiến yêu cầu dễ bị hiểu lệch và cần kiểm thử, đối chiếu kỹ hơn. "Does not meet people needs" là rủi ro chung của mọi phần mềm mua hoặc thuê làm, không phân biệt vị trí nhà thầu. "Loss of control over reallocation of resources" cũng xảy ra với nhà thầu trong nước, vì nguồn lực nằm ở phía nhà thầu. "Relinquishments of control" là việc từ bỏ quyền kiểm soát quy trình phát triển, đặc điểm chung của mọi hình thức thuê ngoài.

Tính chất phần mềm không tốt thường bao gồm cả rủi ro dự án và rủi ro sản phẩm. Rủi ro dự án liên quan đến các vấn đề phát sinh trong quá trình triển khai dự án, chẳng hạn như vượt quá ngân sách, chậm tiến độ, hoặc không đáp ứng yêu cầu khách hàng. Rủi ro sản phẩm liên quan đến chất lượng của sản phẩm phần mềm, chẳng hạn như lỗi, không tương thích, hoặc không đáp ứng yêu cầu kỹ thuật. Vì vậy, lựa chọn đúng là cả rủi ro dự án và rủi ro sản phẩm.

Vấn đề này liên quan đến quản lý và kiểm soát các thành phần cấu hình trong một thư viện được kiểm soát. Thư viện này chứa tất cả các cấu hình vật thể. Để trả lời câu hỏi này, chúng ta cần hiểu các khái niệm liên quan. Configuration Control là quá trình kiểm soát và quản lý các thay đổi đối với các thành phần cấu hình. Status Accounting là quá trình theo dõi và cập nhật trạng thái của các thành phần cấu hình. Configuration Identification là quá trình xác định và phân loại các thành phần cấu hình. Trong trường hợp này, câu trả lời đúng là Configuration Control vì nó liên quan đến việc cung cấp và quản lý một thư viện được kiểm soát chứa tất cả các thành phần cấu hình.

Khái niệm mức độ nghiêm trọng (severity) và mức độ ưu tiên (priority) trong kiểm thử phần mềm thường được nhầm lẫn với nhau. Tuy nhiên, chúng có ý nghĩa khác nhau. Mức độ nghiêm trọng của một lỗi (defect) ám chỉ tầm quan trọng của nó đối với người dùng cuối, trong khi mức độ ưu tiên của một lỗi phản ánh tác động của nó lên đội ngũ phát triển. Ví dụ, một lỗi nghiêm trọng có thể không ảnh hưởng đến trải nghiệm người dùng, nhưng lại gây khó khăn cho đội ngũ phát triển. Ngược lại, một lỗi có mức độ ưu tiên cao có thể không nghiêm trọng, nhưng lại cần được sửa chữa ngay lập tức để tránh ảnh hưởng đến kế hoạch phát triển. Do đó, việc hiểu rõ sự khác biệt giữa mức độ nghiêm trọng và mức độ ưu tiên là rất quan trọng để đảm bảo rằng các lỗi được sửa chữa một cách hiệu quả và kịp thời.

Mục tiêu thoát (Exit Criteria) có thể bao gồm các yếu tố sau: i. Các chỉ số độ sâu, như độ bao phủ của mã nguồn, tính năng hoặc rủi ro. ii. Các ước tính mật độ lỗi hoặc các chỉ số độ tin cậy. iii. Rủi ro còn lại, chẳng hạn như lỗi chưa được sửa chữa hoặc thiếu độ bao phủ trong một số khu vực. iv. Xác minh môi trường thử nghiệm. Mục tiêu thoát là các tiêu chí để xác định khi nào một dự án hoặc giai đoạn đã đạt được mức độ hoàn thiện mong muốn. Các mục tiêu thoát thường được thiết lập dựa trên các yếu tố như độ bao phủ của mã nguồn, mật độ lỗi và rủi ro còn lại. Trong câu hỏi này, câu trả lời đúng là "iv là đúng và (i, ii, iii) là sai". Điều này có nghĩa là xác minh môi trường thử nghiệm là một phần quan trọng của mục tiêu thoát, trong khi các yếu tố khác không phải là một phần của mục tiêu thoát.

Trong quá trình kiểm tra hệ thống, người quản lý SSSR không nên báo cáo các lỗi mà họ đã phát hiện. Điều này có thể gây ra sự nhầm lẫn và làm chậm quá trình kiểm tra. Thay vào đó, họ nên tập trung vào việc báo cáo các vấn đề thực sự cần được giải quyết. Ngoài ra, việc báo cáo các lỗi mà họ đã phát hiện có thể làm giảm sự tin tưởng của khách hàng vào hệ thống và có thể gây ra sự chậm trễ trong việc phát hành hệ thống.

Theo ISTQB Glossary, rủi ro liên quan đến những hậu quả tiêu cực có thể xảy ra. Trong quá trình kiểm thử, rủi ro thường được định nghĩa là những hậu quả tiêu cực có thể xảy ra trong quá trình kiểm thử hoặc sau khi kiểm thử. Điều này giúp cho các nhà kiểm thử có thể dự đoán và chuẩn bị cho những tình huống xấu có thể xảy ra. Ví dụ, rủi ro có thể bao gồm việc mất dữ liệu quan trọng, lỗi hệ thống hoặc chậm trễ trong quá trình triển khai. Việc nhận biết và đánh giá rủi ro là một phần quan trọng trong quá trình kiểm thử để đảm bảo rằng các sản phẩm hoặc dịch vụ được kiểm thử một cách đầy đủ và hiệu quả.

Đáp án đúng: "When the test completion criteria are met.". Tiêu chí hoàn thành kiểm thử (test completion criteria) được thống nhất khi lập kế hoạch và kết hợp nhiều thước đo như độ phủ, số khiếm khuyết còn mở, rủi ro còn lại, ràng buộc thời gian và chi phí; đạt được chúng là căn cứ khách quan để dừng kiểm thử. "When the specified number of faults are found" sai vì không ai biết trước phần mềm có bao nhiêu khiếm khuyết, dừng theo số lỗi đã tìm không nói gì về số lỗi còn lại. "When all high and medium priority tests are complete." chỉ là một điều kiện có thể nằm trong tiêu chí, tự nó chưa đủ vì chưa xét kết quả và khiếm khuyết còn mở. "When all statements have been executed" là phủ câu lệnh 100%, cũng chỉ là một thước đo có thể dùng trong tiêu chí, không chứng minh được hành vi đã đúng.

Để xây dựng một kế hoạch kiểm tra, các đầu vào quan trọng được lấy từ kế hoạch dự án. Kế hoạch dự án cung cấp thông tin chi tiết về mục tiêu, phạm vi, thời gian và ngân sách của dự án. Điều này giúp cho việc xây dựng kế hoạch kiểm tra trở nên rõ ràng và hiệu quả hơn. Ngoài ra, kế hoạch dự án cũng cung cấp thông tin về các yêu cầu chức năng và không chức năng của dự án, giúp cho việc xác định các trường hợp kiểm tra trở nên dễ dàng hơn. Vì vậy, kế hoạch dự án là nguồn thông tin quan trọng để xây dựng kế hoạch kiểm tra.

Đáp án đúng: "All of the others". Mô hình tăng trưởng độ tin cậy thống kê (statistical reliability model) dự báo tốc độ tìm lỗi theo thời gian, ví dụ kỳ vọng nhiều lỗi lúc đầu rồi giảm dần, và nếu quản lý lịch dự án bám vào đường cong đó thì phát sinh nhiều rủi ro; cả ba phát biểu đều là rủi ro thật nên phương án gộp đúng. Phát biểu "Testers spend more energy early in the product trying to find bugs" đúng: để khớp đường cong dự báo, tester dồn sức tìm lỗi sớm thay vì chuẩn bị làm phần còn lại của dự án hiệu quả hơn, nhưng nó chỉ là một rủi ro nên chọn riêng nó là thiếu. Phát biểu "Managers might not realize that the testing effort is ineffective" đúng: cuối dự án quản lý vốn chờ tỉ lệ tìm lỗi thấp, nên tỉ lệ thấp do kiểm thử kém hiệu quả không làm họ cảnh giác; chọn riêng nó cũng thiếu. Phát biểu "increase the end-of-project pressure on testers to not find bugs" đúng: khi lịch phụ thuộc vào việc đường cong đi xuống, tester bị áp lực không tìm hoặc không báo lỗi; chọn riêng nó cũng bỏ sót hai rủi ro kia.

Đáp án đúng: "During test planning.". ISTQB nêu rằng thủ tục và hạ tầng quản lý cấu hình (configuration management) phải được chọn, ghi lại và triển khai ngay khi lập kế hoạch kiểm thử, để mọi testware và phiên bản phần mềm được định danh, kiểm soát phiên bản và truy vết được từ đầu. "During test analysis." đã muộn: lúc này cơ sở kiểm thử và điều kiện kiểm thử đã được tạo ra, chúng cần được quản lý phiên bản từ trước. "During test execution." quá muộn: chạy kiểm thử mà không biết đang chạy trên phiên bản nào, với ca kiểm thử phiên bản nào thì kết quả không tái hiện được. "When evaluating exit criteria" là gần cuối quy trình, khi đó quản lý cấu hình không còn phát huy tác dụng phòng ngừa.

Đáp án đúng: "Open, Assigned, Fixed, Closed". Vòng đời lỗi (bug life cycle, defect life cycle) mô tả các trạng thái mà một báo cáo lỗi đi qua: người kiểm thử phát hiện và ghi nhận lỗi nên lỗi ở trạng thái Open (mở, có nơi gọi New), trưởng nhóm duyệt rồi giao cho lập trình viên nên chuyển sang Assigned (đã giao), lập trình viên sửa xong thì đánh dấu Fixed (đã sửa), người kiểm thử chạy lại ca kiểm thử (kiểm thử xác nhận, retest) thấy lỗi không còn thì chuyển thành Closed (đóng); nếu lỗi vẫn còn thì mở lại (Reopened). "Open, Fixed, Assigned, Closed" sai vì lỗi chưa thể được sửa khi chưa giao cho ai chịu trách nhiệm. "Assigned, Open, Closed, Fixed" sai hai chỗ: không thể giao một lỗi chưa được ghi nhận, và không thể đóng lỗi trước khi sửa. "Assigned, Open, Fixed, Closed" tuy đặt Fixed trước Closed đúng thứ tự nhưng vẫn giao việc trước khi lỗi được mở.

Khi một phần mềm đã được cấp giấy phép, bạn sẽ thực hiện các kiểm tra sau. Trước hết, bạn cần xác định giấy phép đã cấp cho phần mềm có phải là giấy phép mở (Open-source) hay không. Nếu là giấy phép mở, bạn sẽ kiểm tra xem phần mềm có tuân thủ các điều khoản của giấy phép hay không. Điều này bao gồm việc kiểm tra xem phần mềm có được sử dụng miễn phí hay không, có được chia sẻ mã nguồn hay không, và có được sử dụng cho mục đích thương mại hay không. Ngoài ra, bạn cũng cần kiểm tra xem phần mềm có chứa bất kỳ mã độc (malware) nào hay không. Nếu phần mềm không phải là giấy phép mở, bạn sẽ kiểm tra xem phần mềm có được sử dụng hợp pháp hay không, và có được sử dụng cho mục đích thương mại hay không. Cuối cùng, bạn sẽ kiểm tra xem phần mềm có tuân thủ các quy định về bảo mật và bảo vệ thông tin cá nhân hay không.

Mục tiêu thoát (Exit criteria) là một phần quan trọng trong quá trình kiểm thử phần mềm. Nó xác định điều kiện để kết thúc kiểm thử và đảm bảo rằng phần mềm đã đạt được yêu cầu. Một số nhiệm vụ chính của mục tiêu thoát bao gồm: kiểm tra nhật ký kiểm thử so với mục tiêu thoát đã được chỉ định trong kế hoạch kiểm thử, ghi lại kết quả thực hiện kiểm thử, đánh giá xem có cần thêm kiểm thử hay không. Tuy nhiên, viết báo cáo tóm tắt kiểm thử cho các bên liên quan không phải là một nhiệm vụ chính của mục tiêu thoát. Mục tiêu thoát được thiết kế để xác định khi nào kiểm thử nên kết thúc, chứ không phải để tạo ra báo cáo cho các bên liên quan.

Đáp án đúng: "1&2 are true and 3 is false". Khi nhận một phần mềm với thời gian và nguồn lực có hạn, không thể kiểm thử vét cạn, nên ISTQB khuyên kiểm thử dựa trên rủi ro (risk-based testing): ưu tiên các vùng quan trọng nhất với quy trình nghiệp vụ, nơi hỏng hóc gây tác động lớn, và các vùng nhiều khả năng chứa lỗi nhất theo nguyên lý lỗi tụ thành cụm (defect clustering). Vì thế mệnh đề 1 và 2 đúng, còn kiểm thử các chức năng dễ nhất là sai vì dễ kiểm thử không có nghĩa là rủi ro cao. "1,2&3 are true." sai vì nhận cả tiêu chí dễ nhất, vốn không phản ánh tác động hay khả năng hỏng. "1 is true, 2&3 are false." bỏ mất vùng nhiều lỗi, trái với nguyên lý lỗi tụ thành cụm. "1&2 are false, 3 is true" đảo ngược hoàn toàn, chọn việc dễ thay vì việc quan trọng.

Đáp án đúng: "When the test completion criteria have been met". Tiêu chí hoàn thành (test completion criteria, hay exit criteria) được đặt từ lúc lập kế hoạch, chẳng hạn mức độ phủ, số khiếm khuyết còn mở, rủi ro còn lại chấp nhận được, và chính chúng là căn cứ khách quan để dừng kiểm thử. "When time for testing has run out." là điều hay xảy ra trong thực tế nhưng là dừng vì áp lực, không bảo đảm chất lượng đạt yêu cầu; thời gian chỉ hợp lệ khi đã được ghi vào tiêu chí. "When all planned tests have been run" chưa đủ vì có thể còn nhiều ca thất bại hay khiếm khuyết nghiêm trọng chưa sửa. "When no faults have been found by the tests run" sai vì kiểm thử chỉ chứng minh có khiếm khuyết chứ không chứng minh được không còn khiếm khuyết; không tìm thấy lỗi có thể chỉ do bộ ca yếu.

Đáp án đúng: "To define when a test level is complete.". Tiêu chí thoát (exit criteria) là các điều kiện được thống nhất với các bên liên quan, như mức độ phủ đạt được, số khiếm khuyết nghiêm trọng còn mở, rủi ro còn lại, để quyết định một cấp kiểm thử hay một hoạt động kiểm thử đã có thể coi là hoàn thành; chúng được đặt khi lập kế hoạch và được đánh giá ở pha đánh giá tiêu chí thoát và báo cáo. "To determine when a test has completed." nhầm phạm vi: một ca kiểm thử chạy xong là khi các bước được thực hiện hết, không cần tiêu chí thoát. "To identify when a software system should be retired." thuộc quyết định bảo trì và vòng đời sản phẩm, không liên quan tới tiêu chí thoát của kiểm thử. "To determine whether a test has passed." là việc so kết quả thực tế với kết quả mong đợi của từng ca, khác với việc quyết định dừng cả cấp kiểm thử.