Sólo el 1% de las empresas Agile dicen no tener problemas

Como cada año por estas fechas desde 2008, el proveedor de servicios profesionales de tecnología y high-tech consulting, en colaboración de Capgemini (de la que es filial) y en esta novena edición con participación de Micro Focus, publica su Global Quality Report (GQR17) sobre calidad en los procesos de desarrollo de software.

De las 1.600 entrevistas a decisores MDIT de 32 países, este año se ha tenido en cuenta una adenda específica para el Sur de Europa (España, Portugal e Italia), que cómo es de esperar presentan un diferencial de madurez respecto al resto del continente. Aun así, las 35 empresas españolas consultadas en el informe ofrecen interesantes pistas sobre los departamentos DevOps nacionales, como es la mayor concienciación respecto a estas prácticas de testing y Quality Assurance (QA), donde la primera respuesta ya no es por detectar defectos en fase de desarrollo o producción, sino por mejorar las relaciones con clientes, que es lo que de verdad impacta en los resultados de negocio.

La primera conclusión es buena: las empresas dedicaron el 26% de sus presupuestos TI a las tareas de QA, una parte fundamental para asegurar la calidad del software. “En Sogeti consideramos que un porcentaje óptimo debe situarse en una banda de entre 25 y 30%. En 2015 era un 33%, y en 2016, el 31%. Este descenso, lejos de ser una mala noticia, ya lo vaticinábamos debido a una serie de razones, la primera es que somos más maduros y performantes”, explica José Luis Antón, responsable del área Control, Testing & QA de Sogeti. “Le sigue la adopción de las filosofías Agile y DevOps en las organizaciones, que según declaran alcanza ya al 96%, o al menos contemplan proyectos bajo estas metodologías. Sin embargo, el hecho de que los perfiles ahora sean más polivalentes y los equipos estén mezclados con gente especializada en desarrollo, otros en calidad, y otros en sistemas, dificulta la asignación de unas métricas para medir el dinero invertido. Antes, al ser una actividad centralizada y definida, el presupuesto estaba ajustado a un desarrollo y a un resultado. Ahora las fronteras se diluyen”.

Lo que sí tiene claro el consultor de Sogeti es que por debajo tiene que estar Negocio, no IT. “El objetivo número uno de aplicar QA es ser más rápidos, o al menos, más rápido que mi competencia, pero si por hacer DevOps por moda voy a ir más lento que antes, no me interesa”, dice Antón. “Ni todos los sistemas son susceptibles de estar en DevOps ni todas las aplicaciones van a estar en este mundo. La convivencia de los dos mundos, el tradicional y el digital, obliga a adoptar una estrategia bimodal, donde lo importante será para qué lo quiero y cómo va a beneficiar a mi organización”.

Hasta hace un tiempo (apenas dos o tres años), las métricas del QA se referían al número de bugs que iba a tener en producción cada nuevo requerimiento funcional introducido. Hoy la tendencia es a valorar más y garantizar la experiencia de usuario; se da por sobreentendido que la performance del software va a ser la adecuada y el número de fallos asumibles (de ahí la importancia de automatizar las tareas de prueba y testeo antes de entrar en producción para limitar el número de fallos lo máximo posible: esto va a depender de lo bien diseñados que estén los casos de prueba, de saber qué es lo que hay que probar, del aprovechamiento de elementos ya testados, etc.).

“No hay una herramienta estándar para el QA que se pueda comprar en la tienda. Cada organización es distinta, tiene unas prioridades y unas necesidades diferentes, el desarrollo de software es como un rompecabezas, hay piezas que pueden ser comunes y reutilizables, otras piezas que hay que hacer a medida, y otras piezas que nos van a faltar”, señala el consultor de Sogeti. “Lo que va a marcar la diferencia es la manera de enfocar el proyecto por parte de sus responsables, para desplegarlo paso a paso de manera concienzuda. No es abrir y cerrar la puerta y ya soy DevOps. Hay que entender el proceso y el ciclo de diseño-desarrollo-prueba-producción para aplicar QA desde el principio y en toda la cadena, lo que ya hacen el 30% de los encuestados”.

Lo que también está claro es que cada vez la cantidad de pruebas van a ser mayores y en un mayor número de escenarios: “el futuro del QA pasa por la cantidad de pruebas a realizar, cada vez más numerosas; con los canales a comprobar, ya que las empresas tienden a ser omnicanales, teléfono, web, móvil, cada vez más complejos. Las pruebas se van multiplicando cada vez por números más altos, por lo que la automatización cognitiva y la aplicación de machine learning es fundamental, porque cada vez será más humanamente imposible realizar las pruebas de manera manual, además de que lo manual es por definición lento”. El continuous delivery obliga a acortar los ciclos de desarrollo y a estar continuamente lanzando nuevas features cada semana, por lo que la fase de testing y QA debe ser lo más automatizada posible. Ya nadie desarrolla pensando en años, ni siquiera en semestres.

Por eso el GQR17 ya señala una serie de técnicas emergentes que potenciarán esta área de cara al 2020, cuando se duplique (32%) el número de organizaciones que empleen de manera natural nuevos paradigmas basados en smart analytics (como el testing predictivo y la autoreparación) para atender los proyectos cada vez más numerosos en movilidad e IoT. “Algunos proyectos de este tipo ya son una realidad. Cuando hablamos de machine learning no se lo creen, pero ya podemos decir que tenemos en fase piloto tres proyectos, dos de antes del verano y una aseguradora que empezó en octubre”, confiesa Antón.

El tema de la seguridad

Se ha dejado para el final este tema, que para las empresas españolas supone el 63% de sus preocupaciones (frente al 57% de las portuguesas y el 48% de las italianas). Una tendencia general es que los equipos DevOps se están enriqueciendo con perfiles de seguridad y pasan a denominarse SecOps. Sin embargo, la inminente entrada en vigor el próximo mes de mayo de la directiva RGPD ha disparado entre las empresas españolas el temor a las sanciones y a extremar las precauciones.

Así, en los entornos de prueba se han preocupado de que los datos de trabajo cumplan los requisitos de anonimanización, y que los datos personales estén ocultos o enmascarados para el compliance. Esto ha dificultado en muchas ocasiones la disponibilidad de datos de prueba y poder replicar entornos de producción para diseñar la automatización de pruebas AB y QA, en especial en mobile testing.

“Desde principios de 2016 en Sogeti ya realizamos proyectos de anonimación de datos, pero cada vez son más las peticiones que nos llegan porque se acaba el tiempo. Las organizaciones cada vez más están buscando soluciones para la manipulación de datos alineados con el RGPD. No todos, como señala nuestra encuesta, hay un 37% que no, pero no tanto porque lo tengan ya resuelto, sino porque no están del todo concienciados o no le dan la suficiente importancia”, dice Antón. “Antes del RGPD ya estaba funcionando la LOPD, pero en muchas empresas las preguntas eran ‘¿cuánto es la multa?’ y ‘¿cuánto el proyecto?’, y nos decían ‘entonces espero a que venga la multa’. Ahora que las multas son más altas, habrá más interés”.

La recomendación final del consultor de Sogeti es que las empresas tengan el presupuesto adecuado para cumplir con el RGPD. “Pero claro, el 4% de la facturación sería impensable, así que habrá que priorizar, no basta destinar un presupuesto para encriptar una determinada aplicación, sino tener una estrategia global”.