TL;DR

  • El testing de software verifica que el software funciona como se espera y cumple necesidades del usuario
  • Tipos de testing: funcional, no funcional, manual, automatizado, caja negra, caja blanca
  • Diseño de casos de prueba: partición de equivalencia, análisis de valores límite, tablas de decisión
  • STLC (Software Testing Life Cycle): requisitos → planificación → diseño → ejecución → reportes
  • No se necesita código para empezar — testing manual es una carrera válida

Ideal para: Personas considerando carrera en QA, desarrolladores queriendo entender testing, project managers Omite si: Ya eres tester practicante buscando técnicas avanzadas Tiempo de lectura: 12 minutos

Encontraste un bug en producción. Los usuarios se quejan. El equipo de desarrollo está en pánico. Todos preguntan: “¿Cómo pasó esto por testing?”

Este tutorial enseña los fundamentos del testing de software — los conceptos, técnicas y procesos que previenen que los bugs lleguen a los usuarios.

¿Qué es el Testing de Software?

El testing de software es el proceso de evaluar una aplicación para:

  1. Encontrar defectos — bugs, errores, comportamiento inesperado
  2. Verificar requisitos — ¿hace lo que debería?
  3. Validar calidad — ¿es suficientemente bueno para usuarios?

Testing no es solo “hacer clic por ahí”. Es una disciplina sistemática con técnicas, procesos y conocimiento especializado.

Por qué Importa el Testing

Sin TestingCon Testing
Bugs en producciónBugs detectados temprano
Usuarios enojadosUsuarios satisfechos
Arreglos costososArreglos baratos
Brechas de seguridadSeguridad verificada
Ingresos perdidosIngresos protegidos

El costo de bugs aumenta con el tiempo:

  • Bug encontrado en requisitos: $1 para arreglar
  • Bug encontrado en desarrollo: $10 para arreglar
  • Bug encontrado en testing: $100 para arreglar
  • Bug encontrado en producción: $1000+ para arreglar

Tipos de Testing de Software

Por Enfoque

Testing Manual

  • Tester ejecuta pruebas a mano
  • Mejor para: testing exploratorio, usabilidad, escenarios complejos
  • Sin código requerido

Testing Automatizado

  • Scripts ejecutan pruebas automáticamente
  • Mejor para: regresión, pruebas repetitivas, CI/CD
  • Requiere habilidades de programación

Por Conocimiento del Código

Testing de Caja Negra

  • Probar sin conocer el código interno
  • Enfoque en entradas y salidas
  • La mayoría del testing manual es caja negra

Testing de Caja Blanca

  • Probar con acceso completo al código
  • Análisis de cobertura, rutas de código
  • Usualmente hecho por desarrolladores

Testing de Caja Gris

  • Conocimiento parcial de internos
  • Testing de base de datos, testing de API
  • Común en testing de integración

Por Nivel

┌─────────────────────────────────────┐
│        E2E / Tests de Sistema       │  ← Flujos completos de usuario
├─────────────────────────────────────┤
│       Tests de Integración          │  ← Interacciones de componentes
├─────────────────────────────────────┤
│          Tests Unitarios            │  ← Funciones individuales
└─────────────────────────────────────┘

Ciclo de Vida del Testing (STLC)

1. Análisis de Requisitos

  • Revisar requisitos/user stories
  • Identificar qué necesita testing
  • Aclarar ambigüedades con stakeholders

2. Planificación de Testing

  • Definir estrategia de testing
  • Estimar esfuerzo y recursos
  • Identificar herramientas necesarias

3. Diseño de Tests

  • Escribir casos de prueba
  • Crear datos de prueba
  • Diseñar escenarios de prueba

4. Ejecución de Tests

  • Ejecutar casos de prueba
  • Registrar resultados (pass/fail)
  • Reportar bugs encontrados

5. Reportes

  • Resumen de resultados de testing
  • Estadísticas de bugs
  • Métricas de cobertura

6. Cierre

  • Lecciones aprendidas
  • Archivar artefactos de testing

Escribiendo Casos de Prueba

Un caso de prueba es un conjunto de condiciones para verificar si una función funciona correctamente.

Plantilla de Caso de Prueba

Test Case ID: TC-LOGIN-001
Título: Login exitoso con credenciales válidas
Prioridad: Alta
Precondiciones: Cuenta de usuario existe, usuario deslogueado

Pasos:
1. Navegar a página de login
2. Ingresar email válido: user@example.com
3. Ingresar contraseña válida: Password123
4. Hacer clic en botón Login

Resultado Esperado: Usuario redirigido a dashboard, mensaje de bienvenida mostrado
Resultado Actual: [Completar durante ejecución]
Estado: [Pass/Fail]

Técnicas de Diseño de Tests

Partición de Equivalencia

Dividir entradas en grupos (particiones) que deberían comportarse igual.

Ejemplo: Campo de edad (válido: 18-120)

Partición 1: Inválido (< 18)   → Probar con 17
Partición 2: Válido (18-120)   → Probar con 50
Partición 3: Inválido (> 120)  → Probar con 121

Análisis de Valores Límite

Los bugs suelen ocurrir en límites. Prueba los bordes.

Ejemplo: Campo de edad (válido: 18-120)

Test: 17  (justo bajo mínimo)  → Inválido
Test: 18  (límite mínimo)      → Válido
Test: 19  (justo sobre mínimo) → Válido
Test: 119 (justo bajo máximo)  → Válido
Test: 120 (límite máximo)      → Válido
Test: 121 (justo sobre máximo) → Inválido

Tablas de Decisión

Cuando múltiples condiciones afectan el resultado.

Ejemplo: Login con 2FA

| Condición           | R1 | R2 | R3 | R4 |
|---------------------|----|----|----|----|
| Contraseña válida   | Y  | Y  | N  | N  |
| Código 2FA válido   | Y  | N  | Y  | N  |
|---------------------|----|----|----|----|
| Acceso permitido    | Y  | N  | N  | N  |
| Mensaje de error    | N  | Y  | Y  | Y  |

Reportes de Bugs

Plantilla de Reporte de Bug

Bug ID: BUG-2024-001
Título: Login falla con credenciales válidas en Chrome mobile

Severidad: Alta
Prioridad: Crítica
Ambiente: Chrome 120, Android 14

Pasos para Reproducir:
1. Abrir app en Chrome mobile
2. Ingresar email válido: user@example.com
3. Ingresar contraseña válida: Password123
4. Tocar botón Login

Esperado: Redirección a dashboard
Actual: Mensaje de error "Something went wrong"

Adjuntos: screenshot.png, video.mp4

Carrera en Testing de Software

Entry Level (0-2 años)
├── Tester Manual
├── Analista QA
└── Ingeniero de Testing

Mid Level (2-5 años)
├── Ingeniero QA Senior
├── Ingeniero de Automatización
├── Tester de Performance
└── Tester de Seguridad

Senior Level (5+ años)
├── QA Lead / Manager
├── Arquitecto de Testing
├── Director QA
└── Principal QA Engineer

Testing Asistido por IA

La IA está cambiando cómo testeamos software.

Lo que la IA hace bien:

  • Generar casos de prueba desde requisitos
  • Testing de regresión visual
  • Predecir áreas de alto riesgo
  • Analizar patrones de resultados

Lo que aún necesita humanos:

  • Decisiones de estrategia de testing
  • Entender contexto de negocio
  • Testing exploratorio
  • Evaluación de usabilidad

FAQ

¿Qué es el testing de software?

El testing de software es el proceso de evaluar software para encontrar defectos, verificar que cumple requisitos y asegurar que es apto para usuarios. Incluye varias actividades: escribir casos de prueba, ejecutar tests, reportar bugs y verificar correcciones.

¿Puedo ser tester sin programar?

Sí. Las carreras de testing manual no requieren programación. Escribirás casos de prueba, ejecutarás tests, reportarás bugs — todo sin código. Al avanzar, scripting básico (SQL, automatización simple) ayuda pero no es obligatorio.

¿Cuál es la diferencia entre QA y testing?

Testing es un subconjunto de QA. Testing encuentra bugs en software existente mediante ejecución y verificación. QA (Quality Assurance) es más amplio: prevenir defectos mediante mejora de procesos, estándares, revisiones e involucramiento temprano en desarrollo.

¿Cuánto tiempo toma convertirse en tester?

Los tiempos varían por rol:

  • Testing manual entry-level: 2-3 meses de aprendizaje enfocado
  • Testing automatizado: 6-12 meses (incluye fundamentos de programación)
  • Roles senior: 3-5 años de experiencia práctica

Recursos Oficiales

Ver También