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.
