what is acceptance testing
Introducción a las pruebas de aceptación (Parte I):
En esta serie de tutoriales, aprenderá:
- ¿Qué son las pruebas de aceptación?
- Pruebas de aceptación y plan de pruebas
- Estado de las pruebas de aceptación e informes resumidos
- ¿Qué es la prueba de aceptación del usuario (UAT)?
¿Terminó con las pruebas del sistema? ¿Se corrigieron la mayoría de sus errores? ¿Se verifican y cierran los errores? ¿Qué es lo siguiente?
Lo siguiente en la lista es la prueba de aceptación, que es la última fase del proceso de prueba de software. . Esta es la fase donde el cliente decide Ir no ir para el producto y debe seguirse obligatoriamente antes de lanzar el Producto al mercado. Los esfuerzos conjuntos del equipo de desarrollo y de prueba serán recompensados por el cliente al aceptar o rechazar el Producto desarrollado.
Este tutorial único sobre pruebas de aceptación le dará una descripción completa del significado, tipos, usos y varios otros factores involucrados en la prueba de aceptación de una manera simple y fácil para su mejor comprensión.
Lo que vas a aprender:
- ¿Qué son las pruebas de aceptación?
- ¿Por qué pruebas de aceptación?
- Tipos
- ¿Quién realiza las pruebas de aceptación?
- Cualidades de los probadores de aceptación
- Utilizar
- Diferencias entre las pruebas del sistema, las pruebas de aceptación y las pruebas de aceptación del usuario
- Prueba de aceptacion
- Banco de pruebas de aceptación
- Criterios de entrada y salida para AT
- Proceso de prueba de aceptación
- Factores de éxito para esta prueba
- Conclusión
- Lectura recomendada
¿Qué son las pruebas de aceptación?
Una vez el Proceso de prueba del sistema es completado por el equipo de prueba y firmado, todo el Producto / aplicación se entrega al cliente / pocos usuarios de clientes / ambos, para probar su aceptabilidad, es decir, el Producto / aplicación debe ser impecable para cumplir con los requisitos críticos y Principales requisitos comerciales. Además, los flujos de negocios de un extremo a otro se verifican de manera similar a los escenarios en tiempo real.
El entorno similar a la producción será el entorno de prueba para la aceptación de pruebas (generalmente denominado entorno de ensayo, preproducción, conmutación por error, UAT).
Esto es un técnica de prueba de caja negra donde solo se verifica la funcionalidad para garantizar que el producto cumpla con los criterios de aceptación especificados (sin necesidad de conocimientos de diseño / implementación).
¿Por qué pruebas de aceptación?
Aunque la prueba del sistema se ha completado con éxito, el cliente exige la prueba de aceptación. Las pruebas realizadas aquí son repetitivas, ya que se habrían cubierto en Pruebas del sistema.
Entonces, ¿por qué los clientes realizan estas pruebas?
Esto es porque:
- Ganar confianza en el producto que se lanza al mercado.
- Para asegurarse de que el producto esté funcionando como debe hacerlo.
- Asegurar que el producto se ajuste a los estándares actuales del mercado y sea lo suficientemente competitivo con otros productos similares en el mercado.
Tipos
Hay varios tipos de esta prueba.
Algunos de ellos se enumeran a continuación:
# 1) Prueba de aceptación del usuario (UAT)
UAT es evaluar si el Producto está funcionando para el usuario, correctamente para el uso. Los requisitos específicos que los usuarios finales utilizan con bastante frecuencia se seleccionan principalmente con fines de prueba. Esto también se denomina prueba de usuario final.
El término 'Usuario' aquí significa los usuarios finales a los que está destinado el Producto / aplicación y, por lo tanto, las pruebas se realizan desde la perspectiva del usuario final y desde su punto de vista.
=> También Leer: ¿Qué es la prueba de aceptación del usuario (UAT)?
# 2) Prueba de aceptación comercial (BAT)
Esto es para evaluar si el Producto cumple con los objetivos y propósitos comerciales o no.
BAT se enfoca principalmente en los beneficios comerciales (finanzas) que son bastante desafiantes debido a las condiciones cambiantes del mercado / tecnologías avanzadas, por lo que la implementación actual puede tener que sufrir cambios que resultan en presupuestos adicionales.
preguntas y respuestas de la entrevista del desarrollador de red
Incluso el Producto que pasa los requisitos técnicos puede fallar BAT debido a estas razones.
# 3) Prueba de aceptación de contrato (CAT)
Este es un contrato que especifica que una vez que el Producto entre en funcionamiento, dentro de un período predeterminado, se debe realizar la prueba de aceptación y debe pasar todos los casos de uso de aceptación.
El contrato firmado aquí se denomina Acuerdo de Nivel de Servicio (SLA), que incluye los términos en los que se realizará el pago solo si los servicios del Producto cumplen con todos los requisitos, lo que significa que se cumple el contrato.
A veces, este contrato puede suceder antes de que el Producto entre en funcionamiento. Cualquiera de las formas, un contrato debe estar bien definido en términos del período de prueba, áreas de prueba, condiciones sobre problemas encontrados en etapas posteriores, pagos, etc.
# 4) Regulaciones /CumplimientoPrueba de aceptación (RAT)
Esto es para evaluar si el Producto viola las reglas y regulaciones definidas por el gobierno del país donde se lanza. Esto puede no ser intencional, pero tendrá un impacto negativo en el negocio.
Por lo general, el Producto / aplicación desarrollado que está destinado a ser lanzado en todo el mundo, tiene que someterse a RAT, ya que diferentes países / regiones tienen diferentes reglas y regulaciones definidas por sus órganos de gobierno.
Si se viola alguna de las reglas y regulaciones de cualquier país, entonces ese país o la región específica de ese país no podrá usar el Producto y se considerará una falla. Los proveedores del producto serán directamente responsables si el producto se libera aunque haya una infracción.
# 5) Prueba de aceptación operativa (OAT)
Esto es para evaluar la disponibilidad operativa del Producto y es una prueba no funcional. Incluye principalmente pruebas de recuperación, compatibilidad, mantenibilidad, disponibilidad de soporte técnico, confiabilidad, conmutación por error, localización, etc.
OAT principalmente asegura la estabilidad del Producto antes de lanzarlo a producción.
# 6) Prueba Alfa
Esto es para evaluar el Producto en el entorno de desarrollo / prueba por un equipo de probadores especializados, generalmente llamados probadores alfa. Aquí, los comentarios de los probadores y las sugerencias ayudan a mejorar el uso del Producto y también a corregir ciertos errores.
Aquí, las pruebas se realizan de forma controlada.
=> Leer también: ¿Qué son las pruebas alfa?
# 7) Prueba Beta / Prueba de campo
Esto es para evaluar el Producto exponiéndolo a los usuarios finales reales, generalmente llamados probadores beta / usuarios beta, en su entorno. Se recopilan comentarios continuos de los usuarios y se solucionan los problemas. Además, esto ayuda a mejorar / mejorar el Producto para brindar una experiencia de usuario rica.
Las pruebas se realizan de manera incontrolada, lo que significa que un usuario no tiene restricciones sobre la forma en que se utiliza el Producto.
=> Leer también: ¿Qué son las pruebas beta?
Todos estos tipos tienen un objetivo común:
- Asegúrese de ganar / enriquecer la confianza en el producto.
- Asegúrese de que el Producto esté listo para ser utilizado por usuarios reales.
¿Quién realiza las pruebas de aceptación?
Para el tipo Alpha, solo los miembros de la organización (que desarrollaron el Producto) realizan las pruebas. Estos miembros no forman parte directamente del proyecto (jefes de proyecto / clientes potenciales, desarrolladores, probadores). Los equipos de administración, ventas y soporte generalmente realizan las pruebas y brindan comentarios en consecuencia.
Aparte del tipo Alpha, todos los demás tipos de aceptación generalmente los realizan diferentes partes interesadas. Al igual que los clientes, los clientes del cliente, probadores especializados de la organización (no siempre).
También es bueno involucrar a analistas comerciales y expertos en la materia al realizar esta prueba según su tipo.
Cualidades de los probadores de aceptación
Los probadores con las siguientes cualidades están calificados como probadores de aceptación:
- Capacidad para pensar de forma lógica y analítica.
- Buen conocimiento del dominio.
- Capaz de estudiar los productos competitivos en el mercado y analizar los mismos en el producto desarrollado.
- Tener la percepción del usuario final durante la prueba.
- Comprenda la necesidad empresarial de cada requisito y realice las pruebas correspondientes.
Impacto de los problemas encontrados durante esta prueba
Cualquier problema que se encuentre en la fase de prueba de aceptación debe considerarse de alta prioridad y solucionarse de inmediato. Esto también requiere que se realice un análisis de causa raíz en todos y cada uno de los problemas que se encuentren.
El equipo de pruebas juega un papel importante al proporcionar RCA para los problemas de aceptación. Estos también ayudan a determinar la eficiencia con la que se realizan las pruebas.
Además, los problemas válidos en la prueba de aceptación afectarán tanto a las pruebas como a los esfuerzos del equipo de desarrollo en términos de impresión, calificaciones, encuestas de clientes, etc. A veces, si se encuentra alguna ignorancia del equipo de pruebas sobre las validaciones, esto también conduce a escaladas.
Utilizar
Esta prueba es útil desde varios aspectos.
Algunos de los cuales incluyen:
- Para averiguar los problemas que se perdieron durante la fase de prueba funcional.
- Qué tan bien se desarrolla el Producto.
- Un producto es lo que realmente necesitan los clientes.
- Los comentarios / encuestas realizadas ayudan a mejorar el rendimiento del producto y la experiencia del usuario.
- Mejore el proceso seguido teniendo RCA como entrada.
- Minimice o elimine los problemas que surgen del Producto de producción.
Diferencias entre las pruebas del sistema, las pruebas de aceptación y las pruebas de aceptación del usuario
A continuación se muestran las principales diferencias entre estos 3 tipos de pruebas de aceptación.
| Prueba del sistema | Test de aceptación | Pruebas de aceptación del usuario |
|---|---|---|
| Se realizan pruebas positivas y negativas | Generalmente se realizan pruebas positivas | Solo se realizan pruebas positivas |
| Se realizan pruebas de extremo a extremo para verificar si el producto cumple con todos los requisitos especificados | Las pruebas se realizan para verificar si el Producto cumple con los requisitos del cliente para su aceptabilidad. | Las pruebas se realizan para verificar si se cumplen los requisitos de los usuarios finales de aceptabilidad. |
| Un producto se prueba en su conjunto centrándose solo en las necesidades funcionales y no funcionales | El producto se prueba para las necesidades comerciales: aceptabilidad del usuario, objetivos comerciales, reglas y regulaciones, operaciones, etc. | El producto se prueba solo para la aceptabilidad del usuario |
| El equipo de pruebas realiza pruebas del sistema | El cliente, los clientes de los clientes, el evaluador (rara vez), la administración, las ventas, los equipos de soporte realizan pruebas de aceptación según el tipo de prueba realizada | Cliente, cliente de los clientes, probadores (rara vez) realizan pruebas de aceptación del usuario |
| Los casos de prueba se escriben y ejecutan | Las pruebas de aceptación se escriben y ejecutan | Las pruebas de aceptación del usuario se escriben y ejecutan |
| Puede ser funcional y no funcional | Generalmente funcional, pero no funcional en el caso de RAT, OAT, etc. | Solo funcional |
| Solo se utilizan datos de prueba para probar | Los datos de producción / datos en tiempo real se utilizan para realizar pruebas | Los datos en tiempo real / datos de producción se utilizan para realizar pruebas |
| Los problemas encontrados se consideran errores y se corrigen según la gravedad y la prioridad. | Los problemas encontrados marcan el Producto como Fallo y se consideran reparados de inmediato | Los problemas encontrados marcan el Producto como Fallo y se consideran reparados de inmediato |
| Manera controlada de prueba | Puede controlarse o descontrolarse según el tipo de prueba | Manera incontrolada de prueba |
| Pruebas en el entorno de desarrollo | Pruebas en el entorno de desarrollo o el entorno de preproducción o el entorno de producción, según el tipo | Las pruebas están siempre en el entorno de preproducción. |
| Sin suposiciones, pero si alguna se puede comunicar | Sin suposiciones | Sin suposiciones |
Prueba de aceptacion
Al igual que en los casos de prueba de productos, tenemos pruebas de aceptación. Las pruebas de aceptación se derivan de los criterios de aceptación de las historias de usuario. Por lo general, estos son los escenarios que se escriben en el detalle de alto nivel sobre lo que el Producto tiene que hacer en diferentes condiciones.
No ofrece una imagen clara de cómo realizar las pruebas, como en los casos de prueba. Las pruebas de aceptación están escritas por Testers que tienen un control completo del Producto, generalmente Experiencia en la materia. Todas las pruebas escritas son revisadas por un cliente y / o analistas comerciales.
Estas pruebas se ejecutan durante la prueba de aceptación. Junto con las pruebas de aceptación, se debe preparar un documento detallado sobre cualquier configuración a realizar. Debe incluir detalles de cada minuto con capturas de pantalla adecuadas, valores de configuración, condiciones, etc.
Banco de pruebas de aceptación
El banco de pruebas para esta prueba es similar a un banco de pruebas normal, pero es independiente. La plataforma con todo el hardware, software, productos operativos, configuración y configuración de red, configuración y configuración del servidor, configuración y configuración de la base de datos, licencias, complementos, etc., deben configurarse de manera muy similar el entorno de producción.
El banco de pruebas de aceptación es una plataforma / entorno donde se ejecutarán las pruebas de aceptación diseñadas. Antes de entregar el entorno de prueba de aceptación al cliente, es una buena práctica comprobar si existen problemas medioambientales y la estabilidad del Producto.
Si no hay un entorno separado configurado para las pruebas de aceptación, se puede utilizar un entorno de prueba regular para ese propósito. Pero aquí, será complicado ya que los datos de prueba de las pruebas regulares del sistema y los datos en tiempo real de las pruebas de aceptación se mantienen en un solo entorno.
El banco de pruebas de aceptación generalmente se instala del lado del cliente (es decir, en el laboratorio) y tendrá acceso restringido a los equipos de desarrollo y prueba.
Se requerirá que los equipos accedan a este entorno a través de VM / o URL específicamente diseñadas con credenciales de acceso especiales, y se realizará un seguimiento de todo el acceso a esto. No se debe agregar, modificar o eliminar nada en este entorno sin el permiso del cliente, y se le debe notificar de los cambios que se realicen.
Criterios de entrada y salida para AT
Al igual que en cualquier otra fase del STLC, las pruebas de aceptación tienen un conjunto de criterios de entrada y salida que deben estar bien definidos en el Plan de pruebas de aceptación (que se trata en la parte posterior de este tutorial).
Esta es la fase que comienza inmediatamente después de la prueba del sistema y finaliza antes del lanzamiento de producción. Por lo tanto, los criterios de salida de las pruebas del sistema se convierten en parte de los criterios de entrada para AT. De manera similar, los criterios de Salida de AT se vuelven parte de los criterios de Entrada para el Lanzamiento de Producción.
Criterio para entrar
A continuación se detallan las condiciones que deben cumplirse antes de comenzar:
- Los requisitos comerciales deben ser claros y estar disponibles.
- Se debe completar la fase de prueba del sistema y de regresión.
- Todos los errores críticos, mayores y normales deben corregirse y cerrarse (los errores menores que se aceptan principalmente son errores cosméticos que no perturban el uso del producto).
- La lista de problemas conocidos debe prepararse y compartirse con las partes interesadas.
- Se debe configurar el banco de pruebas de aceptación y se debe realizar una verificación de alto nivel para que no haya problemas ambientales.
- Se debe cerrar la fase de prueba del sistema para permitir que el producto pase a la fase AT (generalmente se realiza mediante comunicación por correo electrónico).
Criterio de salida
Hay ciertas condiciones que debe cumplir AT para dejar que el producto entre en producción.
Son los siguientes:
- Deben ejecutarse pruebas de aceptación y todas las pruebas deben Pasar.
- No quedan abiertos defectos críticos / mayores. Todos los defectos deben repararse y verificarse de inmediato.
- AT debe ser firmado por todas las partes interesadas incluidas con Ir no ir Decisión sobre el producto.
Proceso de prueba de aceptación
En Modelo V , La fase AT es paralela a la fase de Requisitos.
El proceso de AT real es como se muestra a continuación:
Análisis de requisitos comerciales
Los requisitos comerciales se analizan haciendo referencia a todos los documentos disponibles dentro del proyecto.
Algunos de los cuales son:
- Especificaciones de requisitos del sistema
- Documento de requisitos comerciales
- Casos de uso
- Diagramas de flujo de trabajo
- Matriz de datos diseñada
Plan de prueba de aceptación del diseño
Hay ciertos elementos que deben documentarse en el Plan de prueba de aceptación.
Echemos un vistazo a algunos de ellos:
- Estrategia y enfoque de pruebas de aceptación.
- Los criterios de entrada y salida deben estar bien definidos.
- El alcance de la TA debe estar bien mencionado y debe cubrir solo los requisitos comerciales.
- El enfoque del diseño de la prueba de aceptación debe detallarse para que cualquiera que escriba pruebas pueda comprender fácilmente la forma en que debe escribirse.
- Se debe mencionar la configuración del banco de pruebas, el cronograma / los plazos de prueba reales.
- Dado que las pruebas las realizan diferentes partes interesadas, se deben mencionar los detalles sobre el error de registro, ya que las partes interesadas pueden no estar al tanto del procedimiento seguido.
Diseñar y revisar pruebas de aceptación
comandos de script de shell de Unix con ejemplos
Las pruebas de aceptación deben estar escritas a nivel de escenario mencionando lo que se debe hacer (no en detalle para incluir cómo hacerlo). Estos deben escribirse solo para las áreas identificadas del alcance de los requisitos comerciales, y todas y cada una de las pruebas deben asignarse a su requisito de referencia.
Todas las pruebas de aceptación escritas deben revisarse para lograr una alta cobertura de los requisitos comerciales.
Esto es para asegurarse de que no se incluyan otras pruebas además del alcance mencionado, de modo que las pruebas se realicen dentro de los plazos programados.
Configuración del banco de pruebas de aceptación
El banco de pruebas debe configurarse de manera similar a un entorno de producción. Se requieren controles de muy alto nivel para confirmar la estabilidad y el uso del medio ambiente. Comparta las credenciales para usar el entorno solo con un interesado que esté realizando esta prueba.
Configuración de datos de prueba de aceptación
Los datos de producción se deben preparar / completar como datos de prueba en los sistemas. Además, debe haber un documento detallado de tal manera que los datos tengan que usarse para las pruebas.
No tenga los datos de prueba como TestName1, TestCity1, etc., en su lugar tenga a Albert, Mexico, etc. Esto le brinda una rica experiencia de datos en tiempo real y las pruebas estarán al día.
Ejecución de la prueba de aceptación
Las pruebas de aceptación diseñadas deben ejecutarse en el entorno en este paso. Idealmente, todas las pruebas deberían pasar en el primer intento. No debe haber errores funcionales que surjan de las pruebas de aceptación, si los hay, entonces deben informarse con una alta prioridad para su corrección.
Nuevamente, los errores corregidos deben verificarse y cerrarse como una tarea de alta prioridad. El informe de ejecución de la prueba debe compartirse a diario.
Los errores registrados en esta fase deben discutirse en una reunión de clasificación de errores y deben someterse al procedimiento de Análisis de causa raíz. Este es el único punto en el que las pruebas de aceptación evalúan si el producto cumple o no todos los requisitos comerciales.
Decisión comercial
Sale un Ir no ir decisión para el lanzamiento del producto en Producción. Vamos La decisión llevará el producto adelante para ser lanzado al mercado. No vayas La decisión marca el producto como Fallo.
Algunos factores de la decisión de no ir:
- Mala calidad del producto.
- Demasiados errores funcionales abiertos.
- Desviación de los requisitos comerciales.
- No está a la altura de los estándares del mercado y necesita mejoras para adaptarse a los estándares del mercado actual.
Factores de éxito para esta prueba
Una vez planificada esta prueba, prepare una lista de verificación que aumente la tasa de éxito de la misma. Hay algunos elementos de acción que deben seguirse antes de que comience la prueba de aceptación.
Son:
- Tenga un alcance bien definido y asegúrese de que exista una necesidad comercial para el alcance identificado para esta prueba.
- Ejecute pruebas de aceptación en la propia fase de prueba del sistema al menos una vez.
- Realizar extensos pruebas ad-hoc para cada uno de los escenarios de prueba de aceptación.
Conclusión
En pocas palabras, las pruebas de aceptación ayudan a determinar la eficiencia de los equipos de desarrollo y prueba.
Existen varias herramientas para llevar a cabo esta actividad, pero por lo general, se prefiere que se haga de forma manual, ya que hay una participación de los usuarios reales y diferentes partes interesadas que no tienen antecedentes técnicos, y puede que no sea factible para ellos.
¿Que sigue?
En nuestro próximo tutorial, pasaremos el cursor sobre los siguientes temas:
- Ejemplos de criterios de prueba de aceptación.
- Cómo redactar un plan de prueba de aceptación.
- Una plantilla adecuada para la redacción de pruebas de aceptación.
- Cómo escribir pruebas de aceptación con ejemplos.
- Identificación de escenarios de prueba de aceptación.
- Informes de prueba de aceptación.
- Pruebas de aceptación en desarrollo ágil y basado en pruebas.
SIGUIENTE Tutorial # 2: Plan de prueba de aceptación
¿Ha realizado pruebas de aceptación? ¡Estaremos encantados de escuchar sus experiencias!
Lectura recomendada
- Pruebas alfa y beta (una guía completa)
- ¿Qué es la prueba de aceptación del usuario (UAT): una guía completa?
- Guía completa de pruebas de verificación de compilación (pruebas de BVT)
- Pruebas funcionales versus pruebas no funcionales
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- Tipos de pruebas de software: diferentes tipos de pruebas con detalles
- Tutorial de pruebas de almacenamiento de datos de pruebas ETL (una guía completa)
- Guía de pruebas de seguridad de aplicaciones web