El hecho de testear una aplicación conlleva reunir cada vez más y más información. Esto a su vez provoca que cada vez encontremos defectos nuevos en áreas o que antes no prestábamos importancia, eternizando el proceso de testing y provocando una sensación (a mi juicio, verdadera) de que “el test nunca termina”. En vez de eso, deberíamos dar por terminado el proceso de test cuando creamos que hay una baja probabilidad de encontrar un defecto de alta severidad.
Podemos destacar algunos factores que nos decidirán dar por finalizado el proceso del testing:
- Conocemos los tipos de defectos de alta severidad que puedan aparecer.
- Conocemos como funcionan las áreas funcionales del producto, y sabemos como pueden responder ante un problema importante (se nos ha proporcionado toda la documentación necesaria del producto).
- La estrategia de test seguida ha sido suficientemente grande (es decir, no nos hemos focalizado especialmente en un área).
- Hemos usado todos los recursos disponibles para el testing (tools, automatización, etc.).
- Hemos cumplido con todos los procesos estándares de test que el cliente espera que implantemos.
- Hemos desarrollado una estrategia de test y unos resultados tan claros como hemos podido.
- Los defectos (no cerrados) están puestos en conocimiento de los responsables.
Aun así, el mundo no es perfecto y siempre puede aparecer un defecto crítico tras finalizar el proceso, en tal caso, deberíamos hacer un poco de autocrítica y repasar qué estamos haciendo mal:
- No entendimos correctamente los riesgos y funcionalidades del producto.
- No hemos cubierto correctamente todas las áreas, y ha habido funcionalidades sin testear.
A medida que vayamos ganando experiencia en el producto y haciendo sucesivas rondas de test, iremos mejorando nuestros procesos y aumentando la cobertura de los mismos siempre que aprendamos de nuestros errores y los corrijamos, en vez de lamentarse.
Ademas de todos los factores “tecnicos” que comenta Pere, yo incluiria tambien en la lista factores economicos o de “budget”. Muchas veces, sobretodo si trabajas en casa de un cliente, es el, el que te marca el numero de rondas de test, su duracion y los recursos asignados, que dependeran siempre del “budget” que tenga asignado para el proyecto de testing. Las consecuencias de esta dependencia “economica” que tiene el testing se traducen, normalmente, en rondas de “estabilizacion” cuando el producto ya esta en la calle
Las rondas de “estabilización”, a mi juicio, son útiles si se tiene un tiempo de respuesta e implantación bastante rápido. Es decir, por temas de “lanzamiento estratégico” de una versión/app al mercado, no se puede dejar de hacer una ronda completa de test.
Sin embargo, las carencias de una ronda de test, siempre se ven “cubiertas” por el conocimiento de los defectos con los que la versión/app sale al mercado (que obligatoriamente deben ser defectos menores, por no decir “cosméticos”).
Pero eso es inevitable, debe ser el PM el que decida poner la aplicación en producción. El QA no se puede convertir en la persona que pare una entrega o puesta en producción. Debe limitarse a dar su opinión, argumentarlo y aconsejar al PM sobre los riegos que implica.
No conozco ningún caso en el que QA puede estar verificando tanto tiempo como quiera… de todas formas, llega un punto en el que el esfuerzo que se hace y la carga de trabajo que se genera no compesa (se introducen issues que difícilmente se corregirán o que tienen mucho de aportación propia del QA)
Si, es el PM quién finalmente toma la decisión no sólo de poner o no la app en producción, sino también de qué defectos se pasan a la siguiente versión y cuales descartar aunque sigan siendo defectos tanto desde el punto de vista de QA como de desarrollo.
La limitación del tiempo de pruebas, va acorde a la naturaleza de los proyectos/apps.