El desafío actual de QA…

Creo que el mejor software es aquel que se utiliza mientras el usuario hace su trabajo, crear software para ser usado luego del trabajo como documentación post tarea no es del todo efectivo y la única forma de lograr su uso es obligando de una forma u otra a las personas a hacerlo.
La historia dice por sí sola, que la documentación del software tiene dos problemas importantes, uno es que es necesario tiempo extra para poder generarla y luego leerla e interpretarla.
Si logramos que el sistema de trabajo sea autodocumentado puede ser solucionado sin esfuerzo, ahora tenemos el segundo problema, Lleva también tiempo leerla pero además la libre interpretación conlleva un problema en sí dado que a través de los años cada párrafo puede cambiar de forma por el conocimiento de base del lector.
Las metodologías ágiles ponen foco a este problema dando lugar a uno de sus manifiestos y en una forma correcta logran una velocidad estupenda en la tarea del desarrollo donde a su vez gracias a las nuevas herramientas queda autodocumentado, quizá no con el detalle deseado en el pasado pero sí, con la eficacia suficiente.
Otra de las innovaciones que hacen mejorar otra de las tareas importantes en el desarrollo de software esta aparejada a DevOps donde gracias a herramientas como docker y su forma de auto documentar los procesos de creación de infraestructura lograron aumentar la velocidad, control y reproducibilidad, muchos de los problema del pasado.
Por otra parte, el área de QA está siendo la que más afectada se encuentra debido a la falta de automatización y la reducida velocidad en sus procesos los cuales, con ayuda de herramientas de desarrollo de software, disminuyen esa brecha, pero se ven desplazados sus recursos humanos por su falta de respuesta.
Cabe destacar que tal como pasa en todos los casos la madurez del equipo en la utilización de las herramientas es directamente proporcional al éxito del objetivo.
A la hora de disminuir el time to market del software es fundamental encontrar una solución a esto sin la necesidad de desplazar al personal de QA y a su vez no generar más dependencia de recursos calificado en desarrollo de software.
Hace ya más de 3 años que me dedico al área de QA Automation como QA Automation Engineer. Todo comenzó gracias a mi experiencia en desarrollo, contaba con más de 10 años desarrollando java, pero estoy seguro que tanto conocimiento es innecesario para solo desarrollar casos de prueba. Una vez que el proyecto base está completo, uniendo todas las partes: el runner, el intérprete gherkin, el reporting, los datasets, etc, con muy poco conocimiento puede desarrollarse casos de prueba sin necesidad de complejizar nada y llegando a un buen resultado. Este es uno de los motivos por los cuales armamos el framework lippia, un proyecto base que sirva para cualquier tipo de proyecto de pruebas automatizadas: web, mobile, api, performance, base de datos, seguridad, accesibilidad y en realidad cualquier tipo de pruebas dado que todo lo que va surgiendo lo vamos agregando. Si bien esto es muy útil, sigue existiendo una alta demanda de personal con conocimientos en desarrollo, programadores sin mucho conocimiento pero en si con algo, lo que deriva con mucha probabilidad en que deje afuera a muchos QA muy capacitados no solo por su bajo conocimiento en desarrollo sino que también quizá al desinterés por esta rama de la ingeniería de software.
Para esto es necesario una serie de herramientas que logren una auto documentación y la posibilidad de reutilización o automatización en futuras ejecuciones, tal como lo hacen las herramientas de CI/CD en desarrollo o los contenedores en el caso de operaciones.
Es nuestro desafío encontrar una forma de lograr esto y es donde se encuentra nuestro esfuerzo en investigador y desarrollo.

Leave a Reply

Your email address will not be published. Required fields are marked *