En resumen: A menudo se confunden las pruebas funcionales, las pruebas de validación y las pruebas de no regresión. La prueba funcional comprueba que una funcionalidad responda a una necesidad; la prueba de validación confirma que el producto satisfaga al usuario final; la prueba de no regresión garantiza que una modificación no haya provocado ningún fallo. Esta guía aclara sus funciones, sus diferencias y cómo combinarlas para lograr una estrategia de pruebas completa.
Dada la variedad de términos que describen las metodologías de pruebas —que pretenden ser claros, pero que a menudo no lo consiguen—, el vocabulario relacionado con las pruebas puede resultar a veces confuso.
En este artículo, vamos a aclarar las diferencias entre las pruebas funcionales de validación y las pruebas de no regresión (TNR), pero primero debemos señalar que el término «pruebas de regresión» puede utilizarse indistintamente.
En otras palabras: prueba de regresión = prueba de no regresión
El ISTQB prefiere el término «prueba de regresión», pero muchas personas del sector también utilizan el término «prueba de no regresión» (al menos en Francia).
Sin embargo, antes de abordar las diferencias entre las pruebas funcionales de validación y las pruebas de no regresión, veamos primero en qué consisten.
¿Qué son las pruebas funcionales de validación?
Las pruebas funcionales de validación son un tipo de prueba que se realiza para comprobar que cada función o característica de la aplicación de software funciona de acuerdo con las especificaciones de los requisitos.
Al probador no le concierne el código subyacente. Las pruebas funcionales de validación se centran en la fluidez mecánica oen la verificación del correcto funcionamiento de cada módulo.
Se lleva a cabo mediante casos de prueba que recrean todos los escenarios posibles, tanto negativos como positivos. Lo ideal es que las pruebas funcionales de validación comiencen en la fase inicial del desarrollo delproducto y comprueben:
- Las funciones que faltan
- Especificaciones incorrectas
- Si persisten los errores de interfaz
- Las deficiencias que se producen durante la fase de definición de requisitos
Unas pruebas funcionales de validación bien realizadas permiten ofrecer un producto de alta calidad. Contribuyen a crear un producto o un software sin errores para garantizar la satisfacción del usuario final.
Ejemplos de pruebas funcionales de validación:
- Comprueba que el botón «Volver» de la página te lleve a la página correcta
- Comprueba que los enlaces redirijan a las páginas correctas.
- Los menús desplegables deben mostrar los valores correctos al hacer clic en ellos
- Comprueba que el botón «Siguiente» te lleve a la página siguiente
- Comprobar que un usuario pueda introducir caracteres en los campos de texto tal y como se define en la hoja de elementos de datos.
*A diferencia de las pruebas de regresión, los términos«pruebas funcionales de validación» y «pruebas no funcionales» no son sinónimos. Las pruebas no funcionales consisten en evaluar la aplicación desde aspectos no funcionales, como el rendimiento, la facilidad de uso, la seguridad, la fiabilidad, la carga, el estrés, etc. Se llevan a cabo basándose en escenarios reales para comprobar el rendimiento del sistema cuando se somete a dichas circunstancias.
¿Qué es una prueba de regresión/no regresión (TNR)?
Regresión: una evolución que nos lleva a una etapa anterior.
Las pruebas de regresión se llevan a cabo con el objetivo de detectar cualquier regresión en una funcionalidad ya probada.
Estos retrocesos en el código pueden producirse como consecuencia de «correcciones de errores», de «nuevas funcionalidades añadidas al código» o de «cambios en los requisitos».
El objetivo es probar todo el código que pudiera verse afectado por los cambios recientes para asegurarnos de que no se haya introducido ningún error nuevo.
En resumen, una prueba de regresión sirve para comprobar que los cambios introducidos en el software, el sitio web o la aplicación móvil —como la incorporación de una nueva funcionalidad o una actualización— no han afectado a las funcionalidades anteriores ya existentes.
Las diferencias entre estos dos tipos de pruebas
Objetivos
El objetivo de las pruebas funcionales de validación es determinar en qué medida la aplicación desarrollada se ajusta a los requisitos establecidos.
El objetivo de las pruebas de regresión es comprobar que ningún cambio en la aplicación o en los sistemas haya provocado errores en el código y que el sistema funcione correctamente.
Caso de prueba ejecutado
Las pruebas funcionales de validación permiten comprender el conjunto de casos y funcionalidades que nunca antes se habían probado ni ejecutado. Los casos de prueba se vuelven a ejecutar cuando se detecta un fallo en relación con un requisito. A continuación, se corrige y se asigna para una nueva prueba. En la nueva prueba, si el fallo se ha resuelto, los casos de prueba relacionados que antes habían fallado pasan la prueba.
El conjunto de pruebas de regresión contiene casos que ya se han probado y resuelto anteriormente. Básicamente , en las pruebas de regresión, se ejecutan los casos de prueba para garantizar que los cambios no hayan afectado a las funcionalidades probadas anteriormente.
Se requieren pruebas funcionales de validación:
- Cuando se prueba un nuevo sistema.
- Cuando se comprueba que una aplicación cumple con sus especificaciones y los requisitos deseados.
- Para comprobar que la integración del sistema y del módulo funciona correctamente.
- Cuando es necesario analizar el funcionamiento de un sistema en su conjunto.
- Para determinar el flujo de trabajo de un sistema y sus funciones.
- Para asegurarse de que el flujo produzca el resultado esperado.
Las pruebas de regresión se realizan cuando:
- El cliente presenta una solicitud de modificación, lo que da lugar a un cambio en el código base.
- El código del back-end se ha migrado a otra plataforma.
- Se añade una nueva función a la aplicación existente.
- Se han añadido algunas correcciones.
- Se ha producido un cambio en el entorno de pruebas.
- Los errores críticos detectados por el probador durante la fase de pruebas son corregidos por el desarrollador.
- Los desarrolladores han resuelto los principales problemas relacionados con el rendimiento y los fallos del sistema.
- Se ha modificado la interfaz de usuario de la aplicación para mejorar la experiencia del usuario.
Proceso utilizado
El proceso de pruebas funcionales comienza con la lectura y la comprensión de los requisitos por parte de los probadores, lo que da lugar a una discrepancia en caso de divergencia en el requisito, a lo que sigue la identificación de la entrada de prueba. A continuación, se introducen los valores de entrada en los sistemas y se compara la salida con los resultados esperados.
Si el resultado no coincide, se señala el error y el caso de prueba se marca como fallido.
El proceso completo de pruebas funcionales incluye:
- La identificación de las funcionalidades que se van a probar
- El aumento de la demanda de datos
- La ejecución de casos de prueba
- La comparación de un resultado con el resultado esperado.
- El fallo del caso de prueba que no se ajustaba al requisito.
- La creación de escenarios de prueba en función de los requisitos
- La conversión de escenarios de prueba en casos de prueba
- Señalar los errores y asignárselos al desarrollador, en caso de que se detecten anomalías en la aplicación.
- Reejecución en caso de fallo, una vez corregido el error detectado
Por el contrario, el proceso de pruebas de regresión es totalmente diferente, ya que esta actividad solo se lleva a cabo cuando se modifica la aplicación existente o se le añaden nuevas funcionalidades.
Las actividades que conlleva este tipo de prueba son las siguientes:
- Identificación de las piezas modificadas
- Priorización de los casos de prueba en función del riesgo que entrañan.
- Selección de casos de prueba en función de los ámbitos afectados por la modificación.
Viabilidad de la automatización
Las pruebas funcionales de validación se realizan primero de forma manual. Una vez que una funcionalidad es estable, los casos de prueba se se automatizan.
En las pruebas de regresión, los casos de prueba pueden ejecutarse de forma manual o automática. Dado que los casos de prueba ya son estables por defecto (ya que han superado la prueba funcional) en las pruebas de regresión, pueden automatizarse.
Los casos de prueba funcionales no requieren muchos cambios, ya que son menos numerosos y se centran en una funcionalidad específica.
En cambio, en las pruebas de regresión, los scripts de prueba requieren un mayor mantenimiento y pueden contener casos de prueba más antiguos.
Los casos de prueba pueden incluir funcionalidades que hayan cambiado, nuevas funcionalidades que se hayan añadido o algunas que se hayan eliminado; por eso, la suite de regresión debe actualizarse tras cada versión.
Mr Suricate Automatiza tus pruebas con una solución sin código
En Mr Suricate, protegemos la imagen de marca del cliente y aumentamos su volumen de negocio, al tiempo que garantizamos el buen funcionamiento de la experiencia del usuario y detectamos los errores antes y después de la puesta en producción.
Preguntas frecuentes
¿En qué se diferencian las pruebas funcionales de las pruebas de no regresión?
La prueba funcional comprueba que una funcionalidad haga lo que debe hacer; la prueba de no regresión comprueba que, tras una modificación, las funcionalidades existentes sigan funcionando. Una valida lo nuevo, la otra protege lo existente.
¿Qué es una prueba de validación?
Es la prueba que confirma que el producto satisface las necesidades y expectativas del usuario final, a menudo al final del ciclo, antes de su puesta en producción. Valida «el producto adecuado», mientras que la prueba funcional valida «el producto bien hecho».
¿Son complementarias estas pruebas?
Sí. Una estrategia sólida combina pruebas funcionales (la funcionalidad funciona), pruebas de validación (cumple con los requisitos) y pruebas de no regresión (no se ha estropeado nada). Las tres abarcan riesgos diferentes.