Como ingeniero informático, ¿ser asignado a pruebas es malo para mi carrera? [cerrado]

Mi empresa me contrató para el puesto de desarrollador. Sin embargo, como no tienen un proyecto, me trasladaron a Pruebas.

¿Es esto un mal movimiento para mi carrera?

"Prueba" es muy amplio. Por favor sé más específico.
Si bien ha obtenido algunas respuestas, sería útil saber si se trata de una transferencia permanente, temporal hasta que el proyecto X comience o esté listo para usted, hasta que algún proyecto desconocido tenga una necesidad, hasta que algún proyecto desconocido aparezca del cielo, hasta que descubran qué hacer contigo. En cualquier caso, demostrar que es muy bueno en su trabajo, sin importar dónde se le asigne, tenderá a llevarlo mucho más rápido a los puestos que desea. Si vas al equipo de prueba y no están encantados contigo, ¿crees que un proyecto que necesita un desarrollador de nivel inferior te va a querer?
También agregaré que las pruebas son parte del desarrollo de software. Por lo tanto, contratarlo para el puesto de desarrollador y asignarlo para que realice pruebas aún lo mantiene en el puesto de desarrollador. Me di cuenta de que tienes un BScE. Probar con frecuencia es diferente en el mundo integrado. Por lo general, automatiza las pruebas hablando con varios dispositivos de hardware (por ejemplo, Logic Analyzer, Spectrum Analyzer, Protocol Analyzer, etc.). Así que puede que no sea tan aburrido como suena inicialmente. Si puede hacer algo "más" de lo que esperan, entonces sería increíble hablar de esto en futuras entrevistas de trabajo.
Esto es demasiado amplio. Sin embargo, los ingenieros necesitan probar. No veo reparos aquí
Microsoft tiene la posición de SDET, Ingeniero de Desarrollo de Software en Prueba. Considérese un SDET.
En su forma actual, esta pregunta es demasiado amplia y discutible. Si agrega más información (en respuesta a los comentarios anteriores) y la enfoca más sobre cómo evaluar el efecto del cambio en su carrera (no "qué debo hacer", sino "cómo evalúo"), podemos mirar en la reapertura. Gracias.

Respuestas (6)

No, conseguir otra habilidad en tu currículum no está mal. nunca lo es La prueba es una parte importante del proceso de desarrollo de software e incluso como programador, conocer estas habilidades le ayudará.

Si resulta que está atrapado como probador durante un período prolongado cuando realmente quiere programar, entonces debe hablar con su jefe. Si ambos están de acuerdo en que esta es una situación a corto plazo, acéptenla y asegúrese de aprender todo lo que puedan.

Secundado: comprender cómo realizar las pruebas adecuadas lo convertirá en un desarrollador mucho mejor. ¡Aprovecha la oportunidad!
@JennyD: eso supone que el OP aprenderá a hacer "pruebas adecuadas" en lugar de un trabajo descuidado, ya que no están capacitados ni comprometidos.
@Telastyn Bueno, si aceptan la oportunidad y tienen algún tipo de habilidad de aprendizaje, al menos tienen la oportunidad de hacerlo. Si no, no. ¿Podemos ir con "alienta a" en lugar de "asume que"?
¿Qué hace un ingeniero informático? ¿Te refieres a un programador?
Ingeniería Informática (BScE) es un título que combina ingeniería y desarrollo de software. El título requiere tomar todos los cursos básicos de ingeniería. No muy lejos de una doble especialización en CompSci y EE. Por lo tanto, está calificado para tomar el examen de ingeniería en capacitación. Debido a que tomó los cursos básicos de ingeniería, el graduado de BScE tiende a tener un conocimiento de hardware mucho más profundo y una mejor formación en matemáticas aplicadas que un graduado de Ciencias de la Computación. Los graduados de BScE gravitan hacia el desarrollo de software integrado ya que han pasado el tiempo en la escuela cubriendo el funcionamiento interno del hardware con mayor detalle.
Uno podría llamar a un desarrollador integrado simplemente programador, pero eso sería similar a equivocarse con un taxista y un piloto de avión. Después de todo, ambos son solo conductores que transportan personas.
@Telastyn, pero mi empresa no me permite convertirme en desarrollador. Me hicieron probador de por vida. Hablé con el jefe. Pero me contrataron como desarrollador. Me encanta el desarrollo, NO las pruebas.
@ user3416398 - luego busque otra compañía.
@Telastyn, pero la próxima compañía les dará $$$$ como trabajo de desarrollador :(
@ user3416398: ganará menos dinero con el tiempo como control de calidad...
@Telastyn, te refieres a la carrera si consigo a Dev. trabajo, entonces en el futuro superaré el salario de Tester?

Permítanme disentir con los otros respondedores: suponiendo que no quiera ser un probador, esto es horrible para su carrera.

Claro, tener la experiencia de realizar pruebas es una habilidad nueva y valiosa que puede usar para hacer un mejor trabajo al crear software.

Pero esto significa que su currículum ahora tiene una brecha en la que en realidad no creó software. Recursos Humanos lo considerará y no lo contará como los "años de experiencia" siempre deseados. Los gerentes de contratación (¡y sus compañeros!) verán eso y se preguntarán por qué lo trasladaron a las pruebas, ¿fue porque no podía escribir código?

Peor aún, no está adquiriendo experiencia en el diseño, la escritura y la solución de problemas del código . Esta experiencia más que nada te hará un mejor ingeniero de software. Y las habilidades que tiene se volverán obsoletas rápidamente, incluso si hace lo suficiente para evitar que se atrofien. El costo de oportunidad es demasiado alto.

Y luego está el trabajo en sí. Ser un ingeniero de control de calidad de cualquier tipo implica muchas repeticiones sin sentido. Oh, hay una nueva versión candidata. Puedo revisar mis miles de casos de prueba nuevamente. O puedo extender este marco de prueba automatizado para manejar el widget de interfaz de usuario 4033. La mayoría de los ingenieros de software que he conocido han encontrado que el trabajo en sí es enloquecedor. No solo no son buenos en eso (ya que no están comprometidos, o prosperan al crear cosas, no al romper cosas), sino que rápidamente buscan un nuevo trabajo, lo que descarrila cualquier impulso en su trabajo actual (aunque podría argumentarse que el el turno de trabajo ya lo hizo).

Y eso es todo antes de considerar el pago. Justo o no, los ingenieros de control de calidad ganan un 15 % menos que los ingenieros de software. Claro, mantendrá su salario actual por ahora, pero el nuevo trabajo guiará sus aumentos, lo que a su vez influirá en su salario en los años venideros.

-1. Su comprensión de SQA es reduccionista y realmente no capta la naturaleza del trabajo. Con demasiada frecuencia, los programadores ven a los profesionales de control de calidad como drones sin sentido, bots de prueba que solo ejecutan scripts una y otra vez, pero eso es como caracterizar a los programadores web como bots de código que toman una maqueta de Photoshop y la implementan literalmente, sin participación en el proceso creativo. .
@Yamikuronue: después de haber sido ingeniero de SQA durante 3 años, no estoy de acuerdo. Ciertamente, hay algún proceso creativo al hacer los planes de prueba y los scripts si tiene la suerte de no ser un probador completamente manual; pero esa parte creativa es una pequeña fracción del trabajo total. No he visto nada diferente durante los otros 15 años de mi carrera.
No estoy seguro de dónde has trabajado, pero después de haber estado en SQA durante casi 3 años, he tenido exactamente la experiencia opuesta. Las pruebas automatizadas me brindan desafíos nuevos y emocionantes constantemente, siento que siempre estoy aprendiendo una nueva forma de probar.
@Yamikuronue: Symantec, 3M y 3 lugares de los que nunca ha oído hablar. Estoy feliz de que no sea aplastante en todas partes, pero soy escéptico de que su experiencia sea normal de alguna manera.
Estoy de acuerdo en parte con lo que ambos dijeron, sin embargo, las personas más difíciles de colocar tienden a ser personas con menos experiencia. Lo que sucede a menudo cuando los proyectos recién comienzan es que las personas con experiencia están desarrollando el plan, la arquitectura y los requisitos, y las personas con menos experiencia no pueden incorporarse al proyecto hasta que esté terminado. El lugar lógico habitual para colocarlos donde sean fáciles de sacar cuando sea necesario es la prueba. Sería bueno que todos trabajaran en un proyecto desde el principio, pero los presupuestos tienden a no permitirlo. Entonces, si esto es temporal (3 meses o menos), no se preocupe.
+1. La prueba es importante, pero también lo es trapear el piso. Si desea una carrera como desarrollador de software, salga de la prueba lo antes posible antes de llegar al punto en que los trabajos de prueba son todo lo que puede obtener.
+1 Estás perdiendo un tiempo precioso si quieres ser desarrollador. @CaptainCodeman +1 por decirlo brutalmente, aunque espero que nadie se ofenda.
@Telastyn, pero mi empresa no me permite convertirme en desarrollador. Me hicieron probador de por vida. Hablé con el jefe. Pero me contrataron como desarrollador. Me encanta el desarrollo, NO las pruebas. – user3416398 acaba de editar
++ No puedo creer que haya encontrado un rincón de SO donde esta es una opinión disidente. Puede decir que las experiencias son valiosas, pero debe haber formas de acumular experiencia sin sabotear su carrera. Me pregunto qué hizo el OP al final.

Eso depende:

  1. ¿Es mejor ser trasladado a Testing que estar sentado todo el día sin hacer nada? La consecuencia de la inactividad es el desempleo.

  2. ¿Es la prueba una parte esencial del proceso de desarrollo?

  3. ¿Es necesario que los desarrolladores senior comprendan el proceso de prueba lo suficientemente bien como para trabajar con los evaluadores?

Si determina que la respuesta a las preguntas anteriores es "sí", entonces cambiar a Pruebas es bueno para su carrera. Si determina que las respuestas a las preguntas anteriores son "no", entonces está perdiendo el tiempo yendo a trabajar.

He aprendido cosas en todos los trabajos que he tenido, incluido el de cajera en una tienda de comestibles. Tampoco son necesariamente las cosas que esperarías al leer la descripción del trabajo. Si el OP no está aprendiendo cosas, no es su tiempo el que se está desperdiciando sino su oportunidad.
@JennyD Excelente punto: demasiados miran el corto plazo porque está frente a ellos y no ven el mediano plazo y el largo plazo que están detrás del corto plazo :) Ninguna de las palabras "miopía" y "visión de túnel" se usaría en la descripción de una carrera profesional exitosa.
@VietnhiPhuvan, pero mi empresa no me permite convertirme en desarrollador. Me hicieron probador de por vida. Hablé con el jefe. Pero me contrataron como desarrollador. Me encanta el desarrollo, NO las pruebas. – user3416398 acaba de editar
@user3416398 Bueno, cuando solicita un trabajo de desarrollo con otra persona, su mención de la intención de su jefe de convertirlo en un probador de por vida será una excelente razón para irse. Hasta que despegues, no está de más ser el mejor probador que puedas ser.

El diseño adecuado de las pruebas puede ser un campo altamente calificado en sí mismo y requiere una comprensión bastante profunda de la programación para predecir qué patrones de uso serán casos límite/pruebas de estrés. Podría decirse que cada programador debería estar escribiendo casos de prueba para su propio código a medida que avanza, pero eso rara vez sucede... y a veces hay propiedades emergentes que solo pueden provocarse cuando se prueba el sistema en su conjunto. Si lo tienen diseñando pruebas por un tiempo, considérelo una buena experiencia de aprendizaje... del mismo modo que trabajar en atención al cliente, aunque a veces es frustrante, es una buena educación sobre cómo los clientes usan y piensan sobre el producto.

Si haces un trabajo bien y con alegría, solo puede reflejarse bien en ti.

Si no es lo que quiere hacer o dónde cree que se utilizan mejor sus habilidades, recuérdeselo a la gerencia periódicamente (no más de cuatro a seis veces por año) y eventualmente lo llevarán de vuelta al desarrollo.

¡No más de 4 a 6 veces al año! Ay, odio la idea de sentarme allí durante el tercer año, revisando mi calendario para ver si es tiempo de nuevo. Si es algo que realmente no te gusta, y ya lo planteaste una o dos veces de manera formal... ¿cuáles son las posibilidades de que se arregle? :/
Las posibilidades de que se solucione dependen del equilibrio de la disponibilidad de personal en las pruebas frente a las demandas en el desarrollo, que cambia con el tiempo. Mi punto es que molestar a los gerentes con más frecuencia de lo que se reconsidera el equilibrio a su nivel es probable que parezca que "no están dispuestos a adaptarse para satisfacer las necesidades del negocio" y/o simplemente no es agradable trabajar con ellos, y puede convertirse en un movimiento que limite su carrera.
@keshlam: puede limitar su carrera en su organización actual. OTOH hacer un trabajo que es menos valioso que el trabajo del que es capaz erosiona su valor para cada empleador potencial.
No necesariamente. La exposición a las pruebas, especialmente la exposición a las cosas extrañas que hacen los clientes después de comprar sus productos, es una ventaja. Demostrar que puedes escribir pruebas sólidas es una ventaja. Demostrar que puede usar los resultados de esas pruebas para mejorar el producto es una ventaja. Es una cuestión de cuánto tiempo lo estás haciendo, por qué lo estás haciendo y qué más has estado haciendo. Las pruebas no son necesariamente "menos valiosas"; es un valor diferente.

No consideres esta tarea como una temporada en la cárcel. En su lugar, trátelo como una rara oportunidad. En serio.

¿Qué trayectoria profesional esperas?

La mayoría de las carreras en el mundo de la creación de software requieren un conocimiento profundo del ciclo de vida del software. Ese ciclo de vida incluye muchas fases de trabajo además del corte de código nuevo.

Hay especificación. Hay un diseño detallado. Hay pruebas unitarias. Hay pruebas de usabilidad, pruebas de sistema, pruebas de integración y pruebas de carga.

Hay soporte de implementación, soporte continuo. Hay mantenimiento y corrección de defectos.

La experiencia del mundo real en el aseguramiento de la calidad del software mejorará sus habilidades en cada una de estas fases de creación de software.

Por ejemplo, en especificación: podrá comprender "¿cómo vamos a probar este sistema?" En el diseño detallado, podrá diseñar para la capacidad de prueba. Esto es especialmente desafiante para el sistema que se ampliará y requerirá pruebas de carga.

Entonces, hable con su gerente y dígale que espera aprender todo lo que pueda de esta asignación temporal a un equipo de aseguramiento de la calidad del software. Hable con sus colegas profesionales de calidad de software y conozca algo sobre cómo piensan.

Encuentre una copia del libro clásico "El mes del hombre mítico" del Dr. Fred Brooks y léalo. Explica la gran diferencia entre la creación de código y el desarrollo de productos de software.

La prueba es bastante vaga. La respuesta depende mucho de lo que estés haciendo. Escribir pruebas automatizadas es una habilidad valiosa. Ejecutar pruebas manuales es una mala práctica y retrasará su avance técnico. Si su organización realiza pruebas manualmente, ¿puede automatizarse?

En resumen, si están atascados en la ejecución de pruebas manuales, le sugiero que busque otra cosa que hacer.

Estoy de acuerdo con este punto. Si solo eres un mono de prueba que ejecuta scripts, este proceso apestará. Sin embargo, si está creando el plan de prueba, eso es una habilidad en sí misma.
Como ingeniero informático, ¿ser asignado a pruebas es malo para mi carrera? [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v