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