Comencemos poniéndonos de acuerdo en un par de puntos:
- El software falla, porque es hecho por humanos y los humanos fallan (y aunque esté de moda la IA, ésta se basa en el comportamiento de humanos, así que de vuelta a lo mismo).
- El origen de esas fallas puede ser irrelevante, aunque no trivial: un proceso, una (in)definición, una mala programación, una capacitación deficiente, una expectativa equivocada, un mal uso... Hay innumerables razones por las que el software puede fallar, o lo que es lo mismo: no hacer lo que se esperaba que hiciera (aunque eso que se esperaba quizá ni siquiera era lo que se pretendía que hiciera cuando fue creado).
- Si tenemos que vivir con ello, las fallas deberían ser corregidas para mejorar gradualmente el software. No hay nada peor que un software que deja de ser mantenido: las fallas se quedan ahí, y los nuevos usos crecen, y todo se vuelve una maraña de fallos y usos obsoletos.
Así que si los fallos serán inherentes al hecho de crear y usar software, ¿cuál es la mejor manera de lidiar con ellos?
Como programadores, mejorar en nuestras prácticas y técnicas. Incluyendo pensar antes de teclear, diseñar antes de construir. Y probar TODO lo que se pueda probar.
Como diseñadores, mejorar la interacción y la experiencia y el acercamiento que damos al definir un producto para luego llevarlo a quienes lo hacen realidad.
¿Y como usuarios? entender cómo funciona y cómo debe ser usado, pero también mejorar en la forma EN QUE REPORTAMOS LOS FALLOS QUE LLEGAMOS A ENCONTRAR. De eso se trata este artículo, y lo que intentaré es dejar claro qué es lo que hace BUENO un informe de un fallo.
¿Es muy largo el artículo? ¡Lee por lo menos este resumen!
- El primer objetivo de un informe de fallo es permitir que el programador vea el fallo por sí mismo. Si no puedes hacer que el programa falle delante de ellos, dale instrucciones detalladas para que ellos mismos puedan hacer que falle.
- Si esto no surte efecto, y el programador no puede verlo fallar por sí mismo, el segundo objetivo del informe de fallo es describir lo que falló. Describe todo en detalle. Describe lo que viste, y lo que esperabas ver. Toma nota de los mensajes de error, especialmente cuando contengan números o textos crípticos.
- Cuando el software haga algo inesperado, detente. No hagas nada hasta que estés tranquilo, y no hagas nada que creas que es peligroso.
- Los síntomas son más importantes. A pesar de ello, si por todos los medios intentas diagnosticar el problema tú mismo si crees que puedes, hazlo. Pero si lo haces, informa también de los síntomas igualmente.
- Prepárate para proporcionar información extra si el programador la necesita. Si no la necesitasen no preguntarían por ella. No es que estén siendo retorcidos. Ten los números de versión preparados, porque probablemente harán falta.
- Escribe de manera clara. Di lo que quieres decir, y asegúrate de que no se puede malinterpretar.
- Por encima de todo, sé preciso. A los programadores les gusta la precisión, precisamente porque les es útil.
¿Para qué informar de un fallo?
En primer lugar, si lo que tengo en las manos está fallando, ¿qué sentido tiene informar si no funciona como yo esperaba? Al final y al cabo ya tengo un producto en las manos, debería hacer lo que se supone, y que no lo haga solamente me frustra, quizá me enoja, pero sobre todo me vuelve improductivo.
Quedarse cruzado de brazos no debería ser una opción. Contar con que aquellos que fabricaron este producto trabajan "aquí al lado", para la misma empresa, con la misma misión y objetivos, debería ser entonces el principal motivo para levantar la mano.
El objetivo de un informe de fallo es permitir al programador ver el programa fallando ante sus ojos. Puedes mostrárselo en persona, o darle instrucciones cuidadas y detalladas de cómo hacer que falle. Si pueden hacer que falle, podrán intentar recolectar información extra hasta que averigüen la causa. Si no pueden hacer que falle, tendrán que pedirte que tú recolectes esa información en su lugar.
Pero, ¿cómo así? el programador hizo el producto, ¿por qué necesita esto si él lo produjo? Hoy en día crear un producto tecnológico es una labor compleja que no solamente involucra a un programador, ni siquiera a puros programadores, en la mezcla hay diseñadores, diversos tipos de programadores (backends y frontends), administradores, arquitectos, especialistas en infraestructuras, gente especializada en realizar pruebas, y otras en llevar el producto a las fases finales de liberación para llevarlo a tus manos, etc. Ante este escenario, va a ser difícil que CADA programador pueda saber de primera mano lo que está fallando. Puede estar en cualquier lado, incluso en un lugar donde uno o varios programadores ni siquiera metieron la mano. Descubrir dónde, cómo y por qué es el objetivo principal del informe de fallo que tú reportes.
¿Cómo es un buen informe de fallo?
En los informes de fallo, intenta dejar muy claro qué son hechos reales ("Estaba con la computadora y ocurrió esto") y qué son especulaciones ("Creo que esto puede ser el problema"). Excluye las especulaciones si quieres, pero no excluyas nunca los hechos.
Cuando informas de un fallo, lo haces porque quieres que el fallo se arregle. No tiene sentido blasfemar al programador o ser deliberadamente poco útil: puede que sea culpa suya que tú tengas el problema, y puede que tengas razón al estar enfadado con ellos, pero el fallo se arreglará antes si les ayudas proporcionándoles toda la información que necesitan.
"No funciona"
Dale al programador algo de crédito en cuanto a inteligencia: si el programa no funcionase en absoluto, se hubieran dado cuenta. Si no se han dado cuenta, es que en su caso funciona. Por tanto, o bien estás haciendo algo diferente de lo que ellos hacen, o tu entorno es diferente del suyo. Necesitan información; proporcionar esa información es el objetivo de un informe de fallo. Más información casi siempre es mejor que menos.
Incluso si no estás informando de un fallo sino simplemente pidiendo ayuda para utilizar el programa, deberías indicar en qué otros sitios has buscado ya la respuesta a tu pregunta. ("Miré el capítulo 4 y la sección 5.2 de la ayuda en el Centro de Aprendizaje Podemos, pero no encontré nada que me dijera si esto es posible.") Esto permitirá que el programador sepa dónde espera la gente encontrar la respuesta, de forma que pueden hacer que la documentación sea más fácil de usar.
"Muéstrame"
Una de las mejores maneras de informar de un fallo es mostrarlo al programador. Sitúalos delante de tu computadora o dispositivo, lanza su software, y demuestra aquello que funciona mal. Deja que miren cómo arrancas la máquina, que miren cómo ejecutas el software, que miren cómo interactúas con el software y que miren lo que el software realiza como respuesta a tus entradas.
Conocen su software como la palma de su mano. Saben en qué partes confiar, y saben qué partes pueden tener más fallos. Saben intuitivamente lo que tienen que buscar. Cuando el software haya hecho algo obviamente erróneo, puede que hayan reparado en algo anterior sutilmente erróneo que pueda darles una pista. Pueden observar todo lo que la computadora hace durante la ejecución de la prueba, y pueden decidir lo que es importante por sí mismos.
Quizás esto no sea suficiente. Quizás decidan que necesitan más información, y te pidan que les muestres lo mismo una vez más. Puede que te pidan que les guíes en el proceso, de forma que puedan reproducir el fallo por sí mismos todas las veces que sean necesarias. Puede que intenten variar el proceso algunas veces más, y así conocer si el problema ocurre sólo en un caso o en una familia de casos relacionados. Si no tienes suerte, quizás necesiten sentarse durante un par de horas con un conjunto de herramientas de desarrollo y empezar a investigar a fondo. Pero lo más importante es que el programador esté mirando la computadora o dispositivo cuando algo falla. Una vez que puedan ver el problema, normalmente podrán seguir solos a partir de ese punto para intentar arreglarlo.
"Enséñame a mostrar por mí mismo"
Ésta es la era de Internet. Es la era en la que puedes instalar el software aún viviendo al otro lado de la ciudad pulsando un botón, y tu puedes enviarme tus comentarios de forma igualmente sencilla. Pero si tienes un problema con mi programa, no puedes hacer que yo esté presente cuando falla. "Muéstrame" es bueno cuando puedes, pero muchas veces no puedes.
Si tienes que informar de un fallo a un programador que no puede estar presente personalmente, el objetivo del ejercicio es hacer que sean capaces de reproducir el problema. Quieres que el programador ejecute su propia copia del programa, haga lo mismo que tú, y haga que falle de la misma manera. Cuando no pueden ver que el problema ocurre delante de sus ojos, no pueden hacer nada con él.
Así que diles exactamente lo que hiciste. Si es una plataforma web como LUCI, diles qué botones pulsaste y en qué orden los pulsaste. Si es un software en un dispositivo móvil como SPORE, múestrales de forma precisa la información que introdujiste y los botones que pulsaste. Cuando sea posible, debes proporcionar una transcripción de la sesión, describiendo la información que introdujiste y lo que el software mostró como respuesta. Los videos también son útiles, asegúrate de incluir todo el proceso hasta detonar el error, y si incluye como audio una narración en vivo de lo que estás haciendo podría ser útil también.
Dale al programador toda la información que se te ocurra. Si el programa lee de un archivo, probablemente necesites enviarles una copia del archivo. Si el programa usa un navegador web probablemente no puedas enviarles una copia de tu navegador, pero puedes al menos decir qué clase de navegador es, sobre qué sistema operativo lo ejecutas, y qué versión del navegador usas.
"A mí me funciona. ¿Qué está mal?"
Si le das a un programador una larga lista de entradas y acciones y ellos lanzan su propia copia del programa y no ocurre nada malo, entonces es que no les has dado información suficiente (pero no es tu culpa, esto es sólo tema de afinar la comunicación, el programador te pedirá más información, tú proporciónala). Posiblemente el fallo no ocurre en todos los navegadores; tu sistema y su sistema puede diferir de algún modo. Quizás hayas malentendido lo que el programa supuestamente hace, y ambos están mirando exactamente la misma pantalla y tú piensas que está mal y ellos que está bien.
Así que describe también lo que ocurrió. Diles exactamente lo que viste. Diles por qué piensas que lo que viste está mal; aún mejor, diles exactamente lo que tú esperabas ver. Si dices "y entonces falló", estás dejando fuera información muy importante.
Si viste mensajes de error entonces dile al programador, de forma clara y precisa, cuáles eran. ¡Son importantes! En este momento, el programador no está intentando arreglar el problema: sólo están intentando encontrarlo. Necesitan saber qué ha ido mal, y esos mensajes de error son el mayor esfuerzo del software para decírtelo. Anota los errores si no tienes otra forma más sencilla de recordarlos, pero no merece la pena informar de que el programa generó un error a menos que puedas indicar cuál era el mensaje de error.
En particular, si el mensaje de error contiene números o textos que no entiendas porque parecen escritos en un lenguaje de marcianos, asegúrate de informar de ellos al programador. Aunque tú no puedas encontrarles sentido no significa que no lo tengan. Los números y esos textos raros contienen toda clase de información que puede ser leída por un programador, y probablemente contengan pistas vitales.
Los números en los mensajes de error están ahí porque el software está demasiado confundido como para informar del fallo con palabras, pero está intentando hacerlo lo mejor posible para darte la información importante. Por ello, no solamente hagas captura de pantalla del mensaje extraño, si la captura no abarca TODO el mensaje, podría ser inútil informarlo. Copia y pega todo el texto si hace falta.
En este punto, el programador está a efectos prácticos realizando el trabajo de un detective. No saben lo que ha ocurrido, y no pueden estar lo bastante cerca como para verlo por ellos mismos, así que están intentando encontrar pistas que les hagan ver el problema. Los mensajes de error, las incomprensibles cadenas de números y los textos extraños, e incluso los retardos inesperados son todos tan importantes como las huellas dactilares en la escena de un crimen. ¡Guárdalos!
¡OJO! Ten en cuenta que la información que proporciones puede contener un registro del estado completo del programa: cualquier "secreto" presente (quizás el programa estuviera manejando un mensaje personal, o trabajando con datos confidenciales) puede aparecer en la información. Procura ocultar o enmascarar con asteriscos o editando la imagen en esos casos.
"Y entonces intenté..."
Hay un montón de cosas que puedes hacer cuando aparece un fallo o un error. Muchas de esas cosas empeoran el problema. Una amiga mía en la escuela borró accidentalmente todos sus documentos de Word, y antes de pedir ayuda a un experto intentó reinstalar el Word y luego ejecutar el desfragmentador de disco. Ninguna de esas acciones ayudó a recuperar sus archivos, y gracias a ambas el disco se dispersó de tal manera que ningún programa de recuperación hubiese podido hacer nada. Si no hubiese tocado nada, puede que hubiera tenido una oportunidad.
Usuarios como éste son como una suricata atrapada en una esquina: con su espalda contra la pared y viendo la muerte inminente ante sus ojos, ataca salvajemente, porque "hacer algo tiene que ser mejor que no hacer nada", ¿no?. Esto no se adapta bien al tipo de problemas que produce el software.
En lugar de ser una suricata, sé un antílope. Cuando un antílope se enfrenta a algo inesperado o terrorífico, se detiene. Permanece completamente detenido e intenta no atraer la atención, mientras se pone a pensar y calcular qué es lo mejor que puede hacer. (Si los antílopes tuvieran una línea de soporte técnico, probablemente llamarían a ella en ese momento.) Entonces, una vez que ha decidido qué es lo más seguro que puede hacer, lo hace.
Cuando algo va mal, inmediatamente deja de hacer nada. No toques ningún botón en absoluto. Mira la pantalla e intenta encontrar cosas fuera de lo normal, y recuérdalo o anótalo. Entonces quizás empieza cautelosamente a pulsar "Aceptar" o "Cancelar", lo que te parezca más seguro. Intenta desarrollar un reflejo - si el software hace algo inesperado, detente.
Si logras salir del problema, bien cerrando el programa afectado o bien reiniciando la computadora, sería bueno intentar hacer que el problema ocurra de nuevo. A los programadores les alegran los problemas que pueden reproducir más de una vez. Y los programadores alegres arreglan los fallos antes y de forma más eficiente.
"Creo que el modulador de taquiones tiene la polarización incorrecta"
No sólo son los no-programadores los que producen malos informes de fallos. Algunos de los peores informes de fallos que he visto vienen de programadores, e incluso de buenos programadores.
Una vez trabajé con otro programador que no paraba de encontrar fallos en su código e intentaba arreglarlos. De vez en cuando encontraba un fallo que no era capaz de arreglar, y me llamaba para que le ayudase. "¿Qué ha pasado?", le preguntaba. Él me respondía diciéndome su opinión sobre lo que necesitaba repararse.
Esto funcionaba bien cuando su opinión era correcta. Significaba que ya había hecho la mitad del trabajo y así podíamos terminarlo los dos juntos. Era eficiente y útil.
Sin embargo, la mayoría de las veces se equivocaba. Trabajábamos un tiempo intentando averiguar por qué una cierta parte del programa producía datos incorrectos, y eventualmente descubríamos que no los producía, y que habíamos estado media hora o más investigando un trozo de código que funcionaba perfectamente, y que el problema estaba en otra parte.
Estoy seguro de que tú no harías eso con un doctor. "Doctor, necesito que me prescriba hidroyoyodina." La gente sabe que no debe hacer eso con un doctor: le describes los síntomas, las molestias y achaques y dolores y erupciones y fiebres, y dejas que el doctor haga el diagnóstico del problema y decida qué hacer al respecto. En otro caso el doctor te tomará por hipocondriaco y lunático, y con razón.
Ocurre lo mismo con los programadores. Proporcionar tu propio diagnóstico puede que a veces sea útil, pero siempre establece los síntomas. El diagnóstico es un extra opcional, y no una alternativa a describir los síntomas.
Si un programador te pide información extra, ¡no te la inventes! Una vez alguien me informó de un fallo, y le pedí que ejecutara una cierta acción que yo sabía que fallaría. Le pedí que lo probase porque quería saber cuál de dos errores posibles surgiría. Conocer cuál era una pista vital. Pero no lo intentó - sino que me respondió diciendo "No, eso no funciona". Sabiendo que no lo había ni intentado, me llevó un tiempo persuadirle de que lo intentara de verdad.
Usar tu inteligencia para ayudar al programador está bien. Incluso si tus deducciones son incorrectas, el programador debería estar agradecido de que al menos hayas intentado hacerle la vida más fácil. Pero informa de los síntomas también, o quizás se la compliques.
"Vaya, lo hacía hace un momento"
Dile "fallo intermitente" a un programador y fíjate la cara que ponen. Los problemas fáciles son aquellos en los que la realización de una secuencia simple de acciones hacen que surja el problema. El programador puede repetir esa secuencia de acciones en un entorno de pruebas cerrado y observable y ver lo que ocurre con gran detalle. Demasiados problemas no funcionan así: habrá programas que fallarán una vez a la semana, o una vez cada mucho tiempo, o nunca fallarán cuando los pruebes delante del programador pero sí cuando la fecha de cierre de mes está a la vuelta de la esquina.
La mayoría de los fallos intermitentes no son verdaderamente intermitentes. La mayoría de ellos tienen alguna lógica en alguna parte. Algunos pueden ocurrir cuando el dispositivo se está quedando sin memoria, otros pueden ocurrir cuando otro programa intenta modificar un archivo crítico en el momento equivocado, y algunos pueden ocurrir ¡sólo en la primera media hora de cada hora! (Una vez vi uno de éstos). El chiste aquí es hallar ese patrón.
También, si puedes reproducir el fallo pero el programador no puede, podría ser porque tu computadora o dispositivo y su computadora o dispositivo son diferentes en algo y ese algo es lo que provoca el fallo. Una vez tuve un pantalla cuyo contenido se enrollaba en una pequeña bola en la esquina del navegador, se quedaba ahí y se enfurruñaba. Pero sólo hacía eso en pantallas de 800x600; en mi pantalla de 1024x768 estaba bien.
Para dilucidar el patrón y deshacer la posiblemente aparente "intermitencia" del problema, el programador querrá saber todo lo que puedas contarle del problema. Pruébalo en otra máquina o dispositivo, quizás. Pruébalo dos o tres veces y mira la frecuencia con la que falla. Si falla cuando estás trabajando en algo serio pero no cuando estás intentando demostrarlo, puede que sean los tiempos grandes de ejecución o archivos grandes los que lo hagan fallar. Intenta recordar todos los detalles que puedas acerca de lo que estabas haciendo cuando el programa falló, y si encontraste algún tipo de patrón, menciónalo. Cualquier información que puedas proporcionar será útil. Incluso si es sólo probabilística (como "falla con más frecuencia si tengo mensajes pendientes de WhatsApp"), puede que no proporcione pistas directas acerca de la causa del problema, pero puede que ayude al programador a la hora de reproducirlo.
Más importante, el programador querrá estar seguro de si es un auténtico fallo intermitente o un fallo específico de esa máquina o dispositivo. Querrán conocer un montón de detalles acerca de tu computadora, para intentar saber cómo difiere de la suya. Muchos de esos detalles dependerán del programa en particular, pero algo que deberías estar listo para proporcionar son los números de versión. El número de versión del propio programa, el número de versión del navegador si es que el software se ejecuta vía web, el número de versión del sistema operativo, y probablemente de cualquier otro programa que intervenga en el problema.
"Entonces Mambu no decía lo mismo que SPORE..."
Escribir de forma clara es esencial en un informe de fallo. Si el programador no puede entenderte, quizás sea mejor no decir nada.
Recibo informes de fallos de muchas personas en toda la empresa. Muchos de ellos de personas que no tienen nivel técnico en términos de tecnología, y muchos de esos se disculpan por su pobre nivel técnico. En general, los informes con disculpas por el pobre nivel técnico que manejan son en realidad muy claros y útiles. La mayoría de informes confusos provienen de programadores y personas que uno esperaría sabrían expresarse técnicamente, y que suponen que les entenderé aunque no hagan ningún esfuerzo por ser claros o precisos.
- Sé específico. Si puedes hacer lo mismo de dos maneras, di cuál usaste. "Seleccioné Cargar" puede significar "Pulsé sobre Cargar" o "Pulsé Alt+L". Di cuál usaste. A veces importa.
- Sé prolijo. Da más información en lugar de menos. Si dices muchas cosas, el programador puede ignorar parte de ellas. Si dices pocas, tienen que hacerte más preguntas. Una vez recibí un informe de fallo de una sola frase; cada vez que preguntaba más información, el informador respondía con otra frase suelta. Me llevó varias semanas obtener un volumen de información útil, porque respondía con una frase corta cada vez.
- Si anexas una imagen que contiene datos esenciales de tu informe de fallo, por ejemplo un ID de cuenta o cliente o grupo, un monto, etc., lo que sea que tenga que ver con el fallo. Además de incluirlo en la imagen, inclúyelo como texto en tu informe. ¿Para qué si ya está en la imagen? Considera que el programador seguramente al intentar replicar el escenario del fallo va a tener que introducir esa misma información, exactamente la misma. Podría transcribir la información desde tu imagen. Y por lo tanto podría equivocarse al copiar y teclear, y llegar a conclusiones equivocadas en sus pruebas, sin fijarse que sólo omitió un cero, o un guión. En cambio en texto, lo puede copiar y pegar sin ningún problema usando el portapapeles de su sistema.
- Ten cuidado con los pronombres y los verbos sin sujeto. No uses referencias como "la ventana", cuando no está claro lo que significa. Considera el siguiente ejemplo: "Lancé la AplicaciónCualquiera. Apareció una ventana con una advertencia. Intenté cerrarla y tronó." No está claro lo que el usuario intentó cerrar. ¿Intentó cerrar la ventana de advertencia o la ventana de AplicaciónCualquiera? Hay una diferencia. En lugar de eso, podrías decir "Lancé la AplicaciónCualquiera, la cual mostró una ventana de advertencia. Intenté cerrar la ventana de advertencia y AplicaciónCualquiera tronó." Esto es más largo y repetitivo, pero es más claro y más difícil de malinterpretar.
- Lee lo que has escrito. Léete el informe a ti mismo e intenta ver si tú crees que es claro. Si listas una secuencia de acciones a realizar para provocar el fallo, intenta seguirlas tú mismo para comprobar si has omitido algún paso.
¡Y listo!
Espero que con esta lectura, saber qué y cómo informar de mejor manera de los fallos que encuentres en un software, nos ayude a todos: a tí primero que nada, y al programador con quien contactes, para que los fallos se resuelvan de manera efectiva :-)
Advertencia: nunca he visto en realidad una suricata o un antílope. Mi zoología puede ser inexacta.
(basado en https://www.chiark.greenend.org.uk/~sgtatham/bugs-es.html)