Acabamos de terminar nuestra participación en tres eventos casi consecutivos dedicados a la calidad del software. Empezamos en Londres con National Testing Software Conference (NTSC) y Testing, Agile, DevOps & Low Code Showcase , y terminamos en Madrid con ExpoQA23. Acudimos con la intención de aprender de ponentes, patrocinadores y asistentes. También quisimos poner a prueba alguna de las hipótesis con las que trabajamos para diseñar productos que, como icaria TDM, contribuyen a mejorar la calidad del software.

El nivel de automatización de pruebas es muy bajo

El informe World Quality Report 2021-22, publicado por Capgemini y Sogeti tiene un tono positivo y constructivo, ilusionante sobre los retos de sqa. Sin embargo, algunos indicadores revelan que todavía hay áreas de mejora. Uno de estos indicadores es especialmente preocupante: solo el 15-20% de los casos de prueba de regresión han sido automatizados. Dado que nuestra industria se dedica precisamente a la automatización, este dato es una señal de alerta.

Los 3 inputs del caso de prueba

Los tres inputs más importantes de un caso de prueba son: software, acciones del usuario (ya sea humano o automático) y datos. El software pasa por numerosas revisiones y pruebas unitarias, y las acciones del usuario están diseñadas específicamente para cada caso de prueba.

Pero, qué pasa con los datos?

Al preparar nuestras exposiciones, partimos de la hipótesis de que frecuentemente los probadores utilizan datos de prueba de baja calidad. Como bien sabemos, si los datos de entrada son de baja calidad, los resultados serán igualmente deficientes, lo que imposibilita una ejecución automatizada eficiente.

Enfocamos nuestras presentaciones a partir de esta hipótesis, en busca de la validación o el desafío de los especialistas en QA, tanto en Londres como en Madrid. Aunque nuestras conversaciones no nos proporcionaron datos estadísticamente significativos, la información cualitativa que obtuvimos fue extremadamente valiosa, dado el alto nivel de experiencia de nuestros interlocutores.

Identificamos que una petición recurrente era "generar" datos de prueba de manera más eficiente. Los equipos de QA frecuentemente utilizan hojas de Excel, crean datos manualmente, o generan datos mediante scripts de automatización. Sin embargo, estos datos presentan varios problemas: son estructuralmente simples, no suelen ser consistentes entre distintas aplicaciones, no tienen antigüedad, carecen de variedad y riqueza funcional, y no están creados con versiones antiguas de la aplicación. Además, no se pueden reutilizar.

Por otro lado, los datos de producción, que suelen estar en el origen de los errores detectados por los clientes finales o usuarios, son complejos, consistentes entre aplicaciones, antiguos, variados, y han sido creados con versiones anteriores del software.

No es de extrañar que los datos "generados" de manera artificial no sean adecuados para probar el software de manera efectiva.

Hay datos para probar abundantes y de calidad

La realidad es que disponemos de una cantidad casi ilimitada de datos de producción adecuados para pruebas. El desafío radica en aprender a usarlos de manera eficiente y segura, cumpliendo gdpr: localizarlos, disociarlos y entregarlos a demanda en el entorno de pruebas adecuado, tantas veces como sea necesario.

icaria TDM sabe cómo encontrar en la producción el cliente que necesitas para cada caso de prueba, disociar los datos sensibles y entregarlo a demanda en el entorno de pruebas adecuado. Tantas veces como sea necesario.

Si quieres aprender más sobre el proceso de gestión de datos de prueba revisa las principales características de icaria TDM o echa un vistazo a los videos del canal de icaria Technology.

Si tienes retos relacionados con la gestión de datos de prueba y quieres superarlos, ponte en contacto con nosotros.