testing - tecnicas - Los planes de prueba y la mejor forma de escribirlos

tecnicas de pruebas de software (7)

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 los pasos ya que está detallando cómo se supone que funcionan las cosas. 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í.

Estamos tratando de descubrir 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 está probando la apertura de un documento en un procesador de texto, debería leer la prueba:

Con el mouse, abra el menú de archivo
Elija "Abrir archivo ..." en el menú de archivo
En el cuadro de diálogo de abrir archivo que aparece, navegue a xy haga doble clic en el documento llamado y

Abra el cuadro de diálogo Abrir archivo
Abra el archivo y

Ahora me doy cuenta de que una respuesta probablemente será "depende de lo que intentes probar", pero estoy tratando de responder a una pregunta más amplia: si los pasos de la prueba son demasiado específicos, ¿corremos el riesgo de a) hacer el proceso de prueba? a laborioso y tedioso y 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?

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, hay algunas consideraciones. Querrá un nivel de detalle doloroso si:

las personas que realizan las pruebas no pueden venir a hacerte preguntas
las personas que ejecutan las pruebas no están familiarizadas con su producto

Puede evitar algunos detalles si 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.

El primero es la prueba de características. 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.

Vamos a distinguir el plan de prueba y las suites de prueba :)

Test Suite tiene un conjunto de pruebas

Test Plan es [parte de] los recursos disponibles de Test Suite + (personas, 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 tiempo suficiente 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.

buen lado: puede seleccionar cómo probar el producto

lado malo: necesita documentos "duplicados"

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) Ceguera por falta de atención : he observado a personas ejecutando un guión de prueba de procedimiento detallado, recorriendo diligentemente y registrando cada paso meticulosamente, y TOTALMENTE DESAPARECIENDO el error deslumbrante 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 solo 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ás un tiempo increíblemente largo intentando que se escriban los guiones de prueba de "alguien puede seguir esto". 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) 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 ).

Alternativamente, escriba sus planes de prueba como cartas exploratorias cortas. 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. "

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

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. por ejemplo, menú de clic derecho frente a la barra de herramientas o funciones que se pueden llevar a cabo desde varios cuadros de diálogo, etc., etc.

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

si deletrea las cosas en detalle (por ejemplo, "desde el menú de archivo, seleccione ''Abrir'' ..."), lo mejor es que puede recurrir a contratistas que no están familiarizados con su sistema. pero te lleva más tiempo escribir así

si omite muchos detalles (por ejemplo, "abrir un archivo de documento ..."), es más probable que quien utiliza su plan de prueba se quede atascado y que lo interrumpa para que lo aclaren. pero es mucho más rápido escribir

puede ser una falsa economía pensar que es más rápido si haces la versión enérgica, si terminas pasando más tiempo explicando el sistema a la persona qa

Tengo un artículo donde profundizo en este tema: Escribir un plan de prueba del sistema

En este artículo, estoy a favor del enfoque más detallado. pero he estado desarrollando un ''punto medio'' entre estos dos enfoques últimamente (llamado un plan de prueba FEATURE ), pero no estoy en un punto en que sea lo suficientemente maduro como para compartirlo todavía

- LM