Casos de prueba de aceptación de escritura

En mis suites de aceptación me he abstenido de usar controles específicos de la tecnología, es decir, para las aplicaciones web, no use css, no use elementos html si necesita completar un formulario. pruebas de aceptación

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 es devuelto por una aplicación web, pero aún puedo usar la prueba para probar contra una aplicación de escritorio, ya que los pasos se usan 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 configurarse en estos estados con datos o acciones http en este caso, el pago tiene un valor determinado que realiza los pasos de confirmación y el de confirmación genera los pasos para que sean un poco frágiles en el momento

Primero debe definir Pruebas de aceptación .

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

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

Básicamente, el propósito de las pruebas de aceptación es verificar que los procesos "comerciales" que hacen uso del software que usted construyó realmente funcionan según lo previsto y se ajustan a su propósito, con datos de la vida real. Entonces, como tal, no construyes casos de prueba como haces pruebas de unidad o el resto. No se supone que se diseñe de la misma manera.

La pregunta que debe hacerse es "¿Cómo se usa el sistema?". Así que vamos a probarlo de la manera que se supone que debe ser utilizado. Por supuesto, ahora vuelve a poner su sombrero de ingeniería y cumple con los requisitos comerciales para derivar sus casos de prueba. Eso supone que tiene requisitos comerciales bien escritos.

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

Otra forma de hacerlo (nuevamente, si tiene un documento de este tipo) es revisar el manual del usuario. Aunque este es un paso eliminado de los requisitos comerciales reales, solo debe usarse si todo lo demás falla.

Cuando vas a comprar un automóvil, generalmente no profundizas mucho debajo del capó (a menos que seas un mecánico de automóviles). Solo te sientas al volante y verificas la comodidad, la facilidad de uso, el aspecto, los sonidos ... es decir, las cosas generales. Por lo general, confía en que si el automóvil estuviera en sus manos en primer lugar (al menos para un automóvil nuevo), en general es seguro y está bien construido (existe una garantía, usted ha hecho el trabajo de su casa y miró 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, es posible que tengas que hacer lo que mejor funcione en tu contexto.

No soy un gran fanático de los documentos de prueba largos, y he usado elementos visuales con bastante eficacia 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 ayudarte a mantenerte sano a largo plazo. Cualquiera que sea el método que elija, cuanto más trabaje con él, mejor lo logrará.

HTH, y buena suerte!

KM

Creo que ya has definido 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 bufixes (defiendo que cada corrección de errores venga con al menos una nueva prueba de unidad). Puede parecer abrumador ahora, pero simplemente sumérgete, y después de adquirir un poco de experiencia, reconocer lo que hace que las buenas pruebas sean más fáciles.