Las pruebas no funcionales se refieren a las pruebas de software que se realizan para comprobar los aspectos no funcionales de una aplicación informática.
Hay muchos tipos diferentes de pruebas no funcionales, y algunos tipos de pruebas de software pueden considerarse pruebas funcionales y no funcionales al mismo tiempo.
Las pruebas no funcionales son necesarias porque evalúan criterios esenciales para el usuario, como el rendimiento y la usabilidad, y verifican si el software funciona como se espera fuera de su funcionalidad básica.
En este artículo, exploramos la definición y las características de las pruebas no funcionales junto con los tipos de pruebas no funcionales, los enfoques de las pruebas no funcionales y las herramientas de pruebas que pueden ayudar a optimizar y mejorar sus propios procesos de pruebas no funcionales.
¿Qué son las pruebas no funcionales?
Las pruebas no funcionales son cualquier tipo de prueba de software en la que se comprueban aspectos no funcionales de la construcción del software.
Algunos ejemplos de pruebas no funcionales son las destinadas a evaluar la capacidad, el rendimiento, la facilidad de uso, la recuperación y la portabilidad.
Verificar la calidad y el estado de cada uno de estos criterios no funcionales es tan importante como verificar las funciones de un software, pero estos parámetros no se comprueban en las pruebas funcionales estándar.
Esencialmente, las pruebas no funcionales consisten en comprobar “cómo” funcionan las funciones del software en lugar de comprobar “si” funcionan.
1. ¿Cuándo se necesitan pruebas no funcionales?
Las pruebas no funcionales se llevan a cabo durante la fase de pruebas del sistema del software, una vez realizadas las pruebas unitarias y de integración.
Durante las pruebas del sistema, los probadores llevarán a cabo pruebas funcionales y no funcionales, empezando por las pruebas funcionales.
Una vez que los probadores han comprobado que el software funciona como se espera, realizan pruebas no funcionales para evaluar si también cumple los parámetros no funcionales.
Suele ser necesario realizar las pruebas funcionales antes que las no funcionales, porque es imposible comprobar la fiabilidad o el rendimiento de funciones que no funcionan en absoluto. Las pruebas no funcionales son una de las últimas etapas de las pruebas de software antes de las pruebas de aceptación del usuario y el lanzamiento final del producto.
2. Cuando no necesita pruebas no funcionales
Siempre es importante probar los aspectos no funcionales del software, a menos que ya se hayan probado y se haya comprobado que son adecuados.
Aunque ya se hayan realizado pruebas no funcionales de software con anterioridad, puede ser necesario volver a probar parámetros no funcionales, por ejemplo, si se han añadido nuevas funciones al software o si se han introducido cambios en el código que puedan afectar al rendimiento y la fiabilidad.
Objetivos de las pruebas no funcionales
Los objetivos de las pruebas no funcionales son comprobar que el producto cumple las expectativas del usuario y optimizarlo antes de su lanzamiento.
También puede ayudar a desarrolladores y probadores a comprender mejor el software y utilizar estos conocimientos en futuras optimizaciones.
1. 1. Control de calidad
El objetivo de las pruebas no funcionales es comprobar los factores que influyen en la usabilidad, fiabilidad, mantenimiento, portabilidad y eficacia del producto.
Probar estos elementos garantiza que el producto que se lanza al mercado tiene la calidad adecuada y cumple las expectativas de los usuarios en cuanto a rendimiento, tiempos de carga y capacidad de uso.
2. 2. Gestión de riesgos
Las pruebas no funcionales también reducen el riesgo y el coste asociados al lanzamiento de un producto al mercado al maximizar las posibilidades de que el equipo lance un producto satisfactorio.
La comprobación de los parámetros no funcionales del software permite reducir los costes de lanzamiento del producto, ya que se reduce la necesidad de nuevos desarrollos y cambios en el software.
3. Optimización
Las pruebas no funcionales ayudan a probadores y desarrolladores a optimizar la creación del software y el rendimiento durante la instalación, configuración, ejecución y uso.
También puede utilizar las pruebas no funcionales para optimizar el modo en que gestiona y supervisa la creación del software.
4. 4. Recogida de datos
Las pruebas no funcionales permiten a los probadores recopilar y producir mediciones y métricas que pueden ser utilizadas por los equipos de pruebas para la investigación y el desarrollo internos.
Puede utilizar los datos que obtenga de las pruebas no funcionales para comprender cómo funciona su producto y cómo puede optimizarlo de forma más eficaz para los usuarios.
5. Mejora de los conocimientos
Las pruebas no funcionales mejoran y amplían los conocimientos del equipo de pruebas sobre el comportamiento del producto y las tecnologías que utiliza.
Esto no sólo ayuda a los equipos de pruebas a comprender mejor el software en el que están trabajando, sino que también puede proporcionar conocimientos útiles que ayuden a los probadores a comprender mejor las futuras compilaciones.
¿Quién participa en las pruebas no funcionales?
Las pruebas no funcionales suelen realizarlas los probadores en el entorno de control de calidad, pero a veces los desarrolladores pueden llevarlas a cabo durante el desarrollo.
Las pruebas del sistema las realizan casi siempre los probadores, y es la fase de las pruebas en la que tiene lugar la mayor parte de las pruebas no funcionales.
Si las pruebas no funcionales fallan, los probadores devolverán el software a los desarrolladores para que corrijan los errores de funcionamiento antes de volver a probarlo.
Ventajas de las pruebas no funcionales
Las pruebas no funcionales tienen muchas ventajas y son una etapa esencial de las pruebas de sistemas.
Sin las pruebas no funcionales, los equipos de pruebas no podrían verificar que el software cumple realmente los requisitos del cliente o que cumple los requisitos establecidos en el plan de desarrollo del software.
1. Mejorar el rendimiento del software
Las pruebas no funcionales pueden ayudar a probadores y desarrolladores a mejorar el rendimiento general de las aplicaciones informáticas. Las pruebas no funcionales detectan las deficiencias de rendimiento del software, por ejemplo en velocidad de carga o capacidad de procesamiento, e incitan a los equipos de software a introducir cambios para corregir estos defectos.
De este modo se garantiza que los equipos de software sólo lo pongan a disposición del público cuando esté listo y su rendimiento sea lo suficientemente bueno.
2. Mantener el software seguro
Las pruebas no funcionales incluyen pruebas de seguridad, que son fundamentales para garantizar que un software creado es seguro y está a salvo de amenazas y ataques externos.
Las pruebas de seguridad permiten a probadores y desarrolladores comprobar que el software protege adecuadamente los datos confidenciales y dispone de seguridad suficiente para protegerse de los ciberataques actuales.
3. Aumentar la facilidad de uso del software
Las pruebas no funcionales son la mejor manera de hacer que el software sea más fácil de usar, sobre todo realizando pruebas de usabilidad que evalúen lo fácil que es para los usuarios aprender a utilizar y manejar el software.
La facilidad de uso es muy importante porque determina el grado de satisfacción de los usuarios con su software y garantiza que los usuarios sean capaces de aprovechar al máximo todo lo que ofrece su software.
4. Garantizar que el software satisface las necesidades del usuario
Garantizar que el software satisface las necesidades de los usuarios debería ser una de las principales prioridades de todos los equipos de desarrollo y pruebas de software. Además de esperar que el software sea funcional, los usuarios esperan que funcione bien, se ejecute sin problemas y proteja los datos confidenciales.
Las pruebas no funcionales son una de las únicas formas de garantizar que el software cumple estos requisitos.
Los retos de las pruebas no funcionales
La realización de pruebas no funcionales presenta algunos inconvenientes. Aunque las pruebas no funcionales son esenciales durante la fase de prueba del sistema de pruebas de software, el proceso de pruebas no funcionales puede plantear retos a los equipos de software que no disponen de recursos y herramientas suficientes.
1. Repetición
En las pruebas de software, las pruebas no funcionales deben realizarse cada vez que los desarrolladores actualizan el software o cada vez que se modifica el código. Esto significa que las pruebas no funcionales pueden ser muy repetitivas, lo que no sólo lleva tiempo, sino que también cansa a los probadores.
Los probadores cansados que realizan tareas muy repetitivas también son más propensos a distraerse y cometer errores.
2. Coste
Dado que las pruebas no funcionales son tan repetitivas, también pueden ser bastante costosas, especialmente para los equipos de pruebas que dependen de las pruebas no funcionales manuales.
Los equipos de software deben asignar tiempo y presupuesto a pruebas no funcionales frecuentes, y los desarrolladores de software tendrán que pagar más por estas pruebas adicionales.
¿Qué probamos en las pruebas no funcionales?
Las pruebas no funcionales pueden utilizarse para comprobar muchos parámetros no funcionales diferentes, cada uno de los cuales afecta a la calidad y la usabilidad del sistema. Cada uno de estos parámetros se comprueba durante las pruebas del sistema en función de los criterios establecidos en el plan de pruebas.
1. Seguridad
Las pruebas de seguridad son un tipo de pruebas no funcionales que miden el grado de protección de un sistema frente a amenazas y ataques externos. Entre ellas se incluyen las violaciones deliberadas de la seguridad, así como las fugas de datos y otras infracciones comunes.
Las pruebas de seguridad son un paso importante en las pruebas no funcionales, porque proporcionan a los usuarios finales y a los clientes la tranquilidad de que sus datos están seguros.
2. Fiabilidad
Los probadores utilizan las pruebas no funcionales para evaluar la fiabilidad del software y asegurarse de que éste puede realizar continuamente sus funciones especificadas sin fallos.
Mientras que las pruebas funcionales garantizan que el software lleva a cabo sus funciones clave, sólo las pruebas no funcionales comprueban realmente la fiabilidad y repetibilidad de estos resultados.
3. Supervivencia
La capacidad de supervivencia describe cómo responde un sistema de software en caso de fallo de funcionamiento, y las pruebas de supervivencia garantizan que, si se producen errores y fallos, el sistema pueda recuperarse por sí mismo.
Las pruebas de supervivencia pueden comprobar si el software es capaz de guardar datos para minimizar la pérdida de datos en caso de fallo repentino, por ejemplo.
4. Disponibilidad
La disponibilidad del software se refiere al grado en que el usuario puede depender del sistema durante su funcionamiento. Esto también se llama estabilidad, y se comprueba mediante pruebas de estabilidad.
Las pruebas de estabilidad tienen cierto parecido con las pruebas de fiabilidad porque comprueban si el sistema puede funcionar según los estándares esperados de forma constante.
5. Usabilidad
Las pruebas de usabilidad son otro tipo importante de pruebas no funcionales en las pruebas de software. Este tipo de prueba evalúa la capacidad del usuario para aprender, manejar y utilizar el sistema informático siguiendo las instrucciones que aparecen en la pantalla y otras guías básicas.
Las pruebas de usabilidad son importantes porque si el software no es muy usable, la mayoría de los usuarios simplemente lo abandonarán o elegirán usar otra cosa.
6. Escalabilidad
Las pruebas de escalabilidad comprueban hasta qué punto una aplicación informática puede ampliar su capacidad de procesamiento para satisfacer una demanda creciente.
Por ejemplo, si el programa está diseñado para que lo utilicen varios usuarios a la vez en una misma red, ¿cómo funciona cuando diez usuarios se conectan al mismo tiempo? ¿Un mayor número de usuarios afecta significativamente al rendimiento o a los tiempos de carga?
7. Interoperabilidad
Las pruebas de interoperabilidad son un tipo de pruebas no funcionales que comprueban la compatibilidad de un sistema informático con otros.
Esto es especialmente importante cuando el software se diseña como parte de un conjunto de productos que se integran entre sí.
8. Eficacia
La eficiencia en las pruebas de software se refiere a la medida en que un sistema de software puede manejar la capacidad, la cantidad y el tiempo de respuesta.
Por ejemplo, los encargados de las pruebas pueden evaluar cuántos usuarios pueden iniciar sesión en el sistema a la vez, cuánto se tarda en recuperar datos de la base de datos o con qué rapidez puede el software realizar tareas básicas.
9. Flexibilidad
La flexibilidad mide el grado en que un sistema de software puede funcionar con distintos tipos de hardware y periféricos.
Por ejemplo, cuánta RAM necesita el programa o si requiere una determinada cantidad de CPU. Cuanto menores sean los requisitos de la aplicación informática, más flexible será el software.
10. Portabilidad
Las pruebas de portabilidad se utilizan para comprobar la flexibilidad y facilidad con que se puede transferir el software desde su entorno actual de hardware o software.
La portabilidad es importante porque afecta a la facilidad con que los usuarios finales pueden gestionar el software y trasladarlo entre distintos sistemas.
11. Reutilización
Las pruebas de reutilización son un tipo de pruebas no funcionales que comprueban si partes del sistema de software pueden convertirse para su reutilización dentro de otra aplicación.
Aunque las pruebas de reutilización no suelen afectar a los clientes y usuarios finales, son un buen reflejo de la eficacia con la que los desarrolladores crean componentes que puedan reutilizarse en el futuro.
Características de las pruebas no funcionales
Entender qué son las pruebas no funcionales implica comprender las características de las pruebas no funcionales. Estas características definen las pruebas no funcionales en las pruebas de software.
1. Mensurable
Las pruebas no funcionales son siempre cuantitativas y mensurables, lo que significa que los evaluadores no utilizan frases subjetivas como “agradable” o “bueno”, sino cifras y hechos para describir los resultados de las pruebas no funcionales.
Por ejemplo, en lugar de describir los tiempos de carga como “rápidos” o “lentos”, las pruebas no funcionales deben arrojar cifras concretas que muestren el número de veces.
2. Específico
Al realizar pruebas no funcionales, el objetivo de las pruebas debe ser específico de las especificaciones de diseño del software.
Por ejemplo, si el plan del proyecto de software hace referencia al número de usuarios que deben poder conectarse a la vez, habrá que darle prioridad a la hora de realizar pruebas no funcionales.
3. Desconocido
Aunque las pruebas no funcionales pueden diseñarse específicamente para medir atributos establecidos en los planes del proyecto, en muchos casos estos atributos no se especificarán de antemano.
En este caso, los encargados de las pruebas deben limitarse a realizar pruebas no funcionales para evaluar el software en función de cada parámetro y compararlas posteriormente con las expectativas.
El ciclo de vida de las pruebas no funcionales
Dado que las pruebas no funcionales no se refieren a una fase específica del ciclo de vida de las pruebas de software, sino simplemente a un tipo de prueba que suele tener lugar durante la fase de prueba del sistema de pruebas de software, el ciclo de vida de las pruebas no funcionales puede variar mucho de un proyecto a otro.
En general, sigue un ciclo de vida similar al de otros tipos de pruebas de software que comienza con el análisis de los requisitos del proyecto y termina con la ejecución de las pruebas y el cumplimiento del ciclo.
1. Análisis de requisitos de software
La primera etapa del ciclo de vida de las pruebas no funcionales es el análisis de los requisitos del software. Los equipos de software trabajan con criterios específicos cuando crean y prueban aplicaciones, y estos criterios deben dictar qué tipo de pruebas hay que llevar a cabo.
2. Planificación de pruebas
La siguiente fase del ciclo de vida es la planificación de las pruebas. Durante la fase de planificación de las pruebas, el responsable de la garantía de calidad elabora un plan de pruebas detallado en el que se indica qué se va a probar, quién lo va a hacer y qué enfoques, métodos y herramientas se van a utilizar.
El plan de pruebas debe incluir todos los detalles necesarios para que los evaluadores creen y ejecuten los casos de prueba.
3. Creación de casos de prueba
La creación de casos de prueba es la siguiente etapa de las pruebas no funcionales. Esta etapa consiste en desarrollar casos de prueba no funcionales que los evaluadores ejecutarán en una fase posterior para probar los requisitos no funcionales del sistema.
Los casos de prueba describen qué se va a probar, cómo se va a probar y cuál es el resultado esperado de la prueba.
4. Configuración del entorno de prueba
La siguiente etapa del ciclo de vida de las pruebas no funcionales consiste en configurar el entorno de pruebas antes de iniciarlas.
El entorno de pruebas es donde se llevan a cabo todas las pruebas, y es el hogar de los recursos y herramientas que utilizará para ejecutar las pruebas no funcionales.
El equipo de pruebas prepara el entorno de pruebas antes de su ejecución.
5. 5. Ejecución de la prueba
La ejecución de las pruebas es la siguiente fase del ciclo de vida de las pruebas no funcionales. Consiste en ejecutar los casos de prueba creados previamente para comprobar distintos aspectos de las aplicaciones informáticas, como la seguridad, los tiempos de carga, la capacidad y la portabilidad.
El equipo de pruebas ejecuta cada caso individualmente y comprueba el resultado de cada prueba comparándolo con el resultado esperado.
6. Repetición de ciclo
La etapa final del ciclo de vida de las pruebas no funcionales es el cumplimiento del ciclo y la repetición. Tras ejecutar todos los casos de prueba, los evaluadores comprueban qué pruebas se han superado y cuáles no.
Las pruebas que fallan suelen indicar que existe un defecto que debe ser corregido por los desarrolladores. Una vez que los desarrolladores han parcheado o editado el código, el ciclo de pruebas de software se repite de nuevo hasta que no se encuentra ningún defecto.
Aclarar algunas confusiones:
Pruebas no funcionales frente a pruebas funcionales
Las pruebas funcionales y las pruebas no funcionales son dos tipos de pruebas de software diferentes pero igualmente importantes que, juntas, se utilizan para evaluar si una aplicación de software cumple los requisitos de los usuarios establecidos en las instrucciones del proyecto.
Aunque ambos son tipos de pruebas necesarios que permiten a los equipos de software identificar defectos en las construcciones de software, las pruebas funcionales y no funcionales son completamente distintas entre sí.
1. ¿Cuál es la diferencia entre pruebas funcionales y no funcionales?
La diferencia entre las pruebas funcionales y las no funcionales radica en lo que prueban. Las pruebas funcionales comprueban las funciones de la aplicación y verifican si funcionan como se espera. Las pruebas no funcionales comprueban otros aspectos de la aplicación que afectan a la satisfacción del usuario y a la calidad de la aplicación.
Las pruebas funcionales y no funcionales se realizan en distintas fases de las pruebas de software, pero ambos tipos de pruebas suelen llevarse a cabo durante la fase de pruebas del sistema.
Tanto las pruebas funcionales como las no funcionales pueden ayudarnos a comprender lo bien que funciona una aplicación y si realiza su trabajo adecuadamente.
Por ejemplo, si está probando una aplicación móvil que permite a los usuarios guardar listas de tareas pendientes y listas de la compra, las pruebas funcionales pueden probar funciones como crear una lista nueva, guardar una lista y modificar las listas existentes.
Las pruebas no funcionales pueden evaluar lo bien que funciona la aplicación en distintos dispositivos móviles, lo rápido que se cargan las listas y cuánto se ve afectado el rendimiento de la aplicación cuando otras apps se ejecutan en segundo plano.
2. Conclusión: pruebas no funcionales frente a pruebas funcionales
Tanto las pruebas funcionales como las no funcionales son tipos importantes de pruebas de software que pueden ayudar a los probadores y a los equipos de control de calidad a evaluar si una aplicación cumple sus requisitos actuales.
Mientras que las pruebas funcionales comprueban las funciones del software, las pruebas no funcionales comprueban otros aspectos que pueden afectar al rendimiento, la eficacia y la seguridad.
Las pruebas unitarias, las pruebas de integración y las pruebas de API son formas de pruebas funcionales. En cada una de estas fases de las pruebas de software, los probadores evalúan el funcionamiento de las funciones y características, ya sea individualmente o en conjunto, e identifican los errores y defectos que impiden que las funciones funcionen como se espera.
Las pruebas de seguridad, las pruebas de usabilidad, las pruebas de portabilidad y las pruebas de carga son formas de pruebas no funcionales que permiten a los probadores evaluar hasta qué punto una aplicación cumple sus funciones y satisface las necesidades de los usuarios.
Tipos de pruebas no funcionales
Existen muchos tipos distintos de pruebas no funcionales, cada una de las cuales comprueba un aspecto no funcional diferente del rendimiento o la eficacia de una aplicación informática.
Cada uno de estos tipos de pruebas pondrá a prueba parámetros diferentes, y algunas pruebas pueden poner a prueba los mismos parámetros de diferentes maneras.
1. Pruebas de rendimiento
Las pruebas de rendimiento son un tipo de prueba no funcional que comprueba lo bien que funcionan los distintos componentes del software. En lugar de comprobar su funcionalidad, que es lo que hacen las pruebas funcionales, las pruebas de rendimiento pueden comprobar los tiempos de respuesta, los cuellos de botella y los puntos de fallo. Las pruebas de rendimiento ayudan a los probadores a garantizar que el software es de alta calidad y que es rápido, estable y fiable.
2. Pruebas de estrés
Las pruebas de estrés son un tipo de pruebas no funcionales que comprueban el rendimiento del software cuando se somete a un nivel de estrés anormal. Esto podría significar probar cómo funciona el software cuando alguien intenta utilizar muchas funciones diferentes a la vez, o mientras se ejecutan muchas otras aplicaciones al mismo tiempo.
Las pruebas de estrés buscan identificar el límite en el que el software deja de funcionar correctamente y qué ocurre cuando el sistema está sometido a estrés. Permite a los encargados de las pruebas saber si el sistema puede recuperarse por sí solo y si notifica a los usuarios con mensajes de error adecuados.
3. Pruebas de carga
Las pruebas de carga son un tipo de prueba que evalúa el comportamiento del software tanto en condiciones normales como con cargas más pesadas. Se utiliza para determinar cuánto puede manejar simultáneamente el software sin que el rendimiento se vea afectado negativamente.
Las pruebas de carga pueden utilizarse para comprobar cómo funcionan las aplicaciones cuando muchos usuarios las utilizan a la vez o cuando los usuarios intentan descargar muchos datos al mismo tiempo.
Las pruebas de carga son importantes si desea comprobar si su software es escalable.
4. Pruebas de seguridad
Las pruebas de seguridad evalúan las aplicaciones informáticas y buscan vulnerabilidades en la seguridad del software. Entre ellos se incluyen los posibles riesgos de seguridad que podrían provocar la pérdida de datos o infracciones que expongan datos confidenciales.
Las pruebas de seguridad son importantes porque garantizan que el producto está adecuadamente protegido contra la piratería informática, la violación de datos y otras amenazas externas a la seguridad.
Algunos ejemplos de pruebas de seguridad que pueden realizar los evaluadores son las auditorías de seguridad, el hacking ético, las pruebas de penetración, los escáneres de seguridad y las evaluaciones de postura.
5. Pruebas de actualización e instalación
Las pruebas de actualización e instalación son un tipo de prueba de software no funcional que verifica lo bien que funciona el software en diferentes máquinas.
El objetivo de este tipo de pruebas es garantizar que los nuevos usuarios puedan instalar fácilmente el software en sus máquinas y que los usuarios existentes puedan actualizarlo cuando se publiquen nuevas actualizaciones.
Las pruebas de actualización e instalación son importantes porque los usuarios finales deben poder instalar fácilmente su producto siempre que trabajen con una máquina compatible con él.
6. Pruebas de volumen
Las pruebas de volumen son un tipo de prueba que existe para verificar lo que ocurre cuando se añaden grandes volúmenes de datos a la base de datos a la vez. Esto identifica si la aplicación puede manejar grandes volúmenes de datos y qué le ocurre al sistema si no puede.
Las pruebas de volumen también se conocen como pruebas de inundación, y se pueden utilizar para evaluar la pérdida de datos y los mensajes de error que se producen al añadir cantidades significativas de datos al sistema.
Las pruebas de volumen son la única forma de garantizar que el software pueda manejar los volúmenes de datos que los usuarios esperan de él.
7. Pruebas de recuperación
Las pruebas de recuperación consisten en forzar al sistema informático a fallar para comprobar lo bien que se recupera tras un fallo.
Las pruebas de recuperación pueden ayudar a los probadores a comprender cómo el software recupera los datos y evita pérdidas si el hardware se desenchufa durante su uso, si el software se desconecta de la red durante una transferencia de datos o si se reinicia el sistema de forma inesperada.
Este tipo de pruebas es importante porque los sistemas sin protocolos de recuperación adecuados podrían sufrir graves pérdidas de datos cuando se producen accidentes de este tipo.
Lo que necesita para empezar las pruebas no funcionales
Antes de empezar las pruebas no funcionales, tendrá que asegurarse de que ha preparado el entorno de pruebas y reunido las herramientas y los datos que necesita.
1. Plan de pruebas
Antes de iniciar las pruebas no funcionales, asegúrese de que dispone de un plan de pruebas acabado y firmado por las personas adecuadas.
El plan de pruebas debe incluir todos los detalles pertinentes de lo que se va a probar y cómo. Debe explicar cuándo se van a utilizar pruebas manuales y cuándo automatizadas, así como definir las funciones y responsabilidades de todos los implicados en el proceso.
2. Casos de prueba
Antes de poder ejecutar pruebas no funcionales, tendrá que crear casos de prueba. Cada caso de prueba describe una cosa concreta que se va a probar, explica cómo se va a probar y describe el resultado esperado de la prueba.
Por ejemplo, si está realizando pruebas de carga, un ejemplo de caso de prueba puede ser comprobar cómo se comporta el software cuando diez usuarios utilizan el mismo módulo al mismo tiempo.
3. Verificación funcional
No se pueden realizar pruebas no funcionales de componentes de software si no son funcionales.
Por ejemplo, si quieres probar cuántos usuarios pueden iniciar sesión al mismo tiempo en el software, primero es importante verificar que los usuarios individuales pueden realmente iniciar sesión en el software.
Antes de empezar las pruebas no funcionales, asegúrese de que todas las pruebas funcionales se han superado y de que el software funciona como se espera.
Esto suele significar que ya se han realizado las pruebas de humo, las pruebas de sanidad, las pruebas unitarias, la integración y las pruebas funcionales del sistema.
4. Herramientas de prueba
Antes de iniciar las pruebas no funcionales, reúna todas las herramientas de prueba que desee utilizar para llevarlas a cabo.
Tanto si utiliza herramientas de automatización para automatice algunas de sus pruebas o herramientas de documentación que le ayuden a gestionar y almacenar los informes de las pruebas para su uso posterior, asegúrese de que las herramientas que desea utilizar están disponibles y listas para su uso, y de que todos los miembros del equipo de pruebas saben cómo utilizar correctamente cada herramienta.
5. Entorno de pruebas
Configure el entorno de pruebas antes de iniciar las pruebas no funcionales. Es posible que ya disponga de un entorno de pruebas adecuado, sobre todo si puede utilizar el mismo entorno para las pruebas no funcionales y funcionales del sistema.
El entorno de pruebas ideal le permite probar cada elemento que necesita en los dispositivos correctos.
Por ejemplo, si está probando el manejo del volumen en dispositivos smartphone, es mejor probarlo en un dispositivo smartphone real que intentar emular un entorno móvil en un ordenador de sobremesa.
El proceso de pruebas no funcionales
Probar los aspectos no funcionales de un software es un proceso de varios pasos que implica preparar el entorno de pruebas, crear casos de prueba, recopilar datos de prueba y ejecutar pruebas no funcionales.
Es posible dividir el proceso de prueba en pequeños trozos para que sea más fácil de seguir para los principiantes en pruebas no funcionales.
1. Comprobación de la preparación de las pruebas no funcionales
Antes de empezar las pruebas no funcionales, es importante verificar que está preparado para esta fase de las pruebas.
Esto puede significar evaluar los criterios de salida de la última fase de las pruebas para asegurarse de que el software la ha superado y asegurarse de que el software ha superado todas las pruebas funcionales necesarias antes de que tengan lugar las pruebas no funcionales.
Algunos equipos pueden crear criterios de entrada para las pruebas no funcionales, que comprenden todas las condiciones que deben haberse cumplido antes de que comiencen las pruebas no funcionales.
2. Crear un plan de pruebas
Es posible que ya haya llevado a cabo este paso anteriormente si está realizando pruebas no funcionales como parte de las pruebas del sistema y siguiendo su plan de pruebas del sistema. Un plan de pruebas describe todas las pruebas que debe realizar y cómo pretende llevarlas a cabo.
Sin un plan de pruebas claro, es fácil perder de vista el alcance y los objetivos de las pruebas que se están realizando.
3. Crear casos de prueba
La siguiente fase de las pruebas no funcionales consiste en crear casos de prueba diseñados para comprobar cada parámetro no funcional del software.
Cada caso de prueba debe tener un identificador, un nombre, una descripción y detalles sobre el resultado esperado, así como los criterios de aprobado o suspenso determinados de antemano. Esto ayuda a los probadores a comprender cómo realizar cada prueba y qué resultados buscar.
4. Recopilación de datos de prueba
Antes de que pueda ejecutar cada caso de prueba, tendrá que reunir los datos de prueba que utilizará para cada caso de prueba.
Esto suele implicar recopilar código y datos de los distintos módulos y componentes que conforman las funciones y áreas que vas a probar. Si está maximizando la cobertura de las pruebas, debería tener muchos datos de prueba con los que trabajar.
5. Preparar el entorno de pruebas
La siguiente etapa de las pruebas no funcionales consiste en preparar el entorno de pruebas. El entorno de pruebas es un servidor de pruebas que utilizará para realizar pruebas de software de muchos tipos diferentes.
Le permite crear condiciones idénticas en las que probar su software y establecerlo con distintas configuraciones para pruebas de configuración, pruebas de seguridad y otros tipos de pruebas no funcionales.
6. Ejecutar pruebas no funcionales
Una vez que el entorno de pruebas está listo, es hora de ejecutar las pruebas no funcionales. Puede decidir ejecutar las pruebas por orden de tipo, por ejemplo, empezando por las pruebas de rendimiento antes de pasar a las pruebas de seguridad y otros tipos de pruebas no funcionales.
A medida que realice cada prueba, anote los resultados en su informe de pruebas. Si está automatizando las pruebas, su herramienta de automatización también tendrá una forma estandarizada de informar de los resultados de forma clara y sin ambigüedades.
7. Informar de los resultados de las pruebas
Después de ejecutar cada caso de prueba, recopile los resultados de las pruebas no funcionales en un único informe.
Este informe debe ser claro sobre los resultados de cada prueba e inequívoco sobre si cada prueba ha sido superada o no.
Siga una estructura estandarizada para su informe de examen para asegurarse de que se incluye toda la información que necesitará transmitir.
8. Corregir defectos
Una vez obtenidos los resultados de las pruebas, devuelva el software a los desarrolladores si las pruebas han fallado o si ha detectado algún error no funcional que deba corregirse.
Por ejemplo, si el software no gestiona un número adecuado de usuarios a la vez o si el rendimiento se ralentiza demasiado cuando se ejecutan varios programas al mismo tiempo, es probable que haya que solucionar estos problemas dentro del código para garantizar que los usuarios estén contentos con el producto.
9. Repetir el ciclo de pruebas
Una vez que los desarrolladores han reparado los defectos detectados en la fase inicial de pruebas no funcionales, el ciclo de pruebas puede comenzar de nuevo.
Los desarrolladores realizarán pruebas de cordura de los cambios que introduzcan y devolverán la nueva compilación a los evaluadores de control de calidad, que llevarán a cabo el conjunto completo de pruebas, empezando por las pruebas de humo, las pruebas unitarias, las pruebas de integración y, por último, las pruebas del sistema.
El ciclo de pruebas se repite hasta que no se producen errores o defectos en ningún punto, tras lo cual la compilación puede entrar en la fase final de las pruebas: las pruebas de aceptación del usuario.
Casos de prueba para pruebas no funcionales
Los casos de prueba son un aspecto importante de todas las pruebas de software y, cuando realice pruebas funcionales y no funcionales, utilizará casos de prueba para definir qué va a probar y cómo va a hacerlo.
Cada caso de prueba puede considerarse una miniprueba, y cada caso de prueba tendrá sus propias salidas y resultados definidos.
1. ¿Qué son los casos de prueba para las pruebas no funcionales?
Un caso de prueba es un conjunto de acciones realizadas en una compilación de software para comprobar si satisface las condiciones definidas en el plan de software. Cada caso de prueba indica a los evaluadores qué deben probar y cómo, y está diseñado para probar una función específica o una característica no funcional de la aplicación de software.
Los casos de pruebas no funcionales pueden incluir la comprobación de lo que ocurre cuando alguien intenta acceder a datos seguros dentro del sistema o la rapidez con que se carga el software al arrancar.
2. ¿Cómo diseñar casos de prueba no funcionales?
Al diseñar casos de prueba para pruebas no funcionales, es importante seguir las prácticas estándar de casos de prueba sin perder de vista los objetivos de las pruebas no funcionales.
Siga los pasos que se indican a continuación para escribir casos de prueba para pruebas no funcionales que describan claramente lo que deben hacer sus evaluadores para realizar cada prueba.
1. Defina el área que desea cubrir
Para cada caso de prueba, considere qué área de su software va a cubrir este caso de prueba.
Por ejemplo, si está escribiendo casos de prueba para pruebas de instalación y actualización, puede incluir casos de prueba que evalúen la facilidad de instalación de la aplicación en distintos dispositivos y el tiempo que se tarda en actualizar el software con un nuevo parche.
2. Crear un ID de caso de prueba único
Cada caso de prueba debe tener un ID de caso de prueba único. Esto facilita la búsqueda posterior de la descripción y los resultados del caso de prueba y aclara cualquier confusión sobre a qué caso de prueba se está refiriendo si dos casos de prueba tienen nombres o descripciones similares.
3. Nombre y describa cada prueba
Mientras que el ID del caso de prueba identifica la prueba, también querrá proporcionar un nombre y una descripción para cada caso de prueba que escriba.
Debe ser un nombre sencillo que resuma lo que está probando, mientras que la descripción es una sola frase que lo explica con algo más de detalle.
La descripción debe ser lo suficientemente clara como para que los evaluadores sepan qué probar y cómo hacerlo, así como las condiciones particulares que deben cumplirse en la prueba.
4. Especifique el resultado esperado
Para cada caso de prueba, describa el resultado que debería producirse si el software funciona como se espera.
En las pruebas no funcionales, como las pruebas de rendimiento y de carga, esto puede significar en muchos casos que el software simplemente siga funcionando con normalidad sin ralentizarse, retrasarse o bloquearse.
En otros casos, puede significar que se producen determinados mensajes de error para notificar al usuario el problema y recomendarle una solución.
5. Recomendar técnicas de ensayo
Para cada caso de prueba, recomiende el tipo de técnicas de prueba y herramientas de prueba no funcionales que cree que debe emplear el probador durante las pruebas.
En las pruebas no funcionales, los evaluadores pueden utilizar enfoques muy diferentes para distintos tipos de pruebas.
Por ejemplo, las pruebas de carga y las pruebas de estrés pueden requerir automatización porque no es práctico simular manualmente un tráfico extremadamente intenso, mientras que otros tipos de pruebas pueden ser más fáciles de llevar a cabo sin herramientas o tecnologías específicas.
6. Revisión por pares de cada caso de prueba
Antes de dar el visto bueno a cada caso de prueba, haz que lo revise una persona con la que trabajes. Puede tratarse de otro evaluador o de un jefe de control de calidad.
La revisión por pares de los casos de prueba garantiza que sean lo suficientemente claros como para que los pueda seguir un evaluador externo y que no incluyan ambigüedades o errores que puedan dar lugar a pruebas inadecuadas.
3. Ejemplos de casos de prueba no funcionales
Si está escribiendo casos de prueba para pruebas no funcionales, podrían parecerse a los siguientes ejemplos de pruebas no funcionales.
Ejemplo de prueba de escalabilidad
ID del caso de prueba: 6671
Nombre del caso de prueba: Prueba de inicio de sesión de varios usuarios
Descripción: Emule a más de 20 usuarios iniciando sesión en el software al mismo tiempo utilizando herramientas de automatización.
Resultados esperados: El software debería funcionar con normalidad para cada usuario, permitiéndole iniciar sesión correctamente en menos de 5 segundos.
Ejemplo de prueba de compatibilidad
ID del caso de prueba: 5214
Nombre del caso de prueba: Carga de la aplicación en el navegador Opera
Descripción: Carga la aplicación en el navegador web Opera.
Resultados esperados: La aplicación se carga con normalidad en el navegador web Opera con resolución de pantalla y diseño estándar.
¿Pruebas no funcionales manuales o automatizadas?
A la hora de elegir entre diferentes técnicas de pruebas no funcionales, tendrá que decidir si desea llevar a cabo pruebas no funcionales manuales o automatizadas.
Las pruebas manuales son realizadas por evaluadores humanos, lo que significa que suelen llevar más tiempo, pero también ofrecen oportunidades para realizar pruebas exploratorias.
Las pruebas no funcionales automatizadas son más rápidas y, en cierto modo, más fiables, pero también requieren más recursos o herramientas. La automatización y la hiperautomatización son cada vez más populares en las pruebas, sobre todo cuando se trata de pruebas no funcionales.
Pruebas manuales no funcionales: Ventajas, retos y procesos
Las pruebas no funcionales manuales las realizan únicamente los probadores, que prueban cada elemento no funcional de forma independiente.
Cuando se realizan pruebas manuales no funcionales, los evaluadores deben recopilar información sobre el software, crear casos de prueba individuales que se ajusten al plan de pruebas y ejecutarlos manualmente.
Esto lleva un tiempo considerable, pero también significa que los responsables del control de calidad tienen libertad para determinar qué se prueba y cómo.
1. Algunas de las ventajas de las pruebas manuales son:
● Las pruebas manuales pueden ser más baratas que las automatizadas porque no requieren tecnologías específicas ni conocimientos técnicos.
● Las pruebas manuales permiten a los probadores ofrecer una visión humana y subjetiva sobre cómo funciona el software y si funciona satisfactoriamente.
● Las pruebas manuales pueden utilizarse para realizar pruebas de sistemas en escenarios en los que es imposible automatizar.
● Las pruebas manuales permiten a los probadores evaluar los aspectos visuales del sistema, como la interfaz gráfica y otros factores que podrían afectar a la usabilidad.
● Las pruebas manuales ofrecen a los probadores una perspectiva más amplia del sistema en su conjunto y de cómo funcionan juntos los diferentes módulos y componentes.
Sin embargo, las pruebas manuales también tienen sus inconvenientes.
2. Algunos de los retos de las pruebas manuales son:
● Algunos tipos de pruebas no funcionales, incluidas las pruebas de carga y las pruebas de rendimiento, son poco prácticas de realizar manualmente.
● Las pruebas manuales requieren bastante más tiempo que las pruebas no funcionales automatizadas.
● Los probadores manuales pueden distraerse, perder la concentración y cometer errores, especialmente al realizar tareas de prueba muy repetitivas.
Pruebas no funcionales automatizadas: Ventajas, retos y procesos
Las pruebas no funcionales automatizadas se llevan a cabo mediante scripts automatizados y herramientas de prueba. Cuando se utilizan métodos de pruebas automatizadas, los probadores pueden realizar pruebas en segundo plano mientras se ocupan de otras tareas, una vez iniciadas las pruebas automatizadas.
1. Algunas de las ventajas de automatizar las pruebas no funcionales son:
1. Ahorre tiempo y recursos reduciendo la cantidad de tiempo que dedica a tareas largas y laboriosas.
2. La automatización permite aumentar la cobertura de las pruebas al abarcar una gama más amplia de componentes y funciones
3. Es más factible llevar a cabo pruebas automatizadas con frecuencia porque tardan menos en realizarse
4. Las pruebas automatizadas son ideales para tareas que requieren mucho tiempo, como las pruebas de carga, las pruebas de volumen y las pruebas de estrés, que son muy difíciles de realizar manualmente.
5. Hay menos posibilidades de que surjan errores al realizar pruebas automatizadas
Sin embargo, las pruebas automatizadas también presentan algunos inconvenientes, lo que significa que no siempre son el enfoque adecuado para todos los tipos de pruebas no funcionales.
2. Algunos de los retos de las pruebas no funcionales automatizadas son:
1. Las pruebas automatizadas son más caras que las pruebas manuales.
2. La automatización de las pruebas puede requerir tiempo y recursos técnicos.
3. La automatización de las pruebas no deja espacio para las pruebas exploratorias
4. La automatización de las pruebas sigue requiriendo tiempo para la creación de casos de prueba
Conclusión: Manual o automatizado
¿pruebas no funcionales?
En la mayoría de los tipos de pruebas de software, la combinación de pruebas manuales y automatizadas suele ofrecer los mejores resultados. Esto permite a los equipos de pruebas beneficiarse de la eficacia, fiabilidad y precisión de las pruebas automatizadas, al tiempo que llevan a cabo pruebas exploratorias que permiten a los probadores evaluar el software desde una perspectiva más subjetiva.
En las pruebas no funcionales, tanto las pruebas manuales como las automatizadas son prácticamente necesarias para la mayoría de los equipos de pruebas.
Las pruebas manuales se utilizan mejor para llevar a cabo tareas de pruebas no funcionales, como las pruebas de usabilidad, mientras que las pruebas automatizadas se utilizan más a menudo para realizar pruebas que llevarían demasiado tiempo y serían demasiado difíciles de llevar a cabo manualmente, como las pruebas de estrés o las pruebas de volumen.
Las pruebas no funcionales son una de las áreas más obvias para utilizar técnicas de automatización de pruebas, ya que se trata de un tipo de prueba cuantitativa y medible que no exige resultados subjetivos.
Al igual que otros tipos de pruebas, las pruebas no funcionales suelen realizarse mediante una mezcla de pruebas manuales y automatizadas.
Sin embargo, las pruebas automatizadas son prácticamente necesarias para muchos tipos de pruebas no funcionales, y los parámetros y métricas de las pruebas no funcionales hacen que la automatización sea más adecuada para este tipo de pruebas que para las funcionales.
Prácticas recomendadas para las pruebas no funcionales
Cuando realice pruebas no funcionales por primera vez, seguir las mejores prácticas de pruebas puede ayudarle a estandarizar su proceso de pruebas y optimizar la eficacia de las mismas.
Las mejores prácticas sirven de guía para los equipos de pruebas de software que desean mejorar los procesos de pruebas y ajustarse a las normas del sector.
1. Utilizar herramientas de automatización
En las pruebas no funcionales, más que en otros tipos de pruebas, es importante utilizar herramientas de automatización para automatizar ciertos tipos de pruebas, concretamente las pruebas de volumen, las pruebas de estrés y las pruebas de carga.
Estos tipos de pruebas suelen verificar el funcionamiento del software bajo una fuerte presión de usuarios, datos y tráfico, condiciones que pueden ser muy difíciles de emular manualmente.
La automatización de este tipo de pruebas no funcionales no sólo será más eficaz, sino también más precisa y permitirá a los encargados de las pruebas reproducir cargas y tensiones más elevadas con facilidad.
2. Revisión inter pares de toda la documentación
Además de pedir a los compañeros que revisen los casos de prueba que usted crea, pida a los compañeros de su equipo de pruebas que revisen los informes de errores, los informes de pruebas, los planes de pruebas y otras formas de documentación formal creadas durante el proceso de pruebas.
Así se reduce el riesgo de cometer pequeños errores que podrían causar graves retrasos en el proceso de pruebas y desarrollo.
3. Definir requisitos mensurables
Cuando defina los requisitos de su software antes de empezar las pruebas no funcionales, asegúrese de que cada requisito sea objetivo y medible.
De este modo, los encargados de las pruebas pueden determinar más fácilmente si el software cumple estos requisitos durante las pruebas y no dejan lugar a interpretaciones.
¿Qué se considera “rápido” o “eficaz”? Utilice números y valores cuantitativos para definir lo que busca.
4. Considerar cuidadosamente las métricas de las pruebas
Antes de decidir qué métricas va a utilizar para medir el rendimiento de su software, considere lo que querrán los usuarios del software y qué métricas se ajustan realmente al plan y los requisitos del software.
La mayoría de los programas deben ser rápidos y fiables, pero ¿qué otros parámetros buscan los usuarios? ¿Existe alguna métrica específica del software que deba tener en cuenta durante el proceso de prueba?
Tipos de resultados de una prueba no funcional
Cuando lleve a cabo pruebas no funcionales, recibirá distintos tipos de resultados de las pruebas que realice.
Suelen ser bastante diferentes de los resultados de las pruebas funcionales, que a menudo son más claros, porque las pruebas funcionales se limitan a comprobar si una función funciona como debería o no.
Al igual que en las pruebas funcionales, los responsables de las pruebas deben establecer expectativas claras para cada caso de prueba que faciliten determinar si cada prueba se supera o no.
1. Números absolutos
Al realizar pruebas de rendimiento, pruebas de estrés y otros tipos de pruebas no funcionales, los resultados que más se suelen tener en cuenta son las velocidades y otras cifras absolutas.
Las pruebas de rendimiento verifican la rapidez con la que el sistema puede realizar determinadas tareas, y esto se medirá en segundos o milisegundos.
Si está realizando pruebas de carga, puede evaluar la cantidad de datos que el software puede manejar a la vez sin bloquearse ni sufrir retrasos.
2. Mensajes de error
Las pruebas no funcionales también verifican cómo funciona el sistema cuando se producen errores, como errores de seguridad, errores de validación y errores de configuración.
Es importante que los sistemas muestren mensajes de error precisos y claros cuando se produzcan errores para que los usuarios puedan tomar medidas para corregir el problema y seguir utilizando el software.
Los mensajes de error también deben aparecer durante las pruebas de seguridad cuando el sistema impide que los usuarios vulneren las funciones de seguridad integradas en el software.
3. Choques
El bloqueo es un signo de fallo del sistema, y normalmente indica que el sistema no es capaz de rendir al nivel que se está probando y puede significar que la prueba se ha superado.
En algunos casos, el sistema puede bloquearse y aun así superar la prueba en la que estás trabajando, por ejemplo, si el sistema soporta la cantidad necesaria de estrés o tráfico antes de bloquearse.
Al realizar pruebas no funcionales, los probadores deben esperar que el sistema se bloquee con regularidad, sobre todo cuando lo llevan al límite para pruebas de estrés y otras pruebas de rendimiento.
Ejemplos de pruebas no funcionales
Los ejemplos de pruebas no funcionales son similares a los ejemplos anteriores de casos de prueba no funcionales.
Puede consultar ejemplos de pruebas no funcionales para comprender mejor qué son las pruebas no funcionales y qué comprueban dentro de una aplicación de software.
1. Ejemplo de prueba de rendimiento
Si estás trabajando en una aplicación móvil que conecta a los usuarios con una base de datos en línea, es importante que un gran número de usuarios pueda acceder a los datos de esta base y descargarlos al mismo tiempo.
También es una parte fundamental de las pruebas de escalabilidad, sobre todo si se quiere aumentar el número de usuarios de la aplicación en el futuro.
A continuación, probará cómo reacciona el sistema cuando, por ejemplo, 1.000 usuarios intentan acceder a la misma base de datos al mismo tiempo y establecerá los requisitos de rapidez de carga de la aplicación en estas condiciones.
2. Pruebas de compatibilidad
Si estás probando una nueva aplicación de gestión documental, tendrás que comprobar que funciona en todos los dispositivos para los que está pensada.
Esto significa probar que puede instalar y cargar la aplicación en todas las versiones más recientes de Windows, Mac y cualquier otro sistema operativo (como Linux) con el que desee que el software sea compatible.
3. Pruebas de seguridad
Al realizar pruebas de seguridad, comprobarás algunas de las formas en que las personas pueden intentar acceder a datos confidenciales o vulnerar las salvaguardas de seguridad del software para verificar que el sistema se comporta como esperas que lo haga en estas situaciones.
Por ejemplo, podrías iniciar sesión como usuario e intentar acceder a archivos para los que no tienes autorización de seguridad para asegurarte de que el sistema no te permite acceder a esos archivos.
Tipos de errores y fallos detectados
mediante pruebas no funcionales
Las pruebas no funcionales pueden revelar muchos errores y defectos que no son tan fáciles de encontrar como los identificados en las pruebas funcionales. Esto se debe a que las pruebas no funcionales a menudo requieren que los probadores verifiquen diferentes configuraciones, configuraciones y combinaciones de condiciones para evaluar el rendimiento del sistema en una miríada de entornos diferentes.
1. Defectos de funcionamiento
Los defectos de rendimiento surgen cuando el sistema funciona, pero no lo hace con la rapidez o eficacia esperadas.
Por ejemplo, puede ocurrir que el sistema no se cargue con la suficiente rapidez en determinadas condiciones o incluso que se bloquee si demasiados usuarios se conectan al mismo tiempo.
Los defectos de rendimiento no impiden por completo que la gente utilice el software, pero pueden hacer que sea menos utilizable y que tenga menos probabilidades de cumplir los requisitos de los usuarios.
2. Defectos de seguridad
Los defectos de seguridad son aquellos que afectan a la seguridad del sistema informático y de los datos almacenados en él.
Pueden surgir defectos de seguridad si, por ejemplo, los usuarios pueden acceder a datos confidenciales a los que no deberían tener acceso o si determinadas partes de la aplicación no están correctamente protegidas por contraseña, o si falla el cifrado.
Esto podría dar lugar a fallos de seguridad, que pueden afectar gravemente a la reputación de un editor de software.
3. Defectos funcionales
Aunque las pruebas no funcionales no están diseñadas para comprobar las funciones de una aplicación de software, en algunos casos pueden identificar defectos funcionales en el software.
Por ejemplo, el objetivo de las pruebas de fiabilidad no es comprobar si la aplicación funciona, sino si funciona de forma fiable en repetidos intentos.
Esto puede revelar que algunas características no funcionan correctamente de forma fiable cuando se repite una acción, y éstas pueden clasificarse como errores funcionales.
Métricas comunes de las pruebas no funcionales
Las métricas de las pruebas no funcionales describen las métricas con las que se miden el rendimiento y la eficacia del sistema.
Los distintos tipos de pruebas no funcionales se basan en métricas diferentes, y puede optar por utilizar una variedad de métricas en función de los objetivos finales del proyecto.
1. Tiempo
Las métricas de tiempo miden cuánto se tarda en realizar determinadas tareas o cuánto tienen que esperar los usuarios para que se carguen las funciones.
Algunos ejemplos de métricas de tiempo son el número de transacciones o descargas que una aplicación puede realizar en un plazo determinado, los tiempos de respuesta de distintas funciones y el tiempo que tarda la aplicación en completar una operación concreta.
Diferentes tipos de pruebas medirán los resultados en segundos o como una presentación de cuántas operaciones por segundo.
2. Espacio
El espacio es otra métrica importante en las pruebas no funcionales. Las métricas de espacio pueden comprobar cuánto espacio de CPU necesita el sistema o cuánto espacio del disco duro ocupa el software una vez instalado por completo.
Algunos ejemplos de métricas de espacio incluyen la memoria caché, la memoria principal y la memoria auxiliar.
El software que requiere una gran cantidad de espacio para funcionar sin problemas puede ser adecuado para un número menor de clientes.
3. Usabilidad
Algunas métricas de las pruebas no funcionales tienen en cuenta la usabilidad del sistema, por ejemplo, cuánto tiempo se tarda en formar a los usuarios para que utilicen el sistema correctamente, cuántas opciones tienen que recorrer los usuarios para realizar funciones clave o cuántos clics de ratón se necesitan para llevar a cabo determinadas tareas.
Las pruebas no funcionales pueden medir cuantitativamente cada una de estas métricas, y las cifras más bajas suelen implicar niveles más altos de usabilidad.
4. Fiabilidad
Otra métrica importante en las pruebas no funcionales es la fiabilidad. La fiabilidad refleja la probabilidad de que el sistema se comporte de la misma manera una y otra vez o funcione como debería durante un largo periodo de tiempo.
Algunos ejemplos de métricas que se utilizan para medir la fiabilidad son el tiempo medio hasta el fallo, la tasa de fallos, la disponibilidad y la probabilidad de tiempo de inactividad.
Cada una de estas métricas ayuda a los encargados de las pruebas a verificar que el sistema puede funcionar durante mucho tiempo sin experimentar fallos ni caídas.
5. Robustez
La robustez es la medida de lo bien que el sistema gestiona los fallos y lo bien que puede recuperarse en caso de fallo.
Algunos ejemplos de métricas que miden la robustez son el tiempo que tarda el sistema en recuperarse tras un fallo, el porcentaje de incidentes que conducen a un fallo catastrófico y la probabilidad de que los archivos de datos se corrompan tras el fallo del sistema.
Son parámetros importantes porque los usuarios esperan que los sistemas fallen a veces sin perder todos los datos ni corromper los archivos.
6. Portabilidad
Las métricas de portabilidad miden la facilidad con la que el software puede transferirse a diferentes sistemas o trasladarse a una nueva ubicación dentro de una red.
Algunos ejemplos de métricas que miden la portabilidad son el porcentaje de código no portable y el número de sistemas en los que puede ejecutarse el software.
Idealmente, el software que puede ejecutarse en muchos sistemas diferentes es más portátil y, por tanto, más conveniente para su uso en entornos que puedan requerir traslados o reubicaciones frecuentes.
Estrategias para realizar pruebas no funcionales
Cuando comience las pruebas no funcionales, es importante que aborde esta fase de las pruebas con una estrategia en mente. Antes de iniciar las pruebas no funcionales, los jefes de control de calidad y los responsables de las pruebas de software deben tener en cuenta los riesgos de las pruebas, los recursos de que disponen y el objetivo de las mismas.
Desarrollar una estrategia puede ayudarle a optimizar sus pruebas no funcionales desde el principio.
1. Asignar funciones y responsabilidades
Antes de iniciar las pruebas no funcionales, asigne funciones y responsabilidades a los miembros clave del equipo de pruebas. Esto facilita la gestión de la carga de trabajo de las pruebas no funcionales y garantiza que los probadores experimentados se encarguen de mantener la calidad y la eficacia de las pruebas realizadas.
Asegúrese de que las personas que elige para desempeñar estas funciones tienen los conocimientos y la experiencia necesarios para llevar a cabo las tareas que usted espera de ellas, sobre todo si esas tareas requieren conocimientos técnicos.
2. Reunir las herramientas de prueba pertinentes
Reúna todas las tecnologías y herramientas que desee utilizar para realizar pruebas no funcionales. Asegúrese de que todos los miembros de su equipo sepan utilizarlos con eficacia, y organice cursos de formación para cubrir las lagunas de conocimientos cuando sea necesario.
Asegurarse de que todo el mundo sabe qué herramientas de prueba utilizar y cómo utilizarlas antes de iniciar las pruebas no funcionales reduce el riesgo de tener que interrumpir las pruebas o rehacerlas por falta de conocimientos.
3. Priorizar las pruebas
Antes de empezar las pruebas no funcionales, haz una lista de todos los aspectos del sistema que tienes que probar y priorízalos en función de su urgencia e importancia.
Puede priorizar las pruebas no funcionales en función del nivel de riesgo de cada aspecto del sistema que esté probando.
Por ejemplo, pueden realizarse pruebas básicas de seguridad porque se considera que una seguridad adecuada es extremadamente importante en el software moderno. Cuanto antes se identifiquen los defectos de alto riesgo, menor será el impacto potencial de esos defectos en otros aspectos del sistema.
7 mejores herramientas de pruebas no funcionales
Las herramientas de pruebas no funcionales pueden agilizar el proceso de pruebas, facilitar y hacer más rentable la automatización de las pruebas y ayudar a los responsables de control de calidad a gestionar el proceso de pruebas y documentación.
Hay muchas herramientas de pruebas no funcionales gratuitas disponibles en línea, así como algunas herramientas por las que se puede pagar una cuota mensual para actualizarlas.
1. Edición GRATUITA de ZAPTEST
ZAPTEST es una popular herramienta de pruebas de software que permite a los usuarios llevar a cabo pruebas de software funcionales y no funcionales de forma rápida y sencilla. Puede utilizar ZAPTEST para automatizar las pruebas de software y utilizar la tecnología RPA para emular diversas funciones y condiciones en las pruebas no funcionales.
La edición FREE de ZAPTEST no es más que una versión reducida de la edición empresarial, que ofrece muchas de las mismas funcionalidades a menor escala. Puedes buscar ayuda en el foro de ZAPTEST y realizar pruebas de rendimiento con un número ilimitado de usuarios virtuales.
2. Appium
Appium es una herramienta gratuita de pruebas de software muy adecuada para probar aplicaciones móviles en distintas plataformas, incluidos dispositivos iOS y Android. Appium ofrece a los usuarios una gran flexibilidad para diseñar sus propios marcos y estrategias de pruebas, al tiempo que se benefician de las capacidades de automatización que ofrece Appium.
3. Loadium
Loadium es una herramienta de pruebas no funcionales que se utiliza mejor para llevar a cabo pruebas de rendimiento y pruebas de carga, dos tipos de pruebas no funcionales que son mucho más fáciles de llevar a cabo utilizando herramientas de automatización.
Loadium permite a los usuarios ejecutar pruebas de carga a gran escala y ofrece soluciones personalizadas para que pueda adaptar sus pruebas a los objetivos de su software.
Puedes probar Loadium gratis o pagar para descargar la versión completa de la aplicación.
4. Obkio
Obkio es una herramienta de pruebas de software que ayuda a los jefes de control de calidad y a los gestores de pruebas a priorizar y clasificar los problemas en función de su gravedad. Obkio puede detectar problemas antes que los usuarios, les ofrece notificaciones inteligentes y puede ayudar a detectar dónde está el problema.
Obkio no es sólo para pruebas no funcionales, sino que es una herramienta de pruebas gratuita de gran utilidad que puede emplearse en todas las fases del ciclo de vida de las pruebas.
5. SonarQube
SonarQube es una herramienta de pruebas de seguridad de código abierto que puede analizar automáticamente el código para detectar fallos y vulnerabilidades. Escrito en Java, puede utilizar SonarQube para analizar código en más de veinte lenguajes de programación diferentes y la interfaz limpia del sistema facilita la detección de problemas que podrían causar vulnerabilidades de seguridad en el futuro.
6. Tsung
Tsung es otra herramienta de pruebas no funcionales ideal si quieres automatizar pruebas de carga y estrés pero no te llevas bien con la versión gratuita de Loadium.
Tsung es una herramienta de código abierto que permite a los usuarios realizar pruebas de carga de gran volumen en múltiples protocolos y servidores, incluidos HTTP y SOAP.
Tsung es completamente gratuito y puede ayudar a los probadores a garantizar que el software en el que están trabajando ofrece altos niveles de rendimiento en diversas condiciones difíciles.
7. Sikuli
Sikuli es otra aplicación que utiliza la automatización robótica de procesos para automatizar el proceso de pruebas. La aplicación puede automatizar cualquier cosa que se vea en la pantalla. Puedes utilizar Sikuli para probar aplicaciones no basadas en web y reproducir errores rápidamente.
Lista de comprobación, consejos y trucos para las pruebas no funcionales
Antes de iniciar las pruebas no funcionales, compruebe que dispone de todo lo necesario para llevarlas a cabo en un entorno preparado.
Siga la siguiente lista de comprobación para obtener consejos y trucos antes de empezar las pruebas no funcionales.
1. Trabajar según un calendario
Tanto si lo incluye en su plan de pruebas como si crea un documento aparte para ello, estructure sus pruebas de software en torno a un calendario de pruebas.
Si encuentra más errores y defectos de los que espera, es posible que a veces se desvíe del calendario, pero tener un calendario para empezar puede ayudar a guiar a los probadores y motivarlos para que trabajen con eficacia, sobre todo cuando se realizan pruebas manuales que llevan mucho tiempo.
2. Identifique a su equipo de pruebas
Delegar responsabilidades y asignar a los miembros de su equipo de pruebas funciones y títulos oficiales puede ayudar a garantizar que el proceso de pruebas se desarrolle sin problemas.
Comunique claramente las funciones y responsabilidades de su equipo antes de iniciar las pruebas y asigne a distintos evaluadores la responsabilidad de diferentes aspectos de las pruebas no funcionales, de modo que cada uno sea responsable de sus propias tareas.
3. Seleccionar herramientas y tecnologías antes de realizar las pruebas
Si sólo se decide trabajar con determinadas herramientas y tecnologías una vez iniciadas las pruebas no funcionales, se puede retrasar el proceso y crear confusión entre los evaluadores.
En su lugar, investigue con antelación y decida si desea utilizar alguna herramienta antes de empezar las pruebas. Esto facilita la incorporación de estas herramientas al plan de pruebas y la formación de los evaluadores para que las utilicen antes de que empiecen las pruebas.
4. Obtener siempre la aprobación formal de las pruebas y la documentación
Las pruebas son un proceso de garantía de calidad, y la mejor manera de maximizar el valor de las pruebas que se llevan a cabo es realizar también un control de calidad básico de las pruebas que se planifican y ejecutan.
Introduzca protocolos sencillos que obliguen a los encargados de las pruebas a pedir a los jefes y directores de control de calidad que revisen y aprueben los planes e informes de pruebas antes de pasar a la siguiente fase.
Esto aumenta enormemente las posibilidades de detectar y corregir a tiempo los errores en las pruebas.
7 errores y trampas que hay que evitar al aplicar pruebas no funcionales
Si eres nuevo en las pruebas no funcionales, puede ser fácil cometer algunos errores comunes en los que suelen caer los probadores y los profesionales de control de calidad.
Las pruebas no funcionales son un trabajo complejo que implica considerar la construcción de un software desde todos los ángulos y perspectivas.
A continuación se enumeran algunos de los errores más comunes que cometen los evaluadores al realizar pruebas no funcionales.
1. No planificar
Si es la primera vez que realiza pruebas no funcionales, es posible que piense que puede lanzarse directamente a la fase de pruebas sin crear un plan de pruebas exhaustivo de antemano.
Algunos equipos de pruebas pueden elaborar documentos de pruebas incompletos o resúmenes superficiales del plan de pruebas que no describen adecuadamente las acciones que deben realizar los evaluadores durante las pruebas no funcionales.
2. Mala gestión de las pruebas
Pueden surgir problemas si las pruebas se gestionan mal en cualquier fase del proceso. Una gestión inadecuada puede significar que los probadores no dispongan de los recursos adecuados para llevar a cabo las pruebas a fondo o que no dispongan de tiempo suficiente para probar cada aspecto de la compilación.
Los responsables de las pruebas deben ser capaces de aprender de los errores que cometen y desarrollar planes de pruebas más eficaces en el futuro.
3. 3. Mala comunicación
Una comunicación deficiente puede causar muchos problemas durante el proceso de pruebas, concretamente en las pruebas no funcionales.
Esto podría significar una mala comunicación dentro del equipo de pruebas o una mala comunicación entre los probadores, los desarrolladores y las partes interesadas.
Esto suele ocurrir cuando los probadores no mantienen adecuadamente los documentos de prueba o no se comunican regularmente con otros departamentos durante el proceso de prueba.
4. Ignorar a los desarrolladores
Los probadores y los desarrolladores suelen trabajar bastante separados, pero los equipos de pruebas que colaboran estrechamente con los desarrolladores pueden beneficiarse de conocimientos adicionales sobre el funcionamiento del software y la interacción entre los distintos módulos.
Involucrar a los desarrolladores en el proceso de pruebas, o pedirles su opinión en momentos clave, puede ayudar a los equipos de pruebas a elaborar planes más eficaces y completos.
5. Objetivo de las pruebas
Muchos probadores siguen creyendo que el propósito de las pruebas es comprobar que el software funciona o demostrar a las partes interesadas y a los inversores que el software funciona.
En su lugar, los probadores deben abordar las pruebas con la actitud de que el propósito de las pruebas es buscar defectos.
Los probadores que no encuentran defectos sólo pueden estar satisfechos de que el software que están probando está libre de fallos si están satisfechos de haber buscado en todas partes donde podrían encontrarse defectos.
6. Errores manuales frente a errores de automatización
Es importante dedicar tiempo a considerar si las pruebas manuales o las automatizadas son mejores para cada tipo de prueba que realice.
Los métodos de pruebas automatizadas se adaptan muy bien a casi todas las formas de pruebas no funcionales, y los equipos de pruebas acostumbrados a las pruebas funcionales pueden cometer el error de suponer que pueden probar las características no funcionales manualmente con la misma facilidad.
7. Utilización de herramientas de comprobación inadecuadas
Es fácil elegir las herramientas y tecnologías de pruebas equivocadas antes de empezar las pruebas no funcionales, sobre todo si los equipos de pruebas están acostumbrados a realizar pruebas manuales y no están habituados a utilizar herramientas de pruebas.
Investigue de antemano los métodos de pruebas no funcionales que desea utilizar y elija herramientas de software y de automatización que cumplan los requisitos específicos de su proyecto.
Conclusión
Las pruebas no funcionales son un paso esencial en el proceso de pruebas que permite a los probadores verificar el rendimiento de un sistema y hasta qué punto cumple requisitos no funcionales como tiempos de carga, capacidad y salvaguarda de la seguridad.
Hay muchas formas diferentes de realizar pruebas no funcionales, pero las herramientas de automatización actuales facilitan la maximización de la cobertura y la precisión de las pruebas sin comprometer la calidad de los resultados.
Preguntas frecuentes y recursos
Si quiere saber más sobre las pruebas no funcionales, hay muchas preguntas frecuentes y recursos disponibles en Internet.
Navegue por nuestros recursos favoritos de pruebas no funcionales en línea a continuación o lea las respuestas a algunas de las preguntas más frecuentes sobre las pruebas no funcionales.
1. Los mejores cursos sobre pruebas no funcionales
Hay muchos cursos en línea que pueden ayudarle a ampliar sus conocimientos sobre métodos y enfoques de pruebas no funcionales.
Algunos de estos cursos son gratuitos, y otros pueden ofrecer un certificado o cualificación a cambio de una cuota. Si desea realizar un curso acreditado, puede preguntar a su empresa si le patrocina y cubre el coste de la matrícula.
Algunos de los mejores cursos sobre pruebas no funcionales son:
- GET: Curso de formación no funcional de 2 días de duración
- Udemy: El completo 2023 Software Testing Bootcamp
- Edx: Certificado Profesional en Pruebas de Software
- Educativo: Automatización de pruebas de rendimiento 101
2. ¿Cuáles son las 5 preguntas más frecuentes en una entrevista sobre pruebas no funcionales?
Si está preparando una entrevista de trabajo para trabajar en pruebas de software, es posible que su entrevistador le haga preguntas sobre las pruebas no funcionales para asegurarse de que entiende cómo funciona esta fase esencial de las pruebas de software. Prepárese para la entrevista preparando de antemano respuestas eficaces a las preguntas más habituales.
● ¿En qué pueden diferir los enfoques y métodos que utilizas en las pruebas no funcionales de los enfoques que utilizas en las pruebas funcionales?
● ¿En qué se diferencian las pruebas no funcionales de las funcionales?
● ¿Qué diferentes tipos de pruebas no funcionales existen?
● ¿Cómo se priorizan las pruebas funcionales y los casos de prueba?
● ¿En qué fase de las pruebas de software se suelen realizar las pruebas funcionales?
3. Los mejores tutoriales de YouTube sobre pruebas no funcionales
Si prefiere aprender viendo vídeos, puede que los tutoriales de YouTube sobre pruebas no funcionales le resulten útiles para aprender más sobre este tipo de pruebas de software.
A continuación encontrará algunos de los mejores tutoriales de YouTube sobre pruebas de software disponibles en la actualidad.
¿Qué son las pruebas de software no funcionales? Tutorial de pruebas de software
Ayuda para pruebas de software: Pruebas no funcionales
Pruebas no funcionales en las pruebas de software
Visita W3Schools
Pruebas funcionales y no funcionales
4. Cómo mantener las pruebas no funcionales
Un mantenimiento adecuado de las pruebas garantiza que éstas puedan repetirse sin comprometer la calidad de los resultados.
Al mantener las pruebas no funcionales, puede asegurarse de que las pruebas en cada fase del proceso de desarrollo son adecuadas y de que sus pruebas se actualizan siempre en función de los cambios constantes del código.
Puede mantener las pruebas no funcionales siguiendo nuestros consejos a continuación.
● Comunicarse con claridad en todo el equipo de pruebas al crear casos de prueba y redactar documentación.
● Siga siempre las mejores prácticas de diseño de pruebas
● Reevaluar los protocolos de ensayo en las distintas fases del proceso de ensayo.
● Actualiza los cambios en tu prueba sobre la marcha
Tener en cuenta los proyectos futuros al modificar las pruebas actuales
5. ¿Las pruebas no funcionales son de caja negra o de caja blanca?
Las pruebas no funcionales son un tipo de pruebas de caja negra, lo que significa que los probadores no se ocupan del funcionamiento interno del sistema, sino sólo de sus resultados externos.
Esto contrasta con las pruebas de caja blanca, que comprueban el funcionamiento interno del sistema. Ejemplos de pruebas de caja blanca son las pruebas unitarias y las pruebas de integración.
Las pruebas de requisitos funcionales y no funcionales son ejemplos de pruebas de caja negra. Esto significa que los probadores no necesitan conocimientos técnicos avanzados ni de programación informática para llevar a cabo pruebas de caja negra, ni tampoco aprender a implementar los sistemas que están probando.
