Valor relativo de las pruebas manuales vs automatizadas

La organización para la que trabajo ha empleado recientemente a un oficial de pruebas para realizar pruebas manuales, pero cuando pregunté si me daban tiempo como desarrollador para escribir pruebas unitarias, la respuesta fue que las pruebas manuales proporcionarían una inversión mayor. Eso es algo que me parece mal y estoy buscando un medio para evaluar las pruebas manuales y automatizadas entre sí que sea más científico que una intuición. No digo que no haya lugar para las pruebas manuales, pero las pruebas automáticas me parecerían, al menos para mí, eliminar algunas de las tareas más repetitivas y aburridas. Tenemos un servidor de compilación que ejecuta algunas pruebas unitarias y algunas pruebas de selenio, por lo que no parece que la idea de las pruebas automatizadas sea una opción prohibida, sino que se ve como un menor retorno de la inversión.

Puedo entender que hacer que alguien realice una prueba completa de un sistema prueba el producto final y, en última instancia, eso es lo único que le importa al usuario, pero es lento y muy repetitivo. La prueba de regresión manual significa repetir todas las pruebas anteriores y confirmar que nada ha cambiado y si hay 4 caminos a través de un proceso, entonces son 4 pruebas manuales que bien podrían tomar 5 minutos cada una.

Entonces, ¿hay datos y cifras verificables que pueda usar para justificar el tiempo de presupuesto para las pruebas automatizadas? Para el caso, ¿cuáles son las desventajas de las pruebas automatizadas más allá de las del enlace?

Tendría mucho cuidado al pensar en pruebas "manuales" versus pruebas "automatizadas" en un contexto de retorno de la inversión (ROI). Es una forma de pensamiento falaz cuando se discute el valor de la automatización (consulte la sección "Máquina del tiempo" de ese enlace).

La falacia de Time Machine resumida es esta: la única forma en que realmente puede determinar el ROI de un enfoque de prueba es tener una máquina del tiempo donde pueda visitar el futuro y ver qué sucedió. Como usted (muy probablemente) no puede hacer esto, las estimaciones de ROI deben considerarse como una heurística en el mejor de los casos, y no una regla difícil. Usar información actual para tomar una decisión informada sobre un esfuerzo de prueba dado es útil para su equipo o no.

En cambio, cuando se trata de pruebas, piense qué áreas de su producto necesitan más atención y dónde pueden estar los mayores riesgos. Quizás se haya identificado que las pruebas de integración de extremo a extremo podrían encontrar la mayoría de los problemas con su aplicación. Incluso si las pruebas unitarias traen beneficios, esos beneficios pueden no valer los costos asociados (conseguir que los desarrolladores compren, escribir y ejecutar pruebas, etc.). Del mismo modo, intente pensar en beneficios / costos en lugar de ventajas / desventajas para las pruebas.

Primero, debe diferenciar claramente las pruebas unitarias y otras pruebas automatizadas . Esas son dos cosas diferentes, con objetivos diferentes.

Las pruebas unitarias son pruebas para validar porciones muy pequeñas de su código. Generalmente son pruebas de caja blanca, escritas por un desarrollador que conoce el código fuente "bajo prueba". En TDD, están escritos en una primera prueba, por un desarrollador que va a escribir el código fuente después de que él escribió la prueba. Ese tipo de pruebas no pueden transferirse a un "oficial de pruebas" por su naturaleza, y si su organización no está completamente equivocada, no debería tener que preguntarle a su jefe si puede escribirlas, y cuándo puede hacerlo, tal como no debería haberlo hecho. preguntarle a su jefe si puede escribir comentarios en su código fuente y cuándo lo hará.

Las pruebas de integración, las pruebas de aceptación y otras pruebas de caja negra son algo diferente. Si tiene un oficial de pruebas que va a aplicar esas pruebas solo manualmente, y tiene que repetir el mismo tipo de pruebas una y otra vez, él debe solicitar la necesidad de automatización, no usted (por supuesto, debe haga transparente para él qué tipo de pruebas puede automatizar y cuáles no). Debería decirle para qué tipo de pruebas cree que la automatización tendrá sentido y para cuál no. Quizás él mismo va a hacer la automatización, usando alguna herramienta de prueba de regresión, o le pedirá ayuda para crear algunas herramientas para él.

Por supuesto, cuando piense que si no tiene la experiencia o la inteligencia suficiente para llegar solo a esa conclusión, debe hablar con él (y si eso no ayuda, quizás con su jefe). Sin embargo, en mi humilde opinión, debe hacer esto solo cuando tenga la impresión de que su oficial de pruebas es un cuello de botella en su producción debido a la falta de automatización de pruebas.

Todos siempre quieren ejemplos y estudios externos, pero estos no son muy efectivos para convencer a la gerencia. Si las pruebas manuales son realmente un cuello de botella en su empresa, tendrá todos los ejemplos internos que necesita:

Un error accidentalmente sale por la puerta. Usted declara que solía funcionar y solicita que se agregue a las pruebas de regresión. El probador manual afirma que hará que las pruebas de regresión demoren demasiado. Usted ofrece hacer una prueba automatizada para ello. El probador manual agradece la idea porque se ha sentido abrumado y le gustaría tener más tiempo para concentrarse en los casos de prueba más "interesantes". Con las voces de clientes enojados aún resonando en sus oídos, la gerencia comienza a ver su punto sobre la automatización de pruebas.

Si reuniones como esta no están sucediendo en su empresa, ninguna cantidad de estudios externos hará su caso.