¿Cuál es el momento adecuado para que un probador de software solicite un rol de desarrollo de software en su empresa?

Comencé en mi compañía actual como probador de software con la creencia de que era una programación 100% de automatización. Resultó que estaba haciendo un 95% de pruebas manuales y un 5% de automatización. Pasé un año trabajando duro, y yendo más allá de mis tareas normales de prueba de “caja negra”, como profundizar en la base de datos y los registros para dar más información sobre los errores y trabajar de cerca con los desarrolladores en la corrección de errores. Con el tiempo se dieron cuenta de que yo era “diferente” que los otros miembros de QA y comenzaron a mostrarme más código y cómo estaban arreglando las cosas. Les hablaría mucho sobre mi experiencia pasada en el desarrollo, así como mi título de CS, etc. A partir de ahí mencionaron mi nombre a los gerentes, etc. Eso fue hace 5 años, y ahora trabajo en componentes críticos de nuestro software. ¡Espero que ayude!

¡Buena suerte con eso! Lo vas a necesitar.

Si te has convertido en desarrollador, diría que lo más fácil sería conseguir un trabajo en otra empresa. A menos que su compañía actual sea de “mente abierta”. Con eso quiero decir que están dispuestos a darte la oportunidad de probarte a ti mismo. Otoh, la gerencia puede sentirse invertida en usted como probador y sería muy reacio a ‘perderlo’ en una posición de desarrollo, a menos que ya piensen que su potencial supera con creces su utilidad como probador.

En la mayoría de los lugares, sería un gran ejercicio de futilidad.

Primero comencemos con tu papel

Como eres un recién graduado, de repente pedirle cambiar al equipo de desarrollo no será fácil / posible. Hay dos diferencias entre un probador y un desarrollador

1. Un desarrollador tiene mejores habilidades de programación.
2. Un desarrollador tiene un mejor conocimiento de la tecnología en la que ambos están trabajando.

Con mi conocimiento de lo que hacen los probadores es que escriben scripts para automatizar el proceso de prueba y algunos de ellos también escriben casos de prueba unitaria. Ir al equipo de desarrollo requeriría que comprenda la tecnología subyacente en la que está trabajando. Tu camino es muy claro desde aquí. Escriba muy buenos códigos de prueba de unidad y guiones. No comenzará de la noche a la mañana, pero trate de mejorar rápidamente. Siga estudiando sobre la tecnología en la que está trabajando y con la ejecución de casos de prueba unitarios, se familiarizará más con la tecnología. Trate de informar más y más problemas y también trate de adivinar la razón de los problemas y si su prueba es una casilla blanca, intente encontrar la causa del problema también. Asegúrese de que sus casos de prueba de unidad sean tan buenos que su gerente y el gerente del equipo de desarrollo comiencen a elogiarlo por esto. Esto te facilitaría las cosas. Objetivo 6 meses.

La transición del probador al desarrollador no es infrecuente. Lo complicado, por supuesto, es que la compañía claramente necesita un probador, por lo que contrató uno y es posible que no necesite otro desarrollador.

Si su empleador actual no sabía cuándo lo contrataron que quería ser desarrollador, probablemente dejaría pasar un poco de tiempo, por lo que no parece que haya tomado un papel que realmente no quería, incluso si eso es Es cierto, y luego de unos meses, hable con su gerente. Si sabían antes de contratarte que el desarrollo era algo que querías, entonces puedes hablar de ello antes.

De cualquier manera, hágales saber que le gustaría pasar de un rol de prueba a un rol de desarrollo a lo largo del tiempo. Si parecen manejar el pozo, explique que le gustaría trabajar con ellos para determinar qué necesita mostrar para ser considerado, qué hitos debe superar, qué cosas puede necesitar aprender y demostrar si no tiene Ya los aprendí y cómo ayudarlos a reemplazar su posición actual cuando estén listos.

En esencia, desea comenzar a hacer un plan real para esta transición, pero desea que participen para que se sientan cómodos. Sin un plan concreto, puede que no suceda en absoluto, pero con un plan que siempre puede volver a visitar para evaluar el progreso.

Inmediatamente después podrás demostrar que puedes desarrollarte. Recomiendo conseguir un mentor, preferiblemente en la misma empresa.

Te diré el ejemplo de cómo un colega hizo la transición. Comenzó tomando cursos de programación, bases de datos y Linux. Después de eso, pidió que se le asignara una tarea de baja importancia en la que trabajó mientras realizaba sus tareas de control de calidad. Me preguntó si podía ser su mentor, acepté. Él venía a mí todos los días para hacer preguntas y revisar el código de su progreso. El proceso duró aproximadamente un año y se le ofreció un puesto de desarrollador junior, que tomó.

Mantuvo este trabajo por otro año, luego se le ofreció un puesto de desarrollador de nivel medio en otra compañía, que también tomó.

El hecho más importante es que siguió aprendiendo constantemente. Si te ayuda, casi cuadruplicó su salario en 4 años.

Tenga en cuenta que hubo otros probadores en la misma compañía que han sido probadores durante más de 10 años, por lo que si no hace nada, no espere que suceda nada.

¡Buena suerte!

Dependiendo del conocimiento de la herramienta o tecnología que quiere trabajar. Si la comprensión de la tecnología es buena, puede intentarlo en cualquier momento. Pero antes de preguntar, inicialmente debe tener claro su futuro en ese rol.

P : ¿Cuál es el momento adecuado para que un probador de software solicite un rol de desarrollo de software en su empresa?

A : Muchas cosas a considerar. ¿Tiene capacitación para escribir el código que usan? ¿Tendrán alguna vacante pronto? Creo que es un buen movimiento y, en teoría, cualquier código que escriba debe ser más “sólido” que el de un desarrollador “solo desarrollador”. Pero el tiempo es clave, no querrás parecer demasiado ansioso por dejar atrás tu posición actual

Creo que deberías seguir siendo probador durante aproximadamente un año: durante ese tiempo, mantén tus habilidades afiladas, registra los defectos utilizando buenas habilidades de comunicación, demuestra que conoces el software.

¡Buena suerte!

La ruta más fácil es cuando un trabajo de nivel de entrada está disponible. De esta manera, las expectativas son bajas, pero su familiaridad interna con la cadena de herramientas y los procesos son una ventaja.