Introduccion a IEEE 829
IEEE 829, formalmente conocido como “Standard for Software and System Test Documentation”, proporciona un formato estandarizado para documentacion de testing. Publicado originalmente en 1998 y actualizado en 2008, define plantillas para test plans, test designs, test cases, test procedures y test reports.
Aunque muchos equipos hoy usan enfoques agiles que favorecen documentacion ligera, IEEE 829 sigue siendo el estandar de referencia para entender que debe contener un test plan completo. Incluso si nunca escribes un documento IEEE 829 completo, conocer su estructura te hace mejor creando test plans de cualquier formato.
Secciones del Test Plan IEEE 829
1. Identificador del Test Plan
Un identificador unico para el documento, tipicamente incluyendo nombre del proyecto, version y fecha.
Ejemplo: TP-ProjectAlpha-v2.1-2026-03
2. Introduccion
Resumen breve del proyecto, el sistema bajo test y el proposito de este test plan. Incluye referencias a documentos relacionados.
3. Items de Test
Lista los items de software especificos (modulos, features, componentes) que se prueban, incluyendo numeros de version.
- Modulo de Autenticacion de Usuarios v3.2.1
- Servicio de Procesamiento de Pagos v1.4.0
- Motor de Notificaciones v2.0.0
- API Gateway REST v5.1.2
4. Features a Probar
Enumera que features seran probadas y que caracteristicas de calidad aplican.
| Feature | Funcional | Rendimiento | Seguridad | Usabilidad |
|---|---|---|---|---|
| Login de usuario | Si | Si | Si | Si |
| Reset de password | Si | No | Si | Si |
| Checkout de pago | Si | Si | Si | Si |
| Carga de dashboard | Si | Si | No | Si |
| Notificaciones email | Si | No | No | No |
5. Features que No Se Probaran
Declara explicitamente que features estan excluidas del testing y la justificacion.
- Scripts de migracion de BD admin — manejados por el equipo DBA con validacion separada
- SDK de analytics de terceros — probado por el vendor, solo probamos el punto de integracion
- Modulo de reportes legacy — programado para deprecacion en Q2
Esta seccion es critica. Exclusiones no declaradas llevan a culpas cuando bugs se escapan.
6. Enfoque
Describe el enfoque general de testing para cada item o grupo de features.
Enfoque de testing funcional:
- Derivar test cases de requisitos usando particion de equivalencia y analisis de valores limite
- Automatizar suite de regresion cubriendo todos los caminos criticos
- Testing exploratorio manual para features nuevas cada sprint
Enfoque de testing de rendimiento:
- Load test base a 5,000 usuarios concurrentes
- Stress test hasta 20,000 usuarios
- Endurance test por 48 horas a carga normal
7. Criterios de Paso/Fallo
Define que constituye paso o fallo para cada item de test.
- Unit tests: 100% tasa de paso, minimo 80% cobertura de codigo
- Integration tests: 100% tasa de paso para caminos criticos, 95% general
- System tests: Cero bugs criticos/altos, menos de 5 bugs medios
- Performance tests: P95 tiempo de respuesta < 2 segundos, tasa de error < 0.1%
8. Criterios de Suspension y Reanudacion
Criterios de suspension — cuando detener el testing:
- Mas de 20% de test cases bloqueados por el mismo defecto
- Entorno de test inestable (mas de 3 caidas no planificadas por dia)
- Defecto critico de build impidiendo funcionalidad core
Criterios de reanudacion — cuando reanudar:
- Defecto bloqueante resuelto y verificado
- Estabilidad del entorno confirmada por 4 horas consecutivas
- Nuevo build desplegado con fix verificado
9. Entregables del Test
Lista todos los documentos y artefactos producidos durante el testing.
10. Entorno de Test
Especifica requisitos de hardware, software, red y herramientas.
11. Responsabilidades
| Rol | Persona | Responsabilidades |
|---|---|---|
| Test Manager | Jane Smith | Aprobacion del plan, asignacion de recursos |
| QA Lead | John Doe | Diseno de tests, coordinacion diaria |
| QA Engineer | Alice Brown | Ejecucion de tests, reporte de bugs |
| DevOps | Bob Wilson | Setup de entorno, CI/CD pipeline |
12. Cronograma
Define milestones, fases y fechas limite para cada actividad de testing.
13. Riesgos y Contingencias
Identifica riesgos especificos de este esfuerzo de testing con planes de mitigacion.
14. Aprobaciones
Seccion de sign-off para stakeholders que deben aprobar el test plan.
Ejercicio: Escribe un Test Plan IEEE 829
Crea un test plan para una aplicacion de banca en linea. El sistema tiene: gestion de cuentas, transferencias de fondos (domesticas e internacionales), pago de servicios, vista de portafolio de inversiones y deposito de cheques movil.
Escribe las 14 secciones, adaptando la profundidad a la complejidad de cada feature.
Pista
Prioriza testing de seguridad para todas las transacciones financieras. Las transferencias internacionales tienen requisitos de cumplimiento regulatorio. El deposito movil de cheques involucra procesamiento de imagenes y OCR.Solucion
1. Identificador: TP-OnlineBanking-v1.0-2026-03
2. Introduccion: Test plan para SecureBank Online Banking Platform v4.0, cubriendo interfaces web y movil para clientes personales.
3. Items de Test: Account Service v4.0, Transfer Service v3.2, Bill Pay Service v2.1, Investment View v1.5, Mobile Deposit v1.0
4. Features Probadas: Los cinco modulos — funcional, rendimiento, seguridad, usabilidad, accesibilidad
5. No Probadas: Reconciliacion back-office interna (equipo separado), integracion ATM (equipo hardware), internos de API de credit score
6. Enfoque: Basado en riesgos — transferencias y pagos = critico (100% automatizacion + scan de seguridad), gestion de cuentas = alto (90% automatizacion), vista inversiones = medio (funcional + exploratorio), deposito movil = alto (funcional + edge cases de imagen)
7. Paso/Fallo: Cero bugs criticos, cero vulnerabilidades OWASP Top 10, P95 < 1.5s para transferencias, 100% precision en calculos financieros
8. Suspension: Cualquier bug de corrupcion de datos, cualquier brecha de seguridad, errores en calculo de montos
9. Entregables: Test plan, 450+ test cases, reportes diarios, reportes de scan de seguridad, resultados de rendimiento, reporte resumen
10. Entorno: Staging espejo de produccion, datos anonimizados, payment gateway sandbox, APIs regulatorias mock
11. Responsabilidades: Test Manager (aprobacion), QA Lead (diseno), 3 QA Engineers (ejecucion), Security Engineer (penetration testing), DevOps (entorno)
12. Cronograma: Sprint 1-2: Diseno. Sprint 3-5: Ejecucion fase 1. Sprint 6-7: Fase 2 + rendimiento. Sprint 8: Seguridad + UAT.
13. Riesgos: Cambios regulatorios — monitoreo semanal. Downtime de payment gateway — mock fallback. Fragmentacion de dispositivos moviles — top 10 dispositivos.
14. Aprobaciones: CTO, Head of Product, Compliance Officer, QA Director
Adaptando IEEE 829 para Agile
En agile, no escribes un test plan de 50 paginas al inicio. En cambio:
- Manten un test plan vivo — actualizalo cada sprint en tu wiki (Confluence, Notion)
- Combina secciones 4-5 en una tabla de alcance simple actualizada por sprint
- Reemplaza seccion 12 (cronograma) con cadencia de testing basada en sprints
- Automatiza seccion 9 — la mayoria de entregables son generados por CI/CD
- Enfocate en secciones 6-8 — enfoque, criterios de paso/fallo y suspension son las mas valiosas
El espiritu de IEEE 829 — estructurado, trazable, explicito sobre alcance y criterios — sigue siendo relevante sin importar la metodologia.
Puntos Clave
- IEEE 829 define 14 secciones para un test plan completo
- Secciones criticas: features probadas/no probadas, enfoque, criterios de paso/fallo y suspension
- Adaptar para agile manteniendolo ligero, vivo y enfocado en sprints
- El estandar proporciona estructura para pensar sobre testing — incluso si no lo sigues literalmente
- Siempre declara que NO se prueba — esto previene culpas cuando areas no probadas tienen bugs