language-agnostic bug-reporting

language agnostic - Cómo informar errores de forma inteligente



language-agnostic bug-reporting (8)

Escribe los pasos para reproducir el error. Si no puedes reproducirlo, no se arreglará.

Quiero escribir (o encontrar) una guía para informes de errores efectivos en un estilo similar al de ESR How To Ask Questions The Smart Way

¿Cuáles son sus mejores consejos para informes de errores efectivos?

Informe los hechos observables y luego su interpretación de esos hechos.

A veces, los mejores informes de errores incluyen algo que es una sensación instintiva de comprensión del problema. El informe de fallas solo de hechos descuenta este valioso recurso humano.

Para todas las personas que no mirarán algo sin pasos para reproducirse:
Mi primer trabajo cooperativo de programación me asignaron un error que era esencialmente una condición de carrera aleatoria que estaba volviendo el sistema inestable. Ocurrió en cualquier punto de la ejecución del sistema, y ​​todo lo que teníamos eran algunos rastros de pila que apuntaban a una sección de código que obviamente estaba bien. En algún lugar, otro hilo se estaba volcando con datos que no debería ser, y si este hilo estaba en el punto correcto, se bloqueará. Nuestro control de calidad tiene fallas una vez al mes. Pasaron dos semanas de analizar el sistema para encontrar al culpable (por ejemplo, acceso sin marcar a los recursos compartidos, una corrección de 2 líneas) y solucionarlo. Nunca hubo pasos decentes para reproducirse porque no había una forma general de reproducirlo (excepto empujando un montón de rendimiento () en el lugar correcto). Si vas a trabajar en un sistema multiproceso, es mejor que estés preparado para lidiar con errores que no se pueden reproducir de manera confiable, puede que no tengan pasos estables para reproducirse y no solo quejarse a QA porque no puedes reproducir el error .

Tenga en cuenta que lo anterior no es excusa para que el control de calidad no incluya tantos detalles como sea posible cuando sea posible, simplemente señalando que no siempre es posible en un software moderno.

No suponga que el lector de su informe de errores conoce el software tan bien como usted . Incluso la persona que escribió el software puede no saber de qué está hablando si ha pasado suficiente tiempo desde que lo escribieron. Escríbalo para que cualquiera pueda entender y reproducir el problema.

  • Instrucciones paso a paso sobre cómo recrear el error
  • Asegúrese de haber intentado aislar el error de lo que realmente está escribiendo un error, en lugar de algo que podría ser la causa.
  • Lista intenta aislar el error a algo que no sea el software contra el que está escribiendo un error
  • Póngase a su disposición para responder preguntas y estar disponible para ayudar a solucionar / recrear el error

El resultado final es que tienes que involucrar un cierto nivel de pensamiento crítico cuando se encuentra el error. Una vez que haya agotado todas las posibilidades de que pueda ser su culpa, escriba un error. Si descubres que es tu culpa, pero el software que estás utilizando / probando podría haber hecho algo más útil para indicar que es tu culpa, sigue escribiendo un error.

Además, para ser un gran reportero de errores, debe hacer uso de aquellos que prueban el error para ayudarlos a recrearlo. Es probable que hayas "adquirido la habilidad" de recrear ese error y que haya pasos de los que no eres consciente. No puede simplemente quejarse y alejarse, participar en el proceso y ayudar al equipo mediante pruebas, recreación y solución de problemas.

  • Procedimiento utilizado para volver a crear el error, incluyendo lo que se estaba haciendo, qué área de la aplicación se estaba utilizando y qué evento estaba sucediendo en ese momento.
  • Declaración de reproducibilidad (confiablemente, no): ayuda al desarrollador a saber qué tan difícil debe ser reproducir para que no se rindan rápidamente
  • Capturas de pantalla o documentación del mensaje de error / seguimiento de pila producido
  • Criticidad / Prioridad del error (puede evitarse, pasos de evasión, es catastrófico, tiene un impacto comercial, cuál es el riesgo comercial, etc.)
  • Medio ambiente: en qué entorno se encontró el error. Remoto, local, etc.

Con demasiada frecuencia, nuestra gente de control de calidad cree que pueden poner un ticket diciendo: esta es mi excepción sin ninguna documentación de respaldo. Es casi imposible de reproducir, mucho menos solucionar el problema sin más información.

  • Siempre informe el número de versión del software bajo prueba
  • Siempre informe las versiones de cualquier otro software (navegador, sistema operativo, etc.)
  • Siempre liste todo el hardware
  • pasos para reproducir
  • Síntomas de error
  • Capturas de pantalla, rastros, registros, otros archivos adjuntos (si los hay)
  • Qué tan crítico es el bloqueo, la IU, etc.
  • Informar si reproducible
  • Cualquier otra cosa intentada, que haya reproducido o no el error