Aseguramiento de la calidad del software: Pruebas funcionales y no funcionales

Software Testing: Black Box and White Box Testing

En el desarrollo de software no basta con que una aplicación “funcione” en una demostración. También debe responder correctamente ante entradas válidas e inválidas, integrarse con otros componentes, mantener un rendimiento aceptable, proteger los datos, recuperarse de fallos y ofrecer una experiencia de uso adecuada. Ahí es donde entran el aseguramiento de la calidad y las pruebas de software.

Nota de actualización: este artículo fue publicado originalmente el 24 de julio de 2023 y ha sido revisado para incorporar terminología actual de ISTQB y el modelo de calidad de producto ISO/IEC 25010:2023, publicado posteriormente, en noviembre de 2023.

QA y pruebas de software no son exactamente lo mismo

Quality Assurance (QA) o aseguramiento de la calidad es un concepto más amplio que las pruebas. Incluye los procesos, prácticas, criterios, revisiones y controles utilizados para reducir defectos y conseguir que el producto alcance el nivel de calidad esperado.

Las pruebas de software forman parte de ese trabajo de calidad. Consisten en evaluar un producto, componente o sistema para obtener información sobre su comportamiento y detectar diferencias entre lo esperado y lo observado. No se limitan a “buscar bugs”: también sirven para generar confianza sobre el producto y aportar información para decidir si una versión está lista para avanzar o publicarse.

La calidad tampoco se consigue probando únicamente al final. Las revisiones de requisitos, el análisis estático, las pruebas de componentes, la integración continua y las pruebas de sistema permiten detectar problemas en diferentes momentos del ciclo de desarrollo.

Niveles de prueba, tipos de prueba y técnicas: una distinción importante

Una confusión frecuente es colocar en una misma lista las pruebas unitarias, de integración, funcionales, de regresión y de caja negra. En realidad describen cosas diferentes.

Los niveles de prueba indican sobre qué parte del sistema se trabaja: componente o unidad, integración, sistema y aceptación.
Los tipos de prueba indican qué característica se quiere comprobar: comportamiento funcional, propiedades no funcionales, estructura interna o efectos de los cambios, entre otras.
Las técnicas de prueba ayudan a diseñar los casos de prueba. Entre ellas están las técnicas de caja negra, caja blanca y las basadas en la experiencia.

Por tanto, una prueba de integración puede ser funcional o no funcional; una prueba de sistema puede medir rendimiento; y una prueba funcional puede diseñarse mediante técnicas de caja negra. Caja negra y caja blanca no son subcategorías exclusivas de las pruebas funcionales.

Pruebas funcionales

Las pruebas funcionales comprueban qué hace el sistema: reglas de negocio, cálculos, validaciones, flujos, permisos, respuestas de una API, operaciones sobre datos o cualquier comportamiento definido por requisitos y criterios de aceptación.

Un ejemplo sencillo sería un formulario de inicio de sesión. Entre las pruebas funcionales podrían estar comprobar credenciales válidas e inválidas, recuperación de contraseña, autenticación multifactor, bloqueo de cuentas y permisos según el rol del usuario.

Pruebas unitarias o de componentes

Comprueban unidades pequeñas y aislables, como una función, clase, módulo o componente. Suelen ejecutarse muy pronto y, en proyectos modernos, normalmente se automatizan para formar parte del proceso de integración continua.

Una buena prueba unitaria debe ser rápida, repetible y suficientemente aislada para que, cuando falle, resulte sencillo identificar qué parte del comportamiento se rompió. Sin embargo, tener muchas pruebas unitarias no sustituye las pruebas de integración o de sistema.

Pruebas de integración

Verifican la interacción entre componentes: módulos internos, bases de datos, colas, APIs, servicios externos o microservicios. Un módulo puede funcionar perfectamente por separado y fallar cuando cambia un contrato, un formato de datos, un tiempo de espera o una dependencia.

No existe una regla según la cual estas pruebas deban pertenecer exclusivamente a un equipo de QA. Dependiendo del proyecto pueden escribirlas y ejecutarlas desarrolladores, ingenieros de calidad o ambos. Lo importante es que existan responsabilidades claras y cobertura sobre las interfaces críticas.

Pruebas de sistema

Evalúan el sistema integrado como un conjunto. Aquí se comprueban flujos completos y requisitos que no pueden validarse correctamente observando un componente aislado. En una aplicación web, por ejemplo, se puede verificar desde la autenticación hasta una operación de negocio completa que involucre frontend, backend y base de datos.

Pruebas de aceptación

Determinan si el producto satisface las necesidades y criterios de aceptación acordados con usuarios, clientes o partes interesadas. Pueden incluir pruebas de aceptación de usuario, operacionales, contractuales o regulatorias según el contexto.

No tienen que ser necesariamente manuales. Parte de los criterios puede automatizarse, mientras que otros requieren evaluación humana. El objetivo no es repetir todas las pruebas anteriores, sino responder si el producto es aceptable para el uso previsto.

Smoke testing o pruebas de humo

Una prueba de humo es un conjunto reducido de verificaciones sobre funciones críticas que permite saber rápidamente si una versión es suficientemente estable como para continuar con pruebas más profundas. Es muy útil después de un despliegue o de generar una nueva build.

Puede ser manual o automatizada y no constituye un nivel de prueba independiente. Tampoco existe una posición obligatoria “entre integración y regresión”: se utiliza donde aporte una comprobación rápida de salud del sistema.

Pruebas de regresión y confirmación

Las pruebas de confirmación verifican que un defecto concreto haya sido corregido. Las pruebas de regresión comprueban que el cambio no haya introducido efectos secundarios en funcionalidades que antes funcionaban.

La regresión es uno de los mejores candidatos para automatización cuando los casos son repetitivos, estables y se ejecutan con frecuencia. Aun así, automatizar un caso que cambia constantemente puede generar más mantenimiento que beneficio.

Pruebas de API e interfaces

Las interfaces entre sistemas merecen pruebas específicas: códigos de estado, contratos, esquemas, autenticación, autorización, idempotencia, errores, límites, compatibilidad de versiones y comportamiento ante dependencias no disponibles. En arquitecturas distribuidas estas pruebas suelen detectar problemas antes y con menos coste que una prueba gráfica de extremo a extremo.

Las pruebas pueden observar el comportamiento funcional y múltiples atributos de calidad. Los niveles y las técnicas de prueba son dimensiones distintas.

Pruebas no funcionales: cómo se comporta el sistema

Las pruebas no funcionales evalúan propiedades de calidad que describen cómo se comporta el producto y bajo qué condiciones lo hace. No son pruebas “secundarias”: una aplicación puede cumplir todas sus funciones y seguir siendo inaceptable si es lenta, insegura, inaccesible o incapaz de recuperarse de un fallo.

ISO/IEC 25010:2023 define un modelo de calidad de producto con nueve características: adecuación funcional, eficiencia del rendimiento, compatibilidad, capacidad de interacción, fiabilidad, seguridad, mantenibilidad, flexibilidad y seguridad operacional (safety). La norma es un modelo de calidad, no una lista rígida de tipos de prueba, pero sirve como una referencia muy útil para identificar qué atributos deben medirse.

Pruebas de rendimiento

Evalúan tiempos de respuesta, rendimiento sostenido, uso de recursos y capacidad bajo condiciones definidas. Medir únicamente “cuánto tarda una página” suele ser insuficiente: en sistemas reales interesan métricas como latencia media y percentiles —por ejemplo p95 o p99—, transacciones por segundo, concurrencia, utilización de CPU y memoria, saturación y tasa de errores.

Carga: comportamiento con el volumen esperado de usuarios o transacciones.
Estrés: comportamiento al superar los límites normales y forma en que el sistema se degrada o recupera.
Picos: reacción ante incrementos bruscos de demanda.
Resistencia o endurance: estabilidad durante periodos prolongados.
Volumen: comportamiento con grandes cantidades de datos.

Pruebas de seguridad

Buscan identificar debilidades que puedan afectar la confidencialidad, integridad, autenticidad, autorización o disponibilidad del sistema. Deben abarcar más que la aplicación web: código, dependencias, configuración, APIs, identidad, sesiones, infraestructura y lógica de negocio pueden introducir vulnerabilidades.

En una estrategia moderna se combinan revisiones de código, análisis estático, análisis de dependencias, pruebas dinámicas, validación de configuración y pruebas manuales orientadas a riesgo. Para aplicaciones web, la OWASP Web Security Testing Guide es una referencia práctica ampliamente utilizada.

Usabilidad, capacidad de interacción y accesibilidad

Una interfaz puede ser técnicamente correcta y aun así resultar difícil de aprender, propensa a errores o inaccesible. Las pruebas de interacción y usabilidad observan si las personas pueden completar sus tareas con claridad y eficiencia.

En productos web, la accesibilidad debe verificarse con criterios técnicos y también con pruebas reales de teclado, foco, lectores de pantalla y otros mecanismos de asistencia. Las WCAG 2.2 del W3C son actualmente una referencia fundamental para evaluar accesibilidad web.

Compatibilidad e interoperabilidad

Comprueban el comportamiento en navegadores, sistemas operativos, dispositivos, resoluciones, versiones de protocolos y combinaciones de componentes. La interoperabilidad evalúa además si distintos productos pueden intercambiar información y utilizar correctamente la información intercambiada.

Fiabilidad, recuperación y resiliencia

Evalúan la capacidad del sistema para continuar prestando servicio o recuperarse ante fallos: pérdida temporal de red, caída de una dependencia, reinicios, corrupción de datos, falta de espacio, límites de recursos o errores parciales. En sistemas críticos conviene probar explícitamente los mecanismos de recuperación y no asumir que “deberían funcionar”.

Escalabilidad y flexibilidad

La escalabilidad estudia cómo responde el sistema al crecimiento de carga, usuarios, datos o recursos. ISO/IEC 25010:2023 incorpora la escalabilidad dentro de la característica de flexibilidad, junto con aspectos como adaptabilidad, instalabilidad y reemplazabilidad.

Pruebas manuales y automatizadas: no son rivales

La automatización no convierte automáticamente una prueba en mejor. Su principal ventaja es la repetibilidad: permite ejecutar el mismo conjunto de verificaciones de forma rápida y consistente, integrarlo en CI/CD y obtener retroalimentación frecuente.

Las pruebas manuales siguen siendo valiosas para exploración, evaluación de experiencia de usuario, escenarios poco frecuentes, investigación de defectos y comprobaciones donde el juicio humano aporta información que un script no puede valorar por sí solo.

Una automatización mal diseñada también puede fallar: datos inestables, dependencias externas, temporizaciones frágiles o selectores de interfaz poco robustos generan pruebas intermitentes o flaky. Por eso conviene automatizar primero los casos repetitivos, críticos y suficientemente estables, y mantener una proporción razonable entre pruebas de componentes, APIs e interfaz gráfica.

Pruebas manuales y automatizadas se complementan; la decisión depende del riesgo, la frecuencia y el coste de mantenimiento.

Un ejemplo práctico: probar un inicio de sesión

Supongamos que desarrollamos el acceso a una aplicación empresarial. Una estrategia razonable podría combinar:

Pruebas unitarias para reglas de validación y generación de tokens.
Pruebas de integración contra el proveedor de identidad o la base de datos.
Pruebas funcionales de credenciales válidas, inválidas, MFA, bloqueo y recuperación de cuenta.
Pruebas de seguridad sobre fuerza bruta, gestión de sesión, autorización y exposición de información.
Pruebas de rendimiento para conocer cuántos inicios de sesión concurrentes soporta el servicio y con qué latencia.
Pruebas de accesibilidad con teclado, foco visible y tecnologías de asistencia.
Pruebas de compatibilidad en los navegadores y dispositivos soportados.
Pruebas de regresión automatizadas en cada cambio relevante.

Ese ejemplo muestra por qué no existe una única “prueba correcta”. La cobertura útil surge de combinar niveles, tipos y técnicas según el riesgo del producto.

Herramientas habituales para automatización y evaluación

La herramienta depende del tipo de prueba y de la tecnología. Algunas opciones ampliamente utilizadas son:

Playwright y Selenium para automatización de navegadores.
pytest para proyectos Python y JUnit para Java.
Grafana k6 y Apache JMeter para pruebas de carga y rendimiento.
OWASP ZAP como herramienta de apoyo para pruebas de seguridad de aplicaciones web.

No conviene elegir una herramienta solo por popularidad. Hay que valorar integración con el stack, mantenimiento de las pruebas, facilidad para depurar fallos, ejecución paralela, integración con CI/CD y coste operativo.

Conclusiones

El aseguramiento de la calidad no consiste en ejecutar una batería de pruebas al terminar el proyecto. Es una actividad continua que comienza con requisitos claros y criterios de aceptación verificables, y continúa con revisiones, pruebas en distintos niveles, automatización donde aporte valor y evaluación de atributos no funcionales.

La distinción entre funcional y no funcional sigue siendo útil, pero no debe confundirse con los niveles de prueba ni con técnicas como caja negra o caja blanca. Un plan de pruebas eficaz combina todas esas dimensiones y prioriza según el riesgo: qué puede fallar, qué impacto tendría y qué evidencia necesitamos antes de liberar el producto.