Respuesta.

El analista de negocios juega un papel crucial en la etapa de pruebas del producto o solución. Su tarea es asegurarse de que la solución implementada cumpla con los requisitos empresariales y se alcancen los objetivos del proyecto. Para ello él:

1. Prepara los escenarios de prueba (criterios de aceptación): generalmente en la etapa de requisitos, el analista ya formula los criterios de aceptación, que luego se utilizan para elaborar los casos de prueba.
2. Participa en la UAT (Pruebas de Aceptación por el Usuario): el analista de negocios asiste a reuniones, ayuda a los usuarios y testadores a entender qué y cómo debería funcionar, recoge retroalimentación.
3. Documenta defectos y discrepancias: informa rápidamente al equipo sobre errores encontrados durante el proceso de prueba.
4. Mantiene la comunicación entre el equipo de pruebas, desarrolladores y el cliente empresarial: actúa como traductor entre el negocio y los especialistas técnicos.

Características clave:

• Formulación de criterios de aceptación en etapas tempranas
• Acto de participación directa en pruebas y verificaciones
• Enfoque en el valor empresarial, no solo en aspectos técnicos

Preguntas capciosas.

¿Está obligado el analista de negocios a crear todos los casos de prueba por sí mismo?

No, los casos de prueba generalmente los elabora el equipo de testers (QA), y el analista formula los criterios de aceptación y ayuda a descomponerlos.

¿Puede el analista retirarse completamente del proyecto después de pasar los requisitos a los desarrolladores?

No, su participación es necesaria hasta el final para garantizar que la solución cumpla con las expectativas del negocio.

¿Debería el analista corregir los requisitos después de las pruebas?

Sí, si durante las pruebas se identifican problemas o malentendidos, los requisitos deben ser aclarados y documentados.

Errores comunes y anti-patrones

• La falta de participación del BA en las pruebas, lo que lleva a una discrepancia entre las expectativas del negocio y el producto final
• Ausencia de criterios de aceptación previamente definidos
• Comunicación insuficiente con QA o el negocio

Ejemplo de la vida real

Caso negativo: El analista entregó la tarea a los desarrolladores, no participó en las pruebas, los requisitos eran incompletos. Ventajas: Finalización rápida del trabajo "en papel" Desventajas: La solución no resolvía el problema empresarial, se requirieron grandes rehacer.

Caso positivo: El analista de negocios estuvo presente en las pruebas, priorizó los criterios de aceptación, aclaró los requisitos de manera oportuna. Ventajas: Minimización de malentendidos, cumplimiento de la solución con las expectativas del negocio Desventajas: Mayor ocupación del BA en la etapa de pruebas de aceptación