Cuatro pasos para paliar la escasez de talento en la garantía de calidad

A medida que el mercado de trabajo más amplio se va estrechando, los trabajadores del sector de las TI siguen siendo escasos, con una tasa de desempleo del 2,2%.  Junto con los desarrolladores de software y los analistas de seguridad, algunos de los trabajadores de TI más difíciles de encontrar son los profesionales de control de calidad. Aún más escaso es el verdadero unicornio del mundo de la garantía de calidad de las TI: el SDET (Ingeniero de Desarrollo de Software en Prueba).

Una encuesta reciente de Jetbrains reveló que el 44% de los equipos tenía menos de un probador de control de calidad por cada 10 desarrolladores. Esta proporción de probadores por desarrollador abre la puerta a que se cuelen pequeños pero costosos errores.

Aquí hay cuatro maneras de aliviar la presión de los conjuntos de habilidades de control de calidad adicionales y garantizar que el mejor código llegue al mercado.

Emplear la automatización de pruebas, pero conocer sus límites

Invertir en la automatización es una forma de mitigar la escasez de talento y de eliminar las tareas tediosas de los ocupados equipos de control de calidad. Las pruebas que se repiten varias veces en cada compilación o que deben ejecutarse en varios entornos son ideales para la automatización de pruebas.

Aunque la automatización tiene un claro valor, los probadores manuales deben seguir formando parte del proceso. Al aportar intuición y escrutinio sobre cómo se supone que funciona una aplicación, los probadores manuales pueden detectar fallos que una prueba automatizada no puede.

Elevar las habilidades de control de calidad

Aunque la automatización de las pruebas ha permitido acelerar los ciclos de lanzamiento, también ha creado la necesidad de desarrollar conjuntos de habilidades que puedan seguir el ritmo de una producción más rápida. El aumento de la función de SDET es el ejemplo perfecto de la evolución de las expectativas y responsabilidades.

Los SDET poseen una variedad de aptitudes de prueba y desarrollo, como la escritura de scripts para integraciones, API, UI y pruebas de criterios de aceptación. Para hacerlo de forma eficaz, deben comprender la arquitectura, desde cómo funciona la aplicación hasta cómo se supone que debe funcionar. Se trata de un avance significativo, ya que muchos profesionales del control de calidad no escriben código, lo que le dificulta el paso a la función cada vez más importante de SDET. Para las empresas, esta elevación del conjunto de habilidades es un recordatorio de que las capacidades de control de calidad pueden ampliarse a través de los equipos de desarrollo.   

Emplear herramientas de bajo código/sin código

En lugar de añadir más probadores dedicados, algunas organizaciones encargan a los desarrolladores que prueben más su propio código. Sin embargo, esto puede ser problemático, ya que los desarrolladores suelen ser parciales en cuanto a la verdadera calidad de sus propios resultados. Hacer que otros desarrolladores revisen y prueben el código escrito por otros es una forma más eficaz de garantizar la calidad.

Sin embargo, una consideración importante a la hora de utilizar a los desarrolladores para el control de calidad es el tiempo que se resta al proceso de creación de software. Afortunadamente, están saliendo al mercado soluciones que pueden mitigar el tiempo que los desarrolladores dedican a realizar algunas de las tareas que normalmente ejecuta el SDET. Las soluciones de prueba sin código o de bajo código están permitiendo a los desarrolladores construir rápidamente programas para probar el código sin crearlo desde cero.

Las soluciones sin código también pueden permitir que los no desarrolladores participen más en el proceso de pruebas. El estudio de Jetbrains mostró que en el 29% de los proyectos, más de la mitad del equipo de control de calidad sigue realizando únicamente pruebas manuales. Proporcionar a los no desarrolladores más herramientas para crear automatizaciones de pruebas puede aumentar la productividad general, maximizar los recursos existentes y reducir la necesidad de probadores de control de calidad. Los propietarios de los productos, que tal vez son los que mejor conocen los casos de uso y el rendimiento que se espera del producto, también pueden participar más en el proceso de pruebas con estas herramientas.

Poner a trabajar la IA

Los rápidos cambios en el código y las cadencias de lanzamiento también ejercen una gran presión sobre los equipos de control de calidad para que ajusten las pruebas con mayor frecuencia. En este caso, la IA puede desplegarse para apoyar el control de calidad:

· Identificando automáticamente los cambios en el código y actualizando las secuencias de comandos de prueba que se dirigen al nuevo código.

· Aprendiendo de las reparaciones de código anteriores y sugiriendo correcciones.

· Analizar los productos para identificar las áreas en las que el código no está cubierto por las pruebas y crear pruebas para cubrirlas

· Diferenciar entre los errores y los cambios menores en la interfaz de usuario.

El aumento de las capacidades de control de calidad en el resto del equipo no sólo ayuda a abordar la necesidad inmediata de talento, sino que también demuestra el valor de hacer que el control de calidad sea responsabilidad de todo el grupo de desarrollo de productos.