A lo largo de los años, he trabajado con mucha documentación de la que extraer información para realizar las baterías de pruebas y cada caso con un detalle, más o menos, completo.
En ellos , se suele detallar, a nivel funcional, como debe de funcionar el software que queremos construir, pero en muchas ocasiones, están cojos de información técnica o de posibles casuísticas. Hay empresas que solventan estas situaciones con mapas y modelos de cobertura completos, pero no es algo que siempre se vea.
Estos agujeros no contemplados o que son difíciles de detectar a nivel de requisitos, se llaman puntos ciegos.
Puntos ciegos en automatización
Ahora mismo, con los RPA, quedan cubiertos muchos puntos ciegos que antes no eramos capaces de solventar, como inspeccionar un pdf y comprobar que los datos son correctos o se ven bien, esto puede ayudarnos a cubrir esos puntos ciegos y detectarlos, pero no en todos los sitios existe implantación de RPA y herramientas como Selenium no pueden detectarlos.
Este grupo de puntos ciegos que nos encontramos en herramientas de automatización, también pueden solventarse con pruebas manuales (si, lees bien). Las pruebas manuales que a todo el mundo le resultan de la edad de piedra, efectivamente.
El encontrarnos con muchas herramientas de automatización y tener una implantación bastante amplia no quita que sigamos necesitando este tipo de pruebas, ya que lo que detecta el ojo humano, disculpadme, no lo hace ni dios.
Si al realizar una batería “completa”, no tenemos en cuenta estos puntos ciegos, hay casuísticas que se escapan y por lo tanto, tendremos defectos en producción que vienen dados por la falta de cobertura que nos brindan estas herramientas automáticas. Con esto, no digo que no se usen, si no que se hagan como apoyo y en su justa medida y que sean totalmente complementarias, unas con otras.
Puntos ciegos en pruebas funcionales
Al hablar de este tipo de pruebas, nos viene a la mente el nivel de cobertura que hemos conseguido con nuestro plan de pruebas. Habitualmente, tenemos defectos comunes, que suceden una y otra vez y que hay que cubrir con un caso de regresión y posteriormente automático y los tipos de fallos habituales en la plataforma, que suelen suceder al tocar componentes core o críticos.
En estos casos, solemos comprobar cambios en pestaña haciendo click, girar el dispositivo para ver como se adapta la aplicación o realizar inicios de sesión inyectando datos en la propia URL.
Aquí nos encontramos com problemas de apertura de casuísticas y que, en equipos jóvenes son más frecuentes, ya que se dedican a seguir los pasos, unos tras otro, pero no ha ver que hay a su alrededor y a “perder el foco”, con la realización de unas pruebas exploratorias controladas.
Esto, se solventa con herramientas de Test Management, como ALM Octane y deben de cubrir ese tipo de pruebas a las que las herramientas automáticas no llegan, como ese posicionamiento de la aplicación según se gire el dispositivo.
Si unimos las pruebas manuales con las automáticas, nos encontramos con una cobertura mucho mayor, solventando las casuísticas comentadas anteriormente y una serie de baterías de pruebas (ya sean de regresión o no) que se automatizarán para no dedicar el tiempo a tareas repetitivas o que nos hagan invertir demasiado en ellas.
Si esto, a su vez, lo unimos a una estrategia adecuada de cobertura de casuísticas, ya sea mediante un diagnóstico completo o un trabajo de heurística, no tendremos problemas de agujeros donde se nos escapen defectos.
Estrategias de mejora
En este punto, una vez repasado, a nivel general, diferentes puntos ciegos, vamos a comprobar y verificar ciertas estrategias para que esto no nos suceda, aunque es algo que ya hemos podido ver en párrafos anteriores.
Una tarea que suele ser bastante socorrida es la de sacar listados de 3,4 o 6 meses con defectos que se han escapado, centrándonos en que se rompio, no en la causa raiz de los mismos.
Despues, verificamos y comprobamos cuales son nuestros mecanismos (anteriores y posteriores) para reducir estos defectos o agujeros, ya sea desde la revisión estática de código, procesos humanos o automáticos y con herramientas o no. Si comparamos, lo ideal es hacernos la siguiente pregunta: ¿el proceso de control debería de haber encontrado el problema?
Tras ello, realizaremos una serie de acciones:
- Trabaja mano a mano con las personas implicadas en ese defecto, ya sea el tester, el desarrollador y la persona que diseñó el requisito, encontrando que falló y que no se hizo adecuadamente para que se escapara el problema.
- Una vez tenemos detectado que pasó, hay que revisar todo el proceso de calidad implantado y ajustarlo para que no vuelva a suceder.
- Esto, nos dará que pruebas, controles, inspecciones y kpis hay que reestructurar para cubrir todo adecuadamente, implementando una nueva versión del modelo.
Al final, en algún momento nos encontraremos con un punto ciego, con un agujero en el software o con algún problema que ha escapado de todos los controles, pero si actuamos rápido, hacemos los cambios oportunos y sobre todo, cubrimos los problemas de manera adecuada, veremos como este tipo de “fallos” serán un aprendizaje continuo que nos hará no repetir estas acciones o adelantarnos a que sucedan.
0 Comentarios