unit testing - tipos - ¿Quién debería escribir las pruebas?

tipos de pruebas de software

Question

¿Es mejor si una persona es responsable de escribir las pruebas y otra por cumplirlas o si el programador y el escritor de las pruebas son la misma persona, idealmente?

Answer 1

Con TDD, la unidad de desarrollo (leer un programador o un par) debe escribir las pruebas.

Las pruebas de la unidad TDD (desarrollo impulsado por pruebas) se realizan normalmente a nivel técnico. La unidad de desarrollo debe escribirlos a medida que vienen a implementar la clase. El problema que puede encontrar si otros escriben las pruebas es que la fuerza externa influirá en el diseño. TDD funciona bien cuando los desarrolladores están haciendo el diseño.

Con BDD / ATDD, el QA / PO debe estar involucrado.

Las pruebas BDD (desarrollo conducido por comportamiento) y ATDD (desarrollo dirigido por pruebas de aceptación) se escriben normalmente en un nivel menos granular. Las mejores pruebas se escriben con el actor en mente. Así que las mejores personas para escribir estos son QAs (Quality Assurance), POs (Product Owners) o BAs (Business Analysts). Eso no quiere decir que un desarrollador no pueda escribirlos, solo tiene que asumir ese rol.

La belleza de trabajar en parejas es que si tu pareja escribe las pruebas, hay una comprobación automática de la integridad de las pruebas a medida que se escriben.

Answer 2

Esta pregunta invitará a muchas respuestas diferentes, algunas basadas en cómo funcionan las organizaciones, otras basadas en calificaciones para la planificación y prueba. Hay muchas formas diferentes de organizar las pruebas, especialmente debido a que los tamaños de las organizaciones difieren y pueden tener o no recursos para contratar diferentes equipos.

Hay diferentes tipos de pruebas:

• Examen de la unidad
• Pruebas de integración
• Pruebas funcionales
• Pruebas no funcionales: estrés, penetración y muchos otros tipos
• Pruebas de aceptación del usuario

En mi experiencia:
El desarrollador debe realizar las pruebas unitarias (átomos de la funcionalidad de forma aislada, por ejemplo, una sola acción del controlador) y las pruebas de integración (los átomos que trabajan juntos, por ejemplo, un controlador que trabaja con los objetos de nivel de dominio, los objetos de nivel de dominio que trabajan con objetos de nivel de datos).

Las pruebas funcionales (funciones del sistema según los estados de especificaciones) deben ser realizadas por un equipo de control de calidad separado.

Las pruebas no funcionales pueden ser realizadas por un equipo de control de calidad o arquitecto / técnico .

UAT (el sistema es adecuado para el propósito) debe ser realizado por el cliente .

El razonamiento detrás de esto es que, dado que las pruebas automatizadas de Unidades e Integración son una caja blanca (puede ver dentro de la aplicación, por ejemplo, el código), un desarrollador deberá completarlas (no necesariamente el desarrollador responsable del código en prueba).
Las pruebas funcionales y la UAT son caja negra (no se puede ver dentro de la aplicación), por lo que es más probable que las realice alguien que no sea técnico, pero tenga experiencia en el análisis de pruebas.
Las pruebas no funcionales pueden ser blancas o negras dependiendo de lo que se esté probando y de la estrategia general.

Es importante tener en cuenta que se encuentran más defectos al probar el trabajo de otra persona que al probar el suyo. El evaluador pensará de manera diferente y, por lo tanto, buscará / probará cosas que no se hubieran tenido en cuenta durante el desarrollo, y las personas son naturalmente protectoras de su código (no importa lo difícil que uno intente ser objetivo).

Si no hay un equipo de prueba separado, es bueno que los desarrolladores prueben el código de cada uno.

Para responder un poco más a su pregunta, cuando era evaluador, era responsable del análisis de prueba (decidir qué pruebas funcionales se requerían para probar las especificaciones) y escribir guiones de prueba y ejecutarlas manualmente. Una vez que se escribieron esos scripts, cualquier probador podía ejecutarlos, pero era importante que el análisis de la prueba se hiciera por separado al trabajo del desarrollador en la aplicación.

Answer 3

Una política informal en mi equipo de desarrollo es

Todo el mundo hace todo.

Es decir, no hay Testers, Programadores o Arquitectos. Se espera que todos hagan un poco de todas las actividades.

Esto es para evitar un proceso de cascada. Si una actividad es propiedad exclusiva de una persona, el desarrollo puede ser secuencial, con personas que manejan el trabajo en el futuro y sin darse cuenta de las consecuencias de las decisiones que toman.

Esto no significa que todos trabajen en todas las tareas simultáneamente. Significa que cada persona trabaja en cada tipo de tarea en algún momento en el tiempo.

Answer 4

La prueba de unidad es algo que haces mientras escribes código. Esta prueba pone a prueba su visión de cómo deberían funcionar las cosas (en el nivel de clase / método / algoritmo) y lo respalda cuando desarrolla, ya que puede realizar las pruebas antes y después de hacer cambios para ver que las cosas siguen de acuerdo con las pruebas que realizó. tener en su lugar Vea esto como algo que ayudará al programador mientras trabaja. Además, las pruebas también proporcionarán una manera de ver cómo se supone que algo funcione para cualquiera que busque el código. TDD (Test-Driven Development) no está cambiando este concepto , sino que resalta que la codificación necesita pensar primero cómo debería funcionar y qué esperar.

Si hay un problema con no ver los problemas propios, puede probar la programación en pares, las revisiones de código u otras formas de ver las cosas con más ojos y cerebro. Aún así, creo firmemente que la prueba de unidad es una herramienta para el programador y no algo que haga otra persona.

Para otros tipos de pruebas, como pruebas de integración , pruebas funcionales o incluso pruebas de rendimiento (del sistema), podría ser bueno que otras personas hagan esto. Especialmente, si desea automatizar estas pruebas, es necesario que sepa cómo hacer las cosas y, quizás, un mayor nivel de conocimientos empresariales sobre qué realizar pruebas y cómo.

La respuesta a su pregunta también depende de la cultura y cómo funciona su organización, sin embargo, creo que en todos los casos desea realizar pruebas de unidad como parte del desarrollo de código. Si esto se traduce en problemas, podría haber algo más que se rompe en la organización o algo que deba ser examinado.

Actualizar

Aquí hay algunas cosas que he visto en organizaciones que afectan las prácticas de pruebas de unidad:

• algunas personas pueden no querer escribir pruebas unitarias;
• es posible que algunas personas no sepan cómo escribir buenas pruebas unitarias, lo que puede socavar los beneficios de hacerlo y que podrían usarse como una "prueba" de que las pruebas unitarias son malas;
• es posible que la organización no haga que las personas trabajen juntas, sino que tengan responsabilidades distintas, como el código de los codificadores, las pruebas de los examinadores, etc., que podrían forzar las pruebas de unidad en alguien;
• algunas personas pueden ser contratadas para escribir pruebas unitarias, por lo que si no se cambia esta función, se contradice la escritura de pruebas unitarias a medida que se codifica;
• puede haber una organización muy pequeña que puede significar implícitamente que todos hacen un poco de todo;
• la organización en su conjunto no reconoce los beneficios de las pruebas unitarias, sino que codifica lo más rápido posible y resuelve los problemas más adelante,
• ¿Quién está impulsando el esfuerzo para hacer pruebas de unidad? ¿Es una persona? Desarrolladores? ¿Administración?
• ¿La organización es libre de decidir quién hace las pruebas unitarias?

Si hay un acuerdo para realizar pruebas unitarias, las cosas anteriores pueden ser problemas con los que lidiar para llevar a la organización a un estado en el que las cosas simplemente se resuelvan de forma natural. Si tiene personas con buenas prácticas y experiencia en pruebas de unidad , permítales dirigir las cosas para que el resto del equipo vea la magia de la prueba de unidad .

Personalmente, creo que si las personas ven los beneficios de las pruebas unitarias, pueden escribir buenas pruebas unitarias, automatizarlas con compilaciones, y si el equipo puede decidir cómo organizar cómo se escriben las pruebas unitarias, todo quedará en su lugar de manera natural. que los desarrolladores escriban pruebas de unidad mientras desarrollan código, cualquiera puede agregar más pruebas de unidad para cualquier código que estén viendo. Si hay evaluadores , se enfocarán en otros tipos de pruebas como pruebas funcionales o pruebas exploratorias.