¿Qué hacer con los errores que no repiten?

Tengo un probador que durante las pruebas tendrá un error (hasta ahora bien), pero luego lo informa de inmediato. Nosotros (los desarrolladores) luego descubrimos que el probador no ha intentado reproducir el problema y (cuando se le preguntó) no puede encontrar una manera de que vuelva a suceder.

Ahora que todavía son errores, no quiero ignorarlos. Pero sin pasos de reprobación estoy un poco atascado. A veces hay un seguimiento de la pila (aunque a menudo no es útil porque es un marco compacto y no hay números de línea). Pero cuando hay uno, puedo tomar el rastro de la pila y abrir el código y comenzar a adivinar, pero eso no conduce a "correcciones" comprobables.

¿Qué haces en escenarios como este?

Un error sin contexto no es un error, es una casualidad. El problema podría ser su código, podría ser una biblioteca de terceros, podría ser el hardware o podría ser la radiación solar causando que un solo bit se voltee por sí mismo. Si no puede reproducirlo con al menos algo de regularidad (incluso si solo "sucede una vez cada 10 o 20 veces que hago X"), no es mucho mejor que su probador le diga "Algo en algún lugar salió mal de alguna manera, corríjalo" .

Es posible que deba explicarle a su evaluador que su trabajo no es solo generar información hasta que algo se rompa. Si lo fuera, podría reemplazarlo con un generador de números aleatorios. Parte de su trabajo es identificar errores, lo que implica identificar cómo producirlos.

Finalmente, si ni el desarrollador ni el probador pueden reproducir el error, debe cerrarse pero marcarse como tal.

Sin embargo, cuánto tiempo le lleva llegar a ese punto es discutible.

Algunas personas argumentan que si no es reproducible inmediatamente, entonces debería cerrarse de inmediato.

Por lo general, me esfuerzo por tratar de obtener más información del creador del problema. Puede haber algo que olvidaron en el informe original. Tener una conversación sobre los pasos necesarios a menudo puede revelar la información que falta.

Un pensamiento final: cerrado como "no repro" no significa fijo. Si hay un problema real, se revelará tarde o temprano y contar con toda la información que pueda ayudará cuando finalmente pueda reproducir el problema.

Algunas sugerencias más:

1. Agregue el registro (y no solo un keylogger:}) a su código de producto. Los errores "no repro" pueden ser casualidades, pero pueden ser daños en la memoria o el estado que solo se producen en un sistema sucio utilizado de manera no anticipada (es decir, como la computadora de un cliente). La información de registro o rastreo puede ayudarlo a descubrir qué pudo haber estado mal cuando el probador encontró la casualidad.

2. Escanee el resto de los errores "no repro" en la base de datos (o lo que sea que use para el seguimiento de errores). A menudo, los trematodos se agrupan en un área del producto. Si parece que un componente tiene la culpa, revise el código del componente para detectar posibles fallas, agregue un registro adicional a ese componente, o ambos.

3. Tómese media hora más o menos y observe su prueba de prueba. Su enfoque puede darle una idea de lo que salió mal (por ejemplo, "interesante, no sabía que podría llegar a ese diálogo de esa manera"). También es posible que omitan un diálogo o paso de configuración sin querer. Vale la pena invertir tiempo en meterse un poco en la cabeza.

Hago QA en un código comercial grande, este escenario irritante aparece con demasiada frecuencia. Por lo general, es indicativo de no tener procedimientos de ironclad para construir el binario en todas las plataformas que admitimos. Entonces, si el desarrollador construye su propio código (que tiene que hacer para depurar y corregir), y no sigue el mismo procedimiento de compilación al pie de la letra, existe la posibilidad de que los errores dependientes del sistema aparezcan mágicamente (o aparezcan) . Por supuesto, estas cosas generalmente se cierran con "funciona para mí" en la base de datos de errores, y si fallan la próxima vez que se ejecute ese problema, el error se puede volver a abrir. Siempre que sospecho que un error puede depender del sistema, trato de probarlo en una variedad de plataformas e informar en qué condiciones ocurre. A menudo aparece un problema de corrupción de memoria si los datos dañados son de una magnitud lo suficientemente grande como para causar un bloqueo. Algunas plataformas (combinaciones de hardware y sistema operativo) pueden bloquearse más cerca de la fuente real de la corrupción, y esto puede ser muy valioso para el pobre que tiene que depurarlo.

El probador necesita hacer algo de valor agregado, más allá de solo informar que su sistema muestra una falla. Paso mucho tiempo descartando falsos positivos, tal vez la plataforma en cuestión estaba sobrecargada o la red tenía un problema técnico. Y sí, a veces puede obtener algo que realmente se ve afectado por eventos de sincronización aleatorios, los errores de hardware a menudo pueden ser como ejemplo: si dos solicitudes de datos vuelven exactamente el mismo período de reloj, y la lógica del hardware para manejar el conflicto potencial es defectuosa, entonces el error solo se mostrará de forma intermitente. Del mismo modo con el procesamiento paralelo, a menos que mediante un diseño cuidadoso haya restringido la solución para que sea independiente de qué procesador sea más rápido, puede obtener errores que solo ocurren una vez en una luna azul, y su imporbabilidad estadística hace que la depuración sea una pesadilla.

Además, nuestro código se actualiza, generalmente muchas veces al día, rastrear un número de revisión de código fuente exacto para cuando se fue al sur puede ser información muy útil para el esfuerzo de depuración. El probador no debería estar en una relación de confrontación con los depuradores y desarrolladores, él está allí como parte de un equipo para mejorar la calidad del producto.

Hay dos tipos de errores que no son reproducibles:

1) Los que un probador (o usuario) ha visto una vez pero no ha podido o no ha intentado reproducir.

En estas situaciones debes:

• Verifique brevemente el curso básico de acciones que mostraron el defecto para asegurarse de que no sea reproducible.

• Hable con el probador / usuario para ver si hay alguna otra información que pueda ayudar.

• Haga una referencia cruzada con cualquier otro defecto que pueda estar relacionado para ver si tiene suficiente información para investigar en función de varias instancias. Es posible que este único problema no le brinde suficiente información para continuar; sin embargo, cuando se combina con otros problemas, puede sugerirle algo que no está bien y que vale la pena investigar.

• Si aún no tiene suficiente para continuar, debe explicarle al usuario / evaluador que no tiene suficiente información. Explíqueles cortésmente cómo sería la información suficiente y por qué es necesaria.

2) Aquellos donde no pueden reproducirse de manera confiable, sin embargo, hay suficiente evidencia (en términos de ocurrencias repetidas) para sugerir que el defecto existe, entonces tiendo a ver que estos son problemas del desarrollador y que el desarrollador, respaldado por el probador / usuario: necesita investigar.

Es probable que esto sea lento y doloroso, es probable que tenga que recorrer el código, agregar más registros, mirar los datos y hablar con los probadores / usuarios en profundidad, pero si hay suficiente evidencia para sugerir que es probable que exista es un problema que necesita tomar posesión de él y hacer lo que sea necesario para solucionarlo.

Parece que esto sucede con relativa frecuencia, lo que me hace preguntarme, ¿es porque la mayoría de los errores son realmente difíciles de reprobar, o es por alguna otra razón que no está intentando? ¿Sabes por qué no está tratando de reproducir el problema? ¿Es porque no se da cuenta de lo importante que es para ti? ¿O tal vez tiene otras presiones: un administrador de pruebas que solo quiere que supere las pruebas asignadas rápidamente y arroje los errores al muro, por ejemplo? ¿O tal vez simplemente no está seguro de cómo hacerlo?

Estoy de acuerdo con otros en que trabajar en un mejor registro es una prioridad. Mientras tanto, si sospecha que la falta de habilidad / confianza del probador puede ser un problema, entonces realmente me gusta este artículo de Danny Faught sobre el aislamiento de errores , podría señalarlo para empezar.

Si el problema se debe a la presión de la administración, tiene mis condolencias, ya que es difícil de resolver, especialmente si los probadores y programadores informan a diferentes gerentes y los gerentes no están dispuestos a "ayudar" a otro equipo.

Por lo general, noto que no es reproducible, pero lo dejo abierto hasta que se complete ese lote de pruebas o iteración.

Si no se ha reproducido en ese punto, está cerrado, pero se puede volver a abrir si se vuelve a encontrar.

¡pegue un keylogger en la estación de trabajo de este probador!

Bueno, la primera tarea es tener un sistema de prueba reproducible. Su probador debe tener un proceso bien definido, automático si es posible.

Tener estas tres condiciones:

• Mismo binario
• Mismos pasos
• La misma máquina

Si el error aparece esporádicamente con las 3 condiciones anteriores, comience a aislarse más. Considere cada nivel de la pila del sistema y su configuración.

Una forma de detectar errores de administración de memoria es ejecutar el programa en múltiples sistemas operativos con múltiples compiladores. Valgrind también puede ayudar.

Sin embargo, típicamente los sistemas paralelos pueden inducir errores no reproductivos. Cosas como tamaños de búfer y velocidades de procesamiento, asincronización, bloqueos de bases de datos, entrelazados de escritura de memoria variable; todo eso puede generar problemas. Y así sucesivamente.

En primer lugar, debe tener un procedimiento de prueba riguroso (pero entiendo que, en mi empresa, lo que ha descrito sucede con frecuencia).

Dependiendo de la gravedad del error, puede invertir algo de tiempo en él o (mejor) ignorarlo hasta que se proporcionen los pasos de repro.