Tomarse la calidad en serio

Todavía no existe una norma que certifique el producto de software

El pasado mes de noviembre, Sogeti organizó las jornadas sobre ingeniería de calidad y pruebas de software, ExpoQA. “Un mercado que en España todavía no ha llegado a la madurez de otros países europeos”. Así al menos lo reconoce Raynald Korchia, director de la división de software control y testing de Sogeti, empresa perteneciente al Grupo Capgemini. Hoy, la inquietud por el testing está presente en sectores como el espacial, aeronáutico y automoción.

Hoy en día, los productos de software desempeñan un papel muy importante en la sociedad; este rol exige que dichos productos no fallen y se integren adecuadamente tanto con los usuarios como con otros sistemas. Esto demanda que todo el software, antes de ser puesto en uso, deba ser exhaustivamente probado de acuerdo a patrones preestablecidos para asegurar su buen comportamiento. Sin embargo, Patricia Rodríguez, gerente de SoftWcare, empresa dedicada al mantenimiento de la seguridad y la fiabilidad del software, reconoce que “hoy por hoy, la validación y la verificación (V&V) se realiza en sistemas críticos donde un fallo puede afectar a las vidas humanas o provocar pérdidas de dinero y de posicionamiento de mercado”. Aunque es imposible demostrar un 100% de fiabilidad en el software, la responsable de SoftWcare insiste en que “hay que exigir robustez y disponibilidad del software”. No obstante, reconoce que “nos quejamos poco cuando un sistema falla; y cuando esto ocurre, lo asumimos”, asegura.

Independencia
Los sistemas críticos cuyo funcionamiento condiciona nuestra vida cotidiana necesitan ser verificados, certificados u homologados, antes de su puesta en funcionamiento. “Los actuales procesos de certificación de desarrollo de software resultan en ocasiones insuficientes para evaluar todos los aspectos de seguridad y fiabilidad”, apunta Patricia Rodríguez. Para la responsable de SoftWCare, “los organismos internacionales de certificación, como AENOR, sólo certifican el proceso de desarrollo en vez del producto o el sistema en sí”. A falta de una norma específica, la IEC6105 se encarga de establecer los procedimientos del software desde el diseño, pasando por la concepción, la instalación, la manipulación y el mantenimiento hasta la puesta en servicio. Además, según Rodríguez, “la norma IEC6105 recoge el grado de independencia técnica, departamental y organizativa del testing frente al desarrollo”. Para Domingo Gaitero, director de consultoría de Atos Origin, “uno de los principios básicos del testing es la creación de grupos independientes. El responsable de la verificación del software no puede nunca ser el mismo que lo ha desarrollado. Tienen una visión diferente: el proveedor piensa en positivo hacia el software desarrollado mientras que la visión del tester debe ser destructiva; cuantos más fallos se encuentren, mejor”.

Profesionales
Atos Origin cuenta en España con una factoría de testing en Sevilla. “Lo realmente difícil es preparar el entorno de pruebas”, asegura Domingo Gaitero. Para la puesta en marcha de la factoría es necesario un grupo de ingenieros con experiencia en metodologías, capaces de saber los requisitos y las pruebas que hay que realizar sobre el producto. Pero en la ejecución, “se necesitan personas que sepan leer los casos de prueba, ejecutarlos y anotar el resultado. En este caso, no es necesaria una experiencia. De hecho, muchas veces comento a modo de broma que prefiero un profesional que no sepa informática”. No obstante, hoy en día cada vez proliferan más herramientas de automatización de pruebas, que, a pesar de su elevado su coste, resultan muy rentables para una factoría en donde su utilización es continuada. Lo que más calidad aporta al software es el distanciamiento entre el proceso de testing y el cliente. “Su cercanía fomenta la confianza y en consecuencia se trabaja con cierta informalidad”, asegura Gaitero. Atos Origin realiza la programación del software y la prueba unitaria en la factoría que tiene en Valladolid, mientras que las pruebas de integración, seguridad y regresión se realizan en su factoría sevillana.


La mayoría de las empresas tiene un área de calidad
-------------------------------------------------------------------------
• Un 89% de la centena de entidades que asistieron a ExpoQA 2007, entre ellas Vodafone, Banco de España, Mapfre, Repsol, Enagás, asegura que sí tiene un departamento/grupo específico dedicado a calidad de software. Estos datos, extraídos de una encuesta realizada por Compuware, a la que ha tenido acceso ComputerWorld, indican la importancia que el mercado le está concediendo a la calidad del software, dedicándole cada vez más recursos y más especializados. “Existe una evolución positiva y bastante acelerada ya que en 2004, el resultado ante la misma pregunta fue que sólo el 42% tenía un departamento o grupo específico dedicado a calidad del software, mientras que el pasado año un 75% respondía que sí tenían ese departamento”, comenta Pilar Carretero, directora de marketing de Compuware.

• Aquellas empresas que no tienen un departamento de calidad, indicaron que en algunos casos (25%) las pruebas las realizan los propios desarrolladores, y en otros tienen a un equipo concreto dedicado a las pruebas, aunque éste no es un departamento de calidad propiamente dicho.

• En la encuesta también se revela que el 87% de las empresas encuestadas tiene establecidos procesos específicos de calidad de software. Por su parte, el 85% de las empresas afirma que está siguiendo una metodología de mercado como CMMI o ITIL.


Pruebas más frecuentes de testing
--------------------------------------------------
Enrique Placed, director de alianzas de Compuware para España y Portugal, reconoce que si bien las pruebas más habituales realizadas en una factoría de testing son el control de calidad técnica del código o las asociadas a los requisitos, lo cierto es que las más extendidas, actualmente, son las de regresión y las de carga. Las primeras son un tipo particular de pruebas funcionales que sirven para validar que una nueva versión de una aplicación no introduce errores en funcionalidades existentes, lo que supondría una regresión. “Es habitual realizar este tipo de pruebas como parte del ciclo de vida de una aplicación o antes de realizar cambios importantes en su arquitectura”, comenta el directivo. Por su parte, las pruebas de carga son un tipo particular de pruebas de rendimiento y sirven para garantizar que el tiempo de respuesta de un aplicativo será suficiente cuando se alcancen altos volúmenes de usuarios concurrentes. Según Placed, “se utilizan mucho para afinar la parametrización de los sistemas, aunque no suelen ser suficientes para detectar problemas de rendimiento en el código”. Adicionalmente, el directivo apunta que “a día de hoy se está despertando bastante interés en el control de calidad del código y en las pruebas de seguridad, aunque todavía son pocas las organizaciones que realizan estas pruebas de un modo consistente”.

Viñeta publicada el 20 de febrero de 1870 en La Flaca n.º 35 Tendencias

ny2 ACTUALIDAD

ny2 Sociedad de la información

Día de la Movilidad y el BYOD Coffee Break