CODERE, un caso para entender y no repetir

A primera vista el error en la maquina del bingo se trato de una mala interpretación de los decimales y los separadores de miles, lo que derivo en que la maquina multiplicara por mil el valor del premio. Ahora esto da a pensar que si se hubiera testeado el software de la maquina simulando el premio máximo, este error hubiera surgido antes de salir del laboratorio. Esto es una apreciación muy a la ligera, ya que no conozco el esquema de desarrollo y el origen del equipamiento, pero nos sirve como ejemplo o aproximación a los problemas de falta de test.

Otro ejemplo que puedo citar me sucedió a mi personalmente hace varios años, un día deposite en mi banco un cheque, en la cuenta a los pocos días se me acredito el cheque dos veces, como esa cuenta la usaba poco, solo para pagar impuestos por debito, no me preocupe en revisarlo por unos días, a los 10 días de la acreditación del cheque, me llaman del banco para informarme que tenia un saldo negativo importante en la cuenta y que debía cubrirla a la brevedad. Me asombre y fui a averiguar al banco, la primer respuesta fue que me habían rebotado el cheque que había depositado y debía ir a buscarlo a la sucursal del deposito, me remití a la sucursal y en ese lugar me informan que no tenia ningún cheque rechazado en ese momento una empleada de la sucursal me ayudo a revisar la cuenta y encontramos que el cheque se había acreditado normalmente pero con un pequeño detalle, se había acreditado dos veces. días después de la acreditación el banco sin ningún aviso debito dos veces el importe acreditado y la cuenta era fácil, el cheque original 1000, doble deposito 2000, doble debito para arreglar el error 4000.

Este tipo de errores se refieren solo a aspectos monetarios, pero que pasaría si el software de un avión  calcula mal la altura de vuelo, o si un respirador artificial maneja mal los valores y corta el oxigeno.

Para todo esto, que siempre se refiere a aplicaciones informáticas, existen normas de aseguramiento de calidad que implican pruebas de todas las funcionalidades disponibles en un sistema antes de certificarlo para largarlo a trabajar en la vida real. Para que tengan una idea el desarrollo de una aplicación en resumidas cuentas se divide en 4, el diseño, el desarrollo, el testing y la puesta en marcha. El diseño debe tener en cuenta todos los requerimientos del cliente para cubrir sus demandas, pero además debe incluir todos los casos de trabajo en los que la aplicación funcionara, el desarrollo debe ser realizado a conciencia y conociendo las herramientas y el destino, el testing debe ser realizado por personal especializado y a fondo para probar las alternativas posibles y las imposibles incluyendo pruebas de carga para saber como reaccionaria el sistema a situaciones mas allá de lo normal, finalmente la puesta en marcha solo implica la entrega del producto CERTIFICADO al cliente.

Hoy en el mercado hay muchas normas y procedimientos para elegir, y la mayoría de las empresas serias reclaman a sus desarrolladores que tengan protocolos de trabajo y hasta certificaciones similares a las normas ISO, como ejemplo la tan nombrada certificacion CMMI, en la realización del software. Algunas empresas contratan a consultoras que se dedican exclusivamente al testing, lo que permite que auditen la calidad de los productos sin interferencia de la empresa desarrolladora.

Estamos acostumbrados en Argentina a crear productos de Calidad?, la respuesta es difícil pero en lo que es el mercado tecnológico creo que gran parte de las empresas lo tienen en cuenta, normalmente los clientes quieren los desarrollos rápido, y algunos optan por cortar los ciclos de calidad, pero este tipo de procedimientos es la piedra angular de los desastres.

Si este fue el problema de CODERE no me gustaría estar en los pantalones de los desarrolladores y los encargados de calidad. A los clientes los invito a que tengan en cuenta este articulo cuando esten comprando algún desarrollo y EXIGAN los certificados de calidad y los sets de pruebas. Tengan en cuenta que el control de calidad debe por lo menos probar todas las funcionalidades posibles de un sistema, esto insume tiempo, el tiempo es dinero, pero por ahorrar hoy tenemos que prepararnos para pagar mañana.