¿Por Qué Estándares para Documentación?
Cuando cambias de trabajo, encuentras nuevos planes de prueba, nuevos formatos de reportes, nuevas formas de organizar test cases. Cada organización parece reinventar la documentación. IEEE 829 existe para resolver este problema proporcionando un framework estandarizado.
¿Qué Es IEEE 829?
IEEE 829 (oficialmente “IEEE Standard for Software and System Test Documentation”) define un conjunto de documentos que cubren todo el proceso de testing. Publicado originalmente en 1998 y actualizado en 2008, sigue siendo el estándar de documentación más referenciado.
Define ocho tipos de documentos en tres grupos:
Los Ocho Tipos de Documentos
1. Test Plan
Propósito: El documento maestro que describe todo el esfuerzo de testing — alcance, enfoque, recursos, cronograma y responsabilidades.
Secciones clave: Identificador, introducción, ítems de prueba, features a probar/no probar, enfoque, criterios de aprobación/falla, criterios de suspensión/reanudación, entregables, tareas y cronograma, necesidades ambientales, responsabilidades, riesgos y contingencias, aprobaciones.
En la práctica moderna: El test plan sigue siendo el documento IEEE 829 más usado. Incluso equipos que no siguen IEEE 829 formalmente crean alguna versión. En Agile puede ser un documento liviano actualizado cada sprint.
2. Test Design Specification
Propósito: Describe el enfoque detallado para probar una feature específica. Conecta el test plan de alto nivel con los test cases específicos.
Ejemplo: Para una feature de login, podría definir: “Probar usando equivalence partitioning para el campo de usuario y boundary value analysis para el campo de contraseña.”
3. Test Case Specification
Propósito: Documenta test cases individuales con suficiente detalle para que un tester los ejecute.
Ejemplo:
| Campo | Contenido |
|---|---|
| ID | TC-LOGIN-003 |
| Descripción | Login con email válido y contraseña de longitud mínima |
| Precondiciones | Cuenta de usuario existe con contraseña “Pass1234” (8 chars) |
| Input | Email: user@test.com, Password: Pass1234 |
| Resultado Esperado | Usuario redirigido al dashboard, sesión creada |
4. Test Procedure Specification
Propósito: Describe el procedimiento paso a paso para ejecutar uno o más test cases.
En la práctica moderna: Menos común como documento separado. La mayoría de equipos incluyen los pasos dentro del test case o confían en scripts automatizados.
5. Test Log
Propósito: Registro cronológico de actividades y resultados de testing. Captura qué realmente pasó durante la ejecución.
En la práctica moderna: Las herramientas de gestión de pruebas (TestRail, Xray, Zephyr) generan test logs automáticamente.
6. Test Incident Report
Propósito: Documenta cualquier evento durante testing que requiere investigación — típicamente un fallo de test. Es esencialmente un bug report en términos modernos.
En la práctica moderna: Se mapea directamente a bug reports en Jira, GitHub Issues o Azure DevOps.
7. Test Item Transmittal Report
Propósito: Documenta la entrega de ítems de prueba (builds, configuraciones) de desarrollo a testing.
En la práctica moderna: Mayormente reemplazado por pipelines CI/CD y notas de deployment.
8. Test Summary Report
Propósito: Resume el esfuerzo de testing y resultados al final de una fase o proyecto. Proporciona los datos necesarios para decisiones de release.
Secciones clave: Identificador, variaciones (desviaciones del plan), evaluación de comprensividad (cobertura lograda), resumen de resultados, evaluación general, resumen de actividades, aprobaciones.
Este es uno de los documentos más críticos porque influye directamente en la decisión go/no-go de release.
Cuándo Usar IEEE 829
Cumplimiento Completo Apropiado
- Industrias reguladas (salud, aviación, finanzas, defensa)
- Contratos gubernamentales requiriendo documentación formal
- Sistemas de seguridad crítica
- Proyectos grandes con múltiples equipos de testing
Enfoque Adaptado/Liviano Mejor
- Equipos Agile/Scrum con entrega iterativa
- Startups construyendo MVPs
- Herramientas internas con pocas personas usuarias
- Proyectos con herramientas maduras de gestión de pruebas
El Punto Medio Práctico
- Siempre crear: Test Plan, Test Summary Report
- Crear cuando se necesite: Test Case Specifications, Test Incident Reports
- Frecuentemente automatizado: Test Logs, Test Procedures
- Raramente necesario: Test Design Specifications, Test Item Transmittal Reports
IEEE 829 en el Syllabus de ISTQB
IEEE 829 se referencia en el ISTQB Foundation Level. Para la certificación, debes conocer los ocho tipos de documentos, sus propósitos, y cuándo la documentación formal vs liviana es apropiada.
Ejercicio: Mapea IEEE 829 a Tu Proyecto
Escenario: Eres QA Lead en una empresa de e-commerce. Tu equipo usa Jira para gestión de proyectos, TestRail para gestión de pruebas, y GitHub Actions para CI/CD. Siguen Scrum con sprints de 2 semanas.
Documentación actual:
- Un documento de estrategia de testing (actualizado anualmente)
- Test cases en TestRail (organizados por feature)
- Bug reports en Jira
- Reportes de testing por sprint (automatizados desde TestRail)
- Release notes en GitHub
Tareas:
- Mapea cada documento actual al tipo de documento IEEE 829 correspondiente
- Identifica qué documentos IEEE 829 te faltan — para cada uno decide: (a) necesario agregar, (b) cubierto por herramientas, (c) no necesario
- Si tu empresa necesitara cumplir PCI-DSS para un nuevo feature de pagos, ¿qué documentos IEEE 829 adicionales necesitarías formalizar?
Pista
Lista los 8 documentos IEEE 829 y ve cuáles de tus documentos actuales se mapean a cada uno. Recuerda que las herramientas modernas frecuentemente combinan múltiples tipos. Para PCI-DSS, piensa en qué necesitan ver los auditores.
Solución
1. Mapeo
| Documento Actual | Equivalente IEEE 829 |
|---|---|
| Estrategia de testing | Test Plan (parcialmente) |
| Test cases en TestRail | Test Case Specification |
| Bug reports en Jira | Test Incident Report |
| Reportes por sprint | Test Summary Report (parcialmente) |
| Release notes | Test Item Transmittal Report (parcialmente) |
2. Documentos Faltantes
| Documento IEEE 829 | Estado | Decisión |
|---|---|---|
| Test Plan | Parcialmente cubierto | (a) Agregar planes por sprint |
| Test Design Specification | Faltante | (c) No necesario — TestRail organiza por feature |
| Test Case Specification | Cubierto | (b) Cubierto por herramientas |
| Test Procedure Specification | Faltante | (b) Cubierto — pasos dentro de test cases |
| Test Log | Faltante como formal | (b) Cubierto — TestRail auto-genera |
| Test Incident Report | Cubierto | (b) Cubierto por Jira |
| Test Item Transmittal Report | Parcialmente cubierto | (c) No necesario — CI/CD maneja |
| Test Summary Report | Parcialmente cubierto | (a) Agregar reportes comprensivos de release |
3. Documentos Adicionales para PCI-DSS
- Test Plan formal para el módulo de pagos con alcance de testing PCI-DSS
- Test Log formal con timestamps y identificación de testers
- Test Summary Report comprensivo con resultados de security testing
- Test Incident Reports formales para todos los defectos de seguridad
- RTM con trazabilidad entre requisitos PCI-DSS y test cases
Puntos Clave
- IEEE 829 define 8 documentos estandarizados cubriendo planificación, especificación y reporte
- Test Plan y Test Summary Report son los más universalmente aplicables
- Las herramientas modernas automatizan mucho de lo que IEEE 829 define
- El cumplimiento completo es más importante en industrias reguladas
- La mayoría de equipos se benefician de un enfoque híbrido
- El estándar proporciona un vocabulario común para documentación de testing