Si estás usando algún programa realizado a medida, desarrollado por una empresa de software, lo normal es que algún error a lo largo del tiempo acabe apareciendo. Debes saber que una de las fases más importantes en el desarrollo de un software es la fase de pruebas.

Esta fase de pruebas se suele realizar con el cliente, para familiarizarse con el aplicativo y empezarlo a usar, detectando posibles errores que los programas de benchmarking (programas de prueba) no han encontrado.

Si a pesar de toda esta fase de pruebas se ha colado algún error, este debe ser comunicado a la empresa que ha desarrollado el software. Aquí te damos una guía de buenos y malos métodos para enviar estos errores.

Normalmente, la empresa de software tendrá un sistema de tickets. ¿Qué es un sistema de tickets?

Un sistema de tickets es un programa que se encarga de registrar todas las incidencias enviadas por clientes, permitiendo asignarles un departamento y una prioridad.

Cuando envías un ticket, este queda registrado en el programa, y una persona se encarga de asignarlo y darle una prioridad, dependiendo del tipo de error. No es lo mismo un error de nomenclatura (un nombre mal puesto en un campo), que un error que haya borrado todas las fotos de una web. Aquí entra el criterio y la experiencia de la persona que asigna los tickets.

Una vez asignado, el departamento lo recibe y lo intenta remediar según su prioridad y tiempo. Cuando está resuelto, se notifica al cliente y se cierra el ticket, donde queda registrado por si en un periodo de tiempo volviera a suceder algo parecido, saber de primera mano qué había pasado.

Un factor importante de tiempo invertido en la solución del error, tiene mucho que ver con el feedback (descripción del error) que aporta el cliente.

Cuando envías un ticket de soporte, no basta con decir "El programa me está fallando", o decir "La galería de fotos falla", ya que esta información no aporta nada al programador. Hay muchísimos tipos diferentes de fallo, y los fallos que se cuelan cuando el programa ha pasado la fase de pruebas, no son tan fáciles de detectar. Además, si añadimos que la sección del programa que dices que falla ha pasado todos los tests y los sigue pasando, hay algo que has introducido que ha hecho fallar al programa.

Por tanto, es interesante indicar qué estabas realizando exactamente cuando el programa a fallado: "Estaba subiendo una foto", "Estaba modificando una foto", "Estaba ordenando las fotos".

Además, debes ser más específico a la hora de identificar en qué pantalla está fallando el programa, si dices "La galería de fotos falla", es demasiado general. Debes decir "la pantalla de inserción de una foto no funciona", por ejemplo.

También debes incluir los síntomas qué has detectado que falla, si por ejemplo, estás ordenando fotos, y ves que una foto no se ha ordenado correctamente, debes incluir qué foto es la que no se ordena, ya que estás dando una información muy valiosa a la empresa desarrolladora.

Todos estos, son pequeños detalles, que a ti te pueden dar pereza escribir, pero es tiempo que ahorras a la empresa desarrolladora, y tiempo que ganas para que el fallo se corrija más rápidamente.