Planes de prueba y la mejor manera de escribirlos

Question

Estamos tratando de encontrar la mejor manera de escribir pruebas en nuestro plan de prueba. Específicamente, cuando se escribe una prueba que debe ser utilizada por cualquier persona, incluido el personal de control de calidad, los pasos de la prueba deben ser muy específicos o más amplios para que el probador tenga más margen de maniobra sobre cómo realizar la tarea. Como un ejemplo muy simple, si se está probando abrir un documento en el documento de procesamiento de textos, debería leer la prueba:

1. Con el ratón, abra el menú Archivo
2. elegir la opción "Abrir archivo ..." en el menú
3. archivo en el diálogo de archivo abierto que aparece, vaya a X y haga doble clic en el documento llamado y

O

1. Brin g hasta el archivo abierto de diálogo
2. Abrir el archivo y

Ahora realizo una respuesta es, probablemente, va a ser "depende de lo que usted está tratando de probar", pero estoy tratando de responder a una amplia pregunta aquí: si los pasos de la prueba son demasiado específicos, ¿corremos el riesgo de a) hacer que el proceso de prueba sea laborioso y tedioso y lo más importante b) nos arriesgamos a perder algo porque escribimos un camino demasiado específico para lograr un objetivo. Alternativamente, si lo hacemos de forma amplia ¿dependemos demasiado de los caprichos del probador en ese momento y perdemos pruebas cruciales de rutas que son más comunes para los clientes/clientes?

Answer 1

Mi primera pregunta sería: ¿por qué su departamento de control de calidad no está escribiendo los planes de prueba? Normalmente, los desarrolladores de software proporcionan a QA una especificación funcional de cómo se supone que debe funcionar el software y, luego, el control de calidad crea planes de prueba basados ​​en eso.

Dicho esto, sugeriría ser muy específico con las fases, ya que se detalla cómo las cosas se supone a trabajar. Es entonces el trabajo del probador asegurarse de que sus pasos específicos obtengan los resultados deseados y también es su trabajo desviarse del plan y tratar de romper las cosas.

Si hay varias formas de lograr un objetivo, debe describir cada ruta para llegar allí.

Answer 2

No soy un probador, pero en mi opinión es vital documentar la "ruta de IU" que la prueba debe tomar para evitar cualquier confusión.

He trabajado en innumerables defectos que no pude reproducir simplemente porque no estaba accediendo a la función desde la misma ruta de UI que el probador. p.ej. Haga clic con el botón derecho del ratón en barra de herramientas o funciones que se pueden llevar a cabo desde varios cuadros de diálogo, etc. etc.

Answer 3

Parece que su personal de control de calidad es realmente control de calidad (QC) si no son responsables de escribir pruebas. Si en realidad son responsables de escribir las pruebas, sus pruebas serán útiles, pero las especificaciones que son claras serían una mejor fuente para que escriban las pruebas ellas mismas. Aún mejor sería tenerlos como parte del proceso de revisión de las especificaciones para que puedan solicitar detalles que les permitan escribir pruebas.

Si realmente está en una posición en la que está escribiendo pruebas para otras personas, existen algunas consideraciones.Usted desea un nivel dolorosa de detalle si:

• las personas que dirigen las pruebas no son capaces de llegar a hacer preguntas
• las personas que dirigen las pruebas no están familiarizados con su producto

usted puede evitar algunos detalles si estos no son ciertos. Sin embargo, todavía depende :)

Dicho todo esto, lo que habrá escrito no es lo que generalmente se considera un 'plan de prueba'. Un plan de prueba describe qué tipos de pruebas se ejecutarán (funcional, de regresión, de seguridad, etc.), qué características se probarán, tal vez incluso qué pruebas se escribirán, quién realizará las pruebas, cuándo se realizarán los grupos de pruebas. actividades programadas y otras actividades de planificación.

Lo que describes arriba es simplemente un conjunto de pruebas.

Answer 4

Distingamos Plan de prueba y prueba Suites :)

Test Suite es un conjunto de pruebas en sí

plan de pruebas es [parte de] Test Suite + recursos disponibles (personal, hardware, tiempo, ...)

Está bien tener ambas variantes (detalladas y "aproximadas") descritas en la documentación de la prueba, simplemente coloque pruebas detalladas y "aproximadas" en diferentes documentos y priorice estos documentos.

Luego, cuando tenga suficiente tiempo para probar el producto por completo, tome todos los documentos de, por ejemplo, categoría A y pruebe el producto de acuerdo con estos documentos. Si no tiene tiempo, pero necesita una conclusión rápida sobre la calidad, debe tomar los documentos de categoría B y aprobar los controles que allí se describen.

lado bueno: puede seleccionar la forma de probar el producto

lado malo: se necesita "duplicar" los documentos

Answer 5

La primera es la prueba de función. Pruebe con pasos detallados que contengan la ruta de UI ya que posiblemente haya más rutas que una hasta el destino. Pruebe todas las rutas. Este último suena más como prueba de usabilidad. También debe hacerse, pero no solo por sus evaluadores, sino también por personas externas.

Answer 6

hay ventajas y desventajas para tratar su comprobador como si no tuvieran conocimiento del sistema o de las computadoras en general.

si deletrea cosas detalladamente (por ejemplo, "desde el menú de archivo, seleccione 'Abrir' ..."), la ventaja es que puede utilizar contratistas que no estén familiarizados con su sistema. pero le toma más tiempo para escribir como esto

si se salta una gran cantidad de detalles (por ejemplo, "abrir un archivo de documento ..."), que el que utiliza su plan de pruebas es más probable que se atascan, y que te interrumpan por una aclaración.pero Es mucho más rápido para escribir

Puede ser una economía falsa para pensar su rápido si lo hace la versión a paso ligero, si al final acaba de pasar más tiempo para explicar el sistema a la persona qa

tengo un artículo donde profundizo en este tema: Writing a System Test Plan

En este artículo, estoy a favor de un enfoque más detallado. pero yo he estado desarrollando un 'punto medio' entre estos dos enfoques últimamente (llamado un plan de pruebas CARACTERÍSTICA), pero no estoy en un punto en su suficientemente maduro para compartir aún

- LM

Answer 7

Está perfectamente bien querer pasos de reproducción exactos, detallados cuando alguien encuentra un problema. Pero si escribe sus planes de prueba de esa manera, correrá el riesgo de los siguientes problemas:

1) Inattentional blindness - He visto personas ejecutando un guión de prueba de procedimiento detallado, recorriendo obedientemente y registrando cada paso meticulosamente, y TOTALMENTE PÉRDIDA de la deslumbrante error justo en frente de ellos. Porque "no estaba en el guión". Su atención estaba tan centrada en todos los pasos de prueba delicados que literalmente no podían ver los problemas frente a ellos.

2) Extrañará TODOS esos errores que están a un paso de su ruta muy detallada y muy específica. Cuando los clientes obtienen su producto, no seguirán el plan de prueba detallado. Navegarán por su aplicación de varias formas. Ellos cambiarán sus mentes. Tendrán nombres más largos o más cortos de lo que creía probable o posible. Tendrán la mitad de una transacción y la abandonarán. Ellos vagarán. No se pegarán a un camino. Y cada vez que alguien repite la prueba, echará de menos esos errores de nuevo.

3) Pasará un tiempo increíblemente largo tratando de hacer que "cualquiera pueda seguir esto" escriba las secuencias de comandos escritas. Créame, pasé años tratando de perfeccionar esto, y no es humanamente posible. Peor aún, la cantidad de tiempo que desperdicia tratando de hacer esto se puede gastar mucho más rentable de alguna otra manera, por lo que su producto está en peor situación.

4) Usted terminará con una tonelada de repetición, y será difícil decir cuál es el punto de su prueba sin leer todo. No será fácil escanear rápidamente las pruebas para ver qué casos de uso puede haber pasado por alto.

Mantenga sus planes de prueba amplios y permita que las personas que realizan las pruebas ejerzan su juicio. Si tiene información sobre escenarios de uso específicos que deben ser probados, o sobre cómo el grupo objetivo de usuarios querrá operar, entonces dele esto a los evaluadores junto con los planes de prueba, tal vez en forma de personas de usuario, quizás solo en la forma de casos de uso. Si necesita cosas específicas marcadas, considere usar una lista de verificación. (Para obtener más información, consulte la excelente presentación de Cem Kaner www.kaner.com/pdfs/ValueOfChecklists.pdf).

O bien, escriba sus planes de prueba como documentos exploratorios breves. Podría, por ejemplo, brindar orientación tal como: "Los usuarios de Callcentre utilizarán estaciones de trabajo sin mouse. Explore el proceso de subir un ticket en nombre de un cliente, asegurándose de que sea posible completar todas las actividades mediante atajos de teclado solamente". Es mucho más probable que los testers encuentren defectos que decir "Tab en el campo 1. Ingrese" Queja sobre la calidad de línea ". Ingrese en el campo 2. Seleccione" Llamada telefónica "en el menú desplegable. 68. "