Nos encontramos con una aplicación donde las pruebas son una cadena consecutiva de pasos. como toda cadena, todo eslabón debe estar intacto, de lo contrario se pierde la naturaleza como tal de la cadena.

Probar cada paso representa una carga de trabajo considerable en horas/hombre. Entonces, surge la idea de distribuir el trabajo entre varios de los testers. Pero el problema no se resuelve, ya que “apriori” el tester B debe esperar (o duplicar trabajo) a que el tester A termine sus pruebas (entiéndase que A probará el eslabón de la cadena inmediatamente anterior al eslabón que B probará). Sólo un dato más: Hay que hacer un montaje (creación de datos de pruebas en las BBDD) previo al inicio de las pruebas.

Se me ocurren las siguientes opciones:

1. Distribuir la tarea del montaje en la BBDD abarcando todas las casuísticas posibles
2. Tester A puede comenzar sus pruebas del primer eslabón, entrando a consultar y distinguir pormenores
3. Tester A debe dar el OK de un pre-testing de A finalizado y correcto (generación rápida y sin problemas en la estabilidad del eslabón primero)
4. Tester B comienza las pruebas del siguiente eslabón considerando que el o los eslabones anteriores son para él como una “black box”.
5. Tester B debe identificar posibles problemas cuya causa sean de montaje o de output de los procesos ejecutados en la caja negra.
6. Tester A debe identificar posibles complicaciones y nuevas consideraciones de pruebas a transmitir al tester B.
7. Tester X debe considerar toda la cadena como “black box”, con lo cual, lo que le importa es una entrada (montaje) y una salida (pantallas/reportes/documentos/etc.)

Alguna sugerencia o corrección?

Saludos,
Juan Carlos Peláez

Los casos de prueba (Tets Cases) se han utilizado tradicionalmente para probar cualquier sistema software o de cualquier otra cosa. El caso de prueba se puede transformar en una lista de comprobación, unas pautas paso a paso, fáciles de entender, que muestran la información mostrada por el sistema, o lo que se conoce como un escenario de la caja negra (Black Box Testing). En todo caso, un caso de prueba es una representación pura de lo que debe y no debe hacer el sistema.

Lo ideal es que nuestros casos de prueba, o test cases, estén basados en los requisitos especificados por el cliente o la persona que realiza la aplicación. Estos requisitos o especificaciones son escritos en un documento que se le suele conocer como Documento de Requisitos Funcionales o de Especificaciones Funcionales. Este documento especifica de una forma clara y concisa cómo el usuario quisiera que fuera el sistema o cómo él percibe que debería de ser. Las reglas de negocio se pueden también documentar como parte de este documento.

Mucha gente puede discutir que sería más fácil probar directamente desde el documento de especificaciones en vez de crear un documento aparte de caso de prueba, puesto que la base de un caso de la prueba son las especificación funcionales o requisitos. Pero esto puede conllevar muchos riesgos, que a la larga hacen que el trabajo sea más laborioso y se dupliquen los esfuerzos del equipo de QA.

Las especificaciones funcionales son la base de los casos de prueba (Test Cases) conjuntamente con los Diagramas de Flujo (Use cases), las reglas de negocio y algunas otras condiciones especiales.

¿Como podemos entonces definir formalmente un caso de prueba? Un Caso de prueba es un conjunto específico de datos de entrada y de procedimientos asociados, desarrollados para probar un caso determinado (secuencia/camino particular, verificación de un requisito, etc).

Los casos de prueba deben ser documentados y archivados. Existen en el mercado gran multitud de herramientas que permiten gestionar un entorno de pruebas, asociando Requisitos con Use Case y Test Cases. Herramientas tales como el SilkPlan o el Test Director están disponibles en el mercado. Este tipo de herramientas son bastante caras, un forma más barata de controlar tus casos de prueba es usar el Visual Source Safe de Microsoft que es más asequible aunque no es realmente una herramienta pensada para gestionar un entorno de pruebas sino más bien es un controlador de versiones, pero nos puede servir, así como SubVersion, incluso mejor en algunos aspectos que SourceSafe, y además OpenSource.

Pero, ¿cómo debemos escribir nuestros casos de prueba? Hay diferentes maneras de escribirlos y todas pueden ser perfectamente válidas pero debemos de tener en cuenta que un caso de prueba se deben siempre definir los pasos a seguir, definir el resultado esperado, comprobar si no hace lo que debe o hace lo que no debe (casos positivos y negativos) y tanto entras inválidas como entradas válidas. De esto modo reduciremos la probabilidad de la existencia de nuevos errores en una sección de la aplicación.


Diseño de casos de prueba
Cualquier producto de ingeniería puede probarse de dos formas:
• Conociendo la función específica para la que fue diseñado (pruebas de funcionalidad) (Pruebas de caja negra)
• Conociendo el funcionamiento del producto (pruebas de la operación interna a bajo nivel) (Pruebas de caja blanca)

En software, las pruebas de caja negra son las que se llevan a cabo sobre la interfaz del software, examinando aspectos del modelo fundamental del sistema (funcionalidad operativa, aceptación de entradas, resultados, etc), mientras que las pruebas de caja blanca se basan en el estudio minucioso de detalles procedurales. A primera vista, una prueba de caja blanca nos llevaría a un programa 100% correcto, un software sin fallos, pero nos encontramos con el problema de las pruebas completas (o exhaustivas). No podemos generar casos de prueba para todos los caminos lógicos (secuencias de ejecución).

¿Qué solución tenemos? ¿Utilizarlo sólo para generar los casos de prueba más significativos (caminos o estructuras de datos más importantes)?. Dependiendo del tipo de software a probar, hay diferentes técnicas de hacer white box testing, la más comunes son mediante el uso de herramientas o scripts.

Pruebas de Caja Blanca
¿Por qué utilizar pruebas de caja blanca? Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa. A menudo creemos que un camino lógico tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar de forma regular. Los errores tipográficos son aleatorios. Una de las técnicas que describiremos en próximos artículos es el Testeo Estructural, selección adecuada de caminos, definiendo “Camino” como la secuencia de sentencias encadenadas desde la sentencia inicial del programa hasta su sentencia final.

Puede parecer ilógico, pero tenemos que tener siempre en cuenta que no se pueden probar todos los caminos. Es por ello que debemos de usar un criterios de selección ó lo que alguna gente le gusta llamar un criterio de cobertura. Algunos tipos de cobertura:

Cobertura de sentencias
Escribir los casos suficientes para que cada sentencia en el programa se ejecute al menos una vez.

Cobertura de decisión o de ramificación
Escribir casos suficientes para que cada decisión, por lo menos una vez, tenga un resultado verdadero y uno falso.

Cobertura de condición
Escribir el suficiente número de casos para que cada condición de toda decisión tenga todos los resultados posibles.

En próximos artículos entraremos más en detalle de cómo obtener casos de prueba de caja blanca (White Box Testing), como por ejemplo pruebas de condición, pruebas de bucles o pruebas de flujos de datos.

Pruebas de Caja Negra
Como habíamos dicho al comienzo del artículo, las pruebas de caja negra verifican las funcionalidad, a alto nivel, de nuestra aplicación. Por tanto podemos comenzar a diseñar nuestras pruebas de caja negra en cuanto se especifiquen los requisitos de la aplicación.

Cada vez que se recibe una nueva versión del programa (Deploy ó Release), comprobamos cuándo es suficientemente estable para la batería de pruebas. Estás pruebas son conocidas como pruebas de aceptación (Acceptance Test) ó pruebas de calificación (Qualification Test). En este punto podríamos introducir un nuevo concepto, la priorización de nuestras pruebas. Debemos de saber identificar en que áreas del programa se va a confiar. Si el programa parece débil en un área, se probará más duramente y se planificará un mayor tiempo.