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

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.

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.

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.

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.

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.

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.

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.

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é).

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.

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.

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.

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.