Las pruebas funcionales - (Functional Software
Testing) y las pruebas unitarias (Unit Software Testing) deben ser
consideradas como temas cien por ciento técnicos, en mi experiencia
como analista de pruebas o también llamado tester, he llegado a probar
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 definición funcional y técnica decente antes de iniciar el proceso de prueba, en realidad en un proceso de aseguramiento de la calidad el analista QA revisor debe validar que estos documentos son lo suficientemente claros y consistentes, una vez aprobados estos documentos podrán servir de base para que el analista de pruebas pueda preparar el plan de pruebas, el cronograma de pruebas y los casos de prueba.
Para el analista de pruebas es muy importante y conveniente tener una definición funcional y técnica decente antes de iniciar el proceso de prueba, en realidad en un proceso de aseguramiento de la calidad el analista QA revisor debe validar que estos documentos son lo suficientemente claros y consistentes, una vez aprobados estos documentos podrán servir de base para que el analista de pruebas pueda preparar 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 calidad del
sistema. Evidentemente el analista de pruebas o tester debe ser un
profesional en Ing. De Sistemas o Ing. de Software, los conocimientos
técnicos son valiosos en esta labor, pero no son suficientes,
necesitamos también tener conocimientos del negocio, en la actualidad
los sistemas más importantes son realizados para dar solución a los
problemas de negocios.
El nivel de conocimiento del tester sobre 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
aplicación y a cualquier tipo de plataforma: Web, C/S o Host, siendo
esta última a mí parecer la más complicada.
Para conocer como funcionara
el sistema y tener una visión general de lo que este hace para el
negocio es necesario asimilar la documentación funcional y técnica
previamente definida. Luego de asimilar estos conocimientos será más
sencillo el desarrollo de los casos de prueba.
En las pruebas funcionales los
casos de prueba tienen el objetivo de detectar errores, los casos de
prueba deben definir los datos de entrada a utilizar, el proceso que
debemos seguir en el sistema y el resultado esperado.
Una vez concluidos los casos
de prueba es mas sencillo poder estimar cuanto tiempo nos tomara una
primera barrida de pruebas y con esto también podremos realizar nuestro
cronograma y plan de pruebas.
Los casos de prueba
nos permitirán probar todas las funcionalidades del sistema, sin
embargo es importante tener buen criterio a la hora de desarrollarlos.
Las combinaciones de casos de prueba podrían ser prácticamente
infinitas, propongo el siguiente ejemplo:
Si pensamos hacer casos funcionales para un sistema bancario nos encontraremos con una gran combinación de variables:
Para este ejemplo solo nos centraremos en un simple retiro bancario, en donde nos encontraríamos con las siguientes variables:
¿En que tipo de cuenta haremos el cargo? Ahorros, Corriente, A Plazos
Esto nos daría al menos 3 variables o casos de prueba.
Esto nos daría al menos 3 variables o casos de prueba.
¿La cuanta tendrá saldo? Saldo = 0, Saldo > 0, Saldo < 0
3 variables
3 variables
¿Es una cuenta en Moneda Nacional MN o Moneda extranjera?
2 variables
2 variables
¿Pertenece a una Persona natural PN o Persona Jurídica PJ?
2 variables
2 variables
¿La cuenta es mancomunada? Si o No
2 variables
2 variables
¿En que estado se encuentra la cuenta? Activa, Inactiva, Cerrada (Suponiendo que solo se manejen 3 estados).
3 variables
3 variables
¿La cuenta tendrá alguna facilidad crediticia? Es decir ¿Permite sobregiros?
Si o No
2 variables
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 atención se realizará esta operación?
- En ventanilla
- Cajero Automático – ATM
- POS – Pago de servicio o consumo
- Home Bankin
4 variables
Para este ejemplo tan sencillo
podríamos obtener fácilmente más de 3000 casos de prueba y ni siquiera
estamos enfocados a los casos que presentarán en cada pantalla. Como
menús, listas, grillas, botones etc. Por este motivo debemos delimitar
claramente cual es la funcionalidad que queremos probar diseñando cada
caso de manera que abarque la mayor cantidad de esfuerzo posible al
sistema.
Una vez que empezamos a probar
nuestros casos siempre deberíamos ir un poco más allá. Muchos de los
errores que he podido encontrar no estaban escritos en mis casos de
prueba.
Si en mi caso defino hacer un cargo de 1000 dólares, luego de
eso podría hacer una prueba con un cargo de 1000.01 y otro de 9999.99
siempre tratando de encontrar los valores limites que provoquen un mal
funcionamiento. Es interesante notar que la gran mayoría de los errores
se encuentran en los valores límite. Si una pantalla se define para
que no soporte un número mayor de 99999999.99 pues entonces probemos con
100000000.00 pues el sistema debería mostrarnos un mensaje indicando
que el monto ingresado esta fuera del rango permitido o algo por el
estilo.
Es increíble 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 que debe
de hacer y por supuesto que no haga lo que no debe de hacer, la labor
del analista de pruebas es totalmente destructiva para con el sistema,
un analista tester jamás debería estar bajo las ordenes de un
programador y tampoco es recomendable dejar que el programador pruebe
sus propios programas, es gracioso cuando me 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 quieren
maltratarlos, los aman…
Otro nicho en el que se
ocultan errores podrían ser los campos de ingreso de datos, aún no
entiendo porque tantos programadores no colocan valores límite máximos
permitidos en los campos de texto, sobre todo en los campos de párrafos
o multilíneas, disfruto 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 en un sistema y lo
logra pasar limpio pues ese programador se ha ganado mi respeto, a pesar
de ser una definición tan simple muchos la olvidan.
Las pruebas que requieran
cálculos de diversos valores deberían tener pocos casos pero muy
extensos y complejos, alguna vez hice pruebas para un sistema de bolsa
de valores en donde se deberían calcular diversos campos calculados,
cada uno de ellos mostrado en un campo o grilla, el caso debe
especificar que valor se espera en cada campo y una vez ejecutado el
caso constataremos que los datos que se presenten sean correctos, tanto
en las pantallas como en los reportes, jamás he tenido la experiencia
de encontrar un sistema nuevo sin errores en sus cálculos complejos “El
sistema nunca funciona bien la primera vez”. ¡Ese es mi lema!
Por último una muy buena
recomendación de pruebas es el manejo del valor cero 0 muchas 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 algún otro mensaje horrible.
No hay comentarios.:
Publicar un comentario