Escritura de casos de prueba de aceptación

Estamos integrando un proceso de prueba en nuestro proceso SCRUM. Mi nuevo rol es escribir pruebas de aceptación de nuestras aplicaciones web para automatizarlas más adelante. He leído mucho acerca de cómo deben escribirse los casos de prueba, pero ninguno me dio consejos prácticos para escribir casos de prueba para aplicaciones web complejas, y en su lugar arrojaron principios contradictorios que encontré difíciles de aplicar:

• Los casos de prueba deben ser cortos: tome el ejemplo de un CMS. Los casos de prueba cortos son fáciles de mantener e identificar las entradas y salidas. Pero, ¿qué pasa si quiero probar una larga serie de operaciones (por ejemplo, agregar un documento, enviar una notificación a otro usuario, el otro usuario responde, el documento cambia de estado, el usuario recibe un aviso). Más bien me parece que los casos de prueba deberían representar escenarios completos. Pero puedo ver cómo esto producirá documentos de prueba abiertamente complejos.

• Las pruebas deben identificar entradas y salidas: ¿Qué sucede si tengo una forma larga con muchos campos interactivos, con diferentes comportamientos? ¿Escribo una prueba para todo o una para cada una?

• Los casos de prueba deben ser independientes: ¿pero cómo puedo aplicar eso si probar la operación de carga requiere que la operación de conexión sea exitosa? ¿Y cómo se aplica a escribir casos de prueba? ¿Debo escribir una prueba para cada operación, pero cada prueba declara sus dependencias, o debería reescribir todo el escenario para cada prueba?

• Los casos de prueba deben estar ligeramente documentados: estos principios son específicos de los proyectos ágiles. Entonces, ¿tiene algún consejo sobre cómo implementar este principio?

Aunque pensé que escribir casos de prueba de aceptación iba a ser simple, me sentí abrumado por cada decisión que tenía que tomar (FYI: soy un desarrollador y no un probador profesional). Entonces mi pregunta principal es: ¿Qué pasos o consejos tiene para escribir casos de prueba de aceptación mantenibles para aplicaciones complejas? Gracias.

Editar : Para aclarar mi pregunta: soy consciente de que las pruebas de aceptación deben comenzar desde el requisito y considerar toda la solicitud como un recuadro negro. Mi pregunta se refiere a los pasos prácticos para escribir el documento de prueba, identificar los casos de prueba, lidiar con las dependencias entre pruebas ... para aplicaciones web complejas

En mis suites de aceptación, me he mantenido alejado del uso de controles específicos de la tecnología, es decir, para aplicaciones web, no use CSS, no use elementos HTML si necesita completar un formulario, siga los detalles en los pasos para configurar el SUT, no las pruebas de aceptación reales

Yo uso pepino para mi aceptación y tengo lo siguiente

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

este ejemplo está de vuelta por una aplicación web, pero aún puedo usar la prueba para probar en una aplicación de escritorio, ya que los pasos se utilizan para configurar el SUT, no las pruebas de aceptación

esta prueba se encuentra al final de una compra que va

Generar -> Confirmar -> Pago -> Imprimir recibo

la prueba anterior es para el paso de pago, los otros pasos se configuran en otras pruebas debido a que la aplicación puede configurar en estos estados con datos o acciones http en este caso, el pago tiene un hecho que realiza los pasos de confirmación y la confirmación generar pasos para que sean un poco frágiles en el momento

Primero debe definir la Prueba de aceptación .

Lo que parece describir es la integración o las pruebas del sistema .

Entonces, aunque no estoy 100% de acuerdo con las definiciones en wikipedia, todavía son en gran medida válidas.

Básicamente, el propósito de las pruebas de aceptación es verificar que los procesos 'comerciales' que hacen uso de la pieza de software que construyó realmente funcionan según lo previsto y son adecuados para el propósito, con datos de la vida real. Entonces, como tal, no crea casos de prueba como lo hace con pruebas unitarias o el resto. No se supone que esté diseñado de la misma manera.

La pregunta que debe hacerse es "¿cómo se usa el sistema?". Entonces, probémoslo de la forma en que se supone que debe usarse. Por supuesto, ahora te vuelves a poner el sombrero de ingeniería y revisas los requisitos comerciales religiosamente para derivar tus casos de prueba. Eso supone que tiene requisitos comerciales bien escritos.

Si no lo hace, no es demasiado tarde, debe sentarse con los usuarios o sus representantes (y el analista comercial y la persona de diseño técnico) y escribir lo que esperan que el software entregue en términos comerciales ( con la advertencia obvia de que esto es demasiado poco y demasiado tarde, pero es mejor comenzar tarde que nunca, y por supuesto no introducir nuevas funciones). Esto es lo que van a ser sus casos de prueba.

Otra forma de hacerlo (de nuevo si tiene ese documento) es ir a través del manual del usuario. Aunque este es un paso eliminado de los requisitos comerciales reales, solo se debe usar si todo lo demás falla.

Cuando va a comprar un automóvil, generalmente no profundiza mucho debajo del capó (a menos que sea un mecánico de automóviles). Simplemente se sienta al volante y verifica la comodidad, la usabilidad, el aspecto, los sonidos ... es decir, las cosas en general. Por lo general, confía en que si el automóvil tiene que estar en sus manos en primer lugar (al menos para un automóvil nuevo), generalmente es seguro y está bien construido (hay una garantía, ha hecho el trabajo de su casa y examinó las especificaciones ...) Así que ahora verifica si este es el automóvil que querrá conducir durante los próximos años.

Lo mismo con el software.

La información conflictiva puede ser frustrante y difícil de generalizar y aplicar a su situación específica. Ergo, puede que tengas que hacer lo que funciona mejor en tu contexto.

No soy un gran admirador de los documentos de prueba largos, y he usado imágenes de manera bastante efectiva para algunos proyectos más pequeños. ¿Trata eso? ¿Como un diagrama de flujo (o cualquier otro diagrama UML como un diagrama de estado, etc.) en lugar de usar solo texto? Indique entradas, salidas, condiciones, bucles, carriles, estados, interacciones con otros componentes, etc., y luego indique si son exitosos, fallidos, transferidos, otros (?) Según sus criterios.

Puede ser un poco de trabajo al principio, pero puede ayudarlo a mantenerse sano a largo plazo. Cualquiera sea el método que elija, cuanto más trabaje con él, mejor lo conseguirá.

HTH, y buena suerte!

KM

Creo que ya has establecido algunos buenos criterios. Su segundo punto es una buena manera de definir los ámbitos para sus pruebas, y sugiero también probar las condiciones de error y las correcciones (defiendo que cada corrección de errores venga con al menos una nueva prueba unitaria). Puede parecer abrumador ahora, pero simplemente sumérjase y, después de adquirir un poco de experiencia, será más fácil reconocer lo que hace que las pruebas sean buenas.