Cómo informar fallos de software de forma efectiva

Cómo informar de fallos de forma efectiva
por Simon Tatham, programador profesional y de software libre [ English | Português | 简体中文 | Česky | Dansk | Deutsch | Español | Français | Magyar | Italiano | Nederlands | Polski | Русский | 繁體中文 ]

Introducción Cualquiera que haya escrito software para uso público probablemente haya recibido al menos un mal informe de fallo. Informes que no dicennada ("¡No funciona!"); informes que no tienen sentido; informes que no dan información suficiente; informes que dan información errónea. Informes de problemas que acaban siendo un error del usuario; informes de problemas que acaban siendo un fallo del programa de un tercero; informes de problemas que acaban siendo fallos en la red. Existe una razón por la cual el soporte técnico se ve como un empleohorrible, y esa razón son los malos informes de fallo. Sin embargo, no todos los informes de fallo son molestos: yo mantengo software libre, cuando no me estoy ganando la vida, y a veces recibo informes de fallos increíblemente claros, útiles e informativos. En este ensayo intentaré dejar claro lo que hace bueno a un informe de fallo. Idealmente me gustaría que todo el mundo se leyera este ensayoantes de informar de un fallo a cualquiera. Ciertamente, me gustaría que todos los que vayan a informarme de fallos a mí se lo leyesen. En pocas palabras, 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 intentarrecolectar 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. 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 excluyasnunca 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 inú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. Recuerda también que si elprograma es gratuito, entonces el autor lo proporciona amablemente, de modo que si mucha gente fuera ruda con ellos quizás deban dejar de sentirse amables. "No funciona." Dale al programador algo de crédito en cuanto a inteligencia básica: 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 algodiferente 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. Muchos programas, particularmente programas gratuitos, publican una lista de fallos conocidos. Si puedes encontrar una lista de fallos conocidos, merece la pena leerla para ver si el falloque acabas de encontrar ya es conocido o no. Si lo es, probablemente no merezca la pena informar de él nuevamente, pero si piensas que tienes más información que la que aparece en el informe de fallo, puede que quieras contactar con el programador de todos modos. Puede que sean capaces de arreglar el fallo más fácilmente si les das información que todavía no tenían. Este ensayo está lleno deconsejos. Ninguno de ellos es una regla absoluta. Programadores concretos tienen formas concretas en las que les gusta que se les informe de fallos. Si el programa viene con su propio conjunto de consejos para informar de fallos, léelos. Si los consejos que vienen con el programa contradicen los consejos presentes en este ensayo, ¡sigue los que vienen con el programa! Si no estás informando de un fallo...