¿Hace falta un terremoto? …

(Publicado originalmente septiembre 2010)

Releyendo recientemente conceptos de BCM (Business Continuity Management) y de ITSCM
(IT Service Continuity Management), no pude dejar de relacionar el tema con algunos aspectos de las pruebas de software, y la evaluación y mitigación de riesgos, y la gestión de servicios en general, que también hemos destacado en otros artículos de este blog mis colegas y yo anteriormente.

Esos aspectos están relacionados también con las características / sub-características / métricas de calidad de producto descriptas en la norma ISO 9126 y que pueden evaluarse según el proceso descripto por la norma ISO 14598, con las más actuales ISO/IEC 25000 SQuaRE
de calidad de productos de software, y con las normas ISO 20000 que especifican los requisitos de implementación de la gestión de servicios de TI. (Ver Referencias)

En definitiva, están relacionados con los requisitos o requerimientos no funcionales (RNFs) de las aplicaciones que construimos y probamos.

Lamentablemente, en muchas ocasiones, estos aspectos son ignorados o postergados en los proyectos de construcción de software, hasta que ocurren desastres, accidentes, ataques u otros incidentes más o menos críticos, que no siempre necesitan ser de la gravedad de un terremoto, pero que afectan a la disponibilidad de los servicios de TI, o incluso a la posibilidad o forma de restaurar esos servicios luego de algún tipo de evento que ha afectado a su continuidad.

¿Por qué digo que lamentablemente estos aspectos son ignorados o postergados?

Porque suele ocurrir que:

Los RNFs no están especificados, detallados y/o cuantificados.
Se considera que no es momento de probarlos, porque se puede hacer más adelante, o no son riesgosos, o no hay tiempo antes de salir a producción.
Se considera que no es momento de considerarlos en el análisis o diseño de la solución, porque se puede agregar más adelante.
No se ha considerado qué puede ocurrir en ambientes productivos, con mayor interacción de componentes de HW / SW que en los ambientes de prueba.
No se ha previsto qué pasa con el crecimiento de tamaño de entidades de datos, y/o no se han previsto mecanismos de depuración de las mismas.
No se han previsto mecanismos de recuperación ante caídas, o lo más grave aún, no se ha analizado o diseñado para gestionar transacciones en las aplicaciones que lo requieren. También se considera que esto es algo que puede agregarse más tarde.
No se ha planificado quién, cuándo, cómo se actúa ante algún incidente o desastre, o cómo se restaurará la operación normal del sistema, o en qué condiciones de pérdida de información, o se desconoce incluso si toda la información necesaria está respaldada.
No se ha analizado si en función a las características y tipo de solución de software, existen disposiciones legales o regulatorias que apliquen a la misma.
Se considera que todo se resuelve agregando más o mejores servidores / disco / memoria / hardware de comunicaciones.
… y seguramente cada uno tiene un conjunto más de ítems que agregar a esta lista, a partir de su experiencia en diversos proyectos y organizaciones…

Mis opiniones

Desde nuestro rol en las áreas de Calidad o como líderes de práctica, líderes de equipos, o como testers, es nuestra responsabilidad llamar la atención sobre estos temas al líder de proyecto, cuando consideramos que pueden haber sido descuidados, o no los encontramos representados en los planes de proyecto y/o prueba. Al menos preguntar.
Hacen a la calidad de los productos y servicios que estamos colaborando a entregar.

Está claro que los requerimientos no los ponemos nosotros, ni podemos constituirnos en los "guardianes de la calidad" impidiendo que se entreguen a producción productos que creemos no están totalmente probados o todavía presentan defectos… por algo hablamos de pruebas basadas en riesgos, de entregar productos con un nivel suficiente de calidad, de priorizar defectos y no corregirlos, de involucrar a referentes usuarios en esa priorización, etc. .

Pero también considero que está totalmente en línea con nuestra misión como testers, capacitarnos y "evangelizar" sobre estos conceptos… antes de que nos golpee algún terremoto.