• Cuando el tester es transversal

    Hoy, como en muchas cosas, uno tiene que intentar tener conocimientos de todo lo que pueda, tiene que intentar empaparse de cualquier cosa que pueda y en nuestro trabajo no podía ser menos.


    Cuando tenemos un proyecto en el que hay varios equipos y en cada equipo tenemos un tester (o varios) al final esa persona será especialista en exactamente lo que se dedica ese equipo y dejará un poco de lado el resto.

    Para evitar esto hay varias medidas que podemos tomar, una de ellas, que exista un departamento de testing en el que un grupo trabaje mano a mano indistintamente de los equipos de desarrollo, cuando llega algo para probar, lo podrá coger cualquiera de ellos.

    Este método, desde mi punto de vista tiene un pero, que la gente que pruebe será "menos" especialista en una cierta zona de la aplicación y puede no tener toda la información.

    Otra medida que se puede tomar es que cada cierto tiempo, el tester se mueva de equipo, hacer rotaciones, así no se cogerán malos hábitos, costumbres y se podrán tocar todos los palos para probar. El pero de esta "técnica" es la falta de "confianza" con el equipo, el trastorno de estar cambiando contantemente de posición y el "jet lag" que suponen estos cambios hasta que se acostumbra al tester a lo nuevo.

    Para mi la mejor solución, aunque muchas empresas sean reticentes a nivel económico, sobre todo, es que exista un tester transversal.

    Cada equipo tiene su propio tester, que probará y será un experto en esa zona, teniendo conocimientos de las otras zonas pero mínimo. Como apoyo para estos tester, existir.a un tester transversal (o varios) que irán de equipo en equipo dependiendo de las necesidades y de la carga de trabajo, apoyando a los tester "fijos" y ayudándoles en su trabajo.

    Estos tester tendrán toda la información global de la aplicación y podrán ayudar al resto sin ningún problema. Cuando acaben con ese pico de trabajo puntual, irá a otro equipo ayudando y gestionando el trabajo en base a la pila pendiente que tenga.

    De esta manera podremos tener un trabajo constante en todos los equipos de desarrollo y se podrán apoyar unos a otros para que, entre otras cosas, no existan diferencias de horarios, que unos equipos tengan menos trabajo y otros estén saturados y no estén apoyados entre si.

    Al final, cada proyecto tendrá su propia filosofía y sus propias ideas para hacer testing de la mejor manera, pero creo que estas ideas se pueden aplicar siempre a practicamente todos nuestros grupos de trabajo.
  • Libros benéficos

    En 2016 publiqué, “Aseguramiento de la Calidad”, cuyo beneficio es destinado a la Fundación Aladina, después le siguió: “Seis en 75”, destinado a la Fundación Menudos Corazones y “Asegurar la Calidad en dispositivos móviles...y no morir en el intento”, a la fundación Soñar Despierto. También he publicado una recopilación íntegra de los tres libros anteriores, llamada "Fundamentos de la calidad del software".

    Merchandising benéfico

    Desde la tienda de Cultura de Calidad se pueden adquirir diferentes artículos cuyo beneficio es destinado íntegramente a las tres fundaciones con las que colaboro actualmente: Fundación Aladina, Fundación Menudos Corazones y Fundación Soñar Despierto.

    Acciones benéficas futuras

    Esto no va a parar aquí. Mi cabeza no se está quieta, tengo muchas ideas que dar forma y convertirlas en realidad. Desde aquí, hago un llamamiento a diferentes fundaciones y ONGs para poder colaborar juntos y poder hacer cosas grandes que ayuden a personas o animales en todo el mundo. Si te apetece, ponte en contacto conmigo y hablamos.

    0
    Publicaciones
    0
    Seguidores
    0
    Visitas únicas
    0
    Me gusta