La prueba y el contexto del producto

Más allá de los procesos y los aspectos técnicos de la prueba de un producto de software (planificar o no, escribir o no casos de prueba, a qué nivel de detalle, tipos de prueba que conviene realizar, ambientes, herramientas, buenas prácticas, modelos de calidad, …), están los equipos de trabajo que llevan adelante estas actividades. Las personas que los forman. Sus intereses y expectativas. Sus conocimientos. Su sentido ético y profesional. Podríamos seguir la lista.

Quedarse sólo a este nivel pensando que la prueba del software es meramente algo técnico y repetitivo que hace un equipo de trabajo, nos hace perder de vista muchos aspectos del contexto que impactan en la calidad del producto de software percibida o “vivida” por los interesados.
Puede conducir al fracaso del producto cuando es recibido por ellos, o a su éxito.
Las expectativas de los interesados se satisfarán o se frustrarán. 
Los requerimientos explícitos e implícitos estarán cumplidos o no, probados o no, se irán corrigiendo los defectos remanentes y evolucionando el producto según nuevos requerimientos aparezcan o se detecten otras necesidades o tendencias, o aparezcan nuevas tecnologías.

Y los interesados son muchos, diversos, internos o externos a las organizaciones que construyen o proveen el producto de software, conocidos o desconocidos, sujetos a control respecto a la forma en que interactúan con el producto o no, interrelacionados de alguna forma, simple o compleja, … 

Los productos (tanto tangibles como intangibles), además de ser de diferentes tipos, se utilizan de diversas maneras, en diferentes ambientes y lugares, por diferentes personas.
Los productos de software actualmente se ejecutan en plataformas complejas, se interconectan, y se regulan en muchos casos.

Los productos existen porque brindan algún valor, son parte de algún servicio que los contiene, o incluso son el centro del servicio.
Por ejemplo, escribimos con un lápiz, pero también podemos hacerlo con otros productos; podemos elegir y cambiar, según el valor que nos brinde el producto en un contexto dado, como el material sobre el que queremos escribir, en qué color, cuán permanente queremos que sea lo escrito, qué tenemos a mano en el momento en que queremos escribir.

El valor es percibido o no por los diversos interesados, a lo largo de su construcción y su vida útil, y el servicio tiene también evolución, aspectos de calidad, y hasta posibilidades de desaparecer la necesidad que le dio origen.
Los productos pueden contribuir a reducir los riesgos o preocupaciones de los interesados, o a su éxito en algún aspecto. O no aportar valor en esos sentidos.

También la cultura de las organizaciones en que los productos y servicios se construyen y/o se brindan, ocupa un lugar preponderante en el contexto del producto y el servicio. Y su facilidad o aversión a encarar cambios de ser conveniente, respecto a la calidad, la fluidez del conocimiento, la estructura, procesos, herramientas, valoración de su personal, entre otros aspectos. ¿Está realmente la organización dispuesta a mejorar la calidad para ser más exitosa? ¿Querrá transmitir a su gente qué es lo que aporta valor al negocio, y cuándo lo está perdiendo? ¿Querrá analizar por qué y emprender un camino de cambios?

¿Tenemos posibilidades de aportar como testers algún valor al negocio sugiriendo pequeños cambios que muestren beneficios en el corto plazo? ¿Estamos dispuestos a hacerlo saliendo de nuestra zona de confort técnica?

Los aspectos más relevantes en el contexto de la calidad del producto de software mencionados están resumidos en este gráfico:

Pero vayamos otra vez a lo técnico. ¿Y con la prueba qué hacemos?

Fundamentalmente, no olvidar que todo ese contexto existe. Si no lo consideramos, pueden quedar aspectos importantes no cubiertos por las pruebas, aunque hayamos pensado, elaborado, ejecutado y/o automatizado cientos de casos de prueba. La identificación de amenazas y riesgos del producto quedará incompleta. La utilización del producto más allá de su construcción podrá tener defectos más o menos fáciles de corregir, pero lo que es más grave, no habremos brindado un buen servicio: proveer a los interesados información valiosa para tomar decisiones respecto al producto de software.  

Las pruebas exploratorias y las planificadas, en cualquier tipo de proceso, pueden alimentarse del contexto para elaborar las ideas y estrategias de prueba. Independiente de nuestra misión específica respecto a un producto dado.

Considerar el contexto nos permitirá brindar un servicio de testing valioso y perdurable, que nos motive a seguir brindándolo, y que motive a nuestros clientes, internos o externos, a seguir comprándolo.

También nos dará la satisfacción de haber contribuido no sólo a elaborar un producto estándar o bueno, sino que deleite.