Llegamos a ustedes gracias a:



Columnas de opinión

Pruebas de software: Qué debe esperarse y qué no

Por: Eugenio Valdebenito, director técnico de SoftTest S.A.C

[08/07/2009] El crecimiento actual de los negocios no hubiera sido posible sin un adecuado apoyo en sistemas de información. El desafío más grande que se enfrentan las gerencias de TI es entregar soluciones a tiempo, con costos controlados y de alta calidad. El gran desafío es, entonces, mantener el equilibrio de estas variables.

No puedo dejar pasar qué se entiende por calidad:
· Satisfacer los requerimientos (llamados también requisitos). Según esta definición puede darse que se satisfagan los requisitos, pero que el usuario quede con un alto grado de insatisfacción, salvo que los requisitos incluyan las expectativas y se expliciten al máximo los requisitos. Lo bueno que tiene esta definición es que lleva implícita un criterio de aceptación del sistema; esto es, si se satisfacen los requisitos se entiende como aceptable, de calidad y puede darse por terminado el proyecto.
· Satisfacer sus variados usos y propósitos. Esta es la definición más cercana al usuario, pero puede ser ambigua como criterio de aceptación, y por tanto debe ponerse énfasis en capturar en detalle estos usos y propósitos. Si esto no es así puede alargarse el proyecto, y queden usuarios insatisfechos.
¿Cómo entonces podemos medir la calidad de las aplicaciones? Es aquí donde participan las pruebas de software. Sin embargo, existen expectativas acerca de las actividades de testing y en general de la calidad del software, que las mencionaré a continuación y trataré de exponer un punto de vista en cada una de ellas:
¿Las pruebas son sinónimo de aseguramiento de calidad? Esta es una de las principales confusiones que es usual encontrar. La calidad tiene dos grupos de actividades:
· Aseguramiento de calidad, cuyo objetivo es que se construyan productos de calidad (enfoque proactivo). Caen en este grupo las actividades para verificar la adherencia a procesos y estándares, el análisis de las lecciones aprendidas -pensando en un mejoramiento continuo- y la prevención de defectos. 
· Controles de calidad, realizados para verificar que los productos sean de calidad. Las pruebas y las revisiones de productos de software forman parte de este grupo.
¿Las pruebas resuelven el 100% de los errores? Lograr este objetivo en la práctica no es posible, pues se sabe que para abarcar todos los casos de pruebas para n variaciones funcionales (suponiendo bifurcaciones lógicas de dos valores, que es el caso más simple) es igual a 2n. Por tanto, si n es igual a 12, que es un número muy bajo de variaciones funcionales, se requieren 4096 casos de pruebas. Rápidamente se convierte en una cifra inviable y económicamente imposible de soportar. ¿Qué debe hacerse para resolver este dilema? Usar técnicas de pruebas que reduzcan los casos de pruebas sin sacrificar la calidad, tales como clases de equivalencia y valores límites. Además se sabe por la ley de Pareto que el 80% de los errores provienen del 20% de las piezas de código. Hay que concentrase en éstas fundamentalmente, y tener una cobertura de pruebas mayor en ellas.
Lo que sí podemos asegurar es que las pruebas disminuyen la probabilidad de encontrar errores en producción.
El grupo de pruebas es una traba para realizar negocios. Es muy común en las organizaciones inmaduras oír que los grupos de calidad son los responsables de los atrasos, y por tanto se les presiona fuertemente para que liberen las aplicaciones. Muchas organizaciones, cuando tienen problemas con los plazos de entrega de las aplicaciones, sacrifican la calidad y/o afectan el alcance de la funcionalidad prometida.
Esto solo produce ganancias ilusorias.
Al recortar la funcionalidad, tarde o temprano habrá que completarla, salvo que no se necesite. Pero si somos hábiles,  pasamos la aplicación a mantención, donde podemos irla completando o parchando para que funciones aceptablemente. Cuando se toma este camino y no se abusa de esta práctica, es conveniente que los grupos de mantención no dependan de los grupos de desarrollo, y además deben tener criterios escritos para la aceptación de las aplicaciones, con la óptica de la mantenibilidad. Si estos criterios no se satisfacen, no deberían aceptarse las aplicaciones en mantención para evitar que éstas se eternicen en este estado.
En cuanto a recortes en la calidad (reducir ciclos de pruebas, reducir casos de pruebas, saltarse algunos tipos de pruebas considerados fundamentales como son las pruebas de performance, de seguridad) puede afectar en forma importante las fallas encontradas en producción, reducir el nivel de satisfacción de los usuarios o clientes. Si éste es el caso, el responsable de la salida antes de tiempo, debe asumir los riesgos. La mejor forma es que éste sea en forma escrita. No es suficiente el correo electrónico, pues induce a diluir la responsabilidad. 
El mejor ejemplo en cuanto a que la calidad no se contradice con los objetivos de negocios, sino que al contrario, a mediano y largo es un fuerte apoyo para el negocio, es el caso de Toyota, que siendo un ejemplo obligado de aplicación rigurosa de modelos de calidad, ha llegado a posicionarse como líder mundial en ventas de automóviles, usando la calidad y precio como pilares de su éxito.
La calidad es costosa. Es efectivo que aplicar calidad tiene costos asociados en infraestructura, licencias, equipo humano. Estos costos están relacionados con actividades de prevención, evaluación y corrección de fallas, pero esto tiene como recompensa clientes y usuarios más satisfechos, vida útil de los sistemas más larga, y menores tasas de re-trabajo. Lo relevante es comparar los costos de la calidad (de prevención, corrección de errores y control), comparados con los costos de no contar con calidad (re-trabajos, reparaciones, resolver quejas, re-encantar a los clientes, devoluciones por insatisfacción de los sistemas, costos de retener clientes insatisfechos).  Esta comparación es siempre positiva, en particular ya que es sabido que conseguir un nuevo cliente es hasta 10 veces el costo de mantener contentos a los actuales. En las aplicaciones web, que es la tecnología de más crecimiento en los últimos años, es aún más impactante el efecto de las aplicaciones de baja calidad, donde el usuario tiende a no regresar a un sitio defectuoso, y ¡recuperarlo puede ser un esfuerzo titánico o casi imposible!
Las pruebas se efectúan solo a las programas. Hasta hace poco se acostumbraba limitar las pruebas a las piezas de código, usando pruebas de caja negra, con la visión del usuario; y de caja blanca, donde se analiza el código fundamentalmente para analizar la concordancia con las especificaciones y con los requerimientos del usuario. Sin embargo, por estudios internacionales se sabe que la mayor parte de los errores detectados en las pruebas tienen su origen en requerimientos incompletos, ambiguos o inconsistentes. Ante esta realidad, el enfoque actual apunta a efectuar revisiones a los productos de software desde el inicio del proyecto, esto es, revisar entre otros, las  especificaciones de requerimientos ¡y sus cambios! -mapeándolos con los procesos de negocios-, el modelo de datos, las especificaciones de programas, los planes, lo que permite la detección temprana de errores. Estas revisiones se enfocan a detectar ambigüedades, inconsistencias, incompletitud. Si esto no se hace, la corrección de errores será cada vez más cara y difícil mientras mas tarde éstos se detecten.
¿Bastan las pruebas de los usuarios? Es común, e incluso deseable, que los usuarios elaboren casos de pruebas. Se supone que conocen los procesos de negocios y quien mejor que ellos conocen sus necesidades (suponiendo que se asignan al proyecto las personas con mas conocimiento del negocio, lo que no siempre sucede). El problema es que, usualmente, los usuarios tienden a concentrarse en las situaciones normales (happy path) y olvidan las situaciones de excepción, que deben ser probadas con tanta importancia como las situaciones normales. Los proyectos de desarrollo destinan mucho esfuerzo al desarrollo de estas situaciones fuera de lo normal, las que por cierto deben probarse. Por ejemplo, en una aplicación de retiro de fondos de un cajero automático, los caminos de excepción pueden ser cuando la cuenta no tiene fondos suficientes, que el cajero no cuente con fondos necesarios, etc. Por tanto, se sugiere que el grupo de calidad capacite a los usuarios ( y a los desarrolladores!) en la elaboración de casos de pruebas, y además siempre deben revisar los casos elaborados y solicitar que sean completados, cuando corresponda.
Basta con probar con datos reales para asegurar calidad. Es común ver poco acuerdo acerca si hay que obtener los datos de producción (suponiendo que se cuenta con un ambiente separado para el grupo de pruebas) o crear datos específicos para las pruebas. ¿Qué es mejor?
La respuesta es? depende. Si se trata de probar aplicaciones o funcionalidades nuevas, lo más conveniente es que se creen datos específicos para estas pruebas, contemplando todos los datos de entrada que satisfagan las pre-condiciones de los casos de pruebas, los cuales deben cubrir todas las variaciones funcionales que tenga la nueva aplicación. La única desventaja puede ser que al contar con pocos datos se pasen por alto malos comportamientos de performance, pero esto puede detectarse en una prueba posterior hecha específicamente al medir rendimiento.
En el caso de pruebas para aplicaciones existentes o correcciones, puede ser conveniente usar datos reales extraídos del ambiente de producción.
Sin embargo, siempre se debe verificar la existencia de las pre-condiciones de los casos de pruebas, mediante una consulta a las bases de datos. Si no se encuentran registros que satisfagan las condiciones de la prueba, se deben crear o modificar datos, cuidando de mantener la integridad de los datos, asegurando así una buena calidad de la prueba.
Trabajar con proveedores certificados es suficiente para asegurar la calidad. Esta es una tentación muy frecuente.
Con una tendencia actual a externalizar todo el desarrollo, es de alto riesgo descansar en esta presunción. La certificación de los proveedores por cierto que mejora la probabilidad que se obtengan mejores productos de software, pero la organización contratante debe asegurarse que el proveedor capturó bien los requerimientos (si eso no está bien, todo el trabajo posterior será erróneo, aunque se hayan construido correctamente, pero basado en un producto incorrecto), se debe auditar que el proveedor realmente aplique gestión de configuración, se debe verificar que los cambios a los requerimientos se vean reflejados en todos los productos de software (planes, especificaciones, manuales y otros), que sea posible efectuar trazabilidad entre requerimientos y los productos, se debe verificar que hagan adecuadas pruebas de desarrollo y que se efectúan pruebas por un equipo de pruebas independiente, fuera de la dependencia de los grupos desarrollo del proveedor.
 Mientras más se dependa del desarrollo externo, es más crítico asegurar que se están construyendo los productos correctos y que éstos se hacen correctamente.
Las pruebas que se realizan en la fase de pruebas son suficientes. Las pruebas no pueden efectuarse solo en la fase de pruebas. Esta fase es solo un Dique donde se pueden detectar defectos de calidad que se arrastran en todo el ciclo de vida de desarrollo del proyecto. Una buena prueba puede detectar muchos de estos errores, pero detectarlos en este punto puede ser muy tarde. Si se producen malas interpretaciones de las expectativas de los usuarios, si las funcionalidades no están cubiertas, si existen inconsistencias y ambigüedades, son problemas que parcialmente pueden ser detectados en la fase de pruebas, pero es muy tardío. Se debe usar un enfoque proactivo de revisiones y pruebas para construir productos de calidad en todo el ciclo de vida.
La calidad es responsabilidad del equipo de calidad. Los equipos de pruebas no son los responsables de generar la calidad y producir productos de calidad. Esto es responsabilidad de los grupos de desarrollo. El grupo de calidad es solo responsable de detectar estos errores. Por consiguiente, las pruebas de desarrollo son algo que no pueden dejar de hacerse, y como es sabido, la responsabilidad no se delega. Los desarrolladores deben ver a los equipos de calidad como un aliado para producir productos de calidad. Los Jefes de proyectos deberían involucrarlos mas en sus proyectos, desde el inicio de los mismos, para que hagan su aporte en la revisión de los entregables críticos antes que lleguen a la fase de pruebas.  
Eugenio Valdebenito ha sido consultor de calidad por varios años, y los últimos cinco años se desempeñó como encargado de calidad de Paris S.A. (gran tienda en Chile) y Encargado corporativo de mejoramiento de procesos de Cencosud, una de las más importantes empresas retail de Sudamérica. Actualmente es Director Técnico de SoftTest S.A.C., empresa peruana de calidad de software, ingeniería de procesos, mejoramiento de procesos y capacitaciones especializadas en calidad y gestión de proyectos. Referencias
CIO, Perú