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

Interés de los lectores

Distribución del interés de los lectores de nuestro blog ideassobresoftware.blogspot.com.ar, en los distintos temas a lo largo de los meses. Estos son los 10 primeros puestos en cantidad de lecturas.

Entrada	Fecha de Publicación	Tema
Calidad no es testing, ni procesos, ni certificaciones	Oct 2013	Calidad de producto y expectativas
¿Encajar una pieza cuadrada en un hueco redondo? E...	Jun 2013	Administración de proyectos
Acercarnos al Negocio (Conclusión)	Nov 2013	Calidad y negocios, el resumen
Indicadores accionables	Jun 2013	Indicadores Negocio/Producto
¿Todavía quiere seguir jugando?	Sep 2013	Complejidad de distintos escenarios
Sobre Pruebas de software y Servicios de TI	Aug 2013	Testing y servicios
Sobre nuestra misión como testers	Jul 2013	Testing
ISO 25000 y otras - Calidad en Uso	May 2013	Calidad de producto
Release or not release, that is the question!	Sep 2013	Calidad de producto y negocio
La Calidad (no?) se negocia	May 2013	Calidad de producto y negocio

Saludos,

Raúl

TW: @RaulMartinez582

Sobre Pruebas de software y Servicios de TI

Anteriormente comenté sobre nuestra misión como testers y sobre el enfoque del testing como servicio y como mitigador de riesgos. 
Entre lo que tenemos que hacer, obviamente es muy importante:

• Cuestionar y evaluar el producto que estamos probando.
• Focalizar los riesgos, entender y gestionar los cambios que ocurren en el proyecto o el contexto del negocio durante las pruebas.
• Entender qué es prioritario probar, qué funcionalidad y atributos de calidad son imprescindibles para lograr la satisfacción de usuarios y clientes, bases sin las que no se obtendrá un producto de software útil y exitoso.

También me parece interesante compartir un enfoque más amplio del tema, mirado desde el punto de vista de los Servicios de TI.

¿Pará qué está TI?

Para brindar Servicios al Negocio

Según los conceptos actuales, un servicio es un:

Donde los Servicios van mucho más allá de la infraestructura, se apoyan en ella, y deben brindar valor a las áreas del Negocio que los requieren.

¿Qué significa esto para los testers?

La mayoría de los servicios que TI provee al negocio, incluyen sistemas de información computarizados, o se brindan utilizando sistemas o productos de software, ya sean paquetes adquiridos y parametrizados / adaptados, o desarrollos a medida.  De hecho, hay servicios que no podrían existir sin un sistema informático detrás.  Por lo que, para que el cliente reciba el resultado esperado del servicio, el sistema informático tiene que funcionar “bien”, o sea, dentro de pautas de calidad establecidas y acordadas.

Las pautas de calidad del servicio tienen que ver con:

Y aquí es entonces donde debemos poner foco, en el adecuado funcionamiento de los servicios, según su utilidad y garantía. Por ejemplo:

Lo que implica que, las pautas de utilidad y garantía contra las que verifiquemos y validemos las aplicaciones, tienen que contribuir a la calidad del servicio, y provenir de su definición (las mostradas no son las únicas posibles).

¿Cómo se construye un servicio?

Las actividades que conocemos como formando parte del ciclo de vida de la construcción de software, están realmente insertas en el ciclo de vida de construcción del servicio, al igual que deben estarlo nuestras actividades de verificación y validación en cada proyecto o cambio que lo afecte, actividades que deberán permitir diagnosticar acerca de la utilidad y la garantía:

En este sentido, nuestros oráculos de utilidad y garantía, sin duda tienen que estar en línea con, y originarse en, los requerimientos de utilidad y garantía del servicio.

En otras palabras, las aplicaciones que contribuyen a la arquitectura del servicio, tienen que tener funcionalidad y atributos de calidad tales, que el servicio pueda proveer la utilidad y garantía acordada con el cliente y requerida por los usuarios.

Durante la vida útil del servicio, la aplicación de software sufrirá cambios, consecuencia de los cambios solicitados al servicio, que deberemos evaluar, probar e implementar oportunamente, y que operará en un contexto en que tendremos que saber cómo gestionar los incidentes y problemas (del servicio y de la aplicación),  y ejecutar proactivamente mejoras y nuevos proyectos que contribuyan a que el servicio comprometido no se degrade, y siga brindando valor al negocio.

Algunas conclusiones posibles

Creo que esta visión “macro” del servicio, y las buenas prácticas de la industria (ITIL u otros modelos) o los estándares internacionales relacionados (ISO 20000 y otros como ISO 25000), son fundamentales para entender nuestro trabajo de testers y colocarlo en el marco adecuado.

Según nuestra misión (por ejemplo hacer pruebas durante la construcción, pruebas de homologación, o colaborar en pruebas de aceptación de usuarios), estaremos trabajando en un nivel distinto del clásico Modelo V de prueba, y nuestras actividades estarán más focalizadas en la prueba de una aplicación particular, o en la prueba conjunta de las aplicaciones que aportan al servicio completo. 

Lo importante es que podamos entender esa misión, y comprender lo que implica respecto a las pruebas a ejecutar.

La visión del Servicio de TI al negocio también debe darnos ideas respecto a:

·         dónde buscar los requerimientos a testear

·         cómo obtener la cuantificación de los requerimientos de calidad a evaluar

·         cómo gestionar ambientes, configuración, versiones

·         cómo liberar software

·         cómo atender incidentes

·         cómo gestionar cambios

En definitiva, lo que hacemos siempre puede ser mejorado, y la visión del Servicio de TI y su calidad son una excelente e imprescindible guía para nuestro trabajo.
Como testers, tenemos que asumir nuestro pedacito de la responsabilidad.

Nota: Revisión del artículo originalmente publicado en excelza el 11/12/2009

Arriesgamos o no arriesgamos

Según la Real Academia Española, arriesgar es “poner a riesgo” y un riesgo es una “contingencia o proximidad de un daño” que puede ocurrir.
También sabemos que además puede conllevar oportunidades, que no tienen un resultado negativo si se concretan.

Como testers en un proyecto, y más aún si nos toca liderar las pruebas, lo que ponemos a riesgo o arriesgamos en nuestra tarea, es:

● la calidad del servicio que proveemos,

● la adecuada evaluación de la calidad del producto que se liberará,
● nuestra “imagen” profesional.

Si bien lo tercero es importante (para nosotros o nuestras áreas), para nuestro cliente será más importante lo segundo porque además lo ayudará a lograr concretar algunas oportunidades; entonces, si percibe el testing como de baja calidad, posiblemente no vuelva a comprarlo (a nosotros y/o a otro proveedor interno o externo a su Organización).

Por lo que no deberíamos arriesgar el éxito de nuestra misión como testers, que en definitiva pasa por cumplir los objetivos del cliente, no sólo los nuestros. Para ello, debemos entender:

Qué tipo de testing tenemos que ejecutar,
en qué contexto,
en qué momento del proyecto / ciclo de vida del producto,
con qué restricciones y recursos,
con qué objetivos

Y dado que el testing es un servicio, queremos ejecutarlo “con calidad”, para que nuestro cliente (interno o externo) nos siga contratando ese servicio, al entender él que colaboramos a obtener un mejor producto, lo que preserva su inversión.
Y recalco el colaboramos: todo el equipo de proyecto es responsable de la calidad del producto generado o modificado, de que se entregue a satisfacción de los interesados, y con una calidad suficiente para ello.

Y como la calidad es un concepto relativamente subjetivo y el testing nunca puede ser completo, en cada proyecto de testing estamos “arriesgando”.

¿Cuánto queremos/podemos arriesgar? ¿Cuánto quiere/puede arriesgar el cliente que contrata el servicio? Dependerá del daño posible, de cuán “cerca” se vea ese daño y de la gravedad de sus consecuencias. También dependerá de las oportunidades que el cliente cree tendrá con el producto, por ejemplo, introducir un producto novedoso y que le permita ganar mercado entre sus competidores.

El colaboramos a obtener un producto a satisfacción y con calidad suficiente,  sin duda depende de muchas cosas, pero entre otras, es importante la evolución mental de los testers, que puede estar en distintos estadíos según su experiencia y formación, según comenté en Probamos, pero… ¿evolucionamos?

En esa evolución, uno de los estadíos que es deseable que alcancemos tiene que ver con entender que no probamos para mostrar que la aplicación tiene defectos o que no los tiene, sino para reducir los riesgos percibidos a un valor aceptable.

Y el siguiente estadío lo alcanzamos al entender que el testing no es un acto, sino una disciplina mental que resulta en software de bajo riesgo, sin excedernos en el esfuerzo (y costos) incurrido en hacer las pruebas.

En definitiva, nuestro objetivo estará relacionado con gestionar los riesgos del software de la mejor forma posible, minimizando la utilización de recursos y tiempo, y previniendo o encontrando los problemas antes de que los encuentren los usuarios o clientes y se conviertan en usuarios o clientes disconformes. Lo que implica poner todo nuestro foco sobre los riesgos, para arriesgar menos al momento de liberar un producto.

En los párrafos previos, aparece varias veces la palabra RIESGO.
Y la necesidad de reducir los riesgos percibidos a un nivel aceptable.

En esto se basa el Risk Based Testing (RBT): el software nos expone a un conjunto de riesgos; el testing nos da información sobre el estado de esos riesgos y si se han controlado o limitado, a efectos de lograr una liberación (suficientemente) exitosa, o bajar la probabilidad de que ocurran problemas graves al liberar, en aquello fundamental para los interesados.

RBT comprende tanto la estrategia de planificación de las pruebas,
como la técnica de diseño propiamente dicha

Quienes hacemos testing, intuitivamente aplicamos algunas de sus estrategias y técnicas, aunque no las llamemos formalmente RBT… No dejan de ser cosas de sentido común, aun siendo éste el menos común de los sentidos…

¿Qué tester no ha pensado cuáles son las funcionalidades o características más riesgosas del producto que tiene entre manos, o qué situaciones se han dado en el proyecto de construcción que puedan significar riesgos para la estabilidad del producto?

Sin entrar en detalles respecto a RBT, sobre el que abunda la biografía, podemos resumir su enfoque en este gráfico:

Básicamente, muy similar a un proceso planificado de prueba.

¿En qué residen las grandes diferencias? 

En:

1) La forma de determinar el alcance inicial.

2) La forma de realimentar el diseño o el plan, en la medida en que aparecen nuevos riesgos o algunos se reevalúan.

3) La forma de diseñar los casos, a partir de los riesgos identificados, las fallas potenciales, y la manera de tratar de provocarlas.

¿Entonces?

ARRIESGUEMOS

Será la mejor forma de brindar un buen servicio a nuestros clientes, siendo eficaces y eficientes

Eso sí, hagámoslo sobre bases sólidas, y a partir de una buena evaluación de situación y riesgos del producto, los proceso, el contexto.

Nota: Revisión del artículo originalmente publicado en excelza el 09/03/2010

Sobre nuestra misión como testers

Seguramente lo primero que nos han transmitido o se nos ocurre es que nuestra misión es encontrar defectos y/o  lograr entregar aplicaciones libres de defectos. 

Pero esto es sólo una pequeña parte y es una visión muy acotada del aporte de valor que nuestro trabajo puede brindar a una Organización si es bien entendido y encarado (y recordemos que no existen aplicaciones libres de defectos, a lo sumo, si hacemos bien nuestro trabajo, estarán libres de los defectos importantes y relevantes para los interesados).

Por otra parte, fuera de considerar únicamente lo que nosotros pensamos que es testear, tenemos que tener en cuenta qué esperan de nuestro servicio o actividad quienes nos contratan o convocan, qué expectativas tienen:

• ¿Por qué una organización cree que es valioso tener un área de testing o contratar ese servicio en un proyecto?
• ¿Qué espera obtener como retorno de su inversión en el área o el servicio?
• Mejor calidad en sus productos
• Clientes o usuarios satisfechos
• Software “cero defectos”
• ….
• Todas las respuestas anteriores…
• ¿Qué espera que hagamos?
• Prueba durante el ciclo de vida de desarrollo de un producto
• Prueba de homologación de un producto adquirido
• Pruebas de atributos de calidad específicos, seguridad, performance, otros
• ….
• Todas o algunas de las respuestas anteriores…

Difícilmente podamos cumplir los objetivos de quienes nos convocan o contratan, sean clientes internos o externos a nuestra organización, si no identificamos claramente nuestra misión:

Qué tipo de testing tenemos que ejecutar, en qué contexto, en qué momento del proyecto / ciclo de vida del producto, con qué restricciones y recursos, con qué objetivos, ….

En otras palabras, si no entendemos para qué nos llaman, mal vamos a poder cumplir las expectativas. Las expectativas y las percepciones del cliente y otros interesados podrían entonces diferir mucho, con lo que podrían concluir que hacer testing no aporta valor, o que nuestros servicios no aportan valor.

Y esto es también uno de los orígenes de la “resistencia” que encontramos en algunos proyectos y una posible fuente de malos entendidos o conflictos entre los integrantes de un equipo de proyecto. 

El “no pensé que iban a probar a este nivel de detalle” o “no pensé que iban a probar esto” o frases similares, son objeciones que típicamente aparecen cuando algunos miembros del equipo de proyecto no entienden por qué estamos ahí, pero también reflejan que los  primeros que tenemos que tener clara nuestra misión somos nosotros, para aplicar nuestras mejores técnicas, prácticas, herramientas, imaginación, conocimientos, ética, para lograr cumplir esa misión.

El testing es un servicio. Dada esa definición, para poder brindarlo “con calidad” (o sea cumpliendo las expectativas del cliente) necesitamos:

• Entender expectativas y objetivos del cliente y otros interesados (pueden ser diferentes).
• Cuestionar y evaluar el producto.
• Focalizar los riesgos, entender y gestionar los cambios que afecten al servicio (en el proyecto, el producto, el contexto).
• Investigar, explorar, proveer feedback.
• Confirmar, comunicar.
• Aprender, seguir capacitándonos.

Así ayudaremos a completar el proyecto entregando un producto útil y exitoso para todas las partes. Para lograrlo es fundamental una buena comunicación y relación con todos los interesados por parte del equipo de proyecto, así como lo es entender el beneficio que brindará al negocio.

La buena comunicación ayudará a lograr que los interesados transmitan mejor sus expectativas y necesidades, se involucren más en el día a día del servicio y reciban finalmente un producto que perciban como de calidad, sin tantos tropiezos.

En relación a estos puntos, habría seguramente mucho más que decir y cada uno puede tener su propia visión.

Pueden ver también si les interesa el tema una discusión en el blog de James Bach, que aunque siendo de 2006, considero muy valioso leer:  

Question: Tester’s Freedom of Thought

Nota: Originalmente publicado en excelza el 18/10/2009