• El peligro de no dimensionar bien el equipo de testing

    Al pensar en el testing como un apoyo al equipo de desarrollo, nos enfrentamos a que no se suele dimensionar bien a las personas que van a realizar las pruebas.


    En la mayoría de los casos, lo que sucede es que nos solemos quedar cortos en el equipo, ya que se le da prioridad al desarrollo antes que a las pruebas y después ocurre lo de siempre, que cuando el cliente da la colleja, nos pensamos mejor esto y damos prioridad a la Calidad antes que a la Cantidad.

    Cuando nos quedamos cortos en el equipo de testing suele ocurrir que el trabajo nos desborda y que no podemos hacer las pruebas todo lo bien que debemos y, habitualmente, dejamos de lado automatizaciones y cosas menos prioritarias que si que podemos dar importancia si el número de personas del equipo es el correcto.

    Un equipo corto de personal de testing es un gran cuello de botella, porque no soltará el trabajo tan rápido como se desea, siempre y cuando se lo permitan, porque lo que sucederá, como casi siempre, es que la entrega sea en una fecha determinada y se acabe probando rápido y con prisas.

    Al contrario, si el equipo está sobredimensionados, tenemos el problema de gente parada y de que, en la mayoría de los casos nos pisaremos unos a otros. Un equipo de testing más amplio de lo necesario dará la sensación de que su trabajo no es todo lo importante que es y condicionará mucho la idea de realizar pruebas en el futuro.

    En algunos casos, durante los años que llevo trabajando, he visto como el equipo en el que trabajaba estaba escaso de personal y nos matábamos a trabajar, mientras que otros equipos estaban más que dimensaionados y daban la sensación de hacer más bien poco. Este problema es más habitual de lo que parece, ya que, el tester está infravalorado y se piensa que cualquiera puede hacer su trabajo, así que se paga poco y la especialización es escasa, aunque el músculo de pruebas será muy grande.

    Hace unos años tuvimos una mala época cuando se decidía externalizar todas las pruebas a países como la India, que cobraban más bien poco, pero el resultado no era del todo satisfactorio. Al final, es como todo, una especialización se paga y sino no se conseguirán los resultados esperados.

    A la hora de embarcaros en un proyecto siempre tener en cuenta ciertas reglas que se dan en algunas metodología, como que cada cuatro desarrolladores tengamos un tester, cosa que me parece exagerada. Habitualmente, lo ideal es que por cada seis o siete desarrolladores tengamos un tester. Ese número nos resultará muy cómodo a la hora de trabajar con soltura y sin embotellamientos.
  • 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