Apuesto a que has escuchado alguna vez esta frase (o parecida): “Tenemos que conseguir la automatización del 100% de nuestras pruebas de software”. 🧐
El objetivo parece fantástico, en aras de conseguir producir un software (SW) de calidad máxima. Pero debemos tener en cuenta que el proceso de automatización de pruebas puede llegar a ser muy costoso, por lo que se hace necesario seleccionar bien los casos de prueba a automatizar, para que la inversión que vayamos a realizar nos salga rentable. Es decir, deberemos comparar el beneficio a obtener con el coste que nos vaya a conllevar dicha automatización.
¿En qué consiste la automatización de pruebas de software?
📟 La automatización de pruebas de software consiste en crear programas (“scripts”) que mecanicen y permitan la ejecución desatendida de casos de prueba de aplicaciones de SW. Para hacerlo se usan unas utilidades (“frameworks de automatización”) que generan las secuencias que realizaría un usuario cuando realiza una prueba y que incluye las actividades siguientes:
- Preparación de los datos a utilizar.
- Navegación en la aplicación siguiendo los pasos necesarios para probarla.
- Registro de la ejecución en la herramienta de gestión de pruebas.
- Recogida y grabación de evidencias de las pruebas.
- Generación de informe con los resultados.
💻 Los “frameworks de automatización” permiten realizar todas estas actividades a través de lenguajes de programación, que pueden ser de alto nivel y/o cero código (para automatizadores con pocos conocimientos técnicos) o de bajo nivel (para personas más técnicas).
Cuanto más bajo sea el nivel de programación, más sofisticados podrán ser los programas automáticos, pero claro, a costa de perfiles de personas posiblemente más caros… ¡Todo cuenta!.
En el contexto Agile la automatización cobra una importancia especial, dada la necesidad de realizar entregas continuas, que requieren procesos de prueba muy frecuentes.
Business Case 📋
A la hora de decidir cuánto y qué automatizar, debemos tener claros cuáles son los conceptos que contribuyen al coste, qué es lo que deberemos comparar con los costes de realizar pruebas manuales.
Los costes incluyen:
- Diseño de los casos de prueba que, como indicamos anteriormente, se realiza mediante técnicas de programación (el perfil de personas requerido suele ser más caro que el necesario para realizar pruebas manuales).
- Mantenimiento de los casos de prueba, y esto suele no tenerse en cuenta y es muy importante. Dado que los casos automáticos incluyen programación sobre las propias aplicaciones a probar, cualquier cambio en dichas aplicaciones va a requerir reprogramar los casos, y esto es considerablemente más caro que mantener casos de prueba manuales.
- La tipología de aplicaciones a automatizar también condiciona el coste: automatizar interfaces de usuario es mucho más complejo que automatizar capas más cercanas al servidor (como APIs, acceso directo a bases de datos o microservicios).
Los ahorros vienen generalmente de que la ejecución, al ser automática, no requiere intervención humana y lo único que el usuario debe hacer es revisar los registros de las ejecuciones para ver si han sido correctas o no.
Criterios de automatización 📑
No vamos a encontrar una fórmula que nos diga con precisión cuánto y qué debemos automatizar. Lo que sí podemos es facilitar algunos criterios para tener en cuenta a la hora de decidir el nivel de automatización. Entre ellos conviene considerar los siguientes:
- Estabilidad: cuanto más estable sea una aplicación menos mantenimiento tendrá y, por tanto, menos costará el mantenimiento de los casos automatizados. Aplicaciones nuevas son muy susceptibles a cambios y, por tanto, a tener altos costes de automatización.
- Criticidad: aquellas funcionalidades que tengan muy alta frecuencia de ejecución o cuyo impacto en el negocio en caso de fallo sea muy alta. Querremos que se prueben cada vez que se despliegue nuevo SW, para garantizar que siguen funcionando.
- Fragilidad: se trata de funcionalidad cubierta por un desarrollo complejo, donde se considera probable que una nueva versión pudiera incluir defectos.
Otro recurso para ayudar en la decisión de qué automatizar es la pirámide de Cohn.
La pirámide viene a decir que, cuánto más abajo, más debería automatizarse:
- Pruebas unitarias: defectos detectados aquí evitará encontrarlos en fases posteriores del desarrollo, con el consiguiente ahorro de costes.
- De APIs y componentes: esta automatización no suele ser compleja, y si escogemos componentes estables el “business case” seguramente sea favorable.
- De interfaz gráfica (GUI): automatización compleja y, además, de ejecución lenta. No es recomendable automatizar mucho de esto, siendo la prueba exploratoria una muy buena alternativa.
Puntos fundamentales en todo proyecto 👀
Estaremos de acuerdo en que las pruebas son un elemento decisivo a la hora de garantizar la calidad del SW, por lo que invertir en calidad siempre es importante.
El triángulo de hierro se utiliza en desarrollos Agile para referirse a las tres piezas fundamentales de todo proyecto (alcance, coste y tiempo), en el sentido que, para conseguir una calidad determinada, se necesita una combinación de dichos factores.
Cambiar uno de ellos implica tener que cambiar alguno de los otros (o ambos) para compensar. Encontrar la mejor combinación, dependiendo de las circunstancias concretas de cada proyecto, es clave para la gestión y para conseguir, en último extremo, el nivel de calidad deseado.
Si te dedicas al mundo IT y sigues liándote al escuchar términos como «Pruebas de Software» o «Calidad del Software», este otro post donde os contamos las diferencias entre ambos términos, te interesa.
Santander Global T&O es una compañía del Grupo Santander con más de 3.000 empleados y basada en Madrid, trabajamos para convertir al Santander en una plataforma abierta de servicios financieros.
Mira las posiciones que tenemos abiertas aquí para unirte a este equipazo y Be Tech! with Santander
Síguenos en LinkedIn y en Instagram.
Mariano Saúca
Santander Global T&O
Activo e inquieto en todos los ámbitos y absoluto convencido de que Querer es poder. Me apasiona gestionar equipos de trabajo y hacerles crecer, así como hablar en público y divulgar (raro que es uno…). Sin una vocación clara, en los últimos años dedicado al mundo de calidad de SW, porque es lo que me tocó. Lo importante es aportar valor haciendo lo que te toque hacer.
