Functional testing

¿Qué es el functional testing?

El functional testing comprueba que una función hace lo que los requisitos dicen que debería. Le das un input, comparas el output con el resultado esperado. ¿El código de descuento resta un 10% del total? ¿La caja de búsqueda devuelve los productos que coinciden? ¿Una contraseña incorrecta se rechaza? Trata el software como una caja negra. Lo que pasa dentro del código no importa, solo que el comportamiento sea correcto.

Esto lo distingue del testing no funcional, que mide cualidades como la velocidad, la seguridad o cómo aguanta el sistema bajo carga. El functional testing responde a "¿funciona?", no a "¿qué tan bien?". También se sitúa en un alcance distinto al del testing end to end. El functional testing suele verificar una capacidad frente a su especificación, mientras que el E2E encadena muchas capacidades en un recorrido de usuario completo a través de sistemas reales. Una prueba funcional podría confirmar que el endpoint de "restablecer contraseña" envía un email; una prueba E2E sigue el enlace, fija una nueva contraseña y vuelve a iniciar sesión.

Las pruebas funcionales abarcan todos los niveles de detalle. Una prueba unitaria sobre una sola función de precios es funcional. También lo es un tester manual que recorre un formulario de registro a clics. También lo es una suite automatizada que golpea una API y asevera sobre la respuesta. El hilo común es el mismo: comportamiento medido frente a un requisito definido, por eso unos criterios de aceptación claros hacen el functional testing mucho más útil que unos vagos.

Functional testing en Dallonses

Atamos las pruebas funcionales a los requisitos, no a conjeturas sobre lo que una función podría hacer. Cuando acordamos los criterios de aceptación con un cliente al principio, esos se convierten en las aserciones de después. Una prueba que mapea a un requisito escrito te dice algo. Una prueba que no mapea a nada solo infla los números.

La mayor parte de esto corre como testing automatizado dentro del pipeline, así que cada cambio se comprueba contra la especificación antes de fusionarse. Dejamos que las pruebas funcionales y de integración rápidas hagan el trabajo pesado y reservamos las ejecuciones más lentas de recorrido completo para los flujos que cargan un riesgo real. Cuando el producto de un cliente ha crecido más rápido que su suite de pruebas, ayudamos a cerrar ese hueco: fijar qué se supone que hace cada función y luego hacer que las pruebas lo demuestren.

¿Necesitas saber que tus funciones de verdad hacen lo que prometen? Vamos a comprobarlo.

Hablemos de QA