Software Testing Metrics & KPIs - phần 2

13. Test Tracking & Efficiency:

Test Tracking là một thành phần quan trọng cần được đánh giá kỹ lưỡng. Đó là một thuộc tính chất lượng của nhóm kiểm thử được đo lường để đảm bảo tất cả các hoạt động kiểm thử được thực hiện một cách hiệu quả. Các số liệu khác nhau hỗ trợ theo dõi kiểm thử và tính hiệu quả như sau:

1. Passed Test Cases Coverage:

Dùng để đo lường phần trăm số test case đã đạt

(Số lượng test case đạt/ Tổng số test case đã thực hiện)x100

2. Failed Test Case Coverage:

Dùng để đo lương phần trăm số test case lỗi

(Số lượng test case đạt/ Tổng số test case đã thực hiện)x100

3. Test Cases Blocked:

Đưa ra phần trăm số test case bị chặn trong cả quá trình kiểm thử phần mềm

(Số lượng test bị chắn / Tổng số test đã thực hiện) x 100

4. Fixed Defects Percentage:

Cùng với các số liệu, team có thể định nghĩa ra phần trăm các lỗi đã được sửa

(Số lỗi đã được sửa / Tổng số lỗi đã báo cáo)x100

5. Accepted Defects Percentage :

Tìm ra tổng số lỗi được chấp nhận bởi đội phát triển. Nó cũng được đo đạc bằng phần trăm

(Số lỗi được chấp nhận / Tổng số lỗi đã báo cáo)x100

6. Defects Rejected Percentage:

Một số liệu quan trọng khác được xem xét để theo dõi kiểm thử và tính hiệu quả là tỷ lệ phần trăm lỗi bị nhóm phát triển từ chối.

(Số lỗi bị từ chối bởi nhóm phát triển/Tổng số lỗi đã báo cáo) x 100

7. Defects Deferred Percentage:

Xác định tỷ lệ phần trăm lỗi được nhóm trì hoãn cho các bản phát hành trong tương lai

(Lỗi được trì hoãn cho các bản phát hành trong tương lai / Tổng số lỗi đã báo cáo) x 100

8. Tỉ lệ lỗi nghiêm trọng:

Đo đạc tỉ lệ lỗi nghiêm trọng cho phần mềm.

(Tỉ lệ lỗi nghiêm trọng/ Tổng số lỗi đã báo cáo) x100

9. Average Time Taken to Rectify Defects:

Thời gian trung bình được thực hiện để khắc phục lỗi. Với sự hỗ trợ của công thức này, các thành viên trong nhóm có thể xác định thời gian trung bình mà nhóm phát triển và kiểm thử thực hiện để khắc phục các lỗi.

(Tổng số thời gian dành cho khắc phục lỗi / Tổng số lỗi)

14. Test Effort Percentage:

Một số liệu kiểm thử quan trọng, tỷ lệ effort kiểm thử đưa ra đánh giá về những gì được ước tính trước khi bắt đầu quá trình kiểm thử so với những effort thực tế bỏ ra bởi đội ngũ những người kiểm thử. Nó giúp hiểu được bất kỳ phương sai nào trong kiểm thử và cực kỳ hữu ích trong việc ước tính các dự án tương tự trong tương lai. Tương tự như hiệu quả kiểm thử, các effort kiểm thử cũng được đánh giá với sự hỗ trợ của các số liệu khác nhau:

1. Số lượng kiểm thử được chạy ở mỗi giai đoạn:

Đội ngũ đo đạc con số kiểm thử đã thực hiện ở 1 khoảng thời gian xác định.

(Số lượng kiểm thử chạy / Tổng số thời gian)

2. Test Design Efficiency (Hiệu quả thiết kế kiểm thử):

Mục tiêu của số liệu này là đánh giá hiệu quả thiết kế của kiểm thử được thực hiện.

(Số lượng kiểm thử chạy / Tổng số thời gian)

3. Bug Find Rate (Tỉ lệ tìm bug):

Một trong những số liệu quan trọng sử dụng trong tỉ lệ effort kiểm thử là tỉ lệ tìm bug. Nó đo đạc số lỗi/bug được tìm thấy bởi đội trong suốt quá trình kiểm thử.

(Tổng số lỗi / Tổng số giờ kiểm thử)

4. Số bug mỗi lần test:

Theo tên của nó thì nó tập trung vào đo đạc số lỗi tìm thấy trong mỗi giai đoạn kiểm thử.

(Tổng số lỗi / Tổng số kiểm thử)

5. Thời gian trung bình để kiểm thử lỗi đã sửa:

Sau khi đánh giá các số liệu trên, đội cuối cùng cần xác định thời gian cần để kiểm thử lỗi đã sửa.

(Tổng số thời gian sửa và kiểm thử lại lỗi cho tất cả các lỗi / Tổng số lỗi)

15. Test Effectiveness:

Trái với hiệu suất, hiệu quả kiểm thử đo đạc và đánh giá lỗi, khả năng xảy ra lỗi cũng như chất lượng của bộ kiểm thử. Nó tìm thấy các lỗi và cách ly chúng khỏi sản phẩm phần mềm và các sản phẩm có thể chuyển giao của nó. Hơn nữa, các số liệu về hiệu quả kiểm thử cung cấp tỷ lệ phần trăm chênh lệch giữa tổng số lỗi được tìm thấy bởi kiểm thử phần mềm và số lỗi được tìm thấy trong phần mềm. Điều này chủ yếu được tính toán với sự hỗ trợ của công thức sau:

Test Effectiveness (TEF) = (Tổng số lỗi bị từ chối + Tổng số lỗi tìm thấy / Tổng số lỗi không tìm thấy) x 100

16. Test Economic Metrics:

Trong khi kiểm thử sản phẩm phần mềm, các thành phần khác nhau đóng góp vào chi phí kiểm thử như những người liên quan, tài nguyên, công cụ và cơ sở hạ tầng. Do đó, điều quan trọng đối với nhóm là đánh giá số lượng thử nghiệm ước tính, với chi tiêu thực tế trong quá trình thử nghiệm. Điều này đạt được bằng cách đánh giá các khía cạnh sau:

1.Tổng số chi phí của kiểm thử được phân bổ

2.Chi phí thực tế của kiểm thử

3.Phương sai từ ngân sách được dự đoán

4.Phương sai từ lịch trình

5.Chi phí cho việc sửa lỗi

6.Chi phí cho việc không kiểm thử

17. Test Team Metrics:

Cuối cùng, số liệu của nhóm thử nghiệm được xác định bởi cả nhóm. Số liệu này được sử dụng để hiểu rằng nếu công việc được phân bổ cho các nhóm kiểm thử khác nhau thì các thành việc sẽ được phân phối thống nhất và để xác minh xem có thành viên nào trong nhóm yêu cầu thêm thông tin hoặc làm rõ về quy trình thử nghiệm hoặc dự án hay không. Số liệu này vô cùng hữu ích vì nó thúc đẩy chuyển giao kiến thức giữa các thành viên trong nhóm và cho phép họ chia sẻ các chi tiết cần thiết liên quan đến dự án, mà không chỉ ra hoặc đổ lỗi cho một cá nhân về những bất thường và lỗi nhất định. Được thể hiện dưới dạng biểu đồ và đồ thị, điều này được thực hiện với sự hỗ trợ của các khía cạnh sau:

1.Những thông tin quan trọng như số lỗi đã báo cáo, được chấp nhận và từ chối

2.Các lỗi mở được phân phối để kiểm tra lại mỗi thành viên trong nhóm kiểm thử.

3.Test case được phân bổ cho mỗi thành viên trong nhóm kiểm thử

4.Số lượng test case được thực hiện bởi mỗi thành viên trong nhóm kiểm thử

(còn nữa)

Nguồn dịch: https://www.thinksys.com/qa-testing/software-testing-metrics-kpis/

Link phần trước : https://viblo.asia/p/software-testing-metrics-kpis-4dbZNqQkKYM