Gestión de evidencias de prueba: capturas, logs y documentación reproducible

Qué es una evidencia de prueba y por qué debe ser “reproducible”

Una evidencia de prueba es cualquier artefacto verificable que demuestra qué se ejecutó, con qué datos, en qué entorno y cuál fue el resultado observado. En proyectos ágiles, la evidencia no solo “prueba” un resultado: también permite reproducir un hallazgo, acelerar el diagnóstico y sostener auditorías internas/externas. La regla práctica es: si otra persona no puede repetir el resultado con tu evidencia, la evidencia es insuficiente.

Principios de una evidencia útil

• Contextual: identifica entorno, versión, usuario/rol, fecha/hora, build, feature flag.
• Completa: incluye lo necesario para repetir (pasos, datos, request/response, logs).
• Íntegra: no editable o con control de cambios; conserva metadatos.
• Trazable: enlazada a la ejecución y, si aplica, al bug y al requisito.
• Proporcional: el nivel de evidencia se ajusta a criticidad y tipo de prueba.

Estándares: qué capturar según el tipo de prueba

UI Web (manual o automatizada)

• Capturas de pantalla: estado previo, acción clave, estado posterior y mensaje de error. Incluye URL visible y, si aplica, el identificador de sesión.
• Video (recomendado en fallos intermitentes): desde el inicio del flujo hasta el fallo; evita recortes que oculten pasos.
• Console logs: errores y warnings relevantes; exporta el log completo del intervalo del fallo.
• Network traces: HAR o export de red con request/response, status codes, timings; útil para 4xx/5xx, CORS, timeouts.
• Datos de entorno: navegador/versión, SO, resolución, idioma, zona horaria, cookies/almacenamiento si es relevante.

API (manual con Postman/cURL o automatizada)

• Request completo: método, endpoint, query params, headers, body/payload.
• Response completa: status code, headers, body, tiempos.
• Correlación: request-id, trace-id, correlation-id si existen.
• Logs del servicio (si accesibles): extracto con timestamp y correlación.
• Contrato esperado: esquema/validaciones (por ejemplo, campos obligatorios, tipos, límites).

Móvil (Android/iOS)

• Capturas y video: con indicador de versión de app y pasos visibles.
• Logs del dispositivo: Logcat (Android) o Console/Device logs (iOS), filtrados por paquete/app y ventana temporal del fallo.
• Información del dispositivo: modelo, SO, versión, red (Wi‑Fi/4G), permisos otorgados, estado de batería (si relevante).
• Network capture: proxy (si permitido) o trazas de red del framework; especialmente para fallos de backend.

Pruebas no funcionales (si aplican a tu alcance)

• Rendimiento: métricas (p95/p99), configuración de carga, dataset, gráficos exportados, logs de errores.
• Seguridad: evidencia debe evitar exponer secretos; captura hallazgos con redacción (masking) y referencia a la política interna.

Cómo nombrar evidencias: convención consistente y buscable

Define una convención que permita encontrar evidencias sin abrirlas. Debe incluir al menos: identificador de ejecución o bug, tipo de evidencia, fecha/hora y contexto.

Plantilla recomendada

{PROY}-{ID}__{ARTEFACTO}__{PLATAFORMA}__{ENTORNO}__{YYYYMMDD-HHMM}__v{N}.{ext}

Ejemplos:

• PAY-431__screenshot__web__stg__20260204-1015__v1.png
• PAY-431__video__android__stg__20260204-1015__v1.mp4
• PAY-431__network__web__stg__20260204-1016__v1.har
• PAY-431__api_request_response__stg__20260204-1017__v2.txt

Reglas de oro de nombrado

• Sin espacios (usa guiones o guion bajo).
• Versiona (v1, v2) si reemplazas evidencia.
• Un artefacto = un propósito: no mezcles múltiples fallos en un mismo archivo.
• Evita datos sensibles en nombres (emails, tokens, números de tarjeta).

Cuándo adjuntar evidencias y dónde enlazarlas en Jira

Para mantener trazabilidad sin sobrecargar tickets, adjunta evidencia en el punto donde se consume: la ejecución (resultado de prueba) y el bug (si hay defecto). La evidencia “primaria” debe vivir en un solo lugar y el resto debe referenciarla.

Momento de adjuntar

• En el momento del resultado: al marcar una prueba como Fail/Blocked, adjunta evidencia mínima obligatoria.
• Antes de escalar: si vas a abrir un bug, asegura que la evidencia ya está lista (evita “bug sin reproducción”).
• Al detectar intermitencia: agrega video + logs + red, aunque el fallo “desaparezca”.

Enlace recomendado entre ejecución y bug

• Desde la ejecución: agrega el enlace al bug creado (por ejemplo, relación “is caused by / causes” o la que use tu equipo).
• Desde el bug: referencia la ejecución específica (ID o enlace) donde falló, y adjunta o enlaza la evidencia primaria.
• Evita duplicar: si la evidencia está adjunta a la ejecución, en el bug coloca un enlace directo a esa ejecución y adjunta solo lo adicional (por ejemplo, logs del backend).

Práctica útil: “Evidencia primaria” vs “Evidencia de soporte”

• Primaria: prueba visual o técnica del fallo (screenshot/video + request/response o HAR).
• Soporte: logs extendidos, métricas, dumps, archivos de configuración, comparativos.

Nivel de evidencia según criticidad y tipo de prueba

No todos los fallos requieren el mismo paquete de evidencia. Define niveles para estandarizar expectativas y reducir fricción.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Regla práctica: si el bug es P0/P1 o bloquea release, apunta a L2 como mínimo; si es intermitente o no se reproduce en otro entorno, sube a L3.

Estructura de reporte reproducible (plantilla lista para copiar)

Usa esta estructura en la descripción del bug o en un comentario de la ejecución fallida. Mantén el formato consistente para que QA/Dev/PO lo consuman rápido.

Plantilla para UI (Web/Móvil)

Resumen observado:

• Resultado actual: qué ocurrió (mensaje exacto, pantalla, comportamiento).
• Resultado esperado: qué debía ocurrir (criterio verificable).

Contexto:

• Entorno: dev/stg/prod (y URL/base).
• Build/versión: app vX.Y.Z / commit / build number.
• Usuario/Rol: rol (sin exponer credenciales); si aplica, tenant/cliente.
• Plataforma: navegador+versión o dispositivo+SO.
• Fecha/hora: con zona horaria.

Pasos para reproducir (exactos):

1. Precondición: estado inicial (por ejemplo, “usuario con carrito con 1 ítem”).
2. Paso 1…
3. Paso N…

Datos usados:

• IDs/valores de prueba (enmascarados si son sensibles).
• Feature flags / configuración relevante.

Evidencia adjunta/enlazada:

• Screenshot(s): archivo(s) + qué muestran.
• Video: archivo + rango temporal.
• Console logs: archivo + timestamp del error.
• Network trace (HAR): archivo + request relevante.

Plantilla para API (incluye comparativos)

Resumen observado:

• Resultado actual: status code, error code, mensaje, campo inválido.
• Resultado esperado: status code esperado y contrato (campos/valores).

Contexto:

• Base URL: https://api.stg.ejemplo.com
• Servicio: nombre/módulo
• Versión: build/commit
• Autenticación: tipo (Bearer/OAuth), sin pegar tokens reales

Request:

• Método: POST
• Endpoint: /v1/payments
• Query params: ?expand=...
• Headers: Content-Type, Accept, X-Request-Id (enmascara secretos)
• Payload:

{ "amount": 1000, "currency": "USD", "source": "card" }

Response:

• Status: 500
• Headers: date, content-type, x-trace-id
• Body:

{ "error": { "code": "INTERNAL", "message": "Null reference" } }

Comparativo (Esperado vs Actual):

Correlación y logs:

• x-request-id / trace-id: 12345-abc
• Log relevante: adjunto (intervalo HH:MM:SS–HH:MM:SS)

Guía práctica paso a paso: crear un “paquete de evidencia” sin huecos

Paso 1: captura el contexto antes de repetir

• Anota entorno, versión/build, usuario/rol y hora.
• Si es UI: registra navegador/dispositivo y resolución.
• Si es API: registra base URL y método/endpoint.

Paso 2: reproduce una vez con captura activa

• UI: inicia grabación de video si el flujo es largo o el fallo es intermitente.
• Web: abre DevTools y deja listas pestañas Console y Network.
• Móvil: inicia captura de pantalla/video y logging del dispositivo.

Paso 3: guarda artefactos “mínimos” y “técnicos”

• Captura pantalla del error (incluye URL o pantalla previa).
• Exporta console logs (o copia el bloque con timestamp).
• Exporta HAR o identifica la request fallida y guarda detalles.
• En API: exporta request/response (Postman collection o cURL + salida).

Paso 4: redacta el reporte reproducible con datos exactos

• Escribe pasos numerados y deterministas (evita “hacer clic varias veces”).
• Incluye datos de prueba (IDs) y precondiciones.
• Agrega comparativo esperado vs actual cuando haya contrato/validación.

Paso 5: adjunta y enlaza en Jira con trazabilidad

• Adjunta evidencia primaria en la ejecución fallida o en el bug (según tu estándar), pero evita duplicar.
• Enlaza ejecución ↔ bug.
• En el bug, referencia el nombre exacto de archivos adjuntos y qué contienen.

Controles para evitar evidencias incompletas

Checklist obligatorio por tipo de prueba

Implementa un checklist que el tester complete antes de marcar un fallo como listo para triage. Puedes usar una lista en la descripción o un campo/plantilla de comentario.

• UI: pasos exactos + captura + entorno + (console o network si aplica) + datos usados.
• API: endpoint + método + headers relevantes + payload + response + status + correlación.
• Móvil: dispositivo/SO + versión app + video o capturas + logs del dispositivo.

Reglas de “rechazo” en triage (Definition of Ready para bugs)

• Sin pasos reproducibles o con ambigüedad (“a veces falla”).
• Sin entorno/versión.
• Sin evidencia primaria para P0/P1.
• Sin request/response en bugs de API o sin HAR en bugs de UI con fallo backend.

Plantillas y campos para estandarizar

• Plantilla de descripción para bugs (UI/API/Móvil) pegable en Jira.
• Campos estructurados (si tu instancia lo permite): Entorno, Build, Plataforma, Severidad, Reproducibilidad (Always/Sometimes/Rare).
• Automatización: al crear un bug desde una ejecución fallida, prellenar entorno/build y copiar enlaces a evidencias adjuntas.

Controles para asegurar auditabilidad e integridad

Integridad de archivos y cadena de custodia

• Evita editar capturas o videos; si debes resaltar, conserva el original y adjunta una versión anotada separada.
• Conserva metadatos: fecha/hora de creación, dispositivo, versión.
• Hash opcional (para auditorías estrictas): registra SHA-256 del archivo en un comentario del ticket.

Gestión de acceso y retención

• Permisos: limita quién puede ver evidencias con datos sensibles.
• Retención: define cuánto tiempo se conservan evidencias (por ejemplo, por release o por trimestre) y dónde se almacenan (adjunto en Jira o repositorio externo).
• Redacción (masking): oculta tokens, IDs sensibles, PII en payloads y logs; documenta qué se enmascaró.

Trazabilidad verificable

• Todo bug debe enlazar al menos a una ejecución donde se observó.
• Toda ejecución fallida debe tener evidencia adjunta o enlace a evidencia primaria.
• Los artefactos deben ser buscables por convención de nombre e identificadores (PROY-ID).