Skip to content

Clase 13 — Tema 8: Calidad del Software, Pruebas y Desarrollo Dirigido por Pruebas

Resumen Ejecutivo

Sesión doble con dos bloques. Bloque 1 (Tema 8A): introducción a la calidad del software desde el ángulo de las pruebas. Conceptos de verificación y validación, tipos de pruebas (unitarias, integración, funcionales/validación, sistema, aceptación alfa/beta), mocking, y evolución desde TDD hasta BDD. Introducción a Selenium/Appium para pruebas extremo a extremo automatizadas. Bloque 2 (Refuerzo 02): revisión de trabajos de la Actividad 2 con comentarios sobre arquitectura, modelos de servicio cloud, patrones BFF y errores habituales (CDN mal entendido, punto y coma, texto no justificado, historias triviales). El taller de la semana siguiente trabajará Git y React de cara a la actividad grupal.

Conceptos Clave

  • Verificación: comprobar que el proceso es correcto; que el producto de cada fase es coherente con la fase anterior. Proceso estático: revisiones, inspecciones, análisis de documentación. ⚠️ EXAMEN
  • Validación: comprobar que el software construido cumple las necesidades reales del usuario. Requiere ejecutar el código. La única validación "pura" son las pruebas de aceptación. ⚠️ EXAMEN
  • TDD (Test-Driven Development): escribir la prueba antes de implementar el código. Técnica de diseño más que de testing. Origen en XP.
  • ATDD (Acceptance TDD): las pruebas de aceptación guían el desarrollo; definidas por el cliente.
  • BDD (Behavior-Driven Development): modelar el comportamiento de la aplicación a priori con frameworks como Cucumber/Gherkin. Los requisitos se expresan como pruebas en lenguaje casi natural.
  • Pruebas unitarias: verifican una sola función/clase en aislamiento. Las dependencias se mockean.
  • Mocking: simular dependencias para aislar la unidad bajo prueba y obtener resultados controlados.
  • Pruebas de integración: verifican la colaboración entre dos o más componentes (sin mockear las dependencias).
  • Pruebas de aceptación: verifican que el sistema cumple los requisitos del usuario. Las hace el cliente (o el tester siguiendo las indicaciones del cliente). Son las únicas pruebas de validación en sentido estricto.
  • Pruebas alfa / beta: alfa = en el entorno del equipo de desarrollo; beta = en el entorno real del usuario.
  • Selenium WebDriver: herramienta para automatizar pruebas extremo a extremo de aplicaciones web simulando interacción de usuario en el navegador. ⚠️ EXAMEN
  • Gherkin: lenguaje de alto nivel (casi natural) para definir pruebas de aceptación. Se usa con Cucumber.

Desarrollo del Temario

1. Verificación y Validación ⚠️ EXAMEN

Ambos procesos buscan que el software sea correcto y útil, pero desde perspectivas distintas.

graph LR
    U[Necesidades del usuario] --> R[Especificación de requisitos]
    R --> D[Diseño del sistema]
    D --> I[Implementación]
    I --> P[Producto entregado]

    R -. "Verificación: ¿refleja las necesidades?" .-> U
    D -. "Verificación: ¿coherente con requisitos?" .-> R
    I -. "Verificación: ¿coherente con diseño?" .-> D
    P -. "Validación: ¿cumple necesidades del usuario?" .-> U

Verificación: - Evalúa productos de trabajo intermedios (requisitos, diseños, código). - Pregunta: "¿Estamos construyendo el producto correctamente?" - Actividades: revisiones de código, inspecciones, análisis estático, walkthroughs. - En Scrum, la retrospectiva tiene más carácter de verificación (reflexión sobre el proceso).

Validación: - Evalúa el sistema funcionando frente a las necesidades del usuario. - Pregunta: "¿Estamos construyendo el producto correcto?" - Siempre requiere ejecutar el código. - En Scrum, el Sprint Review es la actividad de validación por excelencia: se muestra el incremento al Product Owner y a usuarios reales. ⚠️ EXAMEN

El problema de los requisitos: si la especificación de requisitos está mal desde el principio, un producto perfectamente verificado puede fallar la validación. Por eso los requisitos son los cimientos del desarrollo, y la agilidad (con el cliente in situ) reduce este riesgo.

Debate académico: hay autores que consideran que todas las pruebas son de verificación, y que la única validación real son las pruebas de aceptación (porque son las únicas que comparan directamente con las expectativas del usuario, no solo con los requisitos escritos).

2. TDD, ATDD y BDD

Son tres niveles del mismo paradigma: que las pruebas guíen el desarrollo antes de escribir el código.

Paradigma Nivel Quién define las pruebas Objetivo principal
TDD Unitario Desarrollador Calidad del código y diseño
ATDD Aceptación Cliente / Product Owner Validar funcionalidad completa
BDD Aceptación Cliente (con Gherkin) Especificar comportamiento en lenguaje natural

Por qué TDD mejora el diseño (no solo el testing):

Antes de implementar un método, plantear la prueba obliga a responder: - ¿Qué tipos de parámetros puede recibir? ¿Puede haber nulos, cadenas vacías, caracteres especiales? - ¿Cómo debería comportarse ante entradas inesperadas? - ¿Necesita métodos auxiliares? ¿Debería recibir un parámetro de configuración? - ¿Es estático o de instancia?

Estas preguntas mejoran el diseño de la clase antes de escribir una línea de implementación. Ejemplo: implementar un método ordenar(String[]) parece trivial, pero al definir las pruebas surgen casos: ¿mayúsculas antes que minúsculas? ¿caracteres especiales al principio? ¿string vacío? ¿nulo?

Ventaja de que las pruebas las haga alguien distinto al desarrollador: la persona que implementó tiene un sesgo sobre los casos de uso; quien prueba desde fuera puede descubrir situaciones no anticipadas.

Limitación de las pruebas: las pruebas no garantizan la ausencia de errores. Solo detectan errores para los casos de prueba definidos. Un caso no previsto puede causar fallos en producción.

3. Tipos de Pruebas

3.1 Pruebas Unitarias

  • Comprueban una única unidad (función, método, clase) en aislamiento.
  • Las dependencias se mockean: se simulan con implementaciones falsas que devuelven resultados controlados.
  • El código de pruebas debe estar separado del código funcional (carpetas distintas en el repositorio).
  • Si no se mockean las dependencias y algo falla, es más difícil localizar el origen del error.

Estructura típica: 

src/
  GestorTexto.js        ← código funcional
tests/
  GestorTexto.test.js   ← pruebas unitarias (importa GestorTexto)

3.2 Pruebas de Integración

Verifican la colaboración entre dos o más componentes (ya no se mockean las dependencias).

Tipos de integración: - Big Bang: se integran todos los componentes de golpe. Difícil trazar el origen de los fallos. - Bottom-Up: se integra de los componentes más elementales hacia arriba. Requiere simular los componentes superiores. - Top-Down (la más habitual): se integra de arriba hacia abajo, simulando los componentes inferiores que aún no están listos.

3.3 Pruebas Funcionales / de Validación

  • Comprueban que la funcionalidad del sistema integrado es correcta.
  • Suele participar el usuario final.
  • Pueden ser manuales (poner a un usuario a probar la app) o automatizadas (Selenium, Gherkin/Cucumber).

3.4 Pruebas de Sistema

  • Comprueban requisitos no funcionales: rendimiento, seguridad (penetration testing), resiliencia, capacidad de carga.
  • Las hacen especialistas (incluyendo "hackers éticos" para pruebas de seguridad).

3.5 Pruebas de Aceptación (Alfa / Beta) ⚠️ EXAMEN

Pruebas Alfa Pruebas Beta
Entorno El del equipo de desarrollo El del usuario final (sus máquinas, su infraestructura)
Participantes Equipo + representante de usuarios Usuarios reales
Control Alto (entorno conocido) Bajo (entorno heterogéneo)
En Scrum Sprint Review Despliegue en producción real

Diferencia práctica: en alfa, el equipo muestra el incremento en su entorno controlado. En beta, los usuarios lo ejecutan en sus propias máquinas y pueden aparecer problemas que no se detectaron en alfa (distintos SO, navegadores, resoluciones de pantalla, versiones de Python con distintas librerías nativas...).

Comparativa pruebas unitarias vs de aceptación:

Unitarias Aceptación
Quién las define Desarrollador Cliente / Product Owner
Qué prueban Métodos/clases individuales Comportamiento del producto completo
Cuándo se ejecutan Durante todo el desarrollo Para demostrar incrementos
Garantizan ausencia de errores No No (pero garantizan cumplir lo que el cliente especificó)

4. Selenium y Pruebas Extremo a Extremo

Selenium WebDriver permite automatizar la interacción de un usuario con el navegador desde código (Java, Python, Ruby, JavaScript, Kotlin...).

Funcionamiento básico:

from selenium import webdriver
from selenium.webdriver.common.by import By

driver = webdriver.Chrome()
driver.get("https://mi-aplicacion.com")

# Encontrar un campo de texto por nombre y escribir
campo = driver.find_element(By.NAME, "myText")
campo.send_keys("texto de prueba")

# Encontrar el botón por selector CSS y hacer clic
boton = driver.find_element(By.CSS_SELECTOR, "button")
boton.click()

# Verificar resultado
titulo = driver.title
assert "Resultado esperado" in titulo

Problema de los timeouts: en aplicaciones web modernas (SPA, React...) el contenido puede tardar en renderizarse porque hay peticiones a APIs y JavaScript que se ejecuta después de cargar el HTML. Es necesario esperar a que los elementos estén disponibles antes de interactuar con ellos. Los implicit waits (esperas fijas) son menos recomendables que los explicit waits (esperar hasta que una condición se cumpla).

Equivalente para aplicaciones móviles: Appium sigue el mismo principio que Selenium pero para aplicaciones Android/iOS en simuladores o dispositivos reales.

5. Gherkin y BDD (introducción)

Gherkin es el lenguaje que usan frameworks como Cucumber para definir pruebas de aceptación en formato legible por humanos no técnicos.

Feature: Búsqueda de gasolineras

  Scenario: Usuario busca gasolineras por ciudad
    Given que el usuario está en la pantalla de búsqueda
    When introduce "Madrid" en el campo de ciudad
    And pulsa el botón "Buscar"
    Then se muestran al menos 10 resultados
    And cada resultado incluye el precio del combustible
  • El cliente o Product Owner puede definir el comportamiento en Gherkin (con ayuda del tester).
  • Un framework como Cucumber traduce cada línea Given/When/Then a código de prueba ejecutable.
  • Las pruebas de aceptación en Gherkin son a la vez documentación y especificación ejecutable.

6. Refuerzo: Revisión de Actividad 2

6.1 Estructura de la actividad y apartados

La Actividad 2 pedía: 1. Introducción (descripción de la aplicación, modelos de servicio cloud). 2. Diseño arquitectónico con 3 patrones y diagrama. 3. Diseño detallado con patrones GoF (tabla: problema, patrón, diagrama de clases). 4. Interfaz de usuario con 2 patrones de UI (indicando catálogo).

6.2 Modelos de servicio cloud ⚠️ EXAMEN

Para la app de búsqueda de combustibles, los modelos correctos son: - Desde el punto de vista del usuario final: SaaS (Software as a Service) — consume la aplicación terminada desde el navegador o la app móvil; no gestiona infraestructura. - Desde el punto de vista del equipo de desarrollo: PaaS (Platform as a Service) o combinación de PaaS+SaaS. El equipo despliega el backend en la plataforma del proveedor cloud; utiliza además servicios SaaS externos (API del ministerio, mapas, geolocalización). - IaaS (Infrastructure as a Service): reservado para escenarios que requieren control total sobre la infraestructura; generalmente se descarta para aplicaciones sencillas.

Error conceptual grave detectado en varios trabajos: describir la aplicación web como "servida desde un CDN". Un CDN (Content Delivery Network) es un servidor de contenido estático (imágenes, vídeos, JavaScript compilado...), no un servidor de aplicaciones. Una aplicación web con microservicios, lógica de negocio y API no se sirve desde un CDN.

6.3 Arquitectura: patrón Backend for Frontend (BFF) ⚠️ EXAMEN

En la arquitectura de la app de combustibles pueden aparecer distintos tipos de cliente (usuario móvil, usuario web, administrador, empresario de gasolinera). El patrón BFF implica que cada tipo de cliente tiene su propio backend:

graph TD
    MovilUsuario[App Móvil Usuario] --> BFF_Movil[Back Móvil]
    WebUsuario[Web Usuario] --> BFF_Web[Back Web]
    Admin[Panel Admin] --> BFF_Admin[Back Admin]
    BFF_Movil & BFF_Web & BFF_Admin --> Servicios[Microservicios compartidos\nEstaciones, Precios, Auth...]

Error común en diagramas: tener tres aplicaciones cliente que parecen completamente independientes, cada una con su propio servicio de estaciones. Lo correcto es que los microservicios (lógica de negocio) sean compartidos; los BFF son la capa de adaptación que expone a cada cliente los servicios que le son propios.

6.4 Consejos de redacción y presentación

  • Texto justificado (más elegante y acorde con plantillas académicas).
  • No usar punto y coma: siempre se puede sustituir por punto o coma.
  • En el índice siempre incluir números de página.
  • En APA 7, los elementos visuales son "figuras" (no "ilustraciones").
  • Las URLs en documentos deben ser clicables (añadir espacio al final o usar formato hipervínculo).
  • Los diagramas de arquitectura deben dibujarse, no copiarse de webs. El buscador de imágenes inverso de Google delata las copias.

Preguntas de Autoevaluación

  1. ⚠️ EXAMEN: Define verificación y validación. ¿Qué actividad de Scrum corresponde a cada una?
  2. ⚠️ EXAMEN: ¿Por qué TDD se considera más una técnica de diseño que de testing? Pon un ejemplo.
  3. ¿Qué es el mocking y por qué es importante en las pruebas unitarias?
  4. ⚠️ EXAMEN: Explica la diferencia entre pruebas alfa y pruebas beta. ¿Por qué pueden fallar las beta aunque las alfa pasaran?
  5. ¿Cuáles son los tres tipos de integración de componentes? ¿Cuál es el más habitual y por qué?
  6. ¿Qué herramienta se usa para automatizar pruebas extremo a extremo en aplicaciones web? ¿Y en aplicaciones móviles?
  7. ¿Por qué en las pruebas con Selenium es importante usar explicit waits en vez de implicit waits?
  8. ¿Qué es Gherkin? ¿Qué ventaja tiene para que el cliente participe en la definición de pruebas de aceptación?
  9. ⚠️ EXAMEN: ¿Por qué es incorrecto decir que una aplicación web se sirve "desde un CDN"? ¿Qué sirve realmente un CDN?
  10. En el patrón BFF, ¿qué elementos deben ser compartidos por todos los BFF? ¿Qué es lo que diferencia a cada BFF?
  11. ¿Cuáles son los tres modelos de servicio cloud que pueden aparecer en el apartado de modelos de la actividad/examen? Explica cuál corresponde a cada perspectiva (usuario final, desarrollador, infraestructura pura).
  12. Las pruebas unitarias garantizan la ausencia de errores si todas pasan en verde. ¿Verdadero o falso? Justifica.