viernes, 15 de noviembre de 2013

Pruebas de comunidades y seguridad

La importancia de probar la seguridad salta a la vista,
pero hay algunos detalles que conocen los
 Arquitectos de información de experiencia que vale la pena revisar
Coherentes con el discurso general que hemos mantenido de que una aplicación con una buena Arquitectura de Información tiene cinco dimensiones: Estructura, Funcionalidad, Navegación, Seguridad y Estética y que todo lo que se construye en la fase de desarrollo debe probarse, y habiendo hablado ya de las pruebas de las tres primeras y de la última, dedicaremos el día de hoy a hablar del importante e insoslayable tema de las pruebas de seguridad. La importancia salta a la vista, pero hay algunos detalles que conocen los Arquitectos de información de experiencia que vale la pena examinar.

Las pruebas de seguridad deben permitirnos corroborar que la solución que se construyó cumple a cabalidad las especificaciones que la fase de diseño legó a la fase de desarrollo en cuanto a los perfiles de las comunidades de usuarios que usará la solución automatizada en la que trabajamos. Cuando esto es así es posible confiar en los resultados y operar con la aplicación construida en forma segura y consistente.

Cuando el proceso de desarrollo es guiado con una Arquitectura de Información definida y bien establecida, (ver Las cinco dimensiones de la Arquitectura...) y se usan herramientas apropiadas, la funcionalidad debe poder desarrollarse con independencia de las comunidades de usuarios y la seguridad. El énfasis cuando se trabaja con la funcionalidad es que todos los casos de uso definidos se comporten según lo especificado en el diseño, por eso, salvo las pruebas que involucran la funcionalidad que está dirigida al público anónimo no identificado, es válido, en las primeras etapas de la fase de construcción, hacer las pruebas funcionales sin reparar en los permisos. Esto equivale a hacer verificaciones de resultados operando el sistema con la figura de un administrador o súper usuario al que le es permitido hacer todo tipo de cambios.

Lo que se establece durante el proceso de construcción de la seguridad es precisamente qué es lo que cada comunidad de usuarios puede hacer con cada objeto de información y esto debe poder definirse y redefinirse para cada comunidad sin afectar adicionalmente las otras dimensiones del desarrollo y las otras comunidades. Simplemente se recorre cada perfil de usuario y se establece qué puede hacer y qué no puede hacer y, de nuevo, si las herramientas de desarrollo usan criterios de Arquitectura de Información, los resultados deben cumplir las especificaciones diseñadas.

Las pruebas de seguridad deben alinearse también con los casos de uso (ver Conceptualización de la solución y casos de uso). Para cada comunidad hay que probar que puede hacer lo que está definido que puede hacer en cada caso de uso que es válido para ella. También hay que probar que no puede hacer lo que está definido que no puede hacer. Son dos tipos de pruebas que son complementarias porque se no sustituyen entre sí.

Es muy importante cuando se vayan a hacer las pruebas de comunidades y seguridad llevar un registro de cada prueba y cada resultado y dejarlo grabado como línea base debido a que es imprescindible en un desarrollo confiable que estas pruebas con cada comunidad se automaticen ya que, en ningún momento, debería haber dudas acerca de la confiabilidad con que se trabaja al usar una aplicación. Resulta imprescindible por tanto poder ejecutar  las pruebas de seguridad cada vez que se cambie cualquier variable involucrada en el sistema, así se trate de un elemento aparentemente intrascendente. Esto debe convertirse en un hábito.

Un error de algunos desarrolladores nóveles es suponer que como se probó para dos comunidades y todo trabajó bien se puede extrapolar el buen esultado y suponer que todo seguirá trabajando bien con las restantes que son del mismo tipo. Esto no es necesariamente cierto y lo razonable es probar con cada comunidad de usuarios y automatizar las pruebas para que el hacerlas con todas no sea limitado por el tiempo y el trabajo que tales pruebas involucran.

No hay comentarios: