Sobre Pruebas de software y Servicios de TI

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 que estamos probando.

• Focalizar los riesgos, entender y gestionar los cambios que ocurren en el proyecto o el contexto del negocio, durante las pruebas.

En relación a cómo evaluar el producto, escribí sobre cómo podemos pensar qué probar:

• Requerimientos funcionales.

• Atributos de calidad (requerimientos no funcionales).

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 la definición de ITIL v3, 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. Los servicios no son únicamente infraestructura.

 

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.

No olvidemos al probar aplicaciones, que en el mapa completo que  vimos antes, estamos aquí:

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 la definición de dicho servicio.

 

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 (en ITIL, Service Design y Service Transition), al igual que deben estarlo nuestras actividades de verificación y validación, que deberán 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 no funcionalidad tales, que el servicio pueda proveer la utilidad y garantía acordada con el cliente.

 

Cómo se prueba un servicio?

Uno de los conceptos básicos de testing que tradicionalmente aprendemos, tiene que ver con el llamado “Modelo V”, que describe la manera de aplicar verificaciones y validaciones a los productos de software:

Similar proceso se aplica según las buenas prácticas, a nivel del servicio completo que se construye y se entrega al cliente, validando en cada nivel contra los diferentes criterios y planes establecidos:

Esto significa, por ejemplo, que si uno de los paquetes a liberar es una aplicación de software, las pruebas del paquete del servicio a liberar, cumplirán probablemente algunas de las actividades del modelo V de testing, según se planifiquen y ejecuten dichas pruebas:

También significa que 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 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, las buenas prácticas de la industria (ITIL) y las normas internacionales relacionadas (ISO 20000), son fundamentales para entender nuestro trabajo de testers, y colocarlo en el marco adecuado a las necesidades actuales de los negocios.

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 Modelo V de prueba de servicios graficado, y nuestras actividades estarán más focalizadas en la prueba de una aplicación particular, o en la prueba del 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 también deben darnos ideas respecto a:

·         dónde buscar los requerimientos a testear

·         cómo cuantificar los requerimientos no funcionales

·         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 y su calidad son una excelente guía para nuestro trabajo.
Como testers, tenemos que llevarnos nuestro pedacito de la responsabilidad de TI de brindar servicios al negocio, y cumplirlo.

Que lo disfruten!

 

Bibliografía

ITIL® v3 Service Transition – OGC - www.tsoshop.co.uk