Durante años, uno de los mayores retos en las pruebas de software ha sido la de evitar que los usuarios experimentan defectos. Este reto sigue sin resolverse. El Probador humano está siendo observado por los involucrados en un proyecto y monitoreado por componentes de diferentes tipos de software, con el fin de mejorar las metodologías, técnicas y muchas otras variables. En este momento, las herramientas de prueba no están guiando sobre cómo probar mejor. Entonces, ¿Qué pasa si tuviéramos una herramienta de prueba que nos ayude a que nuestras pruebas sean más eficaces?
La mayor parte de los enfoques para mejorar la eficacia en un proceso de prueba se centraron en la mejora de los procesos y los recursos humanos que realizan esa actividad.
Este contenido esta extraído del Blog de Bstriker.
Más allá que sepamos que no podemos asegurar el 0% defecto, perder un defecto, es decir no detectarlo a tiempo, y dependiendo de su severidad, siempre se ha considerado «malo» para la práctica del testing en si misma, ya que el daño que puede causar se ve o se verá reflejado en la actividad comercial u operativa del cliente afectado, ni que hablar si las consecuencias son globales por ser un producto o servicio a nivel regional o mundial.
En fin, cierto es que hay que tener siempre presente que:
- Cada proyecto tiene su propia prioridad
- Cada cliente tiene necesidades y expectativas diferentes
- Cada compañía tiene una cultura diferente
- Cada Probador tiene habilidades diferentes
- Cada Probador tiene sus propios problemas
Tal como lo expresa, el autor, la gente comete errores y estar bajo presión no ayuda.
Siempre estamos bajo presión en ciertos momentos del proyectos, sea por plazos o metas especificas que nos han impuesto y que debemos cumplir.
¿O acaso no has vivido la experiencia que por atraso de una fase o etapa anterior como puede ser el desarrollo de uno de los componentes, nos «acortan» nuestro tiempo de prueba?
O que de parte del cliente mismo, cambia las prioridades por una cuestión del negocio mismo y se debe replantear el desarrollo y hasta las entregas.
Ni que hablar en un entorno de proyecto ágil donde todo evoluciona mucho más rápido.
Como se menciona en el artículo original, en general la gente cometer errores, especialmente bajo presión o en situaciones de estrés, tales como fecha límite para entregar los resultados de las pruebas, y ésto, por lo que se puede ver, no cambiará en el corto plazo.
Pensemos que este tipo de situaciones ocurre en todo tipo de área de testing, las de mayor o menor envergadura.
Aquí se plantea la comparación de las actividades de prueba con un médico, cuando un paciente se presenta al médico y describe todos los síntomas, el médico diagnostica los síntomas que indican la medicina que debe tomar para curarse. El Testing diagnostica una aplicación y muestra los resultados de la manera más profesional. Ahora bien, para ser capaz de diagnosticar el estado de la misma, las anomalías deben ser identificadas.
Hay actividades durante el proceso de pruebas que se llevan una cierta cantidad de tiempo para detectar anomalías, tales como la planificación, el mantenimiento de la documentación al día, la comprobación de que los defectos no se duplican, la generación de informes para los grupos de interés del proyecto, entre otras, y sólo por mencionar algunas, ya que no se han considerado por ejemplo las estimaciones del esfuerzo de testing, la gestión de los riesgos.
Los Probadores son más precisos y eficaces cuando se centran exclusivamente en lo que mejor saben hacer: Analizar y Detectar anomalías.
Desde BStriker están trabajando en proporcionar características que aumenten justamente este factor, la eficiencia de la detección de defectos.
Es común que los defectos se duplican de vez en cuando o no se planteado debido a la falta de tiempo para hacerlo correctamente. Los defectos se pueden plantear de forma automática a partir de un caso de prueba que falla. En el mismo momento en el Probador indica que un caso de prueba ha fallado, la aplicación comprueba si se ha creado en el pasado. Si ese es el caso, el defecto se vuelve a abrir de lo contrario, se crea. Si el defecto es abierto, sólo se añade un comentario indicando que está sucediendo.
Como los defectos no se describen adecuadamente, generan una situación en la que el Desarrollador necesita más información; por el Probador tiene que dejar de probar para recopilar información. Cuando un tester marca un caso de prueba como fallido, entonces toda la descripción del caso de prueba se añade al defecto. En los casos de prueba automatizados se pueden añadir incluso el registro o información adicional.
Con el fin de dar plena transparencia en el proceso de pruebas, mediciones y cuadros de mando, la actualización desde ser accesible desde cualquier dispositivo, en cualquier momento en tiempo real.
Re-utilización de casos de prueba: cuando se prueban varias aplicaciones algunos casos de prueba se pueden volver a utilizar. Una acción muy útil es la de mover, copiar o incluso vincular casos de prueba que se utilicen en varios planes más. Si se vincula el primero en los otros planes al actualizar un caso de prueba los otros enlaces se actualizan también.
Una de las características más interesantes que se utiliza en nuestra aplicación es el bucket!
El bucket es el lugar donde el usuario selecciona los Probadores que participan en el plan, los casos de prueba que participan en el plan y luego por cada Probador, las peticiones que hace desde la aplicación por caso de prueba para su ejecución. La aplicación dispone de todos los casos de prueba organizados por importancia cobrando mayor valor aquí para cuando el tiempo de testing es reducido. Principio que no se sigue habitualmente y que esta solucionado aquí.
La documentación evoluciona rápidamente durante el proyecto y por lo general se pone obsoleta con el tiempo; la tecnología evoluciona más rápido que lo que podemos aprender, por lo tanto los Probadores necesitan ayuda para ser eficaces y comunicarse más rápido. No deben preocuparse por estas actividades complementarias.
Por ejemplo notificar al propietario del producto o a un desarrollador que su parte del código tiene una anomalía, debería hacerse de forma automática, ya que el tiempo es muy limitado.
La mayor característica del bucket junto con la automatización de pruebas, es que con un solo clic logramos alcanzar cuatro navegadores con un clic contribuye tanto a la prueba ágil y estructurada para aumentar la cobertura y mantener bajo control la evolución.
Estas son sólo algunas de las características que contribuyen a que los Probadores se puedan enfocar en lo que mejor saben hacer y que también hará que los usuarios finales estén más felices al poder experimentar una aplicación más estable.
No dude en contactar con nosotros para una prueba gratuita de la aplicación Bshape.
Fuente de inspiración: Bstriker Blog
