PDF de programación - Automatizacion de pruebas

Automatizacion de pruebas

Tabla de contenido

1. Introduction
2. Pruebas en contexto
3. Clasificación de pruebas

1. Los cuadrantes de Marick
2. La pirámide de Cohn
3. Una visión mixta

4. Premisas para automatizacion
5. Arquitectura de prueba
6. Pruebas del desarrollador
1. Pruebas unitarias
2. Dobles de test

7. Pruebas de usuario

1. Selenium IDE
2. Cucumber
3. Fitnesse

8. Pruebas de propiedades
9. Cobertura de la prueba
10. test_doubles.md

2

Automatizacion de pruebas

Introduction
Tutorial de Automatización de pruebas

Escribí este material para dar soporte a uno de mis cursos de automatización de pruebas. Dicho curso surgió a partir de consultas
recurrentes que he recibido sobre esta temática.

Con este material busco reunir conceptos y herramientas pues a mi parecer hay un gap en esa relación. Existen varios libros sobre
pruebas automatizadas algunos de ellos están enfocados en conceptos (como es caso de los libros de Agile Testing agile-testing, more-
agile-testing) mientras que otros están enfocados en alguna herramienta particular para hacer un tipo de prueba específico (como el caso
de Cucumber o JUnit). Aquí me propongo reunir ambas cosas.

Gran parte del material aquí reunido ha sido publicado previamente en mi blog: http://nicopaez.wordpress.com. Al mismo tiempo este
material está en constante evolución ya que lo voy a actualizando cada vez que dicto el curso.

En esta primera versión esta basada en tecnologías Java lo cual implica herramientas tales como JUnit, Mockito, Cobertura, Cucumber-
JVM, Fitnesse, JMeter y Cobertura entro otras.

Para feedback o consultas pueden encontrarme en Twitter como @inicopaez.

Nicolas Paez, Julio 2015

Introduction

3

Automatizacion de pruebas

Pruebas en contexto
Pruebas en el proceso de desarrollo
Estrategia de prueba 'ad-hoc'

Esta estrategia es sin duda la menos formal, pero no por ello la menos usada. Partiendo de una especificación de un requerimiento, se
construye una pieza de software acorde a la especificación y luego se la prueba de forma ad-hoc sin seguir ninguna heurística
premeditada. Respecto de los involucrados, tampoco hay formalidades, aunque se observan dos variates bastante populares: o bien una
misma persona se encarga de las 3 tareas o a lo sumo hay un persona que se encarga de la especificación del requerimiento y otra
persona que se encarga de la construcción y la prueba.

Estrategia de prueba tradicional

Esta estrategia es la que muchos hemos aprendido en la universidad y es posiblemente las más utilizada en la actualidad. Partiendo de
una especificación de un requerimiento, se trabaja en paralelo en la construcción de la pieza de software y en la generación de los casos
de prueba que se ejecutarán sobre la pieza de software una vez construida para verificar su correcto funcionamiento.

Estrategia de prueba ágil

Como su nombre lo indica esta estrategia surge con el movimiento ágil. Se parte de una especificación de requerimiento muy liviana
llamada User Story, tan liviana que incluso usar el término especificación resulta incorrecto, posiblemente seria mejor decir
simplemente "enunciado de requerimiento". Ese enunciado de requerimiento es entonces complementado con un conjunto de ejemplos
que constituyen los casos de aceptación y que sirven para guiar al equipo de desarrollo en la construcción de la funcionalidad. Una vez
completada la construcción se verifica que el producto resultante se comporta de acuerdo a los ejemplos.

Pruebas en contexto

4

Automatizacion de pruebas

Pruebas en contexto

5

Automatizacion de pruebas

Los cuadrantes de Marick
Tipos de pruebas: los cuadrantes de Testing

Existen diversas clasificaciones de pruebas pero sin duda una de las que más popularidad a cobrado en los últimos años es la propuesta
por Brian Marick y conocida como los cuadrantes de testing.1.

La clasificación de Marick fue luego tomada y modificada por otros autores entre ellos Gerard Meszaros en su libro xUnit Test Patters.

La versión más difundida de esta clasificación sin dudas es la creada por Lisa Crispin y Janet Gregory en su libro Agile Testing.

Los cuadrantes de Marick

6

Automatizacion de pruebas

Los cuadrantes de pruebas ofrecen una clasificación útil para entender las pruebas desde dos perspectivas:

Función del test: soporte al desarrollo o crítica del producto
Términos en los que se expresa el test: términos del negocio o términos de tecnología

Adicionalmente cada grupo de pruebas definido por esta clasificación comparten algunas propiedades. Las pruebas que guian el
desarrollo son muy factibles de ser automatizadas. Las pruebas técnicas que critican el producto suelen requerir del uso de herramientas
muy específicas y de conocimientos/habilitades particulares. Las pruebas de negocio que critican el producto (exploratorias, de
usabilidad) son poco factibles de ser automatizadas.

Otros tipos de pruebas

Hay dos términos en particular que suelen utilizarse al hablar de pruebas y que suelen generar confusión:

Prueba de integración: término poco feliz si lo hay, ya que conceptualmente prueba de integración es toda prueba que no es
unitaria. Personalmente intento evitar utilizar este término y al hablar de pruebas de integración busco ser más específico.
Prueba de regresión: suele ejecutarse con el fin de asegurar que los cambios realizados sobre una aplicación al introducir nuevas
funcionalidades no afectaron las funcionalidades previamente existentes. En sí no es que una prueba particular sea de regresión,
sino que hacer una regresión implica correr pruebas ya existentes, de diverso tipo para asegurar que nada se ha roto. Es por esto
que personalmente prefiero hablar de "ejecutar una regresión" que de "hacer pruebas de regresión".

Los cuadrantes de Marick

7

Automatizacion de pruebas

La pirámide de Cohn
Pirámide de pruebas

En su libro Succeeding with Agile, Mike Cohn propuso una clasificación de test automatizados conocida como la pirámide de tests.

En la parte inferior de la pirámide se ubican los test unitarios los cuales representan la parte más extensa de la pirámide de
automatización. Los test unitarios brindan feedback muy específico y rápido.

En el otro extremo de la pirámide se encuentran los test de usuario que testean la aplicación punta-a-punta a través de la interface de
usuario. Generalmente querremos tener pocos de estos test debido a su fragilidad y alto costo de mantenimiento.

A partir de esto surge la parte media de la pirámide la cual está constituida por test que van justo por debajo de la interface de usuario y
que Cohn denomina service tests pues testean las funcionalidades/servicios provistas por la aplicación por debajo de la interface de
usuario. Esto hace que sean más robustos y mantenibles que los test de interface de usuario y al mismo tiempo son más abarcativos que
los test unitarios ya que no testean un componente den forma aislada sino un conjunto de ellos que interactuar para implementar una
funcionalidad de negocio.

Varios autores han escrito sobre la pirámide y han expuesto diversos argumentos reforzando el enfoque de Cohn 1 2 3.

Algunos otros autores han propuestos variantes de la pirámide 4.

Referencia: https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid

La pirámide de Cohn

8

Automatizacion de pruebas

Una visión mixta
Una visión mixta

En las secciones anteriores vimos dos modelos (y algunas variantes) de análisis de pruebas. En primer instancia vimos el modelo de
cuadrantes en cual nos sirve para analizar los distintos tipos de pruebas y algunas de sus propiedades. Luego vimos la pirámide las cual
no ayuda a entender cuantas pruebas de cada tipo realizar.

Si analizamos ambos modelos de forma conjunta nos encontramos que la pirámide nos habla concretamente sobre las del margen
derecho de los cuadrantes, o sea, de las pruebas que soportan el desarrollo. Al mismo tiempo encontramos que la parte superior de la
pirámide coincide con el cuadrante de pruebas de aceptación mientras que la parte inferior de la pirámide corresponde al cuadrante de
pruebas unitarias.

Una visión mixta

9

Automatizacion de pruebas

Premisas para automatizacion
Premisas para automatización de pruebas
Testeabilidad

Para que podamos hacer pruebas de una aplicación la misma debe cumplir con ciertas propiedades, o mejor dicho con una propiedad en
particular: tiene que ser testeable. Esta propiedad es relativamente fácil de lograr en la mayoría de los casos con tan solo tomar algunas
acciones en el diseño de la aplicación. Pero curiosamente en muchos casos no se toman esas precauciones y ello termina dificultando la
realización de pruebas. Una forma de asegurar la "testeabilidad" de una aplicación es utilizar Test-Driven Development.

Claro que (casi) siempre es posible realizar pruebas de usuario de caja negra, pero como veremos a lo largo de este libro, hay otros tipos
de pruebas muy útiles que sólo podremos realizar si nuestra aplicación es testeable.

Código de test y de aplicación

El código de test debe tratarse de la misma forma que el código de aplicación ya que este código de test también debe evolucionar a la
par del código de la aplicación.

El manifiesto de automatización de pruebas

Según el manifiesto de automatización de pruebas, toda prueba automatizada debe cumplir con un conjunto de propiedades en las que
que personalmente destaco:

Conciso (concise)
Auto-verificable (self-checking)
Repetible (repetable)
Clara (clear)
Específica (specific)
Independiente (independant)
Mantenible (maintainable)
Traceable (traceable)

Premisas para automatizacion

10

Automatizacion de pruebas

Arquitectura de prueba
Arquitectura de prueba

Una de las decisiones a tomar al querer hacer pruebas automatizadas es qué herramientas utilizar. Para poder tomar esta decisión resulta
importante entender mínimamente la arquitectura de una infraestructura de pruebas automatizadas. El siguiente gráfico resumen de
forma muy general una arquitectura