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

Software Product Quality - Más allá de los defectos

Hemos publicado nuestro artículo acerca de calidad de producto de software y la evolución de una organización en su intento de lograrla, en su versión en español.

En el artículo se muestra un caso práctico y el análisis del mismo.

El articulo en español lo pueden encontrar en 

Software Product Quality Más allá de los defectos

Probamos, pero… ¿evolucionamos?

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 lograrla.

Componentes fundamentales en la calidad de nuestro servicio serán la continua capacitación de nuestros testers, y lograr que ellos evolucionen en sus procesos mentales, para ser cada vez más eficaces y eficientes.

Revisando algunas definiciones históricamente aceptadas de qué es probar, de qué es un tester, o qué es calidad, vemos que existe una importante evolución en esas definiciones o conceptos.  Esa evolución está muy bien resumida en, y tiene correlato con, las llamadas “fases mentales del tester”  que describe Beizer en su clásico libro "Software Testing Techniques":

• Fase 0: El testing y el debugging son aproximadamente lo mismo. El propósito único del testing es ayudar a hacer debugging.        
• Fase 1: El propósito del testing es mostrar que el software funciona.
• Fase 2: El propósito del testing es mostrar que el software NO funciona.
• Fase 3: El propósito del testing no es mostrar que funciona o no funciona, sino reducir los riesgos percibidos a un valor aceptable.
• Fase 4: El testing no es un acto, es una disciplina mental que resulta en software de bajo riesgo, sin demasiado esfuerzo en hacer pruebas. 
        

Cómo nos impactan estas fases

 Aunque sea básico en cualquier curso de testing explicar axiomas como “nunca podemos encontrar todos los defectos”, “sólo podemos probar la existencia de defectos, no su ausencia” y otros, no siempre los entendemos, o no siempre todos los que están a nuestro alrededor en un proyecto los entienden o aceptan. Pese a que desde que Beizer describió estas fases, la profesión se ha difundido y avanzado mucho. Al igual que el entendimiento de la necesidad de prevenir los problemas de  calidad, mejorar procesos y productos, y hacer pruebas.

Por lo tanto, dependiendo de la madurez de la organización en que estemos trabajando, en muchos casos surgirán problemas a la hora de definir / pedir lineamientos / consensuar mecanismos de:

• Separación de ambientes (probemos en producción / probemos en desarrollo)
• Control de configuraciones (para qué?)
• Control de versiones (seguro que se necesita?)
• Registración y seguimiento de defectos (sólo luego de que los desarrolladores los aceptan…)
• Conjunto básico de métricas (horas de trabajo, qué más?)
• Criterios de reporte (sólo los defectos importantes, o quedaremos mal!!!)
• Criterios de planificación (lo más difícil o complejo al final, testing sólo al final…)
• Priorización de defectos / diferencias Severidad-Prioridad (es lo mismo!…)
• Criterios de finalización de pruebas (fecha fija / cero defectos!!)
• ….

La imposibilidad de consensuar sobre estos puntos, afecta a la calidad de nuestro trabajo, y a nuestra “calidad de vida” durante los proyectos.  Pero lo más grave, es que dificulta cumplir el principal objetivo del testing, que es el que se logra cuando se llega a Fase 4:

Ayudar a construir software
con la funcionalidad y atributos de calidad requeridos,
entregándolo a tiempo,
con costes que lo hagan financieramente posible,
y logrando la satisfacción de usuarios, clientes y otros interesados

Un punto muy importante sobre el que volveré, tiene que ver con la Fase 3: reducir los riesgos percibidos.

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