La planificación de pruebas es esencial para el éxito de cualquier proyecto de desarrollo de software, ya que permite tener en claro un objetivo definido, su alcance, los recursos (humanos y técnicos) y el cronograma de las pruebas a realizar, asegurando la calidad del producto final. Estas actividades se pueden llevar a cabo en cualquiera de los niveles de prueba, mediante el tipo de prueba que se requiera o en la versión/iteración/sprint en Agile que se necesite.
Punto para reflexionar: Seguramente lo sabrás, no te diré nada nuevo, pero por las dudas y para que estemos alineados en este sentido pienso que es severamente importante que TODO el equipo de proyecto y de desarrollo entienda la razón de ser del primer párrafo, incluso debiera también estar en conocimiento del tema quienes o quien represente al negocio, sea el líder de los product owners o el product owner a cargo del proyecto. En síntesis, el «negocio» debe estar involucrado y en caso de no lograr el entendimiento que requiera, nosotros «debemos» acompañarlos en dicho entendimiento ya que el beneficio será para todos. Es muy importante que esta reflexión la hagas como para auto evaluar tu condición y situación.
Algunas preguntas que me surgen a partir de leer el título
- En relación con la importancia de planificar nuestras pruebas:
- Una planificación de pruebas deficiente puede aumentar los costos del proyecto hasta en un 50%.
- La planificación de pruebas debe comenzar lo antes posible en el ciclo de vida del desarrollo de software, idealmente antes de la identificación de los requisitos.
- El plan de pruebas debe ser un documento vivo que se actualice a medida que avanza el proyecto.
- Punto de reflexión: Si bien para nosotros es sumamente importante planificar nuestras pruebas, el equipo de desarrollo y de proyecto también lo debe entender así porque de estar trabajando en modelo ágil, marco scrum, hay que considerar el espacio o el tiempo que le dedicaremos en ciertos sprints para pensar la idea del alcance del plan y gestionar le ejecución y mantenimiento del mismo. Algunos ingredientes más a considerar para pensar en la complejidad que debemos manejar:
- ¿En cuánto influye a la planificación de pruebas el correcto entendimiento de la o las historias de usuario?,
- gestión de equipos de testers con diferentes habilidades y que atienden diferentes partes de proyecto (p.e. front end, back end), diferentes tipos de prueba a realizar y por ende,
- a gestionar (p.e. automation testing, performance testing, usability testing, security testing entre otras),
- implementación y uso (y mantenimiento) de las diferentes herramientas que necesitemos para aplicar las prácticas mencionadas.
- Ni hablar si además de se usan herramientas que nos sirven para asentar y organizar nuestro proceso de control de calidad como puede ser un Jira Software.
- Todo deberá estar contemplado en la planificación de nuestras pruebas. Hasta aquí, sólo algunos ingredientes, ¿no?
- En relación con los riesgos del producto:
- La identificación temprana de los riesgos del producto puede reducir significativamente el impacto de los defectos en el producto final.
- Los riesgos del producto pueden ser técnicos, de negocio, de proyecto o de otro tipo.
- El análisis de riesgos debe involucrar a una variedad de partes interesadas para asegurar una visión completa de los riesgos potenciales.
- Punto para reflexionar: Lo importante que debemos pensar aquí es cuánto nos hemos capacitado en análisis de riesgo enfocado al testing, ¿Sabemos planificar y ejecutar prueba basadas en riesgos? ¿Estamos en condiciones de identificar puntos vinculados a riesgos de producto o ausencia de los mismos cuando nos enfrentamos con la o las historias de usuario en la sprint planning si estamos participando en proyectos ágiles?
- En relación con el tratamiento de riesgos:
- Existen diferentes estrategias de mitigación de riesgos, como pruebas específicas, asignación de recursos adicionales o planes de contingencia.
- La elección del enfoque de tratamiento de riesgos depende del nivel de riesgo y del contexto del proyecto.
- El tratamiento de riesgos debe ser monitoreado y ajustado a lo largo del proyecto.
- Punto para reflexionar: ¿En qué medida estamos involucrados? ¿Participamos de todas las reuniones donde son tratados los temas relacionados con riesgos como para que conocer los posibles impactos que puede haber y pensar en el testing basado en riesgos que debemos considerar ejecutar en los sprints que correspondan?
- En relación con la norma ISO/IEC/IEEE 29119-2:
- La norma ISO/IEC/IEEE 29119-2 proporciona una guía completa para la gestión de pruebas.
- La norma ISO/IEC/IEEE 29119-2 puede ser utilizada por organizaciones de cualquier tamaño y sector.
- La aplicación de la norma ISO/IEC/IEEE 29119-2 puede ayudar a mejorar la eficiencia y la efectividad de las pruebas.
- En relación con la importancia del plan de pruebas:
- Un plan de pruebas bien definido facilita la comunicación y la colaboración entre las partes interesadas.
- El plan de pruebas debe ser revisado y aprobado por todas las partes interesadas.
- El plan de pruebas debe ser accesible y comprensible para todos los miembros del equipo de pruebas.
- Punto para reflexionar: Todos estos puntos se pueden materializar mediante un Jira Software por ejemplo considerando que por cada Historia de Usuario tendremos un Plan de Prueba que ejecutará la misma. Esta vinculación podrá ser visualizada por todo el equipo de proyecto, se pueden definir usuarios Observadores que pueden ser muy bien personas bajo el rol de Stakeholders y hasta incluso se puede conocer cómo esta constituído el Plan de Pruebas. De más esta decir que al ser un artefacto de trabajo, se podrá clonar y adecuar al próximo proyecto.
El objetivo es proporcionar información adicional relevante e interesante que pueda ayudar a los usuarios a comprender mejor la importancia de la planificación de pruebas y la gestión de riesgos en el desarrollo de software.
Actividades importantes
Comprender el contexto y organizar la planificación de pruebas
Es fundamental comprender el contexto de la organización, incluyendo la política de pruebas y la estrategia de pruebas de la organización, así como el alcance de la prueba y el elemento de prueba. Esto implica todas las actividades necesarias para organizar el desarrollo del plan de pruebas y obtener la aprobación de las partes interesadas, como el propietario del producto, el jefe de proyecto o el jefe del equipo de desarrollo.
Identificar y analizar los riesgos del producto
El análisis de riesgos implica la identificación y evaluación del impacto potencial y la probabilidad de los riesgos del producto como parte de la planificación de las pruebas.
Identificar los enfoques de tratamiento de riesgos
Con base en el análisis de riesgos, se seleccionan y documentan en el plan de pruebas los enfoques adecuados para el tratamiento de riesgos. Estos pueden incluir acciones preventivas, correctivas o de mitigación para abordar los riesgos identificados.
Definir el enfoque de prueba y estimar y asignar los recursos de prueba
Con base en la estrategia de pruebas de la organización, las normas reglamentarias, las restricciones del proyecto y los enfoques de tratamiento de riesgos, se define el enfoque de prueba para el alcance actual de las pruebas. Al definir un enfoque de prueba, es importante estimar los recursos de prueba necesarios, como personal, herramientas, entornos y datos de prueba, y asignarlos a las actividades de prueba.
Establecer el plan de pruebas
El plan de pruebas debe ser aceptado por todas las partes interesadas y, por lo tanto, deben resolverse los desacuerdos entre ellas.
Fuente de inspiración: ISTQB CTAL-TM v3.0
