Derivando Casos de Prueba a partir de Casos de

Uso
En este post queremos mostrar (sin entrar en gran detalle) en la tcnica
de derivacin de casos de prueba a partir de casos de uso. Antes que
dejen de leer queremos aclarar que no es necesario tener los casos de
uso descritos formalmente para aplicar la tcnica. Dicho esto, veamos
de qu se trata, y veremos que ser muy til en casi cualquier
contexto...
Los casos de uso son un elemento de anlisis muy conocido para
documentar una interaccin tpica entre el usuario y el sistema. Ganaron
su popularidad seguramente con UML y los diagramas de Casos de Uso.
Ahora, estos diagramas UML simplemente muestran los actores
involucrados en cada caso de uso (mostrando qu tipo de actor o
usuario puede ejecutar cada caso de uso o funcionalidad), y la relacin
entre un caso de uso y otro (relaciones de dependencia o inclusin).

En esta tcnica no utilizaremos ese tipo de diagramas sino las

descripciones de los casos de uso, lo que nos indica cul es la
interaccin esperada entre el usuario y el sistema para realizar
determinada accin o lograr determinado cometido. Por este motivo de
estar disponible es una fuente interesantsima para utilizarla como

input para disear pruebas.

Lo que ocurre muchas veces es que no se cuenta con las
formalizaciones de los casos de uso. Estos quiz estn en la cabeza
de distintas personas que ocupan distintos roles (desarrolladores,
usuarios, etc.). El equipo de testing muchas veces termina aportando en
la formalizacin de la documentacin, para poder luego validar los
documentos, y utilizarlos como el input principal para el diseo del
orculo de pruebas.
Los casos de uso se representan en lenguaje natural, pero generalmente
se intenta seguir cierta estructura, indicando el flujo de interaccin como
pasos numerados. Generalmente se comienza describiendo el flujo
principal, y luego se enriquece describiendo cada uno de los posibles
flujos alternativos y excepciones.
Cada caso de uso cuenta con una serie de pre-condiciones y postcondiciones que deben cumplirse antes y luego de la ejecucin del
mismo respectivamente. Se suele definir tambin un objetivo o
descripcin asociado al caso de uso, indicando qu es lo que buscar el
usuario al ejecutar ese caso de uso.

Para aplicar la tcnica de generacin de casos de prueba a partir de

casos de uso, lo primero ser pasar a otra representacin, en forma de
grafo, para poder desde ah visualizar ms fcilmente los distintos flujos
que se pueden seguir y seleccionarlos como casos de prueba.

Nosotros les vamos a sugerir aqu una representacin intermedia que es

mucho ms completa y permitir validar ideas con mayor detalle. La
idea principal al pasar a una representacin grfica es abstraerse de la
letra, representarlo como un grafo dirigido que muestre fcilmente
cules son los flujos del sistema. Esto muestra que esta tcnica en
realidad es extrapolable casi que para cualquier especificacin del
sistema que podamos trasladar a esta representacin, no
exclusivamente a casos de uso representados en el formato tabular
mostrado anteriormente. Incluso, podramos comenzar preguntando a
un usuario o experto del sistema y construir directamente el grafo, y es
por esto que afirmamos que esta tcnica es aplicable incluso si
no se cuenta con la especificacin en casos de uso.
Vamos a utilizar para esto un diagrama de actividad, donde quedarn
representados los distintos flujos del caso de uso. Al observar la
siguiente figura se puede ver que al representar el caso de uso como un
diagrama de actividad todos los flujos pueden ser representados en
forma concisa y unificada, y al intentar representarlo de este modo, es
necesario refinar mucho ms en detalles que son muy tiles para su
anlisis.

Con una representacin de este estilo, y segn con el tiempo con el que
se cuente para probar, podremos decidir qu flujos queremos probar.
Supongo que estamos todos de acuerdo en que esta representacin es
mucho ms fcil de visualizar y analizar que la representacin textual.
Bsicamente, para derivar los casos de prueba vamos a recorrer desde
el nodo inicial a cada uno de los nodos finales, pasando por cada una de
las transiciones del modelo. En el caso que existan bucles se deber
decidir si es suficiente con visitar una sola vez el bucle, o si vale la pena
recorrerlo varias veces, y en ese caso cuntas. Una vez que tenemos los
flujos vamos a analizar qu datos utilizar para cada uno.

Para definir los datos de prueba combinaremos con otras tcnicas

conocidas, como por ejemplo usando particin en clases de
equivalencia, valores lmites, combinacin por pares, etc., una vez que
hayamos reconocido las variables en juego.
Aqu hay algo particular a considerar: ciertos flujos se asocian con
ciertas clases de equivalencia de algunas variables. O sea, solo
podremos seleccionar algunas clases de equivalencia para algunos
flujos. De hecho, hay algunas variables que ni siquiera estn en juego
para ciertos flujos, como el usuario y password para el caso en que se

indica que se quiere recordar el password. El flujo del caso de prueba

indica que no son entradas que cambien el comportamiento de ese caso,
con lo cual no son variables para este caso, por lo tanto no tiene sentido
disear valores de prueba para las variables usuario y password para
ese caso en particular.
Lo que se suele hacer en este punto es entonces definir cules son las
variables para cada flujo, y cules son las clases de equivalencia a
considerar, y de esa forma luego vamos a poder determinar valores de
prueba para ellos.
Ahora, una vez generados los casos de prueba, no significa que vamos a
querer ejecutar todos los casos de prueba con todas sus combinaciones
de datos y para cada caso de uso del sistema. Esta es la tcnica que nos
da la cobertura de casos de uso, luego est en nosotros seleccionar lo
que ejecutamos/automatizamos de acuerdo a los recursos y la
importancia que le damos a cada valor de cada variable y a cada caso
de uso.
Cmo seleccionarlas? Pues teniendo en cuenta lo que antes dijimos, y
de esa forma priorizando:

Primero seleccionando los casos de uso ms importantes

Para cada caso de uso, cules son los flujos ms importantes

Para cada flujo, ver qu datos son los ms importantes a utilizar

Cuando digo importante hablo de testing basado en riesgos,

considerando relevancia, lo ms usado, lo que ms costos o impacto
negativo genera en el caso de no funcionar, lo que est ms verde (o
menos probado, y seguramente con ms probabilidades de que tenga
errores), etc.