Después de haber arreglado más o menos 1000 bugs en mi carrera como programador (de los que más o menos 700 los había cometido yo), creo que tengo una visión más o menos sencilla de como deberíamos escribir un ticket para que ayudemos lo máximo posible al programador de soporte. Así esa persona no tendrá que devanarse los sesos en entender que es lo que parece está ocurriendo
Ejemplos como los siguientes son de lo más comunes cuando estamos haciendo soporte de usuarios:
– El formulario está fallando
– ¿Qué formulario? ¿Cuál es la URL?¿Qué es más o menos lo que falla?¿Qué estabas haciendo, cuéntame los pasos? ¿Con qué navegador?¿Puedes pasarme una captura de pantalla?…
– El informe que me descargo está en mal
– ¿Qué formulario? ¿Cuál es la URL?¿Qué es más o menos lo que falla?¿Qué estabas haciendo, cuéntame los pasos? ¿Con qué navegador?¿Puedes pasarme una captura de pantalla?…
La primera pregunta que tenemos que hacernos ante un problema así es: ¿Cuál es el comportamiento normal? ¿Que hacía eso que “parece” que está fallando? ¿Tenemos un sitio para trackear las subidas y ver si se hemos subido algo últimamente?
Antes de ir al código lo mejor que podemos hacer es recopilar toda la información posible, no será la primera vez que un bug se convierte en una feature encubierta. Me explico, quizás ese comportamiento anómalo ya fue reportado anteriormente y está en “pila de cosas por hacer”, quizás fué asumido como un comportamiento normal en aquel momento o en el peor de los casos se justificó haciendo uso de “pareto”. Por lo que tener toda la información posible es lo mejor que podemos hacer antes de tirarnos a la piscina de código y al debugueo.
De la misma forma cuando en un ticket leemos algo como: “no es normal”, “no OK”, “está fatal”… esos comentarios están añadiendo un juicio personal, así que tenemos que intentar leer “entrelineas”, y haciendo sacando toda la información posible del contexto: quien es la persona que escribe el ticket, que muestra la captura de pantalla,… por lo que hay que leer con atención. Y un tip para cuando nosotros escribamos tickets es que a nadie le gusta leer comentarios con juicios de valor, por lo que es mejor intentar escribir los tickets en un lenguaje lo más neutral posible.
Máxima información posible
Cuando nos llega un ticket indicando que un formulario está mal, empezamos a probar, primero con un navegador, luego con otro, con un usuario con sesión, con un usuario anónimo, más adelante limpiamos caché,… para finalmente acabar preguntando al usuario que puso el ticket, ¿puedes enseñarme lo que está fallando? y que te des cuenta de que el formulario/informe que estabas probando no es ni por asomo lo que el usuario estaba haciendo, sino que es otro totalmente opuesto.
Por esta razón, cuando estamos desarrollando es necesario añadir en el logger información valiosa. Y no solo eso, tenemos que pensar que ese error lo leeremos nosotros en un futuro, por lo que lo mejor es ayudar a nuestro “yo del futuro”. Del mismo modo, el usuario debe conocer que es lo que está pasando en un lenguaje cercano y claro, nada de an error occurred. Al final se trata de tener un poco de sentido común. Ni loggear información a “cholón”,ni ser quedarse corto, al final la idea que yo siempre tengo en mente es; “esto ayudará a mi yo del futuro”, así intentaremos llegar a un termino medio. Ese termino medio es complicado, es necesario mostrar un mensaje lo suficientemente claro al usuario y del mismo modo que nos proporcione a nosotros como desarrolladores información suficiente para ver lo que ha pasado, o al menos saber por donde empezar a buscar.
¿Qué podemos hacer nosotros como desarrolladores?
Entonces, ¿qué podemos hacer los desarrolladores? ¿Rendirse? No. Resistir. Cada vez que recibamos un ticket con un error que no está bien escrito, lo ideal es contestar pidiendo más información, capturas de pantalla y todo lo que creamos necesario para intentar reproducir el error. ¿No puede reproducir el problema? Lo hemos intentado con ganas, no perdamos el tiempo, pidamos los pasos que el usuario realizó para para reproducir. No nos volvamos locos y pidamos más información.
Del mismo modo, cuando pedimos más información vamos a ser capaces de conocer la prioridad del ticket, es decir, si un usuario escribe un ticket y cuando le pedimos información no contesta, volvemos a perdirle información y sigues a la espera,… podemos intuir que ese ticket no tenía tanta prioridad.
Conclusiones
Si buscamos en Internet sobre como escribir “bug reports”, seguramente encontraremos miles de listas sobre como escribir buenos tickets, aquí va mi pequeña lista basada en “mi sentido común”:
– Título: Debe ser simple conciso y describir el bug, nada de “todo mal, error, urgente…”
– Pasos para reproducirlo: Este nos haría la vida mucho más sencilla a los desarrolladores, aunque es el más «molesto/difícil» de escribir. Una bueno estructura podría ser “Estando en la página XXX,… Cuando pulso/hago XXX… Entonces ocurre XXX”
– Resultados esperados: ¿Qué resultados esperaba y por qué? ¿Hay una historia de usuario, ticket o cualquier otro documento que pueda sernos útil?
– Resultados reales: ¿Qué resultados obtuvo? ¿Qué es lo que está pasando?
– Navegador: ¿Qué navegador estaba usando?¿Qué dispositivo?¿Movil/tablet/desktop?
– Screenshots: Una captura de la ventana completa ayuda muchísimo, porque da al desarrollador muchísima información: La URL, el navegador,… Y Si además se incluyen flechas para remarcar información entonces genial.
– Información adicional: Cualquier otra información que pudiera ser útil.
Del mismo modo, si no pudieses incluir esta plantilla, las preguntas que intentaría hacer son:
- – ¿Cuál es la URL?
- – ¿Puedes pasarme una captura de pantalla?
- – ¿Qué estabas haciendo, cuéntame los pasos? ¿Con qué navegador?
- – ¿Qué es más o menos lo que falla?
Jesús L.C. - Apuntes de un aprendiz 