Page 31 - REVISTA 2016

Para lograr testing continuo tenemos que tener claro qué es lo que estamos probando, cómo y qué tan
bien. Todo esto se logra con un buen enfoque de testing, ya sea exploratorio o planificado, pero nunca
ad-hoc.

La automatización de pruebas

El testing automatizado consiste en que una máquina logre ejecutar los casos de prueba en forma automática,
leyendo la especificación del mismo de alguna forma, que pueden ser scripts en un lenguaje genérico o propio de
una herramienta, a partir de planillas de cálculo, modelos, etc (aparece en el libro del mismo autor “Introducción a
las Pruebas de Sistemas de Información”). El objetivo es que con el uso de estas herramientas se pueda aumentar
el alcance de los testers, permitiendo automatizar ciertos procesos que suelen ser reiterativos. Uno de los objeti-
vos perseguidos en la automatización, es tener feedback sobre el estado de calidad del software lo antes posible,
y así reducir costos no solo de testing sino de desarrollo también. Bien se sabe que automatizar el caos trae caos
más rápido, con lo cual para el éxito de esta actividad es fundamental seleccionar adecuadamente lo que se va
a automatizar, los casos de prueba de los que mayor retorno se obtenga, y el nivel al cual se hacen las pruebas
automatizadas. El problema típico es que la mayoría de la gente lo primero que piensa al hablar de testing auto-
matizado es en automatizar las acciones de un usuario, a nivel de interfaz gráfica, pero no es ni la única ni la mejor
opción. Para entender esto tenemos que hablar de la Pirámide de Cohn.

En esta pirámide se definen varios niveles de pruebas, señalando el grado en el que se deberían automatizar. Lo
recomendado desde este punto de vista sería:

Mayor cantidad de tests automatizados a nivel unitario, logrando que los desarrolladores sean los primeros en
detectar fallos.
Bastantes tests a un nivel intermedio, lo que incluiría API, integración de componentes o servicios, que son más
estables y buenos candidatos a automatizar.
Menor cantidad de tests a nivel de interfaz gráfica automatizados, porque estos tests son más lentos de ejecutar
y más difíciles de mantener.
Los test de interfaz gráfica dan un grado de tranquilidad mayor, ya que se prueban las funcionalidades end-
to-end, pero no es recomendable apuntar a tener solo ese tipo de test automatizado, ni que sea la mayoría del
test-set. Para tener una referencia, Google dice tener un 70% de sus pruebas automatizadas a nivel unitario, 20%
a nivel de API y solo 10% a nivel de interfaz gráfica. El objetivo de este esquema es que llegue un momento en el
que invirtiendo los mismos recursos se logre cada vez una cobertura mayor de pruebas.

Reflexiones sobre Ingeniería 33