En la sección 5.1.1. «Propósito y Contenido de un Plan de Prueba» del ISTQB CTFL v4.0, podemos leer acerca del plan de prueba que es un documento muy importante en cualquier proyecto de testing, ya que detalla cómo pensamos enfocar y ejecutar el proceso de pruebas. Es una herramienta que facilita la comunicación entre todos los miembros del equipo. En marcos de trabajo ágiles, el plan de prueba es muy importante, es más ligero y flexible respecto de los enfoques tradicionales (cascada). Aquí analizo cada parte del contenido de la sección 5.1.1 y cómo lo puedes aplicar en un entorno ágil, incluyendo la norma ISO/IEC/IEEE 29119-3:2021 y OWASP ya que considero que debemos tenerlas en cuenta en nuestro trabajo. En caso de que estés usando como marco de trabajo Xray integrado a JIRA Software, todo este contenido es aplicable perfectamente.

Vayamos primero por lo básico: ¿Qué es un Plan de Prueba?

Un plan de prueba es básicamente el mapa que nos guía en el proceso de pruebas. Es nuestra hoja de ruta (road map) para asegurar todas las actividades necesarias que el equipo debe realizar para validar y verificar que el software cumpla con los requisitos y funcione correctamente. En un equipo ágil, el plan de prueba puede ser más flexible y adaptativo, pero su propósito principal sigue siendo el mismo: organizar y comunicar las actividades de prueba. 

Momento para reflexionar: Si estás usando Jira & Xray (o cualquier otro complemento), aplica muy bien cada una de estas recomendaciones ajustando las opciones funcionales que ofrecen las herramientas que nos permiten gestionar de manera integral el testing. Ejemplo de ésto lo tenemos con Xray que nos propone gestionar nuestro testing mediante la creación de issues del tipo Test Plan, Test Sets, Precondition, Tests y Tests Execution.

¿Cuál es el propósito de un Plan de Prueba?

1. Documentar objetivos, recursos y cronograma de pruebas 

El plan de prueba establece cuáles son los objetivos específicos que se quieren lograr con las pruebas (¿Qué se va a probar? ¿Cuál es el alcance de la Historia de Usuario?), qué recursos son necesarios, y cuál será el cronograma que seguiremos considerando la duración del sprint, lo que se haya estimado en la respectiva sprint planning y teniendo en cuenta que seguramente no se estará trabajando en una sola historia de usuario. Para los testers ágiles, esto es especialmente importante para mantenerse alineados con las metas del sprint y asegurar que se tiene todo lo necesario para cumplir con los entregables a tiempo.

1. Asegurar el cumplimiento de los criterios de prueba 

El plan también se asegura de que las pruebas realizadas cumplan con los criterios establecidos, como los criterios de aceptación. Para los testers ágiles, esto es clave para garantizar que los criterios de calidad y requisitos definidos por el Product Owner se cumplan en cada sprint.

1. Aplicar como medio de comunicación 

Un buen plan de prueba actúa como una herramienta de comunicación entre todos los miembros del equipo y otras partes interesadas (Desarrolladores, Product Owner, Stakeholders, DevOps, etc.). En un entorno ágil, donde la colaboración constante es fundamental, el plan de prueba ayuda a mantener a todos actualizados y conociendo que haremos y en dónde estará nuestro foco, asegurando que los objetivos y las actividades estén claros.

1. Alinear las pruebas con las políticas y estrategias de la organización 

En equipos ágiles, a pesar de la rapidez y flexibilidad, es importante que las pruebas sigan las políticas y estrategias establecidas por la organización para asegurar consistencia y calidad. Si el equipo necesita desviarse de estas estrategias, el plan de prueba debe explicar claramente por qué.

1. Ayudar a anticipar desafíos 

El plan de prueba obliga a los testers a anticipar posibles desafíos relacionados con riesgos, recursos, cronogramas, herramientas, costos y otros aspectos que pueden afectar el éxito de las pruebas. Esta previsión es clave para no encontrarse con sorpresas durante el sprint.

Momento para reflexionar: Recordemos que frente a los riesgos que se hayan detectado, debemos pensar en aplicar estrategias para el diseño de casos de prueba bajo riesgos. 

Contenido de un Plan de Prueba

El contenido del plan de prueba puede variar, pero normalmente incluye los siguientes puntos:

1. Contexto de las pruebas

Aquí se define el alcance de las pruebas (¿qué partes del software se van a probar?), los objetivos de las pruebas (¿qué queremos lograr con las pruebas?) y las limitaciones (¿qué no se va a probar?). En un equipo ágil, este contexto se define en cada sprint para asegurar que las pruebas se alineen con las metas del sprint.

Momento para reflexionar: Debemos considerar también las vinculaciones con otros sistemas que estén bajo el gobierno de otro equipo ya que merecerá pensar en pruebas de integración.

2. Supuestos y limitaciones

Los supuestos tienen que ver con todo lo que debe estar presente antes de que se desarrollen las pruebas, así como las limitaciones tienen que ver con las restricciones de tiempo o recursos. Por ejemplo, un equipo ágil podría asumir que todas las historias de usuario estarán completamente definidas antes de las pruebas o que se tendrá acceso a ciertos datos de prueba.

3. Partes interesadas

Define quiénes son los roles clave involucrados en las pruebas, como los responsables de ejecutar las pruebas, las personas que necesitan estar informadas, o los entrenamientos o contrataciones necesarias. En Agile, esto incluye al Product Owner, Scrum Master, Desarrolladores y Testers.

4. Comunicación

Un plan de prueba también debe definir cómo se va a manejar la comunicación en el equipo. Esto incluye las plantillas de documentos que se van a usar, y cómo se compartirán los resultados de las pruebas. En Agile, la comunicación suele ser diaria y se manejan plantillas más ligeras.

Momento para reflexionar: Si estas usando Jira & Xray (p.e. como complemento para testing management) los resultados los podemos mostrar con ciertos reportes que tenemos por defecto, y si no tenemos el que necesitamos lo podemos generar con JQL, y además creando dashboards con ciertos indicadores. 

5. Registro de riesgos

Un registro de riesgos ayuda a identificar y gestionar los posibles riesgos que podrían impactar el proyecto. Por ejemplo, si el equipo no tiene acceso a un entorno de prueba adecuado, esto podría afectar la calidad de las pruebas. En Agile, los riesgos se revisan frecuentemente para adaptarse a los cambios rápidos.

Momento para reflexionar: Si estas usando Jira & Xray (p.e. como complemento para testing management) tienes un campo para aplicar. 

6. Enfoque de prueba

Describe el enfoque que se va a seguir en las pruebas, como los niveles de prueba (pruebas unitarias, pruebas de integración, pruebas de sistema), los tipos de prueba (funcionales, no funcionales), y las técnicas de prueba (caja negra, caja blanca, exploratorias). También cubre los criterios de entrada y salida, que determinan cuándo se inicia y cuándo se considera que una prueba está completa. Para los testers ágiles, el enfoque de prueba puede adaptarse sprint a sprint.

7. Presupuesto y cronograma

Un plan de prueba también debe considerar los costos asociados a las pruebas y el cronograma en el que se llevarán a cabo. Aunque en Agile los cronogramas son cortos, es importante planificar adecuadamente el tiempo para las pruebas dentro del ciclo de desarrollo.

¿Cuál es la importancia del Plan de Prueba?

Aunque a veces se puede pensar que en Agile no hay tanta planificación formal, la verdad es que un plan de prueba sigue siendo importante, aunque puede ser más ágil y menos formal que en enfoques tradicionales. Un buen plan de prueba permite a los testers estar organizados, mantener la claridad en los objetivos de las pruebas y comunicar claramente los resultados donde los cambios son constantes. Tener un plan flexible pero bien estructurado es esencial para poder adaptarse rápidamente sin perder de vista los objetivos de calidad.

Momento para reflexionar: Si estas usando Jira & Xray (p.e. como complemento para testing management), tener un plan de prueba bien alcanzado permite que todo tester que se incorpore al proyecto, pueda rápidamente comprender todo lo que hay que probar.