“Secretos”  detrás del éxito

 Esta presentación explora algunos de los “secretos”  que hay detrás del éxito de ciertos  productos de software y/o servicios para comprender si con acciones similares, podremos tener éxito con nuestros productos y servicios.

Cuando nos proponemos crear un producto de calidad, de alto impacto y exitoso para nuestro negocio, siendo nosotros:

Un emprendedor o

Alguien que desarrolla en forma interna o para terceros

en algunos casos nos preocupa el proceso que seguimos, los defectos que encontramos, o bien el aspecto de usabilidad del  producto, estética y cantidad de funciones que provee.

Sin embargo nada de esto parece alcanzar,

¿Por qué?

¿Faltó ingeniería?

¿Faltó organización?

¿Fue útil al negocio?

A menos que veamos todo como una unidad difícilmente alcanzaremos el éxito.

De todo esto trata esta presentación.

Las propuestas son prácticas, y surgen después de haber visto, discutido y expuesto todos estos temas en los últimos años con los responsables de este caso y otros casos, no siempre exitosos, en otras empresas.

Esperamos debatan y compartan estas conclusiones.

La presentación se puede encontrar aquí:

Seminario de Calidad de producto



Saludos,
Raúl
@RaulMartinez582

¿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

Pensando qué probar

Anteriormente comenté sobre nuestra misión como testers. Entre las cosas que tenemos que hacer, obviamente unas muy importantes son:

- Cuestionar y evaluar el producto.

- Focalizar los riesgos, entender y gestionar los cambios.

Y pensando en cómo cuestionar y evaluar el producto, hay mucho que podemos leer, discutir, hacer o dejar de hacer, en relación a planificación, diseño, exploración, preparación de condiciones y casos de prueba, no preparación, no diseño, etc. 

Sabemos que hay muchas opiniones y criterios a este respecto, y diferentes “escuelas” o tendencias, pero, en definitiva, escribamos o no las condiciones y casos de prueba, las escribamos a un gran nivel de detalle o no, lo primero que aparece es la necesidad de entender en qué consiste el producto que tenemos que cuestionar y evaluar, y cómo focalizamos los riesgos que hayamos identificado en el marco de nuestra misión.

O sea, tanto cuando nos sentemos a explorar un producto, como cuando nos sentemos a diseñar condiciones y casos de prueba formalmente, tendremos que seguir algún orden o lineamiento para encarar estas actividades.

Algunos lineamientos

Algunos  obvios y probablemente explicitados, otros no tan obvios, o no tan fácilmente identificables, y en muchos casos no cuantificados (los números no implican orden):

1.    Requerimientos que el producto tiene que satisfacer: lo que dice “la caja”, los manuales o las especificaciones funcionales, otros requerimientos regulatorios o normativos.

2.    Usos típicos que el producto va a tener: lo que los usuarios tienen que poder hacer, en los distintos escenarios posibles; interacciones con procesos manuales, interacciones con otros sistemas.

3.    Atributos de calidad establecidos para el producto, muchos relacionados con requerimientos no funcionales, por ejemplo, los caracterizados por las normas ISO de calidad de producto (Norma IRAM ISO IEC 14598, la serie ISO 9126, y la norma ISO 25000 actualmente en desarrollo), o simplemente, las restricciones que puede imponer un pedido de usuario en relación a una arquitectura técnica. Entre otros, performance, usabilidad, mantenibilidad, escalabilidad.

4.    Posibles fallas, o cómo imaginamos, en base a experiencia, características del producto, arquitectura, catálogos de fallas conocidos, etc., que el producto puede fallar. Si bien esto es base de la técnica Risk Based Testing – RBT, implica, a nuestro criterio, más que una simple técnica: debe ser central a nuestras políticas y estrategias de prueba.

Qué nos sirve de base para pensar más allá de la especificación

1.    El requerimiento.
Si no está escrito, cuál podemos imaginar o relevar que es, desde el punto de vista del negocio.

2.    El contexto.
Qué parte de una función de negocio estamos viendo, en qué casos se utilizará, por qué tipo de usuario.

3.    Interfaces posibles.
Con otros sistemas, con otras transacciones, con otros aspectos del negocio, dentro o no del sistema que estamos probando.

 Cómo analizamos la especificación

• Pensándola como Caso de Uso (aunque no esté expresada así):

a.    Requerimiento que contribuye a resolver.
¿El CU corresponde a un requerimiento completo o a parte de él?
¿Cuáles son las demás partes?
¿Las vemos de alguna forma?
¿Podemos graficar las interacciones?

b.   Actores.
¿Quiénes, con qué permisos, tenemos que probar expresamente seguridad
(de acceso, funcionalidad, de acceso a datos)? 
¿Cómo llega el actor a esta funcionalidad?
¿Hay varios caminos posibles?
¿De qué dependen?

c.    Precondiciones.
Qué se tiene que cumplir para entrar al curso normal del CU.
¿Qué pasa si no se cumple alguna precondición?
¿Todas son obligatorias?  Si no, ¿está claro por qué o cuándo se requiere cada una?

d.   Poscondiciones.
¿Qué se tiene que cumplir para considerar que el CU terminó bien?
¿Qué pasa si esto no ocurre?
¿Cuál debe ser el estado final si se produce algún error?  ¿Está claramente expresado?
¿Qué pasa si no se cumple alguna poscondición?
¿Todas son obligatorias? Si no, ¿está claro cuándo puede faltar cada una?

e.   Curso normal: ¿es único y bien definido?
¿Hay alternativas al curso normal que no sean por errores o cancelaciones?
¿Qué reglas de negocio aplican? ¿Fórmulas? ¿Decisiones?

f.     Cursos alternativos:
“Positivos”, transacciones exitosas pero que se apartan del curso normal; “Negativos” debido a errores, interrupciones, cancelaciones, timeouts, reglas de negocio que no se cumplen, etc.
¿Podemos identificar qué los hace ser diferentes, y cómo debe terminar cada uno? (datos opcionales, mensajes especiales de error, distinto output, etc).

• Pensándola como proceso: Entradas -> Actividades -> Salidas:

a.    Cómo se inicia el proceso, o qué interfaces de usuario intervienen, reglas que aplican, consistencias puntuales de datos, obligatoriedad, puntos de menú… .

b.   Actividades, ¿qué se hace sobre los datos o con ellos, qué más se consulta o lee o modifica, bajo qué condiciones se hace cada cosa?

c.    Qué tiene que dar como resultados el proceso (y qué no), qué vuelve al usuario y qué puede quedar oculto pero necesitamos validar (estadísticas, logs, archivos temporales, …).

Cómo decidimos qué se justifica probar: Pensando en los riesgos

Es casi una deformación profesional para los testers (o debería serlo), pensar en los riesgos para determinar qué se justifica probar.  El objetivo es siempre utilizar los (escasos) recursos de prueba, en pasar por las funcionalidades o no funcionalidades críticas y/o importantes para la aplicación y para los distintos interesados y usuarios. 
Normalmente trataremos de incluir en las pruebas, en base a dicha criticidad / riesgo, casos de prueba para estas situaciones / atributos:

• Cursos normales bajo entradas habituales (mínimas obligatorias por ejemplo)
• Cursos normales bajo entradas no tan habituales (todos los campos no obligatorios)
• Cursos alternativos, al menos uno de cada uno, importante según las reglas del negocio
• Situaciones que puedan no estar contempladas (fallas de HW o SW o aplicación en algún punto relacionado, entradas o resultados muy fuera de rangos, zapato sobre el teclado…)
• Performance, seguridad, volúmenes, si se considera necesario o surge alguna duda
• Procesos periódicos
• Interacciones típicas y/o inesperadas entre procesos que se comunican
• ...

Obviamente la lista puede ser ampliada y completada con muchísimas variaciones y enfoques, pero nuestro tiempo siempre será escaso, por lo que tendremos que recortarla en función a las necesidades de interesados, producto, proyecto, y a las herramientas disponibles.

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