excelza: 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.

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, tiene que ver con la calidad del producto que se liberará, y también con nuestra “imagen” profesional.

Si bien lo segundo es importante (para nosotros o nuestras áreas), para nuestro cliente será más importante lo primero, 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.

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 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 arriesgar? ¿Cuánto quiere 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.

En el artículo anterior http://excelza.blogspot.com/2010/02/probamos-pero-evolucionamos.html comenté sobre las fases en el proceso mental de evolución de los testers.

En ese proceso, 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 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.

Y en estos breves párrafos que acabo de escribir, 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.

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 estas estrategias y técnicas, aunque no las llamemos RBT… No dejan de ser cosas de sentido común, aún 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?