Los cambios que la tecnología está incorporando a las empresas en los últimos años y la rápida incorporación que estos tienen, están llevando a las empresas a correr importantes riesgos que pueden hacer perder competitividad y serias dudas a la hora de tomar decisiones.
A raíz de proliferar estas situaciones comienza a desarrollarse en España la figura del testing como garantía de calidad del software. Pero ¿Cómo se encuentra nuestro país en este sentido? ¿Es un mercado maduro? ¿Se toman medidas al respecto? ¿Está la empresa española concienciada para analizar sus soluciones antes de implantar, cambiar, migrar o en definitiva alterar de alguna forma su instalación?
Estos entre otros temas se han abordado en este reportaje, en el que han intervenido Edmundo Treviño Gelover, director de la oficina española de BSD Enterprise, Rebeca Márquez, Technical Account Manager de BORLAND, Micro Focus, Javier Sánchez López, responsable del Centro de Excelencia de Panel Testing y Etienne Bertrand, director de DevOps de IBM España, Portugal, Grecia e Israel.
A Edmundo Treviño Gelover, director de la oficina española de BSD Enterprise, cuando le preguntamos ¿qué es el testing y en qué se diferencia de la garantía del software?, nos responde que desde que comenzaron las prácticas de desarrollo de software, han existido procedimientos para probar los programas que se producían: primero con pruebas ejecutadas por los propios desarrolladores con foco en la economía del rendimiento y en la robustez funcional, y posteriormente, desde hace ya más de una década, por la ejecución sistemática de pruebas realizadas por profesionales especializados en pruebas (testing). La creciente profesionalización de los especialistas de pruebas y su consiguiente segregación de funciones respecto de la construcción de software, ha evolucionado hasta llegar al concepto de garantía de software que cubre todo el espectro de pruebas posible: desde aspectos funcionales, como de usabilidad, de rendimiento, de sustentabilidad, de seguridad, de fiabilidad, de portabilidad, de compatibilidad y hasta de cumplimiento normativo.
Por su parte, Rebeca Márquez, Technical Account Manager de BORLAND, Micro Focus, va aún más lejos y apunta que el testing permite comprobar que un software, una aplicación, funciona correctamente en uno o más dispositivos antes de su puesta en operación. También permite someterlas a pruebas de estrés en situaciones de máxima concurrencia de usuarios y comprobar que siguen funcionando correctamente con tiempos de respuesta adecuados. Se puede aplicar a lo largo de todo el ciclo de vida de las aplicaciones y resulta clave en las diferentes fases de desarrollo. Forma parte de la garantía del software pero no es lo mismo: un software puede estar correctamente diseñado pero no ser eficiente. Permite comprobar que es bueno y que funciona bien en cualquier situación.
Javier Sánchez López, responsable del Centro de Excelencia de Panel Testing, afirma que ningún producto del mercado, incluido el software, está exento de fallos. Por esta razón la garantía del software, es decir, el Aseguramiento de la Calidad del Software (SQA-Software Quality Assurance) es un conjunto de actividades encaminadas a monitorizar los procesos de ingeniería del software y aplicar métodos para asegurar su calidad.
El testing es, por tanto, una actividad más del SQA que se encarga de identificar errores en el software y minimizar al máximo los posibles fallos antes de su puesta en funcionamiento, verificando y validando que el nuevo sistema es el adecuado, funciona correctamente y es fiable. Se trata además de identificar errores en el software lo más pronto posible, pues el coste de corregir un error aumenta a medida que se avanza en el desarrollo del sistema.
Etienne Bertrand, director de DevOps de IBM España, Portugal, Grecia e Israel, coincide en lo esencial pero va aún más lejos, afirmando que mientras que la garantía de software que ofrece un fabricante a sus clientes establece las condiciones mediante las cuales el fabricante corrige defectos o fallos que pueda tener el software vendido durante el periodo de postventa, el testing es una disciplina que permite medir cuál es la calidad del software que se está testeando. Los profesionales que desempeñan esta disciplina suelen utilizar un conjunto compuesto por metodología, herramientas, y prácticas que les permite valorar y cuantificar el nivel de calidad que tiene el software testeado y compararlo con el esperado.
Implementación y madurez del mercado
Sobre la implantación en nuestro país y la madurez del mercado, Treviño comenta que en España estamos en un nivel de madurez intermedio, con empresas punteras en la aplicación de métodos científicos de pruebas, hasta empresas, que aún en la segunda década del siglo XXI, siguen utilizando los patrones tradicionales de pruebas de software del último cuarto del siglo pasado. De forma endémica, las empresas españolas reaccionan lentamente al concepto de calidad: pocas son las empresas que toman esta dimensión como eje fundamental de sus operaciones. Es a través de las multinacionales por donde llega la influencia para incorporar la calidad como parte intrínseca de la producción de software y como elemento de competitividad. Baste indicar la diferencia que todavía existe entre el porcentaje que las empresas españolas que invierten en calidad de software frente a las multinacionales con presencia internacional.
Otro aspecto a tener en cuenta para identificar la madurez del mercado radica en el número de profesionales certificados en las distintas prácticas de la calidad de software. La formación continua ya está totalmente asumida en el mundo del desarrollo de software, pero en los temas de calidad, esta formación no tiene la misma prioridad. Desde los puestos directivos de tecnología se pone más foco en la producción para cumplir metas y métricas internas, y no en la producción inteligente de software y que satisfaga completamente las necesidades de los clientes.
Márquez opina que en nuestro país está muy arraigada la fórmula de aprender de los errores, aun cuando el modelo sea terriblemente costoso en tiempo y dinero. Poco a poco el testing va ganando fuerza, especialmente por las necesidades que plantean los nuevos desarrollos orientado a la Web y la movilidad. Ya no se trata solo de que el software funcione correctamente y sea eficiente, sino que lo haga sobre cualquier navegador, sobre cualquier sistema operativo y sobre cualquier tipo de dispositivo. Poco a poco el mercado va madurando y ya existe una cultura de testing, especialmente en las empresas que desarrollan para terceros.
Por su parte Sánchez piensa que el mercado del testing aún no es un mercado maduro, al menos en España. Además, antes del año 2012, el mercado del software testing era muy distinto, pues estaba focalizado en el segmento de gran cliente. Fruto de una pobre planificación en muchos procesos de creación de SW, y la falta de metodologías ALM basadas en el aseguramiento de la calidad, se realizaban proyectos de testing de gran volumen, con continuidad en el tiempo y demanda estable, y con modelos clásicos de gestión de las pruebas, o sea, basados en modelos teórico-predictivos.
El escenario actual sin embargo ha cambiado. Existe una enorme presión sobre los costes de las áreas de SI de las organizaciones y la Calidad es un factor muy comprometido por esta presión, lo cual lleva a muchas empresas a cuestionarse si un proceso de verificación y validación independiente implicará un sobrecoste innecesario. Además, existen nuevos escenarios metodológicos ágiles, donde la filosofía de equipos multidisciplinares y actividades solapadas deja menos cabida al modelo de verificación y validación independiente (ISVV).
En la actualidad nos encontramos, en definitiva, con proyectos de pequeño volumen, con planificaciones muy ajustadas, condicionados a una dependencia presupuestaria creciente y, por tanto, a una demanda variable más complicada de gestionar.
Para Bertrand hay dos categorías de empresas: las que fabrican productos complejos con software embarcado, como los aviones, trenes, coches, equipos medicinales o “empresas System” y el resto de las empresas que fabrican software de gestión o “empresas TI”. Para entender la diferencia en lo que a testing se refiere podemos decir que las empresas System invierten el 80% de los recursos de producción de software en testing, mientras que las empresas de TI un 35%.
Las primeras muestran un larga tradición en esta disciplina mientras, que la mayoría de las otras se están organizando a gran velocidad, respondiendo al ritmo que marcan las líneas de negocio.
Concienciación
Sobre el nivel de concienciación de la empresa española para alterar de alguna forma su instalación, Treviño opina que, en general, hay un grado básico de concientización a la hora de abordar cambios en su estructura tecnológica. La implantación de marcos de referencia como ITIL o CMMI impulsa la creación de procesos orientados a mejorar el éxito de las operaciones de cambio. Sin embargo, es raro encontrar empresas españolas tan obsesionadas con la calidad de su tecnología como Apple o Amazon. En este tipo de compañías, el concepto de calidad se pone por delante del concepto de cambio o entrega y se mide en todas las dimensiones posibles y con la satisfacción del cliente en el centro de todas las métricas. La calidad es además su mejor ventaja competitiva respecto de sus competidores.
Márquez opina que en muchos casos seguimos en el pasado. La situación se agrava con la reducción de los presupuestos, y de nuevo se aprende de los errores. Hace ya tiempo que los departamentos de TI no se dejan seducir fácilmente por las nuevas corrientes y la toma de decisiones se realiza de una manera reposada y tras analizar las muchas opciones que ofrece el mercado. La migración y modernización de las aplicaciones se contempla como una opción segura, fiable y económica y es una corriente en alza. Solo falta una masa crítica de casos de éxito que fortalezca esta tendencia.
Sánchez cree que las empresas sí están concienciadas de que el Testing es imprescindible para asegurar la calidad de los sistemas informáticos y minimizar al máximo los fallos. Pero aun así, las empresas avanzan con dificultad en la implementación de métodos, herramientas y servicios. El ajuste presupuestario que viven todos los departamentos de TI se cobra muchas veces una víctima: las pruebas. Y en una época en que las inversiones se miran con lupa, sigue habiendo empresas que optan por procesos de creación de software sin controles de calidad, o muy pocos y muy específicos. Desafortunadamente, en muchos casos las pruebas quedan pospuestas para el final del proyecto o se realizan con muy poco tiempo, recortando en la propia calidad del Testing que se realiza.
Asimismo, existen nuevos escenarios metodológicos ágiles, donde la filosofía de equipos multidisciplinares y actividades solapadas deja menos cabida al modelo de verificación y validación independiente. Nos encontramos, en definitiva, con proyectos de pequeño volumen, con planificaciones muy ajustadas, condicionados a una dependencia presupuestaria creciente y, por tanto, a una demanda variable más complicada de gestionar.
Sin embargo, Bertrand opina que las grandes empresas españolas son conscientes de esta realidad y se están organizando, pidiendo consejos a las empresas especialistas y estudiando lo que hacen sus competidores. Aun así, para la gran mayoría de las empresas queda todo por hacer, pues no son pocas las que ponen en producción – bajo presión de negocio – software testeado con medios extremadamente rupestres.
Soluciones de testing ¿para qué tipo de empresas?
Treviño piensa que para todas. No todas las empresas tienen el foco de la calidad como el centro de su misión, sin embargo necesitan que sus procesos internos, por simples que sean, funcionen a la perfección para maximizar sus beneficios. Algunas optan por soluciones de ERP y creen que con esta estrategia ya cumplen con lo básico en calidad. Es también función de las empresas que se dedican a la calidad de software ofrecer soluciones a medida a las distintas necesidades de los clientes potenciales, y esto a veces tampoco sucede.
Por su parte, Márquez cree que es necesario para aquellas cuyo software sea crítico para el negocio o tenga muchos usuarios. Ningún negocio puede permitirse un software que falle o sea lento. Tampoco que su web se sature con un pico de accesos concurrentes, especialmente si tiene un eCommerce, ni pueden fallar las apps. El testing permite eliminar todos estos problemas antes de que se produzcan.
Para Sánchez estos servicios son imprescindibles en compañías que desarrollen su propio software, o que dicho desarrollo lo tengan subcontratado a un tercero, ya sean pequeñas medianas, o grandes empresas. Hay que buscar el servicio de testing más adecuado a la aplicación o sistema que queremos implantar.
En Administraciones Públicas y empresas privadas
Sobre la importancia que las administraciones públicas y la empresa privada le da al testing para su buen funcionamiento
Treviño no cree que exista diferencia entre lo público y lo privado. Existe diferencia en el foco que cada organización dedica al tema de la calidad. Como tampoco existe la piedra filosofal que indique el método correcto para asegurar la calidad. Los organismos públicos son más proclives a estar certificados en diversas normas, mientras que las empresas privadas, suelen utilizar la calidad hasta el punto que las mantenga en el mercado frente a sus competidores.
Márquez afirma que hay ejemplos de todo tipo, pero la realidad confirma una fuerte tendencia a favor del testing tanto en las administraciones públicas como en las empresas privadas. El testing será una commodity en el día a día de los departamentos de desarrollo de software. Una herramienta crítica de uso recurrente.
Por su parte Sánchez ve diferencias entre la Administración Pública y la empresa privada. Lla Administración Pública por supuesto que sí le da importancia. Invirtiendo importantes partidas presupuestarias en asegurar la calidad de sus sistemas de información.
En la empresa privada sin embargo, exceptuando aquellas en las que los legacy systems siguen siendo el gran garante del Negocio, es más común de lo que pensamos que el software no se pruebe. En la mayoría de los casos, se considera que las pruebas no son necesarias y preferimos arriesgarnos a no probar debidamente por las prisas en poner algo en producción, porque vamos retrasados en fecha, porque no hay presupuesto para pruebas, o por una mezcla de todas las anteriores.
También suele suceder que no sabemos probar, pues nuestras aplicaciones han llegado a un nivel de complejidad muy alto, como es el caso de las entidades financieras, por su funcionalidad, porque hemos cambiado varias veces de desarrolladores o porque somos cautivos de un desarrollador que nos asegura que prueba, pero no nos lo demuestra. Estas condiciones son el cocktail ideal para ceder ante la tentación de no probar lo suficiente.
Algo parecido opina Bertrand que afirma que todas las organizaciones de entidad son conscientes de este hecho ineludible. Otra cosa es la disponibilidad de presupuesto para que las Administraciones públicas puedan hacer frente a estos retos. Los suministradores de soluciones de Testing y DevOps tenemos la misión de ayudarles a construir los “Business case” adecuados para que puedan dar este salto necesario y alcanzar sus objetivos de mejorar las prestaciones que prestan a los ciudadanos.
Certificaciones
Sobre las certificaciones, los niveles de garantía y normativas, las opiniones coinciden aunque hay diferencias en el modelo implantado. Así para Treviño existen varias organizaciones internacionales para certificar tanto profesionales como empresas, y cada una con su modelo propio. Si se mira a detalle, todos coinciden en lo básico, y solo difieren en el peso que dan a las distintas prácticas dentro de los procesos de calidad. La mayoría basa su proceso de certificación en el modelo de cinco niveles de madurez de Carnegie Mellon. Lo importante no es cuál pudiera ser el mejor, creo que lo importante es tener una de estas certificaciones como marco de referencia para la mejora continua.
Para Márquez, el nivel de garantía es que es una certificación otorgada por un organismo que ha fundado el Instituto para las certificaciones de testers, su responsabilidad debe ser limitada a impartir capacitación y examinar candidatos entregando en caso positivo los certificados, no más, incluso no dan servicios.
Sin embargo Sánchez, no lo ve igual. No hay ningún estándar en particular que acredite o certifique a las empresas de testing como tal.
Criterios de selección
Sobre el proceso y los criterios a seguir que una empresa tiene que llevar a la hora de seleccionar una solución de testing, no todos coinciden en su visión a la hora de recomendar como seleccionar un proveedor. Para Treviño lo primero es alinear la visión y misión de la empresa con las posibles soluciones de calidad en el mercado, eligiendo la que más se ajuste a la realidad. Inmediatamente después, recomiendo verificar si la calidad es un componente fundamental para la supervivencia de la empresa y la satisfacción de los clientes. Por último, elegir un modelo de referencia al cual seguir para mejorar los productos y servicios ofrecidos.
Por su parte Márquez opina que tradicionalmente se hace una búsqueda general en medios y seleccionan las 3 compañías proveedoras que más se acercan a sus necesidades, solicitando la evaluación de las soluciones de testing y por medio de un piloto tratando de comprobar que estas cubren sus requerimientos técnicos. Los criterios a seguir están asociados primero a la cobertura tecnológica de las soluciones de la empresa, es decir, que la aplicación para testing seleccionada soporte los lenguajes, protocolos, tecnologías, etc., de sus aplicaciones; en seguida, que dicha solución tiene costo que puede cubrirse con el presupuesto designado, básicamente todas las empresas ponen tecnología y precio por encima de todos los criterios.
Sánchez cree que lo fundamental es: en primer lugar es implantar una metodología de pruebas que colabore con el desarrollo y la implantación de sistemas, y acelere su puesta en producción garantizando y certificando la Calidad del nuevo software.
En este punto, es muy importante que dicha labor sea realizada por un equipo de Pruebas y Certificación Independiente, con organización propia, y que se utilicen modelos de estimación del Retorno de la Inversión en pruebas.
Desde IBM, Bertrand recomienda a las organizaciones ponerse en contacto con empresas especialistas con larga experiencia en la materia, para poder conseguir, en la mayor brevedad posible, una valoración de su situación particular y decidir la metodología, soluciones, prácticas a adoptar, así como un claro itinerario a seguir para una implantación exitosa.
Sobre cómo definir un proyecto completo cubriendo todas parcelas que cubren el testing, Treviño lo divide en tres grandes líneas de acción:
- Metodología, procesos y certificaciones. En esta línea incluiría un gran esfuerzo a la comunicación interna para que todo el equipo humano asuma los valores de calidad.
- Infraestructura, herramientas e incluyendo datos.
- Ciclo de vida de la calidad de software, comenzando por la gestión de la demanda hasta la certificación de la aplicación antes de su puesta en producción a disposición de los clientes.
Para Márquez la calidad no es un tema exclusivo del área de testing. Es de alta prioridad cuidar la Calidad desde el momento en que un proyecto es aprobado y se comienza la definición de sus requisitos asegurando así que todos los equipos en las distintas áreas de la empresa se encuentran en el mismo canal de entendimiento y comunicados correctamente de los cambios. Cambiar el paradigma de las pruebas de aceptación de usuario (UAT’s) del final del ciclo, a la primera etapa del ciclo de vida de desarrollo del software, asegurará que el usuario está conforme y de acuerdo, desarrollo tiene bien claros los objetivos a alcanzar y pruebas recibe ya documentados los resultados esperados basados en un requerimiento del negocio. Alineados en este sentido se evita trabajo innecesario pero sobre todo gastos ocultos y posibles pérdidas de clientes y prestigio en el mercado por la entrega tardía o de baja calidad de los aplicativos.
Según Bertrand, en IBM consideramos que un proyecto de este tipo debe tener en cuenta los aspectos de metodología y prácticas, y proporcionar las herramientas adecuadas para responder q las necesidades presentes y futuras del cliente. Por ello para IBM es clave tener en cuenta el ciclo DevOps entero, puesto que la disciplina de testing cumple con la misión de medir si el software responde a las exigencias de negocio y cuál es la diferencia entre el software y sus especificacione
