Planes de prueba y la mejor forma de escribir de ellos

Question

Estamos tratando de averiguar la mejor manera de escribir las pruebas en nuestro plan de pruebas.Específicamente, cuando la escritura de una prueba que está destinado a ser usado por cualquier persona, incluyendo QA personal, deben los pasos de la prueba ser muy específicos o más amplio, dando el probador más margen de maniobra en la forma en que la tarea puede llevarse a cabo.Como un ejemplo muy sencillo, si estás probando la apertura de un documento en un documento de procesamiento de textos, caso de que la prueba de lectura:

1. Usando el ratón, abra el menú archivo
2. Seleccione "Abrir Archivo..." en el menú archivo
3. En el cuadro de diálogo abrir archivo que aparece a continuación, vaya a x y haga doble clic en el documento llamado y

O

1. Abrir el cuadro de diálogo abrir archivo
2. Abra el archivo y

Ahora me doy cuenta de que una respuesta es probablemente va a ser "depende de lo que usted está tratando de poner a prueba", pero estoy tratando de responder a una pregunta más amplia aquí:Si los pasos de la prueba son demasiado específicas hacemos corremos el riesgo de a) hacer que el proceso de pruebas para laborioso y tedioso y lo que es más importante b) ¿corremos el riesgo de que falta algo, porque escribimos demasiado específicas de un camino para alcanzar una meta.Alternativamente, si la hacemos amplia hacemos depender demasiado de los caprichos del tester en el tiempo y perder crucial pruebas de que las rutas de acceso más común a los clientes/clientes?

Answer 1

Mi primera pregunta sería - ¿por qué no su departamento de control de calidad de la escritura de los planes de prueba?Normalmente, los desarrolladores de software proporcionan QA con una especificación funcional de cómo el software se supone que funciona y, a continuación, QA crea planes de pruebas basado en eso.

Con eso dicho, yo sugeriría que ser muy específico con los pasos que ya se están detallando cómo son las cosas supone para el trabajo.Es entonces cuando el trabajo del probador para asegurarse de que sus pasos específicos obtener los resultados deseados, y también es su trabajo para desviarse del plan y tratar de romper cosas.

Si hay varias maneras de lograr un objetivo, es necesario describir cada camino para llegar allí.

Answer 2

Yo no soy un tester, pero en mi opinión es vital para documentar la "interfaz de usuario de ruta" que la prueba se debe tomar para evitar cualquier confusión.

He trabajado en innumerables defectos que yo no podría reproducirse simplemente porque yo no era acceder a la función desde la misma interfaz de usuario de la ruta como el probador era.por ejemplo,El menú del Clic derecho vs Barra de herramientas o funciones que se pueden llevar a cabo a partir de varios cuadros de diálogo, etc.etc.

Answer 3

Suena como a su personal de QA es realmente QC (Control de Calidad) si ellos no son responsables de los exámenes de escritura.Si ellos realmente son los responsables de escribir ensayos, las pruebas será de ayuda, pero las especificaciones que son claro sería mejor fuente para que escriban sus propias pruebas.Aún mejor sería contar con ellos como parte del proceso de revisión de las especificaciones, por lo que se puede preguntar por los detalles que les permita escribir las pruebas.

Si realmente están en una posición donde usted está escribiendo pruebas para otras personas, hay algunas consideraciones.Usted querrá una dolorosa nivel de detalle si :

• la gente que se ejecutan las pruebas no son capaces de llegar a hacer preguntas
• la gente que se ejecutan las pruebas no están familiarizados con el producto

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

Todo esto se dice, lo que usted ha escrito no es lo que generalmente se considera un 'plan de pruebas'.Un Plan de Pruebas se describe qué tipos de pruebas se ejecutará (funcionales, de regresión, de seguridad, etc.), cuáles son las características para ser probado, tal vez incluso qué exámenes serán escritos, que van a hacer la prueba, cuando los grupos de pruebas están programadas y otro tipo de planificación de las actividades.

Lo que usted describe arriba es simplemente un conjunto de pruebas.

Answer 4

La primera es característica de la prueba.Prueba con los pasos detallados que contienen interfaz de usuario de la ruta como es posible que exista más rutas de uno para el destino.Prueba de todas las rutas.Esto último suena más como las pruebas de usabilidad.Se debe hacer también, pero no sólo por sus probadores, pero también por personas externas.

Answer 5

Vamos a distinguir Plan de Pruebas y Suites de Prueba :)

Suite de prueba es un conjunto de pruebas en sí

Plan de prueba es parte de la Suite de Prueba + de los recursos disponibles (personas, hardware, tiempo, ...).

Es aceptable tener ambas variantes (detallada y "bruto") que se describen en la documentación de prueba, sólo tiene que colocar detallada y "dura" de las pruebas a los diferentes documentos y dar prioridad a estos documentos.

Entonces, cuando usted tiene suficiente tiempo para probar el producto completamente, todos los documentos de, por ejemplo, la categoría a y de la prueba de producto de acuerdo con estos documentos.Si usted no tiene tiempo, pero necesitan una rápida conclusión sobre la calidad, la toma de la categoría B de los documentos y de paso comprobaciones descritas allí.

lado bueno:usted puede seleccionar el modo de prueba de producto

lado malo:usted necesidad de "duplicar" los documentos

Answer 6

Es perfectamente posible que desee exacta, detallada, los pasos de reproducción cuando alguien encuentra un problema.Pero si usted escribe sus planes de pruebas de esa manera, se corre el riesgo de que los problemas siguientes:

1) Inattentional blindness - He visto a la gente de la ejecución de un detallado procedimiento secuencia de comandos de prueba, obedientemente, y caminar a través de la grabación de cada paso meticulosamente, y TOTALMENTE ausente de la flagrante error de derecho en frente de ellos.Porque "no estaba en el guión".Su atención se centra en todos aquellos quisquillosos pasos de la prueba que, literalmente, no podía ver los problemas en frente de ellos.

2) va a perder TODOS esos errores que son sólo un paso fuera de su muy detallado, muy de ruta específica.Cuando los clientes obtener tu producto, que no siga el detallado plan de pruebas.Van a navegar alrededor de su aplicación en una variedad de maneras.Que cambien de opinión.Tendrán nombres más largos, o cortos, de las que se creía probable o posible.Van a llegar a mitad de camino a través de una transacción y el abandono.Van a pasear.Ellos no se adhieren a una ruta de acceso.Y cada vez que alguien repite la prueba, se perderá esos errores de nuevo.

3) va a pasar un tiempo increíblemente largo tratando de conseguir "cualquiera puede seguir este" secuencias de comandos de prueba por escrito.Créanme, he pasado años tratando de perfeccionar este, y no sólo humanamente posible.Peor aún, la cantidad de tiempo que los residuos tratando de hacer esto podría ser gastado mucho más rentable en alguna otra forma, por lo que su producto es peor.

4) Usted va a terminar con un montón de repetición, y es difícil decir cuál es el punto de la prueba es sin leer toda la cosa.No será fácil para escanear rápidamente a través de las pruebas para ver qué casos de uso que puede haber perdido.

Mantenga sus planes de pruebas amplio y permitir a la gente hacer las pruebas para el ejercicio de su juicio.Si usted tiene información sobre los escenarios de uso específico que debe ser probado, o acerca de cómo el grupo de usuarios de destino se desea operar, a continuación, dar esto a los probadores también junto con los planes de prueba - tal vez en la forma de personas, tal vez sólo en la forma de casos de uso.Si usted necesita las cosas enfadado, considere el uso de una lista de verificación.(Para obtener más información, consulte Cem Kaner excelente presentación www.kaner.com/pdfs/ValueOfChecklists.pdf).

Alternativamente, escribir sus planes de pruebas a corto exploratorio de los fletes.Usted podría, por ejemplo, dar orientación, tales como:"Callcentre de usuarios que utilizarán las estaciones de trabajo sin ratón conectado.Explorar el proceso de obtención de un boleto en nombre de un cliente, asegurando que es posible completar todas las actividades utilizando los métodos abreviados de teclado solamente." Esto es mucho más probable que resulte en su probadores de encontrar defectos que decir "Ficha en el campo 1.Introduzca "Queja acerca de la calidad de la línea".Ficha en el campo 2.Seleccione "llamada de Teléfono" en el menú desplegable.Ficha en ....campo 68."

Answer 7

hay pros y contras para el tratamiento de su probador como que no tienen conocimiento del sistema o de equipos en general.

si usted escribir las cosas en detalle (por ejemplo,"desde el menú archivo, seleccione 'Abrir'...") que el beneficio es que usted puede utilizar los contratistas que no están familiarizados con el sistema. pero se necesita más tiempo para escribir como este

si usted se salta una gran cantidad de detalles (por ejemplo,"abrir un documento de archivo..."), de quien utiliza el plan de pruebas es más probable que quedas atascado, y que la interrupción de clarificación. pero es mucho más rápido para escribir

puede ser una falsa economía, a pensar en su más rápido si haces la enérgica versión, si al final sólo el gasto adicional de tiempo a explicar el sistema de aseguramiento de la calidad de la persona

tengo un artículo donde puedo ir más a fondo sobre este tema: Escribir un Plan de Pruebas de Sistema

en este artículo, a favor de la aproximación más detallada.pero yo he sido el desarrollo de un "punto medio" entre estos dos enfoques últimamente (llamado CARACTERÍSTICA del plan de pruebas), pero no estoy en un punto donde su madurez suficiente para compartir aún

-- LM