¿Deberían los desarrolladores, evaluadores y usuarios comerciales tener un script de prueba unificado?

En desarrollo, normalmente tendría mis propios scripts de prueba que documentarían los datos, los escenarios y los pasos de ejecución que planeo probar; Este es mi plan de prueba de desarrollo. Cuando la funcionalidad se ha implementado en Test, los evaluadores la prueban utilizando su propio script de prueba que escribieron. En UAT, el usuario comercial luego prueba usando su propio plan de prueba.

En retrospectiva, parece que esto proporciona una mejor cobertura, ya que las pruebas de desarrollo tienen una combinación de pruebas de caja en blanco y negro, mientras que los evaluadores y los usuarios comerciales se centran en las pruebas de caja negra. Pero, por otro lado, esto trae distintos casos de prueba que solo se ejecutan por etapa (es decir, algunos casos en los que los probadores pensaron que solo se ejecutan en la etapa de Prueba) y le gustaría que el desarrollador se lo perdiera, lo que lo convierte en un hallazgo / error .

¿Vale la pena consolidar los scripts de prueba desde el principio? Por lo tanto, utilizando un script de prueba unificado, ¿o es un poco difícil hacer esto por adelantado?

En primer lugar, el control de calidad no es una prueba. Si su departamento de QA no está involucrado en todo el proceso de desarrollo, son Test, no QA. El control de calidad al hacer su trabajo, proporciona garantía de calidad, en el mejor de los casos, la prueba muestra la falta de calidad, pero no puede demostrar que existe la calidad, es decir, la prueba muestra que el control de calidad ha fallado, pero no puede demostrar que han tenido éxito, por lo que la prueba y el control de calidad no deberían ser el mismo departamento.

Creo que la mejor manera es hacer que cada grupo administre sus propias pruebas, ya que proporciona una mejor cobertura. Sin embargo, cada equipo debe comenzar a realizar las pruebas lo antes posible. Esto significa que UAT comienza tan pronto como haya algo que los usuarios puedan usar, la prueba comienza tan pronto como una parte para la que tienen una prueba está lista, etc. Esto evita la detección tardía de casos de prueba distintos. Esto puede significar un nuevo ajuste de sus modelos de trabajo, ya que a menudo UAT y Test esperan trabajar en un producto completo y necesitan capacitación para probar productos parcialmente completos. Puede ser más costoso a menos que el flujo de trabajo sea disciplinado y un desarrollador "Completo" signifique Completo.

El control de calidad debe supervisar esto, junto con otras medidas de calidad, para garantizar que el proceso no solo ofrezca el resultado de calidad deseado, sino también a un nivel de eficiencia apropiado.

Editar: se ha eliminado la referencia de la pregunta original al control de calidad, por lo tanto, esta respuesta ahora aparece OT.

Usamos UATs desde el principio.

Actúa como una referencia universal y creo que funciona bien. Si bien puede haber scripts de prueba que solo usan los desarrolladores o probadores para componentes más pequeños, la dirección de la prueba siempre apunta hacia un objetivo unificado. Al final del día, la UAT es la única que cuenta, por lo que es mejor que se convierta en el foco al comienzo.

Hacer UAT desde el principio también tiene un beneficio adicional. Realmente aclara cualquier ambigüedad entre las expectativas del cliente y las suyas.

No necesitan un guión de prueba unificado, ya que las cosas que prueban y la forma en que realizan las pruebas a menudo se supone que son diferentes, lo que necesitan es un requisito unificado del que todas las partes están trabajando. Si UAT y QA están probando cosas que el desarrollador nunca pensó, entonces es hora de analizar los requisitos.

Estoy de acuerdo en que sería bueno tener un script de prueba unificado para desarrolladores, probadores y usuarios comerciales, pero creo que no es posible sin un gran esfuerzo donde el costo supera el beneficio.

La razón de la dificultad es que el contenido de la base de datos en cada sistema es diferente y las pruebas generalmente dependen en gran medida del contenido de la base de datos. nuestro enfoque para las "pruebas unificadas" fue que cada sistema también obtiene una base de datos de prueba adicional y hay secuencias de comandos para crear esa base de datos desde cero. los scripts de prueba se ejecutan contra testdb donde el contenido está estandarizado.

En un mundo perfecto, los desarrolladores deben tener pruebas unitarias (xUnit), probadores - pruebas de integración automatizadas (Selenium) y usuarios comerciales - pruebas de aceptación (FIT). Pueden tener acceso entre sí las pruebas.

Realmente depende del proyecto. En algunos casos, un equipo unificado de prueba, control de calidad y UAT que se reúne para discutir los resultados puede ser muy beneficioso. Ahorra la duplicación del esfuerzo de prueba y garantiza que todas las partes tengan una comprensión más clara de las necesidades comerciales a través de scripts UAT. Por otro lado, dependiendo de la complejidad del proyecto, podría tener más sentido QA'd completamente las entradas y salidas antes de probar ejemplos de negocios. Para el desarrollo de sistemas locales, el control de calidad inicial sería imprescindible antes de la aceptación del usuario. Para implementaciones listas para usar, un equipo de prueba unificado tendría más sentido.