Preparación y Gestión de Datos de Prueba

Si bien es cierto pareciera tan común, no siempre recibe el foco adecuado de entre la lista de tareas predefinidas en el plan de pruebas. Por lo general, creemos que llegada la fase de ejecución de pruebas, se nos podrán ocurrir datos lo suficientemente útiles para ejecutar nuestros casos de prueba sin mayor problema; sin embargo, lo “suficientemente útiles” se queda corto cuando se tiene la expectativa de detectar esos defectos que han sido inyectados desde etapas tempranas del desarrollo del software; de modo que, más bien debiéramos buscar preparar datos lo “suficientemente correctos” para cada prueba, de manera que alcancemos una mayor eficiencia en nuestros ciclos de ejecución.

Test Data Management es el proceso de crear/preparar y utilizar adecuadamente datos de prueba “realistas” para propósitos distintos de los de producción; por ejemplo, para su uso por áreas de Desarrollo, Testing, Capacitación, etcétera (ver Figura 1). Y como Datos de Prueba podemos considerar todas aquellas entradas con las que es alimentado el sistema para ser operado en períodos de evaluación, ya sea que se introduzcan como datos directamente alimentados desde la interfaz de usuario, desde archivos precargados en distintos formatos (xml, .jpeg, etc.), registros tomados desde las tablas de la base de datos, archivos de configuración, archivos de datos generados por el mismo sistema que servirán de entrada para algún otro proceso, así como también datos que ya deben existir en el sistema para que dichos casos de prueba puedan realmente ejecutarse.

Figura 1. Subconjuntos de datos de pruebas para distintos propósitos.

¿En qué tipos y/o niveles de pruebas de software conviene dedicar como tarea específica la de Data Preparation?

• Pruebas funcionales manuales
• Pruebas funcionales automatizadas
• Pruebas de performance
• Pruebas de seguridad
• Pruebas para aplicaciones web, de escritorio, móviles, etc.
• Pruebas a nivel unitario, de sistema, de integración de sistemas, a nivel de aceptación de usuarios, etc.

Existen muchos problemas que se pueden evitar si realizamos una adecuada preparación de datos de prueba, algunos de ellos son:

• Detener o retrasar la etapa de ejecución de pruebas debido a datos inadecuados o insuficientes.
• Cobertura incompleta en el proyecto de pruebas.
• Reportar defectos inválidos a causa de una incorrecta configuración/preparación de datos (errores humanos).
• Dejar de detectar defectos potencialmente graves, importantes y/o urgentes.
• Existencia de datos ya procesados (y no administrados correctamente) en fases de prueba previas, que dificultan o entorpecen la ejecución actual.
• Manejo inadecuado de datos de producción que pudieran propiciar problemas legales (privacidad, seguridad).

En prácticamente todos los casos, es importante cuidar la integridad referencial de la información manejada, dadas las relaciones de ciertos registros que se requiere sean utilizados en diversos módulos de la aplicación a probar. Por ejemplo, si queremos probar un escenario que implica validar las reglas de negocio para determinar los
cargos automáticos mensuales que se aplicarán a aquellos clientes de un banco que han solicitado un crédito de auto, es preciso emplear datos de prueba tales que a su vez estén relacionados a otros datos de prueba previamente registrados desde otros escenarios, de modo que dicho cliente exista, tenga asociada una cuenta, esté activo, tenga saldo disponible para aplicarle el cargo, etc.

Como podemos ahora imaginar, hay situaciones en las que la preparación de datos puede resultar una tarea sencilla, más habrá muchos otros casos en los cuales dicha actividad se convierte en todo un reto, dado que,
no sólo el volumen de datos sino la criticidad de la información a manejar para las pruebas, son de gran peso, tratándose de aplicaciones grandes (que manejan datos complejos y a gran escala) y cuya fuente pudiera requerir
ser una “copia” de datos de producción. Copia de la cual se requerirá enmascarar ciertos
datos/valores a fin de no incurrir en problemas de seguridad o faltas a la privacidad.

Para casos como éste último, donde la preparación manual de datos resultaría ineficiente, existen herramientas especializadas en manejo de datos de prueba, que de alguna manera presentan ciertas ventajas significativas:

• Optimizar/agilizar esfuerzos de Testing.
• Manejar distintas versiones de datos.
• Parametrizar y enmascarar datos para evitar su uso inadecuado en las pruebas.
• Generan de forma escalable sub-conjuntos de datos de BDs acorde a las necesidades.
• Permiten la extracción de un subconjunto de datos de pruebas desde varias tablas de diversas BD’s e incluso desde diversos DBMS’s (Oracle, DB2, SQL server, Informix, etc.).
• Cargan grandes volúmenes de datos de ambientes pre-producción o producción con relativa facilidad.
• Proveen de características y habilidades para “refrescar” los datos de prueba de manera eficiente y confiable.
• Facilidad para editar los datos y forzar condiciones de error.

Por otro lado, en lo que respecta a la preparación manual de datos de prueba, dada la limitación de espacio, abordaremos a continuación sólo la técnica de Clases de equivalencia o Particiones de Equivalencia, la cual se recomienda utilizar al momento de diseñar y ejecutar casos de prueba:

• Es una estrategia de pruebas de Caja Negra, empleada para reducir metódicamente la cantidad enorme (infinita) de casos de prueba posibles, a un conjunto más pequeño, pero con una efectividad equivalente.
• Una clase de equivalencia o partición de equivalencia, es un conjunto de casos de prueba con cuyos valores o datos de entrada se prueba lo mismo; es decir, el empleo de cualquier dato perteneciente a dicha clase, revela el mismo error, reduciendo así la cantidad posible de casos de prueba a diseñar/ejecutar.
• La razón de que bajo esta técnica se requiere probar sólo con un dato representativo de cada partición o clase, es porque asumimos que con cualquiera de los datos de prueba de dicho subconjunto que utilicemos,
  obtendremos los mismos resultados. De igual manera ocurrirá cuando se evidencie una falla.

¿Cómo utilizar las clases de equivalencia para la definición y preparación tanto de los casos de prueba, como de los datos de prueba que en éstos deberemos emplear?

1. Identificar las Clases de equivalencia. Identificar todas las clases, identificar/clasificar las clases válidas e inválidas, rango de valores válidos.
2. Identificar los casos de prueba: Diseñar casos de prueba hasta cubrir todas las clases válidas. Diseñar casos de prueba que cubran clases inválidas (En función de los recursos).

Ejemplo: Ver Tabla 1.

Tabla 1. Ejemplo de identificación de clases de equivalencia.

El ejemplo anterior, aunque simple, refleja cómo a partir de ciertos campos de entrada, como aquí el contenido de Calif (Calificación), pueden desprenderse diversas combinaciones de pruebas, dada la variedad de clases de equivalencia que podrían surgir, si la regla de negocio estipula que se realizarán ciertas acciones si dicho dato de entrada está entre 0 y 10, o si está específicamente entre 6 y 7, o bien entre 8 y 10, o completamente fuera de dicho rango (ya sea hacia arriba o hacia abajo).

La tarea de identificación de clases de equivalencia (válidas e inválidas) se vuelve más interesante cuando intervienen diversas entradas, para las cuales se contemplarían datos de prueba diversos, relacionados entre sí, pues ello generará un mayor número de combinaciones.

La calidad de los datos de prueba, impacta directamente en la calidad de los resultados del proyecto de Testing, razón por la que bien vale la pena dedicar un esfuerzo especial, e incluso a veces un equipo especial para poder replicar las condiciones adecuadas que permitan cubrir los requerimientos de datos de prueba especificados en los escenarios y/o datos de prueba diseñados para evaluar nuestras aplicaciones. Otra buena razón, es que los testers mostrarán mayor productividad en las etapas de ejecución, en la medida que sea más eficiente el proceso
de creación, mantenimiento y gestión de sus datos de pruebas.