Imagina que eres un contador público que lleva la contabilidad de una gran empresa que se dedica a la venta y compra de insumos variados (vamos a suponer que la empresa se dedica a proveer servicios eléctricos). Todos los días generas facturas por las compras y ventas que realiza la empresa a diferentes clientes y proveedores. Para ello utilizas una aplicación que se encarga de hacer las facturas que necesitas y además te ayuda a hacer la contabilidad diaria del lugar.

Un día llega a tu bandeja de correo electrónico un correo del temido SAT (Secretaría de Administración Tributaria, México) diciéndote que hay una serie de irregularidades con muchas de las facturas que generaste en el ejercicio fiscal pasado. Te invade el miedo (a quien no, es el SAT) y empiezas a preguntarte cómo es posible eso. El SAT te pide que acudas a sus oficinas a checar de manera presencial estas irregularidades. Al llegar al lugar te mandan con un agente especializado que te explica la situación por la cual tus patrones ya empezaron a preocuparse. El agente te explica que hubo errores en los cálculos de impuestos aplicados en las facturas emitidas. Se habla $15,000,000.00 MXN de pesos no declarados. ¿Cómo es posible?, te preguntas. Le muestras tu libro de contabilidad al agente y en ella ambos ven que esa suma de dinero no declarada aparece perfectamente marcada en los registros. Pudiera ser un error en la aplicación que genera facturas, te comenta el agente.

De regreso a tu trabajo, checas inmediatamente los registros de configuración del módulo que se encarga de generar facturas en la aplicación y te encuentras con la desagradable sorpresa de que muchos de los campos de impuestos no están actualizados conforme a las nuevas reformas tributarias del año fiscal en curso. Recuerdas que el proveedor del programa mandó un correo comentando que iban a hacer un mantenimiento general en todos sus servicios fiscales. Llamas al proveedor, le explicas la situación y éste te responde que hubo un error al momento de aplicar las actualizaciones en varios módulos fiscales. No se hicieron las pruebas que validaban los nuevos cambios que se implementaron. Ahora tendrás que esperar a que solucionen el problema y volver a generar las facturas correspondientes, sino el SAT le cobrará una cuantiosa multa al lugar donde trabajas (y puede que tu trabajo corra peligro).

Si bien esta historia es ficticia, no está nada alejada de la realidad. En nuestra vida diaria usamos software para muchas cosas: para realizar pagos por algún servicio, para realizar transferencias interbancarias, para tomar videos y fotografías, para checar nuestro correo electrónico o redes sociales, etcétera. Por más sencillos que parezcan, hay electrodomésticos que también utilizan software para cumplir con ciertas tareas.

La mayoría de lo que usamos en nuestra vida diaria debe, o debió, haber pasado por estrictos controles de calidad. Esto no es solamente algo que incumba solamente al área de desarrollo de software.

Aún es muy común escuchar que hacer pruebas de software no son tan necesarias. Es más, algunos lo ven como inútil. Con tal de entregar un producto final al cliente, muchos prefieren saltarse el área de pruebas. O peor aún, ahorrarse dinero y tiempo en esta parte (más adelante veremos los costos que conlleva).

Hacer pruebas nos puede ayudar a reducir el riesgo de fallas que pudieran ocurrir durante el uso de algún producto. Cuando se han detectado los defectos, y subsecuentemente arreglado, esto contribuye a la calidad de los componentes o sistemas que serán utilizados. Además, las pruebas de software deben cumplir con los requerimientos legales o contractuales o los que la industria demanda.

No hacer pruebas de software solamente puede causarnos pérdidas económicas como en el ejemplo que describo arriba, sino también humanas.

Hay dos casos muy famosos que usaré de ejemplo. El primero de ellos es el del Therac-25, un acelerador líneal de radioterapia creado en la década del 70 del siglo XX por la Atomic Energy of Canada Limited (AECL). Fue el causante de al menos 6 muertes por sobredosis de radiación entre 1985 y 1987. El 6 de febrero de 1987, la FDA (U. S. Food & Drug Administration, Estados Unidos), ordenó una suspensión de todas las unidades Therac-25 hasta que se pudieran realizar las reparaciones pertinentes. En los peritajes se encontró que el software empleado por la máquina no fue probado de manera adecuada, además de que se habían utilizado «parches» de software de versiones anteriores de la máquina. Nunca se hicieron las pruebas del software sobre el aparato que estaba siendo desarrollado, generando la falsa idea de que el software estaba libre de bugs (errores).

Therac-25 is a glaring example of what can go wrong in a society that is heavily dependent on technology.

Ethics Unwrapped, University of Texas

El segundo caso, más reciente, es el del Boeing 737 Max, un avión comercial diseñado por Boeing que fue el causante de al menos 346 personas. De acuerdo con testimonios de empleados de Boeing, muchas de las piezas empleadas para la fabricación de esta aeronave no cumplían con los estándares de calidad requeridos. En febrero de 2020, Boeing encontró otro bug relacionado con el indicador de luz. Éste seguía más tiempo encendido de lo previsto. La luz está asociada con el sistema de ajuste del estabilizador, que sube y baja el morro (nariz) del avión. Comparto con ustedes un reportaje realizado por la agencia de noticias Deutsche Welle que explica este caso a detalle:

Viendo los casos anteriores puede surgir la pregunta ¿por qué no se hacen pruebas a los productos que se están desarrollando? Es una pregunta con múltiples respuestas, citaré algunas de ellas:

• Se descarta o evita hacer pruebas. El software está libre de defectos (¡vaya falacia!)
• Se cree que hacer pruebas es innecesario
• No se realizan pruebas en las fases más tempranas del proceso de desarrollo de software (lo ideal sería hacerlo)
• Se cree que el tester (probador) debe probar todo cuando las pruebas son competencia de todos los involucrados en el producto
• Se cree que el tester debe hacer las pruebas que le corresponden al developer (desarrollador)
• No se asigna (o se reduce) tiempo y dinero a las actividades de pruebas
• No se comparte conocimiento sobre el producto que se está desarrollando
• Hermetismo
• Intereses políticos y económicos

Lamentablemente muchas personas y empresas son conscientes de todo esto, pero prefieren tomar el riesgo de no hacer pruebas con tal de entregar un producto a tiempo. ¿Pero a costa de qué o quiénes? ¿vale más el dinero que una vida humana?

Al principio del texto mencionaba que no hacer pruebas conlleva muchos costos y pérdidas. Reparar un defecto en la etapa de toma de requerimientos es más barato que repararlo cuando éste se encuentra en la etapa de pruebas o producción-liberación de producto final. La siguiente gráfica da una idea de cómo los costos se incrementan conforme el defecto va pasando por las diferentes etapas del desarrollo de software.

En conclusión, podemos deducir que hacer pruebas es muy importante. No solamente nos dan seguridad del producto que se está desarrollando, también nos pueden ayudar a evitar pérdidas económicas, humanas y de prestigio.

Como usuarios finales es nuestro derecho exigir que nuestros productos cumplan al menos con los mínimos estándares de calidad para poder utilizarlos. Así también es nuestro deber denunciar ante las autoridades correspondientes a aquellas personas que liberen productos de mala calidad. Debemos ser críticos de los productos que llegan a nuestra manos y no confiar plenamente en ellos.

Al final del día, la calidad de las cosas depende de todos.

Bibliografía

• Therac-25. Ethics Unwrapped. University of Texas. Consultado el 14 de noviembre de 2020 en: https://ethicsunwrapped.utexas.edu/case-study/therac-25
• How the Boeing 737 Max Disaster Looks to a Software Developer, por Gregory Travis. IEEE Spectrum. Consultado el 14 de noviembre de 2020 en: https://spectrum.ieee.org/aerospace/aviation/how-the-boeing-737-max-disaster-looks-to-a-software-developer
• Boeing 737 MAX: el demoledor informe del Congreso de EE.UU. sobre la responsabilidad por los accidentes aéreos que dejaron 346 muertos. BBC. Consultado el 14 de noviembre de 2020 en: https://www.bbc.com/mundo/noticias-internacional-54171645
• Airlines have completely stopped ordering the 737 Max, por Chris Isidore. CNN Business. Consultado el 14 de noviembre de 2020 en: https://edition.cnn.com/2019/04/09/business/boeing-737-max-deliveries/index.html
• A new software glitch was discovered on Boeing’s 737 Max, por Chris Isidore. CNN Business. Consultado el 14 de noviembre de 2020 en: https://edition.cnn.com/2020/02/06/business/boeing-737-max-software/index.html
• The exponential cost of fixing bugs, por Sanket. DeepSource. Consultado el 14 de noviembre de 2020 en: https://deepsource.io/blog/exponential-cost-of-fixing-bugs/

_____________________________________________________________
Síguenos en: Facebook, Instagram, Twitter y LinkedIn
¡No olvides seguirme en Twitter!: @_ArCiGo