tester - testing de software

¿Deberíamos reproducir siempre los errores para verificar las correcciones? (23)

¡Trata de despedir a tu gerente por su estupidez y consigue su trabajo, podría ser una oportunidad!

De vez en cuando obtenemos errores en la producción que pueden corregirse, por ejemplo, cambiando una configuración, deshabilitando alguna parte de la lógica, y demás.

He discutido con mi gerente que debemos reproducir los errores localmente para asegurarnos de que la corrección funcione, y más importante aún para que los desarrolladores y la garantía de calidad puedan incluir el control de estos casos como parte de la versión normal.

Mi gerente piensa que es una pérdida de tiempo, ya que la solución funciona, por lo que no es necesario reproducirla localmente.

Entonces: ¿Deberíamos tratar de reproducir localmente para verificar las correcciones? ¿Alguna sugerencia sobre cómo vender este punto a mi gerente si está de acuerdo conmigo?

¿Tienes prisa? Si es así, ¡entonces reproduce los errores! Esto crea una mentalidad metódica que debe tener para evitar más problemas. ¿De qué otra manera podría descubrir viejos errores reintroducidos? Los errores de reproducción llamarán la atención de los demás:

Buen gerente : "¿Qué estás haciendo?"

Buen desarrollador : "Recibimos ese error nuevamente. Estoy reconstruyendo el entorno de prueba para que podamos reproducirlo".

Buen gerente : "WTF? Pensé que Dave dijo que había corregido eso? Hey Dave, ¿no corrigió ese error? ¿Por qué estamos perdiendo el tiempo de nuevo con esto?

Versus:

Ass-hat Manager : "¿Qué estás haciendo?"

Buen desarrollador : "Recibimos ese error nuevamente. Estoy reconstruyendo el entorno de prueba para que podamos reproducirlo".

Ass-hat Manager : "No, no tenemos tiempo. Solo corrígelo y arrástralo. ¿Respondiste al correo electrónico sobre la reunión? Tengo que irme. Tengo 10 con Steve. Bien. Ah, ponlo de vuelta. , y ah enviar ese correo electrónico ".

Como director, les digo a todos mis equipos que "tomen el tiempo hoy" para hacerlo bien, así que no nos levantaremos a la medianoche.

Aunque decir que la prueba unitaria es la solución y no es necesario reproducir el error si los usa suena bien, no creo que funcione en el mundo real. El hecho de que no hayan reproducido el error en el sitio significa que la reproducción probablemente no sea trivial. Esto probablemente significa que la fuente es complicada. Si el problema era trivial para representar en una prueba unitaria, esa prueba unitaria sería entonces una reproducción del error. Si no lo han reproducido, probablemente no puedan escribir una prueba unitaria simple para ello.

Si no ha reproducido el error, realmente no lo comprende. Es posible que haya encontrado un error en el sistema, pero eso no garantiza que haya encontrado el error que el cliente estaba viendo.

Si no puedes reproducir el error, no puedes estar seguro de que realmente esté arreglado. Puede tratar solo un síntoma del problema y no el problema central. El cliente puede tener un vector diferente al mismo problema central y su problema no será reparado.

Creo firmemente en la reproducción de errores si es económicamente viable (por ejemplo, no copiar todo el disco duro de un usuario en su máquina local solo para reproducir el entorno).

La naturaleza desafortunada de los errores es que a menudo solo hay una forma de corregir un error, pero hay muchas formas de enmascararlo, y muchas correcciones realmente enmascaran en lugar de corregir. Es posible que nunca encuentre la causa raíz, por lo que el error volvería a aparecer, o más tarde aparecería otro error aparentemente diferente.

Si puede encontrar un ejemplo de lo que sucedió (por ejemplo, dos errores no relacionados de la misma causa raíz), es posible que pueda ganarse a su jefe.

Creo que la respuesta a esto depende de cómo pruebes tus errores.

¿Utiliza una herramienta de prueba automática (como los marcos xUnit, Fit / Fitnesse, etc.)?
¿Utiliza un proceso de compilación automatizado?
¿Este proceso de construcción automatizado llama a las pruebas y registra los resultados?

A menos que la respuesta a las preguntas anteriores sea afirmativa en todos los ámbitos, incorporar verificaciones para verificar que se han corregido los errores será tedioso y doloroso. También será difícil convencer al gerente de aplicar tiempo para incorporar estos controles porque siempre pueden decir "bueno, no tenemos suficientes recursos humanos para esto".

Si invierte algo de tiempo en una solución automatizada, no será necesario agregar estas pruebas en el proceso de compilación ya que el primer paso para resolver cualquier error debería ser crear una prueba que reproduzca el problema localmente de todos modos.

Para mi proyecto, usamos subversión para control de fuente, Jira para gestión de actividades, Hudson para compilaciones, Fitnesse y MSTest para pruebas. Todos estos están unidos mediante la integración continua. Fitnesse hace las pruebas de aceptación y MSTest las pruebas unitarias y se ejecutan automáticamente cada vez que se realiza una construcción para darnos un indicador cuantitativo de cuán "buena" es la construcción.

El único caso donde no debería reproducirlo localmente es cuando eso no es factible. Tal vez necesite MUCHOS datos, datos de propiedad, hardware o quizás requiera una configuración más compleja que la que tiene.

Tuve que hacerlo algunas veces porque no pudimos duplicar la configuración interna. (Parte del trabajo de desarrollo incluso se había llevado a cabo en el sistema del cliente). El cliente sabía desde el principio que iban más allá de lo que podíamos reproducir y que los errores que este surgió iban a ser difíciles de manejar.

El principio básico detrás del desarrollo basado en pruebas es que tiene una prueba que demuestra alguna característica.

En este caso, crea una prueba que demuestra el error. La prueba falla.

Arreglas el error. La prueba pasa. Como hacen todas las otras pruebas. Has solucionado el error sin crear otros problemas.

En la mayoría de los casos, no puede saber que el error que ha reproducido es el mismo que el que está experimentando su cliente. Por eso, la reproducción no garantiza que el problema esté realmente solucionado.

Por ejemplo, los clientes experimentaron un error de comunicación con un proyecto en el que trabajé. Buscamos a través del código para corregir cualquier posible error. Un error involucraba un error ASIC en el microprocesador PIC, y la errata del chip proporcionó una solución que implementamos. Luego, uno de mis compañeros de trabajo tomó medidas extremas para reproducir el error y así poder afirmar que el problema de nuestro cliente probablemente fue solucionado.

No fue así.

Al final, agregamos una gran cantidad de codificación defensiva y el cliente nunca volvió a experimentar el problema. No estamos seguros exactamente de qué solución solucionó el problema, y sería maravilloso conocer y reproducir el problema que tenían nuestros clientes, pero al final del día nada de eso importa. Todo lo que importa es que el software funcione.

Por lo tanto, es genial poder reproducir un error y comprender en profundidad qué causa un problema, pero reproducir un error no es garantía de resolver el problema de un cliente, y el software en funcionamiento es más importante.

Parece que su lugar de trabajo está demasiado lejos en el extremo "no reproducir nada" del espectro, y eso es una pena cuando un poco de trabajo extra puede producir un software mucho más confiable. En este post he argumentado que el otro extremo del espectro tampoco es tan bueno, así que trataría de presionar por algo intermedio.

Encuentro la idea de no reproducir un error arreglarlo nada menos que bizarro.

Después de todo, no puedes estar seguro de que algo es el problema hasta que puedas reproducirlo. Hasta entonces, es simplemente una conjetura (incluso si está bien informado, sigue siendo una conjetura).

Ahora, independientemente de si la prueba de la unidad o no, creo que es irrelevante para esta discusión, ya que la reproducibilidad es simplemente una cuestión de ¿has encontrado el error? Una prueba de unidad no lo ayudará si está probando algo incorrecto, trabajando en suposiciones incorrectas o simplemente ha entendido mal el informe de error (posiblemente vago) sobre lo que realmente está sucediendo.

Es por eso que reproduces el problema.

Hay muchas buenas respuestas a esta pregunta, pero la mayoría de ellas no se refieren directamente a la economía de la situación, que es quizás lo principal que puede influir en su gerente.

Si no repro, entonces

ahorre tiempo / esfuerzo ahora, pero
incurrir en riesgo

Sopesar las ventajas y desventajas de incurrir en esfuerzos para reducir el riesgo depende en gran medida de la situación: qué tipo de software está produciendo, cuántos clientes, qué ''errores'' malos están produciendo (por ejemplo, si el sitio de ventas se cae y usted pierde un millón de dólares al día, o el foro web se cae y las personas tienen que esperar hasta mañana para chatear en línea), cuánta automatización de pruebas tiene (afecta la cantidad de esfuerzo para reprogramar / corregir errores), ...

Muchos (¿la mayoría?) Son reacios al riesgo, así que cuando se trata de persuasión, intente deletrear los diversos riesgos (regresión de otras características, despliegue de una solución que en realidad no lo solucione (y parezca estúpido para los clientes), ... ), así como la estimación del esfuerzo que necesita gastar para mitigar ese riesgo (costo de reproducción y confianza en la solución).

La naturaleza del error también está en cuestión:

¿Se puede reproducir el defecto rápidamente con una prueba unitaria? Si es así, el desarrollador que trabaja en el arreglo debe escribir dicha prueba unitaria, integrándola en un conjunto de regresión más completo. Esto asegura que el trabajo futuro no reintroduce el defecto.
¿Se puede reproducir el defecto programáticamente (por ejemplo, con un script de Perl o Python)? Si es así, el equipo de QA probablemente debería tener un caso de prueba automatizado que lo cubra y pueda ser utilizado rápidamente para la verificación.
¿Se puede reproducir el defecto mediante un conjunto de instrucciones paso a paso? Si es así, el equipo de control de calidad (o quien haya marcado inicialmente el error) debe proporcionar el número mínimo absoluto de pasos para la reproducción.

Estos tres principios ayudan enormemente a impulsar el proceso de QA en mi equipo de prueba.

Por lo general, lo mejor para el desarrollador es reproducir el defecto por sí mismo. Si esto no es posible (por ejemplo, escasez de recursos de hardware), trabajar directamente con QA (o quien haya marcado inicialmente el error) sería la mejor opción. Aunque algunos defectos son lo suficientemente obvios (por ejemplo, un error ortográfico en una opción de menú), otros pueden tener mayores consecuencias que pueden ser detectadas por un desarrollador que conoce el estado subyacente de la aplicación.

También es útil que los desarrolladores reproduzcan los defectos para confirmar que efectivamente son defectos. Los probadores, aunque indispensables (hablando como probador de software;)), a menudo carecen de un conocimiento profundo del código de la aplicación, y pueden no tener una comprensión sólida de por qué el comportamiento no se ajusta a sus expectativas (o especificaciones).

La parte superior de mi cabeza:

Podría inadvertidamente introducir nuevos errores con las correcciones
No puede estar 100% seguro de que la corrección realmente soluciona el error sin probar (excepto quizás en los casos más simples)

La razón más importante para tener que reproducir un error localmente es asegurarse de no haber atornillado nada más mientras lo reparaba. Si la solución es solo una cosa de configuración o cualquier cosa que no requiera una recompilación, este argumento es menos poderoso ya que todo lo que se compiló ya debería haber sido probado.

Si su gerente no entiende este punto, no hay mucho que pueda hacer para convencerlo, aparte de mostrarle casos reales en los que arreglar un error en realidad arruinó algo y eso causa aún más retrasos de lo que habría llevado reproducir el error localmente. .

Para caídas aleatorias del campo, a veces simplemente no puedes reproducirlos. He depurado las condiciones raras de la carrera y los bloqueos "imposibles" con los fallos de choque postmortem recopilados por el servicio de informe de errores de Windows de Microsoft. Creo que el gurú de Microsoft Raymond Chen llama a esto "depuración psíquica".

Si su empresa ofrece software de Windows (C ++ o .NET) al público, le recomiendo usar el servicio de Informe de errores de Windows (WER) de Microsoft. Es gratis, incluso para compañías de software comercial. Es más simple que escribir tu propio servicio de recopilación de informes de errores y recopilación de errores. WER incluso recopila todos los rastreos de pila para saber qué bloqueos están duplicados, lo que es útil cuando no tiene ganas de depurar miles de bloqueos duplicados. :)

Si no ha reproducido el error, su "solución" no es más que una suposición.

Siempre debes TRATAR . Debe identificar si se trata de un error, error o defecto. ¿Cómo puede usted solucionar o mitigar un problema sin entenderlo?

¿Cómo se resolverá para el conjunto de registro o prueba? Es el estado apropiado
- "Solucionado", "Abrir", "No se puede reproducir", "No se soluciona", "Característica"?

Si no puede reproducirlo, todavía se debe hacer una desición, dejar que se desvíe a / dev / null y pedirle que vuelva y le muerda.

sí, cuando sea posible / factible; ver Pruebas de regresión

La automatización de pruebas es lo que hace que todas tus pruebas sean reproducibles en cualquier momento con poco o ningún esfuerzo adicional. Las pruebas unitarias son un tipo muy común de automatización de pruebas que implica probar cada una de las partes más pequeñas individuales.

He discutido con mi gerente que debemos reproducir los errores localmente para asegurarnos de que la corrección funcione, y más importante aún para que los desarrolladores y la garantía de calidad puedan incluir el control de estos casos como parte de la versión normal.

Estoy especialmente de acuerdo con la parte sobre desarrolladores y control de calidad, incluidos los controles. Esto es parte de lo que los japoneses llaman Jidoka (que significa "automatización con un toque humano"):

[...] La autonomía evita la producción de productos defectuosos, elimina la sobreproducción y centra la atención en comprender el problema y garantizar que nunca vuelva a ocurrir. Es un proceso de control de calidad que aplica los siguientes cuatro principios:
Detecta la anormalidad.
Detener.
Repare o corrija la condición inmediata.
Investigue la causa raíz e instale una contramedida.

La contramedida está ahí para prevenir la recurrencia. Así es como se construye un proceso Poka-Yoke , a prueba de errores (y un proceso que permite que ocurran defectos es un proceso defectuoso). Los buenos gerentes deberían obtener eso.

Posiblemente repite lo que ya se ha escrito, ¡pero SÍ! El razonamiento es: solo encuentra un error una vez. Si puede escribir una prueba que replique el error, no tendrá que volver a probarla manualmente; su prueba automatizada la encontrará.
Entonces arreglas el error y puedes estar seguro sabiendo que tu software nunca volverá a sufrir este error. Esto es bueno. Le ahorrará tiempo. Te ahorrará dinero.

Leí un buen libro sobre depuración hace un tiempo que recomendaba no solo reproducir el error, sino también, después de solucionarlo:

sacando el parche y viendo si el error vuelve a aparecer
volver a poner la solución y ver si el error se soluciona de nuevo

La razón es que puedes intentar bastante solucionar un error, y esto te ayudará a saber que lo solucionaste. Si no sabe que lo arregló, aún podría estar roto.

(El otro día encontré un caso como este en el que una línea de código que parecía no tener relación causaba que nuestro sitio web se comportara de manera extraña: cuando saqué la línea de código, el sitio funcionó, pero cuando lo puse en , el sitio estaba bien. Pero resultó que era solo una coincidencia, el sitio funcionaba mal cada tanto sin importar lo que hice, porque me ingresaba y desconectaba sutilmente. Debes saber que tu solución es real fijar.)

EDITAR: Trabajé en un lugar donde el propietario se puso muy irritable sobre los errores que se habían reclamado para ser corregidos, pero no lo eran. Esto sucedió porque a pesar de que yo (u otro desarrollador) pude reproducir el error, no lo reproduje exactamente de la misma manera en que el probador lo había producido. No solo debes reproducir el error, sino que debes asegurarte de que estás reproduciendo el error exactamente de la misma manera que lo hizo el verificador .

(Pero si quieres probar primero, sigue adelante, ¡quizás encuentres otro error! Después de eso, haz que el probador demuestre su reproducción antes de que comiences a trabajar en el error).

Si no puede reproducir el error, no puede repararlo.

Cambiar una configuración, deshabilitar alguna parte de la lógica y tal en la producción es una solución temporal.
Necesitamos asegurarnos de que el producto sea confiable y cumpla con los requisitos de los clientes al probarlo localmente, las pruebas en varios dispositivos (móvil, tableta, etc.) y multiplataforma (Firefox, Chrome, Internet Explorer) también juegan un papel importante aquí.
Es necesario verificar que el problema se reproduzca localmente primero para garantizar la calidad del producto, ya que si el cliente encuentra el mismo problema, sería un problema :)
Para proporcionar un producto confiable, libre de errores comprender y reproducir el problema es lo más importante.
Como mencionó, los errores se reparan (es decir, no se reproducen) al cambiar una configuración, deshabilitar alguna parte de la lógica, y demás. Pero si el cliente tiene la misma configuración que por el tiempo que está cambiando, entonces realmente sería un gran problema, por lo que la prueba en varios dispositivos (móvil, tableta, etc.) y multiplataforma (Firefox, Chrome, Internet Explorer) es muy importante.

Como el error ya está en producción, significa que algo pudo haberse perdido durante la prueba y también por error.
Después de un tiempo cuando el probador / QA encuentra el error o si ese error es informado por el cliente, entonces desde el lado del desarrollador se han realizado algunas correcciones.
Después de corregir esos errores, localmente deben verificarse si son reproducibles o no según el escenario de prueba y la cobertura de prueba, para que no vuelvan a estar presentes en la producción en el futuro y el cliente nunca tendrá errores o problemas.