La Evolución de IEEE 829 a ISO 29119
IEEE 829 nos dio documentación estandarizada. Pero la documentación es solo una pieza del rompecabezas. ¿Qué hay del proceso? ¿De las técnicas? ¿Del vocabulario?
ISO 29119 intenta ser un estándar comprensivo y todo-en-uno para testing de software. Donde IEEE 829 se enfocó estrectamente en documentación, ISO 29119 cubre toda la disciplina.
Las Cinco Partes
Parte 1: Conceptos y Definiciones
Establece el vocabulario (300+ términos) y el framework conceptual. Proporciona un lenguaje común para que organizaciones se comuniquen precisamente.
Parte 2: Procesos de Testing
Define los procesos en tres capas:
- Proceso Organizacional — Política de testing, estrategia organizacional
- Proceso de Gestión — Planificación, monitoreo, control y completación
- Proceso Dinámico — Diseño, implementación, configuración de entorno, ejecución, reporte de incidentes
Parte 3: Documentación
Reemplaza a IEEE 829. Define plantillas incluyendo documentos organizacionales que IEEE 829 no tenía:
| Documento | Cuándo se Crea | Propósito |
|---|---|---|
| Política Organizacional | Una vez, se actualiza | Lineamientos organizacionales |
| Estrategia Organizacional | Una vez, se actualiza | Enfoque organizacional |
| Test Plan | Por proyecto/release | Plan de testing específico |
| Test Completion Report | Al final de la fase | Resumen de resultados |
| Test Status Report | Regularmente | Progreso actual |
| Test Case Specification | Durante diseño | Test cases específicos |
| Test Environment Requirements | Durante planificación | Infraestructura necesaria |
| Test Environment Readiness Report | Antes de ejecución | Confirmación de entorno listo |
Parte 4: Técnicas de Testing
Catálogo comprensivo de técnicas con instrucciones de aplicación:
| Categoría | Técnicas |
|---|---|
| Basadas en especificación | Equivalence partitioning, boundary value, decision tables, state transition, use case testing |
| Basadas en estructura | Statement, branch, condition, MC/DC, path testing |
| Basadas en experiencia | Error guessing, exploratory testing, checklist-based |
Parte 5: Testing Keyword-Driven
Define un framework para automatización basada en keywords. Es la parte menos adoptada — la mayoría de frameworks modernos (Playwright, Cypress) tienen sus propios enfoques.
ISO 29119 vs IEEE 829
| Aspecto | IEEE 829 | ISO 29119 |
|---|---|---|
| Alcance | Solo documentación | Procesos, documentación, técnicas, automatización |
| Partes | 1 documento | 5 partes |
| Documentación | 8 tipos | 12+ tipos incluyendo nivel organizacional |
| Procesos | No cubierto | Modelo de 3 capas |
| Técnicas | No cubierto | Catálogo completo |
| Estado | Reemplazado por ISO 29119 Parte 3 | Estándar internacional vigente |
La Controversia
ISO 29119 es uno de los estándares más controvertidos en testing.
Argumentos en Contra
En 2014, profesionales prominentes lanzaron una petición por su retiro (3,000+ firmas):
- Conflicto con valores Agile — Prescribe documentación pesada que contradice “software funcionando sobre documentación comprensiva”
- No existe talla única — Implica una sola forma correcta de testing
- Testing context-driven — Los críticos abogan por adaptar prácticas al contexto
- Input limitado de practicantes — Desarrollado principalmente por comités de estándares
- Presión de certificación — Preocupación por mandatos de cumplimiento
Argumentos a Favor
- Framework común — Referencia compartida, especialmente útil en outsourcing
- Guía, no mandato — El estándar dice explícitamente que puede adaptarse
- Cumplimiento regulatorio — Simplifica discusiones de compliance
- Captura de conocimiento — Documenta mejores prácticas
- Claridad contractual — Referencia neutral entre clientes y proveedores
La Visión Equilibrada
ISO 29119 es valioso como referencia pero dañino si se aplica rígidamente. Un profesional QA senior debe conocer qué contiene, cuándo agrega valor, cuándo es excesivo, y poder seleccionar partes relevantes.
Guía Práctica de Adopción
Para Industrias Reguladas
Adopta Partes 1-3 como framework organizacional. Usa Parte 4 como referencia.
Para Organizaciones Grandes con Testing Tercerizado
Usa Parte 2 (procesos) y Parte 3 (documentación) como base contractual.
Para Equipos Agile
Selecciona elementos útiles: terminología de Parte 1, técnicas de Parte 4 como referencia. Omite la documentación pesada de Parte 3.
Para Preparación de ISTQB
Conoce las 5 partes, su alcance y la relación con IEEE 829.
Ejercicio: Compara ISO 29119 con Tu Proceso Actual
Escenario: Eres consultor QA evaluando una empresa fintech. 80 desarrolladores, 20 testers, trabajan en Scrum, deben cumplir PCI-DSS para el módulo de pagos.
Proceso actual:
- Sin política o estrategia organizacional de testing
- Cada equipo Scrum tiene su propio enfoque
- Test cases en TestRail por user story
- Bug reports en Jira
- Reportes de sprint desde TestRail
- Sin documentación formal de técnicas
- Automatización con Playwright, sin keyword-driven
Tareas:
- Para cada parte de ISO 29119, evalúa qué elementos implementa la empresa (completo, parcial, nada)
- Dado el requisito PCI-DSS, ¿qué elementos priorizar?
- Dado el contexto Agile, ¿qué elementos omitir explícitamente y por qué?
Pista
Considera las necesidades duales: PCI-DSS demanda formalidad; Agile demanda flexibilidad. Aplica formalidad donde la regulación lo requiere (módulo de pagos) y mantén el resto liviano.
Solución
1. Evaluación
| Parte | Elemento | Estado |
|---|---|---|
| Parte 1 | Terminología compartida | Parcial (informal) |
| Parte 2 | Proceso organizacional | No implementado |
| Parte 2 | Proceso de gestión | Parcial (por equipo, inconsistente) |
| Parte 3 | Política organizacional | No implementado |
| Parte 3 | Test plans | Parcial (sprint-level) |
| Parte 3 | Test case specs | Completo (TestRail) |
| Parte 4 | Técnicas formales | No implementado |
| Parte 5 | Keyword-driven | No aplica |
2. Prioridades para PCI-DSS
- Política organizacional — Auditors PCI-DSS esperan políticas documentadas
- Proceso de gestión formal para módulo de pagos — Planificación, monitoreo y completación formal
- Documentación formal para módulo de pagos — Test plans, specs, reportes como evidencia
- Técnicas formales para security testing — Aplicación documentada de técnicas
3. Elementos a Omitir
- Parte 5: Keyword-driven — Playwright funciona bien, sin beneficio
- Documentación completa Parte 3 para features no-pago — TestRail y Jira son suficientes
- Proceso organizacional formal para todos los equipos — Conflicta con auto-organización Agile
- Documentación de técnicas para cada feature — Solo para features de alto riesgo
Insight clave: Aplica formalidad ISO 29119 proporcional al riesgo.
Puntos Clave
- ISO 29119 es un estándar comprensivo de 5 partes que cubre conceptos, procesos, documentación, técnicas y keyword-driven testing
- Reemplaza a IEEE 829 para documentación (Parte 3) agregando cobertura de procesos y técnicas
- Es controvertido — los críticos dicen que conflicta con Agile; los defensores valoran su framework comprensivo
- La adopción práctica debe ser context-driven: aplica formalidad donde la regulación o riesgo lo demande
- ISO 29119 es una referencia para seleccionar, no un libro de reglas rígido