No todos los tipos de pruebas de software son iguales. Algunos escenarios de pruebas requieren incluso diferentes perspectivas para calibrar si el software ha cumplido con la marca. Tal es el caso de las pruebas de aceptación del usuario, que difieren bastante de un enfoque técnico, como las pruebas de integración del sistema.
No hay estándares de la industria para las pruebas de aceptación del usuario (UAT) o las pruebas de integración del sistema (SIT). Con las UAT, las personas que utilizan el sistema o establecen los requisitos del producto realizan las pruebas. Las UAT pueden variar enormemente en función de la experiencia de la persona con la aplicación y la experiencia con las pruebas en sí.
Con las SIT, un equipo de control de calidad evalúa si las aplicaciones -y sus muchos componentes- funcionan como se pretende antes de que llegue al cliente. Las pruebas aisladas, como las pruebas unitarias, a menudo no consiguen detectar los errores que la SIT descubre.
La principal diferencia entre la SIT y la UAT se reduce a sus objetivos de prueba enormemente diferentes y a la experiencia de los probadores. El tiempo es un factor tanto en los escenarios UAT como SIT. Los probadores deben saber cuál es la diferencia entre SIT y UAT, qué aporta cada evaluación a la calidad del software y quién verifica cada prueba. Siga leyendo para saber más sobre estos procesos de prueba.
¿Qué es la UAT?
Con las pruebas de aceptación del usuario, la organización de desarrollo entrega la compilación o el lanzamiento al consumidor objetivo del sistema, al final del ciclo de vida de desarrollo del software (SDLC). Los usuarios finales o el equipo de desarrollo de productos de esa organización realizan las actividades previstas para confirmar o aceptar el sistema como viable. La fase de UAT suele ser uno de los pasos finales de un proyecto de desarrollo de software global.
Algunos tipos de UAT son los siguientes:
- Pruebas alfa y beta. Con las pruebas alfa, los usuarios o grupos de usuarios prueban el software al principio del SDLC para identificar errores durante el desarrollo. Las organizaciones liberan el producto en el entorno del cliente en las pruebas beta, lo que recoge más comentarios y mejora la calidad, pero llega después de que el equipo de software haya hecho más trabajo tras las pruebas alfa.
- Pruebas de caja negra. El usuario no ve el código interno ni los componentes de la aplicación, de donde procede el término caja negra. Los usuarios deben calibrar lo bien que el producto cumple con los requisitos basándose únicamente en su interacción. Las pruebas de caja negra son también un tipo de pruebas funcionales.
- Pruebas de aceptación de contrato. Este tipo de UAT se produce cuando un contrato entre el proveedor y el usuario define los criterios y las especificaciones de un producto. Con las pruebas de aceptación del contrato, el usuario verifica que el software cumple los criterios acordados.
- Pruebas de aceptación operativa. La organización del cliente determina si está preparada para utilizar el software, evaluando criterios como la formación de los empleados, el mantenimiento del software y la forma de gestionar los fallos.
- Pruebas de aceptación de la normativa. También denominadas pruebas de aceptación de conformidad, este proceso verifica que el software satisface las necesidades normativas o de cumplimiento de los usuarios.
Un inconveniente de las UAT es que deja poco tiempo a los usuarios para realizar pruebas antes del lanzamiento del producto. Si los usuarios encuentran defectos, pueden sentirse presionados para aceptar el software tal y como está en lugar de retrasar el proyecto. En algunos casos, los clientes esperan el software durante meses y están ansiosos por recibirlo y empezar a trabajar en él para satisfacer las necesidades del negocio. Esta dinámica presiona a los usuarios para que acepten el software bajo prueba, incluso si los defectos impiden o inhiben la funcionalidad.
Otro inconveniente de las UAT es que los usuarios a menudo no saben cómo hacer pruebas correctamente. Los ingenieros de control de calidad aprenden técnicas que les ayudan a examinar el software. Los usuarios a menudo llegan al teclado sin ningún conocimiento de cómo probar el software – incluso si hay requisitos en el lugar. Esos usuarios son propensos a ejecutar pruebas de camino feliz — no casos de prueba más involucrados o condiciones de prueba interesantes — ya sea debido a la inexperiencia o a la falta de tiempo para llevar a cabo efectivamente diferentes escenarios.
Los usuarios deben tratar de entender la dinámica específica del proyecto y determinar lo que es adaptable y lógico solicitar a los desarrolladores. Si no cree que los usuarios puedan manejar eficazmente la UAT, encargue la tarea a ayuda externa.
¿Qué es la SIT?
Las pruebas de integración del sistema, también llamadas pruebas de integración, evalúan que todos los componentes del software – hardware y software- funcionan como se espera en un sistema completo. Los equipos de control de calidad del software llevan a cabo las SIT, no los usuarios.
Los probadores que evalúan la funcionalidad tal y como se entrega suelen estar preparados para comprobar también la funcionalidad de la aplicación como una solución completa e integrada. La SIT suele ser un proceso de pruebas más técnico que la UAT. Los probadores diseñan y ejecutan la SIT, ya que se han familiarizado con los tipos de defectos comunes en la aplicación a lo largo del SDLC.
La fase SIT precede a la UAT. Debido a que la experiencia técnica entre los usuarios y los probadores varía significativamente, es probable que los dos grupos demográficos encuentren defectos muy diferentes entre UAT y SIT. La SIT a menudo descubre errores que las pruebas unitarias no detectaron, defectos que dependen de un flujo de trabajo o de la interacción entre dos componentes de la aplicación, como el orden secuencial de las operaciones.
Un pequeño solapamiento entre la SIT y la UAT podría ser deseable, como una segunda comprobación de la funcionalidad de la aplicación. Sin embargo, el hecho de que tanto SIT como UAT se produzcan al final del proceso de SDLC, cerca del lanzamiento, es a menudo el único elemento común entre las dos formas de pruebas.