¿Pruebas manuales o automáticas?

Esta es una de esas típicas preguntas que se plantea casi todo aquel a quien le ha tocado dirigir el desarrollo o el control de calidad de un producto software. Cuando uno se lo plantea por primera vez, así, a priori, la idea de sustituir horas de pruebas manuales por pruebas automáticas suena perfecta. Pulsar “un botón” y lanzar automáticamente las pruebas. Pero cuando se le da unas cuantas vueltas al tema, se empiezan a ver algunos problemillas y aparecen las dudas.
Por experiencia conozco varios proyectos de automatización de pruebas que terminaron en auténticos desastres. Recuerdo especialmente un caso en que el equipo de automatización de pruebas trabajaba de forma totalmente independiente al equipo de desarrollo, y ambos equipos trabajaban además sin tener por detrás un buen sistema y estrategia de gestión de la configuración, lo que hacía que los scripts de pruebas estuvieran constantemente desactualizados, con lo que el supuesto ahorro de la automatización se iba en el mantenimiento de los scripts de pruebas. La automatización de pruebas supone al fin y al cabo generar más código, el de las pruebas, que hay que mantener.
Sobre el qué, cuánto y dónde automatizar hay mucho escrito, si bien quería dejar en este post la idea de los cuadrantes que aparecen en el libro Agile Testing, que clasifican los diferentes tipos de pruebas y la estrategia recomendada para las mismas:

– Cuadrante 1. Pruebas unitarias y de componentes, que normalmente se recomienda automatizar.
– Cuadrante 2.  Pruebas que pueden realizarse de manera automática o manual, y que suelen ser las pruebas funcionales, simulaciones, prototipos, etc.
– Cuadrante 3.  Pruebas manuales, que suelen ser las de usabilidad, aceptación, de exploración y alpha/beta testing.
– Cuadrante 4.  Herramientas que se hacen con herramientas, como son las de rendimiento y carga.
Todo esto da para mucho hablar y postear. Y eso que no hemos entrado aquí, lo podemos dejar para el futuro, en temas como que además muchas veces los esfuerzos de automatización se ven frustrados por productos cuya arquitectura hace imposible automatizar las pruebas.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba