Cuando el Software Puede Dañar Personas
La mayoría de bugs de software son molestos — un botón roto, una página lenta, un error de formato. Pero en algunas industrias, los bugs pueden lesionar o matar personas, causar fraude financiero o comprometer la seguridad nacional.
En estas industrias reguladas, gobiernos y organismos de la industria exigen estándares específicos. El testing en estos entornos va mucho más allá del QA típico — requiere validación, documentación formal, audit trails y aprobación regulatoria.
Salud y Dispositivos Médicos
Estándares Clave
| Estándar | Alcance | Organismo |
|---|---|---|
| FDA 21 CFR Part 11 | Registros electrónicos y firmas | FDA de EE.UU. |
| IEC 62304 | Ciclo de vida de software de dispositivos médicos | Internacional |
| ISO 14971 | Gestión de riesgos para dispositivos médicos | Internacional |
| HIPAA | Privacidad y seguridad de datos de salud | HHS de EE.UU. |
| EU MDR | Regulación de dispositivos médicos | Unión Europea |
Requisitos de Testing
Validación de Software (FDA): La FDA requiere que el software de dispositivos médicos sea “validado” — es decir, que exista evidencia documentada de que el software produce consistentemente resultados que cumplen especificaciones predeterminadas.
Validación incluye:
- Installation Qualification (IQ) — ¿el software está correctamente instalado?
- Operational Qualification (OQ) — ¿el software funciona según las especificaciones?
- Performance Qualification (PQ) — ¿el software funciona correctamente en el entorno real?
Testing Basado en Riesgo (ISO 14971): Cada función debe evaluarse por riesgo para la seguridad del paciente.
Audit Trails: Cada acción en un sistema médico debe registrarse — quién accedió a datos del paciente, cuándo y qué cambios se hicieron. Estos registros deben ser a prueba de manipulación.
Trazabilidad: Trazabilidad completa de requisitos a diseño a test cases a resultados a defectos. No es opcional — los auditores lo verificarán.
Finanzas
Estándares Clave
| Estándar | Alcance | Organismo |
|---|---|---|
| PCI-DSS | Seguridad de datos de tarjetas de pago | PCI Security Council |
| SOX | Integridad de reportes financieros | Congreso de EE.UU. |
| Basel III/IV | Gestión de riesgos bancarios | Comité de Basilea |
| GDPR/CCPA | Privacidad de datos | UE/EE.UU. |
Requisitos de Testing
PCI-DSS: Cualquier sistema que almacene, procese o transmita datos de tarjetas de crédito debe cumplir con PCI-DSS, requiriendo escaneo de vulnerabilidades trimestral, penetration testing anual, revisión de código seguro y verificación de controles de acceso.
SOX: Requiere integridad de datos en sistemas financieros — cálculos precisos, datos que no puedan alterarse sin autorización, controles de acceso, y procedimientos de backup funcionales.
Automotriz
Estándares Clave
| Estándar | Alcance | Organismo |
|---|---|---|
| ISO 26262 | Seguridad funcional para vehículos | ISO |
| ASPICE | Mejora de procesos de software automotriz | VDA |
| MISRA | Estándares de codificación | MISRA Consortium |
Niveles ASIL (ISO 26262)
| Nivel ASIL | Ejemplo | Requisitos de Testing |
|---|---|---|
| A | Control de iluminación interior | Testing funcional básico |
| B | Sistemas de luces | Testing sistemático, cobertura de requisitos |
| C | Cruise control | Testing basado en requisitos, inyección de fallos |
| D | Sistema de frenos, dirección | Testing exhaustivo, métodos formales, verificación independiente |
Aviación
DO-178C
Los niveles DAL (Design Assurance Level) van de A a E:
| DAL | Condición de Falla | Ejemplo |
|---|---|---|
| A | Catastrófica | Software de control de vuelo |
| B | Peligrosa | Monitoreo de motor |
| C | Mayor | Display de navegación |
| D | Menor | Entretenimiento de cabina |
| E | Sin efecto | Registro de mantenimiento |
El software DAL A requiere Modified Condition/Decision Coverage (MC/DC) — la forma más rigurosa de análisis de cobertura de código.
Farmacéutica
Categorías GAMP 5
| Categoría | Tipo | Esfuerzo de Validación | Ejemplo |
|---|---|---|---|
| 1 | Infraestructura | Mínimo | Sistemas operativos, bases de datos |
| 3 | Productos no configurados | Bajo | Software comercial estándar |
| 4 | Productos configurados | Medio | Sistemas ERP, LIMS |
| 5 | Aplicaciones personalizadas | Alto | Sistemas de laboratorio a medida |
Requisitos Comunes en Industrias Reguladas
1. Validación vs Verificación
| Concepto | Pregunta que Responde | Ejemplo |
|---|---|---|
| Verificación | “¿Construimos el producto correctamente?” | ¿El código cumple la especificación? |
| Validación | “¿Construimos el producto correcto?” | ¿El producto cumple las necesidades reales del usuario? |
2. Documentación
El testing regulado produce significativamente más documentación: Plan de Validación, Protocolo de Validación, Reporte de Validación, Matriz de Trazabilidad, Evaluación de Riesgos, Registros de Control de Cambios.
3. Control de Cambios
Cualquier cambio a software validado debe pasar por un proceso formal: solicitud documentada, análisis de impacto, aprobación, implementación, testing de regresión, documentación actualizada.
4. Integridad de Datos (ALCOA+)
| Principio | Significado |
|---|---|
| Atribuible | ¿Quién generó los datos? |
| Legible | ¿Se pueden leer los datos? |
| Contemporáneo | ¿Se registró cuando ocurrió? |
| Original | ¿Es el registro original? |
| Apreciso | ¿Es correcto? |
| +Completo | ¿Están todos los datos incluidos? |
| +Consistente | ¿Hay contradicciones? |
| +Duradero | ¿Estará disponible durante todo el período de retención? |
| +Disponible | ¿Se puede acceder cuando se necesite? |
Compliance Testing Básico
- Mapeo de requisitos regulatorios a test cases específicos
- Recolección de evidencia documentada para auditores
- Análisis de brechas donde el software no cumple
- Testing de remediación después de correcciones
- Re-validación periódica según lo requiera la regulación
Ejercicio: Identifica Requisitos de Cumplimiento
Escenario: Eres QA Lead para una startup de salud construyendo una app de telemedicina. La app permite:
- Videollamadas con doctores
- Ver y descargar registros médicos (resultados de laboratorio, recetas)
- Pagar consultas con tarjeta de crédito
- Recibir recordatorios de medicación por push notification
La app se lanzará primero en EE.UU., luego se expandirá a la UE.
Tareas:
- ¿Qué estándares regulatorios aplican? Lista todos y explica por qué.
- Para cada estándar, identifica los 3 principales requisitos de testing.
- Crea un checklist de compliance testing (mínimo 15 ítems) organizado por regulación.
- ¿Cuáles serían las consecuencias del incumplimiento?
Pista
Piensa en qué datos maneja la app:
- Registros médicos → HIPAA, FDA
- Datos de tarjeta de crédito → PCI-DSS
- Expansión a UE → GDPR
- Recordatorios de medicación → Posible clasificación como dispositivo médico
Solución
1. Estándares Regulatorios Aplicables
| Estándar | Por Qué Aplica |
|---|---|
| HIPAA | La app maneja PHI (registros médicos, recetas) |
| FDA 21 CFR Part 11 | Registros médicos electrónicos y e-prescripciones |
| FDA SaMD | La app puede clasificarse como Software as a Medical Device |
| PCI-DSS | La app procesa pagos con tarjeta de crédito |
| GDPR | Expansión a UE significa procesar datos de ciudadanos europeos |
| ADA/Section 508 | Las apps de salud deben ser accesibles |
2. Top 3 Requisitos por Estándar
HIPAA: 1) Testing de encriptación (PHI cifrada en reposo y tránsito) 2) Testing de control de acceso 3) Testing de audit trail
PCI-DSS: 1) Penetration testing anual 2) Escaneo de vulnerabilidades trimestral 3) Testing de almacenamiento de datos
GDPR: 1) Testing de gestión de consentimiento 2) Testing de derechos del sujeto 3) Notificación de brechas de datos
3. Checklist de Compliance Testing
HIPAA: PHI cifrada en reposo, cifrada en tránsito, RBAC, audit trail, timeout de sesión, BAAs
PCI-DSS: Datos de tarjeta nunca en texto plano, tokenización, escaneos trimestrales, pen test anual, segmentación de red
GDPR: Consentimiento explícito, acceso a datos, eliminación de datos, DPIA, política de privacidad
Accesibilidad: WCAG 2.1 AA, compatibilidad con screen readers
4. Consecuencias del Incumplimiento
| Estándar | Consecuencia |
|---|---|
| HIPAA | Multas hasta $1.5M por categoría de violación por año |
| PCI-DSS | Multas $5K-100K/mes, pérdida de capacidad de procesar tarjetas |
| GDPR | Multas hasta 4% de facturación global anual o EUR 20M |
| FDA | Cartas de advertencia, recalls, acciones criminales |
Puntos Clave
- Las industrias reguladas requieren testing que va mucho más allá del QA típico
- Las industrias clave incluyen salud (FDA/HIPAA), finanzas (PCI-DSS/SOX), automotriz (ISO 26262), aviación (DO-178C) y farma (GAMP 5)
- Todas comparten requisitos comunes: trazabilidad, control de cambios, integridad de datos y verificación independiente
- El incumplimiento puede resultar en multas severas, recalls y enjuiciamiento criminal
- El rigor del testing es proporcional al riesgo — mayor riesgo para la vida requiere testing más exhaustivo