Amalia Riaza, directora de Calidad y Pruebas de Software de Efron Consulting

“Una función de SQA mejora la productividad y reduce los costes de operación”

Publicado el 29 May 2012

¿Quién asume la función de Software Quality Assurance (SQA) en las organizaciones? Aunque está generalmente aceptado que la función de calidad debe ser independiente al desarrollo de software, la realidad es que la mayoría de las organizaciones siguen confiando está función a las mismas empresas que les desarrollan el software. Estimamos que, aproximadamente, el 75% de las compañías que contratan desarrollos, siguen delegando ambas funciones en el mismo proveedor.
El liderazgo en la disociación lo mantienen grandes bancos, compañías de seguros y empresas de telecomunicaciones. El resto de compañías avanza lentamente en este sentido, pero aún queda mucho camino por recorrer.

¿Por qué las organizaciones no terminan de implementar una función de SQA a pesar del interés que suscita el tema de la Calidad? El principal motivo es cultural. Para implementar una función de SQA se requiere una inversión inicial que tarda un tiempo en retornar. La implantación además conlleva una serie de cambios en la metodología de desarrollo, por lo que la adaptación entraña una cierta dificultad que se ve agravada en caso de que existan distintos proveedores de desarrollo. Por lo tanto, si se quiere garantizar el éxito, es necesario el apoyo incondicional de la Dirección de la compañía.

En algunos casos, la Dirección de las empresas de TI no entiende las pruebas ni aprecia sus beneficios, por lo que se limita a ver el coste de la implantación y a estudiar el ROI de la inversión. Entre tanto, los proyectos siguen experimentando retrasos, la calidad del desarrollo sigue siendo, en muchas ocasiones, baja, y la Dirección sigue escudándose en que los proveedores de desarrollo deben entregar software “que funcione”.

¿Cuál es el principal detonante que mueve a las organizaciones a dar este paso?
Sería alentador poder decir que las organizaciones, en algún momento, toman conciencia de la necesidad de implantar un modelo de SQA y deciden empezar a definirlo de forma ordenada y metodológica. Pero lo cierto es que, el principal desencadenante de todo el proceso, suele ser la existencia de proyectos abiertos con graves problemas, retrasos en las fechas de entrega, cantidades importantes de defectos en el software, falta de adaptación del software entregado a los requisitos de negocio…

En estas situaciones difíciles es cuando, con mayor frecuencia, la Dirección de TI decide dar el paso de solicitar un servicio de SQA que, generalmente, llega tarde para poder mejorar la situación de forma inmediata, pero que puede ayudar a amainar sus problemas. Una vez que el “incendio” haya sido apagado, el trabajo realizado se utiliza como embrión para la implantación de un modelo que evita que, situaciones similares, vuelvan a producirse.

¿Qué objetivos son los que se persiguen cuando se implanta una función de Calidad?
El objetivo más perseguido es la reducción de costes. Establecer una función de SQA mejora la productividad y reduce los costes de operación y de mantenimiento de aplicaciones. Esta ventaja ya ha sido comprobada por muchas empresas tras años de experiencia.
Otros objetivos importantes que se tienen en mente son la implantación de buenas prácticas, reducir el Time to market de los desarrollos, controlar el riesgo de las puestas en producción o cumplir con las auditorías.

Según su opinión ¿los objetivos se consiguen tras la implementación de una función de Calidad? ¿En qué plazo?
No cabe ninguna duda. Las compañías que han implementado funciones de Calidad que acompañan a sus procesos de desarrollo de software, han visto cumplido su objetivo de disminución de costes, sobre todo de mantenimiento.

Un beneficio que no hay que minusvalorar es la satisfacción de los usuarios de negocio, que han comprobado que el software entregado se acerca mucho más a sus requisitos y que la depuración de defectos se ha hecho antes de su intervención. Los usuarios de los aplicativos han visto disminuir considerablemente el tiempo de dedicación a las pruebas, a las que antes brindaban muchas horas de trabajo, y se han convertido en meros certificadores de que el producto recibido es el esperado.

Respecto al plazo, los resultados no son inmediatos. La implantación de un modelo de calidad requiere intervención sobre el modelo operativo y organizativo de TI y, lógicamente, existe un plazo de cambios para ver los efectos reales de disminución de costes e incremento de la eficiencia en el proceso de desarrollo del software.

¿Qué servicios son los más demandados por las compañías de TI?
El servicio más demandado actualmente es el soporte a la ejecución de las pruebas funcionales A continuación, nuestros clientes nos solicitan una consultoría para el diagnóstico y puesta en marcha de un modelo de calidad completo, desde el análisis estático de documentación y código hasta que el software se pone en producción, de forma controlada.

También se están demandando otros servicios que acompañan al software en el camino que recorre desde que el proveedor de desarrollo lo entrega hasta que se despliega en producción: la gestión de los datos, la preparación de la infraestructura, el despliegue en los distintos entornos, la gestión de la configuración, la gestión de cambios, gestión de versiones…

Por último, está siendo bastante solicitado el Testing as a Service, que permite el acceso a herramientas, frecuentemente caras, que capacitan para ejecutar pruebas de rendimiento y regresión automáticamente, sin tener que desembolsar más que el consumo real de los servicios y bajo SLAs establecidos.

Según su opinión, ¿qué le depara el futuro a este sector en los próximos años? Las pruebas de rendimiento no han alcanzado aún su mejor momento. Es ahora cuando las organizaciones empiezan a darse cuenta de que, durante años, no ha habido cortapisas presupuestarias a los recursos de hardware por las ineficiencias del software. La compra de capacidad de proceso para paliar las ineficiencias de las aplicaciones y sus tiempos de respuesta, ha llegado a su fin y las pruebas de rendimiento tienen mucho que decir en un futuro inmediato. En este sentido, existe un amplio recorrido en la definición de requisitos no funcionales ya que los desarrolladores de software suelen dar una escasa transcendencia a este tema.

Por otra parte, un gran número de organizaciones aún confían la función de calidad a sus proveedores de desarrollo. La separación de ambos procesos está por llegar en los próximos años, así que, los que nos dedicamos a este sector, tenemos por delante un reto importante que afrontar.

¿Qué te ha parecido este artículo?

La tua opinione è importante per noi!

Redacción

Artículos relacionados

Artículo 1 de 5