Asegurar la Calidad de un Producto: Pruebas UAT, Criterios de Aceptación y DoD
El aseguramiento de la calidad - Quality Assurance (QA)- es una parte importante (y fundamental) en el desarrollo de software. Un enfoque incorrecto genera en cualquier equipo muchos dolores de cabeza provocado por la deuda técnica, y por lo tanto mas tiempo de los equipos en reparar errores y menos dinero para la organización. En tecnologia las ineficiencias se pagan.
Scrum dice que el equipo aporta todas las habilidades necesarias para lograr los objetivos del producto. Es por eso que, equivocadamente, se asocia "calidad" solamente al equipo tecnico. En organizaciones ágiles, todos los miembros del equipo deben ser responsables del delivery y asegurar que el producto alcance los estándares de calidad establecidos y por sobre todas las cosas, cumpla con las expectativas del usuario final. En resumen, el equipo de desarrollo es responsable de todas las actividades necesarias para crear un producto y el control de calidad es una actividad dentro del equipo, no un rol.
Cuando comencé mis pasos en Producto los términos "Pruebas UAT, Criterios de Aceptación y DoD" me resultaban confusos ya que no venia con formación técnica. En este articulo voy a explicar qué significa cada uno y cómo se relacionan entre ellos.
¿Qué es la prueba de aceptación del usuario (UAT) y en qué se diferencia con QA?
El Quality Assurance (QA) forma parte de las actividades de gestión de la calidad de una organización. La ISO 9000 define Quality Assurance como la parte de la gestión de la calidad centrada en asegurar que se cumplan los requerimientos de calidad. La diferencia central es que el Quality Assurance tiene un enfoque más hacia los procesos y el Quality Control (Control de Calidad) hacia el producto final. Las UAT se encuentran dentro de el proceso de QA.
La diferencia central es que el Quality Assurance tiene un enfoque más hacia los procesos y el Quality Control (Control de Calidad) hacia el producto final.
En QA, es importante distinguir entre verificación y validación .
Fuente: https://www.altexsoft.com/
La verificación se refiere a los procesos generales de control de calidad destinados a probar los aspectos técnicos de un producto para garantizar que realmente funcione. Las actividades en esta etapa son: System testing, Unit testing, Integration testing.
La validación (o prueba de aceptación del usuario (UAT)) se lleva a cabo para asegurar de que el producto se corresponde con los requisitos funcionales y puede ser utilizado por el usuario o dicho de otra manera, si es el adecuado para los usuarios finales. Tiene otros nombres, por ejemplo, prueba de usuario final, operación, aplicación, prueba beta o validación , pero describen lo mismo.
Esto permite que el equipo de desarrollo solucione la mayoría de los problemas de usabilidad, errores y problemas inesperados relacionados con la funcionalidad, el diseño del sistema, los requisitos comerciales, etc.
Fuente: Usersnap
A su vez, la actividad de validación se puede dividir en dos tipos de pruebas.
La prueba alfa es la etapa inicial de la prueba de aceptación, normalmente realizada por los testers, para garantizar que el producto funcione correctamente y cumpla con los requisitos comerciales. Las versiones alfa suelen ser inestables y no tienen todas las características o funcionalidades que tendrá el producto final. Se puede considerar que es un prototipo experimental. Por lo general las UAT son realizadas contra un prototipo desarrollado rápidamente y con poco coste para poder experimentar con él. De esta forma si las pruebas alfa fallan no hemos desperdiciado mucho tiempo ni dinero. Una vez que las pruebas alfa se completan, se aprovecha todo lo que aprendido sobre el problema para el desarrollo de la versión final.
La prueba beta, el segundo tipo de prueba de aceptación, tiene como objetivo cumplir con los criterios de aceptación del usuario.
Criterios de Aceptación
Los criterios de aceptación son una parte fundamental en establecer alcance esperado de una historia. Dentro de las 3C's de una historia de usuario se encuentra justamente la "Confirmación" la cual es clave para saber que alcanzamos el objetivo de lo "conversado" por la "tarjeta". En estos criterios buscamos clarificar como debe y como NO debe comportarse el producto. Una user story nos indica la acción que quiere hacer el usuario, el requerimiento funcional de qué manera el software provee esa funcionalidad y el criterio de aceptacion cómo o qué deberia suceder cuando se accione la funcionalidad.
Pueden ser de tipo:
Funcionales (los más usuales), indican comportamiento del sistema
No- funcionales, en los cuales indicamos características de diseño, técnicos, etc.
Criterio de Performance: podemos indicar tiempos de respuesta o de consumo de recursos.
Veamos un ejemplo con una user story:
"Como usuario QUIERO poder cancelar una reservación realizada por mi"
Criterio de aceptación
Verificar que solo pueda cancelar reservas hechas por el mismo usuario
De acuerdo al tipo de usuario puede tener un recargo
Se debe enviar un mail de confirmación.
Se debe confirmar la recepción por parte del proveedor que la reserva está cancelada. Caso contrario indicar al usuario que intente más tarde o contacte al servicio de posventa.
Definición de Hecho (DoD)
La definición de hecho (DoD - Definition of Done) es un acuerdo realizado por el equipo para validar cuando una historia puede considerarse completada, evitando cuestionamientos posteriores y pudiendo planificar claramente sobre qué estará “hecho" y cuáles son las actividades y entregables abarcados en la historia.
Es importante destacar que esto no hace referencia solo a la funcionalidad entregada en si misma sino también a la calidad e items asociados requeridos para terminarlo: puede verse como una lista de actividades que completamos por defecto al hacer una historia (Codificación. Prueba unitaria, Generación de Casos de prueba, actualización de documentos, etc.). Estas actividades deben entenderse como de valor para los entregables (descartando toda actividad que no lo hace) y ser conocidas por el Product Owner y el Equipo.
El DoD es la manera en que el equipo considera que puede garantizar calidad y sustentabilidad de sus entregas.
Fuente: https://www.scrum.org/resources/blog/como-diferenciar-la-definicion-de-done-y-criterio-de-aceptacion
En la visión industrialista, el proceso de creación se centra en "construir" la mayor cantidad de unidades en el menor tiempo posible, teniendo una mirada exclusivamente en la producción o salida (output). Esto es sinónimo a "mientras más, mejor". Si hablamos de Producto digital, "construir" significa entregar código en producción. En muchas organizaciones ágiles ocurre lo llamado "miopia de producto": hacer foco en poner en producción la mayor cantidad de funcionalidades (teniendo como concepto la idea "industrialista") con la lógica de cuanto mayor cantidad de features o historias implementadas. equivale a tener software de "calidad" para el usuario.
En Product Management esto nos debe hacer ruido, ya que nuestro foco debe ser lograr el equilibrio entre el time-to-market y una correcta QA para tener un Producto saludable, con el mayor impacto posible, creando valor hacia al cliente y con el menor esfuerzo. El terminar items del Backlog genera una sensación de avance y satisfacción, pero si acumulamos deuda tecnica y no estamos beneficiando al usuario o negocio estamos destinando erróneamente los recursos del equipo.
