Una prueba no funcional es una prueba cuyo objetivo es la verificación de un requisito que

especifica criterios que pueden usarse para juzgar la operación de un sistema.

(Requisitos no funcionales) como por ejemplo la disponibilidad, accesibilidad, usabilidad,

mantenibilidad, seguridad, rendimiento.

Las pruebas no funcionales se enfocan en validar un sistema o aplicación por medio de

sus requerimientos no funcionales, es decir, la forma en que el sistema funciona y no por medio
de comportamientos específicos.

Las características no funcionales de un sistema o aplicación con frecuencia se cuantifican en

escalas variables, como por ejemplo los tiempos de respuesta en pruebas de desempeño.

El ISTQB establece que la omisión de las pruebas no funcionales puede ocasionar problemas de
calidad potencialmente catastróficos luego de la salida a producción, sin embargo, estos tipos de
pruebas son costosos, por lo que deben evaluarse los riesgos antes de comprometer los recursos
del proyecto.

En este artículo te presentamos 10 tipos de pruebas no funcionales, específicamente las pruebas

de usabilidad, seguridad, carga, estrés, volumen, configuración, rendimiento, escalabilidad,
recuperación y mantenibilidad.

10 tipos de pruebas no funcionales

A continuación te presentamos una lista no limitativa de 10 tipos de pruebas no funcionales que
puedes incluir en tu plan de pruebas de software.

1. - Pruebas de carga
Las pruebas de carga consisten en simular demanda sobre una aplicación de software y medir el
resultado. Estas pruebas se realizan bajo demanda esperada y también en condiciones de
sobrecarga (picos en la demanda).

Para ejecutar estas pruebas, se requiere del uso de herramientas de testing que simulen la
carga, como por ejemplo SoapUI.

Las pruebas de carga ayudan a identificar la máxima capacidad operativa de una aplicación, así
como en el identificar cuellos de botella y las causas de posible degradación del desempeño.

Cuando la carga de prueba se eleva por encima de los parámetros esperados, a estas pruebas se
les conoce como pruebas de estrés.

2. - Pruebas de estrés
Son pruebas de carga que se realizan con demandas mayores a la capacidad operativa, con
frecuencia hasta llegar al punto de ruptura.

Este tipo de prueba de software se utiliza para determinar la estabilidad de un sistema o

aplicación, con especial atención en la disponibilidad y manejo de errores cuando se enfrenta a la
sobrecarga.

Al igual que para las pruebas de carga, se requieren de herramientas que simulen la demanda,
SoapUI es una de estas herramientas que permite simular peticiones para servidores de
aplicaciones web.

Aquí te compartimos un Tutorial de SopaUI.

Con las pruebas de estrés se pueden identificar los puntos de ruptura, límites para uso seguro de
la aplicación, confirmar las especificaciones de diseño, identificar las formas en que el sistema
falla, entre otros aspectos.

3. - Pruebas de volumen
Las pruebas de volumen consisten en validar el funcionamiento de la aplicación con ciertos
volúmenes de datos.

Por ejemplo, si se quiere ver el comportamiento de una aplicación con un tamaño de base de datos
específico, se expande el tamaño de base de datos a dichos parámetros y luego e realizan
consultas, procesos o funcionalidades de la aplicación, midiendo su desempeño.

El sujeto de pruebas no está limitado a bases de datos, también se puede usar por ejemplo para
medir el desempeño de una interfaz cuando el archivo de interfaz (un archivo de texto, xml, etc.)
supera cierto tamaño.

El objetivo es ver si dado ciertos volúmenes de datos la aplicación funciona con normalidad, cuales
son los límites máximos de volúmenes de datos para la operación e identificar condiciones de falla.

4. - Pruebas de configuración
En lugar de probar el desempeño de una aplicación desde la perspectiva de la carga, las pruebas
de configuración se usan para validar que efectos en el desempeño tienen ciertos cambios en la
configuración.

Un ejemplo típico de esta situación es experimentar con diferentes métodos de balanceo de cargas
y ver la respuesta de la aplicación a niveles similares de sobrecarga.

Otro ejemplo es verificar si el sistema es capaz de funcionar adecuadamente en diferentes

versiones o configuraciones de entornos de hardware y software, como pueden ser diversos
navegadores de internet, versiones de navegadores, entre otros.

5. - Pruebas de usabilidad
En las pruebas de usabilidad, los testers de software se enfocan en validar que tan fácil de usar
es una determinada aplicación.

Las características evaluadas en la usabilidad incluyen:

 Facilidad de aprendizaje: Que tan fácil es para los usuarios realizar funciones básicas la
primera vez que utilizan la aplicación.
 Eficiencia: Que tan rápido los usuarios experimentados pueden realizar sus tareas.
 Memorización: Que tan fácil de memorizar es el uso de la aplicación, esto es, cuando un
usuario pasa mucho tiempo sin usar la aplicación, puede recordar lo suficiente para usarla con
efectividad la próxima vez, o tiene que empezar a aprender de nuevo.
 Errores: Cuantos errores atribuibles al diseño comete el usuario, que tan severos son y
que tan fácil es recuperarse de los mismos.
 Satisfacción: Que tanto le gusta (o desagrada) al usuario utilizar el sistema.

6. - Pruebas de seguridad
Consiste en probar los atributos o características de seguridad del sistema, si es un sistema seguro
o no, si puede ser vulnerado, si existe control de acceso por medio de cuentas de usuario, si
pueden ser vulnerados estos accesos.

Las pruebas de seguridad también sirven para validar si el equipo de desarrollo de software ha
seguido prácticas de seguridad recomendadas en su programación.

Entre las características de seguridad de un sistema, están la confidencialidad, integridad,

autenticación, autorización y la disponibilidad.

7. - Pruebas de resistencia
Las pruebas de resistencia implican someter a un Sistema o aplicación a una carga determinada
durante un período de tiempo, para determinar cómo se comporta luego de un uso prolongado.

Un sistema informático puede comportarse de forma normal durante las primeras horas, sin
embargo, luego de cierto tiempo, problemas como fugas de memoria suelen ocasionar fallas.

Estos defectos en el desarrollo de software no pueden identificarse bajo pruebas funcionales

normales, por lo que es conveniente involucrar pruebas de resistencia entre los tipos de pruebas
de software.

8. - Pruebas de escalabilidad
Las pruebas de escalabilidad consisten en verificar la capacidad de una aplicación de escalar
cualquiera de sus características no funcionales, como por ejemplo la carga que soporta, número
de transacciones, volúmenes de datos, entre otros.

Al diseñar casos de prueba de escalabilidad, es recomendable considerarlos en bloques

incrementales, dada la dificultad de predecir la carga real que tendrá una aplicación luego de
implementada en producción.

Probar en bloques incrementales significa por ejemplo primero probar con niveles de demanda
bajos, luego incrementar a niveles de demanda medios y finalmente probar con altos niveles de
carga. De esta manera se puede determinar que también escala la aplicación y los problemas que
comienzan a surgir en distintos niveles.

Para que los resultados sean confiables, los ambientes de prueba y su configuración deben
mantenerse constantes.
9. - Pruebas de recuperación
Las pruebas de recuperación se realizan para verificar que tan rápido y que tan bien se recupera
una aplicación luego de experimentar un falló de hardware o software.

Por lo tanto, para realizar pruebas de recuperación se requiere forzar la falla y luego verificar si la
recuperación ocurre adecuadamente.

Por ejemplo, cuando una aplicación esté funcionando desconectar el cable de red, o en
una aplicación móvil interrumpir la conexión con la red Wi-Fi o con la operadora, para luego
restablecer la conexión.

10. - Pruebas de mantenibilidad

Básicamente consisten en evaluar que tan fácil es realizar el mantenimiento de un sistema o
aplicación. Esto significa que tan fácil es analizar, cambiar y probar estos cambios.

Para realizar esta prueba deben evaluarse la forma en que está implementada la aplicación,
siguiendo buenas prácticas de ingeniería de software. Es decir, que se estén siguiendo los
patrones recomendados de ingeniería de software y que no se estén introduciendo
inadvertidamente anti patrones, esto es, que no se estén cometiendo errores comunes de
programación.

¿Y qué opinas tú?

¿Has realizado pruebas no funcionales de software? ¿Qué herramientas has utilizado? ¿Cuáles
buenas prácticas aprendiste y que errores recomendarías evitar?

Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática

(pmoinformatica) (Si lo deseas, puedes firmar tu comentario con la dirección de tu web).