Como Realizar Pruebas Funcionales http://www.calidadysoftware.com/testing/como_realizar_pruebas_funcionales.

php Las pruebas funcionales - Functional Software Testing y las pruebas unitarias Un it Software Testing deben ser consideradas como temas cien por ciento tcnicos, en mi experiencia como analista de pruebas o tambin llamado tester, he llegado a pr obar una buena cantidad de sistemas en varias empresas, enfocadas principalmente al sector financiero. Para el analista de pruebas es muy importante y conveniente tener una definicin f uncional y tcnica decente antes de iniciar el proceso de prueba, en realidad en u n proceso de aseguramiento de la calidad el analista QA revisor debe validar que estos documentos son lo suficientemente claros y consistentes, una vez aprobado s estos documentos podrn servir de base para que el analista de pruebas pueda pre parar el plan de pruebas, el cronograma de pruebas y los casos de prueba.

Cada vez que tengo un sistema en mis manos siento que mi labor debe ser darle un valor agregado, cada error que yo pudiera encontrar significa un xito para la ca lidad del sistema. Evidentemente el analista de pruebas o tester debe ser un pro fesional en Ing. De Sistemas o Ing. de Software, los conocimientos tcnicos son va liosos en esta labor, pero no son suficientes, necesitamos tambin tener conocimie ntos del negocio, en la actualidad los sistemas ms importantes son realizados par a dar solucin a los problemas de negocios. El nivel de conocimiento del tester so bre un negocio debe ser similar al del usuario que utilizar el sistema. Un tester experimentado puede llegar a tener un amplio conocimiento de diversos negocios y le resultar sencillo adaptarse a cualquier tipo de aplicacin y a cualquier tipo de plataforma: Web, C/S o Host, siendo esta ltima a m parecer la ms complicada. Para conocer como funcionara el sistema y tener una visin general de lo que este hace para el negocio es necesario asimilar la documentacin funcional y tcnica prev iamente definida. Luego de asimilar estos conocimientos ser ms sencillo el desarro llo de los casos de prueba. En las pruebas funcionales los casos de prueba tienen el objetivo de detectar er rores, los casos de prueba deben definir los datos de entrada a utilizar, el pro ceso que debemos seguir en el sistema y el resultado esperado. Prximamente espero publicar un artculo tocando el tema de cmo realizar buenos casos de prueba. Una vez concluidos los casos de prueba es mas sencillo poder estimar cuanto tiem po nos tomara una primera barrida de pruebas y con esto tambin podremos realizar nuestro cronograma y plan de pruebas. Los casos de prueba nos permitirn probar todas las funcionalidades del sistema, s in embargo es importante tener buen criterio a la hora de desarrollarlos. Las c ombinaciones de casos de prueba podran ser prcticamente infinitas, propongo el sig uiente ejemplo: Si pensamos hacer casos funcionales para un sistema bancario nos encontraremos c on una gran combinacin de variables: Para este ejemplo solo nos centraremos en un simple retiro bancario, en donde no s encontraramos con las siguientes variables: En que tipo de cuenta haremos el cargo? Ahorros, Corriente, A Plazos Esto nos dara al menos 3 variables o casos de prueba. La cuanta tendr saldo? Saldo = 0, Saldo > 0, Saldo < 0 3 variables Es una cuenta en Moneda Nacional MN o Moneda extranjera?

2 variables Pertenece a una Persona natural PN o Persona Jurdica PJ? 2 variables La cuenta es mancomunada? Si o No 2 variables En que estado se encuentra la cuenta? Activa, Inactiva, Cerrada (Suponiendo que s olo se manejen 3 estados). 3 variables La cuenta tendr alguna facilidad crediticia? Es decir Permite sobregiros? Si o No 2 variables De que tipo ser el cargo a la cuenta? Transferencia entre cuenta propia Transferencia a un tercero Transferencia interbancaria Retiro en efectivo Pago de un cheque 5 variables En que canal de atencin se realizar esta operacin? En ventanilla Cajero Automtico ATM POS Pago de servicio o consumo Home Bankin 4 variables Para este ejemplo tan sencillo podramos obtener fcilmente ms de 3000 casos de prueb a y ni siquiera estamos enfocados a los casos que presentarn en cada pantalla. Co mo mens, listas, grillas, botones etc. Por este motivo debemos delimitar claramen te cual es la funcionalidad que queremos probar diseando cada caso de manera que abarque la mayor cantidad de esfuerzo posible al sistema. Una vez que empezamos a probar nuestros casos siempre deberamos ir un poco ms all. Muchos de los errores que he podido encontrar no estaban escritos en mis casos d e prueba. Si en mi caso defino hacer un cargo de 1000 dlares, luego de eso podra h acer una prueba con un cargo de 1000.01 y otro de 9999.99 siempre tratando de en contrar los valores limites que provoquen un mal funcionamiento. Es interesante notar que la gran mayora de los errores se encuentran en los valores lmite. Si una pantalla se define para que no soporte un nmero mayor de 99999999.99 pues entonc es probemos con 100000000.00 pues el sistema debera mostrarnos un mensaje indican do que el monto ingresado esta fuera del rango permitido o algo por el estilo. E s increble como algunos programadores creen que no se deben probar casos para los cuales el sistema no esta preparado, bueno yo pienso totalmente lo contrario un buen sistema debe funcionar perfectamente con datos ingresados bien o mal esto diferencia a un sistema de alta calidad, se debe probar que el sistema haga lo q ue debe de hacer y por supuesto que no haga lo que no debe de hacer, la labor de l analista de pruebas es totalmente destructiva para con el sistema, un analista tester jams debera estar bajo las ordenes de un programador y tampoco es recomend able dejar que el programador pruebe sus propios programas, es gracioso cuando m e pongo a pensar en la gran cantidad de programadores que me han pagado apuestas por su seguridad en la robustez de sus sistemas, simplemente en el fondo no qui

eren maltratarlos, los aman Otro nicho en el que se ocultan errores podran ser los campos de ingreso de datos , an no entiendo porque tantos programadores no colocan valores lmite mximos permit idos en los campos de texto, sobre todo en los campos de prrafos o multilneas, dis fruto de esas pruebas haciendo un solo Copy de un texto mediano para luego hacer 100 veces Paste, casi me parece escuchar como se truenan los huesos de la base de datos cuando no soportan el contenido. Si realizo esa prueba la primera vez e n un sistema y lo logra pasar limpio pues ese programador se ha ganado mi respet o, a pesar de ser una definicin tan simple muchos la olvidan. Las pruebas que requieran clculos de diversos valores deberan tener pocos casos pe ro muy extensos y complejos, alguna vez hice pruebas para un sistema de bolsa de valores en donde se deberan calcular diversos campos calculados, cada uno de ell os mostrado en un campo o grilla, el caso debe especificar que valor se espera e n cada campo y una vez ejecutado el caso constataremos que los datos que se pres enten sean correctos, tanto en las pantallas como en los reportes, jams he tenido la experiencia de encontrar un sistema nuevo sin errores en sus clculos complejo s El sistema nunca funciona bien la primera vez . Ese es mi lema! Por ltimo una muy buena recomendacin de pruebas es el manejo del valor cero 0 much as veces por la complejidad de los procesos el programador olvida que este valor puede llegar a ser un divisor de otro valor y entonces: Error Exception Faillure #afg99d7 - no valido o algn otro mensaje horrible. Espero que con estas pequeas recomendaciones puedan ser capaces de encontrar una gran cantidad de errores. Prximamente espero mejorar y crear mejores artculos. No olviden que pueden escribirnos sobre cualquier consulta o comentario. Ing. Alexander Or B.