¿Qué son las pruebas funcionales?

En esta sección, te unes al equipo de Tailspin mientras definen las pruebas funcionales para su proceso. Las pruebas funcionales comprueban que cada función del software hace lo que debe hacer.

Primero de todo, el equipo define qué cubre una prueba funcional. Para ello, explora algunos tipos de pruebas funcionales. Después, decide la primera prueba que se va a agregar a su canalización.

Reunión semanal

El equipo celebra su reunión semanal. Andy muestra la canalización de versión. El equipo analiza cómo avanza correctamente una compilación a lo largo de la canalización, de una fase a otra. Por último, la aplicación web se promueve a la fase de ensayo.

Amita: Estoy muy contenta con la canalización. Me facilita mucho las cosas. Por un lado, las versiones se implementan automáticamente en el entorno de prueba. Esto significa que no tengo que descargar e instalar manualmente los artefactos de compilación en mis servidores de prueba, lo que supone un ahorro de tiempo considerable.

Además, las pruebas unitarias que Mara y Andy han escrito eliminan todos los errores de regresión antes de que la versión llegue a mis manos. Esto quita una fuente principal de frustración. No pierdo tiempo buscando y documentando los errores de regresión.

Pero me preocupa que todas mis pruebas siguen siendo manuales. El proceso es lento y no podemos mostrar nada al departamento de administración hasta que termino mi trabajo. Es difícil porque las pruebas son importantes. Las pruebas garantizan que los usuarios obtengan la experiencia adecuada. Pero cada vez hay más presión para entregar más rápido.

Andy: Estoy seguro de que podemos ayudarte. ¿Qué tipo de pruebas te llevan más tiempo?

Amita: Creo que las pruebas de la interfaz de usuario lo hacen. Tengo que hacer clic en cada paso para asegurarme de que obtengo el resultado correcto y tengo que hacerlo para todos los navegadores compatibles. Requiere mucho tiempo. Además, a medida que aumente la complejidad del sitio web, las pruebas de IU dejarán de ser prácticas a largo plazo.

Mara: Las pruebas de interfaz de usuario se consideran pruebas funcionales.

Tim: ¿En contraposición a pruebas no funcionales?

Mara: Exacto. Y las pruebas no funcionales le interesan a usted especialmente.

Tim: Estoy perdido.

¿Qué son las pruebas funcionales y no funcionales?

Mara: Las pruebas funcionales comprueban que cada función del software hace lo que debería. La forma en que el software implementa cada una de estas funciones no es importante en estas pruebas. Lo importante es que el software se comporte correctamente. Se proporciona una entrada y se comprueba que la salida es la esperada. Así es cómo Amita prueba la interfaz de usuario. Por ejemplo, si selecciona al jugador que ocupa la primera posición en la tabla de clasificación, espera ver el perfil de ese jugador.

Las pruebas no funcionales comprueban características como el rendimiento y la confiabilidad. Un ejemplo de prueba no funcional es comprobar el número de personas que pueden iniciar sesión en la aplicación simultáneamente. La prueba de carga es otro ejemplo de una prueba no funcional. Estos aspectos de rendimiento y confiabilidad son en los que te centras tú, Tim.

Tim: Sí, así es. Necesito pensar en esto. Quizás me interese agregar también una automatización a la canalización, pero no estoy seguro de lo que quiero hacer. ¿Qué tipos de pruebas automatizadas se pueden ejecutar?

Mara: Por ahora, vamos a centrarnos en las pruebas funcionales, Es el tipo de pruebas que Amita hace y suena como un área donde queremos mejorar.

¿Qué tipos de pruebas funcionales se pueden ejecutar?

Hay muchos tipos de pruebas funcionales. Varían según la funcionalidad que se necesita probar y el tiempo o el esfuerzo que requieren normalmente para ejecutarse.

En las secciones siguientes se presentan algunas pruebas funcionales que se usan con más frecuencia.

Pruebas de humo

Las pruebas de humo comprueban la funcionalidad más básica de la aplicación o del servicio. Estas pruebas suelen ejecutarse antes que otras más completas y exhaustivas. Las pruebas de humo deben ejecutarse rápidamente.

Por ejemplo, imagine que está desarrollando un sitio web. La prueba de humo podría usar curl para comprobar que el sitio es accesible y que al capturar la página principal se genera un estado HTTP 200 (correcto). Si la captura de la página principal genera otro código de estado, como 404 (no encontrado) o 500 (error interno del servidor), sabe que el sitio web no funciona. También sabe que no hay ninguna razón para ejecutar otras pruebas. En su lugar, debe diagnosticar el error, corregirlo y reiniciar las pruebas.

Pruebas unitarias

En pocas palabras, las pruebas unitarias comprueban los componentes más importantes del programa o la biblioteca, como un método o una función individual. Se especifican una o varias entradas, junto con los resultados esperados. El ejecutor de las pruebas lleva a cabo cada una de ellas y verifica si los resultados reales coinciden con los esperados.

Por ejemplo, supongamos que tiene una función que realiza una operación aritmética que incluye una división. Puede especificar algunos valores que espera que introduzcan los usuarios. También puede especificar valores de caso extremo, como 0 y -1. Si espera que una entrada determinada genere un error o una excepción, puede comprobar que la función produce dicho error.

Las pruebas de la IU que ejecutará más adelante en este módulo son pruebas unitarias.

Pruebas de integración

Las pruebas de integración comprueban que varios componentes de software funcionan conjuntamente para formar un sistema completo. Por ejemplo, un sistema de comercio electrónico podría incluir un sitio web, una base de datos de productos y un sistema de pago. Puede escribir una prueba de integración que agregue elementos al carrito de la compra y, después, los compre. Esta prueba verifica que la aplicación web puede conectarse a la base de datos de productos y completar el pedido.

Puede combinar pruebas unitarias y pruebas de integración para crear una estrategia de pruebas por capas. Por ejemplo, puede ejecutar pruebas unitarias en cada uno de los componentes antes de ejecutar las pruebas de integración. Si se superan todas las pruebas unitarias, puede pasar a las pruebas de integración con mayor confianza.

Pruebas de regresión

Una regresión se produce cuando el comportamiento existente cambia o se interrumpe después de agregar o cambiar una característica. Las pruebas de regresión ayudan a determinar si el código, la configuración u otros cambios afectan al comportamiento general del software.

Las pruebas de regresión son importantes porque un cambio en un componente puede afectar al comportamiento de otro componente. Por ejemplo, imagine que optimiza el rendimiento de escritura para una base de datos. El rendimiento de lectura de esa base de datos, que lo controla otro componente, podría reducirse inesperadamente. Esta reducción del rendimiento de lectura es una regresión.

Puede usar varias estrategias para probar la regresión. Normalmente, estas estrategias varían según el número de pruebas que se ejecutan para comprobar que una nueva característica o corrección de errores no afecta a la funcionalidad existente. Pero al automatizar las pruebas, es posible que las pruebas de regresión en concreto impliquen la ejecución de todas las pruebas unitarias y de integración cada vez que cambia el software.

Pruebas de integridad

Las pruebas de integridad implican la prueba de cada componente principal de un producto de software para asegurarse de que este funciona y puede someterse a pruebas más exhaustivas. Puede considerar que las pruebas de comprobación son menos exhaustivas que las pruebas unitarias o las pruebas de regresión, pero las pruebas de comprobación son más amplias que las pruebas de humo.

Aunque las pruebas de integridad se pueden automatizar, a menudo se realizan de forma manual en respuesta a un cambio en las características o a una corrección de errores. Por ejemplo, un evaluador de software que está validando la corrección de un error también podría comprobar que otras características funcionan introduciendo algunos valores típicos. Si el software parece funcionar según lo previsto, puede pasar a una fase de prueba más exhaustiva.

Pruebas de interfaz de usuario

Las pruebas de interfaz de usuario (IU) comprueban el comportamiento de la interfaz de usuario de una aplicación. Las pruebas de UI ayudan a comprobar que la secuencia o el orden de las interacciones del usuario conducen al resultado esperado. Estas pruebas también ayudan a comprobar que los dispositivos de entrada, como el teclado o el mouse, afectan a la interfaz de usuario correctamente. Puede ejecutar pruebas de IU para comprobar el comportamiento de una aplicación nativa de Windows, macOS o Linux. O bien, puede usar pruebas de IU para comprobar que la interfaz de usuario se comporta según lo esperado en los exploradores web.

Una prueba unitaria o una prueba de integración podría comprobar que la interfaz de usuario recibe los datos correctamente. Mientras que las pruebas de IU ayudan a comprobar que la interfaz de usuario se muestra correctamente y que el resultado funciona del modo previsto para el usuario.

Por ejemplo, una prueba de IU podría comprobar si se muestra la animación correcta al hacer clic en un botón. Una segunda prueba podría comprobar si se muestra correctamente la misma animación cuando se cambia el tamaño de la ventana.

En este módulo, trabajaréis con pruebas de IU cuyo código se escribe a mano. Aunque también puede usar un sistema de captura y reproducción para construir automáticamente las pruebas de interfaz de usuario.

Pruebas de facilidad de uso

Las pruebas de facilidad de uso son un tipo de prueba manual que comprueba el comportamiento de una aplicación desde la perspectiva del usuario. El equipo que compila el software normalmente realiza las pruebas de facilidad de uso.

Las pruebas de IU se centran en si una característica se comporta según lo esperado, en cambio, las pruebas de facilidad de uso ayudan a comprobar que el software es intuitivo y satisface las necesidades del usuario. En otras palabras, las pruebas de facilidad de uso permiten comprobar si el software "se puede usar".

Por ejemplo, imaginemos que tiene un sitio web que incluye un vínculo al perfil del usuario. Una prueba de IU puede comprobar que el vínculo está presente y que abre el perfil del usuario cuando se selecciona el vínculo. Pero si los usuarios no pueden encontrar este vínculo fácilmente, podrían frustrarse al intentar acceder a su perfil.

Pruebas de aceptación de usuario

Las pruebas de aceptación del usuario (UAT), igual que las pruebas de facilidad de uso, se centran en el comportamiento de una aplicación desde la perspectiva del usuario. A diferencia de las pruebas de usabilidad, las UAT suelen realizarlas usuarios finales reales.

Dependiendo del software, es posible que se pida a los usuarios finales que lleven a cabo tareas específicas. También es posible que se les permita explorar el software sin seguir ninguna instrucción específica. En el caso del software personalizado, las pruebas de aceptación de usuario (UAT) las suele realizar directamente el cliente. Por otro lado, cuando se trata de software de uso general, los equipos pueden ejecutar pruebas beta. En las pruebas beta, usuarios de distintas regiones geográficas o con determinados intereses obtienen acceso anticipado al software.

Los comentarios de los evaluadores pueden ser directos o indirectos. Los comentarios directos pueden presentarse como observaciones verbales. mientras que los comentarios indirectos pueden ser mediciones del lenguaje corporal de los evaluadores, de sus movimientos oculares o del tiempo que tardan en completar tareas específicas.

Ya hemos tratado la importancia de escribir pruebas. pero para hacer hincapié en ello, a continuación se muestra un breve vídeo en el que Abel Wang, asesor de cuestiones relacionadas con la nube de Microsoft, explica cómo garantizar la calidad en un plan de DevOps.

Pregunta a Abel

¿Qué elige el equipo?

Tim: Parece que todas estas pruebas son importantes. ¿Cuál deberíamos abordar primero?

Andy: Ya tenemos pruebas unitarias en funcionamiento. Pero todavía no estamos preparados para realizar pruebas de aceptación de usuario. Según lo que he oído, creo que deberíamos centrarnos en las pruebas de la interfaz de usuario. Ahora mismo es la parte más lenta del proceso. Amita, ¿estás de acuerdo?

Amita: Sí, coincido contigo. Todavía nos queda tiempo de reunión. Andy o Mara, ¿querríais ayudarme a planear una prueba de IU automatizada?

Mara: Por supuesto. Pasemos por alto algunas cuestiones preliminares. Me gustaría analizar qué herramienta deberíamos usar y cómo ejecutaremos las pruebas.

¿Qué herramientas se pueden usar para escribir pruebas de IU?

Mara: A la hora de escribir pruebas de interfaz de usuario, ¿qué opciones tenemos? Sé que hay muchas. Por ejemplo, algunas herramientas son de código abierto y otras ofrecen soporte comercial de pago. Estas son algunas de las opciones que me vienen a la mente:

• Controlador de aplicaciones de Windows (WinAppDriver): WinAppDriver le ayuda a automatizar las pruebas de interfaz de usuario en aplicaciones de Windows. Estas aplicaciones se pueden escribir en la Plataforma universal de Windows (UWP) o en Windows Forms (WinForms). En nuestro caso, necesitamos una solución que funcione en un explorador.
• Selenium: se trata de un marco portable de pruebas de software de código abierto para aplicaciones web. Se ejecuta en la mayoría de los sistemas operativos y es compatible con todos los exploradores modernos. Puede escribir pruebas de Selenium en diferentes lenguajes de programación, incluido C#. De hecho, puede usar paquetes de NuGet que facilitan la ejecución de Selenium como pruebas de NUnit. Nosotros ya usamos NUnit para nuestras pruebas unitarias.
• SpecFlow: para proyectos de .NET. Se basa en una herramienta denominada Cucumber. Tanto SpecFlow como Cucumber admiten el desarrollo basado en el comportamiento (BDD). El BDD usa un analizador de lenguaje natural denominado Gherkin para ayudar a los equipos técnicos y no técnicos a definir reglas de negocio y requisitos. Puede combinar SpecFlow o Cucumber con Selenium para compilar pruebas de IU.

Andy mira a Amita.

Andy: Sé que estas opciones son nuevas para ti, por lo que ¿qué te parece si elegimos Selenium? Tengo algo de experiencia con Selenium y admite lenguaje de programación que ya conozco. Selenium también nos ofrece compatibilidad automática con varios exploradores.

Amita: Claro. Es mejor que uno de nosotros tenga algo de experiencia.

¿Cómo se ejecutan las pruebas funcionales en la canalización?

En Azure Pipelines, las pruebas funcionales se ejecutan de la misma manera que cualquier otro proceso o prueba. Pregúntese lo siguiente:

• ¿En qué fase se ejecutarán las pruebas?
• ¿En qué sistema se ejecutarán? ¿En el agente o en la infraestructura que hospeda la aplicación?

Veamos cómo responde a estas preguntas el equipo.

Mara: Lo que me encanta es que ahora podemos realizar las pruebas en un entorno similar al de producción, donde realmente se está ejecutando la aplicación. Las pruebas funcionales como las pruebas de IU tienen sentido en ese contexto. Podemos ejecutarlas en la fase de prueba de nuestra canalización.

Amita: Estoy de acuerdo. Podemos mantener el mismo flujo de trabajo si ejecutamos pruebas de interfaz de usuario automatizadas en la misma fase en la que ejecuto las pruebas manuales. Las pruebas automatizadas nos ahorrarán tiempo y me permitirán centrarme en la usabilidad.

Tim: Amita prueba el sitio web desde su portátil con Windows, ya que es lo que usan la mayoría de los usuarios que lo visitan. Pero nosotros compilamos en Linux y luego implementamos Azure App Service en Linux. ¿Cómo podemos abordar esto?

Mara: Buena pregunta. También debemos tener en cuenta dónde vamos a ejecutar las pruebas. Podemos ejecutarlas:

• En el agente: un agente de Microsoft o un agente que hospedamos.
• En la infraestructura de prueba: local o en la nube.

Nuestra fase de prueba actual incluye un trabajo. Ese trabajo implementa el sitio web en App Service desde un agente de Linux. Podemos agregar un segundo trabajo que ejecute las pruebas de interfaz de usuario desde un agente de Windows. El agente de Windows hospedado por Microsoft ya está configurado para ejecutar pruebas de Selenium.

Andy: Una vez más, mejor nos quedamos con lo que ya conocemos. Usemos el agente de Windows hospedado por Microsoft. Más adelante, podemos ejecutar las mismas pruebas desde los agentes de macOS y Linux si necesitamos mayor cobertura de pruebas.

El plan

Mara: De acuerdo. Esto es lo que vamos a hacer:

• Ejecute pruebas de interfaz de usuario de Selenium desde un agente de Windows hospedado por Microsoft.
• En la fase de prueba, hacer que las pruebas capturen el contenido web de la aplicación que se ejecuta en App Service.
• Ejecute las pruebas en todos los exploradores compatibles.

Andy: Trabajaré en esto con Amita. Amita, ¿qué te parece si nos reunimos mañana? Me gustaría investigar un poco antes de reunirnos.

Amita: ¡Perfecto! Nos vemos mañana.

Creación de un plan de pruebas funcionales

Acabamos de ver cómo ha decidido el equipo la forma en que implementará sus primeras pruebas funcionales. Si su equipo está empezando a incorporar pruebas funcionales a la canalización (o incluso si ya las está realizando), recuerde que siempre necesita un plan.

Muchas veces, al preguntar a los miembros del equipo por su plan de pruebas de rendimiento, es habitual que respondan con una lista de las herramientas que van a usar. Pero una lista de herramientas no es un plan. También debe averiguar cómo se configurarán los entornos de prueba. Debe determinar los procesos que se usarán y qué sucederá en caso de éxito o fracaso.

Asegúrese de que su plan:

• Tiene en cuenta las expectativas de la empresa.
• Tiene en cuenta las expectativas de los usuarios de destino.
• Define las métricas que se van a usar.
• Define los indicadores clave de rendimiento (KPI) que se van a usar.

Las pruebas de rendimiento deben formar parte de su plan desde el principio. Si usa un guion gráfico o un panel Kanban, considere la posibilidad de tener un área cerca donde pueda planear la estrategia de pruebas. Como parte del planeamiento de iteración, debe resaltar las brechas en la estrategia de pruebas. También es importante determinar cómo se supervisará el rendimiento una vez implementada la aplicación y no solo medir el rendimiento antes de su publicación.