Cuando nos enfrentamos a un desarrollo que nos entrega una empresa externa, siempre tenemos la incertidumbre de hasta donde llegarán sus pruebas y validaciones.
En la mayoría de los casos, un desarrollo externo no cumple con ciertas "reglas" que si que cumplen cuando trabajamos con nuestros equipos internos, donde además tenemos la ventaja de poder tratar a diario y cara a cara con los desarrolladores.
Cuando nos entregan un desarrollo externo y en la mayoría de los casos es algo cerrado y en bloque, tenemos que realizar un tratamiento de choque y pivotar prácticamente a todo el equipo para encontrar de un solo vistazo todos los defectos (en el caso de que los hubiese) que podamos, asegurando que al menos, tras esta primera validación todo funcione como debe.
Esta primera validación se debería de realizar con la técnica de las pruebas exploratorias que ya os he comentado en varias ocasiones.
En el caso de encontrar defectos, esto nos dará un tiempo muy valioso que dedicaremos a mejorar (o a realizar) los casos de prueba, en base a los requisitos antiguos y nuevos que se especifiquen después (suele ocurrir en estos casos, que se cambien cosas en el momento).
Una vez que se devuelvan los defectos y podamos reprobarlos, dedicaremos el 100% del tiempo a validar el desarrollo externo con los casos de prueba completamente actualizados, permitiéndonos encontrar otros defectos que no hemos podido encontrar en una primera exploración.
Una vez que hemos pasado los casos de prueba y hemos encontrado defectos que tendrán diferentes criticidades, de esta manera nos resultará muy fácil montarnos una batería de pruebas de regresión funcional que podremos automatizar y poder cerrar siempre este desarrollo y comprobar que no falla en ninguna de las subidas a producción que tengamos en el futuro.
Comentarios
Publicar un comentario