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ư:
Đây là tiến độ thực hiện của 1 sprint, project, phase, or custom period.
Đó 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.
Bạn có thể giám sát số liệu này cho mỗi sprint, project, or a defined time period.
Nó cho thấy có test tasks trong mỗi dự án trong một khoảng thời gian nhất định.
Đó là trạng thái viết TCs trong một khoảng thời gian nhất định.
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.
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.
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.
Đ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.
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.
Đ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.
Đâ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.
Đâ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.
Đâ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.
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 .
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.
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ọ.
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
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.
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”.
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.
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.
https://viblo.asia/p/software-testing-metrics-and-kpis-m68Z0wv2KkG
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
