El Software testing o como se conoce en espaol las pruebas de software se aplican como una etapa ms del proceso de desarrollo

de software, su objetivo es asegurar que el software cumpla con las especificaciones requeridas y eliminar los posibles defectos que este pudiera tener. En un principio la mayora de empresas de desarrollo contaban con una etapa de pruebas demasiado informal, en la actualidad el software testing se ha convertido en una de las etapas ms crticas del ciclo de vida del desarrollo de software y esto ha causado el origen de diversas metodologas. En la actualidad el software testing se hace ms complicado ya que debe hacer frente a una gran cantidad de metodologas de desarrollo, lenguajes de programacin, sistemas operativos, hardware etc. Es por esto que el testing debe apoyarse en metodologas generales que revisan los aspectos ms fundamentales que debe considerar todo proceso de pruebas. Debido a esta complejidad actualmente se cuentan con una gran cantidad de software diseado exclusivamente para la etapa de pruebas, incluyendo la gestin del proceso de software testing, la administracin y seguimiento de errores, la administracin de los casos de prueba, automatizacin de pruebas etc. Luego de culminadas las etapas de anlisis, diseo y desarrollo se inicia la etapa de pruebas, en esta etapa lo recomendable es que el software se mantenga en un ambiente aislado o separado del ambiente de desarrollo o de produccin, lo ideal es preparar un ambiente de pruebas lo ms parecido a los ambientes que existen en produccin para asegurar su correcto funcionamiento en esa futura etapa, se debe considerar adquirir un equipo de pruebas especializado software tester o analista de pruebas, con experiencia, estas personas tienen una formacin que les permite detectar una gran cantidad de errores en tiempos mnimos, as como una metodologa especifica que les permite hacer el trabajo de manera correcta, algunas empresas ms informales utilizan a los futuros usuarios del sistema como testers situacin que puede traer una serie de problemas debido a la poca experiencia que pueden tener los usuarios en la deteccin de errores, adems se obvian pruebas importantes como las pruebas de Esfuerzo o Stress testing, tambin se dejan de lado las pruebas unitarias o pruebas modulares, las que deberan asegurar que cada mdulo del sistema trabaje correctamente de manera independiente, otro error muy conocido en empresas de software es el uso de los mismos desarrolladores como analistas de pruebas, es muy difcil probar con objetividad un software si nosotros mismos lo hemos desarrollado, un tcnico o analista programador empezara a probar con la idea preconcebida de que su hijito trabaja a la perfeccin e inconscientemente evitara realizar pruebas ms exhaustivas considerando que las mismas podran ser absurdas o innecesarias, lo bueno es que poco a poco estas ideas van quedando descartadas y se van alineando conceptos hacia un software testing profesional.

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 especficas para los cuales han sido creados, es comn 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 produccin. A este tipo de pruebas se les denomina tambin pruebas de comportamiento o pruebas de caja negra, ya que los testers o analistas de pruebas, no enfocan su atencin a como se generan las respuestas del sistema, bsicamente el enfoque de este tipo de prueba se basa en el anlisis 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 mayora de los casos son realizadas manualmente por el analista de pruebas, tambin 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 automatizacin de pruebas puede resultar compleja y solo la recomendara en algunas funcionalidades especficas, por ejemplo en las pantallas que tendrn 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 usara 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 bsicamente al negocio, posibles particularidades que no se hayan contemplado adecuadamente en el diseo funcional, el analista de pruebas debera dar fuerza a las pruebas funcionales y ms an a las de robustez, generalmente los usuarios realizan las pruebas con la idea que todo debera funcionar, a diferencia del analista de pruebas que tiene ms bien una misin destructiva, su objetivo ser encontrar alguna posible debilidad y si la llega a ubicar se esforzar por que deje de ser pequea y posiblemente se convertir en un gran error, cada error encontrado por el analista de pruebas es un xito, y se debera 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 algn malestar si el tester sigue encontrando errores, si no se corrige esta situacin los proyectos en su gran mayora fracasaran o perdern ms tiempo an. En la empresa en la he laborado algunos aos solo se realizaban pruebas del tipo funcional, ya que al parecer son los que el usuario mejor comprenda y en las que poda apoyar, con el pasar de los aos esta situacin a cambiado y en la actualidad se utilizan tambin pruebas unitarias en la mayora 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 ms evidentes y fciles de corregir, en la etapa de pruebas funcionales el sistema debera estar bastante estable y con muy pocos errores crticos. Si un sistema llega a la etapa de pruebas funcionales con demasiados errores crticos y/o bloqueantes, se debera 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 resolucin de los errores ya que en esta etapa solo se centra la atencin en las entradas y salidas, y no en la lgica intermedia, (Black Box Caja Negra).