En mi trabajo, todos los desarrolladores que resuelven un error tienen que agregar una nueva prueba unitaria que advierte sobre este tipo de errores (en caso de que ocurra nuevamente). Si no es posible realizar una prueba unitaria (por ejemplo, un problema de diseño de la página web), el departamento de control de calidad debe crear un caso de prueba para verificarlo manualmente.
La idea detrás de esto es que si no se ha detectado un defecto antes del lanzamiento del producto es porque no hay una prueba unitaria adecuada para detectarlo. Entonces el desarrollador tiene que agregarlo.
La pregunta es: ¿es esto común en cualquier metodología de desarrollo de software? Esta técnica tiene un nombre? Me gustaría obtener más información al respecto, pero necesito información para comenzar.
Respuestas:
Esto es bastante común. Usamos esto en nuestro equipo. Para cada defecto de producción, el desarrollador debe agregar una nota sobre la causa raíz del problema, agregar una prueba de la unidad que falla y agregar un análisis de impacto de la prueba antes de que el ticket pueda pasar al estado dev para verificar el código.
La prueba de la unidad que falla debe pasar antes de que podamos enviar el código a producción.
No creo que tenga un nombre específico, excepto esa "prueba de regresión" general. Esto es muy útil y hemos comenzado a ver un aumento en la calidad del producto después de comenzar a seguir este proceso.
fuente
¡Absolutamente!
Si puede aceptar que las pruebas unitarias son algo bueno, se dará cuenta de que si hay un error, falta una prueba unitaria que cubra esa ruta de código.
Entonces, lo que debería suceder es que escriba una prueba unitaria que muestre que el error existe, arregle el error real y luego la prueba unitaria pasará.
Si no tiene pruebas unitarias, esta puede ser una buena manera de comenzar a introducir pruebas unitarias en un proyecto.
fuente
La técnica es un desarrollo basado en pruebas. En realidad, no se trata de poder detectar un error similar la próxima vez, aunque el conjunto de pruebas repetibles siempre es útil. El punto es que puede demostrar que ha aislado lo que está mal con el código, ha demostrado que está mal, lo ha solucionado, ha demostrado que la solución es correcta.
Hay una cita que no puedo recordar o encontrar, pero más o menos es: "Cada error es una prueba aún no escrita".
Intentar venderlo como una prueba de regresión es una batalla perdida, en mi humilde opinión. Dado que con poca frecuencia estas cosas detectan un error repetido, la mayoría de los desarrolladores solo dirán: "¿Por qué molestarme, cuando simplemente puedo solucionarlo?"
fuente
Esta técnica es bastante común y, en mi opinión, el mejor nombre para ella es "Prueba conducida por defectos" (se me ocurrió y la encontré descrita bajo este nombre hace mucho tiempo ).
A veces puede ver que algunas personas llaman a estas pruebas "Pruebas de regresión", pero personalmente me resulta un poco difícil justificar este nombre. Una definición algo más generalizada (y que, posiblemente, tiene mucho más sentido para este nombre) de "prueba de regresión" es "ejecutar pruebas después de realizar cualquier cambio en el código para asegurarse de que no introdujo ninguna regresión" y su CI que prueba cada bifurcación en la inserción al repositorio la satisface.
fuente