¿Quién debe escribir el plan de prueba?

Estoy en el equipo de desarrollo interno de mi empresa y desarrollamos los sitios web de nuestra empresa de acuerdo con los requisitos del equipo de marketing. Antes de entregarles el sitio para la prueba de aceptación, se nos pidió que les proporcionáramos un plan de prueba para que lo siguieran.

Sin embargo, el equipo de desarrollo cree que, dado que los requisitos provienen de los solicitantes, tendrían el mejor conocimiento de qué probar, qué buscar, cómo deben comportarse las cosas, etc. y, por lo tanto, no se requiere un plan de prueba. Siempre estamos discutiendo sobre esto, y los desarrolladores encuentran que es una pérdida de tiempo escribir cosas como:

1. Haga clic en el botón A .
2. Clave en XYZ en el botón de campo de formulario y haga clic en B .
3. Debería ver el comportamiento C .

que debemos repetir para cada requisito / función solicitada. Esto es básicamente reformular lo que ya está en el documento de requisitos.

Estamos avanzando hacia el uso de un enfoque ágil para administrar nuestros proyectos y esto también se solicita al final de cada iteración.

Dejando a un lado las pruebas de unidad e integración, ¿quién debe ser el que elabore el plan de prueba de aceptación del usuario final? ¿Deberían ser los solicitantes o los desarrolladores?

Muchas gracias de antemano.

Saludos
CK

El plan de prueba NO debe ser escrito por los desarrolladores. Parte de lo que debe hacer el plan de prueba es verificar si el desarrollador interpretó correctamente el requisito. Un desarrollador no puede escribir efectivamente un plan de prueba en el código que va a escribir. Los planes de prueba deben ser escritos por las personas que van a realizar el control de calidad o por los analistas de negocios. Si los desarrolladores deben escribir los planes, nunca asigne a alguien que escriba el plan para la parte del programa que va a escribir.

Tenga en cuenta que esto es diferente de diseñar pruebas unitarias que deben ser escritas por el desarrollador, ya que debería estar probando el código que escribió para ver si hace lo que esperaba. Pero los planes de prueba son para comprobar si la aplicación funciona de la forma en que se esperaba que funcione y esto debe hacerlo alguien que no sepa cómo la aplicación fue técnicamente diseñada para funcionar para que sea efectiva.

El equipo de control de calidad debe escribir y ejecutar el plan de prueba.

Idealmente, el plan de prueba debe escribirse en paralelo con la especificación funcional: es sorprendente cómo pensar en cómo probar la funcionalidad concentra la mente y mejora la especificación.

Una respuesta Scrum: si desea definir la 'Definición de hecho', notará que tener un plan de prueba se convierte rápidamente en uno de los elementos. ¿De qué otra manera puedes describir la historia que se debe hacer, si no se ha probado?

¿Quién es el responsable de crear el plan de prueba? El equipo

Quien es el equipo? Cualquier persona comprometida con la realización del producto debe ser miembro del Equipo.

Entonces, en su caso, puede incluir (o contratar) a la persona que puede escribir los planes de prueba en su 'equipo de desarrollo'. Si se está mudando a Agile, notará que la creación de un plan de prueba ocurre en paralelo al desarrollo. Ambos comienzan desde la misma historia y, a través de la comunicación, terminan sincronizados y entregados al mismo tiempo. No debe declarar su historia "terminada" antes de haber aprobado los casos de prueba que las partes interesadas consideran críticos.

Encuentro que los planes de prueba funcionales deben ser escritos por analistas funcionales / comerciales. Escriben el análisis funcional (incluso si está trabajando ágilmente, supongo que tiene algún análisis), por lo que deberían ser los que anotan qué rutas en la aplicación deben seguirse para los propósitos de prueba.

Depende totalmente de cómo esté trabajando, pero en mi opinión los desarrolladores no deberían escribir documentos funcionales sobre cómo probar la aplicación, qué datos usar para probarla, etc.

Aquí hay una idea que podría hacer felices a ambos grupos y encajar bien con avanzar hacia un enfoque ágil:

Automatice sus comprobaciones de aceptación de usuarios y realice una transmisión por pantalla

http://pragprog.com/magazines/2009-12/automating-screencasts

Parece que parte del problema que tiene es que los planes de prueba que está escribiendo son muy repetitivos y puramente confirmatorios. Para ser honesto, no llamaría a lo que está escribiendo pruebas en absoluto: si solo confirma los requisitos, está comprobando . Automatizar esto y hacer screencasts le permitirá empaquetar una demostración ordenada para sus clientes con regularidad (incluso podría enviarlos durante un breve período diario): es más probable que hagan clic en una demostración y la vean que abrir un plan de prueba y comience a trabajar en él, por lo que esperamos obtener comentarios más rápidos (muy importante si está avanzando hacia un enfoque más ágil). Podrá reutilizar componentes para que reduzca la carga de trabajo por usted,

También proporciona una forma de ejecutar los requisitos: ¿ha encontrado las especificaciones ejecutables de Gojko Adzic? Eche un vistazo aquí: http://gojko.net/2010/08/04/lets-change-the-tune/ Si está pensando en esto como una forma de obtener los requisitos en un formulario ejecutable para hacer una demostración a sus clientes , entonces de repente parece mucho menos inútil.

Ahora, poniéndome el sombrero del probador, tengo el honor de señalar que si despega el screencast, los liberará a usted / a sus partes interesadas para realizar algunas pruebas adecuadas, es decir, probar casos extremos y pruebas que realmente desafían la aplicación , en lugar de solo confirmar los requisitos. Le sugiero que proporcione los screencasts junto con preguntas cortas o sugerencias para las áreas sobre las que desea recibir más comentarios, por ejemplo:

1) Aquí está nuestro nuevo formulario de registro: ¡mire este screencast para ver cómo funciona!

Sobre qué nos gustaría recibir comentarios: hemos agregado muchas verificaciones adicionales en este formulario para asegurarnos de que los clientes no puedan ingresar los datos incorrectos; realmente nos gustaría que miraran los mensajes de error que reciben los clientes cuando ingrese lo incorrecto y díganos si nuestros clientes los encontrarán fáciles de entender.
También nos gustaría saber si hemos sido demasiado estrictos en algunos casos: si tiene datos de clientes particularmente inusuales (tal vez un nombre muy largo o muy corto, o alguien con caracteres inusuales en su nombre, o algo más en lo que no pensamos, o tal vez su dirección no tiene el nombre de una calle o algo extraño como ese?) Entonces, ¿tal vez podría pasar unos minutos probándolos?

Es decir, presenta un bonito screencast y luego pide comentarios, enmarcandolo sin ser demasiado específico, haz que piensen en posibles problemas en lugar de solo confirmarlo. Haga que piensen , en lugar de simplemente hacer clic a ciegas en un plan de prueba. Básicamente estás escribiendo una carta de prueba exploratoria para ellos. (Si observa los Cuadrantes de prueba ágiles , estas serían pruebas en el Cuadrante 3).

Tome la renovación de su casa como ejemplo. ¿Aceptaría una lista de verificación hecha por su contratista pidiéndole que marque lo que ha hecho por usted? ¿O elaboraría su propia lista de verificación y comprobaría si el contratista ha hecho lo que USTED especificó?

La respuesta es clara: el solicitante debe verificar si lo que solicitó se realiza de acuerdo con las especificaciones. Él / ella debe salir con su propia lista de verificación y probar la aplicación. en contra de esta lista.

Sin embargo, el desarrollador debe tener su propia lista de verificación y asegurarse de que se realicen las pruebas internas adecuadas y se eliminen los errores antes de manejar la aplicación. para UAT. Idealmente, el desarrollador debería automatizar la mayoría de estas pruebas en forma de scripts de prueba. ¿Recuerdas TDD? Idealmente, los scripts de prueba (en este caso, casos de prueba unitaria) deberían escribirse para probar los componentes de las aplicaciones. El conjunto de pruebas debe escribirse para combinar estos casos de prueba unitarios para realizar pruebas de regresión integradas y posteriores.

El plan de prueba de aceptación del usuario final generalmente lo redactan los clientes o un socio comercial de la compañía que representa al cliente. Se supone que representa las características que el cliente desea, y complementa las pruebas de integración de QA. Ni el control de calidad ni el desarrollo pueden planificar eficazmente las pruebas de aceptación del usuario, ya que uno de los objetivos principales de las pruebas de aceptación del usuario es garantizar que lo que el control de calidad y el desarrollo pensaban que el cliente quería era realmente preciso.