Blog

Hace 5 días inicié un debate en el grupo de discusión Análisis Funcional de mi amigo Dani Mónaco y realmente me sorprende los comentarios que algunos de sus miembros van dejando.

El cuerpo del debate es el siguiente:

Solo para comenzar, debo decir que como Tester necesito del Analista Funcional durante muchos momentos de mi trabajo, partiendo del Requerimiento en adelante.

Quisiera poder discutir con Uds que opinan al respecto, y si han tenido alguna experiencia cuál ha sido su resultado.

Muchos colegas actualmente hacen testing para verificar que las funcionalidades que componen el proyecto cumplan con las especificaciones funcionales del diseño, observando metódicamente el comportamiento del aplicativo y/o eventualmente, el cómo está construido.

Estas pruebas pueden ser realizadas de diversas formas:
> Manuales
> Parte manual y parte automatizada
> Totalmente automatizadas

Todo este camino se recorre junto con el Analista Funcional, quien nos define «El Norte» por así decirlo.

Ahora bien, sin dudas y es una opinión personal, «Automatizar» es sinónimo de «Estrategia», es así que que podemos pensar / reflexionar / discutir los siguientes aspectos, para darle forma a la misma:

# Razones para automatizar las pruebas 
> Ciclo de prueba manual es muy largo
> Proceso de prueba manual es propenso a errores
> Liberar a la gente para realizar tareas creativas
> Generar un ambiente de confianza soportado por los test
> Obtener realimentación de forma temprana y con alta frecuencia
> Generar conocimiento del sistema en desarrollo a partir de los test
> Generar documentación del código consistente
> Generar una mejor utilización de los recursos a partir de menores costos

# Obstáculos para automatizar las pruebas 
> Actitud de los programadores
> Inversión inicial
> Código que siempre cambia
> Sistemas legacy
> Viejos hábitos

# Qué debería automatizarse 
> Pruebas unitarias y de componentes
> Pruebas de funcionalidad sin interfaces de usuarios
> Pruebas de sistema con interfaces de usuario

# Qué no debería automatizarse 
> Pruebas de usabilidad
> Pruebas exploratorias
> Pruebas que no fallarán
> Tareas únicas de fácil ejecución manual y difícil automatización

# Estrategia para comenzar la automatización 
> Capacitación a los analistas, testers y programadores
> Seleccionar una forma de trabajo
> Seleccionar herramientas
> Desarrollar proyectos pilotos
> Institucionalizar

Les dejo a continuación algunos de los comentarios que se han publicado :

Comentario 1

Hoy estamos ante un pequeño gran problema, el analista es funcional, técnico y hasta programador. El funcional solo debe verificar que la funcionalidad de los sistemas estén acorde a las especificaciones. Y eso se logra con la participación de todos los usuarios afectados en forma conjunta. Con un ambiente de prueba que simule a uno de producción.
En las Empresas Multinacionales, donde cada uno tiene un rol perfectamente definido el tema se simplifica.
El exito depende de la disposición de los usuarios, de tratar de probar todo.
Es evidente que todos deben estár capacitados.

Comentario 2

Hola Gustavo, estoy de acuerdo con lo que decís. Muchas veces el analista funcional es el responsable de que lo que se esta desarrollando es lo que se pidió, por lo que, si esta cumpliendo ese rol, el porcentaje en que este involucrado en la automatización será mayor que si solamente baja las específicaciones y ahy otros grupos involucrados. De todas maneras, más allá del rol que cumpla el analista, me parece interesante que cubra el mayor porcentaje posible en el proceso. Una mirada funcional sobre el armado del testeo, manual o automatizado, siempre viene bien para cubrir todas las bases.

Comentario 3

Si el paradigma de desarrollo es TDD ,el analista tiene un 50 % de participación. Es el que define los casos de uso, ,y de prueba asociado con su cobertura correspondiente al comienzo del desarrollo ,y lote de prueba de cada caso.Por que es el que posee el mayor conocimiento del negocio.
Esto es teóricamente ;pero en la práctica se definen los casos de uso, se implementan, a veces con test unitarios /técnicos se pasan a QA/QC, que implementa los casos de prueba y toma la decisión de la cobertura de la automatización ,basándose la toma de decisión el grado de complejidad, o tiempo de ejecución.
Las buenas prácticas recomiendan a lo sumo 20 caso de pruebas activos,que representan los casos de mayor cobertura,o más críticos.Realmente. Se implementan más que se habilitan, deshabilitan de acuerdo a las etapas del proyecto.
Concepto como TDD e IC deben estar bien claros tanto en el área de análisis,como desarrollo y QA a la hora de empezar la automatización;para poder evaluar bien el porcentaje de la tarea de análisis y el porcentaje de éxito en la implementacion de la automatizacion de pruebas.

• Te parecen correctos los comentarios publicados o hay alguno con el cual no estas de acuerdo?
• Has tenido que interactuar con Analistas Funcionales y vivido parte de estas experiencias?