¿Más es mejor?

Anteriormente comenté sobre cómo pensar qué probar. Seguramente, la mayoría dirá que basándonos en el conocimiento (cuanto mayor mejor) del dominio y el producto, riesgos y amenazas, especificaciones disponibles de todo tipo, además de nuestra experiencia.

Con los objetivos de:

- Cuestionar y evaluar el producto.

- Focalizar los riesgos, entender y gestionar los cambios.

En muchas ocasiones, en los emprendimientos de pruebas, los testers nos encontramos ante la solicitud de entregar los casos de prueba preparados, o mostrar alguna evidencia de los mismos.

Lamentablemente, en algunas ocasiones, quienes lo solicitan no necesariamente tienen en claro qué significa planificar una prueba, por lo que puede existir la idea de que a más casos de prueba mostremos y ejecutemos, mejor será la prueba.

Pero sabemos que la prueba completa no es posible, como tampoco lo es un producto con cero defectos, por lo que aparecen importantes disyuntivas cuando pensamos nuestra estrategia de pruebas, el alcance de las mismas, y fundamentalmente cómo lograr el cumplimiento de los objetivos específicos, dentro de las restricciones existentes de calendario y recursos.

Una vez hayamos consensuado el alcance deseable y posible, cuando encaremos el diseño de las pruebas, tengamos o no que detallar los casos de prueba, la siguiente disyuntiva aparecerá continuamente durante el diseño: ¿Cuántos casos de prueba necesitamos?, ¿Hay una cantidad óptima? ¿Cuál es? ¿A más casos de prueba, mayor cobertura?

Algunas respuestas

Ha habido diversas investigaciones y se han elaborado modelos matemáticos para analizar la cantidad óptima de casos de prueba [1], o sobre la relación entre cantidad de casos de prueba ejecutados y cobertura de código lograda [2], o para elaborar métricas [3]. Valgan esos pocos ejemplos. Incluso se trabaja y ha trabajado en la generación automática de casos de prueba en base a heurística, ejemplo [4].
Pero algunas investigaciones proveen resultados sólo aplicables a casos puntuales, no fácilmente generalizables, o bien los resultados obtenidos muestran que la hipótesis planteada no es válida, o requieren un nivel muy detallado de análisis y mediciones, no siempre viable en el día a día.

Por lo tanto, volvamos al análisis que habitualmente hacemos los testers, sobre la información disponible, a partir de experiencia y técnicas.

Para pruebas de caja negra, las combinaciones posibles de comportamiento y datos que podemos calcular para un requerimiento expresado en casos de uso, se dan en función de las cantidades de casos de uso y sus pasos, las interfaces gráficas y las estructuras de datos relacionadas:

Cantidad de combinaciones = {#casos uso x #pasos x #reglas} +
+ {#pantallas x #objetos x #estados} + {#tablas x #tuplas x #instancias}

Si debemos probar las interfaces entre aplicaciones y/o servicios (lo que se suele llamar pruebas de caja gris), se agregan:

         Cantidad de combinaciones = {#interfaces x #parámetros x #valores}

        

Claramente, estas cantidades pueden ser sumamente grandes, aún sin pensar en agregar pruebas de caja blanca. Tanto la especificación como la ejecución de esas cantidades de casos, es prácticamente imposible aún con herramientas de automatización, y sin duda innecesaria, ya que muchos casos son redundantes.

De ahí la necesidad de:

•          Entender nuestro objetivo respecto a tipos y niveles de pruebas a efectuar.
•          Entender qué restricciones existen (fundamentalmente tiempos, recursos, ambientes).
•          Entender cuáles son las condiciones de aceptación y las funcionalidades críticas para los interesados y usuarios.
•          Entender cuáles son los principales riesgos a mitigar (producto, proyecto, contexto): a mayores riesgos, se impondrán pruebas más profundas o exigentes.
•          Diferenciar la funcionalidad según su prioridad, criticidad y complejidad, y su relación con los riesgos a mitigar.
•          Aplicar las técnicas de diseño que permitan acotar las cantidades de casos de prueba para acercarlas a los mínimos necesarios + otras variaciones de interés, según la exigencia que se requiera o sea posible imponer.

Casos de prueba vs exigencia de las pruebas – Pruebas de integración

Primer nivel de exigencia: riesgo y complejidad bajos

Preparamos casos de prueba en base a los casos de uso o funciones de bajo riesgo para:

1. Ejecutar al menos una vez cada acción de un curso normal o función;
2. Ejecutar cero (si aplica), una y más veces cada acción iterable de un curso normal o función;
3. Ejecutar al menos una vez cada curso alternativo del caso de uso o función;
4. Producir al menos una vez cada posible excepción.

Segundo nivel de exigencia: riesgo y/o complejidad medios

Preparamos casos de prueba en base a los casos de uso o funciones que consideremos de riesgo y/o complejidad media, para:

Ídem primer nivel más:

5. Introducir valores límite para cada dato ingresado en cada interacción de interés (técnica de diseño de casos basada en valores límite).
6. Ejercitar al menos una vez el comportamiento asociado a cada clase de equivalencia de interés (técnica de diseño de casos basada en particiones de equivalencia).
   
   

Casos de prueba vs exigencia de las pruebas – Pruebas de sistema

Tercer nivel de exigencia: riesgo y/o complejidad altos

Preparamos también casos de prueba en base a los casos de uso que consideremos de riesgo y/o complejidad altos y para condiciones o entradas no esperadas, tratando de cubrir los casos de uso especificados y escenarios de interés, y todo tipo de requerimientos, en función al alcance de la prueba planificado: técnicos, UI, funcionales, no funcionales, otros (accesibilidad, recuperación,…):

Ídem segundo nivel más:

7. Ejercitar al menos una vez la ocurrencia de cada regla para combinaciones complejas de condiciones (variables o clases de equivalencia de entrada) y acciones aplicables (salidas o porciones de proceso) (técnica de diseño de casos basada en tablas de decisión).
8. Ejercitar al menos una vez cada combinación estado-transición posible para las entidades que puedan modelarse con ciclos de vida basados en estados y cambios de estado (técnica de diseño basada en estado-transición).
9. Ejercitar otras relaciones causa-efecto de interés: listas vacías, primer o último elementos corruptos, parámetros faltantes en interfaces, valores nulos, expiración de sesión por diversas causas, etc.

Cuarto nivel de exigencia: Escenarios de uso

Ejercitar el producto tanto desde el punto de vista de las secuencias “técnicas” de utilización por parte de sus usuarios (no se puede modificar o dar de baja un registro que no se dio de alta; qué ocurre durante la navegación al dar back a una página durante una transacción, situaciones inesperadas, etc.), como de las secuencias “procedurales” que llevan a lograr objetivos (qué quiere obtener o lograr el usuario al utilizar una determinada funcionalidad).

1. Ejercitar las secuencias exitosas de funcionalidades o casos de prueba que reproducen diversas formas en que los usuarios harán uso habitual de las funcionalidades del producto. Por ejemplo, para hacer una compra en un sitio de comercio electrónico, tendrán que recorrer un catálogo de productos on-line, seleccionar, completar datos requeridos en el carrito de compra, efectuar la compra y pagarla exitosamente.
   
2. Ídem anterior para secuencias no exitosas. Por ejemplo, iniciar una compra cuyo pago es rechazado.
   
3.  Ejercitar posibles alternativas de interés. Por ejemplo, iniciar una compra y cancelarla en algún punto, habiendo o no ingresado los datos para su pago.
   
4. Ejercitar situaciones inesperadas o de stress de interés. Por ejemplo, caída de un enlace de comunicaciones durante el pago, servidor no disponible, etc.

Para tener en cuenta

·         La cantidad de casos de prueba o de casos ejecutados por unidad de tiempo no es significativa si se desconoce el contexto al que aplican.

·         Su calidad es más importante que su cantidad: La eficacia de los casos de prueba (ayudan a detectar defectos importantes) y su eficiencia (se ejecutan utilizando pocos recursos y permiten aislar rápidamente los defectos).

Nuestra mejor recomendación sigue siendo: Riesgos, triage de ideas sobre qué probar, y sentido común!!!!!

…… Continuará……
en próximas entregas, más datos sobre los datos
y sobre las técnicas de diseño de casos específicas
J

Hasta la próxima
Pilar

Ejemplos referenciados:

[1] OPTIMAL TEST CASE SELECTION FOR MULTI-COMPONENT SOFTWARE SYSTEM - Praveen Babu Kysetti, 2004

[2] Assessing the Relation Between Quantity of Test Cases and Amount of Code Coverage - Anju Bansal, 2014

[3] Measuring the Effectiveness of a Test - Harry M. Sneed, 2004
[4] Generación automática de casos de prueba mediante búsqueda dispersa – Blanco, Díaz, Tuya, 2006