Plan de pruebas y su importancia

Creo que muchas personas en pruebas de software han escuchado el término plan de pruebas, sin embargo, no todos saben lo que realmente es un plan de pruebas, su importancia y las partes de él. Hoy voy a describir lo que para mi son las partes mas importantes y lo que es un plan de pruebas.

El plan de pruebas es el documento que describe lo que QA va a hacer en el proyecto, si me lo preguntan a mi, no se puede asegurar o garantizar el éxito y la calidad del proyecto o que el proyecto salga bien sin un plan de pruebas porque no se tendrá suficiente información sobre el mismo, es decir, que se debe probar, como se debe probar, que tipos de pruebas se deben hacer, que no esta incluido, entre otros aspectos. Se debe tener un alcance en el proyecto y una cobertura a probar, y dependiendo del tipo de proyecto, puede ser mas complejo. Desde mi punto de vista un plan de pruebas debería incluir los siguientes puntos:

• Alcance: ¿Qué se va a probar ?
• Objetivo: ¿Cual es el objetivo o la meta que tiene el cliente con el proyecto?
• Fuera de alcance: Lo que no se va a probar y no esta incluido en el proyecto
• Roles y responsabilidades: ¿Cuantos QAs estarán en el proyecto (Líder QA, automatizador de pruebas, analista de calidad, etc) y cuales son sus tareas en el proyecto?
• Metodología: El enfoque del proyecto y como se atacará, ¿será con BDD?, ¿metodología ágil?, ¿se harán casos de prueba?
• Navegadores/sistemas operativos/dispositivos móviles a probar: Esto se debe definir por parte del cliente, sin embargo, como QA, se deben saber cuales son los navegadores/sistemas operativos/dispositivos móviles mas usados a nivel mundial, y si el cliente no sabe, siempre se puede proponer en que probar, por supuesto, la última palabra la tiene y debe tener siempre el cliente respecto a su alcance y su objetivo.
• Puntos de interrupción o quiebre (breakpoints) solo para proyectos web responsivos.
• Tipos de pruebas (seguridad, accesibilidad, automatizadas, desempeño, entre otras): No todos los proyectos requieren todos los tipos de pruebas, esto depende del tipo de proyecto y del alcance, a veces ingenieros de pruebas o QAs internos del cliente hacen algunas de las pruebas descritas, para mi, siempre se debe proponer hacer la mayor cantidad de estos tipos de prueba si se tiene el conocimiento y las habilidades.
• Guía para el reporte de errores: Esto depende de cada compañía, generalmente es un modelo ya pre establecido, es bueno describirlo en este punto.
• Severidad de los errores: Se debe describir que es un error que bloquea al usuario, crítico, mayor, menor, para que todo el equipo sepa y esté claro en los errores que reporta el equipo de QA.
• Herramientas a usar: Es bueno describir las herramientas que se van a utilizar y no cambiarlas a la mitad del proyecto, puede pasar que el cliente pida herramientas que no sabes usar o que desconoces, en todo caso, es mejor listar las herramientas a usar y para que son en este punto.
• Riesgos: Se deben resaltar los riesgos iniciales en el proyecto, por ejemplo fecha de entrega muy cercana, entrenamientos requeridos, el tamaño del equipo no es el adecuado, entre otros.
• Ambientes de prueba: Esto tal vez no se sepa en esta etapa, pero si se sabe, no se debe olvidar agregar los ambientes de prueba que tendrá el proyecto

Pueden haber mas componentes aparte de los que mencioné arriba, como: criterios de éxito y certificación de QA, entregables, una lista a alto nivel de las funcionalidades a probar, y muchos mas, sin embargo, eso también depende de los modelos y documentos internos de la compañía y del enfoque del QA, creo que con las partes descritas arriba tienen un gran plan de pruebas.

Es muy importante que el plan de pruebas se comparta no solo con el cliente, sino con todo el equipo de trabajo porque tanto desarrolladores como gerente de proyecto,  dueño del producto (PO), equipo de diseño, deben estar informados sobre el alcance, esto ayuda a alinear expectativas y cambios en el plan, si hay sugerencias por parte del equipo, se debe llegar a un acuerdo entre todo el equipo. La aprobación del documento es importante porque asegura y garantiza que el alcance es válido y que el enfoque presentado por el equipo de QA es el correcto.

En muchas entrevistas que he tenido con diferentes candidatos, siempre que les pregunto sobre las partes del plan de pruebas, algunos a veces mencionan los casos de prueba, en mi experiencia y desde mi punto de vista, los casos de prueba son descritos y mencionados después en el proyecto, ya que aún no se sabe toda la funcionalidad a fondo y detallada, esto se sabe en una fase distinta. No olviden que el plan de pruebas es el primero o uno de los primeros entregables del proyecto por parte del equipo de QA y que los casos de prueba, escenarios de prueba o "feature files" se hacen mucho después a medida que avanza el proyecto.

Como pueden ver, el plan de pruebas define y limita las pruebas a hacer y es realmente importante tener un plan de pruebas en cada proyecto sin importar que tan pequeño o sencillo pueda llegar a ser, es la primera base de lo que se hará mas adelante en el proyecto.

Una vez mas, espero que les guste este articulo, el próximo martes estaré hablando sobre casos de prueba Vs feature files.

Déjenme sus comentarios

@LuchoAgileQA