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!!!!!

Sobre la importancia de la camiseta

En estos días en que el mundial de fútbol está al tope de las noticias y es tema de conversación aún entre los no futboleros, solemos darnos cuenta del valor de los buenos equipos. No sólo de las figuras o estrellas con que se cuente, o de los buenos entrenadores. Y de cómo en equipo se logran victorias, que individualmente no es tan fácil o posible lograr.

Trasladando esto a los equipos de trabajo, es claro que si cada integrante “corre” hacia distinto lugar sin un objetivo común, lo que se logre será sumamente pobre.

Y esto es lamentablemente así y puede tener resultados a veces catastróficos, en los proyectos relacionados con TI, y en particular con la construcción de software. Seguramente cada uno lo habrá podido apreciar en diferentes contextos, proyectos, posiciones dentro de los equipos, posiciones dentro de las organizaciones para las que se llevan a cabo.

Si bien no siempre se requiere un equipo compacto y súper motivado, ya que hay tareas para las cuales se requiere un grupo de trabajo, por ejemplo en mantenimientos repetitivos y otras tareas más rutinarias (que no implica que sean sencillas), en un proyecto no ocurre lo mismo.

Cuando se lo requiere, hay varios aspectos de la gestión de proyectos relacionados con la gestión del equipo de proyecto, como por ejemplo:

•          Roles necesarios
•          Momentos en que debe involucrarse cada rol
•          Capacitaciones / habilidades requeridas
•          Mecanismos de incorporación y desafectación / proveedores
•          Dependencias
•          Responsabilidad / autoridad
•          Motivación
•          Incompatibilidades
•         Localización
•          Restricciones
•          Aspectos culturales y de idioma
•          …

Habitualmente nos preocupa tener a la gente adecuada y capacitada, y disponible cuando se la requiere en las diversas actividades.

Lo que no siempre miramos con igual cuidado, es lo relativo a aspectos motivacionales, buena relación y sinergia entre los miembros de todo el equipo, voluntad de cada persona para colaborar con otros y compartir sus conocimientos, ganas de “poner garra” para triunfar y llegar entre todos a lograr los objetivos del proyecto. Gente que esté “orgullosa de la camiseta”.

Pero cuidado, una gran mayoría de esos aspectos, no dependen sólo de cada persona, dependen de cómo gestionamos el equipo como responsables de hacerlo, de cómo escuchamos a la gente, atendemos sus dudas y problemas, colaboramos también al logro de sus expectativas personales, y al logro de un buen clima en el proyecto. También depende del contexto organizativo donde se desarrolla el proyecto y la cultura de cada organización participante.

Claramente, muchos podrán aducir que la mayoría de esos aspectos son muy difíciles o imposibles de manejar cuando los proyectos que actualmente se contratan se basan en menores costos, tercerización, distribución de pequeños paquetes de trabajo, desconociéndose el “todo” de los proyectos, etc.

Pero creo que cualquiera sea la forma de la contratación, es fundamental la formación del equipo, y lograr que se trabaje de la forma más satisfactoria para todos, cliente, proveedor, personas.
Y por favor, dejemos de llamar a nuestra gente recursos. Es el primer obstáculo que ponemos en el camino a construir un buen equipo de trabajo.

Hasta la próxima
Pilar

El producto de software Calidad y contexto

Está publicada la nueva versión de nuestro seminario sobre Calidad de Producto (Mayo 2014).

Allí podrán ver un caso real, una nueva línea de negocios de Mercado Libre, y la posible aplicación de distintas herramientas o prácticas, todas conocidas (Kano, mapas de empatía) pero no necesariamente utilizadas en nuestros desarrollos.   

En el tipo de desarrollo que se presenta, además de los requerimientos “debe estar” utilizando la terminología del modelo Kano, aparece la necesidad de buscar aquello que “diferencien” al negocio del  resto de la competencia.

También se ve la identificación de diversos interesados, dado que todos ellos evaluarán la calidad del producto desde su punto de vista.

La presentación plantea a lo largo de su desarrollo la necesidad de ver a la calidad no como un conjunto de herramientas y prácticas aisladas y sumadas, sino como una composición donde los aspectos: Producto y sus características, Interesado y sus expectativas, Organización y su visión de la calidad y la Cultura de la organización que tratamos, colaboran a potenciar la satisfacción del cliente y el valor para su negocio.

Al final de la presentación hay una serie de preguntas que creemos es interesante tratar de responderse y que entendemos son las dudas que habitualmente se tienen al encarar el tema calidad.

Esta presentación fue actualizada en setiembre 2014, ver http://www.slideshare.net/rmartinez582/el-producto-de-software-negocio-calidad-y-contexto 

Saludos,

Raúl

Twitter: @RaulMartinez582