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

Cerrada . Esta pregunta está basada en la opinión . Actualmente no está aceptando respuestas.

¿Quieres mejorar esta pregunta? Actualice la pregunta para que pueda ser respondida con hechos y citas editando esta publicación .

Cerrado hace 2 años .

Nuestro código base está creciendo desde hace 20 años. Somos unos 10 desarrolladores + 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 ejecución dura 11 horas y de alguna manera es una prueba de integración. Estamos trabajando en ello para reducir esto y reducir los falsos positivos y estamos haciendo un buen progreso en eso. Pero los detalles no deberían importar.

Está funcionando bien y seguimos mejorando. A nosotros (el equipo pequeño) nos gusta mucho. Si rompemos algo, 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 la prueba. 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 hacer cumplir algo. ¿Cómo podemos demostrar que las pruebas automatizadas son una cosa?

testing integration-tests

— Peter Schneider
fuente

Este no es un problema de Ingeniería de Software; Es un problema de personas.

— Robert Harvey

@RobertHarvey Recibí votos negativos en SO porque "basado en opiniones" y un comentario de que este sitio se adaptaría perfectamente (y votos positivos en ese comentario). Entonces: ¿dónde debería preguntar? Educarme

— Peter Schneider

Estoy con @RobertHarvey acerca de que esto es un problema de personas. Pero según Workplace, su pregunta probablemente la consideraremos un tonto. Por ejemplo, vea esta pregunta que es fundamentalmente lo que está preguntando en el lugar de trabajo.stackexchange.com/questions/44964/…

— Peter M

¡No dejes que esos votos negativos (o incluso votos cerrados) te desanimen! Algunas personas pueden entender que tales preguntas son importantes y tal vez puedan brindar ayuda. Por cierto, también mis colegas no ven la utilidad de las pruebas automatizadas, a pesar de que la versión anterior (sin pruebas automáticas) es una caja de errores. Simplemente cambie una cosa y rompa algunas otras cosas aparentemente no relacionadas. Algunas personas simplemente no quieren aprender (hay una resistencia abierta a aprender cosas nuevas).

— Bernhard Hiller

Es una pena que esta pregunta se haya cerrado. Si la ingeniería de software significa algo, significa los problemas de trabajar con personas reales, y las respuestas a tales problemas implicarán una opinión. Dicho esto, un par de ideas rápidas: (1) si las pruebas dan falsos negativos, esto definitivamente aumentará el rechazo porque los resultados se sentirán como una pérdida de tiempo; (2) reduzca el tiempo de ejecución, si es posible. 11 horas no se siente inmediato, incluso si es mucho mejor que dos meses; (3) adoptará sqa estas pruebas como métricas que observan. ya son reconocidos por su organización en esta área.

— Dale Hagglund

Respuestas:

Descargo de responsabilidad

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

Debes entender la psicología básica de los desarrolladores. Es una necesidad arraigada de los desarrolladores comprometer el código. Cualquier cosa que les impida hacerlo es algo muy, muy malo. La prueba fallida es definitivamente algo que les impide hacerlo, por lo tanto, es algo malo. De ahí la resistencia.

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

Y sí, debes imponerlo. Debe obtener el apoyo incondicional de la administración y hacer que la escritura de pruebas automatizadas sea obligatoria y no negociable. Con el tiempo, los desarrolladores se acostumbrarán a ellos. Lo que ayudará es si puede idear algunas métricas que muestren cuánto más se realizó un nuevo desarrollo y cuánto se redujo el número 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 usando números sólidos que las pruebas automatizadas son buenas, obtendrá poca o ninguna resistencia a ellas.

— Vladimir Stokic
fuente

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 escamosas (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 entonces el resto del equipo ganará suficiente confianza en los resultados para confiar realmente en ellos.

— Eterno21
fuente

Por otra parte, podría ser otra cosa. Como resistencia al cambio. Si una prueba falla, siempre hay algo que arreglar, ya sea el código o la prueba, por lo que la actitud de que las personas ignorarán las pruebas porque las pruebas son escamosas está fuera de lugar.

— Robert Harvey

Hablamos con ellos cuando estábamos seguros de que algo se rompió (por ejemplo, la prueba falló 3 veces seguidas después de que su registro afectara la funcionalidad en cuestión). Pero sí, aumentar la fiabilidad es la prioridad actual.

— Peter Schneider

@PeterSchneider una prueba puede fallar 100 veces seguidas, lo hará especialmente si la prueba es incorrecta.

— Pieter B

Por otro lado, una prueba que nunca falla es muy probable que sea completamente inútil

— Vladimir Stokic el

Las pruebas de +1 frágiles son definitivamente un problema. Los desarrolladores deben estar convencidos de que las pruebas que escriben son útiles, no introducen complicaciones innecesarias y no están ocupados .

— Andres F.

No podemos y no queremos hacer cumplir algo.

¡Definitivamente deberías aplicarlo! Si alguien introduce 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.

— Banan
fuente

Supongo que eso depende del sistema, las pruebas, la escala y el proceso de desarrollo. No todos los errores se pueden resolver de inmediato, ni todos los problemas tienen que resolverse de inmediato.

— NickL