¿Cómo hacer populares las pruebas automatizadas? [cerrado]

13

Nuestro código base está creciendo desde hace 20 años. Estamos a unos 10 devs + sqa trabajando con 500kloc. Hace algún tiempo, un pequeño equipo de nosotros (2 desarrolladores, uno de sqa) comenzó a trabajar en un programa de prueba automatizado. Actualmente una carrera toma 11h y es de alguna manera una prueba de integración. Estamos trabajando en ello para reducir esto y reducir los falsos positivos y estamos progresando bien en eso. Pero los detalles no deberían importar.

Está funcionando bien y continuamos mejorándolo. A nosotros (el pequeño equipo) nos gusta mucho. Si rompemos algo, lo notamos un día después y no 2 meses después cuando sqa echa un vistazo. Además, a nuestros gerentes (dev + sqa) les gusta la idea. Pero otras personas en el equipo simplemente ignoran los resultados de las pruebas. En su opinión, si las pruebas fallan después de un registro, es un problema de la prueba y no del cambio de código y es solo nuestro proyecto de juguete. Tuvimos discusiones varias veces si una prueba fallida es un error real. La mayoría de las veces lo es.

No podemos y no queremos imponer algo. ¿Cómo podemos demostrar que las pruebas automatizadas son una cosa?

    
pregunta Peter Schneider 12.10.2017 - 20:58

3 respuestas

4

Aviso legal

Aunque pueda parecer un gerente, escribí esto como un desarrollador que también necesitaba ser convencido de que las pruebas automatizadas son buenas.

Debes entender la psicología básica de los desarrolladores. Es una necesidad arraigada de los desarrolladores para cometer código. Cualquier cosa que les impida hacerlo es algo muy, muy malo. Prueba fallida es definitivamente algo que les impide hacerlo, ergo es algo malo. De ahí la resistencia.

Lo que debe señalar es que, si bien las pruebas automatizadas las retrasan a corto plazo, a la larga les ahorrará mucho dolor y las acelerará, porque podrán centrarse más en el desarrollo de nuevas cosas, y perderá menos tiempo haciendo otra cosa que los desarrolladores odian hacer: corregir errores.

Y sí, debes hacerlo cumplir. Debe obtener el apoyo incondicional de la administración y hacer que las pruebas automatizadas de escritura sean obligatorias y no negociables. Con el tiempo, los desarrolladores se acostumbrarán a ellos. Lo que le ayudará es si puede diseñar algunas métricas que muestren cuánto más desarrollo nuevo se realizó y cuánto se redujo la cantidad de errores desde que introdujo las pruebas automáticas. Las palabras son volátiles. Los números son sólidos. Y los números son algo que un desarrollador promedio entiende mejor que las palabras. Si puede probar con números sólidos que las pruebas automatizadas son buenas, obtendrá poca o ninguna resistencia a ellas.

    
respondido por el Vladimir Stokic 13.10.2017 - 10:09
11
  

En su opinión, si las pruebas fallan después de un registro, es un problema   de la prueba y no del cambio de código y es solo nuestro proyecto de juguete.   Tuvimos discusiones varias veces si una prueba fallida es un error real.    La mayoría de las veces lo es.

Ahí está tu problema. Si sus pruebas son inestables (incluso si son confiables 'la mayor parte del tiempo'), las personas tenderán a ignorar los resultados. Su equipo de automatización debe centrarse en eliminar esos falsos negativos. Solo así el resto del equipo ganará la confianza suficiente en los resultados para realmente confiar en ellos.

    
respondido por el Eternal21 12.10.2017 - 21:22
6
  

No podemos y no queremos imponer algo.

¡Definitivamente deberías hacerlo cumplir! Si alguien inserta un código nuevo y las pruebas fallan, ¡el código debe ser rechazado! Es la única forma de mantener de manera confiable un proyecto de software más grande.

    
respondido por el Banan 13.10.2017 - 09:34

Lea otras preguntas en las etiquetas