El concepto de "puertas de calidad" en las pruebas de software

7

Estamos utilizando SonarQube para las pruebas de calidad de código. Prueba la calidad del código, y no la función del código. Tiene el concepto de puertas de calidad, por lo que puede establecer, por ejemplo, una puerta con un 90% de calidad, lo que significa que cualquier calidad superior al 90% se considera un pase.

A algunas personas aquí les gusta esta idea y han decidido aplicarla a las pruebas funcionales y de unidad. Después de ejecutar nuestras pruebas funcionales y de unidad, verificamos qué porcentaje se aprobó y promovemos el código al siguiente entorno si se aprueba un porcentaje suficientemente alto de pruebas. Para que el código sea promovido a producción, el porcentaje aprobado debe ser 100.

Para mí, las pruebas en sí son la puerta de calidad. Las pruebas nunca deben fallar. Si las pruebas fallan, existe un riesgo introducido en toda la aplicación y debe solucionarse de inmediato.

Estoy luchando para ver un argumento válido para exigir que solo pase un cierto porcentaje de pruebas funcionales y de unidad a medida que el código viaja a través de nuestros diferentes entornos en ruta a producción. ¿Alguien puede proporcionar uno?

    
pregunta Fo. 14.03.2016 - 18:26

2 respuestas

9

Un conjunto de pruebas solo debería pasar si todas las pruebas pasan. De lo contrario, las pruebas se vuelven inútiles. ¿Qué es un error importante? ¿Qué es un error que puede ignorarse? El resultado sería que todas las fallas de prueba serían ignoradas después de un tiempo. Malo.

Hay una excepción a esto: una serie de pruebas puede contener pruebas que se sabe que fallan, ya que la funcionalidad necesaria aún no se ha implementado o el error aún no se ha solucionado. Tales pruebas son valiosas porque documentan claramente un error. Pero debido a que su falla no sería una regresión, su falla no debería fallar a todo el conjunto de pruebas (por el contrario, si comienzan a aprobar eso indicaría que su conjunto de pruebas no está actualizado con su código). Idealmente, su marco de prueba tiene un concepto de tales "TODO tests".

Las métricas de calidad son una bestia diferente. Si una métrica de calidad cruza un umbral, eso indica que es probable que algo esté, pero no necesariamente, maduro para una refactorización. Pero algunas "violaciones" pueden estar bien en el contexto de ese código. Siempre que ciertas regiones de código puedan ser excluidas de herramientas de análisis específicas, la selección de esa métrica de calidad está bien. Obviamente, cualquier exclusión explícita sería una bandera roja en una revisión del código y está sujeta a un escrutinio adicional, pero mantener tal escotilla de escape abierta en circunstancias excepcionales es importante.

En particular, la idea de requerir una calidad creciente a medida que un artefacto viaja a través de la tubería de lanzamiento no es necesariamente buena. ¿De dónde viene el incremento de calidad necesario? De los desarrolladores que mejoran el código y vuelven a enviar un nuevo artefacto a la tubería. Dado que la métrica de calidad necesaria para atravesar todo el oleoducto es conocida de antemano, enviar cualquier artefacto sin esta calidad es una pérdida de tiempo. Entonces, ¿por qué lo haces? Probablemente, las etapas en la tubería proporcionan información sobre su programa que es útil antes del lanzamiento principal. Para obtener estos comentarios, debe enviar el código incluso cuando no tenga la intención de hacerlo a través de la canalización. Una vez más, los falsos negativos son malos. Dicho flujo de trabajo no es adecuado para un modelo de canalización, y los comentarios deberían estar disponibles de forma independiente.

Eso no significa que debas renunciar a un control de calidad. Pero si su objetivo es una métrica del 100% para un lanzamiento, la métrica de calidad actual se convierte en un indicador de progreso para su proyecto, como un gráfico de quema de deuda técnica.

    
respondido por el amon 14.03.2016 - 18:55
1

Le agregaría algo a la buena respuesta de Amon:

  

... las pruebas en sí mismas son la puerta de calidad.

Son una puerta de su código de producción, pero las pruebas en sí mismas pueden tener sus propias mediciones de calidad (potenciales), que incluyen:

  • ¿Se clona el código de configuración / desmontaje común en cada prueba? ¿O está ubicado correctamente en los métodos de configuración / clase de inicialización / prueba de inicialización, etc., que son compatibles con su conjunto de pruebas?
    • Si el código que se está probando no hace un uso suficiente de los contratos, ¿cubre la prueba un rango aceptable de parámetros cuando sea necesario? ¿Se están probando los valores de borde? ¿Colecciones nulas? Colecciones vacias? Incluso con altos porcentajes de cobertura, es posible que no esté ejercitando el código lo suficiente.
    • ¿Las pruebas tardan demasiado en ejecutarse?
    • ¿Están incluso corriendo? ¿O alguien ha hecho que la suite pase al marcar muchas pruebas con @Ignore ?
    • Por supuesto, ¿el porcentaje de cobertura es aceptable?

Estos atributos, y muchos más, por supuesto, son cosas que puede elegir para medir sus propios paquetes de pruebas (algunos de los cuales son compatibles con SonarQube) para obtener la confianza de que no solo está probando, sino que está probando de manera efectiva. p>     

respondido por el Dan1701 14.03.2016 - 22:07