Pruebas de aceptación de software según el ISTQB

En la Ingeniería del software, las pruebas de aceptación se realizan para establecer el grado de confianza en un sistema, partes del mismo o en sus características no funcionales.

La confianza en el sistema estará determinada por su grado de adherencia a las necesidades, requerimientos y procesos de negocio solicitados por el usuario o cliente. Es en función a estos que el usuario debe decidir si acepta o no el sistema que le está siendo entregado.

Por lo tanto, las pruebas de aceptación suelen ser responsabilidad de los clientes o usuarios del sistema. Otros interesados del proyecto pueden involucrarse también.

En este artículo te presentamos los diversos aspectos que definen que son las pruebas de aceptación de software, incluyendo a partir de que se define, sobre qué aspectos se realizan y cuáles son las clases de pruebas de aceptación.

¿Que es el Testing de aceptación?

En Ingeniería y sus diversas disciplinas, el Testing de aceptación se realiza para determinar si los requerimientos de una especificación o contrato han sido cumplidos.

En la Ingeniería de sistemas, las pruebas de aceptación de software implican pruebas de caja negra antes de su entrega definitiva.

Por su parte, el Internationa Software Testing Qualification Board (ISTQB) define la “Aceptación” como: Pruebas formales con respecto a las necesidades del usuario, requerimientos y procesos de negocio, realizadas para determinar si un sistema satisface los criterios de aceptación que permitan que el usuario, cliente u otra entidad autorizada pueda determinar si acepta o no el sistema.

Las pruebas de aceptación a menudo también se les denominan pruebas de aceptación de usuario (UAT), pruebas de usuario final, pruebas de aceptación operacional o pruebas de campo.

Estas pruebas son fundamentales para asegurar el éxito de la implementación final de un proyecto de ingeniería de software, por lo cual deben incluirse obligatoriamente en el plan de pruebas de software.

¿Cuál es la base para definir las pruebas de aceptación de software?

Según los estándares establecidos por el ISTQB, las pruebas de aceptación de software son diseñadas a partir de:

Requerimientos del usuario.

Requerimientos de sistema.

Casos de uso.

Procesos de negocio.

Reportes de análisis de riesgo.

Cursos de Software Testing

Curso Introducción al Testing de Software para principantes

¿Estás trabajando en el área de pruebas de software y te gustaría ampliar tu formación?

Te recomendamos los Cursos de Software Testing de Udemy.

Introducción al Testing de Software, pruebas de webservices con SoapUI, automatización de pruebas con Selenium y muchos más.

También Visita nuestra página de Recursos en Pruebas de Software

¿Que se valida con las pruebas de aceptación de software?

El ISTQB establece que los siguientes elementos pueden ser sujeto de pruebas de aceptación de software.

Los procesos de negocio de sistemas que ya han sido integrados.

Procesos operacionales y de mantenimiento.

Procedimientos de usuario.

Formularios.

Reportes.

Datos de configuración.

¿Cuando se realizan las pruebas de aceptación de sistema?

Las pruebas de aceptación pueden servir para evaluar el grado en que el sistema está listo para ser implementado y usado, aunque no necesariamente es el último nivel del Testing. Por ejemplo, después de las pruebas de aceptación podría estar establecida una prueba de gran escala de integración del sistema.

No necesariamente se limitan a la fase final de integración del sistema, sino que pueden realizarse en distintas etapas del ciclo de vida, por ejemplo:

Si uno de los componentes del nuevo sistema, es un paquete de software comercial, las pruebas de aceptación de este pueden realizarse tan pronto sea instalado e integrado.

La prueba de aceptación de usabilidad (un tipo de prueba no funcional de software) de un determinado componente se pueden realizar durante las pruebas de dicho componente.

La prueba de aceptación de una nueva mejora de funcionalidad se puede realizar antes de la prueba de sistema.

El Plan de pruebas de software del proyecto debe especificar en cuales partes se realizaran pruebas de aceptación de sistema, sobre partes del software o integración completa.

Clases de pruebas de aceptación de software

Las pruebas de aceptación pueden ser de diversos tipos, a saber:

Pruebas de aceptación de usuario (UAT)

Designed by Freepik

Las pruebas de aceptacion de usuario (User Acceptance Testing o Pruebas UAT) Se enfocan en verificar si el sistema es “apto para el uso”. Se diseñan principalmente a partir de las especificaciones de requerimientos, casos de uso y de los procesos de negocio definidos.

Los usuarios y clientes suelen involucrarse en la ejecución de las pruebas de aceptación de software, siendo esto un mecanismo muy útil para ganar su confianza en el nuevo sistema o funcionalidad.

Sin embargo, para que esta premisa se pueda cumplir, deben presentarse muy pocas o ninguna incidencia (bug) durante las pruebas de aceptación, pues de no ser así, lejos de crear confianza más bien podría tener el efecto contrario (desconfianza en el nuevo sistema).

Dentro de las buenas prácticas de las pruebas de usuario, existen tipos de pruebas de caja negra que se adaptan perfectamente a los objetivos de las pruebas de aceptación de usuario, como lo son las de tablas de decisión y casos de uso.

Casos de prueba que debe incluir la aceptación de usuario

Con frecuencia, el diseño de casos de pruebas de aceptación de usuario es un subconjunto de los casos de prueba usados en las pruebas funcionales de componente y pruebas de integración.

El subconjunto se define buscando incluir los principales escenarios de ejecución de la aplicación.

Dado que el objetivo final de la prueba de aceptación es ganar la confianza del usuario, es recomendable incluir los casos de prueba que él defina dentro de las pruebas de aceptación. Para lo cual se le puede enviar una copia del diseño de casos de prueba y pedir su opinión.

Si bien puede ocurrir que en la sesión de aceptación de software, el usuario pueda definir casos de prueba adicionales, debe hacerse todo lo posible que estos casos sean identificados de manera temprana, preferiblemente mucho antes de llegar a la sesión de aceptación.

Pruebas de aceptación operacional

Comprende la aceptación del nuevo sistema o funcionalidad por parte de los administradores, es decir el área de operaciones de informática de la organización.

Entre los aspectos a validar pueden incluirse:

Pruebas de respaldo y recuperación.

Recuperación ante desastres.

Gestión de cuentas de usuario y control de acceso al sistema.

Tareas de mantenimiento.

Tareas de carga y migración de datos.

Revisiones periódicas de vulnerabilidades de seguridad.

Las pruebas de aceptación operacional suelen contemplar tipos de pruebas no funcionales, sobre características no funcionales como el desempeño, mantenibilidad, capacidad de recuperación ante errores, resistencia, entre otras.

Pruebas de aceptación de contratos y regulaciones

Designed by Freepik

Cuando se haya firmado un contrato para desarrollar software a la medida, por ejemplo entre una empresa cliente y un integrador de software, pueden definirse pruebas de aceptación en función de las cláusulas de dicho contrato.

Las pruebas de aceptación de regulaciones se realizan verificando que la funcionalidad del sistema cumple con dichas regulaciones, tales como las definidas por el gobierno, las leyes o estándares de seguridad.

Pruebas alfa o beta (Pruebas de campo)

Los desarrolladores de software comercial (de paquete), a menudo necesitan obtener feedback de clientes existentes o potenciales de su mercado antes de sacar a la venta el producto.

Las pruebas Alfa son realizadas por la misma organización desarrolladora del software, pero no por el equipo de desarrollo (Por ejemplo un equipo de pruebas de software).

Las pruebas Beta son realizadas por clientes existen o potenciales en sus propias instalaciones. A estas pruebas también se les conoce como pruebas de campo.

Las pruebas de aceptación no son para identificar incidencias

El encontrar defectos (bugs) no es el enfoque principal de las pruebas de aceptación, de hecho, deben evitarse a toda costa, pues además de significar que se ha perdido buena parte del trabajo en la fase de análisis de requerimientos, afectan negativamente la confianza del usuario.

Como buena práctica, el Analista de pruebas (Tester) debe ejecutar pruebas de componente y pruebas de integración sobre áreas que se determine sean de alto riesgo, para favorecer una identificación temprana de los posibles errores. Esto en lugar de esperar que sean las pruebas de aceptación las que identifiquen defectos de alto impacto.

¿Y qué opinas tú?

¿Que buenas prácticas de pruebas de aceptación de software recomendarías?, en tu organización, ¿sólo realizas pruebas de aceptación funcionales (de usuario) ? ¿También realizas pruebas de aceptación operativas de las características no funcionales?

¿Buscas más información de desarrollo y pruebas de software?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de metodologías de desarrollo y pruebas de software?, entonces presiona "suscríbete" a continuación.

También puedes seguirnos vía Twitter, Facebook o Linkedin: