Pruebas de aceptación: el qué y el por qué
- 10 mins read
-
By
Marjan Venema
- Updated on abril 26, 2024
Navigate to
Pruebas de Aceptación: El Qué y Porqué + los tipos que hay que conocer
Las pruebas de aceptación consisten en descubrir que el software que ha creado no es lo que el cliente y los usuarios esperaban. ¿No es así?
Hace un par de décadas, esto ocurría con bastante frecuencia debido al largo tiempo que transcurría desde que se especificaban los requisitos.
Las prácticas ágiles han hecho mucho para cerrar la brecha. Pero incluso cuando su adopción de Agile es de primera categoría, sigue siendo crucial tener pruebas de aceptación en su arsenal porque implica más que la verificación de los requisitos.
Este artículo le explicará lo que necesita saber para ponerlo en práctica de forma eficaz y asegurarse de que ofrece un software que sus clientes y usuarios finales estarán encantados de utilizar.
¿Qué son las Pruebas de Aceptación y por qué son Importantes?
Históricamente, como usuario, sólo se veía por primera vez un nuevo producto de software mucho después de que la mayoría de los desarrolladores y probadores se hubieran ido.
Debido a ese largo intervalo, las pruebas de aceptación eran cruciales para determinar si el software cumplía las expectativas y era viable para sus usuarios, es decir, si era aceptable y apto para salir al mercado. Sólo si lo era, se añadía a un entorno de producción y se utilizaba en el curso normal de la actividad empresarial.
En el desarrollo ágil, las pruebas de aceptación forman parte del proceso y no son una ocurrencia tardía. Sin embargo, la intención sigue siendo la misma: verificar que el software cumple las expectativas desde el punto de vista del cliente y de los usuarios finales.
Cuando trabaje con un equipo ágil maduro, ni siquiera verá la diferencia entre las especificaciones y la verificación. Colabore con el equipo para crear historias de usuario y sus criterios de aceptación. Y usted o ellos escribirán estos criterios de aceptación en una notación que las herramientas pueden convertir en pruebas de aceptación automatizadas.
La enorme ventaja es que el producto en desarrollo está siempre en un estado aceptable — se acabaron las sorpresas desagradables..
¿En qué se diferencia de las pruebas funcionales y las pruebas del sistema?
Las pruebas funcionales son el antiguo nombre de las pruebas de aceptación. El nombre cambió para reflejar mejor la intención de las pruebas.
Ahora se utiliza el término prueba funcional para distinguirla de la prueba no funcional, es decir, la verificación de los requisitos no funcionales (más información al respecto en la siguiente sección).
La diferencia entre las pruebas de aceptación y las del sistema radica en el punto de vista que se adopte. Con las pruebas del sistema, se verifica que el software se comporta como se espera de acuerdo con la forma en que los desarrolladores interpretaron y entendieron los requisitos.
Tipos de Criterios de Aceptación
Para realizar una prueba de aceptación y decidir si se acepta el software, se necesitan criterios claros. Son los llamados criterios de aceptación.
Los criterios de aceptación funcional indican cómo debe comportarse el software para ayudar a los usuarios a realizar su trabajo. Se refieren a las funciones, o características, que ofrece el software.
Los criterios de aceptación no funcionales especifican los requisitos para todo lo demás. Se refieren a cómo el software hace lo que hace: aspectos como la accesibilidad, la facilidad de uso, las garantías de seguridad y privacidad, la velocidad, la fiabilidad y muchos, muchos más.
Tipos de Pruebas de Aceptación
La prueba de aceptación del usuario es lo que generalmente se piensa cuando se oye el término prueba de aceptación. Pero hay mucho más en las pruebas de aceptación que verificar que se cumplen las expectativas de los usuarios.
Pruebas de Aceptación del Usuario (UAT)
Durante la UAT, el usuario se somete a un producto de software para asegurarse de que satisface sus expectativas como usuario y de que le resulta factible. En otras palabras, que le ayude a hacer su trabajo y le proporcione los beneficios que se propuso obtener.
En los equipos ágiles maduros y en los que utilizan CI/CD, las pruebas de aceptación (automatizadas) combinan las pruebas de aceptación del usuario y las pruebas del sistema.
La UAT se mantiene centrada en el usuario gracias a la estrecha colaboración entre los usuarios finales y el equipo de desarrollo a la hora de especificar los criterios de aceptación para cada historia de usuario desarrollada. El equipo de desarrollo los utiliza para crear casos de prueba automatizados que se ejecutan cada vez que se realiza una compilación de integración.
Pruebas de Aceptación Operativa (OAT)
Las pruebas de aceptación operativa se utilizan para evaluar si se puede ejecutar y administrar correctamente un sistema de software. Las OAT también se denominan Pruebas de Disponibilidad Operativa (ORT) o Pruebas de Disponibilidad y Aseguramiento de las Operaciones (OR&A).
Durante la OAT, se examinará todo lo que se necesita para que un sistema de software funcione sin problemas: su seguridad, su escalabilidad, su velocidad y rendimiento, la degradación gradual bajo cargas máximas, etc. También se examinará su capacidad de recuperación ante fallos, sus procedimientos de copia de seguridad y restauración, el equilibrio de la carga, etc.
En resumen, la OAT es el principal tipo de prueba de aceptación para todos los requisitos no funcionales. Las únicas pruebas funcionales que usted realizaría se refieren a las funciones que necesita para ejecutar y verificar estos requisitos no funcionales.
Gobernanza y Cumplimiento, o Pruebas de Aceptación de la Normativa
Las pruebas de aceptación reglamentarias se llevan a cabo cuando el campo para el que se utiliza el software está regulado de alguna forma.
El primer ejemplo que se me viene a la mente es el de los programas informáticos con fines médicos. Encontrará otros ejemplos en la aviación, la automoción, el petróleo y el gas, el transporte marítimo, la agricultura y la pesca. Apenas queda un sector en el que no haya que lidiar con normas y reglamentos.
Cuando se realizan pruebas de conformidad o reglamentarias, se verifica que el software cumple con las normas y reglamentos aplicables. Pueden ser requisitos funcionales, pero a menudo son no funcionales. Piense, por ejemplo, en las pistas de auditoría necesarias para saber quién actualizó qué y cuándo.
Pruebas de Aceptación Alfa y Beta
Las pruebas de aceptación Alfa y Beta son prácticas que permiten obtener los primeros comentarios de un número limitado de usuarios finales y clientes, o incluso de los clientes de éstos.
El objetivo es recopilar información sobre el uso en la vida real para solucionar cualquier problema, como un comportamiento incorrecto o incómodo, antes de lanzar el software al público en general.
Las pruebas de aceptación Alfa también se conocen como pruebas de aceptación interna. Y las pruebas de aceptación Beta también se conocen como pruebas de aceptación externas o de campo.
Ambas son formas informales de pruebas de aceptación del usuario. Los probadores alfa o beta obtienen un acceso temprano a las nuevas funciones a cambio de sus comentarios. No tienen voto en la decisión de salir al mercado y no ejecutan ninguno de los casos de prueba.
Los probadores alfa suelen ser usuarios internos y quizá algunos clientes (potenciales) selectos. A veces, los equipos de pruebas independientes se encargan de las pruebas alfa.
Las pruebas beta siguen a la fase alfa. La diferencia es que se deja entrar a (muchos) más usuarios finales externos.
Pruebas de Aceptación Contractual o por Contrato
Un contrato de software suele incluir cláusulas sobre el tiempo que tiene el cliente después de la entrega para notificar a la empresa de software los problemas que debe resolver como parte del acuerdo. Un cliente tendrá que pagar por separado para resolver los problemas que no notificó durante el «periodo de aceptación».
Como tal, es más una razón para hacer pruebas de aceptación que un tipo de prueba. Sin embargo, un contrato puede incluir los criterios de aceptación que usted definió al negociar su acuerdo con un proveedor de software. Si éstos no se incluyeron en la historia de usuario o en los criterios de aceptación no funcionales, habría que hacer pruebas específicas del contrato para verificarlos.
¿Cuándo se Realizan las Pruebas de Aceptación?
Src: Usersnap
Se ejecutan pruebas de aceptación formales como la prueba final antes de que el nuevo software entre en acción.
Sin embargo, cuando se practica el desarrollo basado en CI/CD o en el tronco con cambios de funciones, la «puesta en marcha» es cuando se activa el interruptor (el cambio de funciones) para que una función esté disponible para todo el mundo.
Así que, incluso entonces, la idea sigue siendo la misma. Las pruebas de aceptación deben ser satisfactorias antes de la puesta en marcha.
Cómo Realizar Pruebas de Aceptación de Usuarios en 5 Sencillos Pasos
Las pruebas de aceptación informan de la decisión de poner en marcha un producto o función. Requiere un plan de pruebas exhaustivo y una ejecución diligente.
Los pasos para realizar una prueba de aceptación como actividad independiente son:
Recoger los Criterios de Aceptación de las historias de usuario que están listas para entrar en funcionamiento.
-
Si sus historias de usuario aún no tienen criterios de aceptación, créelos. Hágalo en colaboración con los profesionales de la empresa, los probadores y los desarrolladores. Consulta la sección «Los Three Amigos como idea central del desarrollo guiado por el comportamiento» en Behaviour Driven Development para saber por qué.
Tomando los Criterios de Aceptación como entrada, crear al menos un caso de prueba para cada uno.
-
Describa los datos y la situación que necesita como punto de partida.
-
Describa las acciones precisas que debe realizar el usuario desde ese punto de partida, incluidos los datos que debe introducir.
-
Describa el comportamiento esperado del programa informático, incluidos los datos fácticos que debe mostrar en respuesta a las acciones del usuario.
Prepare un entorno de prueba instalando el software y reuniendo los datos que necesita para todos los casos de prueba.
Ejecute los casos de prueba.
-
Diagnosticar los fallos: determinar si se trata de un problema con el caso de prueba o con el software. Solucionar los problemas de los casos de prueba y volver a ejecutarlos. Informar de los problemas con el software y volver a ejecutarlo cuando se haya solucionado.
Cuando todos los casos de prueba tienen éxito, firmar la prueba de aceptación.
Aunque ya no sea una actividad independiente, deberá seguir estos pasos. Simplemente formarán parte de otras actividades de desarrollo. Por ejemplo, crearía criterios de aceptación como parte de la recopilación de requisitos o la definición de historias de usuario.
Cerrar la Brecha entre lo que se quiere y lo que se obtiene
Felicitaciones para usted. Ha aprendido lo que son las pruebas de aceptación. En realidad, ha aprendido mucho más.
Así que, estoy seguro de que está conmigo cuando digo que las pruebas de aceptación son una parte esencial de cualquier proceso de desarrollo de software.
Ahora también sabrá que puede evitar las interpretaciones erróneas que conducen a obtener lo que no quería decir adoptando un enfoque de prueba primero como BDD. O al menos creando primero los criterios de aceptación para las historias de usuario y dejando que informen tanto al desarrollo como a las pruebas de control de calidad.
Así que dé el primer paso – cree criterios de aceptación para cada historia de usuario que pretenda desarrollar – y crezca a partir de ahí.
