| Actualmente un software se vende cuando está probado en un 80% |
| El 20% restante lo hará el usuario final y ¡gratis!, Monoposoft |
Sin duda el mercado actual no ha ayudado a mejorar ninguna de las etapas de producción de software, debido a la carrera por salir lo antes posible al mercado. Por ejemplo, Windows'98 no podía salir en 1999. Sin duda, la etapa más perjudicada es la de testeo o prueba del software. En esta columna describimos algunas herramientas que existen hoy para facilitar esta tarea.
El Proceso de Prueba
Este proceso tiene tres etapas bien definidas: pruebas de desarrollo e ingeniería, pruebas de aseguramiento de calidad internas y pruebas con usuarios reales. La primera etapa se focaliza en el nivel del código, integración de módulos y sistemas, además de maximizar la cobertura de las pruebas en todo el código. Nuevas herramientas visuales pueden facilitar significativamente esta etapa. Un ejemplo es SeeSoft, un visualizador de código desarrollado por Lucent. SeeSoft permite visualizar miles de líneas de código en una sola ventana, usando líneas de distintos colores que pueden indicar distintos programadores trabajando en distintas partes del código, la cobertura de las pruebas realizadas (ver figura) o la antiguedad de cada línea, entre otras alternativas. La segunda parte opera principalmente a nivel de la interfaz de usuario, probando compatibilidad y funcionalidad, más la instalación del software. Muchas veces también incluye mediciones de desempeño. Muchas compañías realizan esta etapa con un grupo selecto de usuarios externos también llamados Alfa.
Las pruebas reales conocidas como Beta testing se realizan con usuarios actuales o potenciales de la aplicación en distintas plataformas y ambientes de trabajo. Estas pruebas son las únicas que realmente dan información acerca del posible éxito o fracaso de un producto, y por lo tanto el manejo adecuado de la información que generan los usuarios es crucial. Sin embargo, existen muy pocas herramientas que ayuden en este proceso, el cual tiene cuatro actividades principales: administrar la instalación de las pruebas, recolectar estadísticas de uso, identificar tendencias y anomalías en los datos y medir resultados con respecto a criterios de término del proceso (número de usuarios, horas de prueba y errores reportados por hora).
Métricas de Uso
Las pruebas no comienzan formalmente hasta que un número mínimo predeterminado ha instalado el software. En particular, usuarios que tardan en comenzar, generalmente nunca lo hacen y ponen en peligro todo el proceso. Esto puede significar tener que reemplazar usuarios. En la práctica, pasarán al menos cuatro semanas antes del punto de partida. En particular, los problemas iniciales pueden indicar falta de interés del usuario o fallas críticas. Por lo tanto, una primera métrica es el número de usuarios, sus características, sus tipos de problemas y las horas de uso.
Una segunda métrica es la frecuencia de uso de cada opción del software. Esto permite saber si la funcionalidad completa del software ha sido verificada. El poco uso de algunas opciones puede deberse a que se necesitan poco, pero también es importante verificar si es que se debe a que hay problemas, que son difíciles de encontrar o que tienen poco valor práctico.
Otra métrica es el número de fallas reportadas por semana. Sin embargo, esto no es suficiente si las horas de uso también disminuyen, debido a la frustración de los usuarios. Aunque hayan suficientes horas de uso, podría ser que éstas están concentradas sólo en algunos usuarios y por lo tanto es normal que el número de fallas decrezca. Es decir, un gran número de usuarios en distintos ambientes debe probar todas las funcionalidades, para asegurar que las pruebas tienen validez general.
El escenario final ideal consiste en tener un número adecuado de usuarios (sobre el 80% de los considerados), que además al menos la mitad de ellos usen las opciones principales y que la razón de fallas reportadas con respecto a las horas de uso sea razonablemente baja. Realizar este proceso en forma manual es tedioso, costoso y largo. Recolectar datos vía teléfono es ineficiente y pueden ser vagos o subjetivos. Sin embargo, ya existen herramientas automáticas que son instaladas dentro de la aplicación que permiten recopilar datos automáticamente y enviarlos vía correo electrónico de forma transparente al usuario de prueba. Un ejemplo es Aqueduct Profiler, que a través de una biblioteca de funciones permite que la aplicación envíe los datos. Por el otro lado, la herramienta misma permite visualizar las métricas discutidas anteriormente (ver figura) y analizar datos confiables en cantidad y calidad.
Referencias
Si tiene preguntas o sugerencias, envíe e-mail a rbaeza@dcc.uchile.cl