Módulo 00: Introducción al Testing de Software

Objetivos del módulo

• Comprender qué es el testing y por qué es esencial
• Conocer los tipos fundamentales de pruebas
• Entender la pirámide de testing
• Diferenciar roles y responsabilidades en QA
• Conocer el vocabulario básico del testing

---

1. ¿Qué es el testing de software?

El testing (o pruebas de software) es el proceso de evaluar un sistema o componente para verificar que cumple con los requisitos especificados y detectar defectos.

📘 Concepto: Testing no es solo “buscar errores”, es un proceso sistemático que da confianza en la calidad del software.

¿Por qué es importante?

Motivo	Ejemplo
Prevenir fallos	Una app bancaria que calcula mal los intereses
Ahorrar dinero	Corregir un bug en producción cuesta 100x más que en desarrollo
Proteger la reputación	Un fallo público destruye la confianza del usuario
Cumplir normativas	Sectores como salud o aviación exigen pruebas certificadas
Mejorar la calidad	Código probado es más mantenible y confiable

Coste de los defectos según la fase

graph LR
    A[Requisitos<br/>1x] --> B[Diseño<br/>5x]
    B --> C[Desarrollo<br/>10x]
    C --> D[Testing<br/>20x]
    D --> E[Producción<br/>100x]
    style A fill:#4CAF50,color:white
    style E fill:#f44336,color:white

⚠️ Importante: Cuanto más tarde se detecta un defecto, más caro es corregirlo. Por eso el testing temprano es fundamental.

---

2. Terminología fundamental

Término	Definición
Bug / Defecto	Error en el código que causa un comportamiento incorrecto
Error	Acción humana que produce un defecto
Fallo	Manifestación visible de un defecto al ejecutar el software
Caso de prueba	Conjunto de condiciones para verificar un requisito
Suite de pruebas	Colección organizada de casos de prueba
Plan de pruebas	Documento que describe la estrategia y alcance de las pruebas
Cobertura	Porcentaje de código o requisitos probados
Regresión	Defecto introducido al modificar código existente
Smoke test	Prueba rápida para verificar que lo básico funciona
Sanity test	Prueba enfocada para verificar una corrección específica

Diferencia entre Error → Defecto → Fallo

graph LR
    A[Error humano<br/>Programador se equivoca] --> B[Defecto<br/>Bug en el código]
    B --> C[Fallo<br/>El usuario ve un error]
    style A fill:#FF9800,color:white
    style B fill:#f44336,color:white
    style C fill:#9C27B0,color:white

---

3. Tipos de pruebas por nivel

3.1 Pruebas unitarias

Prueban componentes individuales (funciones, métodos, clases) de forma aislada.

// Ejemplo: prueba unitaria con NUnit
[Test]
public void Sumar_DosPositivos_RetornaSuma()
{
    var calc = new Calculadora();
    int resultado = calc.Sumar(2, 3);
    Assert.That(resultado, Is.EqualTo(5));
}

• Quién las escribe: Desarrolladores
• Velocidad: Muy rápidas (milisegundos)
• Cantidad: Son las más numerosas

3.2 Pruebas de integración

Verifican que varios componentes funcionan correctamente juntos.

// Ejemplo: prueba de integración con base de datos
[Test]
public async Task CrearUsuario_GuardaEnBaseDeDatos()
{
    using var db = new AppDbContext(opciones);
    var servicio = new UsuarioService(db);
    
    await servicio.CrearAsync("Ana", "ana@mail.com");
    
    var usuario = await db.Usuarios.FirstOrDefaultAsync(u => u.Nombre == "Ana");
    Assert.That(usuario, Is.Not.Null);
}

• Quién las escribe: Desarrolladores / QA
• Velocidad: Más lentas (segundos)
• Cantidad: Menos que las unitarias

3.3 Pruebas End-to-End (E2E)

Simulan el flujo completo del usuario desde la interfaz hasta la base de datos.

// Ejemplo: prueba E2E con Selenium
[Test]
public void Login_CredencialesValidas_AccedeAlDashboard()
{
    driver.Navigate().GoToUrl("https://miapp.com/login");
    driver.FindElement(By.Id("email")).SendKeys("user@test.com");
    driver.FindElement(By.Id("password")).SendKeys("123456");
    driver.FindElement(By.Id("btn-login")).Click();
    
    Assert.That(driver.Title, Does.Contain("Dashboard"));
}

• Quién las escribe: QA / Testers
• Velocidad: Lentas (segundos a minutos)
• Cantidad: Son las menos numerosas

3.4 Pruebas de rendimiento

Evalúan cómo se comporta el sistema bajo carga y estrés.

• Carga: ¿Soporta 1000 usuarios simultáneos?
• Estrés: ¿Qué pasa cuando se supera la capacidad?
• Herramientas: JMeter, k6, Gatling

---

4. La pirámide de testing

graph TB
    subgraph Pirámide de Testing
        E2E["🖥️ E2E / UI<br/>Pocas, lentas, caras"]
        INT["🔗 Integración<br/>Cantidad media"]
        UNIT["⚙️ Unitarias<br/>Muchas, rápidas, baratas"]
    end
    UNIT --- INT --- E2E
    style UNIT fill:#4CAF50,color:white
    style INT fill:#FF9800,color:white
    style E2E fill:#f44336,color:white

Nivel	Cantidad	Velocidad	Coste	Confianza
Unitarias	Muchas (70%)	Milisegundos	Bajo	En componentes
Integración	Media (20%)	Segundos	Medio	En interacciones
E2E	Pocas (10%)	Minutos	Alto	En flujos completos

💡 Consejo: Sigue la pirámide: muchas unitarias, menos de integración, pocas E2E. Si tu pirámide está invertida (muchas E2E, pocas unitarias), tendrás suites lentas y frágiles.

---

5. Tipos de pruebas por enfoque

Pruebas funcionales vs no funcionales

Tipo	Qué verifican	Ejemplos
Funcionales	Que el sistema hace lo que debe	Login funciona, cálculo correcto
No funcionales	Cómo lo hace	Rendimiento, seguridad, usabilidad

Pruebas manuales vs automatizadas

Aspecto	Manual	Automatizada
Ejecución	Una persona sigue pasos	Un script se ejecuta solo
Velocidad	Lenta	Muy rápida
Repetibilidad	Propensa a errores humanos	100% repetible
Coste inicial	Bajo	Alto (escribir scripts)
Coste a largo plazo	Alto (repetir cada vez)	Bajo (se ejecuta gratis)
Exploración	Excelente	No aplica

📘 Concepto: No todo debe automatizarse. Las pruebas exploratorias, de usabilidad y de experiencia de usuario siguen siendo esencialmente manuales.

Caja negra vs caja blanca

Tipo	Conocimiento del código	Quién lo hace
Caja negra	No se ve el código interno	Testers / QA
Caja blanca	Se conoce el código	Desarrolladores
Caja gris	Conocimiento parcial	QA con acceso a BD/logs

---

6. Roles en testing

Rol	Responsabilidades
QA Engineer	Diseña estrategia de calidad, define procesos
Tester Manual	Ejecuta casos de prueba manualmente
QA Automation	Automatiza pruebas (Selenium, Playwright, etc.)
SDET	Software Development Engineer in Test — escribe frameworks
Performance Engineer	Pruebas de rendimiento y carga
Security Tester	Pruebas de seguridad y penetración

---

7. Principios del testing (ISTQB)

El ISTQB (International Software Testing Qualifications Board) define 7 principios:

1. El testing muestra la presencia de defectos, no su ausencia
   • Nunca puedes demostrar que no hay bugs
2. El testing exhaustivo es imposible
   • No puedes probar todas las combinaciones
3. Testing temprano ahorra tiempo y dinero
   • Cuanto antes pruebes, mejor
4. Los defectos se agrupan
   • El 80% de los bugs están en el 20% del código (Pareto)
5. La paradoja del pesticida
   • Si siempre ejecutas los mismos tests, dejan de encontrar bugs nuevos
6. El testing depende del contexto
   • Una app médica requiere más rigor que un blog personal
7. La ausencia de errores es una falacia
   • Un software sin bugs pero que no cumple necesidades del usuario sigue siendo inútil

---

8. Ciclo de vida del testing (STLC)

graph LR
    A[Análisis de<br/>requisitos] --> B[Planificación]
    B --> C[Diseño de<br/>casos de prueba]
    C --> D[Preparación<br/>del entorno]
    D --> E[Ejecución]
    E --> F[Cierre y<br/>reporte]
    style A fill:#2196F3,color:white
    style F fill:#4CAF50,color:white

Fase	Actividades
Análisis	Revisar requisitos, identificar qué probar
Planificación	Definir alcance, recursos, cronograma
Diseño	Escribir casos de prueba, preparar datos
Preparación	Configurar entornos, herramientas, accesos
Ejecución	Ejecutar pruebas, registrar resultados, reportar bugs
Cierre	Evaluar métricas, lecciones aprendidas, informe final

---

9. Herramientas que aprenderás en este curso

Herramienta	Tipo	Módulo
NUnit	Pruebas unitarias (.NET)	05
xUnit	Pruebas unitarias (.NET)	06
Postman	Testing de APIs	09
Selenium	Automatización UI (web)	10
Katalon Studio	Automatización UI (todo en uno)	12
Playwright	Automatización UI (moderna)	11
JMeter	Pruebas de rendimiento	13
GitHub Actions	CI/CD para testing	14
Jira	Gestión de proyectos/bugs	02
TestLink	Gestión de pruebas	03

---

Resumen

Concepto	Descripción
Testing	Proceso de verificar que el software funciona correctamente
Pirámide	Muchas unitarias → pocas integración → mínimas E2E
Manual vs Auto	Lo repetitivo se automatiza; lo exploratorio se hace manual
Caja negra/blanca	Según el conocimiento del código interno
STLC	Ciclo de vida: análisis → plan → diseño → ejecución → cierre
7 principios	Guías fundamentales del ISTQB

---

Navegación
Volver al índice del curso	Siguiente módulo: Metodologías ágiles →