¿Cuán detallada debe ser la prueba de aceptación del cliente?

Aquí hay una descripción de la prueba, probando el caso de uso "Crear nuevo widget".¿Cuán detallada debe ser la prueba de aceptación del cliente?

Confirme que puede introducir un nuevo widget en el sistema.

Aquí es otra descripción de la prueba, prueba de la "Crear nuevo widget" de casos de uso.

Inicie la aplicación.
Cree un nuevo widget con el nombre "A-008", con la descripción "Widget de prueba para la prueba de aceptación 3-45".
Confirme que el widget ahora esté visible en la vista del árbol del widget más a la izquierda.
Seleccione otro widget en la vista de árbol, luego seleccione de nuevo el widget "A-008". Confirme que los valores en la visualización del widget sean iguales a los valores que ingresó.
Eliminar widget de "A-008" y cerrar la aplicación

Aquí es otra descripción de la prueba, prueba de la "Crear nuevo widget" de casos de uso.

Inicie la aplicación.
Muestra una segunda instancia de la aplicación que visualiza los mismos datos.
En la primera instancia de la aplicación, haga clic con el botón derecho en el nodo "Widgets". En el siguiente menú contextual, active la opción de menú "Crear nuevo widget".
Se debe activar una ventana "Nuevo widget". Deje cada campo en blanco y presione el botón OK. Debería aparecer un cuadro de mensaje que diga "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 también para la producción de fibra y carne. La altura de una llama grande, de tamaño natural, está entre 5,5 pies (1,6 metros) y 6 pies (1,8 metros) de altura en la parte superior de la cabeza. pesa entre 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)

Establezca la descripción en "'); ELIMINAR 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 apareció automáticamente en esa vista de árbol.
En la primera instancia de la aplicación, haga clic con el botón derecho en el nodo "Widgets". En el siguiente menú contextual, active la opción de menú "Crear nuevo widget". Se debe activar una ventana de "Nuevo widget".
Establezca el nombre en "A-008" y presione OK. Debe aparecer un cuadro de mensaje que diga "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 widgets".
Muestra la página del widget para el widget "A-008" en la segunda instancia.
En la primera instancia, presione la opción de menú "Deshacer"
Confirme que la segunda instancia ahora muestra la página de inicio.
................. etc ..............

cada ejemplo pruebas de que puede 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 comprobando cada uno de estos. ¿Es el tercero apropiado para una prueba de aceptación del cliente?

¿Cuán completo es "demasiado amplio"?

Fuente

2009-05-07 Andrew Shepherd

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

Las pruebas de aceptación del usuario deben ser más parecidas a "crear widget, verificar que aparezca, eliminar widget, etc." Esto también alentará a los usuarios a buscar funciones individuales y (como efecto secundario) eliminar cualquier problema de usabilidad que haya pasado por alto.

Fuente

2009-05-07 00:49:59

Al presionar el botón "marcar" sobre esto porque está haciendo buenos puntos con claridad, pero reconozco que las otras publicaciones hacen lo mismo. –

En un mundo perfecto, la descripción de la prueba sería el siguiente:

Confirmar que todas las pruebas automatizadas se ejecuten hasta su finalización con éxito

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

Cualquier forma de prueba manual con guiones va a ser propensa a errores y fallos, sin mencionar trabajo intensivo.

Fuente

2009-05-07 00:32:51

No, esto es una prueba de aceptación del cliente. Una prueba que debe realizar un cliente. Si soy un cliente, incluso si la empresa de desarrollo ME ASEGURA de que tienen pruebas automáticas completas, aún tengo que probar el sistema antes de que entre en producción y antes de que se pague a los proveedores asociados. –

¿Por qué un cliente no puede cerrar sesión en un conjunto de pruebas automatizadas? –

No me malinterpreten, como desarrollador creo que las pruebas automatizadas son geniales, hasta el punto en que me negaría a trabajar en un proyecto que no las tenía. Pero el cliente promedio no tiene habilidades técnicas y ni siquiera pretende saber cómo evaluar una prueba automatizada. Él/ella miraría cualquier descripción de prueba automatizada, y diría "Esto es solo un montón de tonterías, sáquelo de mi camino para que pueda ver si esta aplicación funciona". –

Creo que sus pruebas de aceptación deben ser principalmente buenas pruebas de ruta. Algunas veces, la ruta "buena" asegurará que los errores se manejen de forma adecuada. Debería tener otras pruebas que validen su seguridad y ejerciten los casos de esquina, pero una prueba de aceptación es más sobre asegurarse de que se haya construido 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 las buenas pruebas de ruta son totalmente apropiadas.

Por ejemplo, no probaría necesariamente que no tengo problemas con la inyección de SQL si utilizo una tecnología que aplica consultas parametrizadas o donde genero consultas a mano (no lo hago), que el las pruebas unitarias validan que la inyección falla. Abordar los casos de esquina en 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 su implementación de back-end aborda sus inquietudes, entonces hágalo de todos modos, pero yo no probaría cosas que sé que he abordado adecuadamente a través de otras pruebas.

Fuente

2009-05-07 00:47:17 tvanfosson

¿Qué dice tu especificación? Si cubre todas las cosas descritas en su tercer caso de prueba, entonces, ¿por qué yo, como cliente, no quisiera ver que su producto cumple con todas las especificaciones?

Si usted no tiene un conjunto explícito de requisitos ( facepalm), a continuación, romper sus pruebas en módulos: Calificación (con el cliente), Integración (módulos de prueba a los desarrolladores trabajar juntos) y Desarrollo (desarrolladores probar módulos individuales)

Automatice DT & E tanto como sea posible (por ejemplo, utilice pruebas unitarias para probar inyección SQL, desbordamientos de longitud de cadena, etc.). Esto debería ser fácil de hacer porque su backend debe estar separado de la GUI que se comunica con él (¿no?). La mayoría de las cosas de GUI que ha descrito en el tercer caso de prueba se pueden cubrir 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 de unidad, sus procedimientos de prueba de integración y resultados, entonces la prueba de calificación puede ser bastante fácil y sin complicaciones.

Fuente

2009-05-07 00:51:23 Catchwa

Me intriga lo que podría estar refiriendo a "facepalm". (Nunca escuché el término). –

http://en.wikipedia.org/wiki/Facepalm#Facepalm Lo envolví en asteriscos para indicar una acción, pero SO decidió ponerlo en itallics en su lugar. Mi intención de ese comentario fue que hacer las pruebas de aceptación del cliente sin un conjunto acordado de requisitos es un boleto de ida a pain-central. – Catchwa

Estaba pensando que era un producto de software (* facepalm *) –

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

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

Fuente

2009-05-07 00:55:33 SRO

Eso se parece más a un plan de prueba función para mí (es decir, las pruebas internas )

Las pruebas de aceptación por lo general se refiere a lo que muestran los clientes. Supongo que podría darle al cliente una prueba como esa - buena suerte

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

El quid de la cuestión es; haga una tabla que enumere todas las páginas del sistema, luego haga una columna para que el cliente inicie, y otra para usted mismo para inicializar. Te sientas con el cliente por unas horas y repaso todo. Si son felices con una página, firman apagado en él

Para los detalles completos de la plantilla, ver: User Acceptance Testing

Fuente

2010-06-10 10:12:38 louism

Es interesante que el desglose sea por páginas, en lugar de historias de usuarios. Los controles en cada página podrían funcionar bien, pero el flujo de información de una página a otra podría romperse, y no estoy seguro de si esta plantilla de prueba lo cubre. Quizás las pruebas deban descomponer la funcionalidad de dos maneras: por cada página (o ventana y diálogo en una aplicación de cliente enriquecido), y también por cada caso de uso. –

¿Cuán detallada debe ser la prueba de aceptación del cliente?

Respuesta

Cuestiones relacionadas