Las máquinas de estado son una herramienta súper útil para un tester, aunque lamentablemente bastante subutilizada en la industria. Eso me llevó a escribir una serie de posts para explicar la técnica de derivación de pruebas a partir de máquinas de estado:
- En el primer artículo vimos una introducción a la técnica con un ejemplo bien simple.
- En este veremos un ejemplo un poco más complejo en un caso real.
- En el último mostraré el uso de una herramienta con un ejemplo simple para aplicar la técnica.
Vayamos entonces al ejemplo un poco más complejo o más parecido a lo que nos enfrentaremos al probar un sistema. En este ejemplo veremos que no estamos atados a una única representación de máquinas de estado y que podemos aplicar la técnica en forma manual.
Imaginemos que estamos probando un sistema que gestiona artículos. El objetivo es diseñar los casos de prueba para la creación de artículos, teniendo en cuenta todo el ciclo de vida y las distintas personas que tienen que realizar diferentes validaciones y acciones sobre la información cargada al sistema. Para eso decidimos modelar el comportamiento de los artículos con una máquina de estado y a partir de ella derivar los casos de prueba. Los artículos pueden tener distintos estados y el comportamiento esperado para cada acción o funcionalidad del sistema dependerá del estado asociado al artículo.
La siguiente figura presenta una máquina de estado parcial para el concepto artículo. A la izquierda de la figura se puede ver el actor involucrado en la tarea y, en este caso puntual, las guardas están representadas como puntos de decisión en el diagrama.
Los estados determinan distintos comportamientos de las instancias de artículos. Las transiciones se corresponden con funcionalidades del sistema que hacen que el artículo cambie su comportamiento, su estado.
La máquina de estado muestra el comportamiento esperado de la entidad artículo en su ciclo de vida. Lo que se intentará es cubrir todas las transiciones y nodos de este diagrama. El resultado es un conjunto de secuencias a seguir sobre la máquina de estados que definen los casos de prueba interesantes y que para esta máquina de estado son las siguientes:
- Caso 1: Alta preliminar de artículo, verificar datos y rechazar compra.
- Caso 2: Alta preliminar de artículo, verificar datos y aprobar por el comprador responsable de área.
- Caso 3: Alta preliminar de artículo, verificar datos y aprobar por el comprador responsable de área, completar los datos por trade marketing, el gerente de departamento de compras no aprueba la compra por ser un artículo no promocional y saturado.
- Caso 4: Alta preliminar de artículo, verificar datos y aprobar por el comprador responsable de área, completar los datos por trade marketing, el gerente de departamento de compras no aprueba la compra para un artículo promocional y saturado.
- Caso 5: Alta preliminar de artículo, verificar datos y aprobar por el comprador responsable de área, completar los datos por trade marketing, el gerente de departamento de compras aprueba la compra para un artículo no promocional y no saturado.
- Caso 6: Alta preliminar de artículo, verificar datos y aprobar por el comprador responsable de área, completar los datos por trade marketing, el gerente de departamento de compras aprueba la compra para un artículo promocional y saturado.
Hasta aquí se cuenta con los casos de prueba en alto nivel (casos de prueba abstractos). O sea, solo se cuenta con las secuencias de funcionalidades que se deben invocar y las condiciones sobre los datos. Luego, se deben definir los datos concretos que permitan ejecutar sobre el sistema.
Al momento de ejecutar se utiliza la máquina de estado como oráculo (para determinar si el resultado es válido o inválido), pues se debe verificar en cada paso si se llegó al estado esperado o no. Cada caso de prueba abstracto podrá corresponderse con uno o más casos de prueba concretos en base a los distintos datos que se seleccionen.
En este ejemplo vimos cómo podemos modelar el estado esperado del sistema con un grafo y de ahí derivar casos de prueba teniendo en cuenta los criterios de cobertura que queramos alcanzar. En el próximo artículo mostraré además cómo usar una herramienta para generar los casos de prueba.
