Menú

Pruebas exploratorias frente a pruebas con guiones: ¿Quién gana?

exploratory testing vs scripted testing

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Beneficios del mundo real de las pruebas exploratorias:

Tradicionalmente, las pruebas de software han sido una actividad muy rígida, pero en los últimos años se ha producido un cambio en las pruebas basadas en scripts. Prueba exploratoria , que se basa más en el contexto, ha pasado a primer plano. Esto se debe a que les brinda a los evaluadores más libertad para aprovechar sus habilidades y conocimientos, y los hace responsables de optimizar el valor de su propio trabajo.

Pruebas exploratorias frente a pruebas con guiones

No todo el mundo está convencido del valor de las pruebas exploratorias. La falta de formalidad percibida y el énfasis en la responsabilidad personal pueden hacer sonar las alarmas. Pero esa preocupación se basa en gran medida en una mala interpretación de las pruebas exploratorias. No se trata de tirar reglas por la ventana y probarlas al azar, en realidad es muy estructurado y sistemático. Y también es muy eficaz.

Los escépticos quieren pruebas concretas de que hace más que mejorar la moral del evaluador. Es por eso que decidimos realizar un estudio que compararía las pruebas exploratorias basadas en el contexto directamente con un enfoque de prueba basado en secuencias de comandos. Los resultados fueron muy interesantes, como está a punto de descubrir.

Lo que vas a aprender:

mejor eliminación de virus para windows 10

Equipos de pruebas basados ​​en contexto (pruebas exploratorias) frente a guiones

Dos equipos, dos enfoques:

Comenzamos dividiendo a los probadores en dos equipos de tres. Los evaluadores de cada equipo tenían el mismo conocimiento de aplicaciones comparable. Las mismas definiciones para gravedad del defecto (mayor, menor) se establecieron para ambos equipos. Ambos equipos recibieron la misma compilación de la aplicación. Un equipo ('con guión') aplicaría un enfoque de prueba tradicional basado en guión y el otro equipo ('exploratorio') adoptaría un enfoque de prueba basado en el contexto. Las actividades de prueba se dividirían en dos fases de tres días cada una.

El equipo basado en guiones identificó cinco flujos de trabajo comerciales para probar y generó 15 casos de prueba. Los casos de prueba tenían un alcance limitado, por lo que los evaluadores no tenían libertad para explorar fuera de los límites del guión.

El equipo exploratorio creado dos mapas mentales visuales , uno que identificaba la cobertura de prueba y los estatutos de prueba, y el otro cubría los componentes / módulos del producto. El proceso produjo 24 cartas de prueba en total. Los estatutos definidos fueron de alto nivel y permitieron la interpretación contextual, extendiendo el alcance de la sesión de prueba para los probadores.

Fase 1:

El equipo con guión logró completar 6 casos de prueba en los tres días asignados. Informaron de 6 defectos importantes en ese tiempo.

El equipo exploratorio logró completar 13 sesiones de prueba que van desde 30 minutos a 180 minutos cada una. Informaron 10 defectos mayores y 5 defectos menores.

pruebas con guión vs exploratorias 1

Curiosamente, el equipo exploratorio informó todos los defectos que había informado el equipo con guión.

Fase 2:

El equipo con guión logró completar 9 casos de prueba esta vez. Ellos informaron 10 defectos importantes y 8 defectos menores .

El equipo exploratorio completó 18 sesiones. Ellos informaron 14 defectos mayores y 5 defectos menores.

pruebas con guión vs exploratorias 2

En la fase 2, el equipo con guión informó 2 defectos mayores y 1 defecto menor que el equipo explorador no encontró, pero el equipo exploratorio informó 3 defectos mayores y 1 defecto menor que el equipo con guiones no informó.

Esto no tiene en cuenta las complejidades relativas de los flujos de trabajo que pueden haber sido elegidos por los evaluadores dentro de estas sesiones y los casos de prueba, pero aún podemos sacar algunas conclusiones interesantes.

Qué significa eso?

Parecería que un enfoque exploratorio y la responsabilidad y flexibilidad que genera dan como resultado una forma de prueba más eficaz. Puede ser posible cubrir más terreno desarrollando y adaptando sus cartas de prueba a medida que avanzan las sesiones de prueba, según lo que tenga sentido en el contexto. Esta libertad falta en las pruebas basadas en scripts y puede evitar el descubrimiento de defectos.

mejor descargador de videos gratis windows 10

Apegarse rígidamente a los guiones crea caminos muy gastados, y solo desviándonos de esos caminos vamos a descubrir todos los defectos. Como lo mencionaron varias veces los líderes de opinión dentro de la comunidad de pruebas, 'si imagina un producto como un campo de minas terrestres y cada mina terrestre es un defecto, entonces está bastante claro que recorrer el mismo camino una y otra vez no es la manera de encontrarlas todos.'

Al final, ninguno de los enfoques fue perfecto, porque cada equipo informó defectos que el otro equipo no identificó, incluso si el equipo exploratorio informó más, en general.

Siendo realistas, esto puede significar que el enfoque correcto, con respecto a acercarse lo más posible a los defectos “mínimos”, será una mezcla de los dos. Pero, hay muchos beneficios con el enfoque basado en el contexto que hable a su favor. Requiere menos tiempo de preparación, menos documentación, identifica problemas antes y desafía a los evaluadores a usar habilidades analíticas y razonamiento deductivo. Obtienen una comprensión más profunda y completa del producto y realmente actúan como defensores del usuario final.

Conclusión

El resultado final demuestra que las pruebas exploratorias conducen a la notificación de más defectos antes de la puesta en marcha, lo que da como resultado un mejor producto entregado por el equipo y, en última instancia, probadores más satisfechos / satisfechos que son todos resultados deseables, de cualquier forma que se mire.

Sobre el Autor

Mush Honda es director de control de calidad en Tecnología KMS , un proveedor de servicios de TI a lo largo del ciclo de vida del desarrollo de software con oficinas en Atlanta, GA y Ho Chi Minh City, Vietnam. Anteriormente fue tester en Ernst & Young, Nexidia, Colibrium Partners y Connecture. Los servicios de KMS incluyen administración de aplicaciones, pruebas, soporte, servicios profesionales y aumento de personal.

¿Estás de acuerdo? No dude en publicar sus comentarios, preguntas a continuación.

PREV Tutorial | SIGUIENTE Tutorial # 4: Pruebas exploratorias con HP Sprinter

Lectura recomendada

^