Bienvenida
En resumen: La verificación pregunta «¿lo construimos bien?», la validación pregunta «¿construimos lo correcto?». El curso enseña las dos, con requisitos, historias, ejemplos y tests sobre una tienda.
Problema
Hecho exactamente según el requisito. Y aun así mal
El dueño de la tienda escribe en el encargo: «Envío gratis en pedidos de más de 50 €». El programador lo construye tal cual: un pedido de 50,00 € paga 4,90 € de envío, y con 50,01 € es gratis. El tester comprueba 50,00 € contra lo escrito. Todo coincide.
Sale la publicidad: «Envío gratis desde 50 €». Los primeros clientes con un carrito de justo 50 € escriben correos enfadados. El dueño pensaba «desde 50 €» y escribió «más de».
El programa no se equivocó en nada. Lo que estaba mal era el requisito, y nadie lo vio, porque todos comprobaban contra él.
La idea
Dos preguntas
La historia tiene dos preguntas distintas:
- ¿Lo construimos bien? ¿El programa hace lo que dice el requisito? Eso es verificación (verification). En la historia, pasó.
- ¿Construimos lo correcto? ¿El requisito es lo que el cliente de verdad quiere? Eso es validación (validation). En la historia, nadie la hizo.
Las dos se confunden porque suenan a «comprobar». La diferencia está en la vara de medir: en la verificación es lo escrito, en la validación es la necesidad real.
También pasa lo contrario. El requisito dice «desde 50 €» y el programa hace «más de 50 €». Entonces el requisito es correcto y el programa no lo cumple. Eso lo detecta la verificación.
Más precisamente, para curiosos
El glosario de ISTQB toma las definiciones de ISO 9000. Verificación: confirmación, mediante examen y evidencia objetiva, de que se han cumplido los requisitos especificados. Validación: lo mismo, pero para los requisitos de un uso previsto concreto, es decir, si el producto hace el trabajo para el que se pidió.
IEEE 1012 (el estándar de V&V, última edición de 2024) presenta las dos como actividades a lo largo de toda la vida de un sistema, no solo al final. También introduce el nivel de integridad (integrity level): cuanto más graves son las consecuencias de un fallo, más y más estricta es la comprobación. La tienda es un nivel bajo. El software de un dispositivo médico es alto, y ahí se llega a la verificación formal: una demostración matemática de que el modelo del sistema no puede entrar en un estado prohibido. Aquí no llegaremos tan lejos.
La idea
El ejemplo detecta las dos
¿Cómo se habría detectado el error a tiempo? Con una pregunta, antes de escribir código: «¿Y con justo 50,00 €?»
Un ejemplo concreto junta las dos comprobaciones. El dueño responde «gratis, claro», y el requisito se corrige (validación). Después, el mismo ejemplo se convierte en un test que comprueba el programa (verificación).
Así se verá este ejemplo en el módulo de escenarios. El lenguaje se llama Gherkin y se lee como una frase:
# language: esCaracterística: Envío gratis
Escenario: Pedido de justo 50 € Dado un carrito de 50,00 € Cuando hago el pedido Entonces el envío es de 0,00 €Por eso el curso mantiene juntos el análisis de negocio y las pruebas: el requisito y el test se encuentran en el ejemplo. La regla con la que trabajamos de aquí en adelante es la corregida: el envío es gratis en un pedido desde 50 € inclusive; si no, cuesta 4,90 €.
Pruébalo
¿Cuál de las dos?
La idea
Quién hace qué
Alrededor de un requisito hay cuatro roles. En un equipo pequeño una persona puede tener dos de ellos, pero sus preguntas son distintas.
- El dueño del producto (product owner) decide qué se construye y en qué orden. Responde por el valor: por qué esto y no otra cosa.
- El analista de negocio (business analyst) averigua qué hace falta de verdad. Pregunta, escucha a las partes interesadas, y escribe los requisitos, las historias y los ejemplos. Su pregunta es «¿qué problema resolvemos?».
- El programador construye la solución. Su pregunta es «¿cómo?».
- QA (quality assurance) comprueba, y no solo al final. Un buen tester pregunta «¿y con justo 50 €?» mientras el requisito todavía se está escribiendo.
La validación es sobre todo trabajo del analista y del dueño, y la verificación, de QA y del programador. El límite no es un muro: en la historia del envío, el tester habría salvado la validación con una sola pregunta.
Más precisamente, para curiosos
ISTQB separa el aseguramiento de la calidad (quality assurance) de las pruebas (testing). El aseguramiento trata del proceso: cómo trabajamos para que no aparezcan defectos (revisiones, estándares, formación). Las pruebas tratan del producto: encuentran los defectos que de todos modos están ahí, y son un tipo de control de calidad (quality control). En el trabajo, «QA» suele significar «tester». El curso enseña las dos cosas.
La idea
El camino del curso
El curso sigue el camino de una petición, desde la conversación con el cliente hasta el lanzamiento:
- Bienvenida: validación y verificación, por qué fallan los programas, qué es la calidad.
- Requisitos: a quién preguntar, cómo preguntar, los tipos de requisitos y qué hace bueno a uno.
- Historias y criterios de aceptación: «Como … quiero … para …», dividir las historias grandes, reglas y ejemplos.
- Escenarios con Gherkin: Dado, Cuando, Entonces; escenarios que el negocio lee.
- Trazabilidad: qué requisito está cubierto por qué y qué se toca cuando un requisito cambia.
- Pruebas estáticas: un defecto encontrado en el texto, antes de que haya programa.
- Técnicas de diseño de pruebas: clases, límites, tablas de decisión, estados. Por qué 49,99 €, 50,00 € y 50,01 € son tres pruebas distintas y 30 € y 40 € son una sola.
- Niveles, tipos y proceso: desde la prueba de un componente hasta la aceptación, el plan, el riesgo y el informe de defecto.
- No funcional: usabilidad, desempeño y seguridad como requisitos que se miden.
- Automatización: los escenarios se convierten en tests que se ejecutan solos.
- Validar con el cliente: pruebas de aceptación y medición tras el lanzamiento.
- Proyecto: los códigos promocionales desde la petición hasta el lanzamiento.
Las tareas se comprueban al instante. Más adelante escribirás escenarios y casos de prueba que se ejecutan contra la tienda correcta y contra versiones con errores reales.
La idea
El curso y las certificaciones
El curso sigue los programas de las instituciones más grandes del sector y cubre sus temas. No está acreditado por ninguna de ellas y no da certificado. Si te preparas para un examen, esta tabla te dice dónde está cada tema. Es una guía, no una promesa sobre el examen.
| Programa | Qué es | Módulos |
|---|---|---|
| ISTQB CTFL v4.0.1 | el nivel básico para testers | 0, 2, 3, 4, 5, 6, 7, 9 |
| ISTQB CT-AcT v1.0 | pruebas de aceptación | 2, 3, 8, 10 |
| IIBA BABOK Guide v3 | análisis de negocio | 1, 2, 4, 5, 10 |
| IREB CPRE Foundation Level 3.3.0 | ingeniería de requisitos | 0, 1, 2, 4 |
| ISO/IEC 25010:2023 | el modelo de calidad | 0, 8 |
| IEEE 1012-2024 | el marco de V&V | 0 |
Los términos se dan en español y, entre paréntesis, en inglés la primera vez que aparecen, porque en el trabajo y en el examen los encontrarás en inglés.
La idea
Qué necesitas saber
No necesitas programar. Casi todo el curso está en el lenguaje de los requisitos: frases, ejemplos, tablas y escenarios.
La excepción es el módulo «Automatización». Ahí los escenarios se convierten en código, y necesitas uno de los lenguajes del sitio hasta el módulo «Programas en el mundo real», donde están los tests de componentes. El mapa del curso lo indica en el módulo.
La tienda es la misma que en los otros cursos, en euros: productos, carrito, códigos promocionales, pedidos, envío y devolución. Sus reglas son reales, y la gente se equivoca con ellas.
Test