En el desarrollo de software, cualquier cosa que queramos medir se llama “Metrics”, métricas en castellano. Las mediciones son claves en todas las disciplinas (gestión de proyectos, la captura de requisitos, diseño de sistemas, desarrollo de software, pruebas, etc.)…hay una famosa frase que dice: “You cannot manage what you cannot (or do not) measure” (“No se puede gestionar lo que no se puede o lo que no medimos”). La métrica nos dirán si una actividad se está haciendo o no y cuando las cosas comienzan a deteriorar o mejorar, actúan como un punto de referencia para demostrar mejoras – o al menos para garantizar que no estamos empeorando!!!!!!!

Sin métricas estaríamos perdidos, ya que no sabríamos dónde estamos, hacia donde vamos y dónde hemos estado. Sin embargo, pese a que cualquier dato puede ser un sistema métrico, esto no significa que debamos estar todo el día creando nuevas métricas ya que algunos indicadores pueden no ser útiles en el contexto de nuestro proyecto / organización. Siempre que creemos nuevas métricas debemos tener en cuenta los siguientes factores:

• Tienen que tener un propietario, tiene que haber una persona que se responsabilice y asegure que los datos son recopilados y administrados.
• Los datos tiene que ser recopilados de forma fácil . Si el coste de recopilar los datos es superior al beneficio de la métrica deberíamos de plantearnos si realmente tiene sentido, ¿es nuestra métrica eficaz y eficiente?
• La información debe de ser clara y concisa, un sistema métrico no debe sólo incluir información correcta, sino que además debe ser plasmada de forma clara, de modo que sea fácilmente entendible por todo el mundo.
• Frecuencia de las métricas. Determinemos con que frecuencia debemos presentar la métrica. Un indicador que se entrega cada día, pero que se ignora, no añade ningún valor y es esfuerzo perdido.

Implementar un programa de mediciones puede parecer una tarea costosa, pero los beneficios siempre hacen que valga la pena. Así que, ¿cómo puede nuestra empresa iniciar un programa de métricas? Un buen marco de referencia sería la de utilizar el enfoque GQM: “objetivo, pregunta, medida” (Gol, Question, Measurement):

• Determina cuáles son las metas u objetivos de la medición.
• Decidir qué preguntas nos dirá si hemos logrado esa meta u objetivo.
• Identifica la escala de medición, los límites máximos y mínimos y su “target”.

Bueno, estos son sólo algunos factores que debemos tener en cuenta cuando comencemos a desarrollar un programa / sistema de métricas.

Las métricas son estándares para medir que se han estado usando en la industria del softwate, y en otros muchos sectores, para indicar la efectividad y la eficacia de una actividad en particular dentro de un proyecto. En este caso en particular estaré hablando de métricas en entornos de pruebas.

Las métricas existen en una gran variedad de formas. La pregunta no es si debemos utilizarlas, sino, cuales debemos utilizar. Lo más simple casi siempre es lo mejor.

En muchas ocasiones sabemos que hacer cambios en nuestro ciclo de vida de desarrollo nos puede ayudar a mejor la calidad de nuestro proyecto, pero siempre somos retizentes al cambio porque no sabemos que pasará. El uso regular de métricas durante el transcurso del proyecto, nos puedo aportar la información necesaria para conocer el estado del mismo, y por lo tanto ver la mejora. Aquí están algunos ejemplos de métricas que se pueden utilizar para conocer el progreso de los cambios durante las rondas de test.

Por ejemplo, imaginemos que nuestro equipo de calidad está en mitad de la ejecución de una ronda de test – menos del 50% de los test se han ejecutado. La mitad del tiempo ha transcurrido, pero menos de la mitad de las pruebas se han ejecutado. Inicialmente esto supone un problema para el equipo de testing, pero el Test Lead comenta que el 30% de los test cases están marcados como “Bloqueados”. El Test Lead explica que por un fallo en un módulo evitará que no se puedan ejecutar los casos de prueba marcados como “Bloqueados”. Por otra parte, la próxima “release” se efectuará dentro de 4 días y ninguno de los test cases “Bloqueados” se podrán ejecutar hasta entonces. En este punto podemos usar información objetiva disponible en las métricas para que nuestro Jefe de proyecto nos entrege una “release” interna con todos los problemas arreglados para que se puedan ejecutar los test cases bloqueados.

Por lo tanto, las métricas nos pueden proporcionar la información necesaria para tomar decisiones críticas, ahorrando tiempo y dinero. Esto hace que el equipo avanze con más rapidez.

¿Que métricas podemos usar?
sdsdsdLas métricas constituyen la información recopilada por un analista de pruebas durante varias rondas de test. Estas métricas se utilizan también a la hora de generar nuestro informe final (Final Test Report) que debemos entregar a nuestro Jefe de Proyecto. Estas son algunas de las métricas que podemos usar:

# de test cases
# de test cases Ejecutados
# de test cases “Passed”
# de test cases “Failed”
# de test cases “Blocked”
Tiempo de ejecución de los test cases
Total de errores
Total de Execuciones
Total de defectos

…y muchas otras, estos son sólo algunos ejemplos para que tengais una idea…

El cálculo
El cálculo de estas métricas convierten los datos en información más útil. Estos tipos de métricas generalmente son de gran ayuda a nuestro Jefe de Proyecto:

% Completado % Defectos corregidos
% Test Cases Passed % Test Effectiveness
% Test Cases Blocked % Test Efficiency
% Cobertura de Test

Conclusión
Estas métricas proporcionan información valiosa que a menudo nos ayudan a mejorar significativamente la calidad de nuestro proyecto. Por lo tanto, las métricas nos pueden proporcionar la información necesaria para tomar decisiones críticas, ahorrando tiempo y dinero. Así conseguiremos que el equipo avanze con más rapidez.