Manejo de expectativas y Estimación del Esfuerzo de Pruebas – Parte II

manejo de expectativasEl 19 de Enero publiqué un debate (puedes pulsar AQUI para acceder a él) originado en un grupo de discusión dentro de la red LinkedIn, en donde planteaba una situación que estaba viviendo una amiga en su oficina.

A continuación, les dejo parte de los comentarios que han dejado otros miembros del grupo interesados en este tema y y que me parecen interesantes para compartirles.

_____
Comentario de Maximiliano,
Analista de Negocios

Buen día.
Es una situación complicada para todos; para el jefe, para el equipo de QA y para el cliente. Cada uno tiene sus intereses y quiere lograr sus objetivos cuanto antes.
La responsabilidad de que un proyecto sea exitoso es de todas las áreas involucradas. La responsabilidad de que el cliente entienda que sus expectativas se van a ver realizadas, corresponde al acompañamiento que debe dar el equipo de proyectos de IT, comenzando por el jefe o los responsables de «vender» el proyecto, como un proceso complejo y amplio, al cliente.
Me da la sensación de que en algún momento del proyecto el jefe perdió de vista el estado del proyecto y su complejidad. Por otro lado me parece que faltó comunicación más fluida y frecuente entre en área de operativa de IT y el jefe ya que este último no tenía idea de la cantidad de casos a probar para este caso puntual.

Por lo tanto, según lo veo, creo que se trató de una falta de seguimiento más cercano del lado de IT sobre los tiempos del proyecto y las tareas pendientes. Esto involucra a ambas partes, jefes y subordinados.

_____
Comentario de Adrian,
Manual / Technical Test Manager | Test Lead | Senior Tester

Hola Gustavo, que tal.

Viendo los comentarios desde mi punto de vista a lo que me ha pasado puedo especular en lo siguiente:

¿Qué conclusiones pueden sacar al respecto?
1.-Que no se toma para nada el esfuerzo de prueba
2.-Que ya haya habido fecha de la dirección y esta no se mueve, ya sea por ser una promoción, por no caer en alguna multa, etc.
3.-Que no se tento el corazón el jefe para su personal(no creo que haya estado en la semana igual de estresado que su equipo)

¿Qué nivel de conocimiento e involucramiento e injerencia tiene el «jefe»?
1.-Ninguno, no sabe de Testing
2.-Que aun sabiendo de testing tenia que cumplir con una fecha dada previamente a él.
3.-Solo paso el trabajo a su equipo y se deslindo, nada mas quiere los resultados

¿En dónde se puede encontrar el origen del problema? ¿En el «jefe», en mi amiga o en el cliente?
1.-En el equipo completo creo que esta el problema, ya que con las métricas en la mano presentadas no es mas que sentido común y adoptar otra estrategia, probando como testeron el proyecto asi no hay tester que dure.

¿Alguien habrá hecho alguna «orden de magnitud» o estimación preliminar?
1.-Suele pasar
2.-Puede ser que no y se da una fecha muy corta por quedar bien con los altos mandos
3.-Puede ser que se tengan mal los parámetros de estimación o analogías de otros proyectos

¿El tema aquí habrá pasado por el «manejo de las expectativas» o por la «estimación del esfuerzo de prueba» debidamente concensuado con las partes?
Por el extracto del correo definitivamente no esta consensuado.

Como decimos en México, fue robo en despoblado(haciendo una analogía)

¿Les pasa algo parecido a Uds frecuentemente?
Esto es muy común cuando no se tiene un proceso y reglas definidas, y aun teniéndolas pasa.

Esto pasa y va a seguir pasando amigo Gustavo, lo mejor es tener métricas en lo posible que nos puedan dar un estimado realistas de los tiempos de prueba y esa información darla al PM, si de plano no da para mas ya hay que hacer una prueba basada en riesgos, primero los happy paths de la App y luego por priorización.

Te mando un Abrazo, por cierto, ¿Cuándo tienes la próxima reunión de testers OnLine?

Saludos.

_____
Comentario de Mariana
Analista QA

Buen dia,
es común que el tiempo de testing sea el primero en ser «sacrificado» cuando los tiempos no son suficientes, esto puede ser porque por lo general es el eslabón final de la cadena de de desarrollo y porque no se es consciente de que no por ser el último eslabón es el menos importante, al contrario, a mi entender el proceso de pruebas es fundamental. Seguramente no participó alguien del equipo de testing en la estimación de las tareas…

Saludos!

_____
Comentario de Andrea
Quality Assurance Technical Engineer

Hola! He pasado por esta situación y como bien dice Adrian Acosta si no es posible mover la fecha de entrega, el equipo de QA debe considerar una nueva estrategia y ejecutar los casos de prueba según sus prioridades (las cuales deben estar muy bien definidas y conversadas tanto con desarrolladores, manager y en el mejor de los casos clientes para que esto tenga éxito) y finalmente lo ideal es que el líder de QA pueda participar en las reuniones en donde la fecha límite sea acordada y hacer notar que si no es un tiempo aceptable, entonces el sistema se entregará por decirlo así «parcialmente probado según prioridades». Saludos!

_____
Comentario de Vanina
Analista Funcional

Coincido con Maximiliano, hubo una falla en el seguimiento, Control y Comunicacion en el Proyecto. Y agrego que tambien falto el compromiso e involucramiento del Jefe y posiblemente del Cliente.
Implementar algo que esta «parcialmente probado», conlleva sus riesgos… quizas se quiera seguir adelante ASUMIENDOLOS pero si la decision es arbitraria y sin tenerlos en cuenta, el remedio puede llegar a ser peor que la enfermendad.

_____
Comentario de Luis Adrian
Analista QA

Puedo agregar que es necio de parte del Jefe y de la Lider QA hacerlos trabajar un fin de semana. Cuando no se llega, NO SE LLEGA y eso es parte del trato con el cliente, no hacer caprichoso al Product Owner con los tiempos y hay que hacerle entender que es un proceso que lleva tiempo y que ni é,l que es el que «paga», puede acelerar las cosas.

Como Tester en esas condiciones yo no firmo nada, y mientras quede claro eso no hay problema, el riesgo lo corre quien da la oren de hacer las cosas fuera de esquema. No hay ni fines de semana ni horas extra, hay una capacidad finita y estimada con anterioridad. Punto final. El ponerse firme con el «no se puede» o negociar un intermedio es parte de ser líder y es una practica para «educar» al cliente.

Si existe un departamento de Calidad debe ser respetado como tal con sus metodologías y sus tiempos.

_____

¿Tienen algún comentario por hacer?
¿Les ha sucedido algo parecido y quieren compartir también su experiencia como todos nosotros?
¿Es nuevo este tema para ti?

Deja tu comentario, piensa que mientras más información compartamos, nuestro conocimiento y experiencia aumentará y todos nos veremos beneficiados.

Muchas gracias
Gustavo
gustavo@testingbaires.com

Gus Terrera

Apasionado por el agile testing y la ia.

Deja una respuesta