Entre los elementos básicos a tener en cuenta, planificar y diseñar al
gestionar un área de QC o pensar una estrategia de pruebas para un proyecto o
servicio específicos, no podemos dejar de lado los ambientes y datos de prueba
necesarios.
Ambientes
y datos de prueba ocasionan en algunos casos preguntas como “¿Realmente se necesitan? ¿No puede ser la máquina
del desarrollador / ambiente de desarrollo? ¿Por qué no Producción antes de
liberar? ¿Un equipo potente les es
suficiente? ¿No pueden crear sus propios datos, o traer una base / archivos
productivos? …”,
o directamente objeciones como “Nunca los hemos tenido; en nuestro caso no es necesario; saldrá muy caro…”
o directamente objeciones como “Nunca los hemos tenido; en nuestro caso no es necesario; saldrá muy caro…”
Afortunadamente
estas preguntas y objeciones son cada vez menos frecuentes. Sin embargo, aún
pueden aparecer, y es parte de nuestra misión al gestionar un área de pruebas o
un proyecto / servicio dados, ocuparnos seriamente de ambientes y datos de
prueba. Desde contestar adecuadamente las preguntas y objeciones, pasando por
saber diseñarlos, solicitarlos y gestionarlos.
Ellos contribuirán a la fiabilidad de nuestras pruebas. En definitiva, lograremos que lleguen a Producción productos donde las pruebas realizadas serán más representativas de lo que ocurre en la realidad, deseablemente con menos fallas evidentes u ocultas.
Ellos contribuirán a la fiabilidad de nuestras pruebas. En definitiva, lograremos que lleguen a Producción productos donde las pruebas realizadas serán más representativas de lo que ocurre en la realidad, deseablemente con menos fallas evidentes u ocultas.
Hemos
aprendido y enseñado habitualmente que al menos tres ambientes bien diferenciados
son los mínimos recomendables:
- Desarrollo. Donde trabajan los
desarrolladores con todas sus
herramientas.
- Pruebas. Donde trabajan los testers con sus propias
herramientas y datos.
- Producción. Donde trabajan los
usuarios con sus datos y donde las aplicaciones conviven con otras.
Y
que deseablemente se agrega un cuarto ambiente entre Pruebas y Producción:
- Pre-producción. Donde
pueden trabajar los usuarios con copias de sus datos durante las pruebas
de aceptación, existirán algunos de los sistemas con los que convivirá la aplicación, se pueden dar capacitaciones y demostraciones sobre los productos a liberar
o modificados, y se pueden realizar pruebas de requerimientos no
funcionales.
Y
la disyuntiva que suele plantearse es la del título de este artículo:
Ser o parecer.
Ser o parecer.
- ¿Puede
nuestro ambiente de Pruebas ser
Desarrollo / Producción / Pre-producción, tal vez utilizando distintas
instancias de los datos?
- ¿Pueden nuestros
datos de prueba ser
directamente los datos de Producción?
- ¿Cuánto
se tienen que parecer los
ambientes que nos suelen ocupar, Pruebas y Pre-producción, al ambiente de
Producción?
- ¿Cuánto
se tienen que parecer los datos
de prueba que generemos a los datos productivos?
Lamentablemente
no tenemos una respuesta terminante y taxativa a estas preguntas, sólo que deberían
“parecerse tanto como sea posible”.
Y
esa recomendación parte del sentido común, y de la necesidad y conveniencia de
llevar a cabo pruebas que realmente diagnostiquen la calidad de los productos
entregados. Al margen de considerar que muchos tipos de pruebas directamente no
tienen sentido en ambientes o con volúmenes o variedad y tipo de datos no similares
a Producción.
Como
ya he mencionado, ambientes y/o datos mal configurados o estructurados, generan
riesgos respecto a la calidad de nuestras pruebas. Entonces, ¿por qué no
gestionar esos riesgos como
gestionamos los del producto de software que estamos probando? ¿por qué no
justificar la inversión necesaria en adquirir / configurar los ambientes y
generar los datos de prueba, en función al riesgo de pérdidas potenciales para el negocio que ocasionan pruebas no fiables?
Poder
pensar, planificar y luego gestionar, ambientes y datos con los que controlamos
la calidad de los productos de software, ayuda a mitigar adecuadamente los
riesgos identificados en relación al producto, a su contexto y a su evolución.
Entonces:
- Ajustemos
los diseños y estrategias a lo importante para mitigar los riesgos y potenciales pérdidas, dentro de las restricciones existentes.
- Justifiquemos
y negociemos alternativas para los ambientes y datos de prueba, mostrando los riesgos de cada una.
No hay comentarios:
Publicar un comentario