¿Cuánto tiempo puede pasar escribiendo un nuevo informe de error?

En general, me llevó entre 10 y 30 minutos, todo depende del error que informe. Si es de naturaleza severa, debe proporcionar registros del servidor, consultas SQL, capturas de pantalla y cualquier información de depuración si lo ha realizado.

Si es solo un defecto de la interfaz de usuario, proporcione la captura de pantalla.

Si es solo un problema de compilación, proporcione los registros.

Si es un problema de rendimiento, proporcione los tiempos.

Si es un problema de seguridad, proporcione todas las dependencias que están expuestas.

y muchas otras cosas

Con todo esto, debe proporcionar los pasos que ha seguido.

Entonces, en promedio, está gastando un mínimo de 10 minutos en informar un error.

Con tus 10 minutos de tiempo, dale una buena comprensión al desarrollador para que solucione ese error. La notificación de errores no muestra que haya un defecto, está destinado a informar al desarrollador sobre el problema de forma rápida y clara.

Siempre y cuando se necesite corregir el valor del error, el concepto importante es notificar a las partes relevantes a tiempo para solucionarlo. Si el error es importante y los pasos para reproducirlos son difíciles, o si partes del informe de errores requieren mucho tiempo, puede presentar uno rápidamente que detalle qué información adicional está por venir. Luego más tarde seguimiento con detalles. Un buen informe de error ahorra tiempo al equipo de ingeniería, pero uno tardío puede solucionarse antes de archivarlo o dar el impulso de lanzamiento que no debería tener. Es más importante que las personas sean notificadas rápidamente sobre algo que está bloqueando un lanzamiento, particularmente hacia la fecha de lanzamiento programada o algo que necesita arreglarse en la producción. En general, la importancia del error determina el valor del tiempo dedicado al informe del error. Si deben hacer que alguien trabaje horas extras para arreglarlo, puede trabajar horas extras para archivarlo.

La pregunta no es útil. Estás combinando el rendimiento de los empleados con su papel en las pruebas.

El contexto lo es todo en las pruebas y el trabajo de aseguramiento de la calidad: el contexto del software que se está probando, los procesos del equipo, los requisitos de la administración para informes y métricas, etc.

Todo esto es infinitamente discutible cuando se trata de los detalles; Te daré mi punto de vista. El propósito de las pruebas es ejercitar las aplicaciones para medir algo; puede llamar a eso algo “calidad”, “conformidad con los requisitos”, “soporte de casos de uso”, lo que sea, está utilizando algún oráculo para la corrección o las expectativas en la aplicación.

Cuando encuentre una variación, llámela “error”, “problema”, “problema”, “comportamiento experimentado no conforme”, lo que sea, entonces debe dar a conocer esa variación. Puede ser muy formal y registrar un boleto, puede ser informal y mostrárselo a alguien. Puede tener procesos súper refinados para la categorización, priorización, escalado, con actualizaciones de estado, antigüedad, votos, lo que sea; o puede ser súper informal y simplemente arreglarlo usted mismo o vincular el programa con el desarrollador, o simplemente rogarles que lo arreglen. Los detalles son específicos del contexto.

Si tradicionalmente es responsable de informar sobre los síntomas si hay un problema, y ​​utiliza un sistema de tickets, probablemente debería crear un ticket con bastante rapidez. Lo importante puede ser introducirlo en el sistema y luego dar detalles. Si usted es tradicionalmente responsable de * diagnosticar * un problema, bueno, eso a menudo lleva más tiempo. Aún así, probablemente debería obtener un informe en el sistema rápidamente, luego completarlo con detalles.

Si usted fuera un ingeniero de control de calidad en mi equipo, me preocuparía más si está probando las cosas correctas y si se enfoca en las cosas más importantes para probar, que cuánto tiempo le llevó crear un boleto mecánicamente. Algunos problemas pueden demorar días en comprender, reproducir y documentar por completo. El valor devuelto por un ingeniero de control de calidad no se puede medir por la tasa de generación de tickets. Si cree que a su equipo le toma demasiado tiempo escribir boletos, busque herramientas que los ayuden a recopilar más información con mayor facilidad. O templatice sus pantallas de errores.

Si está dedicando tiempo a formalizar su proceso en torno a cuánto tiempo debe llevar informar un problema que aún no se ha descubierto, le sugiero respetuosamente que tal vez esa no sea la mejora de proceso de mayor prioridad que pueda abordar. Pero el contexto lo es todo, y no sé el tuyo.

La forma más sencilla de reducir el tiempo dedicado a escribir un informe de error es haciendo lo siguiente:

• Describa lo que se descubrió usando viñetas y agregue una grabación de pantalla para aclarar el problema.

Eso es. No hay campos o secciones largas para describir los pasos para recrear, el resultado real, el resultado esperado, la solución conocida, el número de usuarios afectados y más. La grabación de pantalla es un excelente lugar para comenzar una conversación.

Normalmente pasaré 2 minutos compartiendo un problema.

Suponiendo que está trabajando en un equipo ágil, la presentación de un error no debería llevar más de 30 minutos . Si el error requiere más que eso para describirlo y reproducirlo (ocurre de manera intermitente), es mejor hablar directamente con los desarrolladores.

Archivar un informe de error solo es bueno para los errores críticos y por debajo (estoy usando la categorización de Jira) con los que los desarrolladores no deberían molestarse ahora. Los errores que dejan de funcionar deben corregirse de inmediato para que pueda continuar con sus pruebas.

Debería demorar entre 5 y 10 minutos y un máximo de 15 minutos dependiendo del error y su complejidad.

Un nuevo debe consistir en:

• Una breve descripción / titular
• Inquilino / Dominios
• Versión de lanzamiento
• Detalles sobre cómo producir el error
• Resultado Esperado
• Resultado actual
• Registros (si es necesario)
• Información adicional (si es necesaria)
• Imágenes adjuntas y gif

Ahora debería poder visualizar esto y el tiempo necesario para esto.

¿Cuánto tiempo está bien que pases escribiendo el código para corregir un error?

Como puede ver, ese es igualmente difícil de responder porque:

1. Los errores varían en complejidad. No son una cosa monolítica.
2. Asignar tiempo solo para escribir informes de errores solo es como asignar tiempo solo para escribir códigos solo.
3. El tiempo dedicado depende de:

1. tiempo necesario para aclarar los requisitos técnicos / comerciales o (si es necesario) para volver a visitar el documento de especificaciones funcionales
2. el tiempo necesario para ejecutar el mismo caso de prueba nuevamente
3. tiempo necesario para ejecutar manualmente escenarios de prueba similares para investigar las condiciones (escenarios donde se encuentra el error versus escenarios donde no se encuentra el error)
4. tiempo necesario para determinar qué compilación se introdujo el error
5. tiempo necesario para investigar la causa raíz probable

La mejor manera de informar un error es mostrarle al desarrollador el error en su escritorio o en su escritorio.

De todos modos, si tiene que escribir, hagámoslo breve y claro para ayudar a sus lectores (desarrolladores, gerentes, compañeros) a comprender el problema. Sus lectores son diferentes de mis lectores, así que trate de entender qué tipo de información están viendo en su informe. Cómo quieren que se vea el informe.

De hecho, depende del error.

Tarda de 5 minutos a 30 minutos.

10min-> si es fácil de reproducir y si es obvio.

max 15-30 min → Agregue todos los pasos de prueba en detalles, agregue la captura de pantalla, adjunte los registros, pruebe el entorno.

Cada segundo que se pasa escribiendo un informe de error es un segundo que NO se gasta en arreglarlo.