El plan de pruebas es un conjunto de casos de pruebas que se encarga de probar una funcionalidad completa de un producto o software en concreto. Es una guía para la realización de las pruebas, con la ejecución de los casos de prueba y en base al resultado de los mismos, sabremos si el software cumple con las necesidades establecidas en el proyecto y cubre los estándares de calidad definidos.
Un plan de pruebas es la herramienta general de los profesionales dedicados a QA y a Testing y define el marco de trabajo en el que deben de apoyarse para que su trabajo sea efectivo y adecuado a lo largo de toda la vida del proyecto y del ciclo de vida del software.
Debe de realizarse a partir de los requisitos aportados en el proyecto o en las historias de usuario, depende de la metodología que se utilice. Además, se deben de realizar a partir de las especificaciones, del diseño funcional, del prototipado y de los casos de uso, entre otra documentación que se pueda obtener dentro del proyecto.
Un plan de pruebas es un elemento que debe de estar vivo a lo largo del proyecto, ya que se suelen añadir nuevas funcionalidades o requisitos y estos deben de ser cubiertos a lo largo de la vida del desarrollo del mismo.
De cara a garantizar que se cubre todo, se deben de identificar funcionalidades existentes (que se suelen sacar de toda la documentación y de reuniones que se realicen con el equipo y con cliente), pero hay una serie de componentes que pueden verse afectados por la arquitectura realizada en el proyecto y hay que tener en cuenta todo.
Hay dos tipos de modificaciones o ampliaciones dentro de un plan de pruebas, que han de tomarse en cuenta para que se pueda cubrir toda la funcionalidad existente:
- Funcionalidades de usuario final: cuando se agregan nuevos módulos, pantallas o flujos en las funcionalidades que son utilizadas por el cliente o se ven visualmente.
- Funcionalidades internas: son cambios internos que mantienen todos los elementos visuales de la misma manera, por lo tanto, el cliente final no observa ninguna modificación, pero al modificar componentes o flujos internos, como accesos a base de datos o a capas de lógica de negocio, deben de cubrirse con casos de pruebas dentro del plan de pruebas y cubrir toda la funcionalidad de este tipo.
Cuando se ejecuta un plan de pruebas al completo, quiere decir que se han ejecutado todos los casos de prueba que estaba adjuntos al mismo y en base al resultado de ellos, nos da el resultado final de plan de pruebas, pudiendo dar el OK final a la funcionalidad, módulo o software que se ha probado o el KO, abriendo los defectos oportunos y esperando a que sean solucionados para volver a ejecutar los casos erróneos y dar el OK definitivo si todo funciona como debe de funcionar.
No hay una pauta general para realizar un plan de pruebas, pero si que existen organismos como ISTQB, que nos dan unas pautas bajo su criterio. Cuando realizamos un plan de pruebas, el foco se debe de centrar más en el número y forma de los casos de prueba que lo completan y el resultado aportado en su ejecución, además, de centrarse en el objetivo para el que ha sido realizado y, despues, ejecutado.
0 Comentarios