Hace aproximadamente dos meses NexoQA (empresa que organiza ExpoQA) con SoftQaNetwork y ATI (Asociación de Técnicos Informáticos) lanzaron una encuesta sobre la situación salarial de los testers en España.

La encuesta estuvo abierta del 1 de Febrero al 15 de Marzo en la que participaron 86 personas del mundo de la calidad de software y el testing. Algunos datos curiosos, es que existe un buen porcentaje de mujeres en el mundo del testing (cosa no muy común en la ingeniería de software). También otro dato importante es la edad de los encuestados ya que todos los encuestados se encuentran entre los 20 y los 40 años por lo que se nota que es una disciplina muy joven y con mucho camino para madurar.

Unos números que me han gustado mucho, es que un 86 % de los encuestados tienen estudios superiores, por lo que se muestra que es una disciplina que necesita una base importante, y que no puede hacer cualquiera como piensan algunas personas. Si que es cierto que no es un requisito indispensable tener una carrera técnica o estudios superiores, pero si que ayuda bastante.

Sobre el tema de salarios prefiero no opinar… la mayoría de gente se siente peor pagado que la gente de desarrollo, aunque yo opino todo lo contrario. Hay muchos desarrolladores que están cobrando mucho menos que nosotros. En parte creo que es ratio oferta / demanda. Desarrolladores hay muchos, mientras que testers hay pocos, por lo que la cotización de un tester generalmente ha crecido mucho más en relación con el desarrollo.

Podéis ver el informe completo en la página de ExpoQA.

Tagged with:  

Esta mañana se ha creado la lista de distribución de correo de la asociación TestQA mediante Google Groups.

La lista es totalmente abierta y puede apuntarse cualquier persona que este interesado en el testing y en la calidad de software y que quiera estar enterado de todos los eventos que se realizan desde la asociación, al igual que seguir comentando y debatiendo sobre los diferentes temas.

Porque hemos utilizado Google Groups? Básicamente porque necesitábamos un sistema de comunicación que fuera rápido y pudiera llegar a todos el mundo. A parte nos interesaba un sistema en el que pudieramos debatir y hablar sobre temas de testing y calidad de software de forma flexible y accesible a todo el mundo. De esta manera podemos crear un espacio de comunicación que no sea dependiente de las plataformas como linkedin y que puede llegar directamente al correo de los miembros del grupo.

Esperemos que os guste la idea, y que se utilice de forma activa por todos los usuarios para seguir hablando sobre testing y seguir aprendiendo entre todos de esta disciplina.

Para apuntarse solo has de ir a la página del Google Groups de TestQA

Happy testing!

 

Ventanas rotas

On 1 marzo, 2012, in Consejos, Prácticas desarrollo, Sin categoría, by twiindan

Hay una teoría que nacio en los años 1980 por parte de James Q. Wilson y George Kelling que se denomino la teoria de las ventanas rotas con un simple principio:

“Consideren un edificio con una ventana rota. Si la ventana no se repara, los vándalos tenderán a romper unas cuantas ventanas más. Finalmente, quizás hasta irrumpan en el edificio, y si está abandonado, es posible que sea ocupado por ellos o que prendan fuegos adentro.

O consideren una acera o banqueta. Se acumula algo de basura. Pronto, más basura se va acumulando. Eventualmente, la gente comienza a dejar bolsas de basura de restaurantes de comida rápida o a asaltar coches.

Esto responde a una curiosa conducta humana que dice que si algo esta mal ¿ Porque tengo que hacerla yo bien?

Esto es fácilmente aplicable al código de desarrollo y incluso a nuestros diseños de tests o los tests automáticos. Cuantas veces no habremos a alguien quejarse de que ha cogido legacy code que es un desastre y que es muy complicado lidiar con ello. O alguien que haya visto unos tests que de repente fallan y grita a los 4 vientos que están mal realizados o son un desastre?

Ahora preguntaros vosotros cuantas veces hemos hecho algo, hemos pensado que se podría hacer de otra forma mejor pero nos ha dado pereza realizarlo? En ese momento estamos dejando una ventana rota y que puede provocar lo que llamamos deuda técnica (tanto para desarrollo como para test). Cuantas ventanas rotas estamos creando que pueden tener una repercusión en el futuro? Y lo peor de todo cuantas las dejamos aun con la conciencia de que se podrían arreglar? No es más fácil arreglar las cosas cuando son pequeñas que cuando se han acumulado? Esta acumulación suele ser muy peligrosa, ya que después de mucho tiempo cuando se hace inmanejable es cuando alguien piensa cuanto tiempo se tardaría en arreglarlo y te das cuenta que es un tiempo inasumible.

El siguiente punto es… cuantas ventanas rotas hemos arreglado? Como hemos comentado antes es muy sencillo quejarse de que algo esta mal hecho y se pudiera hacer mejor, pero generalmente cuando te encuentras algo mal hecho (por ti o por quien sea), por algún extraño motivo se sigue realizando igual de mal o peor. No estoy diciendo de que digas “a partir de hoy durante 10 días solo voy a arreglar ventanas”, si no que cuando veamos algo que esta mal realizado, y debamos hacer una modificación en esa parte, la arreglemos. Alguien tiene que arreglarlo para que siga siendo mantenible… entonces hay que preguntarse… ¿Porque no yo? Seguro que a la larga, tu y tu equipo lo agradece… no hay nada mejor que predicar con el ejemplo.

 
Para este último caso hay que seguir la regla de los Boy Scouts, “Deje la zona del campamento, incluso más limpia que como  la encontró” o la que solemos encontrar en muchos baños “Deje el baño como le hubiera gustado encontrarlo”. Es decir, si tenemos que tocar algo que hemos realizado anteriormente nosotros o otra persona, en lugar de quejarnos, mejoremoslo, ya que seguro que a largo plazo lo agradeceremos.

 

Tagged with: