Cuando los desarrollos están a punto de finalizar y las funcionalidades están casi listas para ser entregadas, deben asegurarse de que estas cumplan con los criterios de aceptación de las Historias de Usuario y se ajusten a la Definition of Done. Esto garantiza que no se comprometa la calidad del producto.
Probar las funcionalidades antes del despliegue
En el equipo, cada uno tiene un papel que desempeñar para cubrir las pruebas técnicas y funcionales de cada funcionalidad y permitir ofrecer a los usuarios funcionalidades de calidad:
- Los desarrolladores prueban sus desarrollos integrando pruebas técnicas.
- Los Product Designers y Product Managers realizan pruebas funcionales que buscan validar la conformidad de los desarrollos con lo esperado, descrito en las Historias de Usuario y los prototipos.
- Los Testers redactan, ejecutan y mantienen campañas de pruebas funcionales avanzadas, automatizadas o no.
Este artículo es un extracto del libro:
La importancia de las pruebas de aceptación
Las pruebas de aceptación verifican que las funcionalidades desarrolladas cumplan con los criterios de aceptación de las Historias de Usuario. Podéis redactar las pruebas de aceptación utilizando el BDD (Behaviour-Driven Development).
Este enfoque, creado por Dan North, permite redactar pruebas en un lenguaje claro y con ejemplos concretos, mejorando la comprensión entre los Product Managers, desarrolladores y testers.
Podéis uniformar la sintaxis de las pruebas de aceptación utilizando el lenguaje Gherkin. Este lenguaje se basa en una sintaxis estandarizada, que se presenta de la siguiente manera:
GIVEN (dado que): los prerrequisitos para la correcta ejecución de la prueba.
WHEN (cuando): la acción a realizar.
THEN (entonces): el resultado esperado.
Este lenguaje permite redactar ejemplos precisos y facilita la automatización de pruebas.
Realizar pruebas de no regresión
Antes de desplegar una nueva funcionalidad, es importante asegurarse de que esta no impacte negativamente en el funcionamiento global del producto. Para ello, lleva a cabo pruebas denominadas de no regresión. Sin embargo, estas pruebas pueden rápidamente convertirse en consumidoras de tiempo. Por lo tanto, debes priorizar los casos a probar (los recorridos con más tráfico, los casos de uso más críticos...).
La automatización de los tests también es una estrategia interesante para facilitar las campañas de tests de no regresión. Dependiendo de las organizaciones, las pruebas automatizadas pueden ser implementadas directamente por los desarrolladores durante la implementación de una Historia de Usuario o por un tester automatizador.
Adaptar la estrategia de pruebas
La profundidad de las pruebas depende del tipo de funcionalidad, la madurez del producto y el contexto. Es esencial definir cuántas pruebas se realizarán y cuánta inversión se hará en QA. Cuando los recursos son limitados, trabajar en colaboración con los desarrolladores es clave para asegurar una buena cobertura de pruebas.
En un equipo que requiere un ejercicio de QA minucioso, el refuerzo de testers dedicados al equipo es una ventaja considerable. No obstante, si no cuentan con testers, aseguraos de colaborar bien con el equipo de desarrollo y liberar tiempo para probar de manera adecuada. Cuando esta situación se vuelve demasiado exigente e influye en la calidad del discovery (porque tienen poco tiempo para dedicarle) o la velocidad del equipo (porque los desarrolladores pasan demasiado tiempo en las pruebas), es recomendable sugerir al líder de Producto establecer un verdadero equipo de QA que pueda ayudarles en la optimización y automatización de las pruebas.
Despliegue de funcionalidades
Verificar la Definition of Done
Al igual que la Definition of Ready, la Definition of Done (DoD) es un contrato establecido con el equipo de desarrollo, y reúne en forma de lista el conjunto de criterios que debe respetar una Historia de Usuario para ser considerada como terminada. Su rol es, especialmente, verificar que se haya realizado una revisión de código, que las pruebas de aceptación estén validadas, que la documentación esté actualizada y que el etiquetado esté bien implementado.
La DoD debe permanecer en los hechos, ser realista y ser exhaustiva. No obstante, puede evolucionar para reajustar el nivel de calidad cuando sea necesario. Una vez que sus Historias de Usuario validan la DoD, pueden desplegar las funcionalidades en producción
¿Cuándo organizar una reunión de Go/No Go?
Cuando trabajes en un tema arriesgado que requiere una validación por parte de un equipo específico, o cuando lancéis una nueva funcionalidad que impacta a varios equipos y que requiere una coordinación de las
actividades de lanzamiento (varias puestas en producción sucesivas en el caso de una asociación, formación de equipos en el terreno...), debéis prestar especial atención a la decisión de ponerlo en producción. En este caso, organiza una reunión donde las partes interesadas puedan decidir desplegar o no, y sobre todo, validar las etapas de lanzamiento.
Entregar continua o en release
Cuando el equipo considera que la funcionalidad puede ir a producción, tienen la opción de entregar la funcionalidad inmediatamente a los usuarios o esperar para ofrecer un conjunto de funcionalidades coherentes. Aquí las diferentes aproximaciones:
- La entrega continua: las funcionalidades se ponen en producción en cuanto las Historias de Usuario cumplen con los criterios de la Definition of Done. La ventaja de esta aproximación es que permite entregar las funcionalidades lo más rápido posible para recoger feedback. No obstante, esta aproximación implica un desglose en Historias de Usuario independientes que aportan valor por sí mismas para ser entregadas directamente a los usuarios.
- La creación de release: varias funcionalidades se agrupan para formar un incremento en el Producto coherente para entregar. La release permite entregar un bloque funcional más completo a los usuarios. Esta aproximación se debe favorecer cuando los equipos tienen fuertes dependencias o cuando trabajan en un producto para el cual el nivel de exigencia es alto. Por ejemplo, para una API bancaria, el riesgo de entregar a los usuarios un modo degradado de una funcionalidad sobre la cual se iterará más tarde es demasiado importante. Se preferirá entregar una release más completa que asegure el nivel de calidad y seguridad esperado por los usuarios.
Actividades post-despliegue
Verificar la producción
Una vez realizada la entrega y si el producto lo permite, no dudes en hacer una verificación rápida en producción. Si detectáis un problema o una anomalía, se puede:
- Realizar un rollback volviendo a la versión anterior de la aplicación para restaurar instantáneamente el correcto funcionamiento de su producto, y luego investigar el problema con calma.
- Realizar un hotfix entregando rápidamente una corrección.
Activar las funcionalidades con un feature flag
Un feature flag o feature toggle es una técnica que permite activar o desactivar fácilmente una funcionalidad en producción, sin necesidad de un despliegue específico. Gracias al feature flag, pueden entregar sus funcionalidades en producción y activarlas más tarde o solo para un público objetivo. Esta técnica ofrece numerosas ventajas:
- Ofrecer más flexibilidad al equipo al disociar el despliegue, por un lado, de la disponibilidad de la funcionalidad para los usuarios, por otro.
- Facilitar el rollback en caso de problema, desactivando la funcionalidad mientras se realizan los correctivos necesarios.
- Hacer disponible gradualmente una funcionalidad, activándola para un público limitado antes de hacerla accesible para todos los usuarios.
- Facilitar la gestión de las pruebas de propuestas de valor (capítulo 8) o experimentaciones, activándolas para objetivos específicos en un tiempo limitado.
Nuestros consejos prácticos
- No esperar a que las Historias de Usuario estén terminadas para probar. Probar localmente con los desarrolladores puede ayudar a detectar algunos ajustes muy rápidamente.
- Las pruebas funcionales no son únicamente responsabilidad de los Product Managers, especialmente si no tenéis testers en el equipo. Los desarrolladores pueden realizar pruebas cruzadas durante la revisión del código para verificar la funcionalidad desarrollada por un compañero.
- Asegurar un alto nivel de calidad del producto es un proceso que va más allá de los tests. Cuanto más colaboréis desde el principio de los desarrollos en el refinamiento y la redacción de los criterios de aceptación en el equipo, así como en el respeto de la DoR, más fácilmente validaréis la etapa de tests.
Para saber más: descarga nuestro libro Las Claves del Product Management
Foto de Freepik
