Testing Automatizado en agile


En esta entrada vamos a ver como debemos estructurar nuestro testing automatizado en un proyecto agile.

Primer idea

Al pensar en pruebas automatizadas, como testers, lo primero en que pensamos es en automatizar la interfaz de usuario ya que es la capa de la aplicación con la que mas interactuamos, siendo así nuestra zona de confort, una estructura que nos imaginamos sería algo así:

Primer Idea

Esto se potencia por la creciente oferta de herramientas de automatización enfocadas en la capa de interfaz de usuario.  Pero esta estrategia es errónea,  es inestable y frágil; cada vez que la interfaz de usuario de la aplicación cambia, los tests automatizados se ven fuertemente afectados. Por lo tanto uno de los problemas es la estabilidad de la automatización y los costos de mantenimiento. Otro problema es que no se involucra a todo el equipo, sólo los testers generan los tests automatizados y por lo general sólo comprenden una parte menor del equipo generando una sobrecarga con el tiempo dedicado a las pruebas manuales contra el desarrollo de la automatización de pruebas.

Mejorando la idea

Un punto clave para que los productos desarrollados en metodologías ágiles tengan éxito es entender que la calidad la hacen todos y no solo los testers del equipo, ese es un paradigma del desarrollo en cascada, en agile, la calidad la hacemos entre todos.

Por eso, una estrategia de automatización eficaz requiere la automatización en tres niveles diferentes, como se muestra en la siguiente figura, que representa la pirámide de automatización de las pruebas.

Mejorando el modelo

Pruebas de Unidad (Unit Test)

En la base de la pirámide de automatización esta la prueba de unidad (unit test). Las pruebas de unidad deben ser la base de una estrategia de automatización sólida y, como tal, representar la parte más grande de la pirámide. Las pruebas unitarias son maravillosas porque dan datos específicos a un programador (hay un error y está en línea 47) lo que es mucho mejor que tener un tester que te dice: “Hay un error en cómo se está recuperando registros de miembros de la base de datos“, lo que podría representar 1.000 o más líneas de código. Además, debido a que las pruebas unitarias se escriben normalmente en el mismo lenguaje que la aplicación, los programadores suelen estar más cómodo al escribirlos.

Herramientas más comunes son aquellas variantes xUnit:

Pruebas de Servicios (Capa Media)

Todas las aplicaciones se componen de varios servicios. En la manera en que yo lo estoy usando, un servicio es algo que la aplicación hace en respuesta a alguna entrada o conjunto de entradasPruebas a nivel de servicio es verificar una aplicación por separado de su interfaz de usuario. Ignorar las pruebas en esta capa media, es lo que hace fracasar muchos proyectos de automatización. Aunque automatizar las pruebas unitarias es maravilloso, no alcanzan para cubrir todas las opciones brindadas por una aplicación. Sin pruebas a nivel de servicio para llenar el vacío entre las pruebas de unidad y las pruebas a nivel de interfaz de usuario, todas las prueba terminan siendo a nivel de la interfaz de usuario, lo que resulta en pruebas que son caras de mantener, requieren mucho esfuerzo para escribir, y  resultan frágiles.

Herramientas mas comunes:

Pruebas típicas:

  • Pruebas de Componentes
  • Pruebas de Integración
  • Pruebas de Aceptación

Pruebas de Interfaz de Usuario (UI Testing)

Las pruebas automatizadas de la interfaz de usuario se coloca en la parte superior de la pirámide de automatización, porque queremos hacer tan poco de ella como sea posible. ¿Por que? Las pruebas a nivel Interfaz de Usuario (UI), sin duda funcionan, pero son frágiles, costosas, y requieren de mucho tiempo. Lo importante aquí no es desechar las pruebas de interfaz de usuarios, solo ser consciente de estos “costos” y automatizar por interfaz de usuario solo aquellos escenarios sumamente importante para el negocio, escenarios que se sabe que pueden ser afectados fácilmente por los cambios realizados en el sprint y escenarios dependientes de la plataforma (en caso de crossbrowsing o dispositivos móviles). Además, hay que ser lo menos redundante posible al momento de elegir escenarios para automatizar desde la interfaz de usuario (pensar en cuántas veces un conjunto de pruebas pondrá a prueba la misma interfaz de usuario). Como seleccionar tests a automatizar, es una temática que extenderé en un próximo post.

Herramientas más comunes:

Pruebas típicas:

  • Pruebas Funcionales
  • Pruebas de Humo
  • Pruebas de Regresión

Te gustó el post? Quieres contribuir? Contribute with the Blog

8 pensamientos en “Testing Automatizado en agile”

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s