Pruebas automatizadas: explicando su valor comercial

Para empezar, no creo que esto sea una repetición de otras preguntas sobre las pruebas unitarias . Estoy buscando ayuda para articular su valor a un equipo de programadores, analistas, gerentes y evaluadores. Mediante pruebas automatizadas, no creo que necesite hacer una distinción entre pruebas unitarias (por ejemplo, JUnit), BDD (por ejemplo, JBehave, Fitness) y UI (Selenium, Watir) porque creo que todas ofrecen un valor similar (pero siéntase libre de escribe una respuesta que no está de acuerdo :))

La siguiente es una lista que he identificado, estoy buscando respuestas que ayuden a expandir o refinar:

1. Ahorro de tiempo / costo : escribir pruebas automatizadas puede tomar más tiempo que los casos de prueba escritos. Sin embargo, teniendo en cuenta que las pruebas se ejecutan varias veces, el trabajo marginal (es decir, costo / tiempo) para ejecutar pruebas automatizadas es de varios órdenes de magnitud menos. Que las pruebas automatizadas sean baratas de ejecutar facilita cambiar el sistema con el tiempo.
2. Documentación : no hay una forma más verdadera de saber cómo funciona un sistema que sus pruebas. Cualquier otra documentación generalmente está desactualizada en el momento en que se escribe, pero las pruebas (al menos las que pasan) revelan cómo funcionan realmente las cosas. Esto es cierto tanto para el usuario final como para la documentación de la API.
3. Calidad del código : la escritura de prueba lo obliga a:
   • considerar clientes porque las pruebas son un cliente
   • rompe las dependencias donde hacer que el código sea comprobable a menudo significa descubrir cómo hacer que ese código no requiera que algún otro sistema grande esté disponible

Algunos de mis pensamientos:

1. Sé honesto que escribir pruebas automatizadas llevará más tiempo. Si está haciendo TDD a nivel de unidad (lo que recomendaría como punto de partida si va a invertir en pruebas automatizadas), puede esperar alrededor del 30% de tiempo adicional necesario para codificar una función. La clave aquí es explicar que este 30% adicional (que probablemente sea superior al 30% al principio a medida que su equipo aprende a escribir buenas pruebas) es una inversión creada para ahorrar costos con el tiempo. Como mínimo con TDD a nivel de unidad, el diseño de su sistema está acoplado de forma flexible y es altamente cohesivo, lo que hace que su sistema sea adaptable a los cambios a lo largo del tiempo. Los nuevos requisitos y los errores inesperados siempre requieren cambios en su sistema,
2. Hay mucho debate sobre el valor de las pruebas de nivel de aceptación y de interfaz de usuario dada la cantidad de tiempo que lleva escribir estas pruebas, cuánto tiempo lleva ejecutarlas y cuánto mantenimiento requieren. Recomiendo leer este artículo de James Shore sobre esto.
3. En el mundo de las pruebas automatizadas, hay buenas y malas maneras de hacerlo. Si está presentando pruebas automatizadas a su gerencia, le diré cómo planea hacer que su equipo se capacite para escribir buenas pruebas. The Art of Unit Testing de Roy Osherove, Working Effectively With Legacy Code de Michael Feathers y The Art of Agile Development de James Shore son excelentes libros que abordan estos temas directa o indirectamente. También debe buscar algún tipo de entrenador o entrenamiento formal. Es un gran cambio.
4. En términos de valor comercial, los puntos # 2 y # 3 de sus puntos anteriores en realidad sirven a su primer punto, por lo que me gustaría volver a casa en el punto # 1 y hablar sobre cómo los puntos # 2 y # 3 sirven a ese punto mayor. La documentación hace que su sistema sea más comprensible, lo que hace que su equipo trabaje más rápido. Code Quality hace que su sistema se adapte a los cambios, lo que hace que su equipo trabaje más rápido. Para los empresarios, se trata de maximizar el flujo de valor desde el momento en que se presenta una idea hasta el momento en que la idea se entrega como software de trabajo.

Una cosa de valor definitivo es que las pruebas automatizadas pueden ejecutarse continuamente; como cada hora en una reconstrucción o similar. Hacer esto obliga a que cualquier error o regresión salga a la luz rápidamente en cuestión de horas o días después de que un programador trabaje en el código infractor, esto hace que el cambio de contexto sea mucho más fácil. El segundo beneficio de las pruebas continuas es que te obliga a mantener tus pruebas en un estado de trabajo; nada es más tedioso que pasar la primera semana de un ciclo de prueba arreglando todas las pruebas desactualizadas. Si puede automatizarlos, puede ejecutarlos en cualquier momento y al ejecutarlos regularmente puede detectar errores en sus pruebas o código rápidamente.

Gastos de prueba

Una vez que se escribe una prueba automática, puede ser ejecutada por una computadora a costa de unos pocos julios. La prueba manual equivalente requiere que una persona en la nómina trabaje en una lista de instrucciones.

Prueba de confiabilidad

Se puede confiar en la computadora para ejecutar fielmente el mismo procedimiento de prueba, siempre. El humano puede cometer errores y ser flojo.

Los modos de falla de prueba de la computadora también son mucho más evidentes: se bloqueó (los informes de prueba dejan de aparecer), tuvo un pequeño error que causó un resultado de prueba falso (ejecute una prueba determinista nuevamente y el resultado difiere). Si un humano pierde un paso y marca el "OK", ¿cómo podemos saberlo?

Prueba de durabilidad

Una prueba automatizada tiene que ser un artefacto concreto (por ejemplo, un fragmento de código) para ejecutarse, y naturalmente se incluye con los otros artefactos de desarrollo de software: el repositorio de origen. Un probador puede desarrollar una prueba manual en una hoja de papel de nota y nunca formalizarla. Es más probable que el negocio necesite procesos para garantizar que eso no suceda.

Valor de prueba

La computadora puede ser programada para generar resultados de prueba en una forma consistente y fácilmente analizada. La persona está haciendo la entrada de datos para generar lo mismo, o está grabando notas de forma libre que requieren un analista, desarrollador o gerente para digerir.

Principalmente (dependiendo de su cobertura de prueba) código libre de errores, y yo diría que uno de los mayores argumentos es cuando le dice a su gerente que puede escribir una prueba para un error descubierto, asegurando que siempre sabrá en el futuro si ese error vuelve :)

Mi opinión es que las pruebas de unidad / integración son más importantes, mientras que si aplica algún patrón de interfaz de usuario como MVC, es suficiente para la mayoría de los proyectos. Por lo general, pruebo todas las acciones en mis controladores / presentadores y dejo el enlace de datos a las Vistas.

Por supuesto, las pruebas automatizadas no sustituyen a los viejos puntos y clics aventureros en torno a su aplicación, tratando de descubrir las cosas más salvajes que su usuario podría hacer.

También hay un punto de integración continua .

Una cosa más: uno debe esforzarse por que la calidad del código conduzca a la calidad del producto, el valor comercial y la capacidad de mantenimiento; de lo contrario, no tiene sentido hacerlo.

Creo que deberías liderar con los puntos mágicos de "menor costo" y "más funciones / unidad de tiempo" / menor tiempo de ciclo.

Sin embargo, antes de presentar un caso, le aconsejaría que reflexione sobre su situación. Su pregunta me llevó a escribir una publicación de blog sobre los posibles inconvenientes de las pruebas automatizadas.

La facilidad de refactorización es un factor importante aquí. Al tener una buena cobertura mediante una prueba de unidad agradable y READABLE (!!!), puede refactorizar su sistema sin preocuparse por comprometer la funcionalidad existente.

Tienes que vender el concepto, debes evitar decirles que mejorará el código. Si tienen alguna inversión en el código, eso los pondrá inmediatamente en contra de usted / prueba automática. Si son buenos, también entenderán GIGO, por lo que no entenderán por qué crees que no se aplica.

Dejaría venderlo también como aspecto de documentación, cosas como Fitnesse pueden hacerlo bien, pero hasta que lo experimenten, puede ser difícil de visualizar.

Áreas en las que creo que podría tener suerte vendiéndolo

1. Las pruebas unitarias pueden tomar el lugar de muchos arneses de desarrolladores, donde se crea una aplicación solo para llegar al área para depurar / probar sin pasar por todos los inicios de sesión / menús.

2. Las pruebas le permiten configurar y repetir fácilmente situaciones problemáticas, sin perder mucho tiempo configurando datos de prueba (especialmente usando un sistema de burla decente)

3. A medida que construye conjuntos de pruebas de BDD y UI, obtiene una respuesta mucho más rápida si hay pausas simples que esperar la próxima vez que el probador lo mire

4. Las pruebas de BDD y UI pueden evitar que presione repetidamente los botones para verificar todos los aspectos que podrían haberse visto afectados por su cambio y evitar que tenga que recordar todas las áreas.

5. Las compilaciones automáticas a menudo se destacan cuando alguien se ha olvidado de ingresar el código

6. Las pruebas lo ayudan a evitar que vuelvan a aparecer errores.

7. Las pruebas unitarias y la burla decente significarán menos código interconectado y serán más fáciles de resolver

Recuerde que está tratando de venderlo, no convertirlo a una religión, así que acepte pequeños pasos e intente no hacerlo en contra de usted. También les tomará tiempo adaptarse y aprender a escribir buenas pruebas.

Alguien debe creer que hay un problema antes de aceptar una solución propuesta para ese problema.

Las pruebas automatizadas pueden ahorrar costos de corrección de errores, por lo que si sus colegas no creen que los costos de corrección de errores sean considerables o excesivos, será difícil convencerlos. Si esos costos son altos o excesivos, pero las personas no creen que lo sean, es posible que primero deba obtener algunos datos convincentes sobre esos costos.

Lo que les encanta a las empresas es aumentar el valor y reducir los costos. Debe explicar cómo las pruebas automatizadas aumentarán el valor, ya que agrega un costo adicional.

Si su código es modular, será posible reutilizarlo. Lo que significa que las pruebas no tienen que volverse a escribir de nuevo y solo puede trabajar sobre ese código existente.

Si hay proyectos heredados, las pruebas automatizadas hacen que sea mucho más fácil refactorizar. La deuda técnica debe pagarse en algún momento.

El argumento de documentación que proporciona no es muy bueno. La diferencia entre mantener las pruebas actualizadas y la documentación actualizada es solo un hábito.

"Lo que busco es ayuda para articular su valor para un equipo de programadores, analistas, gerentes y evaluadores. Mediante pruebas automatizadas, no creo que necesite hacer una distinción entre pruebas unitarias (por ejemplo, JUnit), BDD ( por ejemplo, JBehave, Fitness) y UI (Selenium, Watir) porque creo que todos proporcionan un valor similar (pero siéntase libre de escribir una respuesta que no esté de acuerdo :)) "

OK, aceptaré ese desafío;)

Principalmente trabajo con programadores y control de calidad y mis herramientas son rubí, rieles, testunit, rspec, jazmín y selenio.

Las herramientas BDD / TDD de rspec y testunit son parte de la programación. No los separa y habla de ellos por separado a la gerencia, no los pospone debido a la falta de tiempo, los incluye en todas sus estimaciones de tiempo. Si realmente lo presionó, le preguntó cuánto tiempo tiene la gente para que usted les explique la informática y la programación. No uso estas pruebas para el front end

GUI / UI / Jasmine / Selenium. Estos son diferentes Las hice personas de QA que tienen experiencia en programación. Nos aseguramos de que las pruebas estén escritas para ser lo más robustas posible y basadas en el contenido, no en el diseño. El costo (posiblemente nuevo) de esto debería explicarse como un costo desplazado . En lugar de pagar con software dañado, clientes perdidos y soluciones costosas más tarde, ahora paga mucho menos (relativamente) con algunas prácticas simples.

Creo que la clave es hablar sobre categorías específicas de pruebas que creará, no 'pruebas automatizadas' en su conjunto. Este último puede ser un poco nebuloso y preocupante, y es demasiado fácil encontrar ejemplos de dónde sería una pérdida de tiempo.

Siempre recomiendo dividir sus pruebas en 4 grupos (más detalles aquí ). Quédate conmigo aquí, veré cómo esto te ayuda a vender pruebas a otros en un momento.

1. Pruebas de su funcionalidad principal . Es decir, para una herramienta de monitoreo de sitios web, esto sería pruebas de alertas que deberían activarse para los sitios web que está monitoreando. Estas pruebas aseguran que estas cosas nunca se rompan.
2. Pruebas de humo de toda su aplicación . Por ejemplo, usando Selenium para navegar por todos los enlaces / botones en una aplicación web y asegurarse de que no haya errores del servidor. Estas pruebas evitan que pierdas el tiempo de los probadores con compilaciones obviamente rotas.
3. Pruebas de cualquier código frágil . Es decir, para ese viejo módulo que nadie quiere tocar, o la compleja pieza de código que parece tener siempre errores.
4. Pruebas que los desarrolladores querían escribir para apoyar su trabajo . Porque a veces las pruebas son útiles cuando escribes algo, pero no caigas en las categorías anteriores.

Al dividir sus pruebas en estas categorías, ahora puede tener una discusión diferente. Tome los primeros tres grupos (el cuarto queda a discreción individual de todos modos) y pregunte si la gente piensa que valdría la pena hacer pruebas para esos códigos. Si no puede llegar a un acuerdo, tal vez no incluya esas pruebas por ahora. Si puede, es decir, si las personas están de acuerdo en que las pruebas en torno a la funcionalidad central que se ejecutan en cada confirmación son útiles, entonces comience a agregarlas.

El otro grupo que puede ser útil son las pruebas que son difíciles o lentas de hacer manualmente . Debería haber un beneficio bastante fácil de explicar aquí en términos de ahorrar tiempo de prueba manual, o hacer que se prueben las cosas que se omiten por falta de tiempo.