En mi organización anterior había una desconexión entre las Operaciones Comerciales y TI que siempre impactaba en el derivable final.
Por alguna razón, la intención comercial no se representó con precisión en el producto final. A pesar de que revisamos el Business Case una y otra vez, siempre faltaba una funcionalidad o no funcionaba como se esperaba. Teníamos evaluadores de control de calidad en el equipo de desarrollo, pero no se llevó a cabo UAT en el extremo operativo. Así que tengo algunas preguntas de las cuales me gustaría su apoyo para evitar este problema en el futuro,
Este es un problema común, que me he encontrado en varias organizaciones.
Las empresas pueden tener la expectativa de que el control de calidad pueda garantizar que el sistema satisfaga sus necesidades. Sin embargo, el control de calidad trabajará con las mismas especificaciones de requisitos que el desarrollo. El control de calidad puede garantizar que el sistema cumpla con las especificaciones. Esto no es lo mismo que asegurar que los requisitos cumplan con las necesidades del negocio.
UAT debería ser un proceso completamente diferente. Es verificar que los requisitos implementados cumplan con las necesidades del negocio. Si considera que esto es una actividad de control de calidad, entonces necesita dos controles de calidad con dos equipos diferentes. Después de la entrega no es el momento de identificar las variaciones entre las especificaciones y las necesidades comerciales.
Las pruebas de usabilidad pueden caer en el área gris entre UAT y QA. El control de calidad debe manejar aquellas pruebas que requieren un usuario nuevo (recurso externo) cada vez. UAT puede manejar casos en los que los usuarios comerciales aplican el sistema a su propósito específico. Los usuarios de pruebas UAT pueden estar involucrados en más de un ciclo de prueba.
UAT es un rol comercial para garantizar que el sistema, tal como se construyó, realmente cumpla con los requisitos comerciales. Cuanto antes pueda hacer que el equipo de negocios pruebe que la aplicación satisface sus necesidades, mejor. El negocio anterior revisa el sistema, los problemas anteriores se pueden identificar.
Involucrar a las empresas en UAT tiende a ser difícil. He encontrado que este es un problema bastante común. Esto retrasará la detección de variaciones entre las especificaciones y las necesidades comerciales. La participación empresarial a lo largo del proceso de desarrollo debería resultar en una detección más temprana.
Las empresas también pueden querer pasar la culpa al retirarse del proyecto después de proporcionar los requisitos. Evitar el juego de la culpa e involucrar a las empresas para garantizar el éxito del proyecto puede ayudar.
El equipo de control de calidad debe escribir los casos de prueba de requisitos. Si están involucrados en el proceso de recopilación de requisitos, tendrán una mejor comprensión de los requisitos. Esto permitirá la detección temprana de variaciones entre los requisitos documentados y las especificaciones de prueba.
Puede haber un número significativo de casos de prueba de unidad desarrollados para el código. Esto debería ser responsabilidad del equipo de desarrollo. Los requisitos probados en casos de prueba unitaria pueden no ser parte de los requisitos del sistema. El equipo de control de calidad puede asesorar a los desarrolladores en el diseño de casos de prueba de unidad.
Creo que esta cita resume uno de los problemas con la recopilación de requisitos:
“Sé que crees que entiendes lo que crees que dije, pero no estoy seguro de que te des cuenta de que lo que escuchaste no es lo que quise decir”. Roberto McClosky
Me lee como una falta fundamental de requisitos decentes que se recopilaron desde el principio. ¿Estuvo involucrada la empresa en el descubrimiento o en la discusión inicial?
Esto suena como el escenario perfecto en el que probar un plan iterativo ágil. Concentrarse en entregas más pequeñas y más frecuentes (un sprint, si lo prefiere) con un representante de la unidad de negocios para dar retroalimentación debería resultar en un producto más cercano a las metas de todos. O si no, deberían saber por qué antes.
Para responder tu pregunta:
1 QA debería ser suficiente, si los requisitos se definen con precisión. 2 suena como un infierno burocrático.
En este caso, aconsejaría que la UAT sea realizada por Business.
Si se recopilan los requisitos, los casos de prueba prácticamente deberían escribirse solos.