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
El testing manual sigue siendo un pilar fundamental de la calidad del software pese al auge de la automatización. El SmartBear State of Testing 2025 encontró que el 56% de toda la actividad de testing todavía se realiza manualmente, incluso en organizaciones con programas de automatización maduros. El ISTQB reporta más de 600.000 testers certificados en todo el mundo — una cifra que crece cada año — lo que refleja la demanda global sostenida de profesionales QA calificados. ¿Por qué persiste el testing manual? Porque el software sirve a personas, y el juicio humano es insustituible para evaluar usabilidad, corrección visual y si una aplicación realmente tiene sentido para el usuario. La automatización puede verificar que un botón existe y responde al clic; el testing manual determina si ese botón está en el lugar correcto, es legible en todos los tamaños de pantalla y es consistente con el resto de la interfaz. Esta guía cubre el kit completo: diseño de casos de prueba, técnicas de testing exploratorio, reporte de bugs y las habilidades que distinguen a los ingenieros QA efectivos.
Fuentes: SmartBear State of Software Quality 2025, ISTQB
¿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
“Cada equipo que ha intentado eliminar el testing manual por completo, eventualmente lo ha traído de vuelta. La automatización te dice qué se rompió — el testing manual te dice qué está mal. No son lo mismo, y necesitas ambos. Mi regla: automatiza lo repetitivo, testea manualmente lo que requiere criterio.” — Yuri Kan, Senior QA Lead
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
| Severidad | Descripción | Ejemplo |
|---|---|---|
| Crítica | Sistema inutilizable | App crashea al iniciar |
| Alta | Feature principal rota | No se puede completar compra |
| Media | Feature con limitaciones | Filtros de búsqueda no funcionan |
| Baja | Issue menor | Typo 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
- Software Testing Tutorial - Fundamentos de testing para principiantes
- Test Automation Tutorial - Cuándo y cómo automatizar
- Exploratory Testing Guide - Inmersión profunda en testing exploratorio
- Bug Reports Guide - Gestión efectiva de defectos
