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.