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.
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}
+ {#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:
- Ejecutar al menos
una vez cada acción de un curso normal o función;
- Ejecutar cero (si
aplica), una y más veces cada acción iterable de un curso normal o función;
- Ejecutar al menos
una vez cada curso alternativo del caso de uso o función;
- 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:
- 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).
- 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:
- 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).
- 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).
- 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).
- 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.
- Ídem
anterior para secuencias no exitosas. Por ejemplo, iniciar una compra cuyo pago
es rechazado.
- 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.
- 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
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
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
[4] Generación automática de casos de prueba mediante búsqueda dispersa – Blanco, Díaz, Tuya, 2006
