Automatizaci贸n Test de Software (1) Desarrollo

3 criterios clave para la automatizaci贸n de pruebas de software

03/06/22 6 min. de lectura

Apuesto a que has escuchado alguna vez esta frase (o parecida): 鈥淭enemos 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.

Appropriate selection of test cases for automation to determine ROIpruebas software

驴En qu茅 consiste la automatizaci贸n de pruebas de software?

馃摕 La automatizaci贸n de pruebas de software consiste en crear programas (鈥渟cripts鈥) que mecanicen y permitan la ejecuci贸n desatendida de casos de prueba de aplicaciones de SW. Para hacerlo se usan unas utilidades (鈥渇rameworks 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 鈥渇rameworks 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.

Frameworks de automatizaci贸n para realizar las actividades a trav茅s de lenguajes de programaci贸n

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.

Pir谩mide de Cohn
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 鈥渂usiness 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.

Tri谩ngulo de Hierro Agile
Tri谩ngulo de Hierro

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.

 

Otros posts