Defectos y el informe de defecto
En resumen: Un informe de defecto es una carta a alguien que no vio el error. Tiene que poder repetirlo a la primera: pasos cortos, el resultado esperado de la regla y el resultado real del sistema. La gravedad dice cuánto daño hace el defecto, la prioridad cuándo corregirlo; las dos son una valoración y a menudo difieren.
Problema
«El envío no funciona»
El tester escribe en el gestor de defectos: «El envío no funciona. ¡Urgente!». El programador prueba un carrito de 30 € y ve 4,90 €. Prueba con 70 € y ve 0,00 €. Todo bien. Cierra el informe como «no se puede reproducir».
Una semana después un cliente se queja de que pagó envío en un pedido de exactamente 50,00 €. El tester lo vio primero. Pero su informe no daba ni el importe, ni lo que esperaba, ni lo que obtuvo.
La idea
Un informe es una carta a alguien que no estaba allí
Un informe de defecto tiene una sola tarea: que otra persona repita el error a la primera y entienda por qué es un error. Por eso un buen informe tiene:
- un título que dice el error: «El envío es de 4,90 € para un pedido de exactamente 50,00 €», no «El envío no funciona»;
- pasos: el camino más corto hasta el error, con los datos exactos. Ni un paso de más;
- esperado: lo que dice la regla. Envío gratis;
- real: lo que hizo el sistema. 4,90 €;
- entorno: versión, navegador, dispositivo, cuando importan;
- gravedad y prioridad (las siguientes tarjetas);
- un enlace al requisito y al caso de prueba que lo atrapó.
Hay algo que un informe no contiene: quién tiene la culpa. El defecto está en el producto, no en la persona.
Más precisamente, para curiosos
CTFL v4.0.1, sección 5.5, da el contenido típico de un informe: un identificador único, un título con un resumen breve, la fecha, el autor y la organización, el objeto de prueba y el entorno, el contexto (caso de prueba, actividad, técnica), una descripción del fallo que permita reproducirlo y resolverlo, con pasos, registros y capturas, los resultados esperado y real, gravedad, prioridad, estado y referencias. El plan de estudios da también sus objetivos: información para la corrección, una manera de seguir la calidad del producto e ideas para mejorar el proceso.
La idea
La vida de un defecto
Un informe no termina cuando se escribe. Pasa por varios estados:
- Nuevo: lo escribe el tester.
- Abierto: en la clasificación inicial (triage) el equipo lo acepta como defecto y le da una prioridad.
- En curso: el programador encuentra la causa y lo corrige.
- Corregido: la corrección está en la versión para probar.
- Verificado: la prueba de confirmación pasa, y también las pruebas de regresión a su alrededor.
- Cerrado.
Los desvíos importan igual. Rechazado: no es un defecto, el sistema hace lo que dice la regla (entonces quizá la regla está mal, y es una pregunta para el analista). Duplicado: ya está informado. Aplazado: es un defecto, pero no se corregirá ahora. Reabierto: la prueba de confirmación vuelve a fallar.
Más precisamente, para curiosos
Los nombres de los estados difieren entre equipos y herramientas (Jira, Azure DevOps, GitHub Issues). CTFL no prescribe nombres concretos: lo que importa es que el proceso de defectos esté acordado, y que todos sepan qué significa cada estado y quién lo cambia.
Pruébalo
Ordena el camino
Ordena los estados del defecto desde el informe hasta el cierre.
Verificado: la prueba de confirmación pasa, y también las pruebas de regresiónEn curso: el programador encuentra la causa y lo corrigeNuevo: el tester escribe el informeCerradoAbierto: la clasificación inicial lo acepta como defecto y le da una prioridadCorregido: la corrección está en la versión para probar
La prioridad se da en la clasificación inicial, antes de que nadie empiece a trabajar. «Verificado» significa una prueba de confirmación y regresión, no la palabra del programador.
La idea
Gravedad y prioridad no son lo mismo
Las dos se mezclan todo el tiempo:
- La gravedad es cuánto daño hace el defecto: al cliente, al dinero, a los datos. Normalmente la propone el tester, porque vio el daño. Escala: crítica, alta, media, baja.
- La prioridad es lo pronto que hay que corregirlo. La decide el negocio o el dueño del producto, porque depende del plan, de los clientes, de la publicidad. Escala: alta, media, baja.
A menudo difieren. Una falta de ortografía en el nombre de la tienda hace poco daño pero se corrige hoy. Un informe anual equivocado hace mucho daño pero faltan 10 meses para la próxima ejecución.
Las dos son una valoración, no un hecho. Dos buenos testers pueden dar una gravedad distinta, y es normal. Lo que importa es que puedas decir por qué.
Pruébalo
¿Gravedad o prioridad?
Pruébalo
El primer informe
En las tareas de abajo la tienda no está del todo bien. Cada una tiene un error escondido, puesto a propósito en un sistema por lo demás correcto. En el módulo de Gherkin una versión así, con un error, se llama mutante: tus escenarios lo atraparon si fallaron con ella. Aquí el error ya está atrapado. Sabes más o menos dónde está. Tu tarea es el informe.
Cómo funciona la tarea:
- armas los pasos con el vocabulario de pasos de la funcionalidad y escribes los valores;
- Probar ejecuta tus pasos en el sistema con el error y muestra lo que da;
- eliges esperado (lo que dice la regla) y real (lo que viste);
- das una gravedad y una prioridad.
La comprobación ejecuta tus pasos en el sistema con el error (el error tiene que verse ahí) y en el correcto (ahí no debe verse). El título se comprueba solo en parte: no puede estar vacío ni ser «no funciona». La gravedad y la prioridad se comparan con el informe modelo, que ves después de tu intento.
Encuentra un importe con el que se vea el error, y escribe el informe.
con pedidos muy por debajo de 50 €
La regla: El envío es gratis en un pedido desde 50 € (incluidos), si no, cuesta 4,90 €. Un carrito vacío no se puede pedir.
Pasos para reproducirlo
- Todavía no hay pasos. Añádelos desde el vocabulario de abajo.
Los pasos vienen del vocabulario de la funcionalidad, como en los escenarios. Los valores se escriben en el propio paso: el importe como 50,00.
El informe de ejemplo
- Título
- El envío es gratis para un pedido de 30,00 €
- Pasos para reproducirlo
- Dado un carrito de 30,00 €
- Cuando hago el pedido
- Esperado
- el envío es de 4,90 €
- Obtenido
- el envío es gratis
- Gravedad
- alta. El pedido pasa y el cliente está contento, pero la tienda pierde 4,90 € en cada pedido entre 5 € y 50 €, y esos son la mayoría. Nada se ha detenido, así que no es crítico, pero el daño es grande y crece cada hora.
- Prioridad
- alta. El dinero se pierde hoy. Se corrige de inmediato, sin esperar al siguiente lanzamiento planificado.
El error se ve solo entre 5 € y 50 €: por debajo de 5 € tanto el sistema correcto como el que tiene el error cobran 4,90 €, y desde 50 € ninguno cobra nada. Por eso el informe con 3,00 € no reproduce nada. El buen informe tiene dos pasos, y lo esperado es el número de la regla, 4,90 €. «El pedido se acepta» es verdad en los dos sistemas y no muestra la diferencia.
La idea
Cómo encontrar los pasos más cortos
Viste el error después de 12 pasos: añadir, quitar, cambiar la cantidad, introducir un código, quitar el código. El programador no debería tener que pasar por todos. Antes de escribir, acótalo:
- quita un paso y prueba de nuevo. ¿Sigue el error? Entonces el paso no hace falta;
- cambia un valor cada vez. Con 30 € el error está, con 3 € no: así que está en el total, y sabes más o menos dónde está el límite;
- anota los datos exactos. No «algún importe» sino 30,00 €. No «unas cuantas unidades» sino 8 y luego 3.
Esa es también la diferencia entre «en mi máquina funciona» y «corregido a la primera».
Ejercicio
Informes de defecto
1. La tarifa del envío. El error está en el precio del envío de pago.
Escribe un informe con el que el error se corrija a la primera.
en el precio del envío de pago
La regla: El envío es gratis en un pedido desde 50 € (incluidos), si no, cuesta 4,90 €. Un carrito vacío no se puede pedir.
Pasos para reproducirlo
- Todavía no hay pasos. Añádelos desde el vocabulario de abajo.
Los pasos vienen del vocabulario de la funcionalidad, como en los escenarios. Los valores se escriben en el propio paso: el importe como 50,00.
El informe de ejemplo
- Título
- El envío de pago cuesta 4,99 € en lugar de 4,90 €
- Pasos para reproducirlo
- Dado un carrito de 20,00 €
- Cuando hago el pedido
- Esperado
- el envío es de 4,90 €
- Obtenido
- el envío es de 4,99 €
- Gravedad
- baja. El cliente paga 9 céntimos más. El pedido pasa y no se pierde nada: el daño es pequeño.
- Prioridad
- media. Poco daño, pero el precio no es el 4,90 € anunciado: los clientes se quejan, y para la protección del consumidor esto es un precio equivocado. Se corrige en el siguiente lanzamiento, y algunos equipos lo lanzarían de inmediato.
Con 60 € el envío es gratis en los dos sistemas, así que el error no se ve. Hace falta un importe por debajo de 50 €. La gravedad es baja, porque son 9 céntimos. La prioridad es una valoración: el precio anunciado es 4,90 €, y algunos equipos lo corregirían de inmediato. Por eso «alta» también se acepta.
2. La unidad número once. El error está en torno al límite superior del carrito.
Escribe un informe con el que el error se corrija a la primera.
cuando el carrito pasa del límite superior
La regla: En el carrito puede haber como mucho 10 unidades de un producto. Añadir por encima de 10 se rechaza con un mensaje, y el carrito queda igual. Se añade al menos 1 unidad.
Pasos para reproducirlo
- Todavía no hay pasos. Añádelos desde el vocabulario de abajo.
Los pasos vienen del vocabulario de la funcionalidad, como en los escenarios. Los valores se escriben en el propio paso: el importe como 50,00.
El informe de ejemplo
- Título
- El carrito acepta una unidad número 11 de un producto
- Pasos para reproducirlo
- Dado un carrito con 10 unidades del producto
- Cuando añado 1 unidad
- Esperado
- no se permite añadir
- Obtenido
- se permite añadir
- Gravedad
- baja. El cliente se lleva una unidad más que el límite. El límite protege las existencias en una oferta, pero una unidad no las agota, y el total y el pago son correctos.
- Prioridad
- baja. Ocurre pocas veces: solo cuando alguien quiere exactamente 11. Entra en el plan con las demás correcciones pequeñas, salvo que se acerque una oferta.
Con 9 unidades y 1 más el carrito pasa a 10, y el sistema correcto también lo permite. El error está en la 11. Es el ejemplo clásico de gravedad baja y prioridad baja: un error real que puede esperar, salvo que se acerque una oferta.
3. El rechazo que vacía. El error está en lo que queda en el carrito después de un rechazo.
Escribe un informe con el que el error se corrija a la primera.
en lo que queda en el carrito después de un rechazo
La regla: En el carrito puede haber como mucho 10 unidades de un producto. Añadir por encima de 10 se rechaza con un mensaje, y el carrito queda igual. Se añade al menos 1 unidad.
Pasos para reproducirlo
- Todavía no hay pasos. Añádelos desde el vocabulario de abajo.
Los pasos vienen del vocabulario de la funcionalidad, como en los escenarios. Los valores se escriben en el propio paso: el importe como 50,00.
El informe de ejemplo
- Título
- El carrito se vacía cuando añadir pasa del límite de 10 unidades
- Pasos para reproducirlo
- Dado un carrito con 8 unidades del producto
- Cuando añado 3 unidades
- Esperado
- en el carrito hay 8 unidades del producto
- Obtenido
- en el carrito hay 0 unidades del producto
- Gravedad
- media. El rechazo es correcto, pero el cliente pierde las unidades que ya estaban en el carrito y tiene que volver a buscarlas. No se pierde dinero y se puede seguir pidiendo, así que no es alta.
- Prioridad
- alta. Afecta justo a los clientes que compran mucho, y justo en una oferta, cuando más se llega al límite. Muchos desistirán antes de volver a llenar el carrito.
El rechazo es correcto en los dos sistemas, así que «no se permite añadir» no muestra la diferencia. La diferencia está en las unidades que quedan: 8 frente a 0. «Dado un carrito vacío» antes de «Dado un carrito con 8 unidades del producto» es un paso redundante: el segundo anula el primero. La prioridad es alta o media, porque afecta a los clientes que más compran.
Test