Verificación, validación y pruebas de aplicaciones web

Verificación, Validación y Pruebas en Aplicaciones Web: Cómo Evitar Errores Antes de que Paguen los Usuarios

En una aplicación web, los fallos no se limitan a “bugs visibles”. También hay errores de requisitos, incoherencias en reglas de negocio, vulnerabilidades, degradación de rendimiento y comportamientos inesperados cuando el sistema se ejecuta en condiciones reales. Por eso, verificación, validación y pruebas forman un bloque central del desarrollo: permiten asegurar que el software está bien construido y que, además, es el software correcto.

En un stack típico con Node.js, Express y SQLite, estas prácticas se aplican sobre el código, sobre los endpoints HTTP, sobre la base de datos y sobre el comportamiento de la aplicación desde el punto de vista del usuario. La idea no es “hacer pruebas por cumplir”, sino controlar el riesgo: detectar errores cuando corregirlos todavía es barato.

Verificación, validación y pruebas se parecen al control de calidad de una fábrica.

La verificación comprueba que el proceso y las piezas cumplen el plano.

La validación comprueba que el producto sirve para el uso real del cliente.

Las pruebas son los ensayos concretos que demuestran ambas cosas con evidencia repetible.

Verificación, validación y aseguramiento de la calidad

La verificación responde a si el software se está construyendo correctamente respecto a lo especificado. Es un control orientado al proceso y a la coherencia interna: revisiones de código, inspecciones, análisis estático, revisión de documentación, comprobación de que el diseño se está respetando. En web esto incluye, por ejemplo, revisar que una ruta no accede directamente a SQLite saltándose la capa de acceso a datos, o que se aplican validaciones y manejo de errores con consistencia.

La validación responde a si el software construido es el correcto para el usuario. Aquí el centro es el comportamiento en uso real: flujos completos, experiencia de uso, reglas de negocio y criterios de aceptación. En una aplicación web, validar significa comprobar que el usuario puede completar tareas reales y que el resultado es el esperado, no solo que el código “parece correcto”.

El aseguramiento de la calidad (QA) es el conjunto de procesos que hacen que verificación, validación y pruebas se planifiquen y se ejecuten de forma sistemática. Incluye definir qué se va a probar, con qué criterios se considera “aceptable”, cuándo se ejecutan las pruebas, cómo se registran resultados y cómo se corrigen desviaciones. En proyectos web, QA evita que las pruebas dependan del azar o de la memoria del equipo.

Ejemplo Eldoria Chronicles

Antes de entrar en cada tipo de prueba, es imprescindible fijar una idea central. Sin este marco, las pruebas parecen heterogéneas y desconectadas. Con él, todas encajan como partes de una misma estrategia.

El objetivo del conjunto de pruebas no es “probar mucho”, ni cubrir todas las técnicas posibles. El objetivo es reducir el riesgo antes de entregar una feature a los jugadores. Riesgo de fallos técnicos, riesgo de que la funcionalidad no sirva para lo prometido y riesgo de que el propio proceso de desarrollo falle de forma sistemática.

Cada grupo de pruebas existe porque hay un tipo de error distinto que puede arruinar una feature. Ninguna prueba sustituye a otra, porque cada una responde a una pregunta diferente. El orden no es arbitrario: primero se comprueba que el sistema es sólido, después que es útil, y finalmente que el proceso que garantiza ambas cosas es fiable y repetible.

Con esta perspectiva, verificación, validación y QA no son categorías teóricas, sino barreras sucesivas de control que impiden que una feature llegue a producción por azar o confianza ciega.

Mapa de Responsabilidades: Control de Calidad en Eldoria Chronicles

Este mapa no describe herramientas ni tecnologías. Describe un flujo mental: qué se comprueba primero, qué después y con qué objetivo.

Visión General

[DESARROLLO] → [VERIFICACIÓN] → [VALIDACIÓN] → [DESPLIEGUE]
    ↓              ↓               ↓              ↓
  Código       ¿Está bien     ¿Resuelve el    ¿Funciona en
  nuevo        construido?    problema real?  producción?
  
Este esquema resume una idea clave:

1. Primero escribes código.
2. Luego compruebas que está bien escrito (verificación).
3. Después compruebas que hace lo que el jugador necesita (validación).
4. Solo entonces lo entregas a los jugadores (despliegue).

Un error típico del principiante es saltarse pasos y pasar del desarrollo directamente al despliegue.

La verificación es la primera barrera de control. Aquí no se evalúa si la feature es divertida, útil o deseada. Se evalúa algo más básico: si el sistema es internamente coherente y estable.

Todas las pruebas de verificación existen para reducir un único riesgo: que el software falle por errores estructurales, incoherencias internas o decisiones técnicas mal integradas. Si este riesgo no se controla, cualquier validación posterior carece de sentido, porque se estaría evaluando una base inestable.

Por eso en esta fase se piensa como equipo técnico, no como jugador. El criterio no es la experiencia, sino la solidez.

1. Verificación - "¿Está bien construido?"

La verificación no tiene que ver con si el juego es divertido. Tiene que ver con si el código está bien hecho según las propias reglas del proyecto. Aquí no se piensa como jugador, se piensa como programador.

Para un principiante, esto equivale a algo mucho más simple:

“Antes de dar por bueno mi código, lo reviso con calma o se lo enseño a otra persona”.

Para Eldoria: Antes de fusionar código al juego, se revisa:

PR: "Añadir sistema de crafting"
┌─────────────────────────────────────────┐
│ El código sigue convenciones del juego  │
│ No rompe combate existente              │
│ Tests pasan                             │
│ Documentación actualizada               │
└─────────────────────────────────────────┘

Esto significa:

– El código se parece al resto del código del proyecto.
– No rompe funcionalidades antiguas.
– No introduce errores evidentes.
– Si hay documentación, se ha actualizado.

Nada de esto habla todavía de diversión o experiencia de juego.

Las formas de verificación pueden variar —revisión humana, herramientas automáticas, inspección de diseño— pero todas comparten el mismo propósito: detectar problemas **antes de ejecutar el sistema en condiciones reales**. No importa quién o qué realice la comprobación; importa que los fallos estructurales se identifiquen cuando aún son baratos de corregir.

Ejemplo concreto:

// PR #45: Nueva habilidad "Bola de Fuego"
// REVISIÓN:
// 1. ¿Daño balanceado? (20-40 por nivel)
// 2. ¿Animación se ve bien? (Assets incluidos)
// 3. ¿Consume maná correctamente? (15 maná)
// 4. ¿Interactúa bien con resistencia al fuego? (Sí)

Se revisa preguntando cosas muy concretas:
¿El daño tiene sentido dentro del sistema del juego?
¿La animación está incluida o falta algún archivo?
¿Consume recursos correctamente?
¿Respeta las reglas existentes (resistencias, estados, etc.)?
Esto es verificación, porque se comprueba que la nueva habilidad encaja técnicamente.

Análisis Estático

Responsable: Herramientas automatizadas (SonarQube, ESLint)

Hay programas que leen tu código y detectan errores sin ejecutarlo.

Problemas encontrados:
  - Posible división por cero
  - Función demasiado compleja
  - Variables no usadas
  
 Esto significa:

– Hay código que podría fallar en tiempo de ejecución.
– Hay funciones difíciles de entender y mantener.
– Hay partes del código que no sirven para nada.

El objetivo no es “hacer código bonito”, sino reducir errores futuros.

Inspección de Arquitectura

Aquí no se revisa una función, sino cómo encajan las piezas grandes.

Para Eldoria: Revisar que el diseño sigue patrones establecidos:

Sistema propuesto: "Almacenamiento en la nube"
┌────────────────────────────────────────────┐
│ ARQUITECTURA ACTUAL:                       │
│   Frontend ↔ API ↔ SQLite                  │
│                                            │
│ NUEVA PROPUESTA:                           │
│   Frontend ↔ API ↔ Cloud DB                │
│                                            │
│ PROBLEMAS DETECTADOS:                      │
│   • Jugadores offline no podrían jugar     │
│   • Latencia en zonas con mala conexión    │
│                                            │
│ SOLUCIÓN: Sistema híbrido                  │
│   • SQLite local + sincronización a nube   │
└────────────────────────────────────────────┘

Revisión de Contratos de API

Un contrato de API es un acuerdo: “Si me llamas, te devuelvo estos datos con esta forma”.

Para Eldoria: Verificar que frontend y backend se comunican correctamente:

// CONTRATO API: /api/characters/{id}
// Esperado por frontend:
{
  "id": "uuid",
  "name": "string",
  "level": "number",
  "stats": { ... }
}

// Implementado en backend:
{
  "id": "uuid",
  "name": "string",
  "level": "number",
  "stats": { ... },    // ✅ Coincide
  "created_at": "date" // ⚠️ Campo extra no esperado
}
// RESULTADO: Frontend ignora created_at, todo OK

La verificación aquí consiste en comprobar que:

– El backend devuelve lo prometido.
– El frontend sabe manejarlo.

Si el backend añade campos extra, hay que asegurarse de que no rompan nada.

Esto es verificación porque no se evalúa el uso, solo la coherencia técnica.

Superada la verificación, el riesgo principal ya no es técnico. El sistema puede estar bien construido y aun así fracasar. La validación aborda ese segundo riesgo: haber construido algo correcto que no sirve a quien lo usa.

Aquí cambia deliberadamente el punto de vista. Ya no importa cómo está hecho el código, sino qué puede hacer el jugador con él. La validación existe para comprobar que las promesas funcionales se cumplen en la práctica, en contextos reales y con comportamientos no controlados por el desarrollador.

Una feature validada no es la que “funciona”, sino la que resuelve el problema por el que fue creada.

2. Validación - "¿Resuelve el problema real?"

Aquí cambia completamente el punto de vista. Ahora no importa cómo está hecho el código. Importa si el jugador puede hacer lo que espera hacer.

Pruebas de Aceptación Basadas en Criterios

Los criterios de aceptación son promesas.

Ejemplo:

“Un jugador puede añadir amigos y hablar con ellos”.

Validar significa comprobar que esas promesas se cumplen de verdad, no solo en teoría. Cada punto se formula como una acción real del jugador. Si una sola falla, la funcionalidad no está validada, aunque el código esté bien escrito.

Para Eldoria: Verificar que una feature cumple lo prometido:

FEATURE: "Sistema de amigos"
CRITERIOS DE ACEPTACIÓN:
1. Como jugador, quiero añadir amigos por nombre
   Puedo buscar "Aragorn23" y enviar solicitud

2. Como jugador, quiero ver mis amigos online
   Lista muestra amigos conectados con ícono verde

3. Como jugador, quiero chatear con amigos
   Chat funciona en tiempo real sin delay

4. Como jugador, quiero desactivar notificaciones
   Puedo silenciar a un amigo específico

Pruebas con Usuarios Reales

Los jugadores no usan el juego como el programador imagina. Las pruebas basadas en criterios verifican lo prometido de forma explícita. Las pruebas con usuarios van un paso más allá: revelan lo que nunca se prometió, pero igualmente importa. Confusión, frustración o usos inesperados no son errores de implementación, pero sí señales claras de una validación incompleta.

Para Eldoria: Observar a jugadores reales usando el juego:

SESIÓN DE TEST CON JUGADORES:
Usuario A (novato):
  • Se pierde en el tutorial ❌
  • No encuentra cómo equipar armas ❌
  • Le gusta el combate ✅

Usuario B (experimentado):
  • Encuentra bug en combo de habilidades ❌
  • Sugiere atajo de teclado para inventario 💡
  • Dice que el jefe es muy fácil ❌

ACCIONES RESULTANTES:
1. Rediseñar tutorial
2. Añadir tutorial de equipamiento
3. Arreglar combo bug
4. Ajustar dificultad del jefe

Esto no es un bug técnico, pero sí un fallo de validación.

La validación detecta problemas que ningún test automático puede encontrar, como 
confusión, frustración o aburrimiento.

Revisión en Entorno Similar a Producción

La idea básica es: Probar el juego en condiciones parecidas a las reales. No se busca perfección técnica, sino responder a preguntas simples:

– ¿Se guarda el progreso? – ¿Aguanta varios jugadores a la vez? – ¿Qué pasa si algo falla?

Esto sigue siendo validación porque se prueba el uso real, no el código aislado.

Para Eldoria: Probar en un entorno idéntico al de producción:

ENTORNO STAGING (copia exacta de producción):
• Mismos recursos: 2 CPUs, 4GB RAM
• Misma base de datos: PostgreSQL 14
• Mismo sistema operativo: Ubuntu 22.04

PRUEBAS REALIZADAS:
1. Carga simultánea: 100 jugadores conectados
   Respuesta < 2 segundos

2. Persistencia de datos: Crear personaje, cerrar, reabrir
   Personaje guardado correctamente

3. Recuperación de fallos: Simular caída de servidor
   Los jugadores pueden reconectarse sin perder progreso

QA no introduce un nuevo tipo de prueba sobre la feature. Introduce un nuevo nivel de control: el del proceso completo. Su objetivo no es detectar errores concretos, sino evitar que la calidad dependa de la suerte, la memoria o el esfuerzo individual.

El riesgo que aborda QA es organizativo: pruebas olvidadas, criterios ambiguos, entregas inconsistentes y errores que se repiten sprint tras sprint. QA convierte las buenas prácticas puntuales en hábitos verificables y sostenibles.

3. QA - Control del Proceso de Calidad

Planificación de QA

QA no es “probar cosas”. QA es asegurarse de que siempre se prueban las cosas importantes.

Para Eldoria: Plan para cada sprint:

# plan-qa-sprint-5.yml
Sprint: 5 - "Expansión del Bosque"
Features a probar:
  1. Nueva zona: Bosque Encantado
  2. NPCs: Druida y Hadas
  3. Misiones: 3 misiones principales, y otras secundarias
  4. Enemigos: Lobos, Arañas, Treants

Recursos necesarios:
  • 2 testers full-time
  • 5 beta testers externos
  • Servidor de staging, con las caracteristicas iguales a produccion
  • Herramientas: Jira, TestRail, etc.

Criterios de éxito:
  • 0 bugs críticos
  • 95% cobertura de pruebas
  • Feedback positivo de beta testers

Definition of Done (DoD)

La DoD responde a una pregunta peligrosa:

“¿Esto ya está terminado?”

Sin una definición clara, cada persona entiende algo distinto por “terminado”. La DoD evita entregar funcionalidades a medias.

Para Eldoria: Qué significa "terminado" para una feature:

DEFINITION OF DONE - Sistema de Comercio:
- Código escrito y revisado.
- Pruebas unitarias pasando (100% cobertura).
- Pruebas de integración pasando.
- Documentación actualizada.
- UI/UX aprobada por diseñador.
- Performance aceptable (<100ms respuesta).
- Compatible con todos los navegadores.
- Desplegado en staging y probado.
- Aprobado por Product Owner.

Trazabilidad de Requisitos a Pruebas

Esto conecta dos mundos:

– Lo que se prometió. – Lo que se comprobó.

Sirve para responder con claridad:

“¿Esto se probó? ¿Dónde?”

Para Eldoria: Seguir cada requisito hasta su prueba:

REQUISITO: RF-23 "Los jugadores pueden formar clanes"
  ↓
CASO DE PRUEBA: CP-23-01 "Crear clan"
  • Prueba crear clan "Guardianes de Eldoria"
  • Verificar que aparece en listado global

CASO DE PRUEBA: CP-23-02 "Invitar miembros"
  • Invitar a jugador "Aragorn"
  • Verificar que recibe notificación

CASO DE PRUEBA: CP-23-03 "Chat de clan"
  • Enviar mensaje en chat de clan
  • Verificar que todos los miembros lo ven

ESTADO: ✅ 3/3 pruebas pasando

Control del Proceso

Las métricas no son para castigar. Son para detectar problemas estructurales:

– Falta acceso a builds. – Falta documentación.

QA mejora el proceso, no el código directamente.

Para Eldoria: Métricas y seguimiento:

# reporte-calidad-mensual.yml
Mes: Abril 2025 (segundo trimestre año)
Métricas:
  bugs_abiertos: 12 (↓ 30% vs que el trimestre anterior)
  bugs_críticos: 0 (✅)
  cobertura_pruebas: 92% (↑ 5%)
  tiempo_resolución_bugs: 2.3 días (↓ 0.5 días)

Problemas identificados:
  • Los testers no tienen acceso a builds nocturnos
  • Falta documentación para probar combos complejos

Acciones de mejora:
  • Configurar acceso automático a builds
  • Crear guía de pruebas para combate
  • Implementar pruebas de regresión automáticas

RESUMEN VISUAL DE RESPONSABILIDADES

• Verificación: Comprueba que el código está bien construido según las reglas internas.
• Validación: Comprueba que el juego funciona para jugadores reales.
• QA: Asegura que estas comprobaciones se hacen siempre y de forma ordenada.

Este ejemplo es avanzado en forma, pero la idea central es simple: primero construir bien, luego comprobar que sirve, y no confiar nunca en la suerte.

EJEMPLO PRÁCTICO COMPLETO

Feature: "Sistema de Monturas"

1. VERIFICACIÓN:

// PR Revisión
✅ Código modular, separado en MountService
✅ No afecta rendimiento (pruebas de carga OK)
✅ Sprites optimizados ( < 100KB cada uno)

// Análisis Estático
✅ 0 vulnerabilidades de seguridad
✅ Complejidad ciclomática < 10

// Arquitectura
✅ Monturas como decoradores de Personaje
✅ Persistencia en tabla separada mounts

// Contrato API
GET /api/mounts → [{id, name, speed}]
✅ Coincide frontend/backend

2. VALIDACIÓN:

// Pruebas de aceptación
✅ Jugador puede comprar montura en establo
✅ Velocidad aumenta 50% al montar
✅ Animaciones fluidas

// Pruebas con usuarios
👥 10 beta testers prueban monturas
📊 Resultados: 9/10 dicen "divertido y útil"
🐛 Bug encontrado: Montura se atasca en puentes

// Entorno staging
🔧 50 jugadores simultáneos montando
📈 CPU < 60%, memoria estable

3. QA PROCESO:

Planificación:
  - 2 días de pruebas intensivas
  - Checklist: compra, montar, desmontar, combate montado

Definition of Done:
  ✅ Código revisado
  ✅ Pruebas pasando
  ✅ Performance OK
  ✅ UX aprobada
  ✅ Bugs críticos: 0

Trazabilidad:
  RF-45 "Sistema de monturas" →
    CP-45-01 Compra montura ✅
    CP-45-02 Montar/Desmontar ✅
    CP-45-03 Velocidad aumento ✅

Control:
  Bugs abiertos: 1 (puentes)
  Tiempo estimado resolución: 2 días
  Riesgo: Bajo (workaround disponible)

Vista en conjunto, cada capa cumple una función precisa. La verificación asegura que el sistema no se rompe a sí mismo. La validación asegura que el jugador puede hacer lo que espera. QA asegura que estas comprobaciones no dependen del azar ni del estado de ánimo del equipo.

El objetivo final no es aprobar pruebas, sino entregar funcionalidades con riesgo controlado.

RESUMEN PARA ELDORIA CHRONICLES

Verificación = "¿Lo construimos bien?"

• Revisamos el cómo se hizo
• Técnico, interno, automatizable
• Responsables: equipo técnico

Validación = "¿Construimos lo correcto?"

• Revisamos el qué se hizo
• De negocio, con usuarios reales
• Responsables: PO, UX, testers

QA = "¿El proceso funciona?"

• Controlamos todo el flujo
• Planificación, métricas, mejora
• Responsables: equipo QA

Resultado: Un juego de calidad donde los jugadores disfrutan sin bugs, con buen performance, y que cumple exactamente lo prometido.