Introducción
El software testing es una disciplina fundamental dentro de la ingeniería de software y del aseguramiento de la calidad (Quality Assurance, QA). Su propósito no consiste únicamente en ejecutar un sistema para comprobar si funciona, sino en proporcionar información objetiva sobre su calidad, identificar riesgos y reducir la probabilidad de que los defectos lleguen al usuario final.
En proyectos reales, probar absolutamente todas las combinaciones posibles de datos, estados y escenarios suele ser técnica y económicamente inviable. Por esta razón, el testing debe realizarse de manera sistemática, estratégica y basada en riesgo.
A lo largo de décadas de experiencia en la industria se han identificado siete principios fundamentales que permiten comprender cómo debe plantearse una estrategia efectiva de pruebas. Estos principios son ampliamente difundidos por ISTQB (International Software Testing Qualifications Board) y constituyen una base conceptual importante para profesionales de QA, desarrolladores e ingenieros de software.
1. Las pruebas muestran la presencia de defectos, no su ausencia
Testing shows the presence of defects, not their absence.
Las pruebas permiten demostrar que existen defectos en un sistema, pero no pueden garantizar que el software esté completamente libre de ellos.
Supongamos que un equipo ejecuta 2.000 casos de prueba y todos resultan satisfactorios. Esto proporciona evidencia de que el sistema funciona correctamente bajo las condiciones evaluadas, pero no demuestra matemáticamente que no exista algún escenario no probado que provoque un error.
Podemos expresarlo conceptualmente como:
Pruebas exitosas ≠ ausencia absoluta de defectos
En cambio:
Pruebas exitosas → mayor confianza en la calidad del producto
Ejemplo
Una aplicación bancaria permite realizar transferencias correctamente en las pruebas realizadas con montos entre Bs 1 y Bs 50.000.
Sin embargo, podría existir un defecto cuando:
- el monto es exactamente Bs 0;
- el monto supera determinado límite;
- existen múltiples transferencias simultáneas;
- ocurre una pérdida de conexión durante la transacción;
- dos operaciones modifican simultáneamente el mismo saldo.
El hecho de que cientos de pruebas anteriores hayan sido exitosas no demuestra que estos escenarios funcionen correctamente.
Relación con QA y gestión de riesgos
El objetivo de QA no debería ser declarar que un sistema tiene “cero errores”, sino determinar si existe suficiente evidencia para considerar que su nivel de calidad y riesgo residual es aceptable.
Una decisión de liberación podría plantearse como:
¿Los riesgos conocidos y residuales son suficientemente bajos como para desplegar el sistema?
Esta pregunta es mucho más profesional que preguntar simplemente:
“¿El sistema tiene errores?”
2. Las pruebas exhaustivas son imposibles
Exhaustive testing is impossible.
Probar absolutamente todas las combinaciones posibles de entradas, estados, dispositivos, configuraciones y secuencias de operación suele ser imposible excepto en sistemas extremadamente simples.
Consideremos un formulario con:
- 10 campos;
- múltiples valores posibles por campo;
- diferentes roles de usuario;
- diferentes navegadores;
- diferentes dispositivos;
- diferentes estados de la base de datos.
El número de combinaciones posibles puede crecer exponencialmente.
Por ejemplo, si únicamente existieran 10 campos y cada uno admitiera 10 valores relevantes:
10¹⁰ = 10.000.000.000 combinaciones
Si cada prueba necesitara solamente un segundo, ejecutarlas secuencialmente requeriría más de 317 años.
Por tanto, un ingeniero de testing no intenta probar todo. Debe seleccionar estratégicamente qué probar.
Técnicas utilizadas
Para reducir el espacio de pruebas pueden utilizarse técnicas como:
- partición de equivalencia;
- análisis de valores límite;
- tablas de decisión;
- pruebas por pares (pairwise testing);
- pruebas basadas en estados;
- pruebas exploratorias;
- pruebas basadas en riesgo.
Gestión de riesgos
Una estrategia profesional prioriza las pruebas considerando factores como:
Prioridad de prueba ≈ Probabilidad de fallo × Impacto del fallo
Por ejemplo:
| Funcionalidad | Probabilidad | Impacto | Prioridad |
|---|---|---|---|
| Login | Media | Alta | Alta |
| Pago electrónico | Alta | Crítica | Crítica |
| Cambio de color del perfil | Baja | Baja | Baja |
| Recuperación de contraseña | Media | Alta | Alta |
Los recursos de testing deberían concentrarse principalmente en las funcionalidades donde un defecto pueda producir consecuencias significativas.
3. Las pruebas tempranas ahorran tiempo y dinero
Early testing saves time and money.
El testing no debería comenzar cuando el software ya está terminado.
Las actividades de verificación y validación pueden comenzar desde las primeras etapas del ciclo de vida del software.
Por ejemplo, pueden revisarse:
- requisitos;
- historias de usuario;
- criterios de aceptación;
- modelos de datos;
- arquitectura;
- prototipos;
- contratos de API;
- diseños técnicos.
Esto permite detectar defectos antes de que sean implementados.
Ejemplo
Considere un requisito:
“El sistema deberá permitir registrar clientes mayores de edad.”
Surgen inmediatamente varias preguntas:
- ¿Mayor de edad significa ≥ 18?
- ¿La edad se calcula utilizando la fecha actual?
- ¿Qué sucede exactamente el día del cumpleaños?
- ¿Qué ocurre si la fecha de nacimiento es futura?
- ¿Qué zona horaria se utiliza?
Si estas ambigüedades se descubren durante la revisión de requisitos, corregirlas puede requerir pocos minutos.
Si se descubren después de implementar:
Requisito → Diseño → Backend → Frontend → Base de datos → Pruebas
la corrección puede afectar múltiples componentes.
Shift Left Testing
Este principio está relacionado con la filosofía Shift Left, que propone desplazar actividades de calidad hacia etapas más tempranas del desarrollo.
En lugar de:
Desarrollar → Terminar → Probar
se busca:
Requisitos → Verificar → Diseñar → Verificar → Desarrollar → Probar continuamente
Esto reduce el costo de corrección y mejora la prevención de defectos.
4. Los defectos tienden a agruparse
Defects cluster together.
Los defectos no suelen distribuirse uniformemente dentro de un sistema.
Normalmente, una cantidad relativamente pequeña de módulos concentra una proporción importante de los defectos.
Este fenómeno suele relacionarse conceptualmente con el principio de Pareto (80/20), aunque la distribución real no necesariamente será exactamente 80/20.
Un sistema podría presentar:
| Módulo | Defectos encontrados |
|---|---|
| Autenticación | 5 |
| Usuarios | 8 |
| Facturación | 41 |
| Inventario | 12 |
| Reportes | 7 |
El módulo de facturación debería recibir especial atención.
¿Por qué se agrupan los defectos?
Algunas causas frecuentes son:
- elevada complejidad;
- código legado;
- alta dependencia entre componentes;
- reglas de negocio complejas;
- cambios frecuentes;
- deuda técnica;
- diseños deficientes;
- múltiples desarrolladores modificando el mismo componente;
- requisitos ambiguos.
Aplicación en gestión de riesgos
Si históricamente un módulo presenta muchos defectos, constituye una señal de riesgo.
QA puede utilizar métricas como:
Densidad de defectos = Número de defectos / Tamaño del componente
También puede analizarse:
- severidad de defectos;
- frecuencia de cambios;
- número de incidentes en producción;
- complejidad del código;
- cobertura de pruebas.
Esta información permite desarrollar un enfoque de Risk-Based Testing.
5. Las pruebas pierden efectividad si siempre se repiten de la misma manera
Tests wear out.
Este principio fue conocido tradicionalmente como la paradoja del pesticida (Pesticide Paradox).
Si siempre ejecutamos exactamente las mismas pruebas, llegará un momento en que estas dejarán de encontrar defectos nuevos.
Esto no significa necesariamente que el sistema sea perfecto. Puede significar simplemente que nuestras pruebas ya no están explorando comportamientos diferentes.
Ejemplo
Supongamos que durante seis meses se prueba un formulario utilizando únicamente:
- nombres normales;
- correos válidos;
- números positivos;
- caracteres ASCII.
Las pruebas podrían ejecutarse exitosamente durante meses.
Posteriormente podrían incorporarse casos como:
- nombres extremadamente largos;
- caracteres Unicode;
- valores nulos;
- números negativos;
- entradas duplicadas;
- datos inesperados;
- operaciones concurrentes.
Estos escenarios pueden revelar defectos que las pruebas anteriores nunca detectaron.
Estrategias
Los casos de prueba deben revisarse periódicamente para:
- agregar nuevos escenarios;
- eliminar pruebas redundantes;
- incorporar defectos encontrados en producción;
- modificar datos de prueba;
- probar nuevos límites;
- incluir escenarios negativos;
- incorporar pruebas exploratorias.
Un defecto encontrado en producción debería generar una pregunta:
¿Qué prueba faltaba para detectar este problema antes del despliegue?
La respuesta puede convertirse en un nuevo caso de regresión.
6. Las pruebas dependen del contexto
Testing is context dependent.
No existe una única estrategia de testing adecuada para todos los sistemas.
La profundidad, técnicas y tipos de pruebas deben adaptarse al contexto del producto.
No debería probarse de la misma manera:
- una aplicación bancaria;
- un videojuego;
- una tienda electrónica;
- un sistema hospitalario;
- una aplicación educativa;
- un sistema de control industrial.
Ejemplo comparativo
En una aplicación bancaria probablemente sean prioritarias:
- seguridad;
- integridad transaccional;
- concurrencia;
- auditoría;
- disponibilidad;
- recuperación ante fallos.
En un videojuego podrían recibir mayor atención:
- rendimiento;
- compatibilidad gráfica;
- experiencia del usuario;
- estabilidad;
- comportamiento físico;
- consumo de recursos.
Factores contextuales
La estrategia de testing debe considerar:
Contexto técnico
- arquitectura;
- tecnologías utilizadas;
- infraestructura;
- integraciones.
Contexto de negocio
- criticidad del sistema;
- impacto financiero;
- cantidad de usuarios.
Contexto regulatorio
- protección de datos;
- auditoría;
- normativas específicas del sector.
Contexto de riesgo
- probabilidad de fallo;
- consecuencias del fallo.
Por tanto:
Estrategia de Testing = f(Contexto, Riesgo, Tecnología, Negocio)
7. La ausencia de errores no garantiza el éxito del producto
Absence-of-errors fallacy.
Un software puede tener pocos defectos técnicos y aun así fracasar completamente.
Esto sucede cuando el producto funciona correctamente desde el punto de vista técnico, pero no satisface las necesidades reales del usuario o del negocio.
Ejemplo
Una empresa desarrolla durante un año un sistema de reportes.
El sistema:
- no presenta errores graves;
- responde rápidamente;
- tiene buena seguridad;
- supera todas las pruebas funcionales.
Sin embargo, los usuarios necesitaban reportes diarios y el sistema únicamente permite generar reportes mensuales.
Técnicamente funciona.
Desde el punto de vista del negocio, el producto no cumple su propósito.
Esto permite distinguir dos preguntas fundamentales de la ingeniería de software:
Verificación
¿Estamos construyendo correctamente el producto?
Comprueba que el sistema cumple sus especificaciones.
Validación
¿Estamos construyendo el producto correcto?
Comprueba que el producto satisface las necesidades reales del usuario.
Un sistema de alta calidad requiere ambas.
Relación de los siete principios con la gestión de riesgos
Los siete principios convergen en una idea fundamental:
El testing es una actividad de reducción de incertidumbre y gestión del riesgo.
No podemos demostrar que un sistema carezca completamente de defectos y tampoco podemos probar todas las combinaciones posibles. Por tanto, debemos utilizar los recursos disponibles para obtener la mayor cantidad de información posible sobre los riesgos relevantes.
Podemos representar conceptualmente el riesgo como:
Riesgo = Probabilidad × Impacto
Por ejemplo:
| Riesgo | Probabilidad | Impacto | Nivel |
|---|---|---|---|
| Error visual menor | Alta | Bajo | Medio |
| Pérdida de información | Media | Crítico | Alto |
| Error en cálculo financiero | Alta | Crítico | Crítico |
| Lentitud ocasional | Media | Medio | Medio |
Las funcionalidades relacionadas con riesgos críticos deberían recibir:
- mayor cobertura;
- pruebas más profundas;
- automatización;
- pruebas negativas;
- pruebas de regresión;
- revisiones técnicas;
- monitoreo posterior al despliegue.
Resumen de los 7 principios
| # | Principio | Idea fundamental |
|---|---|---|
| 1 | Las pruebas muestran presencia de defectos | No pueden demostrar su ausencia absoluta. |
| 2 | Las pruebas exhaustivas son imposibles | Debemos seleccionar y priorizar qué probar. |
| 3 | Las pruebas tempranas ahorran tiempo y dinero | Detectar problemas antes reduce su costo. |
| 4 | Los defectos se agrupan | Algunos componentes concentran más riesgo y defectos. |
| 5 | Las pruebas pierden efectividad | Los casos deben evolucionar constantemente. |
| 6 | Las pruebas dependen del contexto | Cada sistema requiere una estrategia diferente. |
| 7 | Ausencia de errores ≠ producto exitoso | El software debe satisfacer necesidades reales. |
Aplicación práctica en un proyecto de software
Supongamos que un equipo desarrolla una plataforma de comercio electrónico.
Una estrategia basada en los siete principios podría ser:
- Aceptar que no se puede garantizar cero defectos, definiendo criterios de calidad y riesgo aceptable.
- Priorizar escenarios críticos, como pagos, inventario y autenticación.
- Revisar requisitos antes de programar, identificando ambigüedades tempranamente.
- Analizar los módulos con mayor historial de defectos y aumentar allí la cobertura.
- Actualizar continuamente las pruebas de regresión, especialmente después de incidentes.
- Diseñar las pruebas según el contexto del comercio electrónico, considerando seguridad, concurrencia, rendimiento y disponibilidad.
- Validar el producto con usuarios y negocio, verificando que la solución realmente resuelva sus necesidades.
Así, el testing deja de ser simplemente una fase ubicada al final del desarrollo y pasa a convertirse en una actividad continua dentro del ciclo de vida del software.
Conclusión
Los siete principios del software testing proporcionan una base conceptual para comprender las limitaciones y objetivos reales de las pruebas.
El testing profesional no consiste en ejecutar casos de prueba hasta que todos aparezcan en verde. Consiste en obtener evidencia sobre la calidad del sistema, descubrir defectos relevantes, reducir incertidumbre y proporcionar información que permita tomar decisiones sobre los riesgos del producto.
Desde una perspectiva universitaria y profesional, estos principios también muestran que QA es una responsabilidad que trasciende al equipo de pruebas. Analistas, desarrolladores, arquitectos, especialistas de QA, responsables de producto y usuarios participan de distintas maneras en la construcción de calidad.
Por ello, una organización madura no debería preguntarse únicamente:
“¿Cuántos casos de prueba pasaron?”
Debería preguntarse:
“¿Tenemos suficiente evidencia para afirmar que los riesgos más importantes del producto han sido evaluados y se encuentran dentro de niveles aceptables?”
Esta diferencia representa el paso de una visión operativa del testing hacia una verdadera ingeniería de calidad de software.