Déjame contarte mi historia. Puede que ayude a alguien que se plantee tener o empezar una carrera de QA.
He tenido exactamente 10 años de experiencia en QA. Empecé como ingeniero de QA y terminé como Director de QA en esos 10 años, mi salario se duplicó con creces en el camino. Tuve suerte porque mi salario inicial era alto. Era de un percentil del 5%, y cuando me convertí en director veterano, mi salario estaba en el percentil del 2% para director de QA y estaba por encima de la media del salario para director de ingeniería. Parece una carrera muy exitosa.
Tengo mi licenciatura y maestría en Ciencias de la Computación. Obtuve mi BS en una universidad de supervisión y MS en una universidad que está dentro del top 10 de escuelas de ingeniería en los estados. A lo largo de mis años universitarios, trabajé como desarrollador independiente. El control de calidad hace unos 10 años era poco diferente del control de calidad actual. La industria se centraba sobre todo en el control de calidad (piense en los inspectores de fábrica) y MS acababa de empezar a contratar a muchos SDET. Google tenía un grupo de control de calidad tradicional, no el grupo de productividad de ingeniería que prevalece hoy en día. A mis ojos, el control de calidad parecía un nicho de mercado. Había muchos desarrolladores – yo, por ejemplo, era uno y estaba rodeado de ellos. Pero no muchos QA y parecía que la demanda era alta mientras que la oferta se quedaba muy atrás. Esto es también alrededor de la época en que Kent Beck vino con TDD. Todo parecía muy halagüeño.
Así que me promocioné como ingeniero de QA fuera de la escuela. QA estaba en alza y simplemente no había mucha gente con grado de CS en MS que quisiera ser ingeniero de QA. (Todo el mundo quería ser un desarrollador) Me conseguí un trabajo como ingeniero de QA en una empresa conjunta bien financiada. También me pagaron muy bien. Como primer trabajo al salir de la escuela de posgrado, ganaba unos 20.000 dólares más que la gente que había estado haciendo pruebas manuales durante años. Ellos se llamaban «analistas de control de calidad» y yo era un «ingeniero de control de calidad», los analistas de control de calidad fueron promovidos a ingenieros de control de calidad. La automatización era una nueva palabra de moda en la industria del software. El grupo de control de calidad al que pertenecía empezó a buscar herramientas de automatización. Mientras estaba en la escuela de posgrado, escribí algo de código JAVA para automatizar las pruebas tediosas de la aplicación que desarrolló mi equipo de proyecto. No sabía que eso era automatización, pero me di cuenta de que’ es lo que hice en mi primer trabajo. Empecé a codificar algunos scripts de prueba automatizados. Nadie podía hacer eso en mi grupo.. Al año siguiente me ascendieron a jefe de control de calidad.
Entonces me convertí en la «persona técnica» del grupo. El siguiente trabajo que tuve fue de jefe de QA práctico. Mi equipo está formado por ex-desarrolladores; uno de ellos se convirtió de desarrollador a ingeniero de QA porque su antiguo jefe que realmente quería que estuviera en su equipo le convenció. Y él convenció a otra chica de la misma escuela para que se convirtiera. La automatización para nuestro equipo fue fácil. Simplemente creamos un marco de trabajo de pruebas que puede acomodar las variaciones en las pruebas y lo hicimos. Entonces, empezó el bombo de Agile.
Ser ingenieros de QA que fueron desarrolladores en la vida pasada tiene una gran ventaja. Contribuir a la calidad de los productos de software enviados no consiste sólo en encontrar defectos. En el régimen ágil, era aún más evidente. No había lugar para las pruebas manuales. El software se convirtió cada vez menos en una pieza de arte y más en una mercancía para vender.
Me trasladé a una gran empresa no tecnológica cuando llegó el momento. La tecnología no era su negocio principal en esta empresa, pero querían hacer crecer el equipo de tecnología para apoyar el negocio. Había unas 40-50 personas en todo el equipo tecnológico cuando me incorporé, y se convirtió en unas 180 personas cuando dejé la empresa 3 años después. 30 de ellas formaban parte de mi equipo. Me convertí en director en el plazo de un año desde que empecé. Había un 20% de pruebas manuales y un 80% de pruebas automatizadas. Tenía un equipo de desarrollo de herramientas dedicado (que eran puros desarrolladores) en mi departamento. Todo el mundo en mi equipo era SDET y todo el día estaban creando códigos de prueba.
Entonces me aburrí mucho mucho. Me trasladé a una empresa emergente pensando que eso podría cambiar las cosas. No funcionó. Nada me simulaba intelectualmente. Y luego también me harté de la gente que piensa que el QA es algo tan fácil que cualquiera puede hacer. O que la GC no es algo esencial para el negocio. Es bueno tenerla, pero cuando el dinero es escaso, tal vez sea una de las primeras cosas que se pueden eliminar para ahorrar dinero. Hay mucha gente, especialmente en el mundo de las empresas emergentes, que piensa que los desarrolladores pueden hacer pruebas mientras que los probadores no pueden hacer codificación. Entonces, ¿por qué no contratamos a más desarrolladores para matar dos pájaros de un tiro? ¿Por qué gastar dinero en el control de calidad? Como he sido jefe de control de calidad durante mucho tiempo, sé lo eficiente que es para la empresa tener un buen equipo de control de calidad, incluso puedo cuantificarlo. Y es por eso que las empresas de éxito tienen un grupo que se centra en la calidad – puede que no se llamen «QA», sin embargo, tiene algún matiz que no resuena con los desarrolladores de alto nivel que podrían encontrar «QA» atractivo. Pero hay gente que simplemente tiene miedo de gastar dinero en QA cuando piensan que pueden gastar ese dinero en los desarrolladores – independientemente de lo malos que puedan ser los desarrolladores. He visto muchas ocasiones en las que los ingenieros de control de calidad han tenido que decir a los desarrolladores exactamente qué líneas de código hay que cambiar para arreglar ciertos defectos que han encontrado. Pero bueno, algunas personas que realmente nunca han codificado profesionalmente o algunos directivos que nunca han visto trabajar bien a un equipo de QA tienen este prejuicio hacia el QA de que QA es igual a pérdida de dinero.
Si empiezas una carrera de QA como ingeniero, tendrás que luchar las batallas que yo luché sin parar. Y si eres bueno, destacarás fácilmente – de hecho, hay tanta, tanta gente de «QA» que no debería estar haciendo QA. La desviación estándar es enorme en QA y hace bajar la media del salario y la calidad de los recursos significativamente – lo mismo ocurre con los desarrolladores, hay incluso más desarrolladores que no deberían estar creando ningún código.
Sin embargo, como nota al margen, si no eres técnico, no sabes codificar, pero quieres estar en el mundo de la tecnología, será más fácil para ti conseguir un trabajo como tester manual de QA que como desarrollador. Pero el probador manual de control de calidad es un trabajo en extinción. La automatización se está imponiendo y es realmente una cuestión de tiempo reemplazar las pruebas manuales por la automatización. No me sorprendería que el «QA» se volviera obsoleto en un futuro cercano. Supongo que los desarrolladores también se quedarán obsoletos, pero el control de calidad desaparecerá antes. Te recomendaría que consideraras la gestión de productos; el QA y la gestión de productos comparten muchas características similares y no necesitas codificar para hacer PM; pero nadie necesita muchos PMs. 1 por equipo. Así que es limitado, pero la entrada es fácil. Pero una vez que la codificación se convierte en algo tan común, PM necesitaría codificar – pero no’te preocupes: para entonces, codificar será como usar excel.
Dejé mi trabajo como director de QA y reflexionando sobre mí mismo para averiguar lo que realmente quiero hacer a continuación. Tuve una buena carrera y no me arrepiento de haber recorrido el camino que recorrí. Espero que mi historia -o una larga memoria- ayude a alguien que considere el control de calidad como una carrera.