Menú

3 peores hábitos de notificación de defectos y cómo acabar con ellos

3 worst defect reporting habits

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Los defectos son un asunto serio y los pequeños errores pueden resultar costosos.

Sabes qué hacer cuando encuentras un defecto. Lo reporta; ya sea en un Rastreador de defectos / Herramienta de gestión de defectos o en una hoja de Excel. Los principios subyacentes son los mismos para ambos métodos.

Las herramientas de gestión de defectos no garantizan mejores informes. Son las buenas prácticas las que salvan el día.

Para apreciar lo bueno, debemos reconocer lo que no lo es.

Lo que vas a aprender:

3 peores hábitos de notificación de defectos y cómo acabar con ellos

peores-hábitos-de-notificación-de-defectos

Aquí va:

# 1) Pereza

No tomarse el tiempo para hacer lo mejor que pueda.

Este es el proceso de seguimiento de defectos seguido en la mayoría de los equipos:

(Nota- haga clic en cualquier imagen para ampliarla)

seguimiento de defectos

Como puede ver, el líder de prueba revisa los defectos antes de enviarlos fuera de los equipos de control de calidad.

Esta revisión incluye confirmar:

  • Validez- ¿Es un error?
  • Integridad: título, pasos, datos, captura de pantalla, etc.
  • Duplicados
  • Reproducible o no ... etc.

Sé de primera mano que es imposible que un cliente potencial de QA sea 100% completo.

Entonces, la actitud, “Informaré el problema de la manera que yo quiera. El líder de QA puede volver a verificar. Él puede decidir si el defecto es válido / completo o no ”es el final de su equipo de control de calidad y su credibilidad.

¿Sabía que algunos clientes tienen un SLA para la cantidad de defectos inválidos aceptables? Una vez que se excede el número, ¿comienzan a penalizar a los contratistas por cada defecto no válido informado?

Remedio: Haga su debida diligencia y sea responsable de su entrega. ¿Un defecto regresó por no tener suficiente información o que no es un error? Puede que no siempre sea culpa del equipo de desarrollo. No es que no quieran ser dueños de los problemas de la aplicación. Podría ser un verdadero lío del equipo de control de calidad. No dejes que suceda.

# 2) Corriendo

Hagamos esto con unejemplo.

A continuación se muestra una captura de pantalla de OpenEMR crear pantalla de paciente. Es un sistema de gestión hospitalaria de código abierto.

Esta pantalla permite al usuario ingresar la fecha de nacimiento del paciente a través de una función de calendario. Lo que no hace es restringir la entrada a elegir del calendario. Lo que quiero decir es que puede elegir la fecha de nacimiento como, por ejemplo, '31 de marzo de 1983' en el calendario. Luego cámbielo a “31-Feb-1983”.

función-calendario-open-emr

abrir-emr-error-adivinar

¿Por qué el 31 de febrero? Para implementar adivinar error e intente un dato negativo en el campo; cuál es el objetivo de las pruebas, ¿no?

Una vez hecho esto, hago clic en 'Crear paciente'. Dado que la fecha no es válida, espero que el sistema muestre un error y no cree el paciente. Pero eso no sucede. Crea al paciente como se muestra a continuación.

Tenga en cuenta los campos Edad y Fecha de nacimiento en la siguiente pantalla:

probador-de-prueba-openemr

Al realizar la prueba, puede intentar esto varias veces y decidir que:

  • Es un error.
  • Es reproducible.
  • No es un duplicado (consulte con su equipo para confirmar)
  • Conoces la descripción exacta del problema.
  • Además, conoce los pasos exactos que lo hacen posible.

Ahora que tiene la materia prima, está listo para comenzar.

Empieza a denunciarlo. Asignar la gravedad del defecto es un paso obligatorio y su equipo podría estar usando algo similar al siguiente tabla para referencia:

Gravedad Impacto
1 (crítico) • Este error es lo suficientemente crítico como para bloquear el sistema, causar daños en los archivos o causar una posible pérdida de datos.
• Provoca un retorno anormal al sistema operativo (aparece un mensaje de falla o falla del sistema).
• Hace que la aplicación se cuelgue y requiera reiniciar el sistema.
2 (alto) • Causa una falta de funcionalidad vital del programa con solución.
3 (medio) • Este error degradará la calidad del sistema. Sin embargo, existe una solución alternativa inteligente para lograr la funcionalidad deseada, por ejemplo, a través de otra pantalla.
• Este error evita que se prueben otras áreas del producto. Sin embargo, otras áreas se pueden probar de forma independiente.
4 (bajo) • Hay un mensaje de error insuficiente o poco claro, que tiene un impacto mínimo en el uso del producto.
5 (cosmético) • Hay un mensaje de error insuficiente o poco claro que no tiene ningún impacto en el uso del producto.

Dado que este defecto no bloquea el sistema ni bloquea una funcionalidad vital o impide que se prueben otras áreas de la aplicación, podríamos optar por 'Bajo'.

¿Se ve bien?

EQUIVOCADO. Según los datos del paciente, todas las vacunas y otros recordatorios están vencidos. Esto puede ser correcto o no. Además, para un paciente, su edad determina si ve a un pediatra o un médico general, etc.

Afecta las dosis de los medicamentos y muchas otras áreas de tratamiento que quizás ni siquiera conozcamos.

recordatorio-clínico-abierto-emr

Entonces, voy a ir con 'Alto'. Estoy de acuerdo en que es poco probable que el personal del hospital ingrese incorrectamente la fecha de nacimiento de un paciente. Pero que sea un factor que influya en la prioridad de cuándo solucionar el problema.

Mi trabajo como evaluador es asegurarme de comunicar la gravedad del problema lo mejor que pueda.

Remedio: No tenga prisa por informar. Esté 100% seguro de que comprende el impacto de los problemas desde muchos ángulos. Es el mejor valor añadido que podemos ofrecer los evaluadores. No solo estamos diciendo: 'Algo no está funcionando'. También decimos: 'Esto es lo que sucederá si esto sigue sin funcionar'. Toneladas de diferencia, ¿no?

# 3) Falta de creatividad

Los probadores tienen una maravillosa oportunidad de hacer sugerencias para mejorar el software.

En tus Herramienta de gestión de defectos también, puede enviar un defecto del tipo 'Sugerencia de mejora'. Aquí es donde puede ser creativo.

Remedio: Piensa fuera de la caja. Si cree que a una determinada característica le falta un factor 'sorpresa' y sabe cómo incorporarlo, presente la idea. En el peor de los casos, podría ser rechazado y eso está bien. Lo importante es intentarlo.

Además, use este superpoder con precaución. Trate de no hacer comentarios como 'Odio el color del banner, cámbielo'.

Aquí hay un buenejemplode una sugerencia de mejora que encontré: Reemplazo de 'Enviar correo electrónico al concesionario' con la opción 'Chatear con el concesionario' en el sitio de un concesionario de automóviles. Se prevé que convierta más tráfico en ventas.

¡Ojalá fuera tan creativo! Pero, tal vez todos podamos trabajar para lograrlo.

Aquí tienes una bonificación. Una lista de verificación para liberarse de estos malos hábitos:

1. ¿Mi título transmite el problema de forma clara y concisa?
Por ejemplo:“Crear paciente no funciona” no es un buen título. 'Crear paciente falla incluso cuando todos los campos de entrada contienen valores correctos' es.

2. ¿Cuál es la tasa de reproducibilidad?
En otras palabras, ¿sucede siempre? ¿Conozco la secuencia exacta de pasos que repetirán el problema?

3. ¿Este problema es específico de la plataforma, el navegador o el usuario?

4. ¿Están completos los pasos y lo llevan a su problema?

5 . ¿Tengo una captura de pantalla incluida?

6. ¿Necesito anotar mi captura de pantalla para resaltar áreas en particular?

7. ¿Es descriptivo el nombre del archivo de imagen adjunto?
No uses algo como 'Untitled.jpg'. Dale un nombre descriptivo.

8. ¿Incluí los datos de la prueba?
Por ejemplo:Para un defecto en un módulo de administración que necesita credenciales de autorización, inclúyalas. El equipo de desarrollo puede tener o no acceso al entorno de control de calidad. No quiere una demora y un seguimiento de algo tan básico como eso.

9. ¿Puedo dar otros detalles para reforzar mi defecto?
(Ejemplo:una referencia al FRD o una conversación con el cliente, etc.)

10. ¿Entiendo la gravedad del problema desde diferentes perspectivas?

11. ¿Conozco la causa raíz del problema? En caso afirmativo, ¿tengo pruebas (tal vez archivos de registro) y puedo incluirlas? Tenga en cuenta que es posible que no siempre sepa esto o necesite saberlo. Pero si lo hace, no está de más incluirlo.

12. ¿El informe de defectos está libre de problemas de gramática, formato, ortografía y puntuación?

las mejores aplicaciones de espionaje de teléfonos celulares para Android

13. ¿Conozco alguna forma de mejorar el producto?

¿Estás pensando que esto lleva mucho tiempo? Bueno, una vez que se convierta en un hábito, ya no lo será.

Arraigo para mejorar informe de defectos rutinas!

Sobre el Autor: Este artículo fue escrito por Swati, miembro del equipo de STH.

No dude en publicar sus consultas / comentarios a continuación.

Lectura recomendada

^