¿La unidad está probando el desarrollo o las pruebas?

Tuve una discusión con un gerente de pruebas sobre el papel de las pruebas de unidad e integración. Ella solicitó que los desarrolladores informaran sobre qué han probado la unidad y la integración y cómo. Mi perspectiva es que las pruebas de unidad e integración son parte del proceso de desarrollo, no del proceso de prueba. Más allá de la semántica, lo que quiero decir es que las pruebas de unidad e integración no deben incluirse en los informes de prueba y los probadores de sistemas no deben preocuparse por ellas. Mi razonamiento se basa en dos cosas.

1. Las pruebas unitarias y de integración se planifican y realizan contra una interfaz y un contrato, siempre. Independientemente de si utiliza contratos formalizados, aún prueba lo que, por ejemplo, se supone que debe hacer un método, es decir, un contrato.

   En las pruebas de integración, prueba la interfaz entre dos módulos distintos. La interfaz y el contrato determinan cuándo pasa la prueba. Pero siempre prueba una parte limitada de todo el sistema. Las pruebas de sistemas, por otro lado, se planifican y se realizan según las especificaciones del sistema. La especificación determina cuándo pasa la prueba.

2. No veo ningún valor en comunicar la amplitud y profundidad de las pruebas unitarias y de integración al probador (de sistemas). Supongamos que escribo un informe que enumera qué tipo de pruebas unitarias se realizan en una clase de capa empresarial particular. ¿Qué se supone que debe quitar de eso?

   A juzgar por lo que debe y no debe probarse a partir de eso, es una conclusión falsa porque el sistema aún puede no funcionar de la manera que requieren las especificaciones a pesar de que pasan todas las pruebas de unidad e integración.

Esto puede parecer una discusión académica inútil, pero si trabajas en un ambiente estrictamente formal como yo, en realidad es importante para determinar cómo hacemos las cosas. De todos modos, ¿estoy totalmente equivocado?

Escribir pruebas automatizadas es el trabajo de un desarrollador; las pruebas son parte de la base de código y deben tratarse como tales; deben estar sujetas a las mismas revisiones de código, estándares de codificación, disciplina de control de fuente, etc., que el resto del proyecto.

La ejecución de dichas pruebas se realiza por dos razones: Primero, como una herramienta para guiar a los desarrolladores. Ejecuta pruebas para verificar que el código que acaba de escribir hace lo que se supone que debe hacer, las usa como documentación adicional y para verificar que los cambios no rompan ninguna funcionalidad existente. Si realiza TDD real, las pruebas también son una fuente autorizada de especificaciones técnicas. La segunda razón para usar las pruebas es durante el control de calidad y la implementación. La ejecución de todas las pruebas automatizadas debería ser uno de los primeros pasos en cada ronda de pruebas; ejecutar pruebas automatizadas es barato (prácticamente no se requiere mano de obra), y no tiene mucho sentido realizar pruebas manuales si las automatizadas fallan.

Esto significa que las responsabilidades deberían ser así:

• Los desarrolladores escriben pruebas automatizadas
• Los desarrolladores ejecutan pruebas automatizadas individuales según sea necesario, como parte de su flujo de trabajo de desarrollo
• QA ejecuta todas las pruebas automatizadas como una de las primeras etapas de prueba

Si tiene un servidor de compilación, la tarea de control de calidad (con respecto a las pruebas automatizadas) se reduce a "abrir el informe del servidor de compilación y verificar que todo esté verde".

Creo que lo más importante para usted sería aclarar por qué ella necesita ese informe.

Puede haber diferentes explicaciones (como lo sugieren varias respuestas), que requieren estrategias muy diferentes.

• Si ella es una persona razonable, simplemente desea obtener información para ayudar al trabajo de su equipo de evaluación, tiene sentido llegar a un entendimiento común y encontrar una solución que sea adecuada para ambos. Puede discutir con ella la naturaleza de las pruebas unitarias y la diferencia fundamental entre las pruebas unitarias vs funcionales / del sistema / de aceptación. Esperemos que pueda hacerle entender que funcionan en niveles muy diferentes y que ninguno puede reemplazar al otro.
• si ella es una fanática del control o una burócrata, que exige un informe solo por el bien, puede generar algo para satisfacer sus caprichos con la menor cantidad de esfuerzo (por ejemplo, lo que sugirió @Doc :-).
• si le gusta algún juego de poder, puede preguntarse si tiene derecho a exigir informes de los desarrolladores. En mi experiencia, los desarrolladores generalmente no deben informar al departamento de control de calidad.

Creo que el papel del control de calidad y el desarrollo, y la interacción, pueden variar mucho entre las organizaciones. Pero en general, en mi equipo, les digo a los miembros que se unen que básicamente pretendan que no hay un equipo de control de calidad, en el sentido de que son responsables de los cambios que están impulsando en la producción. A su vez, nuestro equipo de control de calidad no asume mucho sobre las pruebas de desarrollador, y hace una buena cantidad de pruebas del sistema como un todo funcional.

Por esta razón, a nuestro equipo de control de calidad no le importa mucho lo que se prueba y no se prueba antes de comenzar a probar.

Creo que es útil que el equipo de control de calidad comprenda lo que las pruebas unitarias cubren y no cubren, a un alto nivel, para que podamos trabajar colectivamente para identificar brechas y áreas que podrían necesitar más rigor. Entonces, tal vez su colega busque un resumen de alto nivel, en lugar de los detalles sangrientos.

Insistió en que los desarrolladores informan de qué han probado la unidad y la integración y cómo.

¿Realmente está tratando de discutir si este tipo de prueba está realmente en el ámbito del "desarrollo", o solo está tratando de averiguar qué tan bien su código está cubierto por las pruebas unitarias? Con solo mirar la información que ha proporcionado, parece que solo quiere saber qué partes del código están cubiertas y dónde debe enfocar el esfuerzo de su equipo.

Trabajé en un equipo de evaluación justo fuera de la escuela antes de pasar a un rol de desarrollo, y puedo ver cómo esto podría ser valioso para ella y su equipo.

No veo que importe demasiado.

Si no los proporciona al control de calidad / pruebas, y no realizan las pruebas adecuadas, y falla en la producción, es su culpa por dejar que el control de calidad entre en producción sin verificar que funciona como se especifica.

Si los proporciona a QA / Testing, y no realizan las pruebas adecuadas ... el mismo resultado que si no los hubiera proporcionado.

Sin embargo, si los proporciona, también podrían compararlos con la especificación, y / o sugerir qué pruebas pueden ser defectuosas o si es necesario cambiarlas porque encontraron un error.

Realmente, no veo muchos inconvenientes en proporcionarlos. Todavía está en QA / testing para validar contra la especificación. Si toman el camino perezoso y solo confían en que su prueba es lo suficientemente buena porque todos pasaron, son ellos los que fallaron en su trabajo. Mientras sigan teniendo la especificación también, los resultados de las pruebas de unidad / integración son simplemente imprecisos y no deberían ser capaces de lastimarlo de una forma u otra. Esta es la razón por la que tenemos dev y QA. Múltiples controles que la aplicación realiza según lo especificado.

Los desarrolladores cometen errores, el control de calidad comete errores, idealmente no ambos cometen un error en el mismo elemento ... y si lo hacen ... es potencialmente un analista quien dejó caer la pelota escribiendo una especificación poco clara.

Las pruebas unitarias son responsabilidad de los desarrolladores de que las pruebas pueden ser útiles para comprender cómo funcionan las piezas de código por sí mismas. Algunos pueden ver esto como una forma de documentación y, por lo tanto, tiene algún valor, aunque puede haber una sobrecarga si las pruebas unitarias se cambian regularmente.

El otro valor al pasar las pruebas es que esto puede evitar duplicar las pruebas que pueden ser redundantes en términos de garantizar la funcionalidad básica.

También hay pruebas de aceptación del usuario que están separadas de todo esto, ya que el usuario final puede tener su propia comprensión de cómo debe funcionar un sistema.

Si su empresa tiene una metodología definida para garantizar la calidad de sus productos (si cumplen con SOX o intentan mejorar su nivel de CMMI, probablemente lo hagan), entonces los productos deben ser capaces de resistir la auditoría para mostrar que el proceso fue seguido.

A menudo, el proceso definido incluye pruebas unitarias (que es algo bueno). Desafortunadamente, esto también significa que tiene que documentar sus pruebas unitarias y demostrar que se ejecutaron para resistir la auditoría. Eso significa que necesita una forma de informar sobre sus pruebas unitarias.

Mire una herramienta como Sonar para ayudarlo: informará el nivel de cobertura del código y los resultados de las pruebas de unidad.

Esto realmente depende de la compañía, pero desde mi experiencia, habiendo trabajado tanto como probador de sistemas en un enfoque tradicional como también como probador trabajando en un equipo ágil en un modelo de CD, saber lo que ha sido probado en la unidad y la integración es extremadamente útil.

La calidad es responsabilidad del equipo: tanto los desarrolladores, los evaluadores como la gestión de productos y trabajar juntos es la mejor manera de garantizarlo.

Por lo tanto, el administrador de pruebas quiere saber qué se ha probado con la unidad y la integración y es un poco más de trabajo adicional para los desarrolladores, ¡pero ahorra el trabajo general para el proyecto! Al proporcionar la información al gerente de pruebas, pueden enfocar el esfuerzo de su equipo de prueba en lo que es crítico e importante. Como se mencionó anteriormente, si un área de código no se prueba unitariamente, el equipo puede concentrar su esfuerzo allí en comparación con un área que está muy probada: ¿por qué duplicar el esfuerzo? Todos están trabajando hacia el mismo objetivo final de software de mayor calidad lanzado a tiempo.

Creo que sería beneficioso proporcionar este tipo de cosas. La cobertura de prueba unitaria debe ser algo que se conoce por desarrollo y prueba para que puedan dar cuenta de eso.

Obviamente, tienes que probar las cosas críticas del negocio sin importar qué. Debe probar la funcionalidad de uso común de manera dura, independientemente de si tiene una gran cobertura de prueba de unidad. No estaría de más hacerles saber qué otros lugares están cubiertos por las pruebas unitarias. ¿El código ya comprueba los casos límite en este pequeño control? Es útil saber este tipo de cosas en todos los aspectos del negocio.

Vale la pena mencionar el enfoque discutido en el libro "Cómo prueba Google el software": las pruebas y el control de calidad son responsabilidad de todos, y los estándares son rigurosos.

El papel real de lo que tradicionalmente se llama el departamento de "Pruebas", es en realidad la productividad del desarrollador; es decir, automatización para permitir que la organización alcance el nivel de rigor requerido económicamente.