Inteligencia en la evolución de la calidad del software

He estado trabajando en el desarrollo de software por algún tiempo. En los últimos diez años, me he centrado fuertemente en procesos, pruebas y calidad con un aspecto más técnico, que es mi background. Fui desarrollador durante más de diez años antes de migrar mi punto de vista.

Las personas que han sido jóvenes durante más tiempo, como yo, han tenido la oportunidad de ver cambios profundos en todo el proceso de creación de software, pero especialmente en la calidad.

Las expectativas han cambiado mucho. Hace algún tiempo, dos semanas era el tiempo necesario para programar las primeras reuniones de planificación de características para un nuevo sistema, no el tiempo para entregar un producto pequeño y viable. Estos plazos más cortos generan una fuerte presión sobre los procesos de calidad, que deben ser entregados rápidamente y funcionando.

No había tanta confianza en el software. Hace 35 años, en 1985, las máquinas de autenticación de los bancos eran electromecánicas. El registro de transacciones era la cinta de papel, que copiaba cada autenticación realizada; además, los saldos de cuenta corriente llegaban en una lista en la mañana en la agencia, y por cada débito o crédito que ocurrieron, los empleados hacían anotaciones con un bolígrafo en la lista. Por otro lado, si faltaba energía, los bancos continuaban trabajando, y los cajeros usaban manivelas para operar las máquinas de autenticación. Una falla en el suministro de electricidad (o cualquier otra falla que sea un show stopper) hoy es prácticamente un caos, porque no podemos hacer circular la información con la velocidad necesaria para el requisito actual. Gran presión sobre la calidad.

Otra fuente de presión es la disponibilidad de alternativas. Hablando de manera simple y concreta, si tu aplicación falla o es lenta, el riesgo de que el usuario lo desinstale y busque una alternativa de un competidor es inmenso. La posibilidad de que encuentre esta alternativa muy fácilmente también es inmensa.

No estoy diciendo que solo la calidad ha sido afectada. Todo el proceso de desarrollo tuvo que evolucionar de una manera vertiginosa, y, afortunadamente, lo hizo. Sin embargo, limitaré el alcance de esta conversación a la calidad; aun así, tendremos que mantenernos en un nivel de abstracción algo alto, para que podamos, dentro del alcance de un artículo, discutir las posibilidades de aplicar métodos, enfoques y procesos inteligentes en la calidad del software.

Es un hecho que hemos recorrido un largo camino, pero aún queda mucho por hacer, y la perspectiva es que la velocidad del cambio continuará aumentando y exigiendo más y más eficiencia.

Hablando de inteligencia en el esfuerzo de calidad, algunos temas vienen a la mente:

· La inversión debe adaptarse a las necesidades del negocio. Las necesidades de un hotsite que tendrá cuatro meses de vida, de un CRM y de un software de monitoreo de UCI son totalmente diferentes.

· De acuerdo con las características de mi negocio, necesito invertir más donde la relación costo/beneficio es mayor.

· La retroalimentación de calidad debe ser ligera (poder ejecutarse cuando sea necesario) para que sea frecuente y traiga preguntas y respuestas cuando sea necesario.

· Las informaciones relevantes deben llegar al destino rápidamente.

· Las fallas de producción deben ser proporcionales a la tolerancia de cada negocio. Si no hay tolerancia, no puede haber falla.

· Fallos y falta de eficiencia en la calidad: ¿quién observa al observador?

· Repetibilidad: la regresión de funcionalidades no puede existir; una nueva característica no puede detener a otra que ya existía.

Teniendo en cuenta todos estos puntos, la primera palabra que se me ocurre (y espero que a ti también) es automatización. Es necesaria y fundamental; sin ella, no es posible abordar con éxito todas estas necesidades. Sin embargo, además de ser necesaria y fundamental, es exigente. Cuando hablamos de automatización de calidad, debemos pensar en las necesidades de su negocio y su sistema en varias dimensiones diferentes.

Aquí 7 ejemplos a considerar para tener una automatización de calidad:

· Automatización de pruebas funcionales y no funcionales: primer punto que viene a la mente sobre la automatización de calidad. Existen varios tipos y niveles diferentes de validaciones y verificaciones aplicables a diferentes situaciones y contextos. La relación costo / beneficio de cada tipo y nivel de automatización de prueba es muy variable, y debemos tener en cuenta que debemos hacer con las pruebas más “caras” solo lo que no se puede hacer de otra manera. De forma simplista, este es el resumen de la teoría de la pirámide de pruebas; presentada por Mike Cohn en 2009 y defendida brillantemente por Martin Fowler en varios artículos. Desafortunadamente, sigue siendo un tema en el que muchas personas buenas aún cometen errores y terminan consumiendo más tiempo y recursos para validar sus sistemas de lo necesario.

· Automatización del ciclo de construcción y publicación de software: no es de extrañar que se hable tanto de DevOps, DevSecOps, SRE. Aquí es donde hacemos controles de calidad del código, cumplimiento de los estándares, realizamos la compilación de forma automatizada e independiente del desarrollador y su máquina, realizamos las pruebas apropiadas para la respuesta rápida de la pregunta ‘¿se rompió algo que no podría romperse en esta compilación?’. Fundamental para que el feedback rápido que comentamos antes sea viable. Con un proceso ajustado, nuestra deuda técnica no crece, las respuestas sobre la calidad llegan antes que las preguntas y el time to market se reduce de manera impresionante. Sin embargo, puede ser un desagüe de recursos y un cuello de botella si se implementa mal.

· Automatización de la recopilación de resultados: lo que no se mide, informa y repite no existe. ¿Ha mejorado? ¿Ha empeorado? ¿Cuántas fallas ocurrieron en el tiempo de desarrollo? ¿Y de homologación? ¿Y en producción? ¿Qué áreas del sistema son más frágiles y causan más problemas? ¿El número de problemas está directamente relacionado con el volumen de entregas o hay otros problemas involucrados? Esta colección de resultados se vuelve aún más importante cuando pensamos en un universo que comienza a obtener beneficios de la inteligencia

artificial. Los procesos de IA se construyen con datos; sin datos históricos no hay información, no hay entrenamiento de modelos inteligentes, no hay resultados.

· Automatizar la generación de casos de prueba. Todavía se parece un poco a la ciencia ficción, pero ya es bastante viable facilitar la generación de casos de prueba utilizando inteligencia artificial. En everis ya tenemos herramientas que nos ayudan a convertir el lenguaje natural en pruebas automatizadas de manera concreta.

· Automatización de la generación de masa de datos. Aquellos que han trabajado con pruebas o desarrollo durante más de dos semanas y nunca han tenido problemas con la masa de datos pueden tirar la primera piedra. Ya sea un backup o un snapshot, una herramienta de virtualización o extracción enmascarada, un generador automático o un equipo especializado: todos necesitan una forma de soporte para la generación de sus masas de datos, de lo contrario, la verificación y validación no es factible.

· Automatización de entornos. Misma pregunta que la anterior: ¿quién es del sector y nunca ha tenido problemas para crear entornos? Muchas personas se justifican diciendo que tener entornos para ejecutar las pruebas es muy costoso, por lo que no es factible; ¿alguna vez se han detenido a pensar en el costo de no ejecutar las pruebas? Piénsenlo. Ya sea en la nube, en contenedores, on premises, máquinas virtuales o servicios virtualizados. ¿Cuál es el “sabor” de la automatización de entornos que satisface perfectamente sus necesidades?

· Automatización de controles de seguridad. Subtipo especializado de pruebas funcionales, pero que merece especial atención. ¿Cuál es el valor de tus datos, tu sistema o la ausencia de los mismos? Si es bajo, ignore esta preocupación. Caso contrario, si no estás tomando ninguna acción concreta, preocúpate. It’s a jungle out there.

La buena noticia es que hay muchas alternativas para evaluar, algunas más recientes y otras ya ancianas. Traté de asociar con cada dimensión mencionada una serie de respuestas que se aplican en algunos escenarios. Sin embargo, debemos verificar la sinergia entre nuestras elecciones para cada dimensión, de acuerdo con las características del sistema bajo prueba.

Finalmente, pueden decirme: “Pero, Rui, estamos hablando de calidad y tú solo hablas de automatización. ¿No hay más valor en las pruebas manuales?”. Por supuesto que lo hay, son fundamentales en las pruebas exploratorias, en aquellas (pocas) situaciones en las que no es posible automatizar y llevar ese aspecto experimentado de un probador acostumbrado a localizar problemas. Sin embargo, coloco las pruebas manuales en el contexto de la pirámide de prueba que mencioné anteriormente; es la prueba más cara que tenemos en el “menú”, y debe usarse solo cuando sea necesario.

Sonríe, mañana será más difícil, con necesidades más desafiantes. Esto es lo que mantiene el mundo de la calidad (y el software) tan divertido.