Introducción

• El proceso de prueba nos proporciona el marco de referencia mediante el cual desarrollamos todas nuestras actividades de pruebas durante el ciclo de vida del desarrollo de software (SDLC). En este artículo estaré explorando y desmenuzando un poco los conceptos básicos, principios y objetivos de toda administración de pruebas, para comprender su aplicación en niveles superiores.
• Los aspectos clave que todos debemos considerar son:
  • El propósito de la gestión de pruebas.
    • Todo proceso de prueba con un cierto grado de estructura y gestionado es necesario para contribuir con la calidad del software (desarrollado o por desarrollar).
  • El contexto en el que se encuentra.
    • El proceso de prueba interactúa y tiene dependencia con otros procesos del SDLC.
  • Los aspectos clave para gestionar pruebas.
    • Es importante para nuestra actividad como testers que conduzcan equipos y/o proyectos, conocer el alcance de conceptos como planificación, diseño, ejecución, evaluación y cierre.

Ampliando los aspectos clave

Dentro del marco del  ISTQB® CTAL – Test Management (Versión 3.0), debemos comprender la manera de gestionar pruebas durante el SDLC para construir una base sólida, llevando a la práctica:

• El propósito y el contexto de las pruebas.
• Los conceptos y principios fundamentales.
• El proceso de prueba.
• La importancia de gestionar pruebas.

1. El propósito y el contexto de las pruebas:

• Justificación de las pruebas: En algún momento nos pedirán justificar nuestra actividad y aquí es donde tenemos que fundamentar el porqué de todo lo que hacemos y que muchas veces no se reconoce o porque no tenemos la herramienta apropiada, o porque no se ha aclarado en el sprint 0, o porque no se ha propuesta y establecido durante la sprint planning, o por falta de conocimiento y/o experiencia, entre otras muchas razones. En definitiva, podemos justificar las pruebas que hemos estimado y propuesto durante la planificación, sobre la base de los siguientes aspectos:
  • Para garantizar la calidad del software (desarrollados o por desarrollar), minimizar riesgos (identificados en la historia de usuario) y cumplir con las expectativas de los stakeholders (declarada probablemente en algún criterio de aceptación).
  • Para detectar de forma temprana de defectos, reducir costos y mejorar la satisfacción del cliente.
• Integrando a las pruebas durante el ciclo de vida del software (SDLC):
  • El proceso de prueba es una parte integral del SDLC, interactuando y/o dependiendo de otras actividades como el desarrollo, el análisis de requisitos y la gestión de proyectos. De aquí a que sea sumamente importante que toda persona que lidera equipos y/o proyectos de testing deba adquirir conocimientos en gestionar proyectos de manera ágil. En este sentido, te puedo ayudar, contáctame por LinkedIn para darte más detalles.
  • Las pruebas se adaptan a los diferentes modelos de SDLC (por ejemplo, cascada, ágil, iterativo).

2. Conceptos y principios fundamentales:

• Definición de pruebas:
  • Las pruebas de software se diferencian de otras actividades relacionadas como la depuración o la verificación. Conceptualmente esta diferencia la debemos tener muy en claro y más aún en el plano práctico.
  • Dentro de la definición de prueba, también se incorporan y refuerzan conceptos clave como defectos, fallos, riesgos, calidad y valor de las pruebas.
• Principios de las pruebas:
  • Considerar los principios fundamentales de las pruebas, como que la prueba exhaustiva es imposible, las pruebas tempranas, la agrupación de defectos, la paradoja del pesticida, las pruebas que dependen del contexto y que la ausencia de errores es una falacia, tiene su razón de ser y su aplicación práctica.
  • Estos principios guían la planificación, el diseño y la ejecución de las actividades de prueba.
• Objetivos de las pruebas:
  • La detección de defectos, la evaluación de la calidad, la verificación del cumplimiento de requisitos y la generación de confianza en el software, son parte de los objetivos principales de las pruebas.

3. El proceso de prueba:

• Descripción general del proceso:
  • La visión general del proceso de prueba, incluye fases principales: planificación, diseño, ejecución, evaluación y cierre.
  • Cada fase presenta ciertas actividades clave y entregables resultantes.
• Relación con la gestión de pruebas:
  • La gestión de pruebas se encarga de planificar, organizar, dirigir y controlar las actividades de prueba.
  • Los responsables de la gestión de prueba, se ocupan de realizar la correcta ejecución del proceso.

4. Importancia de la gestión de pruebas:

• Valor de la gestión de pruebas:
  • Optimizar el proceso de prueba, mejorar la eficiencia, reducir riesgos y garantizar la calidad del software, es el valor que ofrece la gestión de pruebas.
  • Los recursos, los tiempos, y los procesos de la gestión de pruebas, se gestionan de forma eficiente con los procesos de prueba.

Conclusión

Para este programa de estudios, nuestra atención se debe centrarse en las siguientes actividades:

• Planificación de la prueba.
• Monitoreo y control de la prueba.
• Compleción de la prueba.

Tener presente la norma ISO/IEC/IEEE 29119-2 y que todo proceso de gestión de prueba se puede aplicar a diferentes niveles, donde cada nivel puede tener su propio plan de prueba, alineado con un plan de prueba de nivel superior.

Ejemplos para llevar al plano práctico estos primeros conceptos

En proyectos ágiles, los equipos de testers se enfrentan a escenarios dinámicos y planteados con esquema colaborativo. Aquí te presento tres ejemplos prácticos que posiblemente sea parte de tu realidad cotidiana:

1. Pruebas de aceptación guiadas por el comportamiento (BDD) en un sprint:

• Escenario:
  • El equipo está desarrollando una nueva funcionalidad de «carrito de compras» para una aplicación de comercio electrónico.
  • Durante la planificación del sprint, los testers (ágiles) colaboran con los desarrolladores y el Product Owner para definir los criterios de aceptación en formato «Given-When-Then» (Dado-Cuando-Entonces).
  • Punto para reflexionar: Este escenario en algunos proyectos no suele darse por muchas razones, una de ellas puede ser que consideren que un tester puede aportar muy poco en una definición o porque le falta conocimiento del negocio o porque le falta conocimiento del proyecto, o por la simple razón que nadie antes haya planteado el hecho de incorporar al tester a la reunión, tan simple como eso.
• Ejecución:
  • Los testers ágiles automatizan estos escenarios BDD, que sirven como pruebas de aceptación ejecutables.
  • A medida que los desarrolladores implementan la funcionalidad, las pruebas BDD se ejecutan continuamente, proporcionando retroalimentación inmediata sobre el cumplimiento de los criterios de aceptación.
  • La comunicación constante con el Product Owner ayuda a clarificar dudas, y a entender correctamente los criterios de aceptación.
  • Punto para reflexionar: Este escenario ocurre cuando existe el contexto adecuado en el que los equipos de testers son bien guiados con formaciones y talleres continuos para que vayan evolucionando en su carrera profesional. Aquí bien puede ser implementado el esquema de «Comunidades de Práctica» no sólo para el desarrollo profesional sino para ir evolucionando la práctica en toda el área. En este sentido, te puedo ayudar, contáctame por LinkedIn para darte más detalles.
• Resultado:
  • Se garantiza que la funcionalidad del «carrito de compras» cumple con las expectativas del usuario desde el inicio del sprint.
  • Se reduce la necesidad de retrabajo y se acelera la entrega de valor.

2. Pruebas de exploración en una sesión de «tres amigos»:

• Escenario:
  • El equipo está trabajando en la integración de una nueva API externa.
  • Para comprender mejor los riesgos y posibles problemas, se organiza una sesión de los «tres amigos» con un desarrollador, un tester y un analista de negocio (o en su defecto, el Product Owner).
• Ejecución:
  • El tester ágil lidera la sesión de pruebas de exploración, realizando pruebas ad-hoc para descubrir comportamientos inesperados de la API.
  • El desarrollador proporciona información técnica sobre la API, mientras que el analista de negocio aporta su conocimiento del dominio.
  • Se van anotando los posibles riesgos, y los casos de prueba que se desprenden de estas pruebas exploratorias.
• Resultado:
  • Se identifican rápidamente posibles problemas de integración que no se habían previsto en la planificación.
  • Se genera un conjunto de casos de prueba adicionales para cubrir los riesgos descubiertos.

3. Automatización de pruebas de regresión en un entorno de integración continua/entrega continua (CI/CD):

• Escenario:
  • El equipo está implementando un proceso de CI/CD para acelerar la entrega de nuevas versiones de la aplicación.
  • Es crucial garantizar que las nuevas versiones no introduzcan regresiones en la funcionalidad existente.
  • Punto para reflexionar: Este escenario se puede conseguir siempre y cuando las partes se hayan puesto de acuerdo, y por «partes» me refiero al equipo de infraestructura (devops) y el equipo de seguridad informática, con el equipo de desarrollo del proyecto (testers y desarrolladores).
• Ejecución:
  • Los testers ágiles desarrollan y mantienen un conjunto de pruebas de regresión automatizadas.
  • Estas pruebas se ejecutan automáticamente cada vez que se realiza un cambio en el código fuente.
  • Los resultados de las pruebas son visibles para todo el equipo, y se generan reportes y gráficos para el seguimiento.
  • Punto para reflexionar: Aquí muchas de los scripts desarrolladores estarán vinculados con los criterios de aceptación de las historias que se estén desarrollando y el impacto que se haya identificado. Este escenario se puede plantear cuando el equipo tiene un cierto grado de madurez.
• Resultado:
  • Se detectan rápidamente las regresiones, lo que permite corregirlas antes de que lleguen a producción.
  • Se reduce el riesgo de introducir defectos en versiones posteriores, mejorando la calidad general del software.

Estos ejemplos ilustran cómo los testers ágiles colaboran estrechamente con el equipo de desarrollo y el Product Owner para garantizar la calidad en un entorno ágil. ¿Puedes identificar la relación con la parte conceptual definida e imaginarte su aplicación?

Fuente de inspiración: ISTQB® Certified Tester – Advanced Level – Test Managent, Version V3.0