TL;DR

  • Testing manual usa juicio humano para encontrar bugs que la automatización no ve — problemas de usabilidad, defectos visuales, comportamientos inesperados
  • Habilidades clave: diseño de casos de prueba, testing exploratorio, reporte de bugs, análisis de requisitos
  • Estructura de caso de prueba: ID, título, precondiciones, pasos, resultado esperado, resultado actual
  • Reportes de bugs necesitan: resumen, pasos para reproducir, esperado vs actual, severidad, screenshots
  • Testing manual complementa la automatización — ambos son esenciales para la calidad

Ideal para: Nuevos ingenieros QA, personas cambiando de carrera, desarrolladores aprendiendo fundamentos QA Omite si: Solo trabajas con pipelines automatizados y nunca tocas UI Tiempo de lectura: 18 minutos

Tu suite de automatización pasa. Los usuarios reportan que el botón de checkout es invisible en móvil. El formulario de login acepta contraseñas vacías. El mensaje de error dice “Error: null.”

La automatización testea lo que le dices que testee. El testing manual encuentra lo que no pensaste verificar.

Este tutorial enseña fundamentos del testing manual — diseño de tests, ejecución, reporte de bugs y las habilidades que hacen valiosos a los ingenieros QA más allá de hacer clicks.

¿Qué es el Testing Manual?

Testing manual es testing de software realizado por humanos. Los testers interactúan con la aplicación, verifican funcionalidad contra requisitos y reportan defectos.

Qué involucra el testing manual:

  • Leer y entender requisitos
  • Diseñar casos de prueba y escenarios
  • Ejecutar tests paso a paso
  • Comparar resultados actuales con esperados
  • Reportar y trackear bugs
  • Re-testear issues corregidos

Por qué importa el testing manual:

  • Encuentra problemas de usabilidad — la automatización no puede juzgar si un UI es confuso
  • Descubre edge cases — la intuición humana atrapa escenarios inesperados
  • Valida experiencia de usuario — usuarios reales no siguen scripts
  • Se adapta rápido — no hay código que actualizar cuando cambian requisitos
  • Costo-efectivo para proyectos pequeños — setup de automatización toma tiempo

Tipos de Testing Manual

Testing Funcional

Verifica que las features funcionan según los requisitos.

Requisito: Usuario puede resetear contraseña via email

Test:
1. Click en "Olvidé mi contraseña"
2. Ingresar email registrado
3. Click en Enviar
4. Revisar email por link de reset
5. Click en link, ingresar nueva contraseña
6. Login con nueva contraseña

Esperado: Usuario inicia sesión exitosamente con nueva contraseña

Testing Exploratorio

Testing sin script donde los testers exploran la aplicación libremente.

Objetivo de sesión: Explorar flujo de checkout para edge cases

Tiempo: 30 minutos

Notas:
- ¿Qué pasa con 100 items en carrito?
- ¿Puedo hacer checkout con tarjeta expirada?
- ¿Qué si cambio cantidad durante pago?
- ¿El botón back rompe el flujo?
- ¿Qué pasa en timeout de red?

Smoke Testing

Tests rápidos para verificar funcionalidad básica después de un nuevo build.

Smoke Test Checklist:
□ Aplicación inicia
□ Login funciona
□ Navegación principal accesible
□ Feature core (búsqueda) funciona
□ Sin errores de consola en páginas clave
□ Logout funciona

Testing de Regresión

Re-testing de funcionalidad existente después de cambios de código.

Cambiado: Rediseño de página de perfil

Áreas de regresión:
- Edición de perfil sigue funcionando
- Subida de avatar funcional
- Cambio de contraseña funciona
- Notificaciones email se envían
- Endpoints API retornan mismos datos
- Otras páginas con links a perfil funcionan

Escribiendo Casos de Prueba

Un caso de prueba es un conjunto documentado de pasos para verificar funcionalidad específica.

Estructura del Caso de Prueba

ID Caso de Prueba: TC-LOGIN-001
Título: Login exitoso con credenciales válidas

Módulo: Autenticación
Prioridad: Alta
Precondiciones:
- Cuenta de usuario existe
- Usuario está en página de login

Pasos del Test:
1. Ingresar username válido "testuser@example.com"
2. Ingresar contraseña válida "SecurePass123"
3. Click en botón "Iniciar Sesión"

Resultado Esperado:
- Usuario redirigido a dashboard
- Mensaje de bienvenida muestra username
- Sesión creada (visible en dev tools)

Resultado Actual: [Se llena durante ejecución]
Estado: [Pass/Fail]
Testeado Por: [Nombre]
Fecha: [Fecha]

Mejores Prácticas de Casos de Prueba

1. Una cosa por caso de prueba

# Malo - testea múltiples cosas
Título: Funcionalidad de login

# Bueno - específico y enfocado
Título: Login falla con contraseña incorrecta
Título: Login falla con email inexistente
Título: Login exitoso con credenciales válidas

2. Pasos claros y accionables

# Malo - vago
1. Intentar hacer login
2. Verificar si funciona

# Bueno - específico
1. Ingresar email "user@test.com" en campo email
2. Ingresar contraseña "wrong123" en campo contraseña
3. Click en botón "Iniciar Sesión"
4. Observar mensaje de error

3. Resultados esperados medibles

# Malo - subjetivo
Esperado: Página carga rápido

# Bueno - medible
Esperado: Página carga en 3 segundos, todas las imágenes visibles

Testing Exploratorio

Testing exploratorio combina diseño y ejecución de tests simultáneamente. Aprendes, testeas y te adaptas en tiempo real.

Testing Exploratorio Basado en Sesiones

Charter de Sesión:
Explorar: Procesamiento de pagos
Duración: 45 minutos
Foco: Edge cases y manejo de errores

Notas de Sesión:
[10:00] Empecé con pago válido - funciona
[10:05] Probé pago de $0.01 - aceptado (¿es correcto?)
[10:12] Testeé monto negativo - mensaje de error poco claro
[10:18] Pago con caracteres especiales en nombre - crashea
[10:25] Timeout durante procesamiento - sin opción de recuperación
[10:35] Múltiples envíos rápidos - ¡cargos duplicados!

Bugs Encontrados: 3
Preguntas: 2
Áreas para más testing: Manejo de timeouts, validación de input

Técnicas de Testing Exploratorio

Testing de Límites

Campo: Edad (acepta 18-100)

Valores de prueba:
- 17 (bajo mínimo)
- 18 (en mínimo)
- 19 (sobre mínimo)
- 99 (bajo máximo)
- 100 (en máximo)
- 101 (sobre máximo)
- 0, -1, 999, vacío, texto

Testing de Transición de Estados

Estados del Carrito:
Vacío → Con Items → Checkout → Pago → Confirmación

Testear transiciones:
- Vacío → directo a Checkout (debería fallar)
- Con Items → de vuelta a Vacío → Checkout (debería fallar)
- Pago → back en navegador → Pago de nuevo (¿duplicado?)
- Confirmación → refresh (¿qué pasa?)

Reporte de Bugs

Un reporte de bug debe permitir que cualquiera reproduzca el problema.

Estructura del Reporte de Bug

Bug ID: BUG-2026-0142
Título: Checkout falla cuando carrito tiene más de 50 items

Severidad: Alta
Prioridad: Alta
Estado: Nuevo
Ambiente: Producción, Chrome 120, macOS 14.2

Pasos para Reproducir:
1. Login como cualquier usuario
2. Agregar 51 items al carrito
3. Click en "Proceder al Checkout"
4. Ingresar dirección de envío válida
5. Click en "Continuar a Pago"

Resultado Esperado:
Página de pago carga con resumen de orden

Resultado Actual:
Página muestra "Error 500: Internal Server Error"
Consola: "TypeError: Cannot read property 'length' of undefined"

Adjuntos:
- screenshot_error.png
- console_log.txt
- network_har.har

Info Adicional:
- Funciona bien con 50 o menos items
- Issue empezó después del deploy del 25 de enero
- Afecta todos los navegadores testeados

Severidad vs Prioridad

SeveridadDescripciónEjemplo
CríticaSistema inutilizableApp crashea al iniciar
AltaFeature principal rotaNo se puede completar compra
MediaFeature con limitacionesFiltros de búsqueda no funcionan
BajaIssue menorTypo en footer

Testing Manual con Asistencia de IA

Las herramientas de IA pueden ayudar con tareas de testing manual cuando se usan apropiadamente.

Lo que la IA hace bien:

  • Generar ideas de casos de prueba desde requisitos
  • Sugerir edge cases y valores límite
  • Crear plantillas de reportes de bugs
  • Crear variaciones de datos de prueba

Lo que aún necesita humanos:

  • Juzgar usabilidad y experiencia de usuario
  • Intuición de testing exploratorio
  • Entender contexto de negocio
  • Decidir severidad y prioridad

FAQ

¿Qué es el testing manual?

Testing manual es testing de software realizado por humanos sin scripts de automatización. Los testers ejecutan manualmente casos de prueba, exploran la aplicación, identifican defectos y verifican que el software se comporta según los requisitos. Depende del juicio humano, intuición y conocimiento del dominio para encontrar issues que los tests automatizados podrían perder.

¿El testing manual sigue siendo relevante en 2026?

Sí. El testing manual sigue siendo esencial para testing exploratorio, evaluación de usabilidad, testing ad-hoc y escenarios que requieren juicio humano. Mientras la automatización maneja tests de regresión repetitivos eficientemente, el testing manual sobresale en encontrar bugs inesperados, evaluar experiencia de usuario y testear nuevas features antes de construir automatización.

¿Qué habilidades necesitan los testers manuales?

Habilidades esenciales incluyen pensamiento crítico, atención al detalle, comunicación clara, análisis de requisitos, diseño de casos de prueba y reporte de bugs. El conocimiento del dominio ayuda a entender necesidades de usuario. Habilidades técnicas como SQL básico, API testing y herramientas de dev del navegador son cada vez más valiosas.

¿Cómo escribo buenos casos de prueba?

Buenos casos de prueba son específicos, repetibles y trazables. Tienen títulos claros, precondiciones explícitas, acciones paso a paso, resultados esperados medibles y campos para resultados actuales. Cada caso de prueba debe verificar una cosa. Incluye valores de datos de prueba, no solo “datos válidos”.

Ver También