Pruebas exploratorias y sus beneficios
Hoy no voy a hablar sobre la definición de las pruebas exploratorias porque ya hay bastantes páginas web y libros que hablan sobre ellas, voy a hablar de los beneficios de estas pruebas y para mi, la mejor arma de un QA en temas de ejecución de pruebas.
Las pruebas exploratorias ayudan mucho a conocer el sistema (más que los casos de prueba o feature files) porque el QA está realmente usando el sistema, probándolo y haciendo cosas dentro de el, se puede saber lo que hace el sistema, lo que no hace y como se comporta. Las pruebas exploratorias son la mejor arma del QA más que otro tipo de pruebas, yo creo, sin temor a equivocarme, que si la historia de usuario o requerimiento está bien definido, se puede probar el sistema usando pruebas exploratorias sin necesidad de casos de prueba, feature files o documentación excesiva y se puede entregar un producto con muy buena calidad.
Hay muchas técnicas que se pueden aplicar al hacer pruebas exploratorias, la mayoría se aprenden con la experiencia, por ejemplo:
En mi trabajo actual y en mis trabajos anteriores he usado y aplicado muchas pruebas exploratorias, más que otro tipo de pruebas y siempre invito y aliento todos los QAs a hacer este tipo de pruebas, la verdad, me han ayudado bastante a encontrar muchos errores, errores que tal vez no hubiera encontrado usando casos de prueba o criterios de aceptación como base para probar, no hay que olvidar que los criterios de aceptación, requerimientos, casos de prueba o feature files son la base en donde empiezan la pruebas pero no donde terminan. Teniendo en cuenta lo anterior, viene por agregado la usabilidad, experiencia de usuario y accesibilidad, se pueden encontrar muchos errores o mejoras en funcionalidad que no es amigable para el usuario o buena para la experiencia del mismo, además de requerimientos o funcionalidad que no se necesitan o no tienen sentido, yo espero que un buen QA identifique esto.
Se pueden y deben usar casos de prueba, feature files o criterios de aceptación para la ejecución de pruebas y para documentación, pero siempre es bueno obligarse a si mismo a hacer pruebas exploratorias en cada módulo y de vez en cuando en todo el sistema, es normal que mientras el proyecto avanza hayan módulos que puedan dañarse por código nuevo introducido en el sistema.
Espero que les haya gustado mi visión sobre las pruebas exploratorias, el próximo martes hablaré sobre pruebas de accesibilidad.
Pueden segurime en Twitter, estoy como @LuchoAgileQA.
Las pruebas exploratorias ayudan mucho a conocer el sistema (más que los casos de prueba o feature files) porque el QA está realmente usando el sistema, probándolo y haciendo cosas dentro de el, se puede saber lo que hace el sistema, lo que no hace y como se comporta. Las pruebas exploratorias son la mejor arma del QA más que otro tipo de pruebas, yo creo, sin temor a equivocarme, que si la historia de usuario o requerimiento está bien definido, se puede probar el sistema usando pruebas exploratorias sin necesidad de casos de prueba, feature files o documentación excesiva y se puede entregar un producto con muy buena calidad.
Hay muchas técnicas que se pueden aplicar al hacer pruebas exploratorias, la mayoría se aprenden con la experiencia, por ejemplo:
- Diligenciar un formulario con los campos vacíos o solo espacios
- Diligenciar un formulario con datos incorrectos
- Hacer clic en un botón muchas veces y ver como se comporta el sistema (múltiples registros iguales, errores de base de datos, etc)
- Asegurarse que la funcionalidad de búsqueda no se active si no se ingresa texto (no espacios o vacíos)
- Subir una imagen que pese mas que el limite descrito por el sistemadel sistema
En mi trabajo actual y en mis trabajos anteriores he usado y aplicado muchas pruebas exploratorias, más que otro tipo de pruebas y siempre invito y aliento todos los QAs a hacer este tipo de pruebas, la verdad, me han ayudado bastante a encontrar muchos errores, errores que tal vez no hubiera encontrado usando casos de prueba o criterios de aceptación como base para probar, no hay que olvidar que los criterios de aceptación, requerimientos, casos de prueba o feature files son la base en donde empiezan la pruebas pero no donde terminan. Teniendo en cuenta lo anterior, viene por agregado la usabilidad, experiencia de usuario y accesibilidad, se pueden encontrar muchos errores o mejoras en funcionalidad que no es amigable para el usuario o buena para la experiencia del mismo, además de requerimientos o funcionalidad que no se necesitan o no tienen sentido, yo espero que un buen QA identifique esto.
Se pueden y deben usar casos de prueba, feature files o criterios de aceptación para la ejecución de pruebas y para documentación, pero siempre es bueno obligarse a si mismo a hacer pruebas exploratorias en cada módulo y de vez en cuando en todo el sistema, es normal que mientras el proyecto avanza hayan módulos que puedan dañarse por código nuevo introducido en el sistema.
Espero que les haya gustado mi visión sobre las pruebas exploratorias, el próximo martes hablaré sobre pruebas de accesibilidad.
Pueden segurime en Twitter, estoy como @LuchoAgileQA.
Comentarios
Publicar un comentario