Menú

El arte de informar de errores: ¿Cómo comercializar y corregir sus errores?

art bug reporting

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

¿Por qué es necesario comercializar un error?

Lo primero que me viene a la mente cuando comienzo a escribir este artículo son las palabras de Cem Kaner – “El mejor evaluador no es el que encuentra la mayor cantidad de errores o el que avergüenza a la mayoría de los programadores. El mejor evaluador es el que soluciona la mayoría de los errores '.

Ahora, ¿cuál es la diferencia entre encontrando la mayoría de errores y arreglando la mayoría de errores ?

¿No es obvio que cualquier error registrado en un sistema de gestión de errores debe ser arreglado por el desarrollador? La respuesta es No. Factores como el tiempo para comercializar el producto, el tiempo para completar el proyecto a tiempo y los desarrolladores que trabajan en horarios ajustados poco prácticos, etc., obligan a las empresas a lanzar el producto con pocos errores que no afectarán en gran medida a los usuarios.

Arte de informes de errores

(imagen fuente )

¿Quién le da confianza a la gerencia al afirmar que los errores presentes en el producto no afectarán la confianza del cliente, la confiabilidad y el interés de las partes interesadas? - El ingeniero de pruebas o el equipo de pruebas: es deber de cada ingeniero de pruebas corregir los errores que puedan tener un impacto negativo en la calidad del producto.

La prioridad del error , en mi opinión, depende en gran medida de cómo el evaluador presenta un problema a los equipos de desarrollo y gestión.

Piense en ello como publicidad o marketing del problema: esto implica 2 pasos:

  1. Escribe o informar errores correctamente
  2. Sepa todo sobre el error, para que se puedan explicar mejor los detalles adicionales.

Lo que vas a aprender:

El arte de informar errores

Sí, informar de errores es un arte . La forma en que se escribe un error muestra la habilidad técnica, la experiencia en el dominio y las capacidades de comunicación de un ingeniero de pruebas.

Normalmente, un error debe contener la siguiente información:

  • Resumen de errores
  • pasos para reproducir
  • Archivos adjuntos (instantáneas, archivos de registro, etc.)
  • Reproducibilidad de errores
  • Severidad del error
  • Versión de software, información medioambiental
  • Otra información basada en requisitos organizativos.

Una nota importante: Investigue siempre más profundamente para encontrar la causa raíz del problema e informarlo. Por ejemplo, un simple error de inicio de sesión con la combinación correcta de nombre de usuario y contraseña puede estar relacionado con varias razones, tales como:

  1. Credenciales de inicio de sesión no validadas en absoluto
  2. Problemas de tiempo de espera de la red en caso de inicios de sesión remotos
  3. El sistema puede considerar todos los CAPS como no CAPS.

Por lo tanto, como Probador, debería poder descifrar las diferencias mientras sigue las declaraciones de resumen de errores:

  • 'No se puede iniciar sesión con el nombre de usuario y la contraseña correctos'
  • 'No se puede iniciar sesión con el nombre de usuario y la contraseña correctos, cuando el nombre de usuario o la contraseña contienen una combinación de alfabetos CAPS y no CAPS'.

Esta última es una descripción muy clara del problema y no es ambigua. Con esto, no solo aumenta su credibilidad como evaluador, sino que también informa el problema real en lugar de un síntoma.

Ahora, echemos un vistazo a cada campo involucrado en un informe de error y analicemos los aspectos importantes de cada uno:

# 1. Resumen de errores

Un resumen de errores debería proporcionar una instantánea rápida de cuál es exactamente el problema. Tiene que ser preciso y bien dirigido.

Ejemplo :

Aparte de la teoría, intentaré explicar con ejemplos.

Supongamos un módulo de inicio de sesión simple. Supongamos que el problema es que un nuevo usuario que visita un sitio web no puede iniciar sesión con su contraseña predeterminada. Cuando presenté el mismo escenario a muchos de los estudiantes que capacité durante la fase inicial de capacitación, hubo varias respuestas como resumen de errores. A continuación se muestran algunas muestras de cómo se veía el resumen:

afirmar () c ++

“ El nuevo usuario no puede iniciar sesión '

'El inicio de sesión del usuario no funciona como se esperaba'

'El usuario no puede iniciar sesión con la contraseña correcta'

resumen de errores incorrecto y correcto

De los ejemplos anteriores, ¿puede elegir una declaración que realmente describa el problema? No lo creo. El resumen siempre debe proporcionar información completa sobre el escenario fallido.

Considere la siguiente declaración:

'El nuevo usuario no puede iniciar sesión con la contraseña predeterminada proporcionada por correo electrónico o SMS'

Como puede ver, a partir de la declaración anterior, un desarrollador puede comprender claramente cuál es el problema y dónde está.

Por lo tanto, trate de encontrar las palabras adecuadas para describir el resumen que daría la información directamente. Deben evitarse declaraciones genéricas como 'no funciona correctamente', 'no funciona como se esperaba', etc.

# 2. Pasos para reproducir y archivos adjuntos

Los errores irreproducibles siempre pasan a un segundo plano, aunque puedan ser importantes. Por lo tanto, tenga mucho cuidado de escribir los pasos de manera correcta y descriptiva.

Los pasos deben ser precisos y exactamente iguales a los que llevaron al problema. Para errores relacionados con la funcionalidad, el siguiente ejemplo es el mejor ejemplo.

Ejemplo :

Considere el mismo problema mencionado en la sección anterior.

  1. Cree un nuevo usuario usando la opción Registrarse en la página de inicio. (Ejemplo de nombre de usuario: HelloUser)
  2. Se recibirá un correo electrónico y un SMS con una contraseña predeterminada. La ID de correo electrónico y el número de teléfono móvil para SMS se proporcionan al crear el usuario en el Paso 1. (Ejemplo de correo electrónico: HelloUser@hello.com , Ejemplo de número de teléfono móvil: 444-222-1123)
  3. Seleccione la opción Iniciar sesión en la página de inicio.
  4. En el campo de texto del nombre de usuario, proporcione el nombre de usuario de muestra proporcionado en el paso 1.
  5. En el campo de contraseña, proporcione la contraseña predeterminada recibida a través de un correo electrónico o SMS.
  6. Haga clic en el botón Iniciar sesión
  7. Resultado Esperado: El usuario debe poder iniciar sesión con el nombre de usuario y la contraseña proporcionados y navegar a la página de la cuenta de usuario.
  8. Resultado actual: Aparece el mensaje “Nombre de usuario / contraseña no válido”.

pasos del informe de defectos

Si parte de la información no se proporciona en la muestra anterior, entonces resultar en brechas de comunicación y el desarrollador no podrá reproducir el problema. Los pasos deben ser específicos y detallados con los datos de muestra que utiliza durante la prueba.

Si es posible o donde corresponda, proporcione un instantánea de lo que ve exactamente en la pantalla. De esta manera, no solo proporcionará una buena visión del problema a los desarrolladores, sino también una evidencia del resultado de su prueba.

los no funcional Casos de prueba como casos de prueba de estrés, estabilidad o rendimiento, además de los detalles anteriores, la información sobre el escenario que causa el estrés en el sistema se puede informar tal como está. Además, hay pocos sistemas que informan registros de cada operación que se realiza. Los registros suelen ser declaraciones de impresión proporcionadas por los desarrolladores en su código. Siempre que se ejecute un módulo, se imprimirán o mostrarán los registros correspondientes. Cuando los registros estén disponibles, eso ayudaría en gran medida a los desarrolladores a reproducir el problema.

# 3. Reproducibilidad de errores

Un tema que sea grande o pequeño se priorizará en función de la reproducibilidad. Se puede ver siempre, a veces, raras veces o incluso solo una vez. Un tema que se reproduzca como “siempre” tendrá mayor prioridad que el resto.

no puedo reproducir un defecto

Por lo tanto, es deber de un ingeniero de pruebas rastrear el escenario exactamente para el problema que siempre se reproduce. A veces, puede haber algunos problemas fuera del control de un ingeniero de pruebas, lo que provocaría que un problema se reprodujera solo unas pocas veces, pero en múltiples ensayos. En tales casos, mencione siempre el número de juicios, se ejecuta un escenario particular junto con el número de veces que se ve el problema durante esos juicios.

Esto, a su vez, agregaría credibilidad al informe de error mencionado por usted. Nuevamente, esto mejoraría su reputación como evaluador. Más tarde te contaré las razones para tener una buena reputación.

# 4. Severidad del error

La severidad es sin duda uno de los mayores influenciadores para priorizar el error.

Las siguientes son las diferentes categorías de gravedad. Tenga en cuenta que estos son solo ejemplos generales y varían de una empresa a otra.

  1. Severidad 1 - Show Stopper: para errores que son catastróficos, sin ser corregidos, el usuario no podrá continuar usando el software y no hay una solución alternativa posible.
  2. Severidad 2 - Alta - para errores similares a Severidad 1, pero hay una solución
  3. Severidad 3 - Media
  4. Severidad 4: baja
  5. Severidad 5 - Trivial.

Por ejemplo, comparemos dos problemas similares.

En nuestros decodificadores, pocos proveedores de servicios brindan la información de frecuencia del servicio sintonizado actualmente. Supongamos que la frecuencia se muestra como 100 MHz en lugar de 100,20 MHz. Es posible que esto no afecte la visualización de los servicios por parte del usuario, pero puede afectar en términos de diagnóstico de monitoreo de los decodificadores. Por lo tanto, esto puede presentarse como un problema de gravedad 3.

Suponiendo un problema similar en el ámbito bancario: si el saldo de su cuenta se muestra como $ 100, en lugar de $ 100.20, imagine el impacto del problema. Debe ser un defecto de Severidad -1. Como puede ver en ambos casos, el problema es muy similar, ya que la interfaz de usuario no muestra los dígitos después del punto decimal. Pero el impacto varía según el dominio involucrado.

Participación eficiente en reuniones de control de versiones de software

Por lo general, cada organización tiene su propio proceso para investigar y priorizar errores. Por lo general, se celebraría una reunión a intervalos específicos durante el proyecto para discutir los errores y priorizar los mismos.

El proceso durante dichas reuniones es el siguiente:

  1. Consulte la lista de errores del sistema de gestión de errores de acuerdo con la gravedad.
  2. Mire el resumen y analice el impacto del error en la experiencia del usuario al usar un producto de software.
  3. En función de la evaluación de riesgos e impactos, establezca la prioridad y asigne el error a un desarrollador adecuado para que lo solucione.

Durante el paso 2, es imperativo que cada ingeniero de pruebas defienda el impacto del error en la experiencia del usuario si el error no recibe la prioridad que merece. Después de todo, somos los ingenieros de pruebas los que consideran el punto de vista de un usuario para escribir casos de prueba y probar el producto.

Considere el problema del ejemplo anterior de no mostrar los dígitos después del punto decimal en un dominio bancario. Para un desarrollador, puede parecer un problema menos grave. Podría argumentar que, en lugar de declarar la variable como un número entero, la declararía como un punto flotante para resolver el problema y, por lo tanto, menos grave.

Pero como evaluador, su función es explicar la situación del cliente. Su punto debería ser cómo se quejaría el usuario en este escenario. El evaluador debe decir que esto causará pánico entre los usuarios ya que el cliente pierde su dinero en centavos.

Impacto de no comercializar un error correctamente

Si un error no se comercializa correctamente, creará problemas como:

  • Prioridad de defecto incorrecta
  • Retraso en solucionar los problemas importantes
  • Lanzamiento de producto con defectos graves
  • Comentarios negativos de los clientes
  • Devaluando el valor de la marca

Impacto de no comercializar un error correctamente

Aparte de todas las razones mencionadas anteriormente, es muy importante crear su reputación como ingeniero de pruebas . Es más como desarrollar un valor de marca para uno mismo.

En la fase inicial de su carrera, si puede mantener su número de 'No se puede reproducir' o 'Necesito más información' o 'No es un error válido' o los cambios en la gravedad lo más bajo posible, en una etapa sus errores no serán analizados. en absoluto y se asignarían directamente al desarrollador apropiado para que los arregle.

Para desarrollar dicho valor de marca y ganarse la confianza de su equipo y de los equipos de desarrollo o de gestión, debe desarrollar algunas habilidades técnicas en términos de pruebas de conocimiento, dominio y habilidades de comunicación.

Conclusión

Cualquier producto o servicio, ya sea grande o pequeño, siempre fracasará sin la publicidad adecuada. Una vez que se establece una marca, cualquier producto pequeño puede ser un gran éxito entre la audiencia.

Dicho esto, la publicidad excesiva de un producto también puede dañar la reputación.

Por lo tanto, un error siempre debe escribirse de manera clara, concisa y precisa para que proporcione una ubicación exacta del error en el mapa de software extenso / exhaustivo. Reitero que esto no solo mejora la calidad del software sino que también reduce el costo de probar y desarrollar el software en gran medida.

¡No es demasiado tarde ahora! ¡Sigamos adelante y solucionemos los errores de inmediato!

¿Cuál es el mejor programa de descarga de música para Android?

Lectura recomendada

^