Software Testing Metrics and KPIs

1. Giới thiệu

Metrics có thể rất hữu ích cũng như rất có hại cho vòng đời phát triển và thử nghiệm của dự án. Nó phụ thuộc vào cách giải thích và sử dụng chúng. Trong bất kỳ loại tổ chức nào, nhà quản lý, người kiểm tra, nhà phát triển, v.v ... nói về các số liệu và cách thực hiện các phép đo đúng cách. Một số người trong số họ sử dụng các thước đo tiêu cực để đánh giá thành tích của các thành viên trong nhóm, mặt khác, một số người sử dụng các số liệu có liên quan, có ý nghĩa và sâu sắc để cải tiến quy trình, hiệu quả, kiến thức, năng suất, truyền thông, hợp tác và tâm lý. Nếu bạn đo lường các số liệu chính xác và minh bạch, chúng sẽ hướng dẫn bạn để hiểu sự tiến bộ của nhóm đối với các mục tiêu nhất định và thể hiện sự thành công và thiếu sót của đội.

Các loại số liệu này cần phương pháp tiếp cận "whole team" bởi vì tất cả nỗ lực của các thành viên nhóm đều nâng cao các kết quả số liệu này. Các số liệu dựa trên thời gian là rất quan trọng để tăng tốc độ của team. Chúng ta nên tự đặt ra một số câu hỏi dựa trên tốc độ, độ trễ, và vận tốc. Trong agile, một trong những thước đo được sử dụng nhiều nhất là Team Velocity. Nó chỉ cho chúng ta, bao nhiêu stories point (SP) mà đội giải quyết trong một cuộc chạy nước rút duy nhất và đây là một trong những thước đo cơ bản của Scrum. Nó được tính vào cuối mỗi lần chạy nước rút bằng cách tổng hợp các điểm Story đã hoàn thành.

Sự phát triển của Lean tập trung làm hài lòng người dùng cuối (khách hàng), là mục tiêu cho cả nhóm. Do đó, chúng ta cần phải đo lường các chỉ số kinh doanh như Return of Investment (ROI) và các chỉ số giá trị kinh doanh. Nếu mục tiêu kinh doanh chính của phần mềm là tiếp cận và giành được nhiều khách hàng hơn, chúng tôi cần cung cấp một phần mềm phục vụ cho mục đích này.

Cách tiếp cận này dựa trên số liệu nhiều hơn và theo cách này bạn nên nói chuyện với những con số như:

• Tổng số nỗ lực test và hiệu quả test (với sự chênh lệch về thời gian và chi phí)
• Số liệu thực hiện thử nghiệm (passed/failed/in progress/N/A ...)
• Hiệu quả kiểm tra (số lỗi tìm thấy trong hệ thống / tổng số lỗi được tìm thấy trong tất cả các giai đoạn)
• Tổng số lỗi và mức độ ưu tiên, mức độ nghiêm trọng, nguyên nhân gốc (dev, test, UAT, stage, live)
• Thời gian fix lỗi (thời gian fix lỗi của dev)
• Tỷ lệ Rejection lỗi (Tỷ lệ các khiếm khuyết bị từ chối / không hợp lệ / sai / trùng lặp)
• Tỷ lệ Reopen lỗi (Tỷ lệ lỗi cố định thành công)
• Defect Density (thơi gian phát triển hoặc số dòng mã)
• Tỷ lệ phát hiện lỗi (thời gian test)
• Test Coverage, Requirement Coverage, ...

2. Một số chỉ số kiểm thử phần mềm.

2.1 Số User Stories (Agile Scrum)

• Số stories trông mỗi sprint.

2.2. Số Test Cases

• Số test cases trong mỗi project/phase/product/tester/story ... Bạn có thể tạo ra nhiều chỉ số dựa trên số TCs.

2.3 Quy trình test

Đây là tiến độ thực hiện của 1 sprint, project, phase, or custom period.

• Passed Test Cases
• Failed Test Cases
• Blocked Test Cases
• In Progress Test Cases
• Retested Test Cases
• Postponed Test Cases

2.4 Test Tasks cho Tester

Đó là một sự phân bố các nhiệm vụ test trong nhóm của bạn. Nếu bạn sử dụng JIRA, bạn có thể dễ dàng thu thập thông tin này với truy vấn JQL và biểu đồ biểu đồ hình tròn.

2.5 Test Tasks Status

Bạn có thể giám sát số liệu này cho mỗi sprint, project, or a defined time period.

2.6 Test Tasks cho mỗi Projects

Nó cho thấy có test tasks trong mỗi dự án trong một khoảng thời gian nhất định.

2.7 Phân bổ viết Test Case Tasks cho Tester

2.8 Test Case Writing Tasks Status

Đó là trạng thái viết TCs trong một khoảng thời gian nhất định.

2.9 Test Case Writing Tasks cho mỗi Projects

Bạn có thể nhận được bao nhiêu task viết TCS cho mỗi dự án trong một khoảng thời gian nhất định.

2.10 Tổng số bug mà tester phát hiện được

2.11. Worklog của Testers trong mỗi Tasks

2.12. Requirement Coverage

Số liệu này cho thấy bao nhiêu TCs bao phủ được requirement

**2.13 Số bug tìm thấy trong phần mềm **

Số liệu này cho biết số bug tìm thấy trong phần mềm. Nó cho thấy sự phát triển của bạn, hệ thống, mạng, vv chất lượng. Bạn phải phân tích Pareto để tìm và ưu tiên các vấn đề chính của bạn.

2.14 Biểu đồ bug

Biểu đồ này cho thấy số lượng lỗi tích lũy trong một khoảng thời gian nhất định.

2.15 Test Case Execution Activity

Điều này cho thấy tình trạng thực thi test trong một khoảng thời gian nhất định.

2.16 Test Case Activity mỗi ngày

Số liệu này cho thấy có bao nhiêu TCs được tạo và cập nhật mỗi ngày.

2.17 Test Case được phân cho mỗi Tester

Điều này cho thấy có bao nhiêu TCs được viết bởi mỗi tester trong một nhóm.

3. Giới thiệu 1 số công thức tính effort

3.1. Cost cho mỗi bug được phát hiện đối với tester

Đây là tỉ lệ test effort và bug count trong mỗi 1 thời kỳ như 1 sprint

Ví dụ: 4 tester thực hiện test trong 2 ngày và tìm thấy 10 lỗi.

4 người * 2 ngày * 8 giờ = 64 giờ

64/10 = 6.4 giờ / Error

Các testers mất 6,4 giờ để tìm ra 1 lỗi.

Tôi nghĩ đây là chỉ số rất thấp. Nó có thể khó đo lường. Chúng ta nên tập trung vào việc cung cấp các sản phẩm có giá trị, có khiếm khuyết, chất lượng cao, nhanh chóng, an toàn, có thể sử dụng được.

3.2 Cost cho mỗi bug được phát hiện đối với developer

Đây là tỷ lệ giữa nỗ lực phát triển và các lỗi được phát hiện trong một khoảng thời gian nhất định.

Ví dụ: 5 lập trình viên có 5 ngày coding. Tổng cộng có 100 lỗi được tìm thấy.

5 người * 5 ngày * 8 giờ = 200 giờ

200/100 = 2 giờ

Điều này cho thấy, trong 2 giờ coding, 1 lỗi nảy sinh.

3.3 Defect Clustering

Đây là báo cáo cho thấy có bao nhiêu lỗi đã được tìm thấy trong mỗi mô-đun của sản phẩm trong một khoảng thời gian nhất định.

Ví dụ: 20% bugs được tìm thấy trong module Tìm kiếm Việc làm và 30% được tìm thấy trong màn hình Quản trị viên.

3.4 Tỉ lệ thành công của 1 sprint

Tỉ lệ thành công của 1 sprint = (Successful Sprint # / Total Sprint #) * 100

Mục tiêu cảu 1 sprint được chấp thuận bởi PO vào cuối mỗi sprint. Tất cả thống kê sprint thành công được thu thập và tỷ lệ phần trăm sprint thành công được tính toán. Một số nhóm agile sẽ sử dụng chỉ số này như KPI .

3.5 Ti lệ chất lượng

Ti lệ chất lượng = (Successful Test Cases/ Total Test Cases) * 100

Nó là một số liệu dựa trên tỷ lệ passes/ failed của tất cả TCs chạy trong một dự án theo thời gian xác định. Vui lòng không sử dụng số liệu này để đánh giá cá nhân. Tập trung vào các vấn đề và cố gắng giải quyết chúng. Nếu bạn sử dụng số liệu này làm KPI, nó có thể gây ra sự cố giữa tester và dev trong vòng đời phát triển phần mềm. Dev muốn tester mở ít lỗi hơn và tester có thể có xu hướng mở ít lỗi hơn để giữ "Tỷ lệ Chất lượng" cao hơn. Hãy cẩn thận về số liệu này.

3.6 Tiêu chí để viết Test Case :

• Test cases phải được viết để tìm được bugs.
• Requirements cần phải được hiểu chính xác.
• Các khu vực bị ảnh hưởng cần được xác định.
• Dữ liệu test phải chính xác và bao gồm tất cả các tình huống có thể.
• Các kịch bản thành công và thất bại phải được đề cập đến.
• Các kết quả mong đợi phải được viết đúng và rõ ràng.
• Test & Requirement phải được thiết lập đầy đủ.
• Khi các bài kiểm tra tương tự được lặp lại lặp đi lặp lại, tests bao gồm các TCs tương tự không còn tìm thấy các lỗi mới. Để khắc phục nghịch lý này, cần phải thường xuyên kiểm tra các TCs, nên viết cácTCs mới cho những lỗi tiềm ẩn trong phần mềm và trong các phần khác nhau của hệ thống.
• Mỗi kịch bản thử nghiệm phải hoàn toàn bao phủ một yêu cầu.
• Không nên có các requirements hoặc test scenarios có thể được viết bằng chữ "có thể", "có thể", "chính xác".

3. 7 Tỉ lệ UAT Defect Leakage/Slippage

Tỉ lệ lack bug = (Tổng số bugs UAT) / ((Tổng số bugs Kiểm tra Hợp lệ) + (Tổng số Các lỗi UAT)) * 100

UAT Defects: Các yêu cầu đã được mã hoá, các bài kiểm tra đơn vị đã được thông qua, thực hiện kiểm tra hoàn thành bởi các chuyên gia kiểm tra và sau đó được kiểm tra bởi PO trong môi trường UAT và các lỗi được tìm thấy bởi PO trong quá trình UAT.

Cả hai đội DEV và TEST đều chịu trách nhiệm gửi đơn xin lỗi đến UAT. Người ta hy vọng lỗi trong UAT sẽ thấp hơn số lỗi chính xác được tìm thấy trong quá trình thử nghiệm và phát triển. Nếu UAT lỗi vượt qua các lỗi TEST, chúng ta có thể nói rằng có một vấn đề đáng kể trong giai đoạn phát triển và thử nghiệm. Bằng cách chia các lỗi tìm thấy trong UAT với tổng của các lỗi UAT + TEST và nhân kết quả đó bằng 100, theo cách này UAT Defake Leakage thu được. Một số nhóm sử dụng chỉ số này làm KPI cho người kiểm tra và phát triển của họ.

1. Các lỗi kiểm tra hợp lệ trong môi trường thử nghiệm = 211

2. Các lỗi trong môi trường UAT = 13

3. UAT Leakage Ratio = (13 / (211 + 13)) * 100 =% 5,8

Lưu ý: Đo lường này được tính thêm một bước nữa bằng cách nhân mỗi lỗi với các ưu tiên và mức độ nghiêm trọng của chúng. Với phương pháp này, điểm lỗi được thu được theo mức độ ưu tiên và mức độ nghiêm trọng của chúng.

Trivial: 0 Point, Minor: 1 Point, Major: 2 điểm, Critical: 3 điểm, Blocker: 4 điểm

3.8 Hiệu quả của việc loại bỏ lỗi trước khi đưa lên staging

Hiệu quả loại bỏ lỗi = (Số lượng lỗi (Test + UAT)) / Tổng số (Kiểm tra + UAT + giai đoạn) Bị khiếm khuyết) * 100

Nó cho thấy thành công của các khuyết tật được phát hiện trước khi chuyển sang môi trường staging. Test Defects> UAT Defects> Staging Defects. Với Chỉ số này, chúng ta sẽ đo lường thành tích phát hiện lỗi và hiệu quả loại bỏ trước khi test trên môi trường Staging.

Ví dụ: Nếu có 20 TCs, 10 UATs, 5 Staging Defects, hiệu quả loại bỏ lỗi được tính như sau: (30/35) * 100 = 85,7% Loại bỏ lỗi. Một số nhóm đang sử dụng chỉ số này làm KPI.

Bạn cũng có thể đo lường hiệu quả loại bỏ lỗi của mình trước khi đưa lên Production.

3.9 Tỷ lệ thành công trong giải quyết lỗi

Tỉ lệ Defect Resolution Success = (Tổng Số lỗi đã Giải quyết - Số lỗi Tổng Số Được Reopened) / Số lỗi Đã giải quyết) * 100

Đó là chỉ số KPI cho thấy có bao nhiêu resolved bugs được reopened. Lý tưởng hơn, nếu tất cả các lỗi không được mở lại, thành công 100% về mặt giải quyết. Nếu 3 trong số 10 lỗi được mở lại, độ resolved bug thành công sẽ là (10-3) / 10) * 100 = 70%.

Ngược lại, nếu bạn trừ tỷ lệ này từ 100 sẽ cho chúng ta "Defect Fix Rejection Ratio".

3.10 Tỉ lệ Retest

Tỉ lệ Retest = (Total Count of Reopened Defects/(Total Number of Resolved Defects + Total Count of Reopened Defects) * 100

Đây là thước đo cho biết số lần một bug là REOPEN và RETEST một lần nữa. Mỗi lần mở lại bug sẽ phải được kiểm tra lại và số liệu này sẽ cho thấy tỷ lệ hiệu quả mà chúng tôi đã mất trong kiểm tra lại các bug đã được giải quyết.

Tổng số bug đã reopen = Tổng Số bug retest

Ví dụ: nếu không có lỗi trong 10 lỗi được reopen:

(0 / (10 + 0)) * 100 = 0

0% Tỷ lệ Retest cho thấy chúng ta đã không mất bất kỳ nỗ lực để test lại.

Ví dụ: nếu 10 bug được reopen 30 lần:

(30 / (10 + 30)) * 100 = 75

Tỷ lệ kiểm tra lại là 75% cho thấy rằng chúng ta mất 75% là nỗ lực restest trong tất cả các bugs cần test.

Một số tổ chức sử dụng chỉ số này làm KPI để đánh giá các nhóm phát triển.

3.11 Tỉ lệ rejected bug

Tỉ lệ rejected bug = (Số (Test + Staging) Rejected bug/ Tổng số (Test + Staging) bugs) * 100

Đây là thước đo đánh giá tình trạng bugs mà kỹ sư kiểm tra đã open. Số liệu này sẽ có thể sử dụng để đánh giá hiệu quả công việc. Quá nhiều rejected bugs chỉ ra sự thiếu hiệu quả và mất thời gian trong chu trình phát triển phần mềm. Một số tổ chức sử dụng chỉ số này làm KPI cho các nhóm Tester của họ.

Tổng số (Test + Staging) Bugs : 217

Rejected (Test + Staging) bugs : 3

Tỉ lệ rejected bug = (3/217)*100 = %1,38

Không nên sử dụng số liệu này làm KPI của tester.

Refer: http://www.swtestacademy.com/software-testing-metrics-kpi/