Làm cách nào để xác định, theo dõi, báo cáo và xác thực số liệu trong kiểm thử phần mềm?

Metrics - Chỉ số giúp đo trạng thái hiện tại của một hoạt động hoặc quy trình. Chúng giúp chúng tôi đặt điểm chuẩn và mục tiêu. Đo lường vị trí hiện tại của bạn giúp bạn thiết lập mức độ cần thiết để đạt được mục tiêu của mình. Người quản lý kiểm tra phải có khả năng xác định, theo dõi, báo cáo số liệu quá trình kiểm thử.

Những gì được đo thì sẽ thực hiện được là một câu nói phổ biến. Vì vậy, có thể suy ra rằng nếu một cái gì đó không đo được, nó sẽ không được thực hiện. Vì vậy, đó là điều cần thiết để thiết lập các số liệu định lượng để thử nghiệm.

4 loại chỉ số hoạt động thử nghiệm

Chỉ số các hoạt động kiểm thử phần mềm có thể được chia thành các phần sau:

• Project metrics - Đo mức độ dự án đang tiến tới các điều kiện xuất cảnh của nó. Ví dụ bao gồm phần trăm số test case chạy thành công, không thành công hoặc được thực hiện.
• Product metrics - Đo lường các đặc tính của sản phẩm như mật độ defects hoặc mức độ thử nghiệm.
• Process metrics - Đo lường khả năng của quá trình phát triển sản phẩm hoặc thử nghiệm. Ví dụ bao gồm số lượng lỗi màkiểm thử đã có thể phát hiện ra.
• People metrics - Đo lường mức độ kỹ năng và khả năng của các thành viên trong nhóm hoặc toàn bộ nhóm kiểm thử. Ví dụ bao gồm việc tuân thủ kế hoạch để thực hiện kiểm thử.

Bất kỳ chỉ số nào cũng có thể là một phần của nhiều danh mục được liệt kê ở trên. Ví dụ: nếu biểu đồ được chuẩn bị để ghi lại tỷ lệ mà tại đó lỗi được báo cáo hàng ngày, thì đó có thể là Project metrics, Product metrics hoặc Process metrics.

Nếu không có lỗi nào được báo cáo trong bảy ngày, dự án có thể được cho là an toàn để di chuyển về phía điều kiện thoát.

Nếu không tìm thấy nhiều khiếm khuyết trong sản phẩm, đó là thước đo chất lượng sản phẩm. Nếu một số lượng lớn các khuyết tật được phát hiện trong giai đoạn đầu của thử nghiệm, nó đo lường khả năng xử lý thử nghiệm.

Việc xử lý số liệu rất cẩn thận là rất quan trọng vì chúng có thể dễ dàng bị nhầm lẫn với các số liệu quá trình.

Nếu điều đó xảy ra, toàn bộ quá trình thử nghiệm có thể thất bại và mọi người có thể mất niềm tin vào người quản lý cũng như khả năng tổ chức của họ. Chúng ta sẽ xem xét cách thúc đẩy các nhóm thử nghiệm và đánh giá chúng dựa trên các chỉ số đã được thiết lập trong các mục sau đây.

Bài kiểm tra Trình độ kiểm tra cấp cao của ISTQB hỏi phần lớn về các chỉ số dự án. Một số chỉ số đo lường tiến trình thử nghiệm cũng là chỉ số đo lường quy trình và sản phẩm.

Số liệu hỗ trợ tester trong báo cáo kết quả kiểm tra và theo dõi tiến độ kiểm tra một cách nhất quán. Test manager thường trình bày các số liệu này tại các cuộc họp có sự tham dự của các bên liên quan ở các cấp khác nhau.

Vì các chỉ số này có thể được sử dụng để đánh giá tiến độ dự án tổng thể, cần phải cẩn thận khi xác định chỉ số nào phải được theo dõi, các kỹ thuật nào dùng để chuẩn bị báo cáo về số liệu và tần suất trình bày báo cáo như thế nào.

Đây là một số điểm mà người quản lý kiểm tra / quản lý chất lượng cần lưu ý:

• Định nghĩa số liệu - Số liệu được xác định, cần phải hữu ích. Số liệu không quan trọng nên được bỏ qua, giữ trong xem bốn phân loại được thảo luận ở trên. Tất cả các bên liên quan phải đồng ý với định nghĩa số liệu để tránh bất kỳ sự nhầm lẫn nào khi thảo luận về các phép đo. Vì một số liệu có thể đưa ra ý tưởng sai, nên chỉ định các số liệu sao cho chúng cân bằng lẫn nhau và cung cấp được bức tranh toàn thể.
• Theo dõi chỉ số - Theo dõi, kết hợp và báo cáo kết quả cho các số liệu phải được thực hiện tự động trong phạm vi khả thi để giảm thiểu công sức dành cho các hoạt động này. Test manager phải quan sát nếu có sai lệch so với kết quả mong đợi và kết hợp chúng vào báo cáo. Nếu có thể, các nguyên nhân của độ lệch cũng phải được đề cập.
• Báo cáo chỉ số - Số liệu được báo cáo cho quản lý cấp cao để quản lý dự án. Vì vậy, báo cáo lý tưởng phải ở dạng bản trình bày và làm nổi bật các giá trị số liệu quan trọng cũng như sự tiến hóa của các chỉ số trong một khoảng thời gian.
• Xác thực số liệu - Test manager chịu trách nhiệm xác minh dữ liệu và giá trị được trình bày trong báo cáo. Test manager cũng nên phân tích tính chính xác cũng như xu hướng được báo cáo.

Số liệu về Test Progress

Test progress được quan sát dựa trên 5 yếu tố sau:

• Rủi ro đối với chất lượng sản phẩm
• Lỗi sản phẩm
• Các kiểm thử được tiến hành
• Test coverage
• Niềm tin vào các hoạt động kiểm thử

Lỗi sản phẩm, rủi ro, kiểm tra và phạm vi thường được báo cáo theo định dạng được xác định trước. Nếu các chỉ số này tương quan với các điều kiện thoát được xác định trước, thì điểm chuẩn để đánh giá hoạt động kiểm thử có thể được phát triển.

Độ tin cậy có thể được đo lường chủ quan hoặc khách quan bằng cách sử dụng các số liệu như khảo sát và bảo hiểm.

Số liệu có thể được định nghĩa cho rủi ro chất lượng sản phẩm

• Tỉ lệ rủi ro đã được kiểm tra đầy đủ
• Tỉ lệ rủi ro trong đó tất cả hoặc ít nhất một số thử nghiệm thất bại
• Tỉ lệ rủi ro không thể kiểm tra đầy đủ
• Tỉ lệ rủi ro đã được kiểm tra hoặc phân loại theo loại rủi ro
• Tỉ lệ rủi ro được phát hiện sau phân tích sơ bộ các rủi ro đối với chất lượng sản phẩm

Số liệu có thể được định nghĩa cho các lỗi

• Tỷ lệ tổng số lỗi được phát hiện đối với số lỗi đã giải quyết
• Thời gian trung bình giữa thất bại hoặc tỷ lệ thất bại được báo cáo
• Phân loại các lỗi theo các yếu tố sau:
  • Các thành phần sản phẩm cần được kiểm tra
  • Lỗi nguyên nhân
  • Lỗi các nguồn như bổ sung các tính năng mới, hồi quy, đặc tả yêu cầu
  • Bản phát hành thử nghiệm
  • Mức độ lỗi
  • Lỗi ưu tiên hoặc mức độ nghiêm trọng
  • Báo cáo trùng lặp hoặc bị từ chối
  • Độ trễ thời gian giữa phát hiện lỗi và độ phân giải
• Lỗi con, tức là các lỗi gây ra do sửa lỗi khác

Số liệu có thể được định nghĩa cho kiểm thử

• Số lượng test đã lên kế hoạch
• Số lượng test đã thực hiện và thực thi
• Số lần test bị chặn, bỏ qua, thất bại hoặc thành công
• Trạng thái, xu hướng và giá trị cho regression test cũng như confirmation test
• Tỷ lệ giờ kiểm thử đã lên kế hoạch so với giờ kiểm thử thực tế hàng ngày

Số liệu có thể được định nghĩa cho phạm vi kiểm thử

• Phạm vi yêu cầu và tài liệu thiết kế
• Độ bao phủ (coverage) rủi ro
• Độ bao phủ của môi trường test hoặc thiết lập
• Mức độ phù hợp của code sản phẩm

Test manager phải thành thạo trong việc diễn giải và sử dụng các chỉ số về mức độ phù hợp để báo cáo về trạng thái kiểm thử. Phạm vi của tài liệu thiết kế và yêu cầu là cần thiết cho các cấp độ kiểm thử cao hơn như kiểm tra tích hợp, kiểm thử chấp nhận và kiểm thử hệ thống.

Độ bao phủ của code được yêu cầu cho các cấp độ kiểm thử thấp hơn như kiểm thử đơn vị và thử nghiệm mức thành phần. Kết quả kiểm thử mức độ cao hơn không nên bao gồm code coverage.

Cần lưu ý rằng mặc dù 100% mục tiêu coverage là ở các cấp thấp hơn, lỗi sẽ được phát hiện ở các cấp cao hơn và được sửa cho phù hợp.

Chỉ số kiểm thử có thể liên quan đến các hoạt động kiểm thử chính. Điều này sẽ giúp giám sát tiến độ kiểm thử đối với các mục tiêu dự án đã nêu.

Số liệu có thể được định nghĩa để theo dõi và kiểm soát lập kế hoạch kiểm thử

• Phạm vi của các yếu tố cơ sở của kiểm thử như rủi ro, yêu cầu sản phẩm, v.v.
• Phát hiện lỗi
• Tỷ lệ số giờ ước tính cần thiết trong quá trình phát triển kiểm thử và thực hiện tổng số giờ yêu cầu

Số liệu có thể được định nghĩa để phân tích kiểm thử

• Có bao nhiêu điều kiện thử nghiệm đã được biết?
• Có bao nhiêu lỗi được phát hiện?

Số liệu có thể được định nghĩa cho thiết kế kiểm thử

• Tỉ lệ các điều kiện kiểm thử có test case
• Trong quá trình thiết kế kiểm thử (ví dụ, khi test basis được sử dụng để phát triển các kiểm thử), có bao nhiêu lỗi được phát hiện

Số liệu có thể được định nghĩa để triển khai thử nghiệm

• Tỷ lệ môi trường kiểm thử đã được thiết lập
• Tỷ lệ hồ sơ dữ liệu kiểm thử đã được tải lên
• Tỷ lệ các test case được tự động hóa

Số liệu có thể được định nghĩa để thực thi thử nghiệm

• Tỷ lệ phần trăm các trường hợp kiểm thử đã chạy, thành công hoặc không thành công
• Tỷ lệ tiêu chí kiểm tra được bao phủ bởi các trường hợp thử nghiệm đã được chạy thành công
• Tỷ lệ lỗi dự kiến đối với các lỗi thực tế đã được báo cáo hoặc giải quyết
• Tỷ lệ phạm vi kiểm tra ước tính đối với phạm vi phủ sóng thực có thể đạt được

Số liệu được định nghĩa để quan sát tiến trình thử nghiệm

Số liệu được xác định để quan sát tiến trình của các hoạt động kiểm tra phải thích hợp cho các mốc quan trọng của dự án, điều kiện nhập kiểm thử và điều kiện thoát thử. Một số chỉ số này có thể là:

• Số trường hợp, điều kiện hoặc thông số kỹ thuật được xác định trước đã được thực hiện, với kết quả của chúng (vượt qua hoặc thất bại)
• Các lỗi phát hiện được phân loại theo mức độ nghiêm trọng, tầm quan trọng, thành phần sản phẩm bị ảnh hưởng, v.v.
• Chi tiết về các sửa đổi cần thiết và trạng thái của chúng được kết hợp và/hoặc kiểm thử
• Chi phí ước tính so với chi phí thực
• Thời gian kiểm thử ước tính so với thời gian thực
• Ngày dự kiến cho milestone kiểm thử của dự án so với ngày thực tế
• Các mốc thời gian ước tính của các hoạt động kiểm thử so với ngày thực của chúng
• Chi tiết về rủi ro đối với chất lượng sản phẩm được phân loại thành giảm nhẹ và không được điều chỉnh
• Các thành phần nguy cơ chính
• Rủi ro được phát hiện tiếp theo để phân tích kiểm thử
• Thời gian và công sức kiểm thử vì các sự kiện bất ngờ hoặc dự kiến
• Trạng thái kiểm thử hồi quy và kiểm thử xác nhận

Số liệu để đánh giá tác vụ đóng kiểm thử

Các chỉ số sau đây có thể được thiết kế để đo lường các tác vụ liên quan đến việc đóng kiểm thử:

• Số lượng các test case
  • Thuộc một trong các các phân loại sau - run, passed, failed, skipped and blocked
  • Đã trở thành một phần của kho lưu trữ các test case có thể sử dụng lại
  • Đã được tự động so với số lượng thực tế các trường hợp được tự động hóa
• Số lỗi đã được giải quyết hoặc không được giải quyết
• Số lượng sản phẩm công việc kiểm thử được lưu trữ

Quá trình kiểm thử cũng được giám sát thông qua các kỹ thuật quản lý khác như cấu trúc phân tích công việc. Các sản phẩm được phát triển bằng kỹ thuật Agile theo dõi quá trình kiểm thử trên Burn down chart. Trong quản lý Lean, tiến trình kiểm tra được giám sát bằng cách tạo ra một thẻ test store trên cột của bảng Kanban.

Đối với nhóm chỉ số được xác định trước, báo cáo có thể được tạo bằng lời nói, dưới dạng dữ liệu dạng bảng hoặc trực quan dưới dạng biểu đồ và biểu đồ. Các giá trị số liệu thu được có thể được sử dụng cho nhiều thứ, như:

• Hiểu nguyên nhân của các lỗi và xác định xu hướng, nếu có
• Tạo báo cáo cho nhóm quản lý dự án và các bên liên quan khác
• Sửa đổi quá trình kiểm thử nếu cần và giám sát việc thực hiện các kiểm thử đã sửa đổi

Ở đây không có cách nào chính xác để thu thập và phân tích các số liệu hoặc tạo báo cáo bằng cách sử dụng chúng. Nó phụ thuộc vào mục tiêu và yêu cầu của dự án và loại và mức độ kỹ năng của người sử dụng các báo cáo.

Các số liệu được thu thập thông qua quá trình kiểm thử phải hỗ trợ Test manager trong việc giám sát việc kiểm thử và dẫn đến việc hoàn thành thành công.

Do đó, các số liệu, số lượng và tần suất thu thập dữ liệu, độ phức tạp và rủi ro của nó liên quan đến nó phải được thiết lập trong chính giai đoạn lập kế hoạch.

Các điều kiện của dự án có thể tiếp tục thay đổi trong suốt vòng đời phát triển phần mềm.

Hoạt động kiểm soát kiểm thử

Kiểm soát kiểm thử phải có khả năng sửa đổi các kiểm thử theo môi trường dự án thay đổi và dữ liệu được cung cấp bởi các thử nghiệm.

Ví dụ, hãy xem xét kịch bản mà kiểm thử động của một sản phẩm cho thấy cụm các lỗi ở các khu vực được giả định là không có lỗi, thời gian có sẵn để thử nghiệm bị giảm do sự chậm trễ trong phát triển. Điều này sẽ yêu cầu sửa đổi phân tích rủi ro và kế hoạch. Trong trường hợp này, các kiểm thử sẽ phải được ưu tiên lại và phân bổ công sức để kiểm thử sẽ phải được xem xét lại.

Luôn cập nhật thông tin mới, kế hoạch kiểm thử nên được xem xét lại, các test case mới được tạo ra và phân phối lại công sức kiểm thử.

Nếu các báo cáo về điểm tiến độ kiểm thử đến sai lệch so với kế hoạch kiểm thử, các hoạt động kiểm soát kiểm thử phải được thực hiện để chỉ đạo kiểm thử theo hướng chính xác.

Một số hành động có thể được xem xét cho điều này bao gồm:

• Sửa đổi trình tự kiểm thử hoặc kế hoạch kiểm thử
• Xem xét phân tích rủi ro chất lượng
• Tăng cường công việc kiểm thử
• Lên lịch phát hành ngày phát hành sản phẩm
• Thay đổi điều kiện thoát kiểm tra
• Sửa đổi phạm vi dự án theo yêu cầu

Tất cả các bên liên quan và người quản lý dự án phải đồng ý trước khi có thể thực hiện bất kỳ bước nào trong số các bước này.

Dữ liệu được cung cấp trong bất kỳ báo cáo kiểm thử nào đều tùy thuộc vào đối tượng dự định. Vì vậy, một báo cáo cho người quản lý dự án sẽ có báo cáo lỗi chi tiết trong khi báo cáo cho người quản lý doanh nghiệp nên tập trung vào rủi ro sản phẩm.

Tài liệu tham khảo

http://tryqa.com/how-to-define-track-report-validate-use-metrics-in-software-testing/