code coverage - pruebas - Métricas de desarrollo de software y reportes

metricas de pruebas de software

Question

Recientemente he tenido algunas conversaciones interesantes sobre las métricas de desarrollo de software, en particular, cómo se pueden usar en una organización razonablemente grande para ayudar a los equipos de desarrollo a funcionar mejor. Sé que ha habido preguntas sobre el desbordamiento de pila sobre qué métricas son buenas de usar, como esta , pero mi pregunta es más sobre qué métricas son útiles para qué partes interesadas , y en qué nivel de agregación .

Como ejemplo, mi opinión es que la cobertura de código es una medida útil de las siguientes maneras (y tal vez otras):

• Para uso interno propio de un equipo cuando se combina con otras mediciones.
• Para los equipos de facilitación / habilitación / tutoría, donde podría ser instructivo cuando se considera una tendencia de equipo por equipo (por ejemplo, si el equipo A y B tienen cobertura este mes de 75 y 50, estaría más preocupado con el equipo A que B si el mes anterior hubieran tenido 80 y 40).
• Para la alta gerencia cuando se presenta como una estadística agregada a través de una cantidad de equipos o un departamento completo.

Pero no creo que sea útil para la alta dirección ver esto equipo por equipo, ya que esto alienta los intentos artificiales de reforzar la cobertura con pruebas que simplemente ejercen el código en lugar de probarlas.

Estoy en una organización con un par de niveles en su jerarquía de administración, pero donde la gran mayoría de los gerentes tiene una mente técnica y capacidad (muchos todavía se ensucian las manos). Algunos de los equipos de desarrollo están liderando el camino hacia las prácticas de desarrollo ágil, pero otros se quedan atrás, y ahora hay un mandato serio desde la cima para que esto sea la forma en que funciona la organización. Algunos de nosotros estamos comenzando un programa para alentar esto. En este tipo de organización, ¿qué tipo de métricas crees que son útiles, para quién, por qué y en qué nivel de agregación?

No quiero que las personas sientan que su desempeño está siendo evaluado en base a una métrica en la que pueden influir artificialmente; al mismo tiempo, la alta gerencia va a querer algún tipo de evidencia de que se están haciendo progresos. ¿Qué consejos o advertencias puede proporcionar según la experiencia en sus propias organizaciones?

EDITAR

Definitivamente queremos utilizar las métricas como una herramienta para el mejoramiento de la organización, no como una herramienta para la medición del desempeño individual.

Answer 1

Como dije en ¿Cuál es la fascinación con las métricas de código? , las métricas incluyen:

• diferentes poblaciones , lo que significa que el ámbito de interés no es el mismo para el desarrollador o para el administrador
• las tendencias que significan que cualquier métrica en sí misma carece de significado sin su tendencia asociada, para tomar la decisión de actuar sobre ella o ignorarla.

Estamos utilizando una herramienta capaz de proporcionar:

• muchas métricas de nivel micro (interesantes para desarrolladores), con tendencias.
• muchas reglas con capacidades de análisis estático multinivel (UI, Datos, Código)
• muchas reglas de agregación (lo que significa que esa gran cantidad de métricas se condensan en varios dominios de intereses, adecuados para un mayor nivel de poblaciones)

El resultado es un análisis que se puede profundizar, desde dominios de agregación de alto nivel (seguridad, arquitectura, prácticas, documentación, ...) hasta una línea de código.

La respuesta actual es:

• los gerentes de proyecto pueden ponerse a la defensiva muy rápidamente cuando no se respetan algunas reglas y hacer que su nota global sea significativamente menor.
  Cada estudio debe ser rediseñado para respetar las peculiaridades de cada proyecto.
  El beneficio es la definición de un contrato donde se reconocen las excepciones pero se definen las reglas a respetar.
• Los niveles superiores (departamento de TI, partes interesadas) utilizan las notas globales solo como un elemento de su evaluación del progreso realizado.
  Verán más de cerca otros elementos en función de los ciclos de entrega: ¿con qué frecuencia podemos iterar y poner en producción una aplicación ?, ¿cuántos errores tuvimos que resolver antes de esa publicación? (en términos de fusiones, o en términos de entorno de preproducción no configurado correctamente), ¿qué retroalimentación inmediata genera una nueva versión de una aplicación?

Asi que:

qué métricas son útiles para qué partes interesadas y a qué nivel de agregación

En el nivel alto:

• las métricas (análisis estático) son en realidad el resultado de agregaciones de métricas de bajo nivel y están organizadas por dominios.
• Se tienen en cuenta otras métricas (más " operational-oriented ", basadas en el ciclo de lanzamiento de la aplicación, y no solo en el análisis estático del código)
• El ROI real se logra a través de otras acciones (como estudios six-sigma )

En el nivel inferior:

• el análisis estático es suficiente (pero tiene que abarcar aplicaciones de niveles multinivel, con desarrollos a veces en múltiples idiomas)
• Las acciones son pilotadas por las tendencias e importancia.
• el estudio debe ser aprobado / respaldado por todos los niveles jerárquicos para ser aceptado / tomado en cuenta (en particular, el presupuesto para la refactorización posterior debe ser validado)

Answer 2

Curiosamente, acabo de terminar de leer PeopleWare , y los autores desaconsejan firmemente que las métricas individuales se hagan visibles a los superiores (incluso a los gerentes directos), pero las métricas agregadas deberían ser muy visibles.

En cuanto a las métricas específicas del código, creo que es bueno para un equipo conocer el estado del código en el momento actual y conocer las tendencias que afectan el código a medida que madura y crece.

Obviamente, la pregunta no está enfocada en .NET, pero creo que el producto .NET Depend ha realizado un gran trabajo para definir y documentar métricas comunes que son útiles.

La sección de documentación sobre métricas es lectura educativa , incluso si no está haciendo .NET.

Answer 3

Esta es una nota lateral a la pregunta principal, pero tuve una experiencia muy similar a la respuesta de Paul Stephenson anterior. Una cosa que agregaría a eso es sobre la recopilación de datos y la visibilidad de las métricas.

En nuestro caso, el director de desarrollo estaba destinado a recopilar una serie de datos de diversos sistemas dispares y distribuir resultados de mediciones individuales una vez al mes. Esto a menudo no sucedía, ya que era un trabajo que consumía mucho tiempo y era un hombre ocupado.

Los resultados de esto fueron:

1. Desarrolladores infelices, ya que las bonificaciones de rendimiento se basaban en métricas y las personas no sabían cómo les iba.

2. Algo de tiempo consumiendo entradas múltiples de datos en varios sistemas diferentes.

Si va por esta ruta, debe asegurarse de que todos los datos métricos se puedan recopilar automáticamente y sean fácilmente visibles para aquellos a quienes afecta.

Answer 4

La clave de las métricas es saber para qué las está utilizando. ¿Los está utilizando como una herramienta de mejora, una herramienta de recompensa, una herramienta de castigo, etc.? Parece que está planeando usarlos como una herramienta de mejora.

El principio número uno al establecer métricas es mantener la información relevante para que la persona que la recibe pueda usarla para tomar una decisión. Lo más probable es que un gerente senior no pueda dictar el nivel micro de si necesita más pruebas, menos complejidad, etc. Pero un líder de equipo puede hacer eso.

Por lo tanto, no creo que una medida de cobertura de código vaya a ser útil para la administración más allá del equipo individual. A nivel macro, la organización probablemente esté interesada en:

• Coste de entrega
• Puntualidad de la entrega
• Ámbito de entrega y calidad externa.

La calidad interna no será alta en su lista de cosas para cubrir. La misión de un equipo de desarrollo es dejar en claro que la calidad interna (mantenibilidad, cobertura de prueba, código de auto-documentación, etc.) es un factor clave para lograr los otros tres.

Por lo tanto, debe dirigir las métricas a más gerentes senior que cubran esos tres, tales como:

• Velocidad general (tenga en cuenta que comparar la velocidad entre equipos suele ser artificial)
• Alcance esperado vs real entregado a los plazos acordados
• Número de defectos de producción (posiblemente per cápita)

Y mida cosas como la cobertura del código, la complejidad del código, la puntuación de cortar y pegar (repetición del código usando desollar o similar), la longitud del método, etc. a nivel de equipo, donde los destinatarios de la información realmente pueden hacer una diferencia.

Answer 5

Las métricas de software han estado con nosotros durante mucho tiempo y, lo mejor que puedo decir, hasta la fecha ha surgido de manera individual o en conjunto que es capaz de guiar proyectos durante el desarrollo. La tuerca del problema es que queremos usar medidas objetivas y éstas solo pueden medir lo que sucedió, no lo que está sucediendo o lo que está por suceder.

En el momento en que hemos medido, analizado e interpretado algunas series de métricas, estamos reaccionando a cosas que ya han salido mal, o muy ocasionalmente, han salido bien. No quiero minimizar la importancia de aprender de las métricas objetivas, pero sí quiero señalar que esta es una respuesta reactiva, no proactiva.

El desarrollo de un "índice de confianza" puede ser una mejor manera de monitorear si el proyecto está en marcha o en busca de problemas. Intente desarrollar un sistema de votación donde se solicite a un número razonable de representantes de cada área de interés del proyecto que voten de forma anónima su confianza de vez en cuando. La confianza se vota en dos áreas: 1) Las cosas están en el camino 2) Las cosas continuarán en el camino o volverán al camino. Estas son mediciones puramente subjetivas de las personas más cercanas a la "acción". Ingrese los resultados en un gráfico de tipo Kanban donde las columnas representan áreas de votación y debe tener una idea bastante buena de dónde enfocar su atención. Use la pregunta 1 para evaluar si la gerencia reaccionó adecuadamente al ciclo de votación anterior. Use la pregunta 2 para identificar dónde debe enfocarse la administración a continuación.

Esta idea se basa en que cada uno de nosotros tenga un nivel de comodidad dentro de nuestra propia área de responsabilidad. Nuestro nivel de confianza es un producto de experiencia, conocimiento dentro de nuestro dominio de experiencia, la cantidad y la gravedad de los problemas que enfrentamos, la cantidad de tiempo que tenemos para cumplir nuestras tareas, la calidad de la información con la que estamos trabajando y un montón de cosas. de otros factores.

MBWA (Management By Walking Around) a menudo se promociona como una de las herramientas más efectivas que tenemos, esto es una variación de la misma.

Esta técnica no es muy útil a nivel de equipos individuales porque solo refleja el estado de ánimo general del equipo. Algo así como usar el reloj de alguien para decirles la hora. Sin embargo, en niveles más altos de gestión, debería ser bastante informativo.

Answer 6

Si tiene antecedentes / conocimientos Lean, sugeriría el sistema que recommends Mary Poppendieck (que ya he mencionado en esta respuesta anterior ). Este sistema se basa en tres medidas holísticas que deben tomarse como un paquete:

1. Tiempo del ciclo
   • Desde el concepto del producto hasta la primera versión o
   • Desde la solicitud de funciones hasta la implementación de funciones o
   • Desde la detección de errores hasta la resolución
2. Realización de caso de negocio ( sin esto, todo lo demás es irrelevante )
   • P&L o
   • ROI o
   • Objetivo de la inversión
3. La satisfacción del cliente
   • Por ejemplo, Net Promoter Score

El nivel de agregación es producto / proyecto y creo que estas métricas son útiles para todos (los desarrolladores nunca deben olvidar que no escriben código por diversión, escriben código para crear valor y siempre deben tenerlo en cuenta).

Los equipos pueden (y en realidad lo hacen) utilizar métricas técnicas para medir el cumplimiento de los estándares de calidad que se integran en la Definición de Hecho (como "no hay aumento de la deuda técnica"). Pero la alta calidad no es un fin en sí misma, es solo un medio para lograr un tiempo de ciclo corto (para ser una empresa rápida) que es el objetivo real (con la realización de casos de negocios y la satisfacción del cliente).

Answer 7

Una métrica es una forma de responder una pregunta sobre un proyecto, equipo o empresa. Antes de comenzar a buscar las respuestas, debe decidir qué preguntas desea hacer.

Las preguntas típicas incluyen:

• ¿Cuál es la calidad de nuestro código?

• ¿La calidad mejora o se degrada con el tiempo?

• ¿Qué tan productivo es el equipo? ¿Está mejorando o degradando?

• ¿Qué tan efectivas son nuestras pruebas?

• ...y así.

Cada pregunta requerirá un conjunto diferente de métricas para responder. Recopilar métricas sin saber qué preguntas quiere responder es, en el mejor de los casos, una pérdida de tiempo y, en el peor de los casos, contraproducente.

También debe ser consciente de que existe un "principio de incertidumbre" en el trabajo, a menos que sea muy cuidadoso, el hecho de recopilar métricas cambiará el comportamiento de las personas, a menudo de forma inesperada y, a veces, perjudicial. Esto es especialmente cierto si las personas creen que se están evaluando en las métricas, o peor aún, las métricas están vinculadas a algún esquema de recompensa o castigo.

Recomiendo leer la gestión de software de calidad de Gerald Weinberg Vol. 2: Medición de primer orden . Entra en muchos detalles sobre las métricas de software, pero dice que los más importantes a menudo son lo que él llama "Medición de orden cero": preguntan a las personas su opinión sobre cómo va un proyecto. Los cuatro volúmenes de la serie son caros y difíciles de conseguir, pero valen la pena.

Answer 8

Uno de los enfoques interesantes que actualmente está recibiendo cierto bombo es Kanban . Es bastante ágil. Lo que es particularmente interesante es que permite aplicar una métrica de "trabajo realizado". Todavía no he usado / encontrado esto en la práctica real, pero me gustaría trabajar para conseguir que un flujo de Kanban-Ish vaya a mi trabajo.

Answer 9

Un cuento desde la experiencia personal. Disculpas por la longitud.

Hace unos años, nuestro grupo de desarrollo intentó establecer objetivos medibles "adecuados" para individuos y líderes de equipo. El experimento duró solo un año, porque las métricas duras realmente no funcionaron muy bien para los objetivos individuales (vea mi pregunta sobre el tema para algunos enlaces y más discusiones).

Tenga en cuenta que yo era un líder de equipo e involucrado en la planificación de todo con mi jefe técnico y los otros líderes de equipo, por lo que los objetivos no eran algo dictado desde lo más alto por una alta gerencia despistada - en el momento en que realmente queríamos que trabajaran . También vale la pena señalar que la estructura de la bonificación alentó inadvertidamente la competencia entre desarrolladores. Aquí están mis observaciones sobre las cosas que intentamos.

Problemas visibles para el cliente

En nuestro caso, contamos las interrupciones en el servicio que brindamos a los clientes. En un producto envuelto en plástico, podría ser la cantidad de errores reportados por los clientes.

Ventajas: Esta fue la única medida real que fue visible para la alta dirección. También fue el más objetivo, ya que se midió fuera del grupo de desarrollo.

Desventajas: no hubo tantas interrupciones (solo alrededor de una por desarrollador durante todo el año), lo que significaba que fallar o superar el objetivo era una cuestión de "culpar" a las pocas interrupciones que se produjeron en cada equipo. Esto condujo a malos sentimientos y pérdida de la moral.

Cantidad de trabajo completado

Ventajas: Esta fue la única medida positiva . Todo lo demás era "notamos cuando suceden cosas malas", lo cual fue desmoralizador. Su inclusión también fue necesaria porque, sin ella, un desarrollador que no hizo nada durante todo el año superaría todos los otros objetivos, lo que claramente no redundaría en interés de la empresa. La medición de la cantidad de trabajo completado verificó el optimismo natural de los desarrolladores al estimar el tamaño de la tarea, lo cual fue útil.

Desventajas: la medida del "trabajo completado" se basó en las estimaciones proporcionadas por los propios desarrolladores (generalmente algo bueno), pero al incluirlas en sus objetivos, se estimuló el juego del sistema para inflar las estimaciones. No tuvimos ninguna otra medida viable de trabajo completado: creo que la única forma valiosa posible de medir la productividad es "el impacto en el resultado final de la empresa", pero la mayoría de los desarrolladores están tan alejados de las ventas directas que esto rara vez es práctico a nivel individual.

Defectos encontrados en el nuevo código de producción.

Medimos los defectos introducidos en el nuevo código de producción durante el año, ya que se consideró que los errores de años anteriores no deberían contar contra ningún individuo en los objetivos de este año. Los defectos detectados por los equipos de calidad internos se incluyeron en el conteo, incluso si no afectaron a los clientes.

Ventajas: Sorprendentemente pocos. El lapso de tiempo entre la introducción de un defecto y su descubrimiento significó que realmente no había un mecanismo de retroalimentación inmediato para mejorar la calidad del código. Las tendencias macro a nivel de equipo fueron más útiles.

Desventajas: Hubo un fuerte enfoque en lo negativo, ya que este objetivo solo se invocó cuando se encontró un defecto y necesitábamos que alguien lo culpara. Los desarrolladores se mostraron reacios a registrar los defectos que encontraron, y un simple conteo significaba que los errores menores eran tan graves como los problemas graves. Dado que la cantidad de defectos por individuo todavía era bastante baja, la cantidad de defectos menores y graves no se pudo igualar con una muestra más grande. Los defectos antiguos no se incluyeron, por lo que la reputación del grupo en cuanto a la calidad del código (basada en todos los errores encontrados) no siempre coincidía con el recuento mensurable de este año.

Puntualidad en la entrega del proyecto.

Medimos la puntualidad como el porcentaje de trabajo entregado a los equipos internos de control de calidad en el plazo establecido.

Ventajas: a diferencia de contar defectos, esta era una medida que estaba bajo el control directo e inmediato de los desarrolladores, ya que decidieron efectivamente cuándo se completó el trabajo. La presencia del objetivo centró la mente en completar tareas. Esto ayudó al equipo a comprometerse con cantidades realistas de trabajo, y mejoró la percepción por parte de los clientes internos de la capacidad del grupo de desarrollo para cumplir las promesas.

Desventajas: como el único objetivo directamente bajo el control de los desarrolladores, se maximizó a expensas de la calidad del código: el día de la fecha límite, dada la opción entre decir que una tarea está completa o realizar más pruebas para mejorar la confianza en su calidad, el desarrollador elegiría marcarlo como completo y esperar que cualquier error resultante nunca salga a la superficie.

Quejas de clientes internos

Para evaluar qué tan bien se comunicaron los desarrolladores con los clientes internos durante el desarrollo y el posterior soporte de su software, decidimos que se registraría la cantidad de quejas recibidas sobre cada individuo. Las quejas serían validadas por el gerente, para evitar cualquier posible vengativa.

Ventajas: Realmente no hay nada que pueda recordar. Medido a un nivel de grupo suficientemente grande, se convierte en una puntuación de "satisfacción del cliente" más útil.

Desventajas: No solo altamente negativa, sino también una medida subjetiva. Al igual que con otros objetivos, los números para cada individuo estaban alrededor de la marca de cero, lo que significaba que un solo comentario sobre alguien podría significar la diferencia entre "infinitamente superado" y "no se cumplió".

Comentarios generales

Burocracia: si bien nuestras herramientas de administración de tareas contenían gran parte de los datos de estas métricas, aún faltaba un gran esfuerzo manual para recopilarlas. El tiempo dedicado a obtener todos los números no fue agradable, generalmente se enfocó en aspectos negativos de nuestro trabajo y puede que ni siquiera haya sido reclamado por el aumento de la productividad.

Moraleja: las medidas donde se culpó a los individuos por problemas, no solo se sintieron desmotivados aquellos con puntajes "malos", sino también aquellos con puntajes "buenos", ya que no les gustó la pérdida en la moral del equipo y algunas veces sintieron que eran Clasificó más alto no porque fueran mejores sino porque tuvieron más suerte.

Resumen

Entonces, ¿qué aprendimos del episodio? En años posteriores intentamos reutilizar algunas de las ideas, pero de una manera "más suave", donde había menos énfasis en la culpa individual y más en la mejora del equipo.

• Es imposible definir objetivos para desarrolladores individuales que sean mensurables objetivamente, agreguen valor a la empresa y no se puedan evaluar, así que no se moleste en probarlos.
• Los problemas y defectos de los clientes se pueden contar a un nivel de equipo más amplio, si la ubicación del defecto es inequívocamente la responsabilidad de ese equipo, es decir, nunca tiene que jugar el "juego de la culpa".
• Una vez que mide los defectos solo en el nivel de responsabilidad de un módulo de código, puede (y debe) medir errores antiguos y nuevos, ya que es de interés de ese grupo eliminar todos los defectos.
• Medir los recuentos de defectos a nivel de grupo aumenta el tamaño de la muestra por grupo, por lo que las anomalías entre defectos menores y graves se suavizan y una simple medida de "número de errores" puede significar algo, como por ejemplo, si está mejorando mes a mes. mes.
• Incluya algo que preocupa a la alta gerencia, porque mantenerlos felices es su principal objetivo como grupo de desarrollo. En nuestro caso, fue una interrupción visible para el cliente, por lo que incluso si la medida a veces es arbitraria o aparentemente injusta, si es lo que los jefes están midiendo, entonces usted también debe tomar nota.
• La alta gerencia no necesita ver las métricas que no tienen en sus propios objetivos. De esta manera, se evita la tentación de culpar a las personas por los errores.
• Medir la puntualidad de la entrega del proyecto cambió el comportamiento del desarrollador y se centró en completar las tareas. Mejoró la estimación y permitió al grupo hacer promesas realistas. Si fuera fácil recopilar la información de puntualidad, consideraría usarla de nuevo a nivel de equipo para medir las mejoras a lo largo del tiempo.

Todo esto no ayuda cuando se requiere establecer objetivos medibles para desarrolladores individuales, pero esperamos que las ideas sean más útiles para la mejora del equipo.

Answer 10

Software de escritura

• ¿Qué hay que optimizar?

Uso de CPU (s), uso de memoria (s), uso de memoria caché (s), uso del tiempo del usuario, tamaño del código en tiempo de ejecución, tamaño de datos en tiempo de ejecución, rendimiento de gráficos, rendimiento de acceso a archivos, rendimiento de acceso a la red, uso de ancho de banda , concisión y legibilidad del código, uso de electricidad, (conteo de) llamadas de API distintas, (conteo de) distintos métodos y algoritmos utilizados, tal vez más.

• ¿Cuánto se debe optimizar?

Debe optimizarse la cantidad razonable mínima (excepto en áreas donde se desea superar los criterios de la prueba de aceptación) para pasar las pruebas de aceptación, facilitar el mantenimiento, facilitar la auditoría y cumplir los requisitos del usuario.

("... para datos de prueba de entrada legales / ilegales y eventos de prueba legales / ilegales en todos los estados de prueba en todos los volúmenes de datos de prueba requeridos y volúmenes de solicitud de prueba para todos los escenarios de integración de prueba actuales y futuros.")

• ¿Por qué la cantidad mínima razonable?

Porque el código optimizado es más difícil de escribir y, por lo tanto, cuesta más.

• ¿Qué liderazgo se requiere?

Normas de codificación, estructura básica, criterios de aceptación y orientación sobre los niveles de optimización requeridos.

¿Cómo se puede medir el éxito de la escritura de software?

• Costo
• Hora
• Pases de prueba de aceptación.
• Hasta qué punto se superan las pruebas de aceptación que es deseable superar.
• Aprobación del usuario
• Facilidad de mantenimiento
• Facilidad de auditoria
• Grado de ausencia de exceso de optimización

¿Qué costo / tiempo debe ignorarse al evaluar el desempeño agregado de los programadores ?

• Costo / tiempo desperdiciado incurrido debido a cambios en los requisitos (arquitectura inc)
• Costo adicional / tiempo incurrido debido a deficiencias en plataformas / herramientas

Pero este costo / tiempo debe incluirse en la evaluación del desempeño agregado de los equipos (inc. Arquitectos, gerentes).

¿Cómo se puede medir el éxito de los arquitectos?

Otras medidas más:

• Los casos de "evitación temprana" de ser afectados por deficiencias en plataformas / herramientas
• Grado de ausencia de cambios en la arquitectura.