¿Por qué se paga menos a los evaluadores que a los desarrolladores? Comencé mi carrera como programador de Java y pasé a las pruebas de automatización. Cuando recibo llamadas para un puesto, me dicen que es un puesto de prueba que no podemos ofrecer más de 70 – 80 $ por hora.

En un mundo ideal, para que un producto tenga éxito, se debe dar más importancia a los evaluadores y pagarles el mismo nivel (si no más) que un desarrollador.

Pero la mayoría de los clientes de las compañías de servicios (especialmente en el sector indio de TI) sienten que los evaluadores a menudo rompen la continuidad del ciclo al tratar de señalar más defectos en lugar de ayudar con el lanzamiento del producto. Nadie sería feliz si sigues señalando errores. Se vuelve irritante y redundante más allá de un punto.

Los clientes tienen bolsillos profundos y mentes superficiales. Quieren que cada entrega se realice lo más rápido posible. Pero las pruebas no se pueden hacer a toda prisa. Necesita incorporar todos los puntos de vista y todas las posibilidades. Si bien el desarrollador piensa principalmente en la línea de los requisitos y especificaciones, los evaluadores deben pensar de forma inmediata.

Digamos que hay una ventana de una semana (7 días hábiles) para entregar un producto. Tenga en cuenta que ‘entrega’ incluye tanto desarrollo como prueba. Como cliente potencial, no puede molestar a los desarrolladores porque realmente crean las cosas. Cuando paga mal a los desarrolladores o subestima sus habilidades, los desarrolladores simplemente se mudarían y unirían sus manos con su competidor. Así el cliente pierde la ventaja. Intenta mantener contentos a los desarrolladores.

Pero los probadores no tienen esta ventaja. Porque en realidad no están creando ningún valor comercial. Claro, no estoy subestimando la importancia del control de calidad, pero espero que entiendas mi punto. Nadie estaría contento si sigue señalando errores / defectos y retrasa la entrega, incluso si esos defectos son por el bien del producto a largo plazo.

Entonces, ¿a quién presionarías para que se cumpla el plazo de una semana? Sí, los probadores.

¿A quién culparías si falla la entrega? Sí, los probadores.

¿A quién pagarías mal? Sí, los probadores.

¿A quién haces un chivo expiatorio cuando hay una crisis? Sí, los probadores.

¿A quién disparas? Sí, los probadores.

Los clientes y las partes interesadas sienten que los evaluadores son una pérdida de tiempo. Por supuesto, las personas inteligentes comprenderían la importancia de las pruebas y esperarían mantener una tensión saludable entre las dos partes. Pero entonces, la mayoría del mundo se compone de idiotas que piensan solo en las ganancias y no en la calidad.

Sí, por supuesto, la mayoría de las empresas están ligeramente por debajo del pago del control de calidad en comparación con los desarrolladores. Recordamos los días en que los evaluadores de control de calidad eran tratados casi como ciudadanos de segunda clase y los desarrolladores gobernaban el mundo del software. Pero la situación está cambiando en los últimos años. Las empresas comenzaron a darse cuenta de la calidad de sus productos y comenzaron a centrarse en derivar más elementos de proceso / acción hacia la Calidad.

Los probadores que constantemente los actualizan a las tendencias actuales siempre reciben un pago bien similar al desarrollador. Pero esto simplemente no se aplica a todos. Es solo para las personas de control de calidad con una gran cantidad de conjuntos de habilidades técnicas / de dominio e incluso se les paga bien que a los desarrolladores. En la reciente demanda de roles SDET hay una clara evidencia de esto.

Los SDET también son desarrolladores. Pero desarrollan solo una característica llamada – “PRUEBA”.

Todos somos probadores ahora – Joe Colantonio – Triunfando con la asombrosa automatización de pruebas. ¡Te mostraré cómo!

En el futuro, donde haremos más pruebas de Shift a la izquierda, las pruebas no serán solo sobre el trabajo de QA. Lo que significa que el desarrollador se encargará de algunas de las actividades de control de calidad, mientras que el control de calidad no debe simplemente emular las acciones del usuario final. También deberían ser parte de todas las cosas que suceden en torno al desarrollo y las operaciones de software.

Si se desplaza hacia la izquierda, su cheque de pago se desplazará hacia arriba.

-Linkesh

Definitivamente no. Hay probadores que ganan más que desarrolladores. Desde mi experiencia personal, y como líder de prueba con 9 años y 3 meses, aquí hay algunos datos reales:

Desinación: QA Lead

Exp. De automatización: 5 años

Total exp: 9 años 3 meses

Salario: 27.5 LPA

Ubicación: Bangalore

Entonces, cuando comparo el salario con los desarrolladores con el mismo nivel de experiencia, todo el equipo de desarrollo y el gerente de desarrollo (tenían la misma experiencia mía) también ganan menos de lo que estoy ganando.

¿Estoy insultando a la comunidad de desarrolladores, * NO, no lo estoy *

mi punto aquí es: independientemente del conjunto de habilidades, aprender habilidades de negociación, subir el listón.

Solo quiero decir / sugerir a todos los evaluadores y / o incluso desarrolladores que negocien su salario al máximo con una situación de ganar-ganar. La mayoría de las veces, no pudimos negociar pensando que podríamos perder la oferta de trabajo si negocia más duro. No siempre es el caso. Si RR. HH. Ve potencial en los candidatos, definitivamente consideran ofrecer sus expectativas o con ligeras negociaciones.

* Sigue aprendiendo habilidades de negociación y nunca te conformes con menos *

Happy Testing y codificación.

Es un hecho que pocas compañías ofrecen un salario un poco menor a los ingenieros de prueba en comparación con los desarrolladores en la fase inicial de la carrera. Pero no he visto que esto siga siendo un problema por más tiempo en mi carrera. De hecho, un ingeniero de automatización calificado puede obtener mucho más salario que un desarrollador con experiencia laboral similar (años).

Ambos juegan roles críticos de punta a punta. Con las empresas que adoptan la integración continua y los enfoques de prueba continua, los probadores y desarrolladores trabajan de la mano. Además, Agile no diferencia entre los equipos de desarrollo y de prueba.

El crecimiento es variable para cada persona, ya que depende de la capacidad, la aspiración, los esfuerzos y las circunstancias. Tiene poco que ver con la rama de TI.

Los desarrolladores podrían pasar a ser gerentes, analistas de negocios, arquitectos, o podrían entrar en ventas, investigación, etc., dependiendo de su calificación, aspiración y oportunidades.

Las mismas posibilidades también existen para los evaluadores, solo en su campo. Test lead, Test manager, Business Analyst, etc., muchas posibilidades.

No forme opiniones ni tome decisiones basadas en lo que dice la gente. La mayoría de las personas no están expuestas a la industria de TI o solo a una de prueba o desarrollo. Haga su propia investigación, recopile información por su cuenta de personas bien informadas

Realmente no. Sin embargo, definitivamente verá una diferencia en términos de número de oportunidades de trabajo. Una cosa para recordar es: una carrera es un desarrollo continuo en sí mismo. Necesita nutrir sus habilidades continuamente para estar a la par con sus pares / mercados. Por ejemplo, si le gustan las Pruebas manuales, no verá un gran crecimiento profesional hasta que lo combine con un excelente conocimiento de dominio (tal vez telecomunicaciones o banca) o lo actualice con experiencia técnica como Automatización. Salesforce y SAP Testing también son campos lucrativos.

Toda la noción en torno a ‘solo está probando’ es basura: habrá personas de renombre tanto en pruebas como en desarrollo, y habrá quienes no estarían en nada de eso, sin importar cuán nicho sea la tecnología / transmisión. ¡Buena suerte!

La compensación es una parte realmente complicada, contenciosa y oculta de la cultura de la empresa. No sería justo decir que existe una ecuación simple que explica todo esto más allá del comportamiento humano y la política. No puedo hablar por la industria, pero por experiencia personal en varias compañías, proporcionaré mis observaciones anecdóticas.

Hay tres factores que influyen principalmente en las decisiones con respecto a la compensación de las compañías con las que he trabajado

• tasa de mercado
• contribución percibida
• antigüedad

No creo que la antigüedad afecte a los profesionales de control de calidad más que cualquier otra función, por lo que su tendencia observada puede tener algo que ver con los otros dos.

La tasa de mercado está determinada por la oferta y la demanda. Existe una gran oferta de mano de obra no calificada dispuesta a realizar pruebas manuales, especialmente si una empresa está lista para subcontratar. Estás hablando de probadores altamente calificados con experiencia en automatización, pero incluso la asociación de estos dos grupos puede afectar la tasa de mercado percibida para los SDET. Si un gerente de contratación incluso considera la opción de reemplazar un trabajo por otro, entonces habrá una cierta sangría de esa lógica en el paquete de compensación final.

Sin embargo, la contribución percibida es lo que creo que está perjudicando más directamente los salarios aquí. Es sencillo para un profesional de ventas decir “Cerré esta venta que lleva a $ X”. Para un ingeniero de producto, pueden decir “Construí este producto que se vendió por $ Y”. Sin embargo, para los profesionales de control de calidad, la propuesta de valor está más alejada del resultado comercial final. Como tal, es más difícil determinar el impacto comercial de este rol, lo que nubla el juicio cuando llega el momento de determinar aumentos o hacer un paquete de oferta. Además de esto , simplemente no creo que el papel esté a la altura de las expectativas. El hecho de que algo sea ​​difícil no significa que tenga un gran impacto . Mi observación final es que los profesionales de control de calidad a menudo están abrumados con la cantidad de cosas que se rompen, se rompen, podrían romperse y, como resultado, no hacen las enormes contribuciones al éxito empresarial de las que nos gusta hablar.

El control de calidad puede ser y, a veces, es vital para el éxito. Sin embargo, generalmente no lo es, y esto está reduciendo los salarios.

En mi opinión, todo se trata de negocios. Me refiero a que depende de la naturaleza de la empresa (basada en productos o servicios) para la que está trabajando.

Cuanto más ganes de tus clientes, más te pagarán.

Por lo tanto, en las empresas basadas en productos, el salario de los evaluadores es igual al salario de los desarrolladores y en las empresas basadas en servicios (Nivel 3) es menos especialmente en India.

Las compañías basadas en productos pagan más a los evaluadores porque no pueden comprometer la calidad del producto que venden. El ingreso total depende de la calidad del producto y del número de clientes satisfechos.

Las empresas basadas en servicios (Nivel 3) pagan menos porque tienen que completar su proyecto y entregar el producto al cliente. Se centran principalmente en los ingresos y poco menos en la calidad del producto que van a entregar. Especialmente a los probadores manuales se les paga menos porque la gerencia piensa que cualquiera puede hacer pruebas manuales y tienen menos demanda con un alto suministro. En este caso, las excepciones son los probadores de automatización.

La razón es que se percibe que los desarrolladores de software proporcionan más valores que los probadores.

¿Recuerdas la frase “Desarrolladores hacen, los probadores rompen”? Por supuesto, no siempre es cierto, pero dice lo que las personas perciben las pruebas de software.

Cuando se ve desde otro punto de vista, vemos que un producto puede o no ser lanzado al mercado sin probarlo. Sin embargo, si no hay un desarrollador para codificar el producto, ¿cómo se puede construir el producto (y, por supuesto, tampoco hay necesidad de un probador)

De todos modos, solía escribir una publicación de blog: 5 percepciones erróneas en las pruebas de software y, debido a estas percepciones erróneas, las pruebas de software parecen baratas

Escribo esto puramente desde una perspectiva india. En mi experiencia, los evaluadores tienen mucha menos responsabilidad que los desarrolladores. La mayoría de las organizaciones piensan que está bien no involucrar a los evaluadores en la fase de recopilación de requisitos para ninguna característica / producto. Incluso si están presentes, es principalmente una formalidad. ¿Cómo se espera que escriban buenos casos de prueba si no entienden los requisitos? Hay 2 “respuestas”:

1. Escriben casos de prueba y le piden al desarrollador que los revise. Y por revisión, me refiero a reescribir.

2. Trabajé en un equipo donde los desarrolladores escribieron casos de prueba y los entregaron a QA. Básicamente, los desarrolladores hicieron el trabajo de QA.

Hay poca o ninguna planificación realizada para los evaluadores. Ninguna estimación tampoco. Básicamente solo prueban en el orden en que las cosas son entregadas por el desarrollo.

Cuando los clientes encuentran defectos críticos, es casi un hecho que algún desarrollador pobre se enfrentará al calor para solucionarlo lo antes posible. Los evaluadores se escapan con relativa facilidad porque el tiempo de respuesta requerido no permite realizar pruebas oficiales. Con frecuencia, el desarrollador lo hace él mismo.

En general, la administración asigna mucha menos responsabilidad a los evaluadores que a los desarrolladores. Eso no significa que sean menos capaces. Se les pide que hagan menos.

Hay explicaciones filosóficas y económicas (esperaré a que otros las den). Creo que la razón más profunda es una ignorancia común sobre las pruebas de software. Las pruebas de software, la forma en que se practican comúnmente, incluso en empresas alocadas como Quora (no tengo experiencia de primera mano con Quora dev / test), se centran más en tareas como la automatización. Esto requiere menos habilidades técnicas e innovación y creatividad que los desarrolladores. Aunque todos comienzan a llorar en el momento en que usas la palabra calidad, cuando se trata de presupuestos, creo que asignarían más al desarrollo.

Voy a dejar de lado lo que creo que es la prueba de software por ahora.

Todos los trabajos tienen personas que reciben salarios altos y bajos. No hay techo cuando estás en la parte superior del grupo.

Te pagan más cuando te vuelves más.

Y su Cargo o Título no le pagan: se le paga por el valor que agregó al Equipo / Compañía.

Si su factor principal para seleccionar el trabajo es el salario, el ciclo interminable de la tolva de trabajo siempre estará ahí. Tan pronto como piense que “no me pagan bien”, comienza el proceso.

Si Software Quality Job es adecuado para nosotros, deberíamos intentar subir a la cima. Entonces ni siquiera tienes que compararte con los demás.

Si no es así y el desarrollador de software parece ser el correcto, ¿por qué no?

Pero, por favor, no comience con dinero: en un momento dado, su vida no se trata solo de dinero.

Bueno, depende de la empresa. Hay algunos MNC en los que la escala de pago es la misma para el perfil de desarrollo y prueba. Y hay algunas otras multinacionales en las que la escala de pago para el perfil de desarrollo es más alta que la prueba. Incluso en el perfil de prueba, he encontrado diferentes escalas de pago para las pruebas manuales y de automatización.

Honestamente diga que sí, hay muchas razones, pero una de las razones tontas es que todos piensan que el desarrollador desarrolla el proyecto tan difícilmente y q una persona solo prueba ese proyecto con algún escenario.

Si el probador solo hace lo mismo una y otra vez sin necesitar mucho conocimiento del producto, entonces se debe pagar menos a este probador.

Si el probador comprende el proceso de desarrollo de software y el producto en sí mismo, encuentra una mejor manera de obtener una mejor cobertura de prueba de una manera más eficiente, este probador debería recibir un pago mayor.

Y realmente, los probadores también son desarrolladores. Simplemente no escriben código para estar en el producto, sino que les indican a los codificadores que escriban el código correcto.

Yo respondería lo mismo que un probador, aunque trabajo tanto como probador manual como de automatización. El salario depende de muchos más factores, como la empresa para la que trabaja, la experiencia de dominio, la experiencia relevante, etc., que ser un probador o desarrollador. Sé que muchos buenos probadores pagaron mucho más que los desarrolladores de anuncios y viceversa.

Sobre mí, me pagan muy bien con respecto a los desarrolladores con el mismo nivel de experiencia.

Pero sí, un consejo, sin embargo, no se estanque con el papel, intente y evolucione. Como estamos en una industria que está en constante evolución, debemos seguir lo mismo.

En mi opinión, todo se trata de negocios.

Cuanto más pueda ganar para su empresa, más le pagarán. Así que, obviamente, los desarrolladores escriben la lógica comercial principal de qué empresa se le pagará a sus clientes.

Mientras que el probador también juega un papel clave para la empresa, pero si no se les proporciona ese código de lógica de negocios. Entonces, ¿cómo pueden funcionar?

Entonces, para el probador, un desarrollador es imprescindible.

Viceversa, no es cierto.

En resumen, su empresa necesita el resultado final que hará el desarrollador, para asegurarse de que el trabajo sea una prueba completa o que el probador no aparezca. Entonces, obviamente, sin el probador, el desarrollador también puede trabajar y viceversa, no es cierto.

Espero haber respondido tu pregunta.

He trabajado en pruebas de software, soporte técnico de software, documentación de software. Realmente no tengo habilidades de codificación.

A los evaluadores se les paga menos porque NO tienen que tener habilidades de codificación. Todavía es un trabajo calificado, pero los desarrolladores tienen habilidades más avanzadas. Ejecute la prueba o active el script de prueba, documente los resultados, verifique que las interfaces funcionen y publique los resultados esperados.

Cuando encontré problemas, “lo arrojé por la pared” a los desarrolladores para que lo solucionaran, y luego volví a probar el problema para ver si realmente se había solucionado.

Esto simplemente significa que los roles sobre los que te están llamando tienen muchos candidatos que se ajustan a la ley y que con gusto harían el trabajo por eso. También recibo correos electrónicos con salarios ridículos sugeridos, pero me doy cuenta de que este no es el tipo de trabajo que estoy buscando.

No tiene que corregir los errores ni asumir la responsabilidad de los diseños.

Me parece que deberías solicitar algunos trabajos de desarrollo.