¿Quién debe escribir el plan de prueba?

10

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

ckng
fuente
1
La única entrada para esto que los desarrolladores deberían tener son áreas de sugerencia y posiblemente algunos casos límite que deberían probarse (y no olvidarse). Pero no deberían dar detalles paso a paso sobre cómo exactamente hacer la prueba.
CaffGeek

Respuestas:

10

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.

HLGEM
fuente
Esto es lo que dije durante años en un trabajo.
David Thornley
1
Bueno hasta la última oración, pero las pruebas nunca deben limitarse a verificar que la aplicación siga las expectativas (¡sino que también debe cubrir lo inesperado!), Y saber al menos un poco sobre cómo la aplicación fue diseñada técnicamente SIEMPRE me ayuda como examinador a identificar las grietas en las que puedo meter la palanca de mi probador para abrir la cosa. ;) Es un poco anticuado imaginar que los probadores son mejores sin saber nada sobre la implementación.
testerab
1
Exactamente, @testerab. No conocer las partes internas ayuda a diseñar algunos tipos de casos de prueba, mientras que conocer las ayudas internas en las pruebas de caja gris, por ejemplo, conozco el área de riesgo en el código, solo necesito demostrar que la aplicación alcanza ese código.
dzieciou
7

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.

Chris Card
fuente
3
Posiblemente con la ayuda de los desarrolladores, pero principalmente el equipo de control de calidad.
Zachary K
¿Qué pasa si no tenemos un equipo de control de calidad? ¿Debería esta tarea recaer en los solicitantes? De las respuestas aquí, esto sería lo más lógico.
ckng
Si se está moviendo hacia Agile, intente contratar a algunas personas especializadas en pruebas en su equipo de desarrollo actual. (Nota: primero lea sobre las diferentes escuelas de pruebas, algunas no son compatibles con un enfoque ágil - redcanary.mypublicsquare.com/view/hiring-software )
testerab
2
Si no tiene un equipo de control de calidad, deberá reunirse con los solicitantes para tomar esa decisión. Por un lado, los desarrolladores no deberían necesitar hacer planes de prueba. Por otro lado, muchos / la mayoría de los clientes comerciales no saben nada acerca de las pruebas, y usted pasará UNA TONELADA DE ENTRENAMIENTO Y MANEJO DE MANOS al principio. Intentamos esto una vez y los clientes comerciales tuvieron grandes dificultades. Los casos regulares no fueron un gran problema, pero cuando se trataba de casos detallados y especialmente de casos de pruebas negativas, tuvieron dificultades. Mejor sería obtener / designar a un tipo de control de calidad o un analista de negocios que asignar a los clientes.
sdek
4

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.

Rudi
fuente
2

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.

koenmetsu
fuente
2

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).

testerab
fuente
Gran respuesta, excelente manera de sacar a los desarrolladores de la monotonía aburrida mientras recibes comentarios de los clientes. Y excelentes enlaces.
Ethel Evans
1

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.


fuente
1

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.

Ethel Evans
fuente
en.wikipedia.org/wiki/… para más información.
Ethel Evans
+1 para señalar que las pruebas de aceptación del usuario deben ser diseñadas por el usuario. Aunque he sugerido un enfoque alternativo en mi respuesta (ya que no parece que realmente tengan ningún recurso de control de calidad), las pruebas de aceptación del usuario no pueden ser efectivas por los no usuarios. En esta situación, parece que tanto el desarrollador como los usuarios están en un punto muerto, por lo que creo que el desarrollador debe intentar romper eso de alguna manera.
testerab