Alguna vez platicaba con colegas sobre los defectos en un proyecto y sin querer usé una frase que parecía incongruente y algo ridícula: “este defecto hace que el programa ‘X’ truene feo”.
Por: J.P.
Nos reímos por lo absurdo de la frase: el simple hecho de que una aplicación “truene” (es decir, falle) debido a un defecto quiere decir que el software tiene algo mal. Decir que algo “truene feo” es redundante, ya que sería muy difícil que algo “truene bonito”, que falle en una “buena manera”. Pasada la broma, en un impulso de pensamiento lateral, me cuestioné: ¿puede algo realmente tronar feo?
En buena parte de la industria del desarrollo de software en México sigue vigente la idea de que las pruebas son sólo para confirmar que todo funciona bien. Las pruebas, según estas creencias, deben enfocarse en los happy paths y mostrar a los involucrados que una aplicación está lista para salir al público ya que ha cumplido con los principales escenarios previstos. En estos casos las pruebas las hace el mismo grupo que desarrolló la aplicación, siendo así juez y parte del producto con todo y sus defectos. No es de extrañarse entonces que los fallos más inesperados y más críticos le ocurran al cliente final.
Por otro lado, ya tenemos a un considerable sector que entiende la esencia del testing: encontrar problemas. Si bien las pruebas nos ayudan a confirmar que todo funciona tal como requería el cliente (al menos en sus flujos más elementales), esto es sólo una parte de todo el proceso que involucra realmente el probar software.
El valor en las pruebas está en encontrar los defectos antes de que lleguen al usuario final, similar al control de calidad de algunos productos de manufactura. Por lo tanto, el objetivo del ingeniero de pruebas es encontrar las maneras en que un sistema puede “romperse” o puede desviarse del funcionamiento esperado. Bajo esta premisa, la meta del tester es que “las cosas truenen”.
¿Es posible que algo “truene feo”? En un inicio, lo consideré algo redundante y absurdo. No obstante, aquellos familiarizados con el desarrollo de software sabemos que hay toda una variedad de tipos de defectos por reportar y esto me llevó a pensarlo con más profundidad. Se pueden clasificar defectos desde los más triviales, pasando por mejoras, menores, mayores y bloqueantes hasta llegar a los más críticos. Es casi tan importante clasificar un bug como lo es el encontrarlo. De otro modo habría un caos en su administración y priorización, lo cual podría llevar a un equipo a malgastar el tiempo en typos e implementación de mejoras en lugar de corregir errores que pueden afectar la seguridad, disponibilidad e integridad de la información.
Muchos pueden considerar que un esfuerzo de pruebas es exitoso porque se han encontrado muchos bugs, sin prestar tanta atención a los tipos de éstos y lo que este número nos dice. Tal vez un equipo logra encontrar en una aplicación cien errores de ortografía, de despliegue de textos o elementos visuales que pueden afectar la interacción con el usuario mientras otro equipo sólo logra encontrar cinco defectos que afectan la integridad de la información de los clientes y la privacidad de los usuarios.
Sin duda, el equipo que provee más valor a la aplicación podría considerarse el segundo ya que si bien se puede hacer un análisis desde una perspectiva en la que los defectos estáticos y de contenido pueden tener demasiada importancia, lo más valioso de las tecnologías de información es –valga la redundancia- la información (o al menos eso considero yo). Un robo o un fallo en toda la información que alimenta o provee un sistema puede anular al mismo.
Un fallo crítico, algo que “truene”, puede generar muchos problemas. Aunque bien, retomando ese comentario que dio pie a este análisis, en ese momento que mencioné el “tronar feo”, la burla ocurrió porque decir que algo “truene” implica que hubo un error grave, que se rompió el software y que no se trata de un simple typo.
Un ejemplo de esto es el conocido error 500 del http (error interno en el servidor) en los sitios web. El error 500 se da cuando ocurre algo inesperado en el servidor y simplemente deja de funcionar. Bajo esta premisa, un mensaje de error interno del servidor quiere decir que ya “tronamos” la aplicación, ya se rompió y no puede seguir funcionado. Al final todo el análisis pudo haber sido más bien un problema con la interpretación.
Sin embargo, considerando que el romper una aplicación ya represente bastante gravedad, creo que puede haber todavía repercusiones más graves atrás de estos errores 500. Que el servidor deje de funcionar sin duda es grave pero, ¿qué pasaría si un defecto no sólo dejara sin funcionamiento al servidor sino que también permitiera a un atacante alguna herramienta para robar y destruir la información? O, ¿qué tal si estuviéramos probando un sistema de defensa antimisiles?
Un error grave podría ser que el sistema deje de funcionar pero uno aun peor es que por ello comenzara a detonar todas las municiones almacenadas, haciendo peor la catástrofe. ¿Qué decir del equipo médico? El infame caso del Therac (máquina de radioterapia conocida en el ámbito de las pruebas de software por haber matado pacientes por un bug) pudo haber “tronado” con alguna falla crítica que detuviera de seco su funcionamiento, dejando al paciente a mitad de la terapia. Sin embargo, pudo fallar de una peor manera al funcionar pero emitiendo muchas veces más la dosis necesaria y así matando personas.
Finalmente, el tester debe probar un software con el objetivo de encontrar defectos críticos para poder evitar que se materialice cualquier riesgo para el usuario final, ya sea en términos de dinero, información o salud. Para esta tarea se tiene que estar preparado para buscar y tener en cuenta las peores consecuencias que puede traer el producto a probar. Un fallo en la autenticación, un error de servidor, intermitencias en la disponibilidad o problemas con la actualización de la información, todos pueden ser errores críticos según el enfoque con el que se analice.
Pero no olvidemos que puede haber peores errores y consecuencias más graves que van más allá de un día sin acceso a tu aplicación bancaria o sin poder revisar Facebook. Hay errores que pueden hacer que una empresa pierda todo su patrimonio o en el peor de los casos, perder vidas humanas. El software puede tronar de muchas maneras, pero sí hay otras en las que puede tronar feo.
