A la hora de definir una buena estrategia de pruebas, identificar los riesgos de productos es una práctica clave para sacar el máximo rendimiento a las actividades de pruebas y conseguir la máxima calidad de producto con el menor esfuerzo posible.
Recuerdo hace algunos años que estuve inmersa en un complejo proyecto de pruebas de una nueva aplicación para una entidad financiera, donde la arquitectura a utilizar estaba en plena construcción, utilizaban tecnologías muy novedosas, el equipo de desarrollo era muy junior y el propio cliente no terminaba de tener claro el objetivo final de la aplicación que nos encargó.
En este contexto, el primer paso fue realizar un análisis de los riesgos funcionales. Tuvimos en cuenta el impacto económico de cada uno de los requisitos a desarrollar, cómo afectaría un fallo de ellos en la imagen del cliente y en su negocio, así como la calidad de las especificaciones que nos proporcionaban. De esta manera, pudimos identificar qué pruebas funcionales debían ser nuestra prioridad a la hora de definir nuestra estrategia de pruebas y qué nivel de compromiso y apoyo funcional necesitaríamos del cliente para la correcta especificación de las pruebas.
En segundo lugar, pusimos nuestro foco en los riesgos no funcionales, los grandes olvidados la mayoría de las veces. Identificando los potenciales problemas que se podrían encontrar en una puesta en producción tan ambiciosa, hicimos ver al cliente, la importancia de tenerlos presente e implementar algunos tipos de pruebas no funcionales como pruebas de volumen de usuarios y de seguridad, no contempladas a priori. De esta forma, aumentamos nuestro alcance como proyecto de pruebas, identificando y ofreciendo solución a cada uno de los riesgos detectados en lugar de esperar a que fuera demasiado tarde.
A continuación, evaluamos los riesgos de arquitectura, que eran bastante elevados si además teníamos en cuenta que se estaba desarrollando en paralelo al propio proyecto, y en una tecnología bastante novedosa. Esto, unido a la poca experiencia de gran parte del equipo en dicha arquitectura, hizo que se recomendara en la estrategia de pruebas definida, pruebas unitarias y de integración técnicas muy exhaustivas, ayudándonos de las herramientas adecuadas y haciendo uso de entregas continuas.
Según fueron madurando las soluciones propuestas para mitigar los riegos identificados inicialmente, nuestra estrategia de prueba fue evolucionando, pasando de una aplicación de técnicas muy exhaustivas y una gran inversión en el proceso de pruebas, a una solución ampliamente automatizada, con un equipo de pruebas más reducido.
Gestora Unidad de Testing en Software Lab de Indra – Badajoz
