Bloodrabbid/qa-software-testing

Pruebas de Software: UI, API, Manuales y Automatizadas

Base: la guía «La calidad lo decide todo: guía completa de pruebas de software» (Román Surkov). Todo lo marcado con [fuera del libro] proviene de otras fuentes (lista al final) o de prácticas generalmente aceptadas. Preséntalo como un complemento, no como la postura del autor.

Cuándo aplicarlo

• «Prueba una funcionalidad / pantalla / aplicación / API», «elabora una lista de verificación / casos de prueba», «documenta un error».
• Revisión de especificaciones técnicas, maquetas de Figma o Swagger antes del desarrollo (shift-left).
• Selección de qué y cómo automatizar; escenario de carga; informe de preparación del lanzamiento.
• Para videojuegos, usa el skill qa-game-testing; de aquí toma la base general (diseño de pruebas, artefactos).

Paso 0. Determina el modo de trabajo

Solicitud	Qué proporcionar
Hay especificaciones técnicas / maqueta, aún no hay código	Revisión de requisitos (paso 1) + lista de verificación escrita de antemano
«Prueba esto» sin detalles	Desglose según «БЛУГИД с ПК» (paso 2) → lista de verificación → casos de prueba para lo complejo
Sitio web / aplicación en funcionamiento disponible	Ejecución de comprobaciones, informes de errores, TRR final
API / Swagger / cURL	BINMEN + POISED (paso 6), colección de solicitudes
«¿Qué automatizar?», pruebas inestables, Playwright	Plan según la pirámide y reglas de pruebas automatizadas (paso 8)
Verificación de seguridad de API	Matriz OWASP API Top 10 (paso 6)
Funcionalidad de LLM (chatbot, generación)	Capas de verificación y conjunto de referencia (paso 9)
Pruebas libres de una nueva funcionalidad	Cartas de sesiones SBTM + SFDIPOT (paso 2)

Primero las comprobaciones positivas (happy path), luego las negativas. En las positivas, las comprobaciones se pueden combinar; en las negativas, un parámetro no válido por comprobación.

Paso 1. Pruebas de requisitos (shift-left)

El error se encarece según la regla 1–10–100: corregir en la especificación cuesta 1, en el código cuesta 3–8 veces más, encontrado por QA cuesta 20–80 veces, en producción cuesta 100+ veces. Por lo tanto, empieza por el documento.

Criterios de un buen requisito (por cada infracción, un comentario en el documento): integridad (se describen los casos extremos y errores), coherencia (el texto no contradice la maqueta), claridad, corrección, comprobabilidad («¿cómo lo verificaré?»), atomicidad (una idea).

Palabras basura: «rápido», «conveniente», «intuitivo», «flexible», «adecuado», «cuando sea necesario». Reescríbelas en términos medibles: «búsqueda rápida» → «resultados ≤ 1,5 s con 1000 solicitudes simultáneas».

Si no hay especificaciones técnicas, el resultado esperado se obtiene de: maquetas y prototipos → competidores → leyes y reguladores (GDPR, PSD2) → mejores prácticas y sentido común (validación de email, rate-limit, máscaras de teléfono) → conversación con el desarrollador o analista.

Cómo analizar a fondo los requisitos: preguntas sobre límites (longitud máxima, caracteres prohibidos, pérdida de conexión, dos usuarios haciendo clic al mismo tiempo); diagrama de flujo o mapa mental de la ruta (una flecha que se pierde en el vacío es un escenario no descrito); casos de prueba directamente durante la lectura (si no se puede escribir un caso, se ha encontrado un error en la especificación).

Oráculos FEW HICCUPPS [fuera del libro, M. Bolton y J. Bach] — de qué otra manera demostrar que el comportamiento es problemático si no hay especificación o está incompleta. El producto debe ser coherente con: Familiar problems (no repite tipos de errores conocidos), Explainability (el comportamiento se puede explicar), World (no contradice la realidad), History (versiones anteriores), Image (imagen de la empresa), Comparable products (análogos), Claims (declaraciones: especificaciones técnicas, publicidad, ayuda), User desires (deseos razonables del usuario), Product (consigo mismo: una acción, un comportamiento en todas partes), Purpose (propósito), Statutes and standards (leyes y estándares). En el informe de error, nombra el oráculo: «contradice la versión anterior», «contradice la ayuda» — así es más fácil discutir que «esto no es un error».

Característica faltante: si la función no está y tampoco está en las especificaciones, no es un error, sino una Mejora / Solicitud de función. Las disputas se resuelven con la matriz de funcionalidad: Web — sí, iOS — sí, Android — no.

Paso 2. Desglose de la tarea «Prueba esto»

Las pruebas funcionales responden a la pregunta «QUÉ hace», las no funcionales a «CÓMO». Los vectores no funcionales se revisan con la nemotecnia «БЛУГИД с ПК»:

• Б — seguridad (XSS, inyecciones SQL, derechos de acceso)
• Л — localización
• У — usabilidad
• Г — interfaz gráfica (GUI)
• И — instalación (solo lo que se instala: escritorio, móvil, consolas)
• Д — accesibilidad (a11y)
• П — rendimiento (del cliente y del servidor)
• К — configuración y compatibilidad

Añade los recorridos exploratorios de Whittaker para la búsqueda libre: guía turístico (funcionalidades principales), callejones traseros (configuraciones poco comunes), mensajero (un objeto a través de todos los estados), dinero (carrito y pago), noctámbulo (tareas en segundo plano), recogedor de basura («Cancelar», «Restablecer»), insistente (100 repeticiones de una misma acción), barrio malo (módulos históricamente problemáticos), museo (código antiguo que no se ha tocado en mucho tiempo).

Qué hay en el producto — SFDIPOT [fuera del libro, HTSM de J. Bach]: Structure (de qué está compuesto: archivos, módulos, compilaciones), Function (qué hace), Data (qué se ingresa, almacena, genera; vacío, enorme, corrupto), Interfaces (UI, API, importación/exportación, integraciones), Platform (SO, navegador, hardware, servicios externos), Operations (cómo se usa realmente: escenarios frecuentes, usuario inexperto y malintencionado), Time (timeouts, paralelismo, orden de eventos, zonas horarias, trabajo prolongado). Repasa las siete palabras y obtendrás un mapa de cobertura que БЛУГИД no proporciona.

Pruebas exploratorias por sesiones (SBTM) [fuera del libro, J. y J. Bach]. Sesión de 60–90 minutos sin distracciones, con una carta: «Explorar <área> usando <herramientas, técnicas, datos> para descubrir <qué queremos saber>». Al final, una hoja de sesión: qué se cubrió, errores encontrados, preguntas, riesgos, proporción de tiempo dedicado a pruebas / documentación de errores / configuración del entorno, y un breve análisis con el líder. Así, las pruebas libres se vuelven reportables: se ve qué se verificó y qué queda.

Paso 3. Técnicas de diseño de pruebas

Orden: primero un esqueleto con EP + BVA + tablas de decisiones, luego refuerzo con Error Guessing.

1. Clases de equivalencia (EP): un valor de cada clase válida e inválida.
2. Valores límite — solo 3BVA: en cada límite tomar min-1, min, min+1 (y lo mismo para max). 2BVA pasa por alto un error tipográfico del operador X == 10 en lugar de X >= 10: los puntos 9 y 10 pasan, pero 11 falla. Ejemplo: acceso de 18 a 100 años → -1, 0, 1, 16, 17, 18, 99, 100, 101. Para dinero, el paso es la unidad mínima (0,01 €).
3. Combinatoria: 1-wise (≈50% de errores, exprés), pairwise — estándar (70–90%), 3-wise para fintech (≈95%), recorrido completo solo para sistemas críticos. Nunca construyas una matriz pairwise en la cabeza: genérala con una herramienta (PICT, si está instalado, o pip install allpairspy --break-system-packages) y verifica con un script que se cubran todos los pares. Dónde aplicarlo: filtros de catálogo, calculadoras, pago × envío, exportación (formato × codificación × delimitador). Para la compatibilidad entre navegadores, no usar pairwise (ver paso 5).
4. Tablas de decisión: cuando en las especificaciones hay muchos «si / y / o / excepto», de 2 a 5 condiciones binarias. Tacha las combinaciones imposibles y fusiona las reglas con el mismo resultado en un solo caso. Lugares típicos: descuentos y códigos promocionales, matriz de roles, campos de formulario dependientes (persona jurídica → TIN y KPP obligatorios), estados del pedido.
5. Estados y transiciones: todo lo que tiene un ciclo de vida y timeouts. Verifica las transiciones no permitidas, la expiración del timeout (una reserva sin pago vuelve a «Disponible»), la naturaleza de un solo uso de los tokens (restablecimiento de contraseña con un enlace antiguo), la interrupción en cada paso.
6. Error Guessing — catálogo de errores comunes:
   • entrada sucia: solo espacios, espacios alrededor del email, U+200B, emojis, comillas, jeroglíficos, 10 000 caracteres desde el portapapeles;
   • repeticiones y condiciones de carrera: triple clic en «Pagar», «Atrás» después de una transacción, dos personas compran el último artículo;
   • interrupciones: pérdida de red al 99%, cierre de pestaña durante la adquisición;
   • fechas y números: 29.02 en año no bisiesto, fecha de nacimiento en el futuro, 00.00.0000, cantidad −1, 0, 999 999;
   • entorno: sesión caducada después de 3 horas de inactividad, .exe con extensión .jpg, archivo de 500 MB.

Paso 4. Artefactos

Lista de verificación (ID, verificación, estado) — por defecto. Caso de prueba — para lógica compleja, onboarding y entrega para automatización.

Campos de un caso de prueba: ID, nombre, prioridad, precondición (se completa siempre), pasos, datos de prueba, resultado esperado; después de la ejecución: resultado real y estado (Passed / Failed / Blocked / Skipped).

Reglas: en los pasos solo las acciones del evaluador, las reacciones del sistema van en el resultado esperado; los pasos son atómicos («ingresar email», «ingresar contraseña», «hacer clic en Iniciar sesión» — tres pasos); un caso = una verificación; los casos no dependen unos de otros (la preparación va a la precondición o se hace a través de la API); la desglose es razonable, sin «mover el ratón»; prioridad High — dinero y autorización, Low — cosméticos, el resto (≈80%) Medium.

Suite de pruebas — carpeta por módulo con suites anidadas por funcionalidades; las verificaciones comunes del módulo están en la raíz de la suite. Ejecución de pruebas — ejecución de un conjunto en una compilación y entorno específicos con estados. Plan de pruebas (a solicitud): alcance (incluido / excluido), estrategia y entorno, criterios de entrada, pausa y salida, recursos y plazos, riesgos con plan B.

Informe de error

Título:      [Dónde] Qué sucede, bajo qué condición
             ejemplo: [Ventana de código promocional] error 500 al ingresar un cupón vencido
Entorno:     Prod/Stage, navegador y versión, SO; para móvil, modelo y versión exacta del SO; URL
Precondición: rol del usuario, página, datos preparados
Pasos:       1. … 2. … (solo acciones, cadena mínima)
Esperado:    concretamente, con referencia a la especificación técnica o maqueta
Real:        lo que sucedió
Severidad:   Blocker / Critical / Major (hay alternativa) / Minor / Trivial — evaluación técnica, la asigna QA
Prioridad:   High / Medium / Low — urgencia para el negocio (lo decide PO/PM)
Reproducibilidad: Always (10/10) o Intermittent (por ejemplo, 1/10)
Solución alternativa: ruta alternativa, si existe
Archivos adjuntos: captura de pantalla para estática, video para dinámica, registros de consola o HAR para backend

Reglas: 1 error = 1 ticket; antes de crearlo, busca duplicados; créalo de inmediato; tono neutral; no inventes una solución en el ticket; escribe de manera que en un mes se pueda verificar la corrección a partir de la descripción. Severidad y prioridad son independientes (error tipográfico en el logotipo: Trivial / Immediate).

Informe de resultados de pruebas (TRR)

Mínimo de relleno, máximo de números y una recomendación clara Go / No-Go:

INFORME DE PRUEBAS DE LA COMPILACIÓN vX.Y
Se planificaron N casos: Passed a (a%) · Failed b (b%) · Blocked c (c%)
Defectos: BUG-… — resumen (prioridad) [enlace] …
Bloqueado: qué bloque y por qué errores
Recomendación de QA: NO se recomienda el lanzamiento / se recomienda con condiciones …

Paso 5. UI: formularios, GUI, usabilidad, accesibilidad, compatibilidad, localización

Formularios y campos de entrada

• Texto: valor válido; campo obligatorio vacío; exactamente max; max+1; caracteres especiales ' " < > / ; : @ # $ % ^ & * ( ) _ +; emojis (fallo en utf8mb4); solo espacios, espacios iniciales, finales e internos (se espera trim); mezcla de cirílico, latino, jeroglíficos y RTL; F5 conserva la entrada (excepto contraseña y captcha); el doble clic en «Enviar» no envía dos solicitudes; U+200B.
• Contraseña: enmascaramiento; se borra al recargar y en caso de error; verificación de contraseña débil y coincidencia con el inicio de sesión o email; pegar desde el portapapeles y el administrador de contraseñas; el «ojo» cambia password ↔ text.
• Selección y carga: valores predeterminados razonables (el consentimiento no está marcado de antemano — GDPR); el clic en la etiqueta alterna la casilla de verificación; «seleccionar todo / deseleccionar todo»; grupo de botones de opción obligatorio; extensiones prohibidas (.exe, .php), archivo de 0 bytes y 100 MB+, barra de progreso.
• UX de validación: verificación inline al perder el foco (blur), lo ingresado no se descarta al mostrar error, el campo se resalta y junto a él el motivo con CTA; el formato se sugiere de antemano («DD.MM.AAAA»); un campo = un valor; pantalla de éxito con número, estado y siguiente paso; «Atrás» en un formulario de varios pasos conserva los datos o está explícitamente prohibido.
• Más БЛУГИД: Tab / Shift+Tab / Enter, Safari y móvil, traducciones de errores, XSS, SQL, CSRF, rate limit.

GUI: verificación con la maqueta (Figma + DevTools)

Empieza por los Componentes Comunes: una corrección en un componente común arregla decenas de pantallas. Tamaños: extensión Pixel Measurement (ancho «menor que la maqueta» con DevTools abierto: adaptabilidad, no error). Fuentes y colores: Elements → Computed (font-size, background-color → HEX). Espaciado: Option/Alt en Figma contra Box Model. Animaciones: Command Palette → Show Animations, ralentizar al 10–25%. Superposición: PerfectPixel al 50% de opacidad. Una diferencia de 1 px no es un error (redondeo subpíxel), si el diseño no se ha desconfigurado.

Usabilidad

Verifica según las 10 heurísticas de Nielsen: estado del sistema, lenguaje del usuario, control y Undo, estándares de la plataforma (HIG / Material), prevención de errores, reconocimiento en lugar de recuerdo, aceleradores, minimalismo, errores comprensibles, ayuda. Para público adulto: fuente no menor de 12 pt, contraste, objetivos grandes. No rompas los patrones nativos: doble toque, gestos del sistema en el borde de la pantalla. Cancelar con «Deshacer» durante 5 segundos es mejor que el diálogo «¿Está seguro?».

Accesibilidad (WCAG, POUR)

Ejecución rápida: Lighthouse (solo Accesibilidad) → axe DevTools → IBM Equal Access → ANDI (orden de Tab nombres de elementos) → contraste (AA ≥ 4.5:1, AAA ≥ 7:1). Texto sobre imagen o degradado verifícalo nuevamente con el cuentagotas de DevTools: los escáneres toman el color de la etiqueta vecina. Manualmente: todo el trabajo sin ratón, foco visible y no superpuesto, alt en imágenes informativas, nada parpadea más de 3 veces por segundo, se respeta prefers-reduced-motion, lector de pantalla (NVDA / VoiceOver). Simulaciones: Web Disability Simulator.

Compatibilidad

Construye la matriz basándote en datos: tu propio análisis → estadísticas regionales → StatCounter (e informa sobre el riesgo de cobertura insuficiente). Observa los ingresos por plataforma, no solo el tráfico. Descarta la cola < 0,5%. Agrupa por motor: Chrome y Edge en Windows son un mismo Chromium; todos los navegadores en iOS son WebKit, pero Safari en iOS pruébalo por separado (tiene sus propios errores de maquetación). Distribuye la regresión proporcionalmente a las cuotas (200 casos × cuota del grupo), no como pairwise «navegador × caso» (eso serían 1400 ejecuciones). La falta de dispositivos se soluciona con emuladores/simuladores, pero verifica los resultados con dispositivos reales.

Consideraciones adicionales

• Localización: verifica que las traducciones no se corten (texto en alemán o ruso en UI en inglés), formatos de fecha, números y moneda, direcciones postales, husos horarios, nombres de países en listas desplegables, plurales y géneros (unidades, días restantes), caracteres RTL.
• Pruebas de instalación/desinstalación: primera instalación, actualización desde la versión anterior, instalación limpia después de eliminar los datos del usuario, instalación en diferentes discos, con espacio insuficiente, interrupción de la instalación a la mitad, desinstalación con eliminación de datos del usuario y sin ella.
• Pruebas de rendimiento (enfoque general): carga de la página (< 3 s en 3G), comportamiento con muchas pestañas, congelación de la UI durante tareas pesadas (procesamiento de un archivo grande), pérdida de memoria al cambiar frecuentemente de pantalla, límites del backend: cuántos usuarios pueden estar en la misma pantalla al mismo tiempo.
• Registro de errores: las herramientas que el desarrollador utiliza (Sentry, LogRocket) son para él, no para el evaluador. El evaluador registra los logs de la consola, solicitudes de red (pestaña Network), HAR (archive todas las solicitudes de la página) — esto se adjunta al error.

Paso 6. API (manual y contratos, seguridad)

Objetivo: verificar que la API funciona según la especificación y no permite escenarios peligrosos.

Tipos de pruebas de API

• Pruebas funcionales: el recurso existe y responde según la especificación. Verifica todos los endpoints (GET, POST, PUT, PATCH, DELETE) de todos los recursos.
• Pruebas de contratos (Contract Testing): la respuesta contiene los campos necesarios, sus tipos y formatos. Para esto son útiles las herramientas de validación de esquemas (JSON Schema, OpenAPI validator).
• Pruebas de integración: la API interactúa correctamente con bases de datos, colas de mensajes, servicios externos.
• Pruebas de seguridad: OWASP API Top 10.
• Pruebas de carga: la API soporta la carga esperada sin errores.

Mnemotecnia BINMEN [fuera del libro] para la revisión de una solicitud

• Boundaries (límites de parámetros: valores mínimo, máximo, vacío)
• Interface (tipos de datos: string, number, boolean, array, objeto, nulo)
• Negative (valores negativos, no válidos, parámetros faltantes)
• Missing (falta un campo obligatorio o todo el cuerpo)
• Extra (parámetros adicionales: el sistema no debe fallar por campos no especificados en la especificación)
• Null (null en lugar de un valor: el sistema no debe caerse)

Mnemotecnia POISED [fuera del libro] para la revisión de una respuesta

• Performance (tiempo de respuesta, código de estado 200, 201)
• Output (el formato de la respuesta coincide con la especificación: JSON, XML)
• Incorrect (códigos de estado incorrectos: 200 en lugar de 404, 500 en lugar de 400)
• Schema (el esquema JSON coincide con la especificación)
• Errors (el formato de error es uniforme para todos los errores)
• Data (los datos en la respuesta son correctos)

Matriz OWASP API Top 10 (para pruebas de seguridad)

Riesgo	Qué verificar
API1:2019 Broken Object Level Authorization	El usuario A no ve los datos del usuario B cambiando el ID en la solicitud
API2:2019 Broken Authentication	Fuerza bruta en la autenticación, robo de token, suplantación
API3:2019 Excessive Data Exposure	No se devuelven contraseñas, hashes ni datos sensibles en la respuesta si no son necesarios
API4:2019 Lack of Resources & Rate Limiting	Límite de solicitudes por minuto, timeouts de backend
API5:2019 Broken Function Level Authorization	El usuario normal no llama a endpoints de administrador cambiando el método o la ruta
API6:2019 Mass Assignment	Inserción de campos adicionales en el cuerpo de la solicitud que cambian la lógica
API7:2019 Security Misconfiguration	CORS abierto, método HTTP incorrecto, información de depuración
API8:2019 Injection	Inyección SQL, NoSQL, inyección de comandos en parámetros
API9:2019 Improper Assets Management	Versiones antiguas de la API disponibles, doc, consola
API10:2019 Insufficient Logging & Monitoring	Falta de registro de intentos de autenticación, acciones sospechosas

Pruebas de contratos (Contract Testing)

Verifica que la estructura de la respuesta cumple con el contrato (OpenAPI/Swagger, GraphQL schema). Usa herramientas como Schemathesis (genera casos de la especificación) o Dredd. En CI, las pruebas de contratos se ejecutan en cada PR para que el backend no rompa el frontend.

Esto no es una especificación ni documentación completa de la API. El evaluador trabaja con la especificación ya creada.

Paso 7. Backend: logs, bases de datos, integraciones, colas

El objetivo de las pruebas de backend es asegurarse de que los datos se procesan correctamente, que el sistema tolera fallos de componentes externos y que no hay fugas de memoria ni datos.

Áreas de verificación

• Registro de eventos (logging): errores de backend en logs, estructura unificada, nivel de detalle suficiente, sin datos sensibles en texto claro (contraseñas, números de tarjetas).
• Bases de datos: los datos se escriben y leen correctamente, no hay pérdida de datos durante la migración, índices y transacciones funcionan, sin bloqueos ni interbloqueos.
• Integraciones: llamadas a API externas, pérdida de comunicación con un servicio externo: el sistema debe manejarlo (retry, timeout, degradación elegante, error en la UI).
• Colas de mensajes: los mensajes se entregan exactamente una vez, no se pierden al reiniciar, se procesan en orden, la cola puede crecer y el sistema no se cae.
• Tolerancia a fallos: reinicio de servidores, apagado de la base de datos, apagado de Redis, latencia de red — el sistema debe volver a un estado operativo.
• Caché: la caché se invalida después de actualizar los datos, TTL funciona, la caché vacía no rompe el servicio.
• Pruebas de compatibilidad (Compat Test): la versión anterior del frontend (A) funciona con la nueva versión del backend (B) y viceversa. Se verifica en un entorno de Stage con un proxy.

Escenarios típicos

1. El backend maneja la pérdida de conexión con la base de datos y se recupera.
2. El backend rechaza correctamente una solicitud maliciosa (SQLi, XSS en JSON).
3. El backend retorna un error uniforme (código, mensaje, detalles).
4. No hay fuga de memoria después de 10 000 solicitudes (no probar a mano, usar k6 o Artillery).
5. Los logs contienen suficiente información para depurar el error sin acceso directo al servidor.

Paso 8. Automatización de pruebas

Pirámide de automatización

• Nivel 1 (base) — Pruebas unitarias (cobertura ≈70%): lógica de negocio, modelos, utilidades. Las escribe el desarrollador, QA revisa la cobertura.
• Nivel 2 — Pruebas de API (cobertura ≈20%): verificar que los endpoints funcionan según la especificación (contratos, lógica de negocio). Para QA, esta es la capa más fiable y rápida.
• Nivel 3 — Pruebas E2E (cobertura ≈10%): UI (Playwright, Cypress) + integración de todo el sistema. Lentas, inestables — solo para caminos críticos.

Reglas para pruebas automatizadas

1. Independencia: las pruebas no dependen unas de otras. Los datos se preparan a través de API o directamente en la base de datos o mocks.
2. Atomicidad: una prueba verifica una cosa. Si falla, está claro qué se rompió.
3. Aislamiento: después de la prueba, los datos de prueba se limpian (o se utiliza una base de datos transaccional con rollback).
4. Estabilidad: las pruebas no fallan sin motivo (flaky). Las pruebas inestables se excluyen de la ejecución y se investigan.
5. Velocidad: una prueba E2E no debe durar más de 10 segundos con todas las comprobaciones. Una suite completa de E2E debe ejecutarse en < 20 minutos.
6. Legibilidad: las pruebas se escriben de manera que un nuevo miembro del equipo entienda qué se está verificando sin comentarios.

Qué hacer y qué no hacer

• Sí: Escribir pruebas para la lógica de negocio, para escenarios críticos, para verificar estados.
• Sí: Usar Page Object en las pruebas de UI.
• No: Automatizar pruebas de UI sin un backend estable (mock).
• No: Escribir pruebas E2E para lo que ya está cubierto por pruebas de API.
• No: Poner datos de prueba en el código (usar fixtures faker o datos de la base de datos).

Cómo decidir qué automatizar

Prioridad:

1. Happy path de la funcionalidad principal (inicio de sesión, búsqueda, compra, registro).
2. Casos de regresión que antes se rompían a menudo.
3. Cálculos y lógica (tablas de decisión, cálculos).
4. Llamadas a API externas (mocks, pero comprobar que la interacción es correcta).

No automatices:

• Pruebas de GUI puro (colores, fuentes, píxeles) — se rompen con cualquier cambio de diseño.
• Pruebas de desplazamiento, animación, comportamiento del ratón sin una especificación clara.
• Funcionalidades en desarrollo activo (hasta que el contrato se estabilice).

Pruebas inestables (flaky tests)

Señales: la prueba falla en CI, pero pasa en local; falla de vez en cuando sin cambios de código. Causas:

• Dependencia del tiempo y orden de ejecución.
• Dependencia de datos compartidos.
• Condiciones de carrera en la UI (esperar a que un elemento sea visible).
• Dependencia de servicios externos.
• Problemas de red y tiempo de espera.
• Mala gestión del estado (falta de limpieza de data de prueba).

Qué hacer:

1. Añadir esperas explícitas en la UI (no timeouts fijos).
2. Usar mocks para servicios externos.
3. Aislar los datos de prueba.
4. Ejecutar la prueba sospechosa 3 veces en CI; si falla dos de tres, marcarla como inestable y desactivarla.
5. Herramientas: Playwright (retry, trace viewer).

Paso 9. Pruebas de LLM (características basadas en modelos de lenguaje)

Si el producto tiene un chat, generación de texto, clasificación, análisis de sentimientos, resumen u otra funcionalidad basada en LLM, aplícanse capas de verificación adicionales.

Capas de verificación

1. Funcional: ¿El LLM hace lo que el usuario espera? (responde la pregunta, resume correctamente, clasifica el género).
2. Sesgo y seguridad: ¿El modelo genera contenido ofensivo, ilegal o incorrecto? Verificar: sesgo racial/de género, incitación al odio, consejos suicidas, llamadas a la violencia, doxing, spam.
3. Alucinaciones: ¿El modelo inventa hechos, personas, eventos, fechas? Verificar con una base de conocimiento o enlaces.
4. Consistencia: ¿El modelo da respuestas diferentes a la misma pregunta? ¿Se contradice en un diálogo?
5. Formatos y límites: ¿El modelo devuelve JSON si se le pide? ¿Supera el límite de tokens? ¿Ignora las instrucciones de formato?
6. Inyección de prompts (prompt injection): ¿El usuario puede obligar al modelo a ignorar instrucciones y ejecutar acciones no deseadas (emitir un comando, acceder a datos)?

Conjunto de referencia

Prepara 50–100 prompts de prueba que cubran las categorías anteriores. Automatiza la prueba del modelo:

• Verifica la presencia de palabras clave obligatorias, formato JSON, ausencia de palabras prohibidas.
• Usa la salida del modelo como entrada para un script de verificación (p.ej., comprueba la validez del JSON).
• Para verificar alucinaciones, usa una base de hechos (base de conocimiento o un modelo de referencia).

Infraestructura de pruebas de LLM

• Frameworks: LangSmith, DeepEval, RAGAS (para RAG).
• Métricas: precisión, exhaustividad (recall), relevancia, toxicidad.
• Rendimiento: tiempo de respuesta, límite de tokens, coste por solicitud.
• Data drift: ¿las respuestas cambian con el tiempo después de actualizar el modelo?

Nota: Las pruebas de LLM requieren un enfoque probabilístico: las mismas comprobaciones pueden dar resultados diferentes. Documenta los umbrales aceptables (p.ej., exactitud no inferior al 85%).

Paso 10. Gestión y reporte

Ciclo de vida del error

1. Nuevo (New): el error se ha encontrado y registrado.
2. Confirmado (Confirmed): el desarrollador ha confirmado que es un error.
3. En progreso (In Progress): el desarrollador está corrigiendo.
4. Solucionado / Para verificar (Resolved / Ready for QA): el desarrollador ha hecho commit de la corrección.
5. Verificado (Verified): el evaluador ha ejecutado la verificación y el error no se reproduce.
6. Reabierto (Reopened): el error se reproduce después de la corrección o aparece en otro entorno.
7. Cerrado (Closed): el error se cierra después de la verificación exitosa.

Priorización

Severidad (Severity):

• Blocker: el error impide continuar probando (la aplicación no se inicia, el login no funciona).
• Critical: la funcionalidad principal no funciona (no se puede hacer un pedido, no se guardan los datos).
• Major: la funcionalidad funciona, pero con límites severos (los filtros no se aplican, el pago falla a veces).
• Minor: la funcionalidad funciona, pero con desviaciones de la especificación (texto erróneo, diseño ligeramente diferente).
• Trivial: error estético o de traducción que no afecta la funcionalidad (tipografía, espaciado).

Prioridad (Priority) (la decide el product manager):

• High: debe corregirse en esta iteración.
• Medium: debe corregirse, pero puede esperar a la siguiente iteración.
• Low: debe corregirse, pero no antes del próximo trimestre.

Informe de resultados de pruebas (TRR)

Como se describe en el paso 4, el TRR se proporciona al final del ciclo de pruebas. Debe contener:

• Estadísticas de ejecución (planificado / ejecutado / pasado / fallido / bloqueado).
• Lista de errores con enlaces.
• Bloqueos (dependencias, infraestructura, bugs bloqueantes).
• Recomendación (Go / No-Go) con justificación.

Gestión de riesgos

• Para cada funcionalidad, identifica los riesgos (falta de documentación, plazos ajustados, nueva tecnología).
• Para cada riesgo, determina la probabilidad (alta, media, baja) y el impacto (alto, medio, bajo).
• Elabora un plan de mitigación: pruebas adicionales, automatización, revisión de código, formación.

Fuentes

1. Surkov R. «La calidad lo decide todo: guía completa de pruebas de software». 2024.
2. Whittaker J. «Exploratory Software Testing». 2009.
3. Bach J. «Heuristic Test Strategy Model (HTSM)».
4. Bach J., Bach J. «Session-Based Test Management (SBTM)».
5. Bolton M. «FEW HICCUPPS».
6. OWASP API Security Project. «OWASP API Security Top 10».
7. Nielsen J. «10 Usability Heuristics for User Interface Design».
8. WCAG 2.1 (Web Content Accessibility Guidelines).
9. Myers G. «The Art of Software Testing» (técnicas de diseño de pruebas).
10. Beck K. «Test-Driven Development: By Example».
11. Fowler M. «PageObject».
12. Schemathesis (pruebas de API basadas en propiedades).