Imagina un queso suizo – Si, ese queso amarillo con huecos como el de las caricaturas-. Ahora imagina que tomas un cuchillo y vas cortando el queso en rebanadas finas: Cortas y cortas y cortas… hasta el infinito. Solo recuerda que cada  rebanada la debes colocar encima de la capa anterior.

Durante este proceso infinito de cortar, notarás como en cada rebanada existen unos agujeros que permiten ver la capa de abajo. Existirán agujeros por aquí, por allá y por “acuya”. Vas a dejar de cortar rebanadas de queso hasta que al menos tres capas tengan huecos que coincidan entre ellas.

El queso suizo representa cualquier proceso crítico de la vida real; llámese pilotear un avión, construir un cohete, construir un puente o construir productos de software. Los huecos vendrían a ser los desperfectos y malas desiciones que hayamos tomado. Cuando los huecos de dos o mas capas de queso suizo coinciden entre si es cuando ocurre la desgracia, y el riesgo latente se materializa producto de nuestro descuido .

El modelo del queso suizo es ampliamente utilizado en el análisis de riesgos y gestión de riesgos, originalmente ideado por James T. Reason. Describe lo que ocurre cuando muchos desperfectos y condiciones ideales se alinean en un instante de tiempo causando una desgracia, catastrofe o errores en productivo de tu producto de software.  

Errores de software

Los errores de software siempre existirán, y eso es inevitable. Sin embargo, es posible reducir la cantidad de errores en un proyecto de software mediante la implementación de procesos o protocolos que permitan descubrir y reducir el riesgo existente.

• Evitar postergar la inspección de anomalías, no permitas que se acumulen con el tiempo.
• Añadir pruebas de software para evitar que un error detectado y corregido ocurra de nuevo, se debe demostrar que la corrección funciona correctamente.
• Nunca evadas o tomes a la ligera el cumplimiento de protocolos que existan en tu organización, esto puede ser la diferencia entre la vida y la muerte de terceros o miembros de la misma organización.
• Si puedes, realiza pruebas con tu producto entonces utilízalo de formas inesperadas, trata de emular las acciones de usuarios reales.
• Si se reportan anomalías en tu producto, es de ley que debes reproducir el error en tu ambiente de desarrollo. Debes usar las mismas variables de entorno y configuraciones. Es un mandato divino que cumplas con esta regla si tu producto es altamente critico. De esto dependerá la vida de mucha gente.

Si tus quesos se alinearon entonces debes medir el impacto del desperfecto: 

• cuándo ocurrió(fecha y hora exacta)
• Módulos / áreas de la organización o sistemas se vieron involucrados�
• A quienes afectó (usuarios)
• Porqué ocurrió, detalladamente�
• Cómo se evitará que ocurra nuevamente: acciones a tomar, protocolos a crear o correcciones en el producto�
• Idear correcciones o medidas para amortiguar el impacto de forma temporal en lo que la solución final exista
• Reproduce el maldito error y no esquives la responsabilidad de reparar un desperfecto que a la larga puede ser letal

Tipo de pruebas podemos utilizar para ejercitar nuestro software:

• Crear pruebas unitarias donde los desarrolladores y programadores escriban sus propias validaciones. Las pruebas escritas se deberían ejecutar en cada nuevo cambio dentro del proyecto para comprobar que no exista más ese problema o incluso para detectar errores de lógica que pudieran surgir.
• Pruebas de usabilidad de usuario, el usuario final debería utilizar el sistema y anotar sus observaciones para ir puliendo y corrigiendo los problemas que surjan. La lista de pruebas que aquí se usan pueden ser generadas con bugzilla utilizando los requerimientos originales y exponiendo lo que el sistema debería hacer o no hacer. Cada retroalimentación del usuario debería añdirse a la testcase o test suite correspondiente.
• Pruebas funcionales: aquí se pueden realizar pruebas de las funcionalidades principales, JMeter de apache podría ser una buena herramienta para desarrollar este tipo de pruebas automatizadas.
• Pruebas no funcionales, de igual manera consiste en tomar tu lista de pruebas e irlas retroalimentando con cada problema que surja y se corrija. JMeter de apache continua siendo buena opción para ello.

Para una lectura mas profunda recomiendo el libro de “Software engineering” de Ian Summerville:

Por último quiero recalcar que como profesionales debemos tener la ética siempre presente y los pies en la tierra. Ya que ignorar desperfectos en nuestros productos puede tener repercusiones mas allá de un simple error en pantalla. Evita que se repita la historia del Therac-25, el cuál mato a una gran cantidad de personas al lanzar dosis letales de rayos-x y todo debido a un simple error de software, malas desiciones de la empresa que la creo y la irresponsabilidad de no prestar atención a reportes anteriores.