archivo

Archivos diarios: agosto 19, 2012

Las expectativas del usuario y la calidad del software están muy por encima de las especificaciones funcionales, por eso que el producto final termine satisfaciendo el catálogo de requisitos funcionales (por mucho que se hayan refinado) no asegura ni el éxito del producto ni su calidad final.

Si solo pensamos en requisitos funcionales estamos limitando nuestra visión sobre lo que debe ser el producto final. Cada uno puede tener una definición de lo que considera calidad del software, en la mía no es condición suficiente la verificación de los requisitos funcionales (y probablemente muchos de vosotros estéis de acuerdo conmigo). Son importantes, no digo lo contrario, pero no es lo único.

Por un lado tenemos las expectativas que, si bien podría englobar los aspectos funcionales, contiene ingredientes adicionales como son la experiencia de usuario y la productividad en el uso de la herramienta (muy ligado a la anterior).

Y por otros los requisitos no funcionales (algunos de ellos serán detectados de manera temprana por los usuarios y podrían afectar a las expectativas del usuario sobre el producto), como por ejemplo, la mantenibilidad (deuda técnica), la disponibilidad, el rendimiento, los recursos que requiere y consume, etc…

Comenta Jim Highsmith que: “Quien toma la decisión es menos importante que hacer que la gente adecuada intervenga en el proceso de toma decisiones”.

Uno de los mayores errores de las personas que tienen que tomar decisiones, es decir, de todos nosotros porque a nuestra escala lo estamos haciendo continuamente, consiste en acariciarnos el ego tomando decisiones sin contar con nadie o minimizando la intervención de terceras personas.

Puede que seamos (o nos consideremos) los mayores expertos en una materia, puede que las personas que nos tengan que ayudar no tengan ni ese conocimiento ni esa experiencia pero eso no justifica que perdamos la oportunidad de que nos puedan aportar valor porque nadie puede controlar todas las perspectivas y es muy probable que ellos puedan aportar matices que no se hayan tenido en cuenta o puedan aportar ideas que enriquezcan la decisión final que se tome.

Además y por regla general no suele ser tanta la diferencia de conocimientos y experiencia entre la persona que tiene la última palabra y las personas que pueden aportarle valor a esa toma de decisiones (es más, lo normal es que en el área sobre la que se tenga que tomar la decisión, estas últimas tengan un conocimiento mayor, ya sea de base y/o por su mayor proximidad al problema o hecho sobre el que hay que decidir).

Como en todo, lo importante es dedicar al testing el tiempo que necesite la aplicación en función de su criticidad, complejidad, etc… y en función de cómo se ha desarrollado el proyecto. Lo difícil es precisar con exactitud cuánto es suficiente (y que exista disponibilidad real de tiempo y recursos para poder realizar esta actividad).

El problema es el de siempre, todo se deja para el final y el equipo de desarrollo no dedica tiempo suficiente al testing y además es más que posible que la calidad del código y de la arquitectura sea tal que la probabilidad de que existan errores de integración o por efectos colaterales es importante.

¿Qué quiero decir con todo esto? Pues que el tiempo es limitado y las condiciones para realizar el testing no serán en muchos casos las mejores (lo cual no quite que intentemos aproximarnos lo máximo posible a ese “tiempo que necesite” que comenté en el primer párrafo).

Esto nos lleva a que hay que priorizar. Si existen casos de prueba diseñados a medida o diseñables a partir de la documentación existente en el proyecto o de la combinación de la misma y conversaciones con los analistas, programadores, usuarios, etc… es necesario ejecutarlos, recordemos que donde más puede flaquear el equipo de testing si no ha participado en el proceso de definición y desarrollo del sistema es en la comprensión de la lógica del negocio.

Y después nos queda el testing exploratorio para intentar cubrir los huecos (muchas veces numerosos) que dejarán tras de sí los casos de prueba. ¿Hacia dónde lo enfocamos?, ¿donde invertir el esfuerzo? Yo lo respondo con otras preguntas: ¿qué partes del sistema son las críticas?, ¿qué aspectos no están cubiertos con casos de prueba?, ¿qué partes del sistema están integradas con otros (ya sea para recibir y/o enviar información)?, ¿qué aspectos no están cubiertos con casos de prueba?, ¿existe una matriz de compatibilidad con navegadores de la aplicación?, ¿se han dedicado pruebas a ello?.

Hacer un buen testing exploratorio no es sencillo, se requieren testers con experiencia y conocimientos para que a través de ello y de la información que dispongan y consigan saber dónde enfocar los esfuerzos. Ahora bien, no esperes un trabajo excelente si no se les proporciona ayuda y/o información y además el tiempo es muy limitado.

Si un sistema tiene una deuda técnica alta y en particular presenta un alto acoplamiento entre clases, la realización de testing exploratorio resulta crucial ya que en este caso, los efectos colaterales pueden aparecer hasta en el sitio más insospechado de la aplicación, en este caso hay que sacar el tiempo que sea necesario a realizar las pruebas oportunas ya que no podemos dejar que el comportamiento de la nueva versión del sistema en el entorno de producción sea como jugar a la ruleta rusa. En producción que, por favor, las sorpresas sean las mínimas posibles.