¿Cómo ahorrar dinero en el proceso de Pruebas?
Autora: Liliana Gómez Arenas – CEO GreenSQA
Probar software es una actividad profesional que viene evolucionando rápidamente, cada vez hay más tecnología y recursos disponibles en el mercado que exigen al mismo tiempo más inversión para las organizaciones que buscan el estado del arte en este sentido. Al mismo tiempo se ha demostrado que liberar sistemas de información a producción con errores, implica una serie de problemas en cadena, cuya solución generalmente cuesta varias veces más de lo que cuesta la prueba, muestra de esto, el estudio de investigación realizado por Tricentis revela que en el año 2017 los errores de software afectaron a 3.6 billones de personas en el mundo y causaron pérdidas financieras por US$1.7 trillones [1], sin mencionar a nivel interno la fricción y pérdida de confianza del equipo a cargo y a nivel externo, el daño colateral a la imagen y la reputación de la organización, cuando dichos errores llegan o afectan al cliente final.
Un gran volumen de estos errores de software ocurridos en el mundo real, se han convertido en casos de estudio documentados, algunos como los publicados en el blog Bitsrc [2], donde además se analizan sus consecuencias. Nuestra sociedad actual tiene una alta dependencia de la tecnología para el funcionamiento del día a día, por lo cual la necesidad de asegurar la calidad de las soluciones tecnológicas es esencial, porque fallan, y cuando fallan pueden generar consecuencias que van más allá de lo económico. Aún con esta certeza sobre la necesidad de las pruebas, es normal que las organizaciones en búsqueda de la eficiencia presupuestal, tiendan a querer que se hagan pruebas con menos inversión y se empeñen en identificar costos a reducir, para lo cual generalmente se intenta trabajar con menos capacidades de las fábricas de pruebas (horas de pruebas), equipos menos expertos en las mismas, o incluso recortar la cantidad de pruebas a realizar, sin embargo, con cualquiera de estos enfoques, la más afectada es la calidad de la solución final y por supuesto la organización por sus efectos colaterales.
Si es posible ahorrar en el proceso de pruebas y existen mejores alternativas que las anteriormente mencionadas, como por ejemplo, ser más hábil en la definición de la estrategia a usar o más eficiente usando técnicas en el diseño y optimizar la estructura de la prueba como tal. Para referirme a estas alternativas, me baso en el artículo de Maximilian Bauer, en la pasada edición de marzo en stikyminds.com en el cual hace un breve pero interesante análisis sobre algunas recomendaciones para ahorrar dinero a la hora de probar software [3].
Como lo menciona Bauer, las organizaciones actuales por un lado buscan ser ágiles, más rápidas a través de implementaciones como DevOps, acortar su ciclo de lanzamiento de soluciones tecnológicas, ir al mercado lo más rápido posible, integrar todas las pruebas en los pipelines (CI,CD) y ser lo suficientemente genéricas para probar múltiples entornos, ya sean reales o simulados; por otro lado, estas mismas organizaciones enfrentan el reto de no aumentar sus costos dado que estos movimientos requieren presupuesto para invertir en herramientas y servicios que permitan materializar esa visión más integral de su calidad y la mayor cobertura del riesgo posible.
¿Cuál sería el beneficio real de migrar un sistema a la nube y reconstruirlo por completo si no podemos asegurar que los procesos de negocio funcionan como lo hacían antes? ¿Qué sucede si invertimos tiempo y dinero en casos de prueba que cubren solo una porción del riesgo? ¿Cómo se sentiría tener que lidiar con la incertidumbre del desconocimiento porque nadie en el equipo tiene la responsabilidad de verificar la cobertura de la prueba? Como dice Bauer en su artículo, responder estas preguntas pueden contar otra historia…
A medida que los sistemas de información cambian en el tiempo, es necesario definir y mantener ajustados los casos de prueba estables para asegurar su ejecución, pero la realidad es que justamente este mantenimiento consume la mayor parte de la inversión pruebas, sin embargo existen algunas prácticas simples que el autor recomienda para generar ahorros significativos en el proceso de pruebas, las cuales resumo en 4 estrategias: separar, evitar, crear y reducir.
- Separar los objetos técnicos del resto, permite ajustar uno solo para mantener todas las pruebas conectadas, o definir una colección de todos los controles de la aplicación juntos, como una clase base, y reutilizarlos todo el tiempo. Así, los cambios técnicos tendrán menos impacto en las pruebas y facilitarán el mantenimiento.
- Evitar crear casos de pruebas para un conjunto de datos, en su lugar, se puede cambiar a una base de datos y a un enfoque metódico para permitir que los datos se separen del caso de prueba, y parcialmente, incluso, de la herramienta o el código. Con lo cual se podrían agregar más conjuntos de datos o eliminar los obsoletos. Las consultas SQL cambian dinámicamente, dependiendo de los datos de entrada, e incluso se hace posible el uso de datos de producción enmascarados, porque solo afecta los datos en la base de datos, que fue extraída por la consulta.
- Crear bloques de pasos de prueba predefinidos y reutilizarlos como objetos.
Recomienda Bauer en su artículo, que sean lo más genéricos posible y que dependan de los datos que utilicen con condiciones simples. Siempre que se cambie el flujo de trabajo, se tendrá nuevamente un único punto de contacto, y será fácil agregar nuevas variantes a un caso de prueba. Un cambio afectará a todos los casos de prueba, con todos los datos consumidos para un uso y necesidad específico. Bauer y su equipo cambiaron por completo el modelo de pruebas de uno de sus clientes, una empresa de orden mundial, solo agrupando los casos de prueba y extendiéndolos con un enfoque basado en datos. Imaginen marcar un material como no existente en el sistema, y que el caso de prueba pueda saber automáticamente que necesita verificar el mensaje de error en lugar del de éxito, solo con los datos de entrada.
- Reducir los casos de prueba a unidades más pequeñas para ver la secuencia de ellos como el caso de prueba real
Para esto, se debe definir una lista de los casos de prueba que son partes del todo. Los datos recién creados podrían pasar a través de una base de datos y reenviarse dinámicamente mediante un estado predefinido. Este enfoque puede conducir a múltiples repeticiones de varios casos de prueba que generan datos, pero aumentaría la reutilización de los bloques de casos de prueba para permitir un único punto de cambio y reducir los duplicados en toda su línea base. Ya no sería necesario gastar tanto dinero en la creación de nuevos casos afirma Bauer, pues los equipos de prueba simplemente los unen de los bloques predefinidos y tienen que asegurarse que se proporcione el flujo de datos. Solo se deben crear características completamente nuevas, como un nuevo bloque estructurado, que luego se puede agregar a la biblioteca de pasos de prueba. Cada vez que otro caso de prueba pasa su nueva función (o aplicación en el medio), el nuevo bloque se atraerá a su caso de prueba, y cada vez que cambie, existe la necesidad de un solo cambio en este bloque específico.
En su artículo menciona Bauer que también se puede ahorrar dinero en la fase de planificación y configuración inicial de las pruebas: ¿imaginen cuánto más rápido podría ser el proceso para evaluar la calidad si se crean los datos de prueba anticipadamente?; y en lugar de crearlos manualmente o mediante casos de prueba basados en la interfaz de usuario, los datos se podrían obtener de una base de datos seleccionando casos de prueba, sin importar si están vinculados a un caso específico o si se seleccionan según ciertos criterios.
Si estamos en un entorno de micro servicios, se podrían ejecutar APIs automáticamente, sin supervisión y en paralelo, para configurar el entorno listo para la prueba y estar preparado para las ejecuciones de casos de prueba automatizados. Se estarían creando casos de prueba que no son de IU para crear u obtener datos de prueba y, según la configuración, se podrían almacenar en una base de datos o “invocar” a los servicios directamente durante la prueba.
La virtualización del servicio es otra recomendación de Bauer para ahorrar costos en hardware, al tiempo que se hace “shift-left”, se optimiza el tiempo de actividad de la prueba, esto logra aprovisionar ambientes tan rápido como los orquestadores (ARM, Terraform, CloudFormation, etc.) interpretan el código fuente de la infraestructura. En este caso es recomendable asegurar las dependencias al principio del proceso de prueba para evitar el tiempo de inactividad y configurar sustitutos para aplicaciones, características o servicios web inestables. Así mismo, recomienda estandarizar las herramientas y los métodos para reducir los costos de escalamiento y adoptar informes sencillos y poderosos sin necesidad de integrar múltiples herramientas.
Como se ha visto, existen diversas formas más innovadoras de ahorrar costos en las pruebas que no sacrifican calidad ni generan costos ocultos; la anticipación será también clave en este proceso y más eficiente que desarrollar o cambiar en caliente durante la ejecución de las pruebas. En cualquier caso, definir estructuras claras y priorizar pruebas estratégicas, respaldadas por un enfoque basado en objetos o modelos, tendrían un altísimo aporte para lograr éxito.
Recogiendo el espíritu de Baver, como organización, le invito a contar con un aliado en pruebas para pensar dos veces en su transformación tecnológica, para pensar en grande y lograr que de principio a fin pueda usar un marco confiable y reutilizable que no solo garantice calidad sino un mejor presupuesto de inversión para su crecimiento tecnológico.
[3] https://www.stickyminds.com/article/where-your-money-lost-testing
Autora: Liliana Gómez Arenas – CEO GreenSQA
