¿Cuál es una buena medida de prueba / eficiencia del probador?

Estoy a punto de participar en una discusión con la gerencia sobre la medición de la eficiencia de nuestras pruebas como organización de control de calidad. La razón principal detrás de esto es que la mitad de nuestro equipo está contratado y nuestro negocio desea proporcionar algunas métricas de cuán efectivos / eficientes somos, para que tengamos datos básicos sobre los que negociar los parámetros del contrato con el acuerdo de servicio de nuestros contratistas. .

He examinado un poco y la mayor parte de la opinión que he encontrado sobre este tema gira en torno a la eficiencia del desarrollador: líneas de código, puntos de historia entregados, defectos introducidos, etc.

¿Pero qué hay de los probadores? Nuestras pruebas se basan principalmente en requisitos y una combinación de pruebas manuales, semiautomáticas y automatizadas (no porque no hayamos podido automatizar todo, sino porque algunas cosas no son automatizables en nuestro sistema de prueba).

El número de pruebas escritas es inútil, y una gran cantidad de errores encontrados puede ser una medida de desarrollo deficiente en lugar de un control de calidad eficiente.

Las medidas de automatización (cobertura de código, cobertura de características ...) pueden ser buenas, pero creo que son más útiles para el desarrollo (como desarrollador, sabré si rompo algo accidentalmente) que los clientes (quiero hacer eso y no funciona)

Dado que la calidad es buena si los clientes no encuentran problemas, una buena medida de la efectividad (no la eficiencia) de un equipo y proceso de QA es la medida de los errores encontrados por los clientes que QA no ha encontrado .

El principal problema con esa métrica es que puede haber un retraso considerable entre el trabajo realizado y cuando comienza a tener números significativos.

Hay algunas métricas que utilizamos en mi último trabajo para evaluar el control de calidad:

• Número de errores encontrados. Odio este Es como "Número de líneas de código escritas" para un desarrollador.
• Número de casos de prueba automatizados producidos.
• Porcentaje de la aplicación total cubierta en pruebas funcionales.
• Número de errores encontrados en la puesta en escena frente a la producción.

Al final, el trabajo de su equipo de control de calidad es encontrar los errores antes de que salgan a la naturaleza. Sus métricas deben basarse en lograr realmente ese objetivo. Si hay una baja cobertura de casos de prueba, una cantidad mínima de pruebas automatizadas y una alta tasa de errores en la producción, entonces no están haciendo un buen trabajo. Sin embargo, si tienen un buen historial de encontrar los errores mucho antes de que golpeen la producción, sus métricas deberían ser bastante altas.

El control de calidad debe medirse mediante dos métricas principales: ¿cuántos errores superan el control de calidad que se encuentra en el campo? ¿Cuáles son su gravedad?

Es posible que pueda activar el control de calidad para encontrar errores graves más cerca del lanzamiento que dev-complete. Es posible que pueda eliminar el control de calidad por no completar las pruebas en su fecha de finalización estimada (por función).

Aunque al final, me temo que gastarás más dinero tratando de medir la efectividad de tu personal contratado que los ahorros obtenidos al usar un personal contratado ...

La empresa en la que trabajo utiliza una serie de métricas de control de calidad.

El que creo que es más relevante es la cobertura del código. Una herramienta como EMMA funciona muy bien, ya que escriben pruebas automatizadas exhaustivas además de sus pruebas manuales.

Hagas lo que hagas, no te concentres en la cantidad de pruebas. Eso es casi tan útil como LOC por día.

Muchas formas de medir el rendimiento en las fases de desarrollo y prueba durante la ejecución del proyecto. Usamos las siguientes medidas en nuestros proyectos. Rendimiento de desarrollo medido por 4 métricas de código populares (índice de mantenimiento, complejidad ciclométrica, profundidad de herencia, acoplamientos de clase). Para C # lo conseguiremos en Microsoft Visual Studio. Para la cobertura de prueba, Ncover / Ndepend es muy útil. Rendimiento de prueba medido por ninguno de los errores de desarrollo: despliegue por los últimos 4 sprints. Errores de prueba del sistema que pasan por los últimos 4 sprints. No de la prueba de automatización aprobada en la versión particular / Características entregadas.