Pruebas de estructura y funcionalidad

Al igual que cuando se hacen obras físicas, cuando se construyen
soluciones digitales debe hacerse distintos grupos de prueba.
La fotografía está tomada de la sección de Estructuras
 resistentes a terremotos de la Wikipedia

La semana pasada estuvimos hablando acerca de la importancia de la actividad de pruebas durante la fase de desarrollo para asegurar la confiabilidad de la solución que se construye. Señalamos todo lo que había que probar: estructura de información, funcionalidad, navegación, seguridad, estética, pero hicimos el énfasis en la necesidad de disponer de un plataforma que permita la realización regular, y metódica de  pruebas automáticas. Hoy continuaremos hablando acerca de aspectos vinculados a las pruebas que todo gerente de información debe conocer, pero dirigiremos nuestro foco a comentar los distintos elementos que deben probarse, señalando algunas estrategias generales para hacerlo en el caso de la estructura de información y la funcionalidad.

Pruebas de la estructura de información
Cuando la gente piensa en pruebas, generalmente piensa en las pruebas de funcionalidad. Cómo saber si la aplicación desarrollada o en desarrollo cumple o no con un determinado requisito funcional. Pero, como hemos señalado (ver Pruebas durante la construcción de una solución), la funcionalidad no es todo lo que se prueba. ¿Cómo, por ejemplo, se puede probar la estructura de información? Si los objetos de información creados, los metadatos distinguidos en ellos y las relaciones o asociaciones entre estos objetos fueron construidos correctamente, de acuerdo con lo planificado, o si hay omisiones que se pasaron por alto en el camino?

La respuesta se obtiene a través de la comparación entre lo diseñado y lo creado. La estructura de información se condensa en tablas, si se dispone de una plataforma que pueda sacar estas tablas del prototipo desarrollado, se puede comparar estas tablas del prototipo con las tablas producidas durante el diseño. De esta forma se puede saber si todo la estructura ha sido creada alineada con el diseño o, en caso contrario, cuáles son las diferencias entre lo inicialmente diseñado y lo finalmente construido.

Una vez más la comparación debe realizarse con pruebas automáticas ya que los seres humanos somos más lentos y pasamos por alto muchos detalles por lo que somos demasiado propensos a error como para realizar tareas de comparación confiables. En lugar de ello las pruebas se realizan a través de la creación de una línea base que establece de alguna forma el producto deseado y una línea de comparación que señala lo obtenido. Ambas deben entonces poder ser comparadas automáticamente con una herramienta que señale con precisión las diferencias. Sobre estas diferencias entre lo diseñado y lo construido  las capacidades humanas si pueden emitir juicio para determinar si son aceptables, porque representan cambios esperados o discrepancias que no impactan el resultado operacional, si son anomalías que deben orientarnos hacia acciones correctivas o diferencias que deben ser analizadas con más detenimiento para ver si se clasifican en el primer grupo o en el segundo.

Pruebas de funcionalidad
En cuanto a la funcionalidad la mejor manera de probarla es a través de los casos de uso. Si estos fueron bien diseñados, de cada caso de uso deben derivarse uno o varios casos de prueba. Cada caso de prueba establece un comportamiento funcional que crea un resultado.

La primera vez la prueba del prototipo se realiza en forma manual y se compara lo obtenido con lo que se esperaba por diseño. Independientemente de lo acertado o no del resultado, este se graba en uno o varios archivos y se establece así una línea base que sirve para mejorar o para verificar el funcionamiento. A partir de este punto de inicio, las pruebas de cada caso de uso deben ser realizadas contra la línea base generada. Si el resultado inicial no estaba bien y el nuevo resultado si lo está, la línea base debe cambiarse. Si el resultado generado previamente si estaba bien la línea base sirve como criterio de verificación de buen funcionamiento de cada nuevo resultado obtenido.

Un conjunto de pruebas confiable se construye de esta manera. Así se realizan decenas, centenares o incluso miles de pruebas automáticas y se conoce cuando y en qué proporción el sistema está mejorando, convergiendo hacia una aplicación correcta y sin errores apreciables. Si los casos de uso están bien diseñados, el prototipo probado iterativamente convergerá adecuadamente. Si los caso de uso tienen insuficiencias, los casos de prueba las tendrán y la aplicación no será confiable.

Pruebas durante la construcción de una solución

Cuando se trabaja desarrollando servicios que operan con
tecnologías de la información siempre hay que probar todo lo que se desarrolla. Además hay
que hacerlo múltiples veces. La caricatura es uno de esos chistes que circulan por Internet:
 "Razones para dejar de probar" (tomado de http://cartoontester.blogspot.com)

Una de las actividades fundamentales que se realiza durante la fase de desarrollo de una solución es la de pruebas. Los profesionales que trabajan con soluciones que implican o requieren del uso de tecnologías de la información saben que todo lo que se construye debe ser probado. Después de que se varía algo hay que volver a probar todo. Pero las pruebas no deben ser algo artesanal, aleatorio, esporádico. Antes bien deben ser actividades  metódicas, sistemáticas y regulares que dejan resultados predefinidos, y que por tanto permiten a gerentes, líderes y coordinadores medir sí o no se está convergiendo hacia una solución que funcionará y cumplirá con todos los requisitos diseñados previamente. ¿Qué se prueba? ¿Cuántas veces se prueba? ¿Cómo se prueba? ¿Con qué se prueba? Son preguntas cuyas respuestas deben estar claras para todos los gerentes y participantes del desarrollo de una solución.

Durante la construcción deben probarse la estructura de información, la funcionalidad, la navegación, la seguridad e incluso la estética. Estas pruebas toman tiempo y consumen recursos y por eso deben ser consideradas durante la planificación del proyecto. Cuando no son incluidas en la planeación es común que luego no se realizan cabalmente porque no se dispone de recursos o tiempo suficiente para hacerlas. Esto es uno de los errores más frecuentes y perniciosos de los desarrollos que no son realizados profesionalmente.

¿Con que datos se prueba? Como hemos señalado anteriormente (ver Los datos para probar), los datos que se usan para hacer pruebas deben producirse durante la fase de diseño. No debe trabajarse con lo que se le ocurre, sin mayores criterios, a las personas que construyen la solución. Debe garantizarse que todos los casos de uso (ver Conceptualización de una solución y casos de uso) se cumplen y que todos los requisitos funcionales son satisfechos. Para ello quienes mejor conocen estas exigencias previas a la fase de desarrollo deben establecer los datos de prueba. Si así se hace, la aplicación resultará en un producto confiable.

Durante todo el desarrollo, e incluso, más allá, durante las fases de implementación y producción siempre ocurren cambios o eventualidades en las condiciones en que se trabajan que requieren volver a probar. Si las pruebas se realizan manualmente, éstas tomarán mucho tiempo y serán poco confiables. Por esta razón en el desarrollo profesional siempre se incluye los recursos y el tiempo para establecer y realizar pruebas automáticas. Un computador puede hacer centenares de pruebas en unas horas, o en unos minutos, una persona no. Un computador puede distinguir con precisión un cambio en un elemento de una salida que una persona puede pasar por alto. Por eso las pruebas manuales no son recomendables: resultan incompletas, inexactas y sus resultados son finalmente aleatorios.

Obviamente no es lo automático en si mismo lo que da calidad a las pruebas. Las pruebas deben ser bien diseñadas, implementadas y realizadas. Cuando así se hace, es cuando cumplen con su función y garantizan la calidad. De otra forma serán poco más que un saludo a la bandera.

Ante un cambio de variable, una nueva característica, un cambio en uno de los elementos de la infraestructura, la mejor decisión es volver a probar todo. Incluso ante un cambio de apariencia completamente inofensiva, el texto de un mensaje, el cambio de posición de un elemento de la pantalla, es conveniente volver a probar. Si las pruebas son algo manual este desiderátum es irrealizable. Si las pruebas están diseñadas, establecidas para su ejecución automática, siempre entonadas y listas para realizarse, se pueden hacer muchas veces, se harán sin dificultad cada vez que hay un cambio y, en muchos casos, pueden hacerse como una actividad de fondo sin impactar las actividades principales, visibles frontalmente.

Las actividades de la fase de construcción

La fase de construcción bien realizada
hace entrar en realidad diseños complejos.
En la ejecución más que en la planificación
 está la debilidad de muchos proyectos...

A la fase de construcción llegamos con un diseño de la solución que queremos. Hemos señalado que un buen modelo, con criterios de Arquitectura de Información, es crucial, pero como apuntamos la semana pasada, suele ser importante construir rápidamente un prototipo que pueda refinarse a través de una secuencia continua de actividades, o que pueda ser la base de un desarrollo de software a la medida que lo concrete siguiendo los procedimientos establecidos de esta rama de la ingeniería. En este post queremos conversar acerca de las actividades de la fase de construcción de una solución de gestión de información.

El desarrollo de la solución es la parte de su ciclo de vida donde ésa se vuelve palpable (Ver La fase de desarrollo o Construcción). No es un proceso lineal, sino un proceso iterativo a través de ciclos que permiten avanzar hacia la concreción de la solución que se desea. El equipo de trabajo que realiza el modelado de la solución no necesariamente es el mismo que el que realiza la construcción. Si este es el caso, es conveniente que haya una comunicación fluida entre ambos equipos.

Una herramienta de desarrollo de prototipos con Arquitecturas de Información definidas permite generar un prototipo a partir de especificaciones del modelo de información: estructura de información, funcionalidad, navegación, comunidades y seguridad, imagen y estética. A medida que la construcción avanza, todas estas actividades pueden realizarse en paralelo. Pero inicialmente hay un orden para el proceso de desarrollo.

Lo primero que debe configurarse y definirse es la estructura de información: Los objetos de información que intervendrán, todos sus campos (metadatos) y sus propiedades. Con este trabajo realizado pueden definirse las asociaciones que existen en los distintos objetos de información, lo cual marca mucha de las interacciones que se realizarán automáticamente en la solución (Ver Estructuras de información. Qué son y para qué se usan).

La definición de la estructura de información permite definir la funcionalidad, las restantes interacciones que debe haber entre los objetos de información (Ver Funcionalidad: La segunda dimensión). Particularmente importantes son las definiciones de las entradas de datos, ya que al habilitarlas podemos comenzar a usar el prototipo haciendo pruebas al diseño, pero esta vez como aplicación ejecutable. Es probable que las entradas y salidas estándares creadas por un generador de aplicaciones moderno a partir de la estructuras de información definidas resulten suficientes inicialmente. Si éste no es el caso, puede considerarse una pequeña variación a partir de ellas.

Con un embrión formado por una estructura de información, un esquema preliminar de entrada y salida que permite introducir y visualizar datos reales y por tanto probar con la data que suministraron los diseñadores de la solución es un paso gigante. Aquí pueden comenzar a detectarse omisiones del diseño, o la incompletitud de sus datos de prueba. El camino a seguir consiste en refinar sucesivamente lo que serán las entradas y salidas principales del sistema asegurándose que la data disponible es suficiente para activar todos los casos de la solución.

Lo interesante para un Gerente de información es entender que la combinación Estructura de información – Funcionalidad puede definir un primer esqueleto de la aplicación que se desarrollará y por tanto puede ser nuestro primer prototipo funcional. Esta aplicación embrionaria no da la idea integral de la solución que se construirá, pero tiene la virtud de que puede usarse como una versión ejecutable que permite cargar y visualizar datos reales permitiendo que los involucrados (más allá del equipo de desarrollo) puedan palpar más dinámicamente las bases estructurales y funcionales de la futura solución.

A partir del prototipo funcional el camino se abre en un trabajo que debe abarcar las cinco dimensiones de la Arquitectura de información ( Ver Las 5 dimensiones...), añadiendo el trabajo de navegación, la definición de los usuarios, la seguridad, la imagen y la estética. Cada dimensión puede trabajarse con independencia, incluso por personas diferentes y, si las herramientas y los procedimientos son adecuados, el producto de trabajo de cada participante de la construcción debe sumarse en un servidor que permitirá que el equipo involucrado en el proyecto y, en particular el líder del desarrollo, pueda hacer seguimiento del estado actual de la construcción.

La Fase de Desarrollo o Construcción

Construcción del estadium olímpico de Londres:
La construcción es la fase en la  que entra en la realidad lo que se ha diseñado.
¡Siempre hay nuevas decisiones para tomar!.

Una vez que se ha hecho el modelo de información de una solución, el reto es hacer realidad la aplicación. Encontrar un camino razonablemente eficiente en tiempo y en recursos para tener trabajando el prototipo de la solución que se ha diseñado. Siempre hay varias alternativas para hacer esto y no todas son iguales en orientación, esfuerzo y resultados. Las organizaciones deben resolver el problema de escoger los desarrolladores y la estrategia de desarrollo. Independientemente del camino y el equipo que se seleccione, la fase de desarrollo es crítica porque en definitiva es en ella en la que se construye la solución, por eso también se le llama fase de construcción.

El ciclo de vida de un proyecto de gestión de información pasa, como hemos señalado, a través de cinco etapas: Identificación, Diseño, Desarrollo, Implementación y Producción (Ver El ciclo de vida de una solución de gestión de información y Desarrollo, Implementación y Producción en un proyecto con Arquitectura de Información).

La fase de desarrollo suele ser percibida como la que permite que todo lo que se ha diseñado entre en la realidad. Es importante que sea una continuación del modelado, que los constructores de la solución partan y respeten el diseño realizado en la fase precedente. Asimismo, también es recomendable una cierta flexibilidad para implementar cambios en el modelo, porque es natural que en esta fase se detecten aspectos que fueron omitidos en el diseño o que aporten nuevas ideas que nacen desde elementos técnicos del esfuerzo de construcción.

Las nuevas propuestas que surgen en el equipo de desarrollo deben ser consideradas y evaluadas. Hay que estar pendientes de su impacto en los calendarios y en los recursos requeridos (Ver Los cronogramas después del modelado) para mantener a todos los involucrados alineados en el proceso de construcción y el proyecto bajo control. Siempre hay riesgos que hay que gestionar con planes de mitigación de eventualidades (Ver Las fechas de un proyecto bien formulado son probabilísticas), pero un rigidez excesiva respecto a la planificación suele ser mas perjudicial que beneficiosa para el proyecto.

Como el producto de la fase de diseño, el modelo de información que la aplicación debe implementar, es en definitiva una abstracción, mientras que el producto de la fase de construcción es una solución que debe funcionar en el mundo real, es muy importante que la estrategia de desarrollo contemple una vía rápida para que los usuarios y el equipo de proyecto puedan visualizar un prototipo funcional. La primera versión de este prototipo puede carecer de aspectos cruciales para la implementación definitiva, pero el mérito es que concreta la solución pretendida en algo que se puede ver y casi operar y por esta razón, incluso cuando se quiera hacer un desarrollo de software a la medida, en proyectos de cierta envergadura suele ser conveniente considerar el uso de alguna herramienta que permita una construcción rápida de un prototipo funcional.

Este prototipo funcional permitirá a algunos usuarios claves, de pensamiento más concreto y sin formación tecnológica, pero con un gran conocimiento de los procesos institucionales, aumentar su participación en el proyecto. Pero además de concretizar las conversaciones de los involucrados, disponer de un prototipo también tiene la virtud de establecer un norte para los desarrolladores que van a concretar la aplicación final. Con el prototipo hay dos maneras básicas de acometer el desarrollo. Una, refinarlo progresivamente, usando la herramienta de Arquitectura de información usada para hacer realidad el primer prototipo y eventualmente programar módulos complementarios requeridos. Dos, usar el prototipo como referencia concreta y desarrollar la aplicación como software a la medida.

Como hemos mencionado en distintas oportunidades, una aplicación hecha con Arquitectura de información tiene cinco dimensiones sobre las que hay que trabajar: estructura, funcionalidad, navegación, comunidades y seguridad e imagen y estética (Ver Las 5 dimensiones de la Arquitectura de Información ). La fase de desarrollo, realizada con herramientas modernas, permite un trabajo paralelo en estas dimensiones.

En un próximo post nos detendremos un poco más en las actividades que deben realizarse en la fase de construcción de soluciones desarrolladas con criterios de Arquitectura de Información..