¿Cuáles son las desventajas de las pruebas automatizadas?

49

Hay una serie de preguntas en este sitio que brindan mucha información sobre los beneficios que se pueden obtener de las pruebas automatizadas. Pero no vi nada que representara el otro lado de la moneda: ¿cuáles son las desventajas? Todo en la vida es una compensación y no hay balas de plata, por lo que seguramente debe haber algunas razones válidas para no hacer pruebas automatizadas. ¿Qué son?

Aquí hay algunos que se me ocurrieron:

  • Requiere más tiempo de desarrollador inicial para una función determinada
  • Requiere un mayor nivel de habilidad de los miembros del equipo
  • Aumentar las necesidades de herramientas (corredores de prueba, marcos, etc.)
  • Se requiere un análisis complejo cuando se encuentra una prueba fallida: ¿esta prueba está obsoleta debido a mi cambio o me dice que cometí un error?

Editar
Debo decir que soy un gran defensor de las pruebas automatizadas, y no estoy buscando ser convencido de hacerlo. Estoy tratando de entender cuáles son las desventajas, de modo que cuando voy a mi empresa para presentar un caso, no parece que esté lanzando la próxima bala de plata imaginaria.

Además, soy explícitamente no busco a alguien para disputar mis ejemplos anteriores. Estoy tomando como cierto que debe haber algunas desventajas (todo tiene compensaciones) y quiero entender cuáles son.

RationalGeek
fuente
18
"Se requiere un análisis complejo ..." la prueba no es la causa de la falla, es un indicador. Decir que no hay pruebas significa que no se requiere un análisis complejo de fallas no es mejor que meter la cabeza en el barro.
P.Brian.Mackey
1
* Tiempos de construcción más largos cuando se realizan pruebas cada proyecto de construcción, y el código repite cuando las pruebas son en el muy bajo nivel (prueba de captadores y definidores)
monstruo de trinquete
2
1. si un desarrollador está usando el tiempo para probar nuevas funciones, el riesgo de que falle se redujo, lo que significa que su producto es más estable. 2. Educar a los miembros de su equipo para un enfoque de enfoque de prueba es una buena cosa, pueden usar este conocimiento para otras cosas en el trabajo (y la vida). 3. Crear una instalación automatizada para el entorno de prueba 4. Esto me dice que 1 prueba hace demasiado.
CS01
1
Si el mismo desarrollador está codificando las pruebas como está codificando el código real, entonces solo pensarán en los mismos casos de prueba para escribir las pruebas en las que pensaron cuando estaban codificando.
Paul Tomblin el
Acabo de publicar una respuesta a la pregunta relacionada y siento que al menos debo comentar sobre esta. En mi opinión, casi todas las desventajas mencionadas aquí (y en las respuestas) parecen falsas y engañosas si hablamos del proyecto real en vivo y no de algo que codifica rápidamente y olvida. Me temo que una pregunta como esta puede usarse como una excusa para desarrollarse sin pruebas automáticas y, en muchos casos, esto conducirá a la muerte del proyecto o un nuevo cableado.
Boris Serebrov

Respuestas:

26

Casi clavaste los más importantes. Tengo algunas adiciones menores, más la desventaja de que las pruebas realmente tienen éxito, cuando realmente no quieres que lo hagan (ver más abajo).

  • Tiempo de desarrollo: con el desarrollo basado en pruebas, esto ya se calcula para las pruebas unitarias, pero aún necesita pruebas de integración y del sistema, que también pueden necesitar código de automatización. El código escrito una vez generalmente se prueba en varias etapas posteriores.

  • Nivel de habilidad: por supuesto, las herramientas tienen que ser compatibles. Pero no es solo tu propio equipo. En un proyecto más grande, es posible que tenga un equipo de prueba separado que escriba pruebas para verificar las interfaces entre el producto de su equipo y el de otros. Muchas personas más tienen que tener más conocimiento.

  • Necesidades de herramientas: eres perfecto allí. No hay mucho que agregar a esto.

  • Pruebas fallidas: este es el verdadero error (para mí de todos modos). Hay muchas razones diferentes, cada una de las cuales puede verse como una desventaja. Y la mayor desventaja es el tiempo requerido para decidir cuál de estas razones se aplica realmente a su prueba fallida.

    • falló debido a un error real. (solo para completar, ya que esto es, por supuesto, ventajoso)
    • falló, porque su código de prueba se ha escrito con un error tradicional.
    • falló, porque su código de prueba se ha escrito para una versión anterior de su producto y ya no es compatible
    • falló, porque los requisitos han cambiado y el comportamiento probado ahora se considera "correcto"
  • Pruebas no fallidas: estas también son una desventaja y pueden ser bastante malas. Ocurre principalmente, cuando cambias las cosas y te acercas a lo que Adam respondió. Si cambia algo en el código de su producto, pero la prueba no lo explica en absoluto, entonces le da esta "falsa sensación de seguridad".

    Un aspecto importante de las pruebas no fallidas es que un cambio de requisitos puede hacer que un comportamiento anterior se vuelva inválido. Si tiene una trazabilidad decente, el cambio de requisitos debería poder coincidir con su código de prueba y sabe que ya no puede confiar en esa prueba. Por supuesto, mantener esta trazabilidad es otra desventaja. Y si no lo hace, termina con una prueba que no falla, pero que en realidad verifica que su producto funciona incorrectamente . En algún lugar en el camino, esto te golpeará ... generalmente cuando / donde menos lo esperas.

  • Costos de implementación adicionales: no solo ejecuta pruebas unitarias como desarrollador en su propia máquina. Con las pruebas automatizadas, desea ejecutarlas mediante confirmaciones de otros en algún lugar central para averiguar cuándo alguien rompió su trabajo. Esto es bueno, pero también debe configurarse y mantenerse.

Franco
fuente
1
En las pruebas fallidas, si los requisitos cambian y las pruebas actuales fallan, la prueba pasa porque la implementación anterior ya no es válida, si no falla significaría que la implementación no
cumple
El caso 4 (b) es de lo que se trata el desarrollo basado en pruebas: escribe una prueba fallida, luego extiende el producto, luego verifica que este cambio hace que la prueba tenga éxito. Esto lo protege contra una prueba escrita errónea que siempre tiene éxito o siempre falla.
Kilian Foth
@ Frank gracias por la respuesta. Hay mucha información allí. Aprecié especialmente las distinciones de las diferentes causas de las pruebas fallidas. Los costos adicionales de implementación son otro punto excelente.
RationalGeek
Lo divertido que he encontrado es que mi error por relación de LOC es mucho peor para las pruebas que el código real. Paso más tiempo buscando y reparando errores de prueba que los reales. :-)
Brian Knoblauch
falló, porque su código de prueba se ha escrito para una versión anterior de su producto y ya no es compatible; si sus pruebas se rompen debido a esto, entonces es probable que sus pruebas estén probando detalles de implantación en lugar de comportamiento. CalculateHighestNumber v1 aún debería devolver el mismo resultado que CalculateHighestNumber v2
Tom Squires
29

Después de comenzar a probar pruebas automatizadas en nuestro equipo, la mayor desventaja que he visto es que es muy difícil aplicar el código heredado que no fue diseñado teniendo en cuenta las pruebas automáticas. Sin duda, mejoraría nuestro código a largo plazo, pero el nivel de refactorización necesario para las pruebas automatizadas mientras se conserva nuestra cordura es una barrera muy alta para la entrada a corto plazo, lo que significa que tendremos que ser muy selectivos acerca de la introducción automatizada pruebas unitarias para cumplir con nuestros compromisos a corto plazo. En otras palabras, es mucho más difícil pagar las tarjetas de crédito cuando ya tienes una gran deuda técnica.

Karl Bielefeldt
fuente
2
Como alguien que trabaja el 80% de una base de código heredado muy grande, no podría estar más de acuerdo. Sin embargo, para mitigar esto, he usado algo de esto en [link] amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/… merece la pena.
DevSolo
1
Es un libro realmente bueno, saqué mucho de él. Tres puntos principales, prueba, un poco a la vez. Algunas buenas pruebas son mejores que ninguna prueba. Manténgase dentro del alcance, no refactorice todo lo que necesita refactorizar a la vez. Sea muy claro dónde están los límites entre el código comprobable y el no comprobable. Asegúrese de que todos los demás también lo sepan.
Tony Hopkinson
21

Quizás la desventaja más importante es ... las pruebas son el código de producción . Cada prueba que escribe agrega código a su base de código que debe mantenerse y admitirse. No hacerlo conduce a pruebas en las que no crees los resultados, por lo que no tienes otra opción. No me malinterpreten: soy un gran defensor de las pruebas automatizadas. Pero todo tiene un costo, y este es uno grande.

Ross Patterson
fuente
Buen punto Ross, que es una forma interesante de decirlo.
RationalGeek
De acuerdo, aunque en mi experiencia de todos modos, el tiempo ahorrado debido a que las pruebas unitarias encuentran instantáneamente errores potenciales en el código recién escrito (es decir, pruebas de regresión) ha superado este tiempo de mantenimiento adicional.
dodgy_coder
15

No diría que estas son desventajas totalmente aplicables, pero las pocas que golpeo más son:

  • Tiempo necesario para configurar la prueba en una aplicación empresarial compleja.
  • Manejando pruebas antiguas que fallan incorrectamente, en otras palabras, el sistema ha evolucionado y ahora las pruebas están equivocadas.
  • Falsa confianza de una cobertura de prueba irregular o desconocida.

La cobertura de prueba que es irregular puede conducir a una falsa sensación de seguridad. Si realiza una refactorización y utiliza las pruebas para demostrar su validez, ¿qué ha demostrado que sus pruebas pueden demostrarlo?

El tiempo que lleva crear la prueba a veces es un problema para nosotros. Nuestras pruebas automatizadas no solo incluyen pruebas unitarias, sino que también usan pruebas de casos. Estos tienden a ser más amplios y requieren contexto.

Por supuesto, mi perspectiva es de una aplicación que es más antigua que sus pruebas unitarias.

Adam Houldsworth
fuente
El OP ya cubrió el tiempo y el código obsoleto en la pregunta.
P.Brian.Mackey
@ P.Brian.Mackey en realidad el elemento tiempo es subjetivo. El tiempo necesario para codificar la prueba es diferente del tiempo necesario para comprender lo que requiere la prueba y codificarla correctamente.
Adam Houldsworth
@AdamHouldsworth Gracias, esos son algunos buenos ejemplos de desventajas. Realmente no había considerado el falso ángulo de confianza.
RationalGeek
9

Yo diría que el principal problema con ellos es que pueden proporcionar una falsa sensación de seguridad . El hecho de que tenga pruebas unitarias no significa que realmente estén haciendo nada y eso incluye probar adecuadamente los requisitos.

Además, las pruebas automatizadas también pueden incluir errores en sí mismos , por lo que surge la pregunta sobre si las pruebas unitarias deben probarse a sí mismas para no lograr necesariamente nada.

billy.bob
fuente
Test Driven Development ayuda con el primero al requerir una prueba fallida antes de escribir el código de característica. Ahora sabe que si la función se rompe, la prueba se romperá. Para el segundo, el código de prueba complicado es un olor a código. Nuevamente, al escribir la prueba primero, puede esforzarse por simplificarla y poner el trabajo difícil en el código de función que corrige la prueba.
David Harkness
El código que es difícil de probar no es un olor a código. El código más fácil de probar es una cadena gigante de llamadas de funciones disfrazadas de clases.
Erik Reppen
4

Aunque las pruebas de automatización tienen muchas ventajas, también tiene sus propias desventajas. Algunas de las desventajas son:

  • Se requiere competencia para escribir los scripts de prueba de automatización.
  • La depuración del script de prueba es un problema importante. Si hay algún error en el script de prueba, a veces puede tener consecuencias mortales.
  • El mantenimiento de la prueba es costoso en el caso de los métodos de reproducción. Aunque se produce un cambio menor en la GUI, la secuencia de comandos de prueba debe volver a grabarse o reemplazarse por una nueva secuencia de comandos de prueba.
  • El mantenimiento de los archivos de datos de prueba es difícil si el script de prueba prueba más pantallas.

Algunas de las desventajas anteriores a menudo restan del beneficio obtenido de los scripts automatizados. Aunque las pruebas de automatización tienen pros y callos, se adapta ampliamente en todo el mundo.

jameswood037
fuente
Gracias. Buenos puntos. Edité tu publicación para gramática y formato. Espero que no te importe.
RationalGeek
3

Hace poco hice una pregunta sobre las pruebas en el desarrollo de juegos , esto es, por cierto, cómo supe de esto. Las respuestas allí señalaron algunas desventajas curiosas y específicas:

  1. Es costoso hacerlo cuando su código debe estar altamente acoplado .
  2. Es difícil hacerlo cuando debe conocer las diversas plataformas de hardware, cuando debe analizar la salida para el usuario y el resultado del código solo tiene sentido en un contexto más amplio .
  3. Las pruebas de UI y UX son muy difíciles .
  4. Y notablemente, las pruebas automatizadas pueden ser más caras y menos efectivas que un grupo de beta testers de muy bajo costo (o gratuitos) .

El cuarto punto me hace recordar alguna experiencia mía. Trabajé en una empresa muy delgada, orientada a XP, administrada por Scrum, donde las pruebas unitarias eran muy recomendables. Sin embargo, en su camino hacia un estilo más delgado y menos burocrático, la compañía simplemente descuidó la construcción de un equipo de control de calidad: no teníamos evaluadores. Con tanta frecuencia, los clientes encontraron errores triviales usando algunos sistemas, incluso con una cobertura de prueba de> 95%. Entonces agregaría otro punto:

  • Las pruebas automatizadas pueden hacerle sentir que el control de calidad y las pruebas no son importantes.

Además, en esos días estaba pensando en la documentación y reflexioné sobre una hipótesis que puede ser válida (en menor medida) para las pruebas dos. Simplemente sentí que el código evoluciona tan rápido que es bastante difícil hacer documentación que siga esa velocidad, por lo que es más valioso pasar tiempo haciendo que el código sea legible que escribir documentación pesada y fácilmente obsoleta. (Por supuesto, esto no se aplica a las API, sino solo a la implementación interna). La prueba sufre un poco del mismo problema: puede ser demasiado lenta para escribir en comparación con el código probado. OTOH, es un problema menor porque las pruebas advierten que están desactualizadas, mientras que su documentación permanecerá en silencio siempre que no la vuelva a leer con mucho cuidado .

Finalmente, a veces encuentro un problema: las pruebas automatizadas pueden depender de las herramientas, y esas herramientas pueden estar mal escritas. Comencé un proyecto usando XUL hace algún tiempo y, hombre, es doloroso escribir pruebas unitarias para dicha plataforma. Comencé otra aplicación usando Objective-C, Cocoa y Xcode 3 y el modelo de prueba era básicamente un montón de soluciones.

Tengo otras experiencias sobre las desventajas de las pruebas automatizadas, pero la mayoría de ellas se enumeran en otras respuestas. No obstante, soy un defensor vehemente de las pruebas automatizadas. Esto ahorró mucho trabajo y dolor de cabeza y siempre lo recomiendo por defecto. Creo que esas desventajas son solo simples detalles en comparación con los beneficios de las pruebas automatizadas. (Es importante proclamar siempre su fe después de comentar herejías para evitar el auto da fé).

brandizzi
fuente
3

Dos que no se mencionan son:

  • Duración del tiempo de reloj que puede llevar ejecutar un conjunto de pruebas grande

He sido parte de los esfuerzos automatizados de control de calidad en los que me llevó medio día ejecutar las pruebas, porque las pruebas fueron lentas. Si no tiene cuidado al escribir sus pruebas, su conjunto de pruebas también podría resultar de esta manera. Esto no suena como un gran problema hasta que ahora esté manejando ese tiempo, "Oh, acabo de cometer una solución, pero tomará 4 horas probar la corrección".

  • Fragilidad de algunos métodos de escritura de prueba.

Algunos métodos de prueba (como la automatización de la interfaz de usuario) parecen romperse cada vez que se da la vuelta. Especialmente doloroso si su script, por ejemplo, bloquea el proceso de prueba porque está esperando que aparezca un botón, pero el botón ha cambiado de nombre.

Estas son dos cosas que puede solucionar, con una buena práctica de prueba: encuentre maneras de mantener su conjunto de pruebas rápido (incluso si tiene que hacer trucos como distribuir ejecuciones de prueba en máquinas / CPU). Del mismo modo, se puede tener cuidado al tratar de evitar métodos frágiles para escribir pruebas.

RyanWilcox
fuente
2

Quiero agregar uno más, una falsa sensación de seguridad.

Más allá de conjuntos de problemas muy pequeños y bien definidos, no es posible crear pruebas exhaustivas. Puede haber, y con frecuencia habrá, errores en nuestro software que las pruebas automatizadas simplemente no prueban. Cuando pasan las pruebas automatizadas, con demasiada frecuencia asumimos que no hay errores en el código.

Jim C
fuente
0

Es difícil convencer a la gerencia / capitalista de riesgo

  • testautomation aumenta el costo inicial.
  • La testautomation aumenta el tiempo de comercialización.
  • El beneficio de la testautomation viene a mediados y a término. La feroz competencia se centra más en los beneficios a corto plazo.

ver Pruebas de unidades dirigidas por el mercado para más detalles.

k3b
fuente
-1

Una de las principales desventajas puede superarse mediante el uso de pruebas de autoaprendizaje. En esta situación, todos los resultados esperados se almacenan como datos y se pueden actualizar con una revisión mínima por parte del usuario del conjunto de pruebas en modo de autoaprendizaje (mostrar diferencias entre el resultado esperado anterior y el resultado real nuevo; actualización esperada si se presiona y). Este modo de aprendizaje de prueba debe usarse con precaución para que no se aprenda el comportamiento defectuoso como aceptable.

Richard Kay
fuente