Métricas en Testing: oro en polvo!

Días atrás leía un post publicado por el sitio Softwaretestinghelp y me inspiró para hablar de un tema que considero muy importante para todos los que trabajamos en el área de Testing/QA.

Quisiera hablarles de métricas, escala de medición, medición, medida. ¡Pará! ¿Esto acaso es un juego de palabras? ¡No! ¡Es oro en polvo a nuestro alcance!

Antes de comenzar a extenderme en el tema quiero que nos alineemos en cuanto a las definiciones que les cité:

Métrica: Es la escala de medición y el método utilizado para llevar a cabo la medición.

Escala de medición: Es una sucesión de medidas que permite organizar datos en orden jerárquico.

Medición: Es el proceso de asignar un número o categoría a una entidad para describir un atributo de esa entidad.

Medida: Es el número o categoría asignada a un atributo de una entidad al realizar una medición.

De una forma más sencilla podemos decir que la medición por ejemplo es hablar de km, horas, metros, segundos, etc. Mientras que la métrica es hablar de km/h ó m/s.

Siempre noté que el área en el cuál trabajo es una fuente inagotable de datos que nos permite generar casi cualquier información.

¿Qué pasa cuando en nuestros proyectos de Testing no hay métricas?

La falta de métricas y mediciones conduce a evaluaciones puramente subjetivas de la calidad del software y de las pruebas. Puede incluso generar disputas sobre el significado de los resultados de las pruebas. También da como resultado una falta de valor, efectividad y eficiencia a la hora de comunicar los resultados de las pruebas.

No solo debemos tener métricas y mediciones, también debemos definir las líneas de base para estas métricas. ¿Cuál es un “buen” resultado para una métrica dada? ¿Cuál es un resultado aceptable? ¿Cuál es un resultado inaceptable? Prácticamente todo puede someterse a una métrica y rastrearse a través de la medición.

Durante la planificación de las pruebas, establecemos expectativas, líneas de base. Como parte del control de las pruebas, podemos medir los resultados reales y las tendencias con respecto a estas expectativas y ajustar nuestro enfoque.

Cuando estés pensando en implementar métricas y su medición, debes considerar tres áreas principales: definición, interpretación e informes.

Definición: Para definir un conjunto de métricas de pruebas exitoso, este debe ser útil, oportuno y conciso. Evita un conjunto de métricas demasiado grande, ya que esto resultará difícil, costoso de medir, y a menudo, confuso para las partes interesadas en ellas.

Interpretación: Se debe garantizar que las interpretaciones sean uniformes de manera de minimizar disputas y opiniones distintas sobre los resultados, análisis y tendencias. No tiene sentido tener un programa de métricas si todos tienen una opinión completamente distinta sobre lo que significan los datos presentados.

Informes: Define tus métricas en función de tu público objetivo. No es lo mismo presentar las métricas a un equipo técnico de desarrollo que exponer resultados a un área de marketing.

Si piensas desarrollar tus propias métricas te recomiendo que utilices el modelo GQM (Goal, Question, Metric). En esta técnica, debemos definir un objetivo. Por ejemplo: para las pruebas, un objetivo es generar confianza. Con este objetivo en mente debemos descomponerlo en preguntas. La pregunta natural que surge al respecto es: “¿Cuánto del sistema ha sido probado?”. Por último, definimos que métricas nos ayudarán con estas preguntas. Tal es el caso de las métricas de cobertura que incluyen el porcentaje de requisitos que ha sido cubierto con nuestras pruebas.

Ten presente que los informes de métricas deben arrojar luz a la gerencia y a los interesados, evitando confundirlos. Los buenos informes de pruebas basados en métricas deben entenderse fácilmente, no ser demasiado complejos y no dar lugar a las ambigüedades. Por último, es necesario que atraigan la atención del espectador hacia lo que más importa y no hacia elementos triviales. De esta manera, los buenos informes de prueba basados en métricas y medidas ayudarán a la gerencia a guiar al proyecto hacia el éxito.

Para enriquecer el contenido de esta entrada les compartimos una compilación de métricas que hemos recabado. Si tienen duda sobre alguna lo dejan en los comentarios:

1. Defect Leakage = (Total Number of Defects Found in UAT/ (Total Number of Defects Found Before UAT – Invalid defect)) x 100
2. Defect Removal Efficiency = Number of defects resolved by the development team/ (Total number of defects at the moment of measurement) x 100
3. Defect Category = Defects belonging to a particular category/ Total number of defects x 100
4. Defect Severity Index (DSI) = Sum of (Defect * Severity Level) / Total number of defects x100
5. Review Efficiency (RE) = Total number of review defects / (Total number of review defects + Total number of testing defects) x 100
6. Test Case Effectiveness = (Number of defects detected / Number of test cases run) x 100
7. Test Case Productivity = (Number of Test Cases / Efforts Spent for Test Case Preparation)
8. Requirement Coverage = (Number of requirements covered / Total number of requirements) x 100
9. Test Design Coverage = (Total number of requirements mapped to test cases / Total number of requirements) x 100
10. Defect Density = No. of Defects identified / Requeriment or LinesOfCode
11. Test Execution Coverage = (Total number of executed test cases or scripts / Total number of test cases or scripts planned to be executed) x 100
12. Passed Test Cases Coverage = (Number of passed tests / Total number of tests executed) x 100
13. Failed Test Case Coverage = (Number of failed tests / Total number of test cases executed) x 100
14. Test Cases Blocked = (Number of blocked tests / Total number of tests executed) x 100
15. Fixed Defects Percentage = (Defect fixed / Total number of defects reported) x 100
16. Accepted Defects Percentage = (Defects accepted as valid / Total defect reported) x 100
17. Defects Rejected Percentage = (Number of defects rejected by the development team / total defects reported) x 100
18. Defects Deferred Percentage = (Defects deferred for future releases / Total defects reported) x 100
19. Critical Defects Percentage = (Critical defects / Total defects reported) x 100
20. Average Time Taken to Rectify Defects = (Total time taken for bug fixes / Number of bugs)
21. Number of Test Run Per Time Period = (Number of test run / Total time)
22. Test Design Efficiency = (Number of tests designed /Total time)
23. Test review efficiency = (Number of test reviewed / Total time)
24. Bug Find Rate = (Total number of defects / Total number of test hours)
25. Number of Bugs Per Test = (Total number of defects / Total number of tests)
26. Average Time to Test a Bug Fix = (Total time between defect fix & retest for all defects / Total number of defects)
27. Test Effectiveness (TEF) = (Defects found before delivery / Defects found before delivery + Defects found after delivery) x 100
28. Quality Ratio: (Successful Tests Cases / Total Number of Test Cases) x 100
29. Defect Resolution Success Ratio = [(Total Number of Resolved Defects) – (Total Number of Reopened Defects)] / (Total Number of Resolved Defects) ] x 100
30. Rework Effort Ratio = (Actual rework efforts spent in that phase/ Total actual efforts spent in that phase) X 100
31. Schedule Variance = [(Actual efforts – estimated efforts ) / Estimated Efforts)] X 100