La importancia jurídica del testing de software

Introducción

El software interviene actualmente en operaciones bancarias, historias clínicas, expedientes judiciales, contratos electrónicos, sistemas tributarios, vehículos, dispositivos médicos, infraestructuras críticas, comunicaciones, plataformas educativas, aplicaciones comerciales y procedimientos administrativos. Como consecuencia, un error informático ya no constituye solamente un problema técnico: puede provocar daños patrimoniales, pérdida de información, vulneraciones de datos personales, interrupciones de servicios, incumplimientos contractuales, decisiones administrativas incorrectas e incluso lesiones o riesgos para la vida humana.

En este contexto, el testing de software —también denominado prueba, verificación o ensayo de software— posee una importancia jurídica creciente. Su función no se limita a encontrar errores antes de que un programa sea utilizado. También permite demostrar diligencia profesional, verificar el cumplimiento de especificaciones contractuales, documentar la calidad y seguridad del producto, establecer criterios objetivos de aceptación, prevenir daños y producir evidencia para auditorías, reclamos y procesos judiciales.

1. Concepto técnico de testing de software

El testing de software consiste en un conjunto planificado de actividades destinadas a examinar un sistema, componente o producto informático para determinar si cumple los requisitos establecidos, detectar defectos y evaluar su comportamiento bajo determinadas condiciones.

La serie de normas ISO/IEC/IEEE 29119 establece conceptos, procesos, documentación y técnicas aplicables a las pruebas de software. Su finalidad es proporcionar un marco internacional común utilizable en diferentes organizaciones, metodologías y ciclos de desarrollo.

1.1. Error humano

Es la equivocación cometida por una persona durante la identificación de requisitos, el diseño, la programación, la configuración, la implementación o el mantenimiento del sistema.

1.2. Defecto o bug

Es la imperfección introducida en un requisito, diseño, código fuente, base de datos, configuración o componente. El error humano puede generar un defecto, aunque este permanezca oculto durante largo tiempo sin producir consecuencias visibles.

1.3. Falla

Es la manifestación externa del defecto durante la ejecución. Una aplicación bancaria, por ejemplo, puede contener un error en el cálculo de intereses; la falla se produce cuando ese defecto causa un débito incorrecto en una cuenta.

1.4. Incidente

Es un acontecimiento observado durante la prueba o utilización del sistema que requiere investigación. No todo incidente deriva de un defecto del software: también puede provenir de datos incorrectos, problemas de red, configuraciones deficientes, fallas de hardware o errores del usuario.

Error humano → defecto técnico → falla del sistema → daño jurídicamente relevante.

Esta secuencia es jurídicamente relevante porque ayuda a reconstruir la causalidad. La responsabilidad no surge por la sola existencia de un bug: deben analizarse la obligación asumida, la diligencia exigible, la previsibilidad, el daño, el nexo causal y las eventuales causas de exoneración.

2. Verificación, validación y aseguramiento de la calidad

2.1. Verificación

La verificación procura determinar si el producto fue construido correctamente conforme a su diseño, arquitectura y especificaciones técnicas.

¿Estamos construyendo correctamente el producto?

2.2. Validación

La validación procura comprobar si el producto satisface las necesidades reales del usuario y cumple la finalidad para la cual fue contratado.

¿Estamos construyendo el producto correcto?

Un sistema puede ajustarse técnicamente a una especificación mal redactada y, sin embargo, resultar inútil para el cliente. Por ello, la validación requiere participación del usuario, del propietario del producto, de especialistas del negocio y, cuando corresponda, de asesores jurídicos.

2.3. Aseguramiento de la calidad

El aseguramiento de la calidad comprende políticas, procedimientos, estándares, revisiones, auditorías, gestión de riesgos y controles destinados a prevenir defectos durante todo el ciclo de vida.

La calidad no puede incorporarse solamente al final del desarrollo. Debe considerarse desde la definición de requisitos, el diseño de la arquitectura, la programación, la integración, el despliegue y el mantenimiento.

3. Principales clases de pruebas

3.1. Pruebas unitarias

Examinan funciones, métodos, clases o componentes aislados. Su automatización permite ejecutarlas cada vez que cambia el código.

3.2. Pruebas de integración

Verifican la interacción entre componentes, servicios, bases de datos, interfaces de programación —API— y sistemas externos.

3.3. Pruebas de sistema

Examinan el sistema completo en condiciones similares a producción, incluyendo infraestructura, configuraciones, permisos y dependencias.

3.4. Pruebas de aceptación

Son realizadas por el cliente, usuarios representativos o un tercero independiente para decidir si el sistema cumple los requisitos y puede ser aceptado.

Estas pruebas pueden determinar:

• la aprobación o rechazo de un entregable;
• el nacimiento del derecho al cobro;
• el comienzo de la garantía;
• la autorización para pasar a producción;
• la recepción provisoria o definitiva.

3.5. Pruebas funcionales

Comprueban si el software ejecuta correctamente las operaciones previstas, como calcular una liquidación, emitir una factura, registrar una transferencia o aplicar permisos de acceso.

3.6. Pruebas no funcionales

Evalúan atributos como:

• rendimiento y capacidad;
• escalabilidad;
• seguridad;
• confiabilidad y disponibilidad;
• accesibilidad;
• compatibilidad y portabilidad;
• mantenibilidad;
• recuperación ante fallas.

3.7. Pruebas de regresión

Se ejecutan luego de una modificación para comprobar que las funciones previamente correctas no hayan sido afectadas.

3.8. Pruebas de seguridad

Buscan vulnerabilidades y verifican controles relativos a:

• autenticación y autorización;
• gestión de sesiones;
• cifrado;
• validación de entradas;
• tratamiento de errores;
• registro de eventos;
• protección de API;
• gestión de dependencias;
• prevención de inyección de código.

3.9. Pruebas de rendimiento, carga y estrés

Las pruebas de carga verifican el comportamiento bajo el volumen esperado de usuarios u operaciones. Las pruebas de estrés someten al sistema a condiciones superiores a las normales para determinar sus límites y observar si falla de manera controlada.

3.10. Pruebas de recuperación y continuidad

Comprueban la restauración del servicio luego de caídas, pérdida de conexión, corrupción de datos, ataques informáticos, fallas de proveedores, interrupciones eléctricas o actualizaciones defectuosas.

4. El testing no demuestra que el software sea perfecto

Las pruebas pueden revelar la presencia de defectos, pero no garantizan su ausencia absoluta. La cantidad de combinaciones de datos, configuraciones, dispositivos, estados internos y conductas de usuarios suele hacer imposible probar todos los escenarios.

La formulación técnicamente adecuada debe explicar:

• qué requisitos fueron probados;
• con qué metodología;
• bajo qué condiciones;
• qué cobertura se alcanzó;
• qué defectos permanecen conocidos;
• cuáles son los riesgos residuales;
• qué supuestos quedaron fuera del alcance.

5. El testing como deber de diligencia profesional

La exigencia de testing depende del contrato, la complejidad del producto, los usos profesionales, los estándares aplicables y la gravedad de los posibles daños. Cuanto mayor sea el impacto potencial de una falla, mayor será normalmente la intensidad del control exigible.

No se requiere el mismo nivel de pruebas para una página personal que para un sistema de dosificación de medicamentos, una plataforma bancaria, un sistema de control industrial, una base de datos de antecedentes o una aplicación que procesa información biométrica.

En la evaluación de la diligencia pueden resultar relevantes:

• la existencia de un plan de pruebas;
• la identificación de riesgos;
• la cobertura de requisitos críticos;
• las revisiones de código;
• la separación entre desarrollo, pruebas y producción;
• el tratamiento de defectos conocidos;
• la documentación de resultados;
• la corrección de vulnerabilidades antes del despliegue.

6. Importancia del testing en la responsabilidad contractual

En los contratos de desarrollo, implementación, mantenimiento o licenciamiento, las pruebas permiten determinar objetivamente si la prestación fue cumplida.

El artículo 1342 del Código Civil uruguayo contempla el resarcimiento de daños y perjuicios por falta de cumplimiento o demora, salvo la existencia de una causa extraña no imputable al deudor.

En software, el incumplimiento puede consistir en:

• no entregar el producto o hacerlo fuera de plazo;
• entregar funciones incompletas;
• incumplir requisitos de rendimiento o seguridad;
• perder o corromper datos;
• proporcionar una versión incompatible;
• omitir documentación o pruebas convenidas;
• no corregir defectos durante la garantía.

6.1. Obligaciones de medios y de resultado

Algunas prestaciones pueden configurarse como obligaciones de resultado, por ejemplo entregar un módulo determinado, migrar cierta cantidad de registros o implementar autenticación multifactor. Otras pueden presentar rasgos de obligaciones de medios, como determinadas tareas de consultoría, búsqueda de vulnerabilidades o investigación.

No corresponde afirmar que todo desarrollo de software sea automáticamente una obligación de medios. Debe analizarse cada prestación, sus requisitos, garantías y riesgos.

6.2. Especificaciones y criterios de aceptación

Expresiones como “el sistema debe ser rápido”, “intuitivo” o “totalmente seguro” son ambiguas. Es preferible establecer parámetros medibles:

El 95 % de las solicitudes deberá responder en menos de dos segundos bajo una carga de quinientos usuarios concurrentes, en el entorno definido en el anexo técnico.

6.3. Recepción y aceptación del software

El contrato debería regular:

1. la entrega de cada versión;
2. el plazo de evaluación;
3. el entorno de prueba;
4. los casos aplicables;
5. la clasificación de defectos;
6. los defectos que impiden aceptar;
7. los plazos de corrección;
8. la repetición de pruebas;
9. la aceptación expresa o tácita;
10. los efectos jurídicos de la aceptación.

7. Responsabilidad por daños a terceros

Una falla puede perjudicar a personas que no contrataron directamente con el desarrollador: pacientes, peatones, clientes bancarios, ciudadanos o titulares de datos.

Los artículos 1319 y 1324 del Código Civil uruguayo son relevantes para analizar la responsabilidad extracontractual, la culpa, la negligencia y los hechos de dependientes.

El testing puede ayudar a determinar:

• si el riesgo era conocido o previsible;
• si existían técnicas razonables para detectarlo;
• si las pruebas fueron suficientes;
• si un defecto conocido fue ignorado;
• si se adoptaron medidas de mitigación;
• si el daño provino del software o de un factor externo;
• si existió culpa concurrente.

8. Testing y relaciones de consumo

Cuando una persona adquiere o utiliza software como destinataria final, puede resultar aplicable la Ley N.º 17.250. Esta reconoce la protección de la vida, la salud y la seguridad frente a riesgos causados por productos o servicios, además del derecho a recibir información suficiente, clara y veraz.

Una aplicación puede considerarse defectuosa cuando:

• no ejecuta las funciones prometidas;
• destruye información del usuario;
• permite accesos no autorizados;
• cobra importes incorrectos;
• incluye mecanismos inseguros;
• no es compatible con los entornos anunciados;
• recopila datos sin informar adecuadamente;
• carece de actualizaciones de seguridad razonables.

Las cláusulas predispuestas que pretendan excluir indiscriminadamente toda responsabilidad deben examinarse a la luz del carácter tuitivo y de orden público de la legislación de consumo.

9. Testing y protección de datos personales

El artículo 10 de la Ley N.º 18.331 exige adoptar medidas necesarias para garantizar la seguridad y confidencialidad de los datos, evitar su adulteración, pérdida, consulta o tratamiento no autorizado y detectar desviaciones de información.

Entre las pruebas vinculadas con la protección de datos se encuentran:

• verificación de permisos y perfiles;
• autenticación y autorización;
• cifrado en tránsito y almacenamiento;
• eliminación y anonimización;
• gestión del consentimiento;
• ejercicio de derechos de acceso, rectificación y supresión;
• retención de información;
• integridad y trazabilidad;
• respaldo y recuperación;
• separación entre clientes.

9.1. Datos reales en ambientes de testing

Copiar bases de producción completas a entornos de desarrollo puede exponer información a más personas, proveedores externos, dispositivos personales, registros de depuración o sistemas con menor nivel de protección.

Siempre que sea posible deben utilizarse datos sintéticos, anonimizados o seudonimizados. Si se emplean datos reales, su tratamiento debe estar jurídicamente habilitado y sujeto a controles equivalentes a producción.

9.2. Privacidad desde el diseño y por defecto

La responsabilidad proactiva, la privacidad desde el diseño y la privacidad por defecto exigen considerar la protección de datos desde el inicio de la aplicación y comprobar mediante pruebas que las medidas fueron efectivamente implementadas.

9.3. Vulneraciones de seguridad

El Decreto N.º 64/020 exige medidas técnicas y organizativas orientadas a conservar la integridad, confidencialidad y disponibilidad de la información, además de prever la gestión de vulneraciones de seguridad.

10. Testing y ciberseguridad

El testing de seguridad no se reduce a ejecutar un escáner automático. Una estrategia completa puede incluir:

• análisis estático y dinámico;
• revisión manual de código;
• modelado de amenazas;
• análisis de dependencias;
• búsqueda de secretos incorporados al código;
• pruebas de configuración y API;
• pruebas de penetración;
• simulación de abuso;
• pruebas de recuperación.

El Marco de Ciberseguridad de Agesic recomienda sistematizar las actividades de prueba, documentar procedimientos, establecer criterios de aceptación y conservar evidencia del versionado, la gestión de cambios y las verificaciones de seguridad.

La intervención delictiva de un tercero no excluye necesariamente toda responsabilidad civil. Debe analizarse si el ataque fue imprevisible o si se vio facilitado por vulnerabilidades conocidas, configuraciones deficientes o ausencia de controles razonables.

11. Testing, documentos electrónicos y registros informáticos

La Ley N.º 18.600 reconoce la admisibilidad, validez y eficacia jurídica del documento electrónico y de la firma electrónica. Por ello, la confiabilidad del software que crea, firma, almacena, transmite o verifica documentos electrónicos es jurídicamente relevante.

Deben probarse, entre otros aspectos:

• la identidad del firmante;
• la integridad del documento;
• la asociación entre firma y contenido;
• los sellos de tiempo;
• la validez de certificados;
• la conservación del documento;
• la detección de modificaciones;
• el registro de eventos;
• la correcta visualización y recuperación.

12. El testing como evidencia

Las pruebas generan documentación con potencial valor probatorio:

• planes y estrategias de testing;
• matrices de riesgos;
• requisitos funcionales y no funcionales;
• casos de prueba y datos utilizados;
• resultados esperados y obtenidos;
• registros de ejecución;
• informes de cobertura;
• tickets de defectos;
• historial de versiones;
• informes de pruebas de penetración;
• actas de aceptación;
• hashes de los artefactos probados.

12.1. Trazabilidad

Requisito → caso de prueba → resultado → defecto → corrección → nueva prueba → aprobación.

12.2. Integridad de la evidencia

Los resultados deben conservarse de modo que puedan verificarse su fecha, autor, versión probada, integridad, herramienta utilizada, configuración del entorno y ausencia de alteraciones posteriores.

13. Separación de ambientes y gestión de cambios

Una organización madura debería mantener ambientes diferenciados de:

• desarrollo;
• testing;
• preproducción;
• producción.

La separación reduce el riesgo de que pruebas experimentales afecten usuarios o datos reales. Los cambios deben ser autorizados, registrados, justificados, probados y acompañados de un mecanismo de reversión.

Una modificación no probada puede ser jurídicamente relevante cuando:

• afecta un sistema crítico;
• omite procedimientos internos obligatorios;
• contradice una obligación contractual;
• introduce una vulnerabilidad previsible;
• altera datos sin respaldo;
• se ejecuta sin autorización;
• impide restaurar la versión anterior.

14. Automatización de pruebas y CI/CD

En procesos de integración y despliegue continuos, cada modificación puede activar:

1. compilación;
2. análisis estático;
3. pruebas unitarias;
4. pruebas de integración;
5. análisis de dependencias;
6. creación del artefacto;
7. pruebas de seguridad;
8. aprobación;
9. despliegue.

La automatización favorece la consistencia, la trazabilidad y la documentación, pero no reemplaza el juicio profesional, la revisión humana ni las pruebas exploratorias.

15. Testing de sistemas con inteligencia artificial

Los sistemas de inteligencia artificial requieren pruebas adicionales. No basta con verificar que el programa se ejecute sin errores. También deben evaluarse:

• calidad y representatividad de los datos;
• exactitud del modelo;
• tasas de falsos positivos y negativos;
• sesgos;
• robustez ante entradas adversariales;
• explicabilidad;
• privacidad;
• posibilidad de alucinaciones;
• supervisión humana;
• degradación del rendimiento.

En ámbitos jurídicos, médicos, financieros o administrativos, los casos de prueba deben detectar decisiones discriminatorias, afirmaciones falsas, omisiones esenciales y respuestas fuera del ámbito autorizado.

16. La relevancia sectorial del testing

16.1. Sistemas bancarios y financieros

Deben cubrir precisión, concurrencia, integridad transaccional, seguridad y trazabilidad.

16.2. Sistemas médicos

El testing debe ser proporcional al riesgo para la salud y considerar errores previsibles de uso, dosificación, diagnóstico, visualización e interoperabilidad.

16.3. Administración pública

Deben probarse la legalidad de las reglas implementadas, la exactitud de cálculos, la accesibilidad, la seguridad y la posibilidad de auditoría.

16.4. Sistemas jurídicos

Una falla puede calcular incorrectamente un plazo, asociar un expediente a otra persona, omitir una notificación, alterar un documento, exponer información reservada o aplicar normativa derogada.

16.5. Infraestructuras críticas

En energía, telecomunicaciones, transporte, agua, defensa y servicios de emergencia se requieren pruebas reforzadas de seguridad, redundancia, recuperación y continuidad.

17. Cláusulas contractuales recomendables

17.1. Objeto y alcance

Identificar módulos, versiones, plataformas e integraciones que serán probados.

17.2. Requisitos verificables

Formular cada requisito crítico de manera objetiva y medible.

17.3. Plan de pruebas

Definir tipos de prueba, responsables, ambientes, datos, cronograma, herramientas, documentación y criterios de suspensión.

17.4. Clasificación de defectos

Diferenciar defectos críticos, altos, medios, bajos y cosméticos según su impacto.

17.5. Criterios de aceptación

Determinar cuántos defectos de cada categoría pueden permanecer abiertos y cuáles impiden la aceptación.

17.6. Garantía

Regular duración, defectos comprendidos, tiempos de respuesta, corrección, exclusiones y procedimiento de reporte.

17.7. Seguridad

Incluir requisitos de desarrollo seguro, análisis de dependencias, pruebas de penetración, tratamiento de vulnerabilidades y comunicación de incidentes.

17.8. Protección de datos

Regular datos de prueba, anonimización, subcontratistas, ubicación, acceso, eliminación y notificación de incidentes.

17.9. Independencia de las pruebas

En sistemas críticos puede convenir que determinadas pruebas sean supervisadas por un tercero independiente.

17.10. Propiedad y acceso a los resultados

Determinar quién puede utilizar los casos de prueba, informes, scripts, datos sintéticos y herramientas desarrolladas.

18. ¿La falta de testing genera automáticamente responsabilidad?

No. La ausencia de pruebas puede ser un indicio importante de negligencia, pero deben acreditarse los elementos del régimen jurídico aplicable.

A la inversa, haber realizado pruebas tampoco exonera automáticamente al desarrollador. Puede existir responsabilidad si:

• el plan era manifiestamente insuficiente;
• se excluyeron riesgos críticos;
• se ignoraron resultados negativos;
• se falsificaron informes;
• se desplegó una versión distinta de la probada;
• se ocultaron vulnerabilidades;
• no se corrigieron defectos graves;
• las pruebas fueron ejecutadas por personas sin competencia.

La cuestión central no es simplemente si “se hicieron pruebas”, sino si existió un proceso razonable, documentado y proporcional al riesgo.

19. Ejemplos prácticos

20. Recomendaciones para desarrolladores y organizaciones

1. Definir requisitos funcionales, legales y de seguridad.
2. Identificar riesgos técnicos y consecuencias jurídicas.
3. Adoptar un plan de pruebas proporcional al riesgo.
4. Documentar versiones, entornos y resultados.
5. Incorporar revisión de código y análisis de dependencias.
6. Automatizar pruebas repetibles.
7. Mantener intervención humana en decisiones críticas.
8. Utilizar datos de prueba seguros.
9. Establecer criterios objetivos de aceptación.
10. Conservar evidencia de las decisiones.
11. Corregir vulnerabilidades según su severidad.
12. Comunicar defectos y riesgos residuales.
13. Controlar cambios antes de producción.
14. Realizar pruebas periódicas durante el mantenimiento.
15. Revisar contratos y limitaciones de responsabilidad.

Conclusiones

El testing de software no es una actividad meramente técnica ni una fase opcional que pueda eliminarse para reducir costos o acelerar una entrega.

Desde el punto de vista jurídico cumple cinco funciones fundamentales:

1. Prevención: reduce la probabilidad de daños, incidentes y vulneraciones.
2. Cumplimiento: verifica requisitos contractuales, legales y regulatorios.
3. Diligencia: demuestra la adopción de procedimientos profesionales razonables.
4. Evidencia: genera documentación útil para auditorías, reclamos y litigios.
5. Asignación de responsabilidad: ayuda a determinar el origen de una falla y las decisiones que la permitieron.

En Uruguay, su importancia surge de la interacción entre las reglas de responsabilidad contractual y extracontractual, la legislación de consumo, la protección de datos personales, los documentos electrónicos y los marcos de ciberseguridad.

Un sistema probado no es necesariamente infalible. Sin embargo, un sistema crítico desarrollado sin pruebas suficientes constituye no solamente una deficiencia técnica, sino también una fuente relevante de riesgo contractual, patrimonial, regulatorio y profesional.

Fuentes normativas y técnicas

• ISO, ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing. Sitio oficial.
• ISO, ISO/IEC 25010:2023 — Product quality model. Sitio oficial.
• OWASP, Application Security Verification Standard. Sitio oficial.
• NIST, Secure Software Development Framework, SP 800-218. Sitio oficial.
• Agesic, Marco de Ciberseguridad 5.0. Portal institucional.
• Código Civil uruguayo, artículos 1319, 1324 y 1342. IMPO.
• Ley N.º 17.250, Relaciones de Consumo. IMPO.
• Ley N.º 18.331, Protección de Datos Personales y Acción de Habeas Data. IMPO.
• Decreto N.º 64/020. IMPO.
• Ley N.º 18.600, Documento Electrónico y Firma Electrónica. IMPO.
• Ley N.º 20.327, prevención y represión de la ciberdelincuencia. IMPO.