Los contratos de testing y SLAs son la capa de gobernanza que transforma expectativas informales de calidad en compromisos profesionales con responsabilidad. Según la Encuesta de Outsourcing TI de Gartner 2024, las organizaciones con SLAs formales de testing experimentan un 47% menos de incidentes de producción post-release comparado con quienes operan con acuerdos verbales. La investigación del SEI muestra que la ambigüedad de alcance representa el 52% de los fallos en engagements de QA — no las brechas de capacidad técnica. Un contrato bien estructurado protege a ambas partes: da a los equipos de QA autoridad clara para definir límites de cobertura y da a los stakeholders entregables medibles para exigir responsabilidad.
TL;DR: Un contrato de testing define el alcance (qué se prueba y explícitamente qué no), métricas SLA (tasa de detección de defectos, cobertura mínima, tiempos de respuesta), entregables con criterios de aceptación y un proceso de control de cambios. La sección de alcance previene disputas; la sección SLA habilita la responsabilidad. Negocia solo métricas medibles.
Introducción
Los contratos de testing y Acuerdos de Nivel de Servicio (SLAs) establecen expectativas claras, responsabilidades y estándares de calidad entre los equipos de QA y sus stakeholders. Ya sea gestionando operaciones de QA internas o trabajando con proveedores externos de testing, los contratos bien definidos aseguran responsabilidad, resultados medibles y expectativas alineadas entre todas las partes.
Esta documentación proporciona orientación integral sobre la creación, negociación y gestión de contratos de testing y SLAs que protegen los intereses organizacionales mientras fomentan asociaciones productivas y entregan valor medible.
Los contratos de testing se basan en el Test Plan acordado y definen las Testing Metrics and KPIs que servirán como indicadores de rendimiento. Los entregables contractuales típicamente incluyen Test Summary Reports y documentación de Defect Life Cycle.
Definición del Alcance del Contrato
Alcance de Servicios de Testing
Servicios de Testing Funcional:
functional_testing_scope:
included_services:
- Planificación y desarrollo de estrategia de testing
- Diseño y documentación de casos de prueba
- Ejecución manual de tests (regresión, smoke, exploratoria)
- Registro y seguimiento de defectos
- Reportes y métricas de testing
- Soporte para pruebas de aceptación de usuario
testing_types_covered:
- Testing funcional (UI, lógica de negocio)
- Testing de integración (API, sistema)
- Testing de regresión
- Smoke testing
- Sanity testing
- Pruebas de aceptación de usuario (UAT)
excluded_services:
- Testing de rendimiento y carga
- Testing de seguridad y penetración
- Testing en dispositivos móviles (a menos que se especifique)
- Testing de accesibilidad
- Testing de localización
- Soporte de producción y monitoreo
environments:
- Entorno de desarrollo (dev)
- Entorno de QA/Testing
- Entorno de staging/pre-producción
- Producción (solo smoke testing)
testing_hours:
coverage: "Horario comercial (9 AM - 6 PM EST)"
timezone: "Eastern Standard Time (EST)"
weekends: "No incluido (disponible con tarifa premium)"
holidays: "Sigue calendario de festivos del cliente"
Servicios de Testing de Automatización:
automation_services_scope:
deliverables:
- Configuración de framework de automatización
- Desarrollo de scripts de pruebas automatizadas
- Mantenimiento y mejora de suite de tests
- Integración con pipeline CI/CD
- Ejecución de suite de regresión automatizada
- Análisis de resultados y reportes
technologies_supported:
web_automation:
- Selenium WebDriver
- Playwright
- Cypress
api_automation:
- RestAssured
- Postman/Newman
- Karate DSL
mobile_automation:
- Appium
- Espresso (Android)
- XCUITest (iOS)
automation_coverage_targets:
year_1: "40% de casos de prueba de regresión"
year_2: "70% de casos de prueba de regresión"
year_3: "85% de casos de prueba de regresión"
maintenance_and_support:
- Mantenimiento semanal de scripts (tests inestables, actualizaciones)
- Actualizaciones de framework (trimestral)
- Automatización de nuevas features (dentro del alcance)
- Actualizaciones de documentación
Límites del Proyecto
Actividades Dentro del Alcance:
## Contrato de Testing - Dentro del Alcance
### Planificación de Testing
- Creación de documento de estrategia de testing
- Desarrollo de plan de testing
- Evaluación y planificación de mitigación de riesgos
- Asignación de recursos y programación
- Definición de requisitos de entorno de testing
### Diseño de Testing
- Identificación de escenarios de prueba
- Diseño y documentación de casos de prueba
- Estrategia de preparación de datos de prueba
- Creación de matriz de trazabilidad
- Ciclos de revisión y aprobación
### Ejecución de Testing
- Ejecución manual de tests según calendario acordado
- Ejecución automatizada de tests (si está contratado)
- Identificación y registro de defectos
- Verificación y cierre de defectos
- Testing de regresión
- Re-testing después de correcciones
### Reporte y Comunicación
- Actualizaciones diarias de estado (escritas)
- Reportes de progreso semanales
- Seguimiento de métricas y KPIs de testing
- Participación en reuniones con stakeholders
- Evaluación de criterios de salida
- Reporte de resumen final de testing
### Aseguramiento de Calidad
- Revisiones por pares de casos de prueba
- Seguimiento de métricas de calidad
- Verificación de cumplimiento de procesos
- Implementación de mejores prácticas
- Iniciativas de mejora continua
Actividades Fuera del Alcance:
## Contrato de Testing - Fuera del Alcance
### Explícitamente Excluido
- Recopilación y análisis de requisitos (a menos que se especifique)
- Actividades de análisis de negocio
- Desarrollo de aplicaciones o corrección de bugs
- Actividades de despliegue en producción
- Soporte de producción (a menos que se especifique)
- Configuración de infraestructura (más allá de entornos de testing)
- Adquisición de herramientas de terceros
- Capacitación para personal del cliente (a menos que se especifique)
### Requiere Solicitud de Cambio
- Expansión del alcance más allá de módulos acordados
- Tipos de testing adicionales no contratados
- Testing fuera de horas/días acordados
- Entornos adicionales no especificados
- Cambios de herramientas a mitad de contrato
- Solicitudes de aumento de recursos
Entregables e Hitos
Entregables Clave
| Entregable | Descripción | Cronograma | Criterios de Aceptación |
|---|---|---|---|
| Estrategia de Testing | Documento de enfoque de alto nivel | Semana 1 | Aprobado por stakeholders en 3 días hábiles |
| Plan de Testing | Plan detallado con cronograma | Semana 2 | Cubre todas las features en alcance, aprobado por cliente |
| Casos de Prueba | Escenarios y pasos documentados | Semana 3-4 | Trazabilidad a requisitos, revisado por pares |
| Entorno de Testing | Entorno configurado y validado | Semana 2 | Todas las aplicaciones accesibles, datos de prueba cargados |
| Framework de Automatización | Configuración y scripts de ejemplo | Semana 4 | Framework ejecuta tests de ejemplo exitosamente |
| Reportes de Ejecución | Estado de ejecución diario/semanal | Continuo | Entregado dentro de 24 horas de ejecución |
| Reportes de Defectos | Defectos registrados con detalles | Continuo | Registrado dentro de 4 horas del descubrimiento |
| Dashboard de Métricas | Visualización de métricas de calidad | Semana 3 | Actualizado diariamente, accesible a stakeholders |
| Suite de Regresión | Suite de tests de regresión automatizada | Mes 3 | 70% tasa de aprobación en build estable |
| Reporte Resumen de Testing | Reporte final integral | Release -1 día | Incluye todas las métricas, evaluación de riesgos |
Cronograma de Hitos
## Hitos del Contrato de Testing - Proyecto de Ejemplo
### Fase 1: Configuración y Planificación (Semanas 1-2)
**Hito:** Preparación para Testing
- [ ] Estrategia de testing aprobada
- [ ] Plan de testing aprobado
- [ ] Entorno de testing configurado
- [ ] Equipo incorporado y capacitado
- [ ] Herramientas y accesos provisionados
**Pago:** 15% del valor del contrato
### Fase 2: Preparación de Testing (Semanas 3-4)
**Hito:** Diseño de Testing Completo
- [ ] Casos de prueba documentados (100%)
- [ ] Datos de prueba preparados
- [ ] Matriz de trazabilidad completa
- [ ] Casos de prueba revisados y aprobados
- [ ] Framework de automatización configurado (si aplica)
**Pago:** 20% del valor del contrato
### Fase 3: Ejecución de Testing - Sprint 1 (Semanas 5-6)
**Hito:** Testing Sprint 1 Completo
- [ ] Todos los tests planificados ejecutados
- [ ] Defectos registrados y triados
- [ ] Reporte de testing entregado
- [ ] Tests de regresión aprobados
- [ ] Criterios de salida cumplidos
**Pago:** 15% del valor del contrato
### Fase 4: Ejecución de Testing - Sprint 2 (Semanas 7-8)
**Hito:** Testing Sprint 2 Completo
- [ ] Todos los tests planificados ejecutados
- [ ] Defectos críticos resueltos y verificados
- [ ] Suite de regresión actualizada ejecutada
- [ ] Reporte de testing entregado
- [ ] Criterios de salida cumplidos
**Pago:** 15% del valor del contrato
### Fase 5: Regresión y Soporte UAT (Semanas 9-10)
**Hito:** Soporte UAT Completo
- [ ] Testing de regresión completo aprobado
- [ ] Defectos UAT registrados y rastreados
- [ ] Soporte de tests UAT proporcionado
- [ ] Documentación actualizada
- [ ] Transferencia de conocimiento completa
**Pago:** 20% del valor del contrato
### Fase 6: Release y Cierre (Semana 11)
**Hito:** Preparación para Release Lograda
- [ ] Todos los defectos críticos/altos resueltos
- [ ] Plan de smoke test de producción entregado
- [ ] Reporte resumen final entregado
- [ ] Lecciones aprendidas documentadas
- [ ] Actividades de cierre de contrato completas
**Pago:** 15% del valor del contrato (pago final)
Acuerdos de Nivel de Servicio (SLAs)
Tiempos de Respuesta y Resolución
# Definiciones de SLA de Testing
defect_response_sla:
critical_severity:
definition: "Sistema caído, sin workaround, bloquea testing"
response_time: "1 hora"
resolution_target: "4 horas"
escalation: "Inmediato a QA Lead y Project Manager"
high_severity:
definition: "Funcionalidad mayor deteriorada, existe workaround"
response_time: "4 horas"
resolution_target: "24 horas"
escalation: "Después de 8 horas a QA Lead"
medium_severity:
definition: "Funcionalidad afectada, workaround aceptable"
response_time: "8 horas"
resolution_target: "3 días hábiles"
escalation: "Después de 2 días a QA Lead"
low_severity:
definition: "Problema menor, cosmético, documentación"
response_time: "24 horas"
resolution_target: "5 días hábiles"
escalation: "Después de 5 días a QA Lead"
test_execution_sla:
test_case_execution_rate:
target: "30 casos de prueba por tester por día (manual)"
measurement: "Promedio sobre sprint"
penalty_threshold: "< 20 casos de prueba por tester por día"
defect_logging_timeliness:
target: "Dentro de 4 horas del descubrimiento"
measurement: "Timestamp entre descubrimiento y creación en Jira"
penalty_threshold: "> 8 horas de retraso"
test_report_delivery:
daily_status: "Antes de 5 PM EST el mismo día"
weekly_report: "Cada viernes antes de 12 PM EST"
final_report: "Dentro de 24 horas de completar testing"
penalty_threshold: "Plazos perdidos > 2 veces por mes"
automation_stability:
target: "Tasa de tests inestables < 3%"
measurement: "Tests fallando intermitentemente / total tests automatizados"
penalty_threshold: "> 5% tasa inestable sostenida por 2 semanas"
communication_sla:
email_response:
business_hours: "Dentro de 4 horas"
after_hours: "Siguiente día hábil"
urgent_issues: "Dentro de 1 hora"
meeting_attendance:
daily_standup: "95% asistencia"
sprint_planning: "100% asistencia (mínimo QA Lead)"
retrospective: "100% asistencia"
status_reporting:
frequency: "Actualización escrita diaria antes de 5 PM"
format: "Template estandarizado"
distribution: "Todos los stakeholders en lista de distribución"
Métricas de Calidad y Objetivos
# Objetivos de Métricas de Calidad para Contrato
class QualityMetricsTargets:
def __init__(self):
self.metrics = {
# Métricas de Cobertura de Testing
'requirement_coverage': {
'target': 100,
'unit': 'porcentaje',
'measurement': 'Requisitos con casos de prueba / Total requisitos',
'penalty_threshold': 95,
'description': 'Todos los requisitos deben tener cobertura de testing'
},
'test_execution_coverage': {
'target': 95,
'unit': 'porcentaje',
'measurement': 'Tests ejecutados / Tests planificados',
'penalty_threshold': 90,
'description': 'Porcentaje de tests planificados ejecutados por sprint'
},
# Métricas de Calidad de Defectos
'defect_rejection_rate': {
'target': 10,
'unit': 'porcentaje',
'measurement': 'Defectos rechazados / Total defectos',
'penalty_threshold': 20,
'description': 'Defectos rechazados como no reproducibles o inválidos'
},
'defect_detail_completeness': {
'target': 95,
'unit': 'porcentaje',
'measurement': 'Defectos bien documentados / Total defectos',
'penalty_threshold': 85,
'description': 'Defectos con pasos, screenshots, logs, entorno'
},
# Métricas de Efectividad de Testing
'defect_detection_effectiveness': {
'target': 90,
'unit': 'porcentaje',
'measurement': 'Defectos encontrados en testing / Total defectos',
'penalty_threshold': 80,
'description': 'Efectividad del testing en encontrar defectos temprano'
},
'test_case_effectiveness': {
'target': 25,
'unit': 'porcentaje',
'measurement': 'Casos de prueba encontrando defectos / Total casos',
'penalty_threshold': 15,
'description': 'Balance entre testing exhaustivo y eficiente'
},
# Métricas de Automatización (si está contratado)
'automation_coverage': {
'target': 70,
'unit': 'porcentaje',
'measurement': 'Casos de prueba automatizados / Total tests regresión',
'penalty_threshold': 60,
'description': 'Al final del período del contrato'
},
'automation_pass_rate': {
'target': 95,
'unit': 'porcentaje',
'measurement': 'Tests automatizados aprobados / Total tests automatizados',
'penalty_threshold': 90,
'description': 'En builds estables, excluyendo problemas de entorno'
},
# Métricas de Productividad
'test_execution_velocity': {
'target': 30,
'unit': 'casos de prueba por día por tester',
'measurement': 'Promedio de casos de prueba manuales ejecutados',
'penalty_threshold': 20,
'description': 'Medido sobre sprint, excluye escenarios complejos'
},
# Métricas de Cumplimiento de Procesos
'test_case_review_completion': {
'target': 100,
'unit': 'porcentaje',
'measurement': 'Casos de prueba revisados / Total casos',
'penalty_threshold': 95,
'description': 'Todos los casos revisados por pares antes de ejecución'
},
'documentation_currency': {
'target': 100,
'unit': 'porcentaje',
'measurement': 'Documentos actualizados / Total documentos',
'penalty_threshold': 90,
'description': 'Artefactos actualizados dentro de 2 días de cambios'
}
}
def evaluate_compliance(self, actual_metrics):
"""Evaluar si las métricas reales cumplen obligaciones contractuales"""
results = {}
for metric_name, config in self.metrics.items():
actual_value = actual_metrics.get(metric_name)
if actual_value is None:
results[metric_name] = {
'status': 'NOT_MEASURED',
'message': 'Métrica no proporcionada'
}
continue
target = config['target']
threshold = config['penalty_threshold']
if actual_value >= target:
status = 'EXCEEDS'
elif actual_value >= threshold:
status = 'MEETS'
else:
status = 'BELOW_THRESHOLD'
results[metric_name] = {
'status': status,
'actual': actual_value,
'target': target,
'threshold': threshold,
'penalty_applicable': status == 'BELOW_THRESHOLD'
}
return results
Criterios de Aceptación
Aceptación de Entregables de Testing
## Criterios de Aceptación para Entregables de Testing
### Documento de Estrategia de Testing
**Criterios de Aceptación:**
- [ ] Se alinea con objetivos y restricciones del proyecto
- [ ] Cubre todos los tipos de testing en alcance
- [ ] Define criterios claros de entrada y salida
- [ ] Identifica riesgos y estrategias de mitigación
- [ ] Aprobado por stakeholders dentro de 3 días hábiles
- [ ] No más de 2 rondas de revisiones requeridas
### Casos de Prueba
**Criterios de Aceptación:**
- [ ] Trazable a requisitos (vía ID de requisito)
- [ ] Precondiciones, pasos y resultados esperados claros
- [ ] Revisado por pares sin hallazgos críticos
- [ ] Sigue template y convenciones de nombres acordadas
- [ ] Requisitos de datos de prueba claramente especificados
- [ ] Prioridad y severidad apropiadamente asignadas
### Reportes de Defectos
**Criterios de Aceptación:**
- [ ] Título claro y conciso resumiendo el problema
- [ ] Pasos detallados para reproducir (numerados)
- [ ] Resultado esperado vs real claramente establecido
- [ ] Screenshots/videos adjuntos (para defectos UI)
- [ ] Logs adjuntos (para defectos funcionales/API)
- [ ] Detalles de entorno especificados
- [ ] Severidad y prioridad apropiadamente asignadas
- [ ] Campos de asignado y componente poblados
### Reportes de Ejecución de Testing
**Criterios de Aceptación:**
- [ ] Estado de ejecución de todos los casos planificados registrado
- [ ] Estado Pass/Fail/Bloqueado claramente indicado
- [ ] Defectos vinculados a casos de prueba fallidos
- [ ] Fechas de ejecución y nombres de testers registrados
- [ ] Estadísticas de resumen proporcionadas (tasa aprobación, cobertura)
- [ ] Entregado a tiempo según SLA
### Framework de Automatización
**Criterios de Aceptación:**
- [ ] Se ejecuta exitosamente en entorno objetivo
- [ ] Documentación proporcionada (setup, ejecución, mantenimiento)
- [ ] Sigue estándares de codificación y mejores prácticas
- [ ] Integrado con pipeline CI/CD (si requerido)
- [ ] Suite de prueba de ejemplo demostrando capacidades
- [ ] Código fuente entregado con control de versiones
- [ ] Capacitación proporcionada al equipo del cliente (si contratado)
### Reporte Resumen de Testing
**Criterios de Aceptación:**
- [ ] Vista integral de actividades de testing
- [ ] Todas las métricas y KPIs clave incluidos
- [ ] Resumen de defectos con análisis de tendencias
- [ ] Evaluación de riesgos para release
- [ ] Comparación alcance de testing vs cobertura real
- [ ] Recomendaciones para mejoras futuras
- [ ] Sección de aprobación para stakeholders
Criterios de Salida de Sprint/Release
# Criterios de Salida de Sprint - Contrato de Testing
sprint_exit_criteria:
test_execution:
- Todos los casos de prueba planificados ejecutados (100%)
- Tasa de aprobación >= 95% para tests ejecutados
- Todos los tests bloqueados documentados con detalles del bloqueador
defect_status:
- Cero defectos críticos abiertos
- Cero defectos de alta severidad abiertos (o renuncia aprobada)
- Defectos medios <= 3 abiertos (con plan de remediación)
- Todos los defectos de baja severidad triados
automation:
- Nuevas features automatizadas (según objetivo de cobertura acordado)
- Suite de regresión ejecutada con >= 95% tasa de aprobación
- Tests inestables corregidos o en cuarentena
documentation:
- Resultados de testing documentados y reportados
- Problemas conocidos documentados
- Matriz de trazabilidad actualizada
- Reporte resumen de testing entregado
stakeholder_approval:
- Aprobación de QA Lead obtenida
- Aceptación de Product Owner
- Revisión de preparación para release completada
# Criterios de Salida de Release - Contrato de Testing
release_exit_criteria:
comprehensive_testing:
- Testing de regresión completo completado (100% ejecución)
- Testing de integración completado y aprobado
- Pruebas de aceptación de usuario completadas
- Plan de smoke test de producción preparado
defect_resolution:
- Cero defectos críticos
- Cero defectos de alta severidad
- Todos los defectos medios evaluados para riesgo de release
- Problemas conocidos documentados en notas de release
quality_metrics:
- Cobertura de testing >= 95% de requisitos
- Efectividad de detección de defectos >= 90%
- Cobertura de automatización cumple objetivo contratado
- Sin problemas no resueltos en entorno de testing
compliance:
- Todos los entregables contractuales enviados
- Todos los SLAs cumplidos (o penalizaciones reconocidas)
- Aprobación de todos los stakeholders requeridos
- Traspaso a soporte de producción completo (si en alcance)
Penalizaciones y Remediación
Penalizaciones por Rendimiento
# Estructura de Penalización del Contrato
penalty_framework:
sla_violations:
calculation_period: "Mensual"
penalty_cap: "Máximo 10% del valor mensual del contrato"
missed_deadlines:
threshold: "2 plazos perdidos por mes"
penalty: "2% del valor mensual por cada fallo adicional"
max_penalty: "6% valor mensual"
quality_metric_failure:
threshold: "Por debajo del umbral de penalización por 2 semanas consecutivas"
penalty: "3% del valor mensual por métrica"
max_penalty: "9% valor mensual"
response_time_sla:
threshold: "SLA incumplido 3 veces en un mes"
penalty: "1% del valor mensual por ocurrencia más allá del umbral"
max_penalty: "5% valor mensual"
critical_failures:
missed_release:
description: "Retrasos en testing causan postponimiento de release"
penalty: "5-10% del valor total del contrato (caso por caso)"
cap: "No sujeto al límite mensual del 10%"
major_production_defect:
description: "Defecto crítico escapa a producción debido a brecha en testing"
penalty: "Determinado basado en impacto de negocio"
remediation: "Análisis de causa raíz, plan de mejora de procesos requerido"
data_breach_security:
description: "Mal manejo de datos de prueba o incidente de seguridad"
penalty: "Según cláusulas de protección de datos, potencial terminación de contrato"
penalty_calculation_example:
monthly_contract_value: "$20,000"
scenario: "3 plazos perdidos, 1 métrica de calidad bajo umbral"
calculation:
missed_deadlines: "3 fallos - 2 permitidos = 1 × 2% = 2%"
quality_metrics: "1 fallo de métrica × 3% = 3%"
total_penalty: "5% de $20,000 = $1,000"
Proceso de Remediación
## Proceso de Remediación para Incumplimiento de Contrato
### Fase de Identificación
1. **Violación de SLA Detectada**
- Monitoreo automatizado señala violación
- O revisión manual identifica incumplimiento
- Violación documentada con evidencia
2. **Notificación (Dentro de 24 horas)**
- Proveedor notificado de violación
- SLA/métrica específica citada
- Evidencia proporcionada
### Fase de Respuesta (48 horas)
3. **Respuesta del Proveedor Requerida**
- Reconocer violación
- Proporcionar explicación/contexto
- Proponer plan de remediación
4. **Análisis de Causa Raíz**
- Identificar causa subyacente
- Evaluar si es problema sistémico o puntual
- Documentar hallazgos
### Fase de Remediación
5. **Ejecución del Plan de Remediación**
- Acciones correctivas inmediatas
- Mejoras de proceso implementadas
- Recursos adicionales asignados (si es necesario)
6. **Monitoreo (2-4 semanas)**
- Seguimiento cercano de métricas afectadas
- Check-ins semanales
- Reportes de progreso
### Fase de Resolución
7. **Verificación de Cumplimiento**
- Métricas vuelven a niveles aceptables
- Cumplimiento sostenido por 2+ semanas
- Documentación actualizada
8. **Evaluación de Penalización**
- Si remediación exitosa: Penalización puede ser eximida/reducida
- Si remediación insuficiente: Penalización completa aplicada
- Violaciones crónicas: Escalamiento a discusiones de terminación de contrato
## Matriz de Escalamiento
| Nivel | Disparador | Quién es Notificado | Cronograma |
|-------|------------|---------------------|------------|
| **Nivel 1** | Primera violación de SLA | Team Leads (ambos lados) | Inmediato |
| **Nivel 2** | 2da violación en 30 días | QA Manager + Project Manager | Dentro de 4 horas |
| **Nivel 3** | 3 violaciones en 30 días | Director de QA + PMO Lead | Dentro de 8 horas |
| **Nivel 4** | Problema que amenaza contrato | VP Ingeniería + Ejecutivo Proveedor | Dentro de 24 horas |
Planes de Mejora de Rendimiento
## Template de Plan de Mejora de Rendimiento (PIP)
### Condiciones Disparadoras para PIP
- 3+ violaciones de SLA en un solo mes
- Fallo consistente en cumplir métricas de calidad (2+ meses)
- Escalamiento crítico del cliente
- Rendimiento sostenido por debajo del umbral
### Estructura del PIP
**Duración:** 30-60 días (basado en severidad)
**Fase 1: Evaluación (Semana 1)**
- Revisión integral de rendimiento
- Análisis de brechas contra requisitos del contrato
- Identificación de causa raíz
- Recopilación de input de stakeholders
**Fase 2: Desarrollo del Plan (Semana 1-2)**
- Objetivos de mejora específicos definidos
- Hitos y checkpoints establecidos
- Necesidades de recursos identificadas
- Cambios de proceso documentados
**Fase 3: Ejecución (Semanas 2-8)**
- Revisiones de progreso semanales
- Métricas monitoreadas de cerca
- Ajustes realizados según necesidad
- Comunicación transparente mantenida
**Fase 4: Evaluación (Semana 8-12)**
- Evaluación de rendimiento contra objetivos
- Decisión sobre continuación o modificación de contrato
- Documentación de lecciones aprendidas
### Criterios de Éxito del PIP
- [ ] Todas las métricas críticas sobre umbral por 4 semanas consecutivas
- [ ] Cero violaciones de SLA durante período de PIP
- [ ] Confianza de stakeholders restaurada
- [ ] Mejoras de proceso documentadas e implementadas
- [ ] Plan de mitigación de riesgos futuros en lugar
### Resultados del PIP
- **Exitoso:** Reanudar operaciones normales, PIP levantado
- **Éxito Parcial:** Período de monitoreo extendido, renegociación
- **No Exitoso:** Terminación de contrato con plan de transición
Template de Contrato
Acuerdo de Servicios de Testing - Cláusulas de Ejemplo
# ACUERDO DE SERVICIOS DE TESTING
## 1. ALCANCE DE SERVICIOS
1.1 **Servicios de Testing.** El Proveedor proporcionará servicios de testing de software según se detalla en el Anexo A (Alcance de Trabajo), incluyendo pero no limitado a:
(a) Testing funcional de la Aplicación
(b) Testing de regresión
(c) Desarrollo y mantenimiento de automatización de tests (si se selecciona)
(d) Gestión y reporte de defectos
1.2 **Entregables.** El Proveedor entregará los artefactos de testing especificados en el Anexo B (Entregables), incluyendo planes de testing, casos de prueba, reportes de testing y reportes de defectos.
1.3 **Niveles de Servicio.** El Proveedor cumplirá o excederá los Acuerdos de Nivel de Servicio definidos en el Anexo C (SLAs).
## 2. PLAZO Y TERMINACIÓN
2.1 **Plazo.** Este Acuerdo comenzará el [FECHA INICIO] y continuará por [DURACIÓN], a menos que se termine antes según lo previsto aquí.
2.2 **Terminación por Conveniencia.** Cualquier parte puede terminar este Acuerdo con 30 días de aviso por escrito.
2.3 **Terminación por Causa.** Cualquier parte puede terminar inmediatamente con aviso por escrito si:
(a) La otra parte incumple materialmente este Acuerdo y no corrige dentro de 15 días
(b) La otra parte se vuelve insolvente o solicita quiebra
(c) Fallos de rendimiento según se define en Anexo D (Penalizaciones y Remediación)
## 3. TARIFAS Y PAGO
3.1 **Tarifas.** El Cliente pagará al Proveedor las tarifas especificadas en el Anexo E (Precios) según el cronograma de hitos.
3.2 **Términos de Pago.** Las facturas son pagaderas dentro de 30 días de recepción. Pagos tardíos acumulan interés al 1.5% por mes.
3.3 **Penalizaciones.** El Cliente puede deducir penalizaciones de facturas mensuales según especificado en Anexo D por violaciones de SLA.
## 4. CONFIDENCIALIDAD Y PROTECCIÓN DE DATOS
4.1 **Información Confidencial.** Cada parte protegerá la Información Confidencial de la otra parte con el mismo grado de cuidado usado para proteger su propia información confidencial, pero no menos que cuidado razonable.
4.2 **Datos de Prueba.** El Proveedor manejará todos los datos de prueba de acuerdo con las políticas de protección de datos del Cliente. Los datos de producción no se usarán sin aprobación explícita por escrito y enmascaramiento apropiado.
4.3 **Brecha de Datos.** El Proveedor notificará al Cliente dentro de 24 horas de cualquier sospecha o brecha real de datos que involucre datos del Cliente.
## 5. PROPIEDAD INTELECTUAL
5.1 **Producto del Trabajo.** Todos los artefactos de testing, documentación y scripts de automatización creados bajo este Acuerdo serán propiedad exclusiva del Cliente.
5.2 **IP Preexistente.** El Proveedor retiene propiedad de herramientas, frameworks y metodologías preexistentes, otorgando al Cliente una licencia para usarlas durante el plazo.
5.3 **Código Abierto.** Cualquier componente de código abierto usado deberá ser revelado y aprobado por el Cliente.
## 6. GARANTÍAS Y REPRESENTACIONES
6.1 **Garantía de Servicios.** El Proveedor garantiza que los servicios se realizarán de manera profesional y con calidad de obra consistente con estándares de la industria.
6.2 **Calificaciones de Recursos.** El Proveedor garantiza que todo el personal tiene habilidades, capacitación y verificaciones de antecedentes apropiadas.
6.3 **Cumplimiento.** El Proveedor garantiza cumplimiento con todas las leyes, regulaciones y estándares de la industria aplicables.
## 7. INDEMNIZACIÓN
7.1 **Indemnización del Proveedor.** El Proveedor indemnizará al Cliente contra reclamaciones derivadas de:
(a) Negligencia o mala conducta del Proveedor
(b) Incumplimiento de confidencialidad
(c) Infracción de propiedad intelectual
(d) Violación de leyes o regulaciones
## 8. LIMITACIÓN DE RESPONSABILIDAD
8.1 **Tope de Responsabilidad.** Excepto por incumplimientos de confidencialidad o protección de datos, la responsabilidad de ninguna parte excederá las tarifas totales pagadas bajo este Acuerdo en los 12 meses anteriores al reclamo.
8.2 **Daños Excluidos.** Ninguna parte será responsable por daños indirectos, consecuentes o punitivos.
## 9. DISPOSICIONES GENERALES
9.1 **Acuerdo Completo.** Este Acuerdo constituye el acuerdo completo y reemplaza todos los acuerdos anteriores.
9.2 **Enmiendas.** Las enmiendas deben ser por escrito y firmadas por ambas partes.
9.3 **Ley Aplicable.** Este Acuerdo se regirá por las leyes de [JURISDICCIÓN].
---
**ANEXOS:**
- Anexo A: Alcance de Trabajo
- Anexo B: Entregables
- Anexo C: Acuerdos de Nivel de Servicio
- Anexo D: Penalizaciones y Remediación
- Anexo E: Precios y Términos de Pago
Mejores Prácticas
Consejos para Negociación de Contratos
Para Equipos de QA (Proveedor de Servicios):
Sea Específico sobre el Alcance: Defina claramente qué está incluido y excluido. La ambigüedad lleva a scope creep.
Establezca SLAs Realistas: No prometa de más. Mejor exceder SLAs conservadores que fallar en agresivos.
Incluya Gestión de Cambios: Asegure que el contrato tenga proceso claro para cambios de alcance con implicaciones de precio.
Proteja a su Equipo: Incluya cláusulas sobre horas de trabajo razonables, sin expectativas de horas extras excesivas.
Documente Supuestos: Especifique todos los supuestos (ej., “asume entorno de testing estable”, “asume requisitos proporcionados 2 semanas antes del testing”).
Incluya Contingencia: No comprometa 100% de la capacidad del equipo. Deje buffer para problemas inesperados.
Para Clientes (Receptor del Servicio):
Defina el Éxito Claramente: No solo especifique actividades; especifique resultados deseados y niveles de calidad.
Incluya Incentivos de Rendimiento: Considere bonos por rendimiento excepcional, no solo penalizaciones.
Asegure Transferencia de Conocimiento: Requiera documentación y capacitación para evitar dependencia del proveedor.
Revisiones Regulares: Incluya revisiones comerciales trimestrales para evaluar salud de la asociación.
Cláusulas de Flexibilidad: El mercado cambia. Asegure que el contrato permita modificaciones razonables.
Derechos de Auditoría: Reserve el derecho de auditar procesos del proveedor, especialmente para industrias críticas de cumplimiento.
Gestión Continua de Contratos
## Monitoreo de Salud del Contrato
### Revisiones Mensuales
- [ ] Scorecard de cumplimiento de SLA
- [ ] Seguimiento de entregables (a tiempo, calidad)
- [ ] Análisis de métricas de defectos
- [ ] Presupuesto vs gasto real
- [ ] Encuesta de satisfacción de stakeholders
- [ ] Log de problemas abiertos y escalamientos
### Revisiones Comerciales Trimestrales
- [ ] Evaluación de rendimiento general del contrato
- [ ] Verificación de alineamiento estratégico
- [ ] Oportunidades de mejora de procesos
- [ ] Evaluación de adecuación de recursos
- [ ] Discusión de salud de la relación
- [ ] Planificación prospectiva (próximo trimestre)
### Revisión Anual del Contrato
- [ ] Evaluación integral de rendimiento
- [ ] Análisis de ROI
- [ ] Consideraciones de renovación de contrato
- [ ] Renegociación de precios (si aplica)
- [ ] Discusiones de ajuste de alcance
- [ ] Estrategia de asociación a largo plazo
## Señales de Alerta a Vigilar
- Plazos perdidos frecuentes o violaciones de SLA
- Alta rotación en equipo del proveedor
- Calidad decreciente de entregables
- Comunicación o capacidad de respuesta pobre
- Resistencia a feedback o mejora
- Disputas crónicas de "fuera de alcance"
“La razón más común por la que los contratos de testing fallan no es técnica — es la ambigüedad de alcance. ‘Probar la aplicación’ no es una declaración de alcance. Un buen contrato lista explícitamente qué está fuera del alcance: qué navegadores, entornos, integraciones no se probarán, y por qué. Esa lista explícita de exclusiones protege a ambas partes y previene los sobrecostos presupuestarios que destruyen las relaciones con proveedores.” — Yuri Kan, Senior QA Lead
Conclusión
Los contratos y SLAs de testing bien estructurados son fundamentales para operaciones de QA exitosas, ya sea gestionando acuerdos de servicio internos o relaciones con proveedores externos. Al definir claramente alcance, entregables, estándares de calidad y mecanismos de responsabilidad, las organizaciones establecen un marco para servicios de testing medibles, predecibles y de alta calidad.
La clave para contratos efectivos no radica en crear los acuerdos más restrictivos, sino en fomentar asociaciones construidas sobre expectativas claras, términos justos, respeto mutuo y compromiso compartido con la calidad. El monitoreo regular, la comunicación transparente y la voluntad de adaptarse aseguran que los contratos permanezcan relevantes y valiosos a lo largo de su ciclo de vida, contribuyendo en última instancia a mejor calidad de software y relaciones profesionales más sólidas.
FAQ
¿Qué debe incluir un contrato de testing?
Un contrato completo incluye: definición de alcance (qué se prueba y explícitamente qué no), entregables con criterios de aceptación, cronogramas con hitos, métricas SLA de calidad, procedimientos de escalamiento, proceso de gestión de cambios y cláusulas de penalización/incentivos. Según ISTQB, la ambigüedad de alcance es la fuente más común de disputas contractuales — siempre incluye una lista explícita de lo que está fuera del alcance.
¿Cuáles son las métricas SLA típicas para contratos de testing?
Métricas estándar: efectividad de detección de defectos (>85% antes del release), tasa de ejecución de pruebas (>95%), sin defectos críticos en el release, tiempo de respuesta a triaje (<4 horas para críticos). La investigación de IEEE Software Engineering muestra que las métricas deben ser rastreables automáticamente — compromisos no rastreables crean fricción.
¿Cómo manejar el scope creep en contratos de testing?
El scope creep se gestiona mediante control formal de cambios: todos los cambios requieren documentación escrita, análisis de impacto, aprobación de stakeholders antes de implementación y enmienda al contrato. Establece un umbral (>10% de aumento activa re-negociación). Rastrea todos los cambios en un registro de cambios referenciado por el contrato.
¿Qué cláusulas de penalización son apropiadas?
Penalizaciones apropiadas: créditos de servicio (5-15% del valor del contrato) por incumplimiento de SLA y penalizaciones por escape rate de defectos vinculadas a incidentes de producción. Equilibra penalizaciones con incentivos — bonificaciones por superar objetivos de calidad crean alineación. Las penalizaciones punitivas incentivan manipular métricas, no mejorar la calidad.
Ver También
- Test Plan and Strategy - Base para definición de alcance contractual
- Testing Metrics and KPIs - Indicadores de rendimiento para SLAs
- Test Summary Report - Entregables contractuales típicos
- Defect Life Cycle - Procesos de gestión de defectos
- Test Estimation Documentation - Estimaciones para contratos
Recursos Oficiales
- ISTQB Foundation Level — estándares de servicios de testing
- IEEE Software Engineering — estándares de medición de calidad de software
- Web Performance
- Core Web Vitals
