¿Por qué las pruebas de software se consideran un trabajo inferior en comparación con el desarrollador de software?

No tengo experiencia como desarrollador y no quiero comentarlo. Pero tengo ciertas habilidades fuertes en las pruebas y puedo comentarlo:

Cualquier ingeniero de pruebas tiene las siguientes responsabilidades:

• Adquiera los procesos y herramientas de control de calidad para garantizar la calidad en todos los aspectos de nuestro producto final.
• Propiedad del desarrollo y ejecución del plan de prueba para una aplicación completa que está directamente orientada al cliente.
• Defienda e impulse la adhesión a una cultura basada en prácticas de mejor calidad basada en pruebas.
• Trabaje en estrecha colaboración con los desarrolladores, el equipo de productos y otros equipos para elaborar los mejores planes de prueba y garantizar la máxima calidad de cada nueva característica / producto.
• Realice pruebas de caja en blanco y negro en la parte frontal utilizando varias herramientas de prueba.
• Anticipe las necesidades del equipo de control de calidad e identifique de manera proactiva áreas de mejora, eficiencia y nuevas herramientas para incorporar en el proceso de calidad. Liderar al equipo con máxima, integridad y sinergia.
• Escale los esfuerzos de prueba en múltiples versiones para nuevas características / productos.
• Responsabilidad de diagnosticar problemas de manera efectiva, informar defectos y proponer pruebas de regresión / estrés / rendimiento / escenario para descubrir repeticiones.
• Triaje y priorizar problemas para su resolución.
• Planifique el proceso de prueba y las estrategias a seguir.
• Creación y mantenimiento de casos de prueba.
• Creación de scripts de automatización utilizando ‘Selenium Web driver’ con Java.
• Garantizar manuales de calidad y pruebas de automatización.

Por lo tanto, si se enfoca en aprender Automatización utilizando herramientas como Selenium, hay mucho más futuro con las siguientes responsabilidades:

• Adquiera los procesos y herramientas de control de calidad para garantizar la calidad en todos los aspectos de nuestro producto final.
• Propiedad del desarrollo y ejecución del plan de prueba para una aplicación completa que está directamente orientada al cliente.
• Defienda e impulse la adhesión a una cultura basada en prácticas de mejor calidad basada en pruebas.
• Trabaje en estrecha colaboración con los desarrolladores, el equipo de productos y otros equipos para elaborar los mejores planes de prueba y garantizar la máxima calidad de cada nueva característica / producto.
• Realice pruebas de caja en blanco y negro en la parte frontal utilizando varias herramientas de prueba.
• Anticipe las necesidades del equipo de control de calidad e identifique de manera proactiva áreas de mejora, eficiencia y nuevas herramientas para incorporar en el proceso de calidad. Liderar al equipo con máxima, integridad y sinergia.
• Escale los esfuerzos de prueba en múltiples versiones para nuevas características / productos.
• Responsabilidad de diagnosticar problemas de manera efectiva, informar defectos y proponer pruebas de regresión / estrés / rendimiento / escenario para descubrir repeticiones.
• Triaje y priorizar problemas para su resolución.
• Planifique el proceso de prueba y las estrategias a seguir.
• Creación y mantenimiento de casos de prueba.
• Creación de scripts de automatización utilizando ‘Selenium Web driver’ con Java.
• Garantizar manuales de calidad y pruebas de automatización.
• Tal vez si quieres comenzar a aprender, te sugiero que consultes:

Responda a su pregunta: No, ya que el probador es único en naturaleza y el objetivo del desarrollador es diferente, pero un probador puede ser un desarrollador dentro de las pruebas (como probador de automatización)

Haga clic en UPVOTE si es útil.

todo está en la perspectiva, para algunos se considera un trabajo superior a los desarrolladores de software.

déjame explicarte por qué es inferior, (supongo que eres un probador de software) te convertiste en un probador de software porque apestas a la codificación, o si querías ingresar al carro de ingeniería de software sofisticado y la posición de prueba de software es la opción más baja, ya que no lo hiciste sabe algo más, sea cual sea la razón, tal vez sea un probador de software y se sienta inferior a otros desarrolladores de software, permítame explicar por qué se siente así, si tengo que decirlo en una línea “no agrega ningún valor al valor cadena / organización al final del día “, antes que nada no sabes lo que se supone que debes hacer como probador de software, vas a la oficina y buscas pedidos de tus gerentes de desarrolladores e intentas ganar su simpatía, estar en su buenos libros, no quieres desafiar ninguna de sus decisiones que incluyen sus malas decisiones de software, nunca dejaste que un software se volviera productivo (o en vivo) porque tenía algunos errores importantes porque tu gerente estaría muy descontento con él. con todo esto, no veo ninguna razón para que te sientas superior a los desarrolladores de software, porque no eres realmente importante para la organización o el proyecto, eres solo otro engranaje en el motor, no trabajo con este tipo de probadores de software .

mis probadores de software son profesionales en hacer que las cosas se rompan, se enorgullecen de romper el software, son probadores de software por elección, disfrutan de reírse de los errores, saben cómo el software final debería ser más que los desarrolladores o gerentes, saben su final usuario muy bien, tienen curiosidad por aprender cosas nuevas relacionadas con la mejora de sus pruebas, son buenos para encontrar errores y escupirlos a los desarrolladores y cuestionar su capacidad para escribir un buen código, si el software es malo, evitarán que la compilación entre en producción, sin compromiso, mis probadores de software son superiores a los desarrolladores de software, los cuestionan, les dicen a los desarrolladores lo que hay que hacer en la solución.

Probablemente se deba al hecho de que ser un probador de nivel de entrada no requiere tanta educación o antecedentes técnicos. PERO, puede ver en esta publicación de blog del Ministerio de Pruebas que las pruebas no son una profesión inferior, y no son solo un medio para convertirse en desarrolladores.

Probando su trayectoria profesional – Ministry of Testing

Como puede ver también en esta infografía, uno puede volverse altamente especializado en pruebas que requieren mucha experiencia técnica, ¡lo cual no debe subestimarse!

Aquí hay un gran artículo para acompañar la infografía.
La trayectoria profesional de un probador de software: una infografía

He sido probador de software durante más de una década. Fui contratado para comenzar tres departamentos de pruebas diferentes en compañías que anteriormente carecían de control de calidad. La respuesta simple es que no se considera “inferior” por varias razones. Los probadores de software generalmente tienen la última palabra sobre si un producto está listo para ser lanzado, no desarrolladores o PMs, siendo el guardián es extremadamente importante. El control de calidad existe porque algunos desarrolladores son descuidados, escriben código pobre, no se molestan en limpiar el código de espagueti y la mayoría son muy malos para probar su propio código. Con las pruebas automatizadas convirtiéndose en un estándar de la industria, los salarios de los probadores de software están mucho más cerca de los de los desarrolladores de software. Dados los recientes errores de alto perfil que han aparecido en las noticias, más empresas se están dando cuenta de que los probadores de software / ingenieros de prueba son imprescindibles, ya que aún hay menos probadores experimentados en comparación con el gran número de desarrolladores, esto lo hace, en general , es más fácil en una industria de TI competitiva conseguir trabajo porque muchas empresas necesitan probadores. Sin mencionar el hecho más importante: la mayoría de los desarrolladores están extremadamente contentos de que haya probadores de software, y si se les da la opción, preferirían tener QA en lugar de no.

Los probadores de software tienen un conjunto de habilidades analíticas superpuestas pero diferentes a las de los desarrolladores, pero de ninguna manera es “inferior”. Quizás algunas personas piensan que es “inferior”, pero si los desarrolladores de software no cometieran errores, no habría necesidad de verificadores (y hablando por experiencia, los desarrolladores de software cometen toneladas de errores).

Se requieren pocas habilidades de programación para trabajar en pruebas de software. Esto lleva a muchas personas no competitivas y no profesionales (que no tienen una mentalidad científica) a asegurar trabajos en puestos de dirección. Son estos líderes y gerentes los que representan expectativas erróneas del departamento de control de calidad y, en última instancia, hacen que el departamento de control de calidad parezca algo inferior.

Los líderes y gerentes deben comprender algunos hechos básicos sobre las pruebas como:

• La prueba nunca se completa. Puedes seguir probando indefinidamente. Se trata de cuánto riesgo quieres cubrir
• No importa cuántos probadores tenga, siempre existe la posibilidad de que se filtre algún error. Los probadores también son seres humanos. Por eso tenemos el equipo de soporte. La alta gerencia necesita ser comunicada sobre esto adecuadamente.
• Las pruebas exploratorias son mucho mejores que ejecutar los mismos casos de prueba una y otra vez
• La automatización comienza a ser cada vez más importante a medida que pasa el tiempo.
• Si a la gente le faltan errores, averigüe qué falta en el proceso actual y modifíquelo para ayudar al ingeniero. El proceso de prueba está destinado a ayudar a la prueba, no al revés.
• Los números de casos de prueba no significan nada por sí mismos. Es necesario observar la cantidad de pruebas exploratorias que se realizaron y cuántos errores se encontraron en ella. Eso da una mejor indicación de la calidad.

He trabajado en equipos de control de calidad varias veces y esa no ha sido mi experiencia.

Si está hablando de ejecutar pruebas que fueron escritas por otros, entonces sí, eso suele ser un trabajo de nivel de entrada.

En el otro extremo del espectro, tiene ingenieros de control de calidad superiores que son responsables de todo el proceso de control de calidad, desarrollando las herramientas de prueba, escribiendo planes de prueba, escribiendo pruebas, ejecutando pruebas, investigando fallas, etc.

En mi tiempo en el control de calidad, a menudo escribíamos pruebas contra API que todavía estaban en progreso y aún no se habían implementado, por lo que fuimos los primeros en probar y hacer uso de estas API. Solo cuando comienzas a usar una API realmente descubres si el diseño funciona bien o no. A menudo, brindaba retroalimentación a los autores de API sobre inconsistencias, faltan funcionalidades u otras formas de mejorar las API.

Lo mismo es cierto para la mayoría de los productos de software, los controles de calidad suelen ser los primeros en probar y utilizar un producto que no participó en el desarrollo. Eso les da una perspectiva diferente a la de los desarrolladores que están demasiado cerca del producto y a menudo no pueden ver los problemas de usabilidad que son obvios para alguien que no sabe cómo debe funcionar todo.

Además, al presentar un error, trataría de señalar el punto de falla y, si es posible, incluir la solución sugerida. El hecho de que una prueba falle no garantiza que la falla esté en el producto. La falla debe investigarse para ver si se trata de una prueba que no funciona o que se hacen suposiciones incorrectas, o si se trata de un error real en el producto. Eso requiere que comprenda la base del código del producto casi tan bien como el equipo de ingeniería.

Si su empresa tiene ingenieros de prueba que simplemente ejecutan pruebas y arrojan errores ciegamente al desarrollo sin ningún análisis, entonces no están haciendo el mejor uso del tiempo del desarrollador.

De profesión soy desarrollador de software y no estoy de acuerdo contigo.
Es solo una cuestión de percepción. QA / Testing es una de las etapas más importantes de cualquier ciclo de vida de desarrollo de software. Leí en alguna parte … más inviertes en calidad, más obtienes de tu producto … Sea dinero, confianza del usuario o hacer de tu producto una marca confiable.

¿Y solo quería saber qué es un trabajo inferior? En qué terminos ?? ¿Alguna vez has visto alguna marca confiable lanzando sus productos sin pasar por la fase de QA / Prueba? Incluso cuando la primera vez que se lanza un producto, solo la versión beta estaría disponible para usuarios cerrados, comunidad por haberlo visto por primera vez.

Tanto los desarrolladores como los probadores son perfiles diferentes que requieren un conjunto diferente y único de habilidades para hacer el trabajo. Ambos se complementan entre sí.

Tienes razón, se considera inferior como lo demuestran los ingenieros de prueba de software de menor pago que tienden a ser comparados con sus pares.

La mayoría de las personas que respondieron no parecen haber captado el “punto” de lo que este tipo pregunta …

En la organización hacia atrás esto es cierto. En mi primer trabajo, un gerente de recursos decidió que este era el caso y solo dio aumentos salariales al equipo de desarrollo. Todos protestaron y TODO el equipo de prueba, incluido yo, se fue. Perdieron a tanta gente que tuvieron que subcontratar el trabajo a una compañía a 240 millas de distancia … ¡quién me llamó para preguntar si quería trabajar allí por el doble de dinero! LoL

¿Por qué las pruebas de software se consideran un trabajo inferior en comparación con el desarrollador de software en la India?