Guía completa de pruebas funcionales con sus tipos y ejemplo

complete functional testing guide with its types

Un tutorial completo de pruebas funcionales en profundidad con tipos, técnicas y ejemplos:

¿Qué son las pruebas funcionales?

La prueba funcional es un tipo de prueba de caja negra que se realiza para confirmar que la funcionalidad de una aplicación o sistema se está comportando como se esperaba.

Se hace para verificar toda la funcionalidad de una aplicación.

LISTA de los tutoriales cubiertos en esta serie:

Tutorial #1: ¿Qué son las pruebas funcionales? (este tutorial)
Tutorial #2: Preguntas de la entrevista de prueba de funcionalidad
Tutorial #3: Principales herramientas de prueba de automatización funcional
Tutorial #4: ¿Qué son las pruebas no funcionales?
Tutorial #5: Diferencia entre unidad, funcional y Integración Pruebas
Tutorial #6 : Por qué las pruebas funcionales y de rendimiento deben realizarse simultáneamente

Instrumentos:

Tutorial #7: Automatización de pruebas funcionales con Ranorex Studio
Tutorial #8: Nuevas funciones de la herramienta funcional UFT
Tutorial #9: Automatización funcional entre navegadores con Parrot QA Tool
Tutorial #10: Tutorial de la herramienta de código abierto Jubula para pruebas de funcionalidad

Lo que vas a aprender:

• Introducción a las pruebas funcionales
  • Tipos de pruebas funcionales
  • Proceso
  • Criterios de entrada / salida
    • Criterio para entrar:
    • Criterio de salida:
  • Pasos involucrados
  • Acercarse
  • Técnicas de prueba funcional
    • # 1) Pruebas del sistema / basadas en el usuario final
    • # 2) Pruebas de equivalencia
    • # 3) Pruebas de valor límite
    • # 4) Pruebas basadas en decisiones
    • # 5) Pruebas de flujo alternativas
    • # 6) Pruebas ad-hoc
  • Automatización de pruebas funcionales
  • Ventajas
  • Limitaciones
  • Conclusión
  • Lectura recomendada

Introducción a las pruebas funcionales

Debe haber algo que defina qué es un comportamiento aceptable y qué no lo es.

Esto se especifica en una especificación funcional o de requisitos. Es un documento que describe lo que un usuario puede hacer, para que pueda determinar la conformidad de la aplicación o el sistema con él. Además, a veces esto también podría implicar la validación de los escenarios reales del lado comercial.

Por lo tanto, las pruebas de funcionalidad se pueden realizar mediante dos técnicas populares :

• Pruebas basadas en requisitos: Contiene todas las especificaciones funcionales que forman la base de todas las pruebas a realizar.
• Pruebas basadas en escenarios empresariales: Contiene la información sobre cómo se percibirá el sistema desde una perspectiva de proceso empresarial.

Las pruebas y la garantía de calidad son una gran parte del proceso SDLC. Como tester, debemos estar al tanto de todos los tipos de pruebas, incluso si no estamos directamente involucrados con ellos a diario.

Como las pruebas son un océano, su alcance es realmente enorme y contamos con evaluadores dedicados que realizan diferentes tipos de pruebas . Lo más probable es que todos debamos estar familiarizados con la mayoría de los conceptos, pero no estaría de más organizarlo todo aquí.

Tipos de pruebas funcionales

Las pruebas funcionales tienen muchas categorías y estas se pueden usar según el escenario.

Los tipos más destacados se analizan brevemente a continuación:

Examen de la unidad :

Las pruebas unitarias generalmente las realiza un desarrollador que escribe diferentes unidades de código que podrían estar relacionadas o no para lograr una funcionalidad en particular. El suyo, esto generalmente implica escribir pruebas unitarias que llamarían a los métodos en cada unidad y los validarían cuando se pasen los parámetros requeridos, y su valor de retorno es el esperado.

La cobertura de código es una parte importante de las pruebas unitarias donde los casos de prueba deben existir para cubrir los tres siguientes:

i) Cobertura de línea
ii) Cobertura de ruta de código
iii) Cobertura del método

Pruebas de cordura : Pruebas que se realizan para garantizar que todas las funcionalidades principales y vitales de la aplicación / sistema estén funcionando correctamente. Esto generalmente se hace después de una prueba de humo.

Prueba de humo : Pruebas que se realizan después del lanzamiento de cada compilación para probar y garantizar la estabilidad de la compilación. También se denomina prueba de verificación de compilación.

Pruebas de regresión : Pruebas realizadas para asegurar que la adición de código nuevo, mejoras, corrección de errores no rompa la funcionalidad existente o cause inestabilidad y aún funcione de acuerdo con las especificaciones.

Las pruebas de regresión no necesitan ser tan extensas como las pruebas funcionales reales, pero deben garantizar solo la cantidad de cobertura para certificar que la funcionalidad es estable.

Pruebas de integración : Cuando el sistema se basa en múltiples módulos funcionales que podrían funcionar perfectamente individualmente, pero tienen que funcionar de manera coherente cuando se combinan para lograr un escenario de extremo a extremo, la validación de dichos escenarios se denomina prueba de integración.

Pruebas beta / usabilidad : El producto se expone al cliente real en una producción como un entorno y ellos prueban el producto. La comodidad del usuario se deriva de esto y se toman los comentarios. Esto es similar a la prueba de aceptación del usuario.

Representemos esto en un diagrama de flujo sencillo:

Prueba de sistema funcional:

Prueba del sistema es una prueba que se realiza en un sistema completo para verificar si funciona como se esperaba una vez que todos los módulos o componentes están integrados.

Prueba de extremo a extremo se realiza para verificar la funcionalidad del producto. Esta prueba se realiza solo cuando la prueba de integración del sistema está completa, incluidos los requisitos funcionales y no funcionales.

=> Diferencia entre pruebas unitarias, funcionales y de integración

Proceso

Este proceso de prueba tiene tres pasos principales:

Enfoque, técnicas y ejemplos

Las pruebas funcionales o de comportamiento generan una salida basada en las entradas dadas y determinan si el sistema está funcionando correctamente según las especificaciones.

Por lo tanto, la representación pictórica se verá como se muestra a continuación:

Criterios de entrada / salida

Criterio para entrar:

• Se define y aprueba el documento de especificación de requisitos.
• Se han preparado casos de prueba.
• Se han creado los datos de prueba.
• El entorno para las pruebas está listo, todas las herramientas necesarias están disponibles y listas.
• La aplicación completa o parcial se desarrolla y se prueba unitariamente y está lista para probar.

Criterio de salida:

• Se ha completado la ejecución de todos los casos de prueba funcional.
• No hay errores críticos o P1, P2 abiertos.
• Se han reconocido los errores notificados.

Pasos involucrados

Los diversos pasos involucrados en esta prueba se mencionan a continuación:

• El primer paso involucrado es determinar la funcionalidad del producto que debe probarse e incluye probar las principales funcionalidades, condiciones de error y mensajes, pruebas de usabilidad, es decir, si el producto es fácil de usar o no, etc.
• El siguiente paso es crear los datos de entrada para que se pruebe la funcionalidad según la especificación de requisitos.
• Posteriormente, a partir de la especificación de requisitos, se determina la salida para la funcionalidad bajo prueba.
• Se ejecutan los casos de prueba preparados.
• La salida real, es decir, la salida después de ejecutar el caso de prueba y la salida esperada (determinada a partir de la especificación de requisitos) se comparan para encontrar si la funcionalidad está funcionando como se esperaba o no.

Acercarse

Se pueden pensar y crear diferentes tipos de escenarios en forma de 'casos de prueba'. Como gente de QA, todos sabemos cómo se ve el esqueleto de un caso de prueba.

En su mayoría tiene cuatro partes:

• Resumen de la prueba
• Prerrequisitos
• Pasos de prueba y
• Resultados previstos.

Intentar crear cualquier tipo de prueba no solo es imposible, sino que también requiere mucho tiempo y es costoso.

Normalmente, querríamos descubrir el máximo de errores sin escapes con las pruebas existentes. Por lo tanto, el QA debe utilizar técnicas de optimización y diseñar estrategias sobre cómo abordarían las pruebas.

Expliquemos esto con un ejemplo.

Ejemplos de casos de uso de pruebas funcionales:

Tome un portal de HRMS en línea donde el empleado inicia sesión con su cuenta de usuario y contraseña. En la página de inicio de sesión, hay dos campos de texto para el nombre de usuario y la contraseña, y dos botones: Iniciar sesión y Cancelar. El inicio de sesión exitoso lleva al usuario a la página de inicio de HRMS y cancelar cancelará el inicio de sesión.

Las especificaciones son las que se muestran a continuación:

#1 ) El campo de identificación de usuario tiene un mínimo de 6 caracteres, un máximo de 10 caracteres, números (0-9), letras (a-z, A-z), caracteres especiales (solo se permiten guiones bajos, puntos y guiones) y no se puede dejar en blanco. La identificación de usuario debe comenzar con un carácter o un número y no con caracteres especiales.

#2) El campo de contraseña tiene un mínimo de 6 caracteres, un máximo de 8 caracteres, números (0-9), letras (a-z, A-Z), caracteres especiales (todos) y no puede estar en blanco.

El enfoque básico para probar este escenario se puede clasificar en dos categorías amplias:

1. Prueba positiva y
2. Prueba negativa

Por supuesto, cada una de estas categorías tiene su subsección de pruebas que se llevarán a cabo.

Pruebas positivas son pruebas de ruta felices que se realizan para garantizar que el producto cumple, al menos, los requisitos básicos que son vitales para el uso del cliente.

Escenarios negativos asegúrese de que el producto se comporte correctamente incluso cuando esté sujeto a datos inesperados.

Lectura sugerida => ¿Qué son las pruebas negativas y cómo escribir casos de prueba negativos?

Ahora, permítanme intentar estructurar las técnicas de prueba usando un diagrama de flujo a continuación. Entraremos en los detalles de cada una de esas pruebas.

Técnicas de prueba funcional

# 1) Pruebas del sistema / basadas en el usuario final

El sistema bajo prueba puede tener muchos componentes que cuando se acoplan logran el escenario del usuario.

En el Ejemplo , un escenario de cliente incluiría tareas como cargar la aplicación HRMS, ingresar las credenciales correctas, ir a la página de inicio, realizar algunas acciones y cerrar sesión en el sistema. Este flujo particular tiene que funcionar sin errores para un escenario empresarial básico.

alternativa gratuita de Quickbooks para pequeñas empresas

Algunas muestras se dan a continuación:

Este es un ejemplo básico de cómo se crean casos de prueba para situaciones. El formato anterior también se aplicará a todas las pruebas siguientes. En aras de una sólida base conceptual, he realizado solo algunas pruebas simples arriba y abajo.

# 2) Pruebas de equivalencia

En Partición de equivalencia , los datos de prueba se segregan en varias particiones llamadas clases de datos de equivalencia. Los datos en cada partición deben comportarse de la misma manera, por lo tanto, solo se debe probar una condición. De manera similar, si una condición en una partición no funciona, ninguna de las otras funcionará.

Por ejemplo , en el escenario anterior, el campo de identificación de usuario puede tener un máximo de 10 caracteres, por lo que ingresar datos> 10 debe comportarse de la misma manera.

# 3) Pruebas de valor límite

Las pruebas de límites implican límites de datos para la aplicación y validan cómo se comporta.

Por lo tanto, si las entradas se suministran más allá de los valores límite, se considera una prueba negativa. Entonces, un mínimo de 6 caracteres para el usuario establece el límite. Pruebas escritas para tener identificación de usuario<6 characters are boundary analysis tests.

# 4) Pruebas basadas en decisiones

Las pruebas basadas en decisiones se centran en la ideología de los posibles resultados del sistema cuando se cumple una condición particular.

En el escenario anterior dado, las siguientes pruebas basadas en decisiones se pueden derivar inmediatamente:

1. Si se ingresan las credenciales incorrectas, debe indicárselo al usuario y volver a cargar la página de inicio de sesión.
2. Si el usuario ingresa las credenciales correctas, debería llevarlo a la siguiente interfaz de usuario.
3. Si el usuario ingresa las credenciales correctas pero desea cancelar el inicio de sesión, entonces no debe llevar al usuario a la siguiente interfaz de usuario y volver a cargar la página de inicio de sesión.

# 5) Pruebas de flujo alternativas

Se ejecutan pruebas de ruta alternativa para validar todas las formas posibles que existen, además del flujo principal, para realizar una función.

# 6) Pruebas ad-hoc

Cuando la mayoría de los errores se descubren mediante las técnicas anteriores, pruebas ad-hoc son una excelente manera de descubrir cualquier discrepancia que no se haya observado anteriormente. Estos se realizan con la mentalidad de romper el sistema y ver si responde con gracia.

Por ejemplo , un caso de prueba de muestra sería:

• Un usuario ha iniciado sesión, pero el administrador elimina la cuenta de usuario mientras realiza algunas operaciones. Sería interesante ver cómo la aplicación maneja esto con elegancia.

Pruebas funcionales y no funcionales:

Pruebas no funcionales centrarse en la calidad de la aplicación / sistema en su conjunto. Por lo tanto, trata de deducir qué tan bien funciona el sistema según los requisitos del cliente, en contraste con la función que realiza.

=> Lea la diferencia exacta aquí

Automatización de pruebas funcionales

¿Podemos automatizar las pruebas funcionales?

Con Automatización se puede reducir el esfuerzo manual, se puede ahorrar tiempo, se puede evitar el deslizamiento de errores y se puede aumentar la eficiencia.

Sin embargo, no es posible automatizar todos y cada uno. Esta prueba se puede automatizar, pero el usuario debe trabajar en casos de prueba para que se realice la automatización. Es importante encontrar los casos de prueba adecuados para automatizarlos junto con una herramienta adecuada.

La automatización de casos funcionales puede tener inconvenientes, como si el número de casos de prueba es mucho mayor y se retrocede una y otra vez (lo que debe hacerse), entonces el desarrollador podría tener problemas para realizar cambios en el código.

Muchas veces, al realizar un análisis de escape de defectos, la causa prominente y perenne de los escapes parece tener una falta de cobertura de prueba en una función en particular.

Nuevamente, hay varias causas para que esto suceda, como la falta de entornos, la falta de probadores, la entrega de demasiadas funciones, menos tiempo para cubrir todos los aspectos de prueba y, a veces, simplemente pasarlo por alto.

Si bien los equipos de prueba dedicados pueden realizar pruebas detalladas en cada sprint o cada ciclo de prueba, siempre existirán defectos y siempre habrá defectos que podrían pasarse por alto. Esta es una de las necesidades fundamentales para tener la automatización de pruebas en su lugar, con lo que se obtiene una mejora notable en la eficiencia del proceso de prueba general y la cobertura de casos de prueba.

Aunque las pruebas automatizadas nunca pueden reemplazar las pruebas manuales, tener una combinación ideal de las dos resultará vital para tener la calidad deseada en los proyectos de software.

Consideraciones de automatización:

#1) Seleccione la herramienta de automatización correcta : Hay varias herramientas disponibles en el mercado, ¡elegir una herramienta de automatización es una tarea realmente abrumadora! Sin embargo, puede hacer una lista de requisitos, en función de la cual puede seleccionar qué herramienta de automatización utilizar.

Algunos aspectos primarios en los que pensar incluyen:

• Seleccione una herramienta que sea fácil de usar para todos los miembros del equipo de control de calidad, si aún no tienen las habilidades necesarias.
• La herramienta se puede utilizar en diferentes entornos. Para Ejemplo : ¿Se pueden crear los scripts en una plataforma de sistema operativo y ejecutar en otra? ¿Necesita automatización de CLI, automatización de UI, automatización de aplicaciones móviles o todo?
• La herramienta debe tener todas las características que necesita. Para Ejemplo : Si algunos evaluadores no están bien versados ​​en un lenguaje de secuencias de comandos, la herramienta debe tener una función de grabación y reproducción y luego admitir la conversión del guión grabado al lenguaje de secuencias de comandos deseado. Del mismo modo, si también necesita la herramienta para admitir pruebas de compilación automatizadas, informes específicos y registro, también debe poder hacerlo.
• La herramienta debe poder admitir la reutilización de casos de prueba en caso de cambios en la interfaz de usuario.

Herramientas de automatización : Hay bastantes herramientas disponibles para la automatización funcional. El selenio es probablemente uno de los favoritos, pero existen otras herramientas de código abierto, como Sahi, Watir, Robotium, AutoIt, etc.

Varias herramientas de automatización de pruebas están disponibles en el mercado. Pero elegir la herramienta adecuada es muy importante para la organización. Puede depender de los requisitos, la facilidad de uso y el costo juega un papel importante aquí.

A continuación se muestran algunas de las principales herramientas de prueba funcional:

• Selenio
• QTP
• Junit
• Loadrunner
• JABÓN
• TestComplete

=> Consulte esta lista completa de las principales herramientas de automatización funcional

#2) Elija los casos de prueba adecuados para automatizar : Si desea obtener lo mejor de la automatización, es vital ser inteligente sobre el tipo de pruebas que elige para automatizar. Si hay pruebas que requieren que se activen y desactiven algunas configuraciones durante la ejecución de la prueba, es mejor no automatizarlas.

Por lo tanto, puede automatizar las pruebas que:

• Necesita ejecutarse repetidamente.
• Ejecute con diferentes tipos de datos.
• Algunos casos de prueba P1, P2 requieren mucho esfuerzo y tiempo.
• Pruebas propensas a errores.
• Conjunto de pruebas que deben ejecutarse en diferentes entornos, navegadores, etc.

# 3) Equipo de automatización dedicado : Esto probablemente se pasa por alto en la mayoría de las organizaciones y la automatización se impone a todos los miembros del equipo de control de calidad.

Cada miembro del equipo tiene diversos niveles de experiencia, conjuntos de habilidades, niveles de interés, ancho de banda para soportar la automatización, etc. Algunas personas posiblemente estén mejor capacitadas para ejecutar pruebas manuales, mientras que otras pueden conocer las herramientas de automatización y secuencias de comandos.

En situaciones como esta, es una buena práctica realizar un análisis de todos los miembros del equipo y tener algunos miembros dedicados a hacer solo la automatización.

La actividad de automatización requiere tiempo, esfuerzo, conocimiento y un equipo dedicado que ayudará a lograr los resultados requeridos en lugar de sobrecargar a todos los miembros del equipo con pruebas manuales y de automatización.

#4) Pruebas basadas en datos: Los casos de prueba automatizados que requieren múltiples conjuntos de datos deben estar bien escritos para que puedan ser reutilizados. Los datos se pueden escribir en fuentes como archivos de texto o propiedades, archivos XML o leer desde una base de datos.

Cualquiera que sea la fuente de datos, la creación de datos de automatización bien estructurados facilita el mantenimiento del marco y hace que los scripts de prueba existentes se utilicen en todo su potencial.

# 5) Los cambios en la interfaz de usuario no deben romper las pruebas: Los casos de prueba que cree con la herramienta seleccionada deben poder hacer frente a los posibles cambios en la interfaz de usuario. Por ejemplo, las versiones anteriores de selenio usaban una ubicación para identificar los elementos de la página.

Por lo tanto, si la interfaz de usuario cambia, esos elementos ya no se encuentran en esas ubicaciones y, a su vez, conducirán al fracaso masivo de las pruebas.

Por lo tanto, es importante comprender las deficiencias de la herramienta de antemano y crear los casos de prueba de manera que solo se requieran cambios mínimos en caso de cambios en la interfaz de usuario.

# 6) Pruebas frecuentes: Una vez que tenga listo un depósito de prueba de automatización básica, planifique una ejecución más frecuente de este depósito. Esto tiene una ventaja bidireccional: una es que puede mejorar el marco de automatización y hacerlo más robusto y la segunda es que detectará más errores en el proceso.

Ventajas

A continuación se enumeran las diversas ventajas de las pruebas funcionales:

• Esta prueba reproduce o es una réplica de lo que es el sistema real, es decir, es una réplica de lo que es el producto en el entorno en vivo. Las pruebas se centran en las especificaciones según el uso del cliente, es decir, especificaciones del sistema, sistema operativo, navegadores, etc.
• No funciona con ningún si y peros o suposiciones sobre la estructura del sistema.
• Esta prueba asegura la entrega de un producto de alta calidad que cumple con los requisitos del cliente y asegura que el cliente esté satisfecho con los resultados finales.
• Se asegura de entregar un producto libre de errores que tiene todas las funcionalidades funcionando según los requisitos del cliente.
• Las pruebas basadas en el riesgo se realizan para disminuir las posibilidades de cualquier tipo de riesgo en el producto.

Limitaciones

Esta prueba se realiza para asegurarse de que el producto funciona como se esperaba y que se implementan todos los requisitos y que el producto cumple exactamente con los requisitos del cliente.

Sin embargo, no considera los otros factores, como el rendimiento del producto, es decir, la capacidad de respuesta, el tiempo de producción, etc., que son importantes y muy necesarios para ser parte de las pruebas antes de lanzar el producto.

Desventajas

• Hay muchas posibilidades de realizar pruebas redundantes.
• Los errores lógicos pueden perderse en el producto.
• Esta prueba se basa en el requisito, si en caso de que el requisito no esté completo o sea complicado o no esté claro, realizar esta prueba en tal escenario se vuelve difícil y también puede llevar mucho tiempo.

Por lo tanto, básicamente, ambos tipos de pruebas son necesarios para un producto de calidad.

Conclusión

Este tutorial ha analizado exhaustivamente todo lo que necesita saber sobre las pruebas funcionales, desde lo básico.

La prueba funcional es uno de los procesos de prueba importantes, ya que verifica la funcionalidad de un producto, que es el aspecto más requerido y, de hecho, el aspecto más importante de cualquier producto o aplicación.

Sobre el Autor: Sanjay Zalavadia - como vicepresidente de servicio al cliente de Céfiro , aporta más de 15 años de experiencia en liderazgo en TI y servicios de soporte técnico.

Espero que algunas de las técnicas que hemos sugerido sean útiles para todos los lectores. Háganos saber sus pensamientos en los comentarios a continuación.

Lectura sugerida => Tutorial de pruebas de funciones

Lectura recomendada

• Pruebas funcionales versus pruebas no funcionales
• Pruebas alfa y beta (una guía completa)
• Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
• Las diferencias entre pruebas unitarias, pruebas de integración y pruebas funcionales
• Tipos de pruebas de software: diferentes tipos de pruebas con detalles
• Spock para pruebas funcionales y de integración con selenio
• Guía completa de pruebas de verificación de compilación (pruebas de BVT)
• Una guía completa de pruebas no funcionales para principiantes