Sumario
Debate iniciado en el grupo de discusión TESTING & QA,
comunidad de testers dentro de la red LinkedIn, para discutir si hay
relación entre la experiencia de un tester y su productividad. Título
del Debate: Salarios testing y QA
Salarios
El siguiente contenido es parte de un debate que se ha generado desde el grupo de discusión en LinkedIn : TESTING & QA, te invito a que participes de él y si aún no eres miembro, solo tienes que unirte.
Me gustaria sabe cual es la opinion
acerca de su sueldo, pero no a modo de encuesta para saber cuanto gana
cada uno. Lo que me interesa es saber si consideran justo su sueldo en
base a las tareas que realizan y a los compromisos que tienen. Por
ejemplo, yo gano como tester con la cantidad de años de experiencia que
tengo, lo mismo que gana el promedio ( según encuestas ), de todas
maneras creo que el trabajo podria estar desvalorizado en el sentido de
que cuando algo falle a los primeros que van a apuntar es a nosotros (
teniendo en cuenta como ya se debatio que un sistema nunca esta excento
de errores ). Sin embargo otros puestos tienen salarios mas altos. ¿ En
base a que podemos darle valor a nuestras tareas ?
Comentario 1
Qué buen debate que iniciaste Diego, y espero que otros miembros participen dejando sus comentarios, tal como ha impactado el debate referido al “Bug en Producción y la respuesta a darle al QA Manager”.
Qué buen debate que iniciaste Diego, y espero que otros miembros participen dejando sus comentarios, tal como ha impactado el debate referido al “Bug en Producción y la respuesta a darle al QA Manager”.
Bien, al punto entonces. Hace un tiempo
elaboré una encuesta referida al tema pero sobre la base de un rango de
montos de acuerdo con el perfil técnico, en este caso lo estas
planteando desde otro punto de vista, no menos interesante.
Si veo para atrás un poco, desde que
abrí este grupo y me puse a ‘trabajar’ en él, difundiendo los debates y
lanzando distintas acciones, nuestra actividad ha crecido mucho.
Me cabe a veces una pregunta, o creció
realmente la actividad del software testing (y cada vez es mayor la
demanda, aunque en algunas partes dicen que nó) y/o no existía un canal
de comunicación en español para permitir esta participación que aquí se
ha dado.
El valor de nuestras tareas diarias,
esta en relación directa con cuán profesionales somos en el desempeño de
nuestra función, y atado a ésto, se encuentra el salario, aunque muchas
veces no se pague como debiera.
No por nada hay períodos en donde hay
muchas rotaciones entre empresas, porque es lógico que así sea, de hecho
a mi me pasa en lo personal.
Hasta donde puedo ver, y consultándolo
con otros pares, todos (quien más quien menos) actualmente estamos
manejando muchas tareas a la vez y por ende, el compromiso aumenta.
No siempre, ésto se recompensa
monetariamente (porque no se vé, no se muestra, no se puede) y así como
surgen variantes de ‘pago’ intentando satisfacernos lo más posible:
homeworking, flexibilidad horaria, sala de relax, sala de juegos,
tickets de descuentos, % pagos para algún curso, descuentos en
universidades, capacitaciones internas, regalos empresariales, otros etc
etc etc.
Hasta hace un tiempo atrás, estábamos
ganando muchísimo menos que un desarrollador, en cambio de un tiempo a
esta parte y para ciertas actividades, esta cuestión se está comenzando a
equiparar.
También mucho depende del lugar que le
dé la empresa al QA/QC dentro de su negocio, dentro de su portfolio de
servicios, dentro de sus estrategias y presupuesto anual.
Comentario 2
Yo pienso que habria que analizar el salario en relacion al valor agregado que se le da a los sistemas. Si un sistema tiene trabajando a 10 programadores durante un año, el precio final tendra en cuenta ese trabajo acumulado. Con los programadores es mas facil sacar cuentas porque ellos trabajan y producen algo tangible ( por decirlo de alguna manera ). Tal vez nuestro salario pueda hacerse valer en cuanto a los costos de produccion que reducimos.
Me interesaria averiguar dentro de otros tipos de trabajo que requieren un proceso de produccion, cual es la relacion de salario entre los trabajadores que se encargan de la produccion en si misma y la de los que se encargan de hacer un test de calidad. Por otro lado aca puede ser el debate mas amplio porque la calidad como concepto general incluye otras cosas mas que el testeo de un producto
Yo pienso que habria que analizar el salario en relacion al valor agregado que se le da a los sistemas. Si un sistema tiene trabajando a 10 programadores durante un año, el precio final tendra en cuenta ese trabajo acumulado. Con los programadores es mas facil sacar cuentas porque ellos trabajan y producen algo tangible ( por decirlo de alguna manera ). Tal vez nuestro salario pueda hacerse valer en cuanto a los costos de produccion que reducimos.
Me interesaria averiguar dentro de otros tipos de trabajo que requieren un proceso de produccion, cual es la relacion de salario entre los trabajadores que se encargan de la produccion en si misma y la de los que se encargan de hacer un test de calidad. Por otro lado aca puede ser el debate mas amplio porque la calidad como concepto general incluye otras cosas mas que el testeo de un producto
Comentario 3
Diego, es un tema mas que interesante. Pero que esta muy lejos de estar resuelto en cualquiera de los sectores del industria del Software. Antiguamente el testing era una area de iniciacion en la industria ( de aprendizaje y conocimiento del sistema en particular). Con el paso del tiempo se transformo en una area de conocimientos especifico ( que necesita de personal calificado y certificado para que se desempeñe en el). Esto hace que esta tarea se valorice. Tambien la automatizacion hace que esta tarea sea “menos bruta”, menor cantidad de horas hombre…..
Respecto de que se apunte siempre al tester y que por esa responsabilidad esta desvalorizado, es relativo. Cuando se analiza un BUG, lo menos jugoso es entender por que el testing no lo detecto, ya que salvo que en el testeo se hayan omitidos pruebas o el tester haya evaluado mal el resultado. Lo mismo viene arrastrado de etapas previas de proyecto. Lo importante es llegar al origen del verdadero problema ( el BUG -Problema del proyecto) y no del falso problema ( por que el testing no lo detecto – Problema del responsable de testing/QA).-
En mi experiencia muchos de los BUG tiene su origen en las etapas primeras de los proyectos.
Diego, es un tema mas que interesante. Pero que esta muy lejos de estar resuelto en cualquiera de los sectores del industria del Software. Antiguamente el testing era una area de iniciacion en la industria ( de aprendizaje y conocimiento del sistema en particular). Con el paso del tiempo se transformo en una area de conocimientos especifico ( que necesita de personal calificado y certificado para que se desempeñe en el). Esto hace que esta tarea se valorice. Tambien la automatizacion hace que esta tarea sea “menos bruta”, menor cantidad de horas hombre…..
Respecto de que se apunte siempre al tester y que por esa responsabilidad esta desvalorizado, es relativo. Cuando se analiza un BUG, lo menos jugoso es entender por que el testing no lo detecto, ya que salvo que en el testeo se hayan omitidos pruebas o el tester haya evaluado mal el resultado. Lo mismo viene arrastrado de etapas previas de proyecto. Lo importante es llegar al origen del verdadero problema ( el BUG -Problema del proyecto) y no del falso problema ( por que el testing no lo detecto – Problema del responsable de testing/QA).-
En mi experiencia muchos de los BUG tiene su origen en las etapas primeras de los proyectos.
Comentario 4
Diego, me quedó dando vueltas una frase que pusiste:
“…Con los programadores es mas facil sacar cuentas porque ellos trabajan y producen algo tangible ( por decirlo de alguna manera )…”
Diego, me quedó dando vueltas una frase que pusiste:
“…Con los programadores es mas facil sacar cuentas porque ellos trabajan y producen algo tangible ( por decirlo de alguna manera )…”
En realidad, nosotros los Testers
también generamos/producimos entregables durante el proceso de pruebas, y
una muy buena cantidad dependiendo de la metodología que se haya
elegido y de las herramientas con las cuales uno trabaje.
Esta producción también da cuentas de
nuestra valor dentro del ciclo de vida de desarollo de software y por
ende, puede y debe cuantificarse para luego llevarlo a números concretos
que demuestren la utilidad y los beneficios de nuestra actividad.
Todos estos datos más alguna
recopilación de resultados anteriores, tendencias, estadísticas, mejores
prácticas, casos de éxito, permiten que los comerciales junto con el
asesoramiento de algún técnico como nosotros, puede vender el servicio
de software testing fuera y/o dentro de la empresa.
De ahí en más, cómo se reparten las
ganancias obtenidas, es ‘harina de otro costal’, ya que aquí intervienen
políticas internas, políticas de distribución, recursos humanos,
gerencia del área, comparativos en el mercado, objetivos conseguidos y
bonus asociados.
En fin, lo cierto es que hoy por hoy,
nosotros podemos demostrar de muchas formas las ‘huellas’ que vamos
dejando por el camino y cuánto es que valemos.
Después dependerá de cada uno hacerse valer más o menos, dependiendo de las circunstancias del momento.
Otro gran punto a tratar para otro
debate, es que no tenemos un GREMIO que nos respalde, distinto es el
caso para otras actividades que sí lo tienen.
………………………………………………………………………………………………….
Si quieres participar del debate y aún
no eres miembros, te invito a que te unas a nuestra comunidad de
software testers de habla hispana. Muchas gracias ! Te esperamos.
http://testingbaires.com/debate-salarios-testing-y-qa/
No hay comentarios.:
Publicar un comentario