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.
0 Comentarios