Pruebas de software

Las pruebas de software (en inglés, software testing) son las investigaciones empíricas y técnicas realizadas para proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad del proceso de ingeniería de software que consiste en la ejecución de un programa o aplicación con el propósito de encontrar fallos (bugs), errores o defectos, asegurando que el producto de software cumple con los requisitos especificados y funciona según lo previsto.^[1]

Diagrama que ilustra cómo, en las pruebas basadas en multitudes (crowdsourced testing), donde la evaluación recae en un gran número de colaboradores mediante un esquema abierto y participativo (crowdsourcing).

v t e

[editar datos en Wikidata]

Las pruebas son una parte integral del aseguramiento de la calidad del software (SQA). Aunque tradicionalmente se asociaban a la etapa final del desarrollo, las metodologías modernas como DevOps y Agile promueven el enfoque Shift-left, que integra las pruebas desde las fases iniciales de diseño y codificación.^[2]

Historia

El concepto de pruebas de software ha evolucionado paralelamente al desarrollo de la informática, pasando de ser una actividad correctiva a una preventiva.

Era de la depuración (1950s)

En los inicios, no existía una distinción formal entre probar (testing) y depurar (debugging). Las pruebas eran realizadas ad hoc por los propios programadores para corregir errores evidentes.

Era de la demostración (1957-1978)

Charles Baker distinguió formalmente entre depuración y pruebas. El objetivo principal era demostrar que el software cumplía con los requisitos establecidos, un enfoque positivo o constructivo.^[3]

Era de la destrucción (1979-1982)

Glenford Myers, en su obra clásica The Art of Software Testing, introdujo un cambio de paradigma vital al definir la prueba como "el proceso de ejecutar un programa con la intención de encontrar errores". Esto estableció una mentalidad "destructiva" necesaria para desafiar al software y encontrar fallos ocultos.^[1]

Era de la evaluación y prevención (1983-presente)

Con la aparición de estándares como el IEEE 829 (actualmente ISO/IEC/IEEE 29119), las pruebas se formalizaron como una disciplina que abarca todo el ciclo de vida. El enfoque actual busca no solo detectar errores, sino prevenir su inclusión desde el análisis de requisitos.

Terminología fundamental

Es crucial distinguir entre tres conceptos a menudo confundidos en la industria, definidos por el estándar IEEE 610:^[4]

• Error (Error): acción humana equivocada que produce un resultado incorrecto (ej. un programador interpreta mal un requisito).
• Defecto (Fault/Bug): el resultado del error en el código; es la anomalía lógica en el software.
• Fallo (Failure): la manifestación física o funcional del defecto cuando el software es ejecutado. Un defecto puede existir sin causar un fallo si esa línea de código nunca se ejecuta.

Caso de prueba

Un caso de prueba (test case) es un conjunto de condiciones bajo las cuales un probador determinará si una aplicación satisface los requisitos. Debe incluir:

• Identificador único.
• Precondiciones (estado del sistema antes de la prueba).
• Pasos de ejecución.
• Datos de entrada.
• Resultados esperados.
• Poscondiciones.

Principios de las pruebas

Según el International Software Testing Qualifications Board (ISTQB), existen siete principios fundamentales que guían las pruebas de software:^[5]

• Las pruebas demuestran la presencia de defectos: las pruebas pueden demostrar que hay errores, pero no pueden probar que no los hay.
• Las pruebas exhaustivas son imposibles: probar todas las combinaciones de entradas y precondiciones no es factible, salvo en casos triviales. Se debe usar el análisis de riesgos para priorizar.
• Pruebas tempranas: las actividades de prueba deben comenzar lo antes posible en el ciclo de vida para prevenir defectos (coste de corrección mucho menor).
• Agrupamiento de defectos: un pequeño número de módulos suele contener la mayoría de los defectos descubiertos.
• Paradoja del pesticida: si las mismas pruebas se repiten una y otra vez, eventualmente dejarán de encontrar nuevos defectos. Los casos de prueba deben revisarse y actualizarse periódicamente.
• Las pruebas dependen del contexto: no se prueba igual un sitio web de comercio electrónico que un software de control de tráfico aéreo.
• La falacia de la ausencia de errores: encontrar y corregir defectos no ayuda si el sistema construido no satisface las necesidades del usuario.

Verificación y validación (V&V)

Estos dos términos, aunque relacionados, tienen objetivos distintos según el modelo de capacidad de madurez (CMMI):^[6]

• Verificación: "¿Estamos construyendo el producto correctamente?". Se asegura de que el software cumple con las especificaciones técnicas y los estándares de diseño. Incluye revisiones de código y análisis estático.
• Validación: "¿Estamos construyendo el producto correcto?". Se asegura de que el software cumple con las necesidades y expectativas del usuario final en su entorno real.

Proceso de desarrollo de software

Los enfoques de desarrollo condicionan el momento y la forma en que se realizan las pruebas:

• Desarrollo en cascada: las etapas se suceden de manera secuencial y, en teoría, sin retrocesos. Las pruebas se sitúan tradicionalmente al final del ciclo, lo que puede dificultar la corrección temprana de errores.
• Desarrollo iterativo e incremental: divide los requisitos en subconjuntos y los construye en ciclos sucesivos; cada incremento incluye su propio conjunto de pruebas.
• Desarrollo iterativo (proceso espiral, por ejemplo): permite revisar los requisitos a lo largo de todo el ciclo, incorporando pruebas en cada iteración.
• Métodos ágiles: procesos iterativos e incrementales con iteraciones cortas que integran pruebas continuas. Entre las metodologías más extendidas se encuentran Scrum y Extreme Programming.

Estrategias de prueba

Las pruebas pueden clasificarse según si requieren la ejecución del código o no, y según el nivel de conocimiento del funcionamiento interno del sistema.

• Pruebas de caja blanca
• Pruebas de caja negra
• Pruebas exploratorias o aleatorias^[7]

Estáticas vs. Dinámicas

• Pruebas estáticas: se realizan sin ejecutar el código. Incluyen revisiones de documentación, inspecciones de código, revisión por pares (peer reviews) y análisis estático mediante herramientas automatizadas (linters, SonarQube). Son altamente efectivas en costos, ya que detectan errores en fases tempranas.

• Pruebas dinámicas: requieren la ejecución del código para observar el comportamiento del sistema ante diferentes entradas.

Caja blanca vs. Caja negra

• Pruebas de caja blanca (estructurales): el probador conoce la estructura interna del código. Se centra en verificar flujos de control, bucles, condiciones y sentencias. Es típica de las pruebas unitarias.

• Pruebas de caja negra (funcionales): el probador no conoce (o ignora) la estructura interna. Se centra en las entradas y salidas esperadas según los requisitos.

• Pruebas de caja gris: una combinación donde se tiene conocimiento parcial de las estructuras internas para diseñar mejores casos de prueba de caja negra.

Pruebas contra especificación (ESRE)

Las Especificaciones de Requerimientos de Software (ESRE) describen de forma completa lo que el sistema debe hacer, sin detallar el cómo. Sirven de base para que los probadores (incluidos los probadores beta) validen si el software se comporta conforme a los requisitos funcionales y no funcionales definidos. A partir de las ESRE se pueden derivar casos de prueba detallados.

Tipos de pruebas por su ejecución

• Pruebas manuales
• Pruebas automáticas

Clasificación de las pruebas según lo que verifican

Pruebas funcionales

Artículo principal: Pruebas funcionales

Evalúan funciones específicas del software basadas en los requisitos funcionales. Entre los tipos más comunes se incluyen:

• Pruebas unitarias
• Pruebas de componentes
• Pruebas de integración
• Pruebas de sistema
• Pruebas de humo
• Pruebas alpha
• Pruebas beta
• Pruebas de aceptación
• Pruebas de regresión

Niveles de prueba

Los niveles de prueba definen el alcance de la prueba dentro del ciclo de desarrollo:

• Pruebas unitarias (Unit Testing): verifican el funcionamiento de las partes más pequeñas de código (funciones, métodos o clases) de forma aislada. Generalmente son escritas por los desarrolladores.

• Pruebas de integración: verifican la interacción entre diferentes módulos o componentes que ya han sido probados unitariamente. Buscan errores en las interfaces y flujo de datos.

• Pruebas de sistema: evalúan el sistema completo e integrado para verificar que cumple con los requisitos especificados. Se realizan en un entorno lo más parecido posible al de producción.

• Pruebas de aceptación (UAT): realizadas a menudo por el cliente o usuarios finales para validar si el sistema está listo para su despliegue operativo. Incluyen pruebas Alfa y Beta.

Pruebas no funcionales

Verifican requisitos de calidad tales como disponibilidad, usabilidad, seguridad o rendimiento.^{[cita requerida]}

• Pruebas de compatibilidad: verifican el funcionamiento en diferentes navegadores, sistemas operativos o dispositivos.
• Pruebas de seguridad: verifican vulnerabilidades, autenticación, autorización y protección de datos.
• Pruebas de estrés
• Pruebas de usabilidad: evalúan la facilidad de uso y la experiencia del usuario (UX).
• Pruebas de rendimiento: incluye pruebas de carga (volumen esperado), estrés (puntos de rotura) y escalabilidad.
• Pruebas de internacionalización y localización
• Pruebas de escalabilidad
• Pruebas de mantenibilidad
• Pruebas de instalabilidad
• Pruebas de portabilidad

Herramientas y automatización

La industria utiliza una amplia variedad de herramientas para apoyar el proceso de pruebas. La automatización de pruebas consiste en el uso de software especial para controlar la ejecución de pruebas y comparar los resultados reales con los esperados.^[2]

Las herramientas se clasifican generalmente en:

• Gestión de pruebas: permiten planificar, redactar casos de prueba y rastrear defectos (ej. Jira, TestLink, Zephyr).
• Ejecución funcional: automatizan la interacción con la interfaz de usuario o APIs (ej. Selenium, Appium, Cypress, Robot Framework).
• Pruebas de rendimiento: simulan múltiples usuarios concurrentes (ej. Apache JMeter, Gatling, LoadRunner).
• Análisis estático: analizan el código fuente en busca de patrones problemáticos sin ejecutarlo (ej. SonarQube).

Véase también

• Ingeniería de software
• Automatización de pruebas
• Pruebas de humo (informática)
• Calidad de software
• Integración continua
• Desarrollo guiado por pruebas (TDD)
• International Software Testing Qualifications Board (ISTQB)