FUNCTIONAL TESTING - PRUEBAS FUNCIONALES

Se denominan pruebas funcionales o Functional Testing, a las pruebas de software que tienen por objetivo probar que los sistemas desarrollados, cumplan con las funciones específicas para los cuales han sido creados, es común que este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyo de algunos usuarios finales, esta etapa suele ser la ultima etapa de pruebas y al dar conformidad sobre esta el paso siguiente es el pase a producción.

A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de caja negra, ya que los testers o analistas de pruebas, no enfocan su atención a como se generan las respuestas del sistema, básicamente el enfoque de este tipo de prueba se basa en el análisis de los datos de entrada y en los de salida, esto generalmente se define en los casos de prueba preparados antes del inicio de las pruebas.

Las pruebas funcionales en la mayoría de los casos son realizadas manualmente por el analista de pruebas, también es posible automatizar este tipo de pruebas utilizando herramientas como WinRunner o SilkTest las cuales permiten generar scripts conforme nosotros hagamos interacciones con el aplicativo a probar. La automatización de pruebas puede resultar compleja y solo la recomendaría en algunas funcionalidades específicas, por ejemplo en las pantallas que tendrán mayor uso, generalmente pantallas de ingreso de datos. Se debe tener en cuenta que el costo de estas licencias suele ser bastante elevado.

Al realizar pruebas funcionales lo que se pretende en ponerse en los pies del usuario, usar el sistema como él lo usaría sin embargo el analista de pruebas debe ir mas allá que cualquier usuario, generalmente se requiere apoyo de los usuarios finales ya que ellos pueden aportar mucho en el desarrollo de casos de prueba complejos, enfocados básicamente al negocio, posibles particularidades que no se hayan contemplado adecuadamente en el diseño funcional, el analista de pruebas debería dar fuerza a las pruebas funcionales y más aún a las de robustez, generalmente los usuarios realizan las pruebas con la idea que todo debería funcionar, a diferencia del analista de pruebas que tiene más bien una misión destructiva, su objetivo será encontrar alguna posible debilidad y si la llega a ubicar se esforzará por que deje de ser pequeña y posiblemente se convertirá en un gran error, cada error encontrado por el analista de pruebas es un éxito, y se debería considerar como tal, en mi experiencia personal

he podido ver que proyectos atrasados, o con algunos problemas de tiempo sacrifican horas de pruebas, incluso se siente algún malestar si el tester sigue encontrando errores, si no se corrige esta situación los proyectos en su gran mayoría fracasaran o perderán más tiempo aún.

En la empresa en la he laborado algunos años solo se realizaban pruebas del tipo funcional, ya que al parecer son los que el usuario mejor comprendía y en las que podía apoyar, con el pasar de los años esta situación a cambiado y en la actualidad se utilizan también pruebas unitarias en la mayoría de los aplicativos desarrollados, siendo las pruebas unitarias una primera etapa y las pruebas funcionales la segunda y definitiva en la que se da la conformidad del sistema.

Los sistemas que han pasado por pruebas unitarias tienen un menor tiempo de pruebas funcionales, este comportamiento es obvio, ya que las pruebas unitarias nos permiten encontrar los errores más evidentes y fáciles de corregir, en la etapa de pruebas funcionales el sistema debería estar bastante estable y con muy pocos errores críticos. Si un sistema llega a la etapa de pruebas funcionales con demasiados errores críticos y/o bloqueantes, se debería devolver el sistema a la etapa de pruebas unitarias ya que resulta muy poco productivo realizar pruebas funcionales con sistemas inestables, el avance es demasiado lento y el analista de pruebas no podrá apoyar mucho en la resolución de los errores ya que en esta etapa solo se centra la atención en las entradas y salidas, y no en la lógica intermedia, (Black Box – Caja Negra).

Ing. Alexander Oré B.