acceptance testing - tipos - ¿Qué tan detallado debe ser una prueba de aceptación del cliente?

tipos de pruebas de software (6)

¿Qué dice tu especificación? Si cubre todos los aspectos descritos en su tercer caso de prueba, ¿por qué yo, como cliente, no quiero ver que su producto cumple con todas las especificaciones?

Si no tiene un conjunto explícito de requisitos ( facepalm ), luego divida sus pruebas en módulos: Cualificación (con cliente), Integración (los desarrolladores que prueban los módulos trabajan juntos) y Desarrollo (desarrolladores que prueban módulos individuales).

Automatice DT&E tanto como sea posible (por ejemplo, use pruebas unitarias para probar la inyección de SQL, desbordamientos de longitud de cadena, etc.). Esto debería ser fácil de hacer porque su backend debería estar separado de la GUI que se comunica con él (¿verdad?). La mayoría de las cosas de la GUI que describió en el tercer testcase pueden cubrirse como parte de las Pruebas de Integración (porque realmente está probando la integración entre el backend y la GUI).

Si el cliente puede revisar sus Pruebas Unitarias, sus procedimientos y resultados de pruebas de Integración, entonces las pruebas de Calificación pueden ser bastante sencillas e indoloras.

Aquí hay una descripción de la prueba, probando el caso de uso "Crear nuevo widget".

Confirme que puede ingresar un nuevo widget en el sistema.

Aquí hay otra descripción de prueba, probando el caso de uso "Crear nuevo widget".

Presenta la aplicación.
Cree un nuevo widget con el nombre de "A-008", con la descripción como "Test Widget for Acceptance Test 3-45".
Confirme que el widget ahora está visible en la vista de árbol de widgets más a la izquierda.
Seleccione otro widget en la vista de árbol, luego seleccione el widget "A-008" nuevamente. Confirme que los valores en el widget se muestran iguales a los valores que ingresó.
Eliminar el widget "A-008" y cerrar la aplicación

Aquí hay otra descripción de prueba, probando el caso de uso "Crear nuevo widget".

Presenta la aplicación.
Muestra una segunda instancia de la aplicación viendo los mismos datos.
En la primera instancia de la aplicación, haga clic derecho en el nodo "Widgets". En el menú contextual que sigue, active el elemento de menú "Crear nuevo widget".
Se debería activar una ventana "Nuevo widget". Deje todos los campos en blanco y presione el botón OK. Debería aparecer un cuadro de mensaje que dice "Por favor, ingrese un nombre de widget". Presione OK en este cuadro de mensaje.
Ingrese "A-008" en el campo "Nombre".
Establezca el campo de descripción en "La llama (Lama glama) es un camélido sudamericano, ampliamente utilizado como animal de carga por los incas y otros nativos de las montañas de los Andes. En América del Sur, las llamas todavía se usan como bestias de carga, así como para la producción de fibra y carne. La altura de una llama de tamaño completo y tamaño adulto es de entre 5.5 pies (1.6 metros) y 6 pies (1.8 metros) de altura en la parte superior de la cabeza. Pueden pesar aproximadamente 280 libras (127 kilogramos) y 450 libras (204 kilogramos). Al nacer, una llama bebé (llamada cria) puede pesar entre 20 libras (9 kilogramos) y 30 libras (14 kilogramos).
Presione el botón OK. Aparecerá un cuadro de mensaje que dice "La descripción debe tener 512 caracteres o menos".
Establezca la descripción en "''); BORRAR DE WIDGET DONDE 1 = 1;" en el campo "Descripción". Presione el botón OK.
En la vista de árbol más a la izquierda, debería haber aparecido un nuevo widget con el nombre "A-008".
Active una ventana en la segunda instancia de la aplicación y confirme que el Widget "A-008" también haya aparecido automáticamente en esa vista de árbol.
En la primera instancia de la aplicación, haga clic derecho en el nodo "Widgets". En el menú contextual que sigue, active el elemento de menú "Crear nuevo widget". Se debería activar una ventana "Nuevo widget".
Establezca el nombre en "A-008" y presione OK. Debe aparecer un cuadro de mensaje que dice "Ya existe un Widget con este nombre. Seleccione otro nombre de Widget".
Presione el botón OK en este cuadro de mensaje, luego presione el botón Cancelar para salir del cuadro de diálogo "Crear widget".
Mostrar la página del widget para el widget "A-008" en la segunda instancia.
En primer lugar, pulse el elemento de menú "Deshacer"
Confirme que la segunda instancia ahora muestra la página de inicio.
................. etc ..............

Cada ejemplo prueba que puedes crear un nuevo widget. En la tercera prueba, estaba probando la funcionalidad como un programador experimentado, pensando "OK, ¿dónde están todos los lugares donde puede aparecer un error" y revisando cada uno de ellos? ¿El tercero es apropiado para una prueba de aceptación del cliente?

¿Qué tan completo es "demasiado amplio"?

Creo que sus pruebas de aceptación deberían ser principalmente buenas pruebas de ruta. A veces, la ruta "buena" asegurará que los errores se manejen adecuadamente. Debe realizar otras pruebas que validen su seguridad y ejercitar los casos de esquina, pero una prueba de aceptación tiene más que ver con asegurarse de que se haya creado la aplicación correcta que asegurarse de que todas las condiciones posibles se manejen correctamente. Si tiene buenas pruebas de unidad y utiliza las mejores prácticas, entonces creo que la buena prueba de ruta es completamente apropiada.

Por ejemplo, no necesariamente probaría que no tengo problemas con la inyección de SQL si he usado una tecnología que impone consultas parametrizadas o donde genero consultas a mano (no) que las pruebas de la unidad validan eso la inyección falla Abordar los casos de esquina en las pruebas unitarias hace que sea menos importante centrarse en ellos en las pruebas de aceptación. Si necesita incluir algunos ejemplos para el cliente de que la implementación de su backend aborda sus inquietudes, hágalo de todas maneras, pero no probaría las cosas que sé que he abordado adecuadamente a través de otras pruebas.

Deben probar los casos de uso normal (no el excepcional). ¡Pero si prueban los excepcionales, es muy bueno!

Las pruebas de aceptación no pueden ser demasiado detalladas. Cuanto más prueban, más disfrutan el producto final.

En un mundo perfecto, la descripción del examen diría:

Confirme que todas las pruebas automatizadas se ejecutan hasta completarse con éxito

Habría una prueba automatizada para cada ruta en el caso de uso.

Cualquier forma de prueba manual, con secuencias de comandos será propensa a errores y fallará errores, por no mencionar el trabajo intensivo.

Eso se parece más a un plan de prueba de características para mí (es decir, pruebas internas )

Las pruebas de aceptación generalmente se refieren a lo que usted muestra al cliente. Supongo que podrías darle al cliente una prueba como esa, aunque buena suerte

Para las pruebas de aceptación del usuario, prefiero un formato muy simple (por supuesto, esto probablemente no será apropiado, por ejemplo, para el software de transbordador espacial o la banca). Está bien para proyectos web pequeños a medianos.

El quid de esto es; haga una tabla que enumere todas las páginas del sistema, que haga una columna para que el cliente inicie, y otra para usted inicial. Te sientas con el cliente por unas horas y pasas por todo. Si están contentos con una página, la firman

Para obtener todos los detalles de la plantilla, consulte: Pruebas de aceptación del usuario

Los casos de prueba de aceptación del usuario deben ser detallados y simples, pero no tan detallados como en su tercer ejemplo. Las pruebas de aceptación consisten en asegurarse de que el cliente obtenga lo que acordaron . Si simplemente dice "haga clic en esto, luego haga clic en eso, etc, etc ...", es más como una prueba funcional. No está provocando que los usuarios verifiquen que la funcionalidad cumple con el caso de prueba establecido en la prueba de aceptación. Solo les está pidiendo que hagan clic en las pruebas que podría haber automatizado simplemente.

Las pruebas de aceptación del usuario deberían estar más en la línea de "crear widget, verificar que aparece, eliminar widget, etc." Esto también animará a los usuarios a buscar características individuales y (como efecto secundario) eliminar cualquier problema de usabilidad que haya pasado por alto.