日本語
EnglishGIÁM SÁT VÀ KIỂM SOÁT KIỂM THỬ
Tiến độ kiểm thử là một yếu tố khó xác định. Ví dụ, trong bài tập về nhà mùa hè, chỉ có những cuộc trò chuyện như “Bạn có làm bài tập không?” “Có, mình đang làm” không thể giúp ta biết được chính xác bài tập đã hoàn thành bao nhiêu phần, liệu có thể hoàn thành trước hạn không, hoặc có cần phải tăng tốc không. Nếu không xác nhận sự khác biệt giữa tiến độ bài tập và kế hoạch, không ai (kể cả bản thân) có thể hiểu được tình hình thực tế. Cha mẹ có thể yêu cầu kiểm tra, và nếu tiến độ chậm, họ có thể bảo con cố gắng hơn hoặc hỗ trợ nếu cần thiết.
Kiểm thử phần mềm cũng tương tự. Để nắm bắt tình hình của quá trình kiểm thử, ta cần thiết lập các chỉ số khác nhau và theo dõi những chỉ số đó. Dựa trên kết quả theo dõi, ta có thể kiểm soát được tiến độ của hoạt động kiểm thử. Nếu tiến độ chậm, sẽ cần xem xét lại lịch trình hoặc tăng cường nguồn lực để có biện pháp phù hợp. Giám sát và kiểm soát là hai yếu tố không thể thiếu để tiến hành kiểm thử một cách suôn sẻ.
Giám sát yêu cầu thu thập và phân tích dữ liệu, điều này tốn công sức, vì vậy cần thu thập thông tin một cách hiệu quả chỉ với những dữ liệu cần thiết. Thêm vào đó, việc triển khai các hệ thống dễ dàng thu thập thông tin (chẳng hạn như tự động hóa) có thể giúp giám sát diễn ra thuận lợi hơn.
Sau đây chúng ta cùng tìm hiểu chi tiết về hoạt động giám sát và kiểm soát trong kiểm thử nào!
Khi một rủi ro đã được nhận diện trở thành hiện thực (ví dụ, khi có sự chậm trễ khi release), ta sẽ đánh giá lại thứ tự ưu tiên của các case kiểm thử.
Dù là ở giai đoạn bắt đầu kiểm thử hay trong quá trình thực hiện, những sự kiện không nên xảy ra sẽ được liệt kê trước đó dưới dạng các rủi ro dự án. Trong suốt quá trình phát triển, ta cần theo dõi xem liệu các rủi ro này có trở thành hiện thực hay không, và khi chúng trở thành hiện thực, cần có biện pháp giải quyết vấn đề.
Ví dụ, trong quá trình phát triển một hệ thống bao gồm nhiều ứng dụng, nếu việc phát triển một ứng dụng cụ thể bị trễ, và điều này có thể dẫn đến việc không thể thực hiện kiểm thử cho một ứng dụng khác phụ thuộc vào ứng dụng này, thì đó là một rủi ro. Nếu sự trễ này trực tiếp dẫn đến việc chậm trễ toàn bộ việc release, thì cần phải có biện pháp đối phó thích hợp. Khi rủi ro trở thành hiện thực, ta sẽ điều chỉnh lại kế hoạch kiểm thử bằng cách ưu tiên kiểm thử các ứng dụng khác có thể kiểm thử được.
Điều chỉnh lịch trình kiểm thử theo tình trạng sử dụng môi trường và tài nguyên kiểm thử
Khi môi trường kiểm thử hoặc các tài nguyên cần thiết không thể sử dụng được, ta sẽ xem xét lại lịch trình.
Ví dụ, nếu một máy in chuyên dụng cần thiết để kiểm thử tính năng in ấn không thể chuẩn bị đúng theo kế hoạch, ta sẽ lùi lại việc kiểm thử tính năng đó và ưu tiên thực hiện kiểm thử các tính năng không yêu cầu máy in chuyên dụng. Trong trường hợp này, việc nhận diện trước các trường hợp kiểm thử thay thế có thể thực hiện được và kiểm tra xem các thiết bị cần thiết đã sẵn sàng hay chưa là rất quan trọng.
Khi cần làm lại công việc, cần kiểm tra lại xem các yếu tố kiểm thử có đáp ứng đầy đủ các tiêu chuẩn bắt đầu và kết thúc hay không
Khi phát sinh lỗi, sau khi sửa chữa các chỗ gây ra lỗi, kiểm thử trước đó bị tạm dừng bây giờ sẽ được tiếp tục. Trong trường hợp này, cần phải đánh giá lại xem các yếu tố kiểm thử có đáp ứng các điều kiện bắt đầu và kết thúc hay không.
Ví dụ, nếu một lỗi nghiêm trọng được phát hiện trong một tính năng và sau khi debug, phát hiện rằng cần phải sửa nhiều khiếm khuyết và sửa chữa có thể ảnh hưởng đến các trường hợp kiểm thử đã đạt yêu cầu, thì sẽ như thế nào? Trong trường hợp này, các tiêu chuẩn bắt đầu lại công việc sẽ bao gồm việc tất cả lỗi đã được sửa chữa, môi trường kiểm thử đã được thiết lập lại, và các trường hợp kiểm thử cần thực hiện đã được xác định rõ. Ngoài ra, tiêu chuẩn kết thúc sẽ yêu cầu việc đánh giá lại tất cả các trường hợp, bao gồm cả những trường hợp đã đạt yêu cầu trước khi tạm dừng.
Các chỉ số (metrics) sử dụng trong kiểm thử
Tiếp theo, chúng ta sẽ kiểm tra các chỉ số dùng để giám sát hoạt động kiểm thử thực tế. Trong suốt quá trình kiểm thử và sau khi kết thúc, sẽ đánh giá các mục sau đây và phản ánh chúng trong báo cáo kiểm thử:
Tiến độ so với kế hoạch về lịch trình và ngân sách
Xác nhận xem tiến độ có đúng theo kế hoạch đã định hay không, hay có sự thay đổi tiến độ, sớm hơn hoặc muộn hơn hay không. Tương tự, ngân sách cũng cần được xác nhận. Ví dụ, mặc dù một số công việc có thể bị trễ so với kế hoạch, nhưng nếu các công việc khác được hoàn thành sớm, có thể không có vấn đề gì đối với tổng thể. Tuy nhiên, nếu tiến độ tổng thể bị ảnh hưởng, cần có phản hồi về việc kiểm soát kiểm thử. Nếu lịch trình tiến triển nhanh hơn, cần phải kiểm tra xem các trường hợp kiểm thử đã chuẩn bị có đủ hay không và đảm bảo rằng tất cả các trường hợp đều được thực hiện đầy đủ
Chất lượng hiện tại của đối tượng kiểm thử
Sử dụng dữ liệu về tình trạng thực hiện các trường hợp kiểm thử, số lượng lỗi phát sinh, số lượng lỗi đã được sửa chữa, để đánh giá chất lượng của đối tượng kiểm thử. Ví dụ, nếu số lượng trường hợp kiểm thử đã thực hiện là ít nhưng số lượng lỗi phát sinh lại nhiều, có thể đánh giá rằng việc tiếp tục kiểm thử sẽ có nguy cơ phát sinh thêm nhiều lỗi. Trong trường hợp này, cần phản hồi lại với việc kiểm soát kiểm thử.
Đánh giá tính đầy đủ của phương pháp kiểm thử
Đánh giá hiệu quả của phương pháp kiểm thử đã chọn. Ví dụ, nếu phương pháp kiểm thử có hệ thống được áp dụng và sử dụng danh sách các điều kiện kiểm thử tiêu chuẩn để thiết kế, nhưng lại phát hiện nhiều lỗi từ các điều kiện kiểm thử không có trong danh sách tiêu chuẩn, cần xem xét lại danh sách điều kiện kiểm thử tiêu chuẩn. Qua đó, cải thiện phương pháp kiểm thử thông qua việc kiểm soát kiểm thử.
Hiệu quả của hoạt động kiểm thử đối với mục tiêu kiểm thử
Dựa trên mục tiêu kiểm thử được thiết lập trong kế hoạch, đánh giá xem liệu kiểm thử đã được thực hiện đầy đủ hay chưa. Ví dụ, nếu mục tiêu kiểm thử bao gồm việc “đánh giá các sản phẩm công việc như yêu cầu, câu chuyện người dùng, thiết kế và mã nguồn”, thì sau khi đánh giá các sản phẩm công việc này, cần xác nhận rằng số lượng lỗi phát hiện trong quá trình kiểm thử đã giảm. Trong trường hợp này, có thể khó để phản hồi trực tiếp đánh giá các sản phẩm công việc vào việc kiểm soát kiểm thử trong suốt dự án, nhưng đó sẽ là bài học quan trọng để áp dụng trong các dự án phát triển trong tương lai.
Trong suốt thời gian thực hiện hoạt động kiểm thử, cần tiến hành các đánh giá này.
Tỷ lệ hoàn thành việc chuẩn bị các trường hợp kiểm thử đã lập kế hoạch
Theo dõi mức độ tiến triển của việc thiết kế và triển khai các trường hợp kiểm thử theo kế hoạch. Điều này giúp xác định còn bao nhiêu công việc cần hoàn thành trước khi bắt đầu thực hiện kiểm thử. Cụ thể, có thể sử dụng chỉ số đo lường số lượng các trường hợp kiểm thử đã được hoàn thành so với dự kiến. Ngoài ra, trong trường hợp thực hiện song song giữa việc viết script cho kiểm thử tự động và thực hiện kiểm thử, cần so sánh tiến độ của việc thực hiện kiểm thử với tiến độ viết script để điều phối công việc.
Tỷ lệ hoàn thành việc chuẩn bị môi trường kiểm thử đã lập kế hoạch
Tình trạng chuẩn bị môi trường kiểm thử khác nhau tùy thuộc vào đối tượng kiểm thử.
Ví dụ, trong kiểm thử phần mềm nhúng, có trường hợp cần bắt đầu từ việc mua sắm nhiều thiết bị phần cứng, dẫn đến khối lượng công việc lớn. Trong những trường hợp như vậy, mức độ tiến triển của việc chuẩn bị tất cả các môi trường kiểm thử cần thiết và thời điểm hoàn thành việc chuẩn bị sẽ là một chỉ số quan trọng để đưa ra quyết định bắt đầu thực hiện kiểm thử.
Thực hiện các trường hợp kiểm thử
Đo lường số lượng các trường hợp kiểm thử đã được thực hiện. Điều này giúp xác định số lượng trường hợp kiểm thử còn lại, từ đó luôn có thể ước tính thời gian cần thiết để hoàn thành việc thực hiện kiểm thử. Tuy nhiên, chỉ đo lường số lượng các trường hợp kiểm thử đã thực hiện thì chưa đủ để thu thập thông tin chính xác. Việc tính toán cần xem xét thời gian cần thiết để thực hiện từng trường hợp kiểm thử.
Thông tin về lỗi
Thông tin về lỗi bao gồm mật độ lỗi, số lượng lỗi được phát hiện và sửa chữa, tỷ lệ lỗi, và kết quả kiểm thử xác nhận. Dựa vào các thông tin này, có thể kiểm tra lại mức độ ưu tiên của các hoạt động kiểm thử hoặc điều chỉnh tài nguyên khi cần, giúp kiểm soát hiệu quả các hoạt động kiểm thử.
Công thức tính mật độ lỗi:
Mật độ lỗi = Số lượng lỗi ÷ Quy mô chương trình
Quy mô chương trình có thể được đo lường bằng số dòng mã nguồn, số câu lệnh, hoặc số điểm chức năng (function points). Trong khi đo lường số lượng lỗi hoặc quy mô chương trình, điều quan trọng là phải thiết lập các quy tắc thống nhất trên toàn bộ dự án (như thời điểm bắt đầu đo lường hoặc phạm vi đo lường). Nếu các quy tắc không rõ ràng, việc so sánh dựa trên các tiêu chí khác nhau có thể khiến giá trị mật độ lỗi trở nên không còn ý nghĩa.
Tỷ lệ lỗi đề cập đến số lần lỗi xảy ra trên một đơn vị thời gian, nhưng trong phát triển phần mềm, khái niệm lỗi khác với phần cứng. Ví dụ, tỷ lệ lỗi có thể được tính toán dựa trên số lượng lỗi xảy ra trong thời gian thực hiện kiểm thử so với tổng thời gian thực tế của công việc kiểm thử.
Mục đích, nội dung và đối tượng của báo cáo kiểm thử
Mục đích chính của báo cáo kiểm thử là chia sẻ kết quả của các hoạt động kiểm thử với các bên liên quan và cung cấp thông tin để tận dụng các kiến thức thu được trong giai đoạn bảo trì hoặc các dự án tương lai. Kết quả tóm tắt bao gồm các dữ liệu cụ thể như sự kiện xảy ra trong quá trình kiểm thử và ngày hoàn thành các tiêu chí kết thúc. Thông tin hữu ích cho các hoạt động tiếp theo bao gồm kết quả phân tích tổng thể về kiểm thử và các chỉ số.
Báo cáo kiểm thử được chia thành báo cáo tiến độ, được lập trong quá trình kiểm thử, và báo cáo tổng kết, được lập sau khi hoàn thành kiểm thử. Báo cáo tổng kết tóm tắt nội dung thực hiện dựa trên báo cáo tiến độ mới nhất và các thông tin liên quan. Nếu không tiến hành theo kế hoạch, cần ghi rõ lý do và biện pháp xử lý. Sử dụng các chỉ số để ghi nhận kết quả đánh giá tiêu chí kết thúc. Báo cáo cũng liệt kê các mục rủi ro chấp nhận được khi phát hành, làm rõ xác suất xảy ra và biện pháp đối phó với các vấn đề dự kiến. Ví dụ, nếu còn lỗi như “không thể đặt chỗ vào ngày 31/12 của năm nhuận”, cần giải thích lý do tại sao rủi ro này nằm trong phạm vi chấp nhận được. Ngoài ra, báo cáo còn liệt kê các sản phẩm có thể tái sử dụng.
Nội dung báo cáo tiến độ và tổng kết cần được điều chỉnh phù hợp với tính chất dự án, yêu cầu tổ chức, và vòng đời phần mềm. Đối với các dự án cập nhật phần mềm đơn giản, cần cân nhắc chi phí lập báo cáo và tối ưu hóa quy trình, như sử dụng định dạng chung cho phần “Mở đầu” và lược bỏ các thông tin rõ ràng hiển nhiên. Tuy nhiên, luôn phải báo cáo các rủi ro còn tồn đọng quan trọng. Trong phát triển Agile, có thể thay thế báo cáo tiến độ bằng các công cụ như bảng công việc (task board) hoặc biểu đồ burndown. Các cuộc họp hằng ngày (daily stand-up) thường được sử dụng để chia sẻ thông tin nhanh chóng.
Nội dung báo cáo cần được điều chỉnh để phù hợp với đối tượng đọc nhằm đảm bảo thông tin cung cấp là đầy đủ và phù hợp với nhu cầu của họ.
Báo cáo dành cho nhà phát triển và nhóm kiểm thử
Cung cấp thông tin ngắn gọn về số lượng các trường hợp kiểm thử đã lên kế hoạch, số lượng đã thực hiện, tình trạng phát sinh và sửa chữa lỗi. Nếu có nhiều lỗi phát sinh, cần ghi rõ ngày dự kiến sửa chữa và làm rõ lịch trình tiếp tục kiểm thử.
Báo cáo dành cho quản lý dự án
Thông thường, nội dung báo cáo dành cho nhà phát triển là đủ. Tuy nhiên, nếu có sự chậm trễ hoặc phát hiện lỗi ảnh hưởng đến tiến độ, cần cung cấp thông tin giúp quản lý dự án thực hiện kiểm soát kiểm thử. Ví dụ, liệt kê các loại lỗi và nhu cầu phân bổ tài nguyên cần thiết.
Báo cáo dành cho lãnh đạo
Tóm tắt ngắn gọn tình hình chung của dự án kiểm thử, tập trung vào chi phí, tiến độ và chất lượng với các đánh giá như “Tốt”, “Cần cải thiện”, v.v. Nếu có vấn đề, cần trình bày ngắn gọn lý do và cách xử lý hiện tại.
Quản lý cấu hình
Quản lý cấu hình, hay còn gọi là Configuration Management (CM) trong tiếng Anh, được gọi cụ thể là SCM (Software Configuration Management) trong lĩnh vực phần mềm. Quản lý này không chỉ bao gồm việc quản lý các thành phần mà còn đảm bảo kiểm soát phiên bản và duy trì khả năng truy xuất nguồn gốc (traceability).
Nói một cách đơn giản, “Quản lý cấu hình là việc quản lý và ghi nhận các thành phần tạo nên một sản phẩm tại một thời điểm cụ thể (phiên bản) sao cho có thể xác định duy nhất chúng.”
Ví dụ, khi chỉ định “phiên bản 1.1 của sản phẩm phần mềm A”, việc quản lý phiên bản phải đảm bảo rằng có thể lấy ra chính xác tất cả các thành phần cấu thành sản phẩm A, bao gồm tệp thực thi, các tệp cần thiết liên quan, hướng dẫn sử dụng, tài liệu trợ giúp, và những thành phần khác.
Ngoài ra, để xây dựng sản phẩm A, cần phải quản lý toàn diện mã nguồn, môi trường xây dựng, môi trường kiểm thử, tài liệu hướng dẫn sử dụng, trợ giúp, và thông tin đóng gói khác. Trạng thái trong đó các mối quan hệ giữa những yếu tố này có thể được theo dõi và truy xuất được gọi là khả năng truy xuất nguồn gốc (traceability).
Quản lý cấu hình trong kiểm thử
Trong kiểm thử phần mềm, quản lý cấu hình đóng vai trò quan trọng như thế nào?
Ví dụ, nếu dữ liệu đầu vào cần thiết cho một quy trình kiểm thử không được ghi lại, thì khi thực hiện lại bài kiểm thử đó hoặc thực hiện bài kiểm thử tương tự trên phiên bản tiếp theo, người kiểm thử sẽ phải tìm kiếm dữ liệu, gây lãng phí thời gian nhiều ngày. Thêm vào đó, nếu kịch bản kiểm thử để tái tạo lỗi phát hiện được trong một bài kiểm thử không rõ ràng, việc kiểm tra xác nhận sau khi sửa lỗi sẽ không thể thực hiện một cách suôn sẻ.
Trong quản lý cấu hình kiểm thử, không chỉ các thành phần của sản phẩm kiểm thử (mã nguồn, ví dụ: mã nguồn phần mềm) mà cả kế hoạch kiểm thử, quy trình, kịch bản, môi trường và kết quả kiểm thử đều được quản lý. Tất cả những yếu tố này đều phải được kiểm soát phiên bản và duy trì trạng thái liên kết với nhau. Hơn nữa, việc đảm bảo khả năng truy xuất nguồn gốc giữa sản phẩm kiểm thử (phần mềm) và các tài liệu kiểm thử là điều vô cùng quan trọng.
Tuy nhiên, thực tế là việc quản lý cấu hình kiểm thử thường bị tách biệt khỏi quy trình phát triển phần mềm thông thường. Một số tổ chức chỉ thực hiện quản lý phiên bản tài liệu và mã nguồn, trong khi việc quản lý dữ liệu kiểm thử và kịch bản kiểm thử lại bị bỏ qua. Một trong những lý do là quản lý cấu hình đòi hỏi kỹ thuật chuyên môn và tốn công sức, khiến nguồn lực không đủ để quản lý các tài liệu kiểm thử.
Tuy nhiên, cần tránh những sự cố như việc sử dụng quy trình kiểm thử cũ để thực hiện kiểm tra xác nhận, gây ra hiểu lầm rằng các lỗi đã được sửa, nhưng thực tế lỗi vẫn tồn tại khi phát hiện trong môi trường người dùng. Để ngăn ngừa điều này, quản lý cấu hình trong kiểm thử cũng quan trọng ngang với quản lý cấu hình phần mềm nói chung. Tiếp theo, chúng ta sẽ thảo luận về các đối tượng và quy trình thực hiện cụ thể của quản lý cấu hình trong kiểm thử.
Quy trình quản lý cấu hình phần mềm kiểm thử
Quy trình thực hiện quản lý cấu hình thông thường sẽ theo các bước dưới đây:
- Xác định đối tượng quản lý cấu hình
Trong quản lý cấu hình sản phẩm phần mềm, chủ yếu tập trung vào việc kiểm soát phiên bản. Từ các sản phẩm đầu ra đã được xác định là đối tượng quản lý cấu hình, cần lựa chọn những gì sẽ được quản lý cho từng dự án. Việc xác định các đối tượng và phương thức quản lý này cần phải được làm rõ ngay từ khi bắt đầu dự án (khi lập kế hoạch kiểm thử chính).
Đối với các dự án có quy mô lớn, cần phải bố trí người chuyên trách và sử dụng công cụ để quản lý. Tuy nhiên, vì khó có thể ghi chép toàn bộ từ ban đầu, việc chọn lựa đối tượng cần quản lý trong phạm vi khả thi sẽ phụ thuộc vào quy mô sản phẩm, đặc tính của sản phẩm và tài nguyên tổ chức. - Xác định phương pháp quản lý cấu hình
Với các đối tượng đã được chọn, cần xác định phương pháp ghi chép, công cụ sử dụng, có hay không người chuyên trách và mức độ chi tiết của ghi chép (ví dụ: tần suất ghi chép). Đặc biệt, đối với các kịch bản kiểm thử được cập nhật thường xuyên, cần thiết lập quy tắc quản lý và thời điểm thực hiện việc kiểm soát phiên bản.
Ví dụ, cần xác định rõ kịch bản kiểm thử nào tương ứng với tài liệu kiểm thử nào, kết quả thực hiện của kịch bản kiểm thử nào và dữ liệu kiểm thử đã sử dụng là gì, để liên kết các đối tượng quản lý với nhau. Việc đảm bảo khả năng truy xuất nguồn gốc (traceability) giúp dễ dàng nhận diện được các bài kiểm thử cần thực hiện khi chức năng phần mềm nào đó được chỉnh sửa, từ đó hỗ trợ kiểm thử hiệu quả và hiệu suất. - Ghi chép và lưu trữ thông tin
Sau khi xác định đối tượng và phương thức quản lý, việc bắt đầu quản lý cấu hình sẽ yêu cầu ghi chép thông tin như lịch sử cập nhật, thông tin phiên bản, v.v. Có thể sử dụng công cụ quản lý cấu hình hoặc ghi chép bằng tài liệu. Dù lựa chọn phương pháp nào, điều quan trọng là thông tin phải được ghi chép chính xác. - Quản lý liên tục và duy trì trạng thái có thể tham chiếu
Mặc dù giai đoạn đầu của dự án có thể đảm bảo ghi chép đầy đủ, nhưng theo thời gian, việc quản lý có thể trở nên lỏng lẻo. Nếu việc quản lý không đầy đủ, lợi ích của quản lý cấu hình sẽ không được tận dụng và có thể gây thêm gánh nặng.
Do đó, việc bố trí người chuyên trách, đào tạo sử dụng công cụ một cách hiệu quả và thường xuyên kiểm tra tình trạng quản lý là rất cần thiết để duy trì quản lý cấu hình một cách liên tục. Điều này sẽ đảm bảo rằng thông tin có thể được tham chiếu nhanh chóng và chính xác khi cần thiết.
※Bài test kiểm tra