Metodología de seguimiento de errores

Question

Estoy trabajando en el software para una empresa que nunca presenta informes de errores, el único que se queja, "algo así no funciona". A veces puedo entender de qué están hablando, a veces no. Mis pedidos de capturas de pantalla y más detalles cayeron en oídos sordos (una vez que tomaron una captura de pantalla, luego la imprimieron, escanearon con su máquina de fax y se la enviaron por correo electrónico a mi jefe como TIFF).

Tengo varios métodos en el lugar para darme los datos que necesito. Estos son los pasos que he tomado:

• un gestor de fallos en las que pueden entrar los insectos (sólo uno fue alguna vez se ha introducido)
• Registro de errores. Cada vez que ocurre un error, lo escribe en un archivo de registro, cortesía de NLog
• El programa tiene un intento de detectar su método inicial para registrar excepciones.
• Cuando se detecta una excepción inesperada, tomo una captura de pantalla del programa.
• Se registra el acceso a todos los formularios y, hasta cierto punto, lo que están haciendo. (aunque esto generalmente solo funciona si tienen éxito)

¿Qué otros métodos puedo emplear para permitirme detectar errores y reunir más datos sobre ellos para saber cómo reproducirlos?

Answer 1

Para ser justo, parece que definitivamente hace su parte del trabajo lo suficientemente bien, ha implementado el software, está registrando los errores de forma activa, casi no tiene opciones.

Programaré una reunión formal en la que analizará la importancia del seguimiento de errores: por qué debe implementarse y por qué el sistema actual está fallando. Explíqueles cómo esto está reduciendo su trabajo, lo que significa que se pierde dinero.

Edúcalos y seguirán. En lugar de ser "ese desarrollador molesto que quiere que pasemos horas en algún software al azar", usted será "ese desarrollador que está buscando nuevas soluciones a problemas y problemas, y haciendo los pasos correctos para rectificar tales situaciones ".

---

En respuesta a su comentario diciendo que está "solamente un interno" - esto debería ser irrelevante. Tiene todo el derecho de explicar su opinión, especialmente si va a salvar la suya, así como el tiempo, dinero y esfuerzo de otras personas. Hable con un superior, pídales que programen una reunión, se mostrará iniciativa, cuidado y prosperidad - tres factores principales que deben tener en cuenta.

Answer 2

Utilice un "supervisor" que supervise la aplicación y registre información contextual al respecto, p. cantidad de memoria que utiliza, cantidad de memoria disponible en el host, cantidad de archivos abiertos, etc.

El tipo de datos que pueden ser útiles para saber cuándo falla la aplicación y (por supuesto) no tuvo tiempo para iniciar sesión .

Answer 3

Parece que tiene que educar a su cliente sobre cómo comunicarse de manera apropiada con usted sobre los problemas o las solicitudes encontradas. Hace poco solicité que uno de nuestros clientes comprara SnagIt. Es una herramienta que hace que capturar, anotar y enviar capturas de pantalla sea muy fácil.

https://store.techsmith.com/order/snagit.asp

ser paciente, y trabajar con ellos (por separado) para mejorar las comunicaciones.

Answer 4

Tuve un problema similar hace algunos años en mi lugar de trabajo. Básicamente, todo se reduce a las políticas de la empresa. Una vez que sepa que ha encontrado las herramientas adecuadas, como el software de seguimiento de fallos correcto (utilizamos Redmine, por cierto), debe aplicar su uso.

En mi lugar de trabajo tuve que hablar con mi jefe al respecto, le expliqué cada detalle importante sobre las herramientas, le demostré cómo funcionaban en los servidores de prueba y le señalé cómo puede ahorrar tiempo, nervios y reducir costos.

Después tuvimos una gran reunión, una larga discusión con todos los involucrados (especialmente los evaluadores), y luego decidimos cómo y cuándo usar las herramientas seleccionadas. Ahora una de nuestras políticas es: Si no está en el rastreador de errores y está razonablemente documentado --- lo más importante es que se puede reproducir, no es un error y no se arreglará.

Tardó un poco en acostumbrarse al nuevo flujo de trabajo, pero ahora nadie quiere perderse las notificaciones por correo electrónico sobre errores, compilaciones nocturnas y nuestra "ronda de café" diaria donde tenemos un poco de chit sobre lo que está por venir y qué prioridades cambiadas

Espero que ayude.

Answer 5

Ponga un botón en cada formulario/página de la aplicación. Debería mostrarse de forma destacada en algún lugar. Cuando hagan clic en el botón, pídales que llenen un cuadro de texto que diga cuál es el problema.

No haga que prioricen o categoricen el error. Simplemente debería permitirles escribir lo que quieran en un campo. Su aplicación debe recopilar toda la información que considere necesaria y enviarla a su sistema de seguimiento de errores. Una vez allí, haga el resto ...

Answer 6

Si tiene un software de seguimiento de errores, úselo. Incluso si solo ingresa la información que le dicen sus usuarios, es un comienzo. Dígales que los errores no se pueden arreglar sin detalles de cómo reproducirse. Además, todos sus colegas y probadores deberían usar el software de seguimiento de errores.

Answer 7

Hay varias formas en las que puede controlar su Crashings de aplicaciones .Net (específico) aplicaciones Windows y Web 1. En su archivo Global.asax.cs, bajo Application_Error registro método de escritura en un archivo de texto de modo que todo lo que pueda ordena excepciones con su rastro de pila y todas las cosas. 2. En un escenario común que no sea el entorno .net, puede crear un método común para que pueda invocarse para escribir el registro cada vez que tenga una excepción, significa en cada try - catch o si se proporciona alguna plataforma para tal.

O si no desea escribir un registro y está trabajando en el entorno de Windows, puede ir al visualizador de eventos y filtrar los bloqueos de aplicaciones con sus volcados.

También Nlog es una buena forma de iniciar sesión.

Para archivar y corregir errores, puede usar Trac para rastrear y solucionar problemas para que no sea necesario tomar impresiones/faxes. Todo en línea, gratis y rápido.

esperan que ayude a

Answer 8

Siga esto para el registro de excepción

1. formulario/página en la que se produjo el error
2. Evento/método
3. fecha/hora
4. Su Seguimiento de la pila
5. Mensaje de error
6. Algún error C oda
7. usuario
8. número de línea si es posible

Answer 9

Ellos son clientes, no es parte de su empresa. Hay un dicho "el cliente siempre tiene la razón". Como clientes, pueden sentir que les está pidiendo demasiado que utilicen su metodología y herramientas de seguimiento de errores para facilitarle la vida.

Pero una pregunta más importante es: ¿su software tiene demasiados errores? Parte de su insatisfacción puede ser con la calidad del software. Su mención sobre el hecho de poner bucles try-catch parece indicar esto.

Mejorando la calidad del software.

1. ¿Tiene un entorno de prueba, a parte de su entorno de desarrollo, donde se prueba a fondo todo el software, escenarios, pruebas unitarias, pruebas automatizadas, pruebas manuales, antes de entregar al cliente?

2. ¿Tiene probadores cuyo único propósito es probar el software?

3. ¿Tiene un conjunto documentado de pruebas y planes de prueba para los probadores?

4. ¿Tiene pruebas unitarias automatizadas para todos sus codigos?

5. ¿Tiene convenciones de codificación y estándares, requisitos/convenciones de diseño y estándares, convenciones y estándares de prueba/prueba, un proceso para el SDLC, análisis de causa raíz?

6. ¿Tiene alguna opinión similar?

7. ¿Tiene controles para asegurarse de que se abordan todos los problemas de las revisiones por homólogos antes de pasar a un entorno de prueba/producción?

Todas estas cosas podrían reducir el número de defectos de software, y hacer que el cliente feliz, que es realmente el objetivo principal.

---

Ahora, sobre su pregunta original.

Claramente no les gusta usar el software de seguimiento de errores. Por lo tanto, debe ser proactivo y seguir las sugerencias de los carteles anteriores. Parece que esto es exactamente lo que estás haciendo, y has dado algunos buenos pasos para hacerlo. ¡Estás en el camino correcto!

1. Mejore su registro para que pueda obtener información después del hecho. Estás haciendo esto.

2. También debe tener acceso remoto si es posible para que, si pueden duplicar el error, puedan ver lo que está sucediendo.

3. Si envían información sobre un error a un punto de contacto en su empresa, esa persona tiene que asegurarse (ya sea por hacerlo ellos mismos o subordinarse a un delegado (supongo que su jefe es el punto de contacto) y usted es el delegado :)) que el error se ingresó con toda la información relevante.

4. Idealmente, podría tener un modo donde capture las interacciones del usuario y pueda reproducir el error mediante la función de reproducción.

5. Puede instalar una cámara de video y registrar lo que están haciendo, de modo que si llaman sobre un error y son capaces de reproducirlo, puede ver exactamente lo que están haciendo.

Answer 10

Hemos utilizado ta durante informes de errores de usuario, me refiero a la presentación de informes por los usuarios de los insectos que encuentran, no informar de errores en los usuarios, por supuesto. Lo bueno de rt es que se puede presentar a los usuarios simplemente como una dirección de correo electrónico. Las instrucciones son tan simples como pueden ser: encontrar un error, enviar un correo electrónico. En mi experiencia, esta es una venta mucho más simple que Trac, Bugzilla y todo lo demás. Son buenos en sus diversas formas, pero todos ellos, para la mayoría de los usuarios, se parecen mucho al llenado informático de formularios.

Answer 11

Me gustaría ir un paso más allá de la respuesta de DisgruntledGoat, y decir que cualquier persona de la compañía que esté en contacto con el cliente debe conocer la herramienta de seguimiento de errores y debe introducir los problemas informados por los usuarios. Esto significa representantes de ventas, gerentes de proyectos, atención al cliente, etc. ...

Estas son las personas que tienen mucho que ganar al tener clientes más felices. Al principio, es posible que tengas que sostener algo con la mano. Pero cuando se dan cuenta de que los problemas mejor informados se resuelven más rápido y les ayudan a generar más ventas/menos trabajo, verán que la calidad de los informes de errores aumenta.