Respuesta.

Históricamente, en proyectos de larga duración, la automatización de pruebas a menudo se convertía en una carga: las pruebas se escribían "sobre la marcha", no se mantenían, y después de algunos años había que desecharlas. La frecuente rotación de equipo provoca que se pierdan conocimientos, la arquitectura de pruebas se diluya, y la automatización se convierta en "un amasijo de scripts".

Problema: los escenarios de prueba se vuelven obsoletos, falta de propietarios de pruebas, ausencia de una arquitectura de sistema de pruebas documentada, no se aplica revisión de código, se acumula deuda técnica. A los nuevos miembros del equipo les resulta complicado entender cómo y qué está cubierto por las pruebas, qué prueba es responsable de qué.

Solución: implementar prácticas de GitFlow para pruebas automatizadas, escribir código legible y bien documentado para las pruebas, utilizar patrones de diseño (como Modular Test Architecture), automatizar el mantenimiento de la documentación (README, autogeneración de informes sobre coberturas y actualidad de las pruebas). Realizar revisiones de código para pruebas automatizadas, describir los escenarios de prueba en la documentación, implementar la propiedad mediante la distribución de responsabilidades.

Características clave:

Aplicación de un enfoque unificado para la organización de la estructura del repositorio de pruebas automatizadas
Documentación de escenarios y arquitectura de pruebas automatizadas
Revisión de código y designación de responsables para diferentes suites

Preguntas capciosas.

¿Tiene sentido utilizar análisis estático del código de las pruebas automatizadas?

¡Sí! El análisis estático (linters, sonarQube, etc.) ayuda a mantener la calidad y uniformidad del código de las pruebas, previene la aparición de códigos "rápidos y sucios".

¿Con qué frecuencia se deben limpiar las pruebas automatizadas de escenarios obsoletos?

Se recomienda realizar una revisión de la actualidad de los escenarios en cada ciclo de lanzamiento (por ejemplo, una vez al mes), para excluir funcionalidad obsoleta y no dañar las métricas de estabilidad.

¿Ayuda la cobertura del 100% de las pruebas automatizadas a evitar la obsolescencia de las pruebas?

No. Incluso con una cobertura “completa”, las pruebas automatizadas pueden volverse obsoletas debido a cambios en los requisitos y la arquitectura, si no se mantienen en un estado actual.

Errores comunes y anti-patrones

No hay miembros responsables de la actualidad de las pruebas automatizadas
Estructura del repositorio confusa, sin README ni documentos de incorporación
Ausencia de un estándar para escribir pruebas, estilo de código heterogéneo

Ejemplo de la vida

Caso negativo

En una gran compañía, todas las pruebas estaban en un mismo repositorio, escritas por cualquiera y de cualquier manera. Después de un año, casi nadie podía explicar qué estaba cubierto y qué no, la mayoría de los escenarios eran obsoletos.

Ventajas:

Adición rápida de nuevas pruebas por todos los interesados
Facilidad de acceso “a corto plazo”

Desventajas:

Caos, duplicación de pruebas, conflictos constantes
Los nuevos empleados necesitan tiempo para aclarar
Alta deuda técnica y riesgo de fragmentación del conocimiento

Caso positivo

Se creó un plan maestro separado para las pruebas automatizadas: cada módulo tenía su propietario; la estructura del código se describía en README, los estándares en CONTRIBUTING.md. Cada PR en el repositorio de pruebas requería revisión de código con una lista de verificación obligatoria.