QAustral

Un Blog de QAustral SA – Calidad de Software y Negocios

Home » Posts tagged "bug" (Page 2)

Errores con historia

NANJING, (Xinhua) — El 8 de noviembre de 2008, expertos en informática chinos estimaron que la aparición de un error en el software del antivirus chino de la compañía Ruixing, que apoyaba los buzones de correo de Outlook Express de Microsoft, puede haber causado una pérdida masiva de correos electrónicos a millones de usuarios de la aplicación.

La compañía Ruixing presentó una disculpa pública y admitió que un error en su software del antivirus Kaka causó la eliminación automática de las listas de correo a los usuarios del sistema Outlook y los archivos conocidos como “cookie”.

Ma Gang, portavoz de Ruixing, dijio que la compañía había hecho una actualización de emergencia del antivirus Kaka. Además, urgió a los usuarios a descargarse la versión actualizada y reiniciar sus computadoras para evitar el error.

La compañía también abrió una línea telefónica para ofrecer ayuda a los clientes afectados para que puedan recuperar sus correos electrónicos perdidos.

Zhao Cheng, empleado de una compañía comercial en Nanjing, capital de la provincia china oriental de Jiangsu, afirmó que había perdido todos sus mensajes en su cuenta de Outlook.

“Tenía pedidos de clientes en el buzón de entrada, pero ahora no hay nada”, dijo. Al parecer, el sistema producía automáticamente diversos archivos del tipo “dbx”, que no pueden ser eliminados.

La compañía informática Ruixing, con sede en Beijing, es una de las empresas líderes en el software de antivirus en China.

El primer Bug

Un defecto de software (computer bug en inglés), es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora (software). Dicho fallo puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. Los errores pueden suceder en cualquier etapa de la creación de software.

En 1947, los creadores de Mark II informaron del primer caso de error en un ordenador causado por un bicho. El Mark II, ordenador sucesor de ASCC Mark I, construido en 1944, sufrió un fallo en un relé electromagnético. Cuando se investigó ese relé, se encontró una polilla que provocó que el relé quedase abierto.

Grace Murray Hopper, licenciada en Física y destacada matemática que trabajó como programadora en el Mark II, pegó el insecto con cinta adhesiva en la bitácora (imagen) y se refirió a ella como “bicho” para describir la causa del problema.

Bug

El evento fue documentado en el log de funcionamiento del ordenador:

1545 Relay #70 Panel F (moth) in relay. First actual case of bug being found.
Un polilla en un relé. Primera vez que se encuentra [en un ordenador] un «bug» de verdad.

Este incidente es erróneamente conocido por algunos como el origen de la utilización del término inglés “bug” (bicho) para indicar un problema en un aparato o sistema. En realidad, Thomas Alva Edison ya había utilizado “bug” en algunas anotaciones relacionadas con interferencias y mal funcionamiento. Grace lo asoció por primera vez a la informática, en este caso, relacionado a un insecto real. No obstante, durante los años 50 del Siglo XX, Grace también empleó el término “debug” al hablar de la depuración de errores en los códigos de programación.

Los programas que ayudan a detección y eliminación de errores de programación de software son denominados depuradores (debuggers).

By Wikipedia

Frases Celebres Testers vs Devs (Negociacion)

Al comienzo de mi carrera pensé que solo en Argentina los desarrolladores usaban estas frases para excusar bugs o justificar algo pero con el paso de los años note que es una característica común en ellos. Mi frase preferida es: En Desarrollo (en el ambiente) funciona perfectamente!

Quien no la habra escuchado. Como si eso hiciese desaparecer magicamente el bug o como si fuese un justificativo valido. Quizás sea gracioso leerlo así pero genera un gran desafío para el Tester hacer entender al Desarrollador que realmente es un bug o que el hecho que funcione en su PC no es ningún justificativo sin entrar en discusiones. Sabiendo que muchos profesionales que desarrollan se siente observados por el area de testing o como si estuviesen bajo una continua evaluacion los testers deben ser habiles mediadores no generadores de conflictos. En empresas donde no hay un procedimiento claro sobre casos de usos o donde se deja la posibilidad a que el Desarrollador use su imaginacion, cuando el sistema se encuentra en Test se escuchan frases como:
* Esa funcionalidad nunca se especifico.
* No lo realice como el cliente lo solicito porque encontre una mejor manera de hacerlo.(Muy pocas veces es asi)
* Nadie se va a equivocar cargando informacion, etc.
Voy a postear mas frases celebres en breves, lo importante de todo esto es nunca discutir sino negociar y hacer entender los errores reales a los desarrolladores. Trabajar para que no se sientan perseguidos o bajo constante evaluacion.

By Sergio E Cusmai
www.qaustral.com