Errores de software: Las tres causas de los errores de programación
«Bug» es una palabra común entre los profesionales del software. También conocidos como defectos, un bug significa simplemente que el software no se comporta como se esperaba. La palabra bug se utiliza con bastante libertad para referirse tanto al síntoma como a la causa.
En términos correctos, un bug es realmente un error humano que produce un defecto que provoca un fallo en el funcionamiento del software, lo que resulta en un mal funcionamiento que causa algún tipo de daño. Por desgracia, la mayoría de los defectos de software causan daños que son mucho peores: pérdida de tiempo y nervios.
A veces, la misma secuencia de acciones puede provocar un mal funcionamiento para un usuario pero no para otro. La gente del software suele llamarlos «fallos aleatorios». En realidad, no hay fallos aleatorios. El efecto (la aparición del fallo) puede ser aleatorio, pero la causa (el error en el código) siempre está ahí: el mal funcionamiento se produce por una razón.
Errar es humano
La causa de un error de programación suele ser uno de los tres «fallos»:
Los errores provocan fallos masivos
Los desarrolladores se enfrentan a menudo a plazos poco realistas para entregar nuevas funcionalidades, realizar mejoras o implantar correcciones. En estas condiciones, es fácil imaginar cómo cometen errores los desarrolladores de software. Tocan la letra equivocada, confunden una variable con otra, utilizan accidentalmente «mayor que» en lugar de «menor que» o colocan un valor de índice desviado en uno. Un pequeño error tipográfico puede ser la causa de un fallo masivo.
El malentendido es una forma más compleja de error humano
El desarrollador hace que el código se comporte exactamente como quería; sin errores. En cambio, el desarrollador malinterpreta cómo debería comportarse el software. Todos lo hemos hecho: leer instrucciones, creer que haces exactamente lo que se te indica, sólo para darte cuenta más tarde de que entendiste mal la instrucción.
Las instrucciones de los desarrolladores de software se conocen como «requisitos». Los requisitos son descripciones en inglés sencillo de cómo debe comportarse el software. Estos malentendidos suelen salir caros. Suelen detectarse en las últimas fases de las pruebas y, a menudo, los probadores tampoco los detectan.
A menudo, el error está sorprendentemente en el propio requisito. No es raro que un desarrollador implemente un requisito exactamente como se describe y descubra más tarde que el software no se comporta como los usuarios reales habrían esperado. Esto sigue siendo un error, pero no un error de programación.
La suposición errónea es la forma de error más desafiante
Como diría Einstein: «Se hacen suposiciones y la mayoría de las suposiciones son erróneas». Pero los desarrolladores de software necesitan hacer muchas suposiciones.
Suponen que sus herramientas de programación y los sistemas operativos subyacentes están libres de errores. Suponen que las bibliotecas de utilidades que utilizan se comportan de una determinada manera. Suponen que el otro sistema con el que interactúa su código siempre responde adecuadamente. Suponen que la respuesta de ese otro sistema nunca supera los 1024 bytes. Y así sucesivamente. Nunca se puede estar preparado para todo.
Sin embargo, esas dependencias no permanecen constantes. El sistema operativo subyacente recibe una actualización de versión o el desarrollador de al lado lanza una nueva versión de su biblioteca. La URL de la API web cambia. Lo bueno de las suposiciones erróneas es que el código correcto de un desarrollador puede empezar a funcionar mal aunque el desarrollador no lo haya tocado en absoluto.
La importancia de encontrar errores
El trabajo de un probador de software consiste en encontrar los errores en un entorno controlado antes de que el software se ponga a disposición de los usuarios reales. Y con unos plazos estrictos, nunca hay tiempo suficiente para hacer pruebas a fondo. Además, los probadores también son seres humanos y pueden cometer errores. En el mejor de los casos, las pruebas manuales pueden reducir la probabilidad de mal funcionamiento en producción, pero nunca eliminar por completo todos los fallos.
Si los probadores no encuentran muchos fallos, puede significar varias cosas:
- el software se ha probado mal: los errores están ahí, pero aún no lo sabemos
- los desarrolladores han hecho un gran trabajo probando su código, de modo que queda poco para que el probador lo encuentre
- los clientes encontrarán los errores y luego se quejarán
La regla de oro es no confundir nunca la ausencia de pruebas con la prueba de la ausencia. Que no hayas encontrado un fallo no refuta totalmente que pueda existir. Con tal incertidumbre, ¿cómo puedes optimizar el proceso de pruebas para maximizar el número de fallos que encuentras?
Para empezar, hay que eliminar tantos errores humanos como sea posible. Ahí es donde entra en juego la automatización de las pruebas. En combinación con la entrega continua, las pruebas automatizadas permitirán a su equipo realizar pruebas más exhaustivas y en fases más tempranas del proceso. La automatización de las pruebas permite detectar los errores en su origen, en lugar de hacerlo más adelante, cuando es más difícil y costoso corregirlos.
Con la presión de entregar cada funcionalidad más rápido, el tiempo es esencial para los desarrolladores, que, por desgracia, es un recurso escaso del que nunca parecen tener suficiente. Aprovechar la automatización de pruebas junto con los flujos de trabajo de los desarrolladores aumentará la productividad sin tener que preocuparse de introducir más errores o de pasar por alto errores al principio del proceso de desarrollo.
