Estoy más fresco trabajando como QA durante los últimos 10 meses, haciendo pruebas manuales y de automatización. ¿Debería considerar mudarme a Dev para mejores oportunidades de carrera?

Answer 1

Hoy en día, la tecnología es lo que importa en la carrera profesional de TI. Créalo a medida que pasan los días, apenas hay preguntas en la entrevista o en el día a la tarea que involucren tareas no técnicas, incluso para los evaluadores. QA es difícil entonces DEV. El desarrollo depende de las habilidades y pueden ser pacíficos con su mundo de codificación que solo es propenso a la fecha límite a veces en la codificación. La gran ventaja de los desarrolladores en los primeros 5 años es que el aprendizaje es mayor y una vez que adquieren la habilidad, el cambio de trabajo es fácil y también en el sitio. La única desventaja es que los desarrolladores tienen más volumen en comparación con los evaluadores, por lo tanto, el alcance del crecimiento es difícil en comparación con el control de calidad. De todos modos, te mostraré lo que es ser un QA toda la vida y puedes decidir según lo que he compartido, ya sea DEV o QA.

Si eres QA transmitir debajo de la esencia:

Pros:

1. Obtenga todos los módulos de aplicación y, por lo tanto, esté más expuesto al conocimiento de la aplicación en profundidad.
2. El papel de la comunicación es más importante en el control de calidad, que es la vida y la carrera. Comenzando desde la clasificación de errores hasta Dev y el estado del proyecto a las partes interesadas por correo o llamada.
3. Más versátil a medida que interactúa con colegas, junior, senior, QA MANAGER, gerente de proyectos, clientes y desarrolladores.
4. El comando sobre la habilidad de Business Analyst está en ventaja.
5. La exposición al control de calidad es más que DEV dentro de la organización y el proyecto.

Contras:

1. Conseguir un trabajo es difícil ya que la proporción del probador de desarrollo es 1: 3 y el rol difiere según la organización y el proyecto.
2. Siempre existe la sensación y el hecho de que QA es solo un rol de soporte y no un rol central.
3. La habilidad y el proceso varían de proyecto a proyecto y de organización a organización.
4. Siempre se ofende por Dev, el error es y Dev intentará lo mejor para defenderse. Un error siempre es negativo para la entrega y el proyecto, y toda la gerencia puede parecer un enemigo.
5. Necesidad de satisfacer al líder de prueba, al gerente de control de calidad, al gerente de proyecto, al cliente más a los seniors, al junior en equipo.
6. El control de calidad siempre se considera técnicamente inferior al desarrollo. Técnico es el núcleo de un software y proyecto.
7. QA es el punto final y el guardián de un proyecto, por lo tanto, debemos hacernos todas las preguntas, en algún momento el papel de un PM, la entrega nos llega.
8. La posibilidad de la política es más en QA STREAM. Si hace preguntas, PM lo golpeará y si no, el administrador de control de calidad que está informando lo golpeará.
9. Los primeros cinco años son cruciales, pero su aprendizaje depende de la organización, el gerente y el proyecto. Hay muchas posibilidades de no ser progresivo en el aprendizaje debido a que la tarea de prueba manual es mayor.
10. Dev tendrá preguntas sobre codificación y temas relacionados en la entrevista, pero se le pedirá QA sobre DB, lenguaje de programación, servicios web y herramientas, UI selenio / codificado y herramientas como testNG, su arquitectura de productos, etc.

Answer 2

Esto podría ayudarlo a resolver el problema.

Los siguientes son algunos de los mitos que están en la mente de los profesionales de TI de nivel principiante:

Mito n. ° 1: Sin aplicación de conocimientos de ingeniería

Mito # 2: alcance limitado para el aprendizaje

Mito # 3: crédito no otorgado a los evaluadores por el producto de software final

Mito # 4: el pago para desarrolladores es más alto que los probadores

Ninguno de los cuales es cierto.

Mito n. ° 1: no se aplican los conocimientos de ingeniería

• Muchas veces, nosotros (graduados en informática especialmente) sentimos una sensación de decepción si el primer proyecto de nuestro primer trabajo es un proyecto de prueba. Esto es porque; El plan de estudios de ingeniería de software no incluye la disciplina de prueba de software . Por lo tanto, no estamos preparados para percibir que los temas que no sean de desarrollo, DB o red tienen algo que contribuir a la producción de software. Es natural sentirse engañado.
• Sin embargo, aunque no es típico ni obligatorio que los evaluadores tengan una comprensión profunda de los lenguajes de programación, esta tendencia está cambiando y los evaluadores con habilidades de programación son altamente valorados . Podemos encontrarlo por nosotros mismos si persistimos un poco más mientras tratamos de aprender todo lo que hay que saber sobre el campo de control de calidad. Este es uno de los lugares donde “nuestra paciencia será recompensada”.
• También es interesante que a los evaluadores se nos pague por no creer en un producto . Nada malicioso, por supuesto, nuestra intención es encontrar áreas problemáticas antes de que lo hagan los usuarios, lo que se puede lograr solo cuando conocemos al máximo las complejidades del producto de software. Si esto no es una aplicación de conocimiento, entonces ¿qué es?
• El siguiente paso para encontrar deficiencias con el software es profundizar un poco más. Análisis de causa raíz : esto significa que no solo informamos un problema, sino que analizamos el problema aplicando el conocimiento obtenido de nuestras experiencias y descubrimos la posible razón del problema. Este es el valor agregado que los probadores deberían aspirar a lograr.

Mito # 2: alcance limitado para el aprendizaje

• La prueba no es una actividad fortuita. Necesita mucha planificación, estrategias, comprensión de la tecnología, gestión del tiempo y también los aspectos no tan obvios, como la comprensión de la facilidad de uso del software, la relevancia del mercado, el rendimiento, etc. La singularidad es que un probador tiene una visión de 360 ​​grados del software desde todos los ángulos , por lo tanto, la experiencia en el dominio del conocimiento, la experiencia en las mejores prácticas en el proceso de desarrollo de software y los conocimientos técnicos son algunas de las áreas adicionales en las que tendremos un buen control.
• El aprendizaje continuo es la clave del éxito en cualquier campo . También es cierto para las pruebas. Podríamos elegir avanzar hacia el rendimiento, la automatización, la seguridad, la base de datos o cualquier otro método de prueba que sea mucho más técnico. O crecemos en nuestras carreras como analistas de negocios, escritores técnicos, a veces gerentes de proyectos, etc. debido a nuestro proceso, gestión y orientación comercial.
• Una parte importante de nuestra descripción de trabajo es corresponder con los otros equipos del proyecto, presentar / facilitar varias reuniones y crear documentos / informes de proceso, etc. Esta es una maravillosa oportunidad para comunicarse verbalmente , en forma de escritura y presentación de información de manera efectiva. conducta. Ahora, ¿quién puede decir no a una mejor comunicación?

Mito n. ° 3: el probador no obtiene crédito por el producto de software final

• Por el contrario, la opinión del equipo de prueba sobre si un producto se lanza o no es final . Llegamos a jugar a ser Dios en este caso. ¿Deberíamos pedir más?
• También tenemos una oportunidad única para sugerir cambios / mejoras para mejorar el producto . Esto se debe a que, según nosotros, “un requisito / mejora faltante también es un defecto”.
• De hecho, no hay prejuicios en la industria contra ningún equipo que contribuya positivamente a un producto de software. Nuestros esfuerzos no pasan desapercibidos y pensar que lo harían es simplemente mezquino.

Mito # 4: a los desarrolladores se les paga más que a los evaluadores

• No es cierto del todo.
• Todos los asociados de nivel de entrada reciben el mismo pago (independientemente del equipo al que pertenezcan).
• Avanzando más en su carrera, el pago depende de factores como: su pago anterior, su experiencia en el campo relevante, las expectativas del nuevo puesto, la situación financiera del nuevo empleador, la demanda actual del mercado, etc .; no en la rama de TI para la que trabaja.

Fuente – Internet

Answer 3

En el nuevo mundo digital, las pruebas son cada vez más técnicas. Los trabajos de prueba futuros serán para personas que puedan programar. Simplemente saber cómo usar las herramientas de automatización no hará el corte. En muchas organizaciones, a los evaluadores se les llama Ingenieros de Software en Prueba (SDET) para resaltar claramente que esperan que los evaluadores conozcan la programación y las secuencias de comandos.

Answer 4

Si tiene un fuerte dominio de la codificación, puede pasar al desarrollo, pero, francamente, no se trata de ser QA o Developer, sino de lo que le apasiona.

En lo que respecta a las pruebas, un QA también tiene oportunidades igualmente buenas y una trayectoria profesional como desarrollador. Además, el papel de QA se está transformando en QE: eso significa que, a diferencia de la práctica tradicional donde el QA estuvo involucrado más tarde en el SDLC, ahora el QA necesita involucrarse directamente desde la fase de requisitos. Se está produciendo un cambio hacia la izquierda donde un QA tiene que codificar incluso antes de que la compilación esté lista: TDD, crear maquetas, automatizar scripts, productos de demostración, etc.

Entonces, busca lo que te fascina y sumérgete en eso. Si amas tu trabajo, no necesitas trabajar.

Answer 5

Realmente no. Las oportunidades para el control de calidad siempre estarán presentes en todas las organizaciones.

Hoy, en los requisitos de trabajo para un control de calidad, el enfoque se centra en la automatización, ya sea QTP o SELENIUM.

Si un probador manual tiene experiencia, la automatización práctica tendrá muchas oportunidades.

Answer 6

Te sugiero que comiences a aprender el lenguaje de programación y apuestes por la automatización. Te llevará un poco más adelante en la carrera. Obtendrá un buen paquete en comparación con los probadores manuales.

Porque puede ser difícil comenzar desde cero. Si buscas un rol de desarrollador ahora, podrías desperdiciar tu experiencia en lo que has ganado hasta ahora. Las pruebas manuales con automatización serán una ventaja adicional para usted.

Aprenda la automatización usted mismo desde mi blog y solicíteme si necesita más información:

http: //aroraglobalservices.blogs …
http://globalsqa.com

Answer 7

Depende de su propio interés, seguro que el desarrollador tiene más poder y el control de calidad se considera un trabajo inferior. El desarrollo le dará una carrera y respeto como persona técnica competente.