Tipos de pruebas: testing funcional vs. no funcional
Artículo de Pablo Gómez
El test funcional, no funcional y la sandwichera automática
Hace unos días mis hijos me preguntaron (de nuevo) qué hacía exactamente en mi trabajo en Redsauce. Les hablé de los defectos en las aplicaciones, de cómo evitar que aparecieran, tipos de pruebas…
…y mientras hablaba a dos niños sobre tipos de pruebas preparando unos sándwiches, se me ocurrió una analogía para diferenciar los test funcionales de los no funcionales. Vamos allá.
Imagina que estás construyendo una máquina de hacer sándwiches automática, para usarla en un cumpleaños con decenas de chavales. ¡Y te quieres asegurar de que va a funcionar correctamente porque sino al día siguiente el grupo de whatsapp del cole te va a poner al hilo!
¿Qué hace la máquina? (es decir, las Pruebas funcionales y su importancia entre los tipos de pruebas)
Para asegurar que tu máquina hace realmente sándwiches y no hamburguesas o pizzas, es necesario hacer pruebas funcionales, entre los distintos tipos de pruebas esta es una de las más cruciales.
Deberías realizar, por ejemplo:
Prueba del pan y el relleno: probando que la máquina coloque el pan correctamente y agregue los ingredientes en el orden correcto. Sería un desastre si el queso termina en el exterior del sándwich, sobre todo si acabas la fiesta teniendo que limpiar la sandwichera.
Prueba de botones: asegurandote de que los botones "Hacer Sándwich" y "Detener" funcionen como deberían. Imagina la escena si el botón "Detener" te lanza el sándwich en la cara en lugar de apagar la máquina.
¿Y cómo lo hace? (es decir, las Pruebas no funcionales y su relevancia entre los tipos de pruebas)
En este caso, las pruebas no funcionales se enfocan en aspectos no relacionados con cómo es el propio sándwich pero si con la experiencia de uso de la sandwichera, siendo otro componente ensencial entre los distintos tipos de pruebas. Veamos unos ejemplos:
Prueba de velocidad: ¿puede la máquina hacer un sándwich en 30 segundos o tarda más que una pelea de Dragon Ball? Si es muy lenta, puede ser preferible hacer los sándwiches a mano.
Prueba de resistencia: ¿puede la máquina hacer 1000 sándwiches uno tras otro (prueba de rendimiento)? ¿Puede atender a 100 niños a la vez? (¡Ataque DDos! Menos mal que sabemos manejar la ciberseguridad). Sobrecalentarse o colapsarse no es una opción cuando tienes decenas de pequeñas criaturas hambrientas mirándote a los ojos.
Prueba estética: si tu máquina es extremadamente fea o apesta, hasta los niños más valientes huirán buscando la de patatas fritas.
Estoy seguro que según has ido leyendo esta pequeña historia, has llevado este símil al campo de desarrollo de software y probablemente te has visto en alguna situación similar, reflexionando sobre los diferentes tipos de pruebas.
Tipos de pruebas: Pruebas funcionales
Son aquellas que prueban la funcionalidad de una aplicación, valga la redundancia. Se trata principalmente de pruebas de caja negra, por lo que no entran en el código fuente.
La funcionalidad está reflejada en los requisitos, las especificaciones, los casos de prueba, los UAT (Criterios de aceptación), o en una reunión de definición de backlog. Estos, pueden ser definidos por el cliente, el equipo de producto, el CTO, etc.
De ahí probablemente termine convertida en una o varias tareas. Estas se convertirán en un ticket, post-it o similar en un tablero con columnas.
Una vez que la funcionalidad está implementada y desplegada en un entorno, es cuando la prueba valida que el resultado actual coincide con el esperado.
Por lo general, estas pruebas se realizan cuando el software ya ha alcanzado un estado avanzado de desarrollo y sus componentes están incorporados al resto, lo que permite detectar posibles problemas de integración.
Ese sería un escenario idílico.
Pero, ¿con qué problemas nos enfrentamos en el mundo real?
Especificaciones o requisitos vagos o inexistentes.
No hay criterios de aceptación
El entorno de pruebas no se parece ni remotamente al de producción.
Pero eso es tema de otro post…
Tipos de pruebas: Pruebas no funcionales
Respecto a las pruebas no funcionales, las cosas cambian mucho.
Son unas pruebas más, digamos, “bohemias”, por aquello de estar en cierto modo alejadas de las normas. Tratan aspectos como las expectativas de uso del usuario final, probando el cómo más que el qué.
Pero ojo, esto no quiere decir que sean menos importantes que las pruebas funcionales. Se trata de pruebas complementarias. Y muy críticas dentro de todos los tipos de pruebas.
Veamos un ejemplo claro:
Una prueba funcional puede ser validar que, tras introducir en una página de autenticación un usuario y password correcto, acceda a la página principal. Si esto sucede, la prueba funcional es un éxito. Y si sucede tras 30 segundos de carga, sigue siendo un éxito funcional.
Sin embargo, no hubiera satisfecho una prueba no funcional que comprobara que la autenticación se realiza en menos de 2 segundos.
El problema llega a la hora de definir qué criterios emplearemos para considerar que la prueba se supera satisfactoriamente o es un fracaso.
Es fácil medir el tiempo de carga o cuántos usuarios concurrentes tiene un sistema pero no es tan fácil definir el valor esperado. ¿Por qué 2 segundos y no 1,8 segundos? ¿o 0,3? ¿Debe soportar el sistema 20 usuarios concurrentes? ¿por qué no 40? ¿Es fácil encontrar el botón de login o acceder a soporte online? ¿Cómo de fácil? ¿Cómo de segura o vulnerable es mi página?
Se trata de conceptos difíciles de valorar cuantitativamente pero de vital importancia para la experiencia de uso de una aplicación.
Tabla comparativa de los tipos de pruebas
Con estas definiciones sobre la mesa, podemos hacernos una idea de las diferencias principales entre las pruebas funcionales y las no funcionales.
Pruebas funcionales | Pruebas no funcionales |
---|---|
Prueban qué hace la aplicación | Prueban cómo se comporta la aplicación. |
Están basadas en los requisitos de negocio. | Están basadas en las expectativas del usuario final y el rendimiento esperado. |
El feedback del cliente ayuda a reducir los defectos y mejorar funcionalidades. | El feedback del cliente ayuda a conocer sus expectativas y la experiencia de uso. |
Ejemplo: una página de autenticación debe mostrar los campos para introducir usuario y password. | Ejemplo: la página de autenticación debe estar cargada en menos de 2 segundos. |
Se llevan a cabo generalmente antes de los test no funcionales. | Se llevan a cabo generalmente después de los test funcionales. |
Es relativamente fácil definir requisitos funcionales. | Suele ser difícil definir los requisitos no funcionales. |
Es posible hacerlas de manera manual y automática. | Aunque algunas es posible realizarlas manualmente, otras es necesario usar herramientas automáticas. |
Ejemplos de estos tipos de pruebas
Ejemplos de pruebas funcionales: | Ejemplos de pruebas no funcionales: |
---|---|
· Unitarias (TDD) | · Rendimiento (carga, estrés, pico…) |
· Smoke testing | · Escalabilidad |
· Test de aceptación de usuario | · Usabilidad |
· De integración | · Cumplimiento de normativa |
· De regresión | |
· Localización | · Backup |
· Globalización | · Recuperación de desastres (DRP) |
· Interoperabilidad | · Estilo de código |
Espero que esta lectura haya sido amena e interesante, llevándote una idea más clara de las diferencias entre las pruebas funcionales y las no funcionales y cómo se clasifican dentro de los tipos de pruebas. ¡Es la hora de comernos ya ese sándwich! Ven a disfrutarlo con nosotros en Redsauce