Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

QAlidad & Agilidad – parte 2

2 comments
QAlidad & Agilidad – parte 2

Open Space Madridagil sobre QA y Agilidad.

Tal y como terminaba diciendo en el post anterior , el último Track de la mañana, antes del descanso para comer trató sobre :

 Pruebas funcionales y por donde empezar a automatizar.

 De aqui destacaría :

            – Las pruebas funcionales son las más caras de realizar.

            – Tdd es lo más barato, pero empezar con ello cuesta tiempo y mentalización de los desarrolladores para diseñar con este concepto su código.

            – No todo el mundo tiene el código preparado para poder hacer Tdd , por tanto las pruebas más sencillas de realizar son las funcionales. No obstante son caras por su continua variabilidad.

             El sw cambia frecuentemente.

            – Automatizar con Ides de pruebas de regresión tipo Selenium, está bien , pero require un gran esfuerzo para tener los scripts de pruebas actualizados.

            – Las pruebas funcionales manuales son necesarias en muchos casos y aqui el equipo de QA es clave para lograr una buena cobertura de pruebas.

            – Si vas a hacer pruebas funcionales automáticas, selecciona el core de tu sistema y prepara la suite de pruebas adecuada. Asegurate que eso siempre pasa las pruebas y si detectas algun fallo en el informe de pruebas, que puede ser falso positivo, eso pruebalo a mano y  ya lo ajustarás luego.

  La mañana fue intensa, nos fuimos a comer y a la vuelta, como se nos hizo tarde al tardar más de la cuenta las raciones y tapas que nos zampamos, decidimos acortar los tracks y se realizaron los dos primeros de la tarde ( cada uno en su zona del local) y para los últimos se hicieron tres tracks en paralelo. Asi no se dejó nada fuera y todos pudimos elegir a cual nos quedábamos como cierre de la jornada.

 El primer track de la tarde fue:

  QA en un Sprint.

 Fue super interesante y aqui pudimos conocer como los chicos de Odigeo , con Juanma Gomez como maestro de ceremonias realizan sus políticas de QA en los Sprints, y también pudimos conocer alguna idea sobre  QA en Sprints de 15 días + fase de  OutSprint Testing, del banco que hace Fresh Banking .

 Muy ilustrativo conocer como otros están aplicando las políticas de QA en sus Sprint.

 Y el último track en el que participé, fue el que yo propuse 😉 , por título :

 QA en Mantenimiento de SW heredado.

 Para la sesión , a aquellos que se apuntaron ( agradezco su participación porque era la última del día y el cansancio ya se hacía sentir ) , se me ocurrió trabajarlo como una dinámica de equipo en la que  bajo la premisa :

 ” Somos una empresa de SW a la que se nos ha encargado hacernos cargo de un sistema de información que no hemos construido y ahora tenemos que mantener y evolucionar” 

 Dividimos en dos grupos a  los participantes , uno en representación de la Gerencia de dicha empresa y otro en representación  del equipo de desarrollo que sería el responsable de ese mantenimiento.

 Con un time box de 15 minutos , aprox, cada grupo tenía que identificar  sus “preocupaciones”  de cara a afrontar esa nueva responsabilidad y escribiéndolas en post-it se fueron pegando en la pared para por último ordenarlas por nivel de “preocupación” y que por tanto tenían que ser resueltas en primer lugar.

 El equipo que representaba a los Developpers,  tenía como principales  preocupaciones : el nivel de documentación del sistema, la arquitectura del sistema, el número de errores heredados, la comunicación con el equipo que lo desarrolló , qué métricas de mantenibilidad podían obtener del código heredado… mientras que el equipo Gestor, tenía como preocupación en primer lugar : el retorno de inversión del proyecto, el equipo necesario para poder llevarlo a cabo, la tasa de errores transferidos, información histórica para poder gestionar  y documentación e indicadores y métricas entre otros.

 Todas esas cuestiones afectarán a la calidad de “la herencia” del código recibido y condicionarán el trabajo futuro de los que lo tienen que mantener, luego hay que preocuparse de disponer de toda esa información y atender las preocupaciones que surgieron de la dinámica. Lo que quedó patente es que los Developpers se sentían más preocupados que los gestores. De hecho ellos eran los que  veían el aluvión de problemas que les vendrían si no conseguían los niveles mínimos de conocimiento para poder hacer su trabajo con la calidad que se les requeriría a partir de la firma del contrato.

 Y con eso,  y tras el cierre del Open Space con una ronda de comentarios sobre la  experiencia y lo que nos llevábamos cada uno de allí , acabó el día . Sin duda recomendable y muy interesante y a estar atentos al siguiente.

 

 

  1. Buenas Pepe!
    Está guay tu resumen. Muchas gracias por haber venido y, sobre todo, participado 😀 Sólo me gustaría hacer una mención a los chicos de QA de Odigeo (Pedro y Patri) que expusieron nuestro modelo mucho mejor de lo que lo habría contado yo y de lo que ellos son parte muy activa.
    Por otro lado, me encantó conocerte, que te sigo desde hace tiempo y por fin te pongo cara. En breve anunciaremos más eventos seguro, así que espero que tengamos oportunidad de compartir más ratos como este.
    Un abrazo enorme!

    • Pepe Vázquez says:

      Gracias Juanma, igualmente para mi , te he desvirtualizado :).
      Respecto a lo de Patri y Pedro, pueden estar muy orgullosos de que haya alguien que les reconocé el trabajo. Grande !!! Yo no recordaba sus nombres, pero ya me di cuenta que los que sabían eran ellos, jejeje.

      Hasta pronto. A ver si puedo ir a algún Coaching dojo, que he leído por los grupos maravillas.
      Ciao!!!

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *


*