Consejo profesional: ¿Mis expectativas sobre cómo realizo mi trabajo como ingeniero de software en la prueba son completamente erróneas?

Como otros han dicho, lo que has experimentado es común. Sin embargo, hay excepciones. Por un lado, las empresas que son (muy) rentables no tienen actitudes tan negativas, por ejemplo, Microsoft, Google (aunque no estoy de acuerdo con la prueba de tipo SDET). Muchas empresas de productos de tipo startup también valoran la contribución de los evaluadores, según el equipo de gestión. Los equipos de tipo de TI, por ejemplo, bancos, telecomunicaciones, otros, es decir, no compañías de productos, probablemente tendrán actitudes similares a pesar de la rentabilidad. Trabajé en organizaciones que requerían sólidos conocimientos de dominio, es decir, software de ingeniería. El equipo de control de calidad fue muy poderoso, ya que los desarrolladores no tenían ese conocimiento de dominio. Por otro lado, cuando trabajé con software de sistema, es decir, software de seguridad, los desarrolladores tenían un conocimiento muy sólido, es decir, comp. sci. el tipo de conocimiento y los probadores tuvieron dificultades para mantenerse al día.

Comencé mi carrera como desarrollador de pruebas. De hecho, cuando dejé Microsoft y regresé unos años más tarde, tuve la opción de elegir entre el desarrollo de pruebas y los roles de desarrollo tradicionales. Elegí el primero porque me gustaba mucho y me habían asegurado que era un socio igualitario con el desarrollo, lo cual era cierto con el equipo con el que trabajé en la primera ronda.

Las cosas que has observado son bastante precisas, en mi experiencia, y tus preocupaciones son válidas.

1. Tener las mismas pruebas y desarrollo del mismo gerente puede ser un conflicto de intereses para ese gerente. Si no poseen otras disciplinas también (por ejemplo, PM, marketing, etc.), entonces puede ser un problema real. Ciertamente fue en la organización en la que estaba que se ejecutó así.
2. Los desarrolladores desprecian explícitamente a los evaluadores como dos grupos generales. En su mayor parte, los desarrolladores suponen que los evaluadores no fueron lo suficientemente buenos como para ser contratados como desarrolladores, y tienen habilidades y experiencia inferiores. Esto me fue explicado sucintamente más adelante en mi carrera: los desarrolladores crean lo que se envía. Sin ellos no tienes un producto. Los probadores lo mejoran, pero si tienes un bote salvavidas con solo dos asientos, y tienes un desarrollador y una prueba para elegir …

Si tiene habilidades de codificación, le recomiendo pasar al desarrollo. Si no tiene habilidades de codificación pero tiene interés, le recomiendo aumentar sus habilidades de codificación en su trabajo actual (o similar).

En mi experiencia, la prueba de software como disciplina es una especie en peligro de extinción. He visto pruebas diezmadas en dos compañías diferentes. Con un cambio del software reducido a la nube y el software como servicio, existe la posibilidad de solucionar problemas rápidamente. ¿Por qué triplicar sus costos de desarrollo y solucionar miles de problemas cuando podría obtener comentarios sobre los diez usuarios a los que les importa y les importa, y solo solucionarlos rápidamente? Triple, porque se necesitan recursos para realizar pruebas y recursos para investigar y solucionar todos los problemas que encuentra la prueba, incluso si los clientes no los encuentran comúnmente.

No estoy necesariamente de acuerdo con esta perspectiva, pero la entiendo y no va a desaparecer.

Si está en una prueba de software y tiene la capacidad de migrar a un rol diferente, le recomiendo que comience a migrar.

No sé mucho sobre el campo, pero he tenido un cliente que probó el control de calidad de microchips. Mi comprensión de él es que todo lo que dices es bastante preciso.

Los desarrolladores de productos (diremos IBM porque sabemos que no lo es) quieren sacar el nuevo producto al mercado lo más rápido posible. Es dinero en el banco, en los bolsillos de los accionistas y disponible para su uso en el desarrollo de productos futuros. Mantiene el nombre de IBM frente a todos.

Su trabajo es lo opuesto al de los desarrolladores de productos. Si hace bien su trabajo, puede descubrir un problema y detener el lanzamiento del nuevo producto. La compañía pierde cuota de mercado, identidad de marca y ganancias. Son más felices si haces un trabajo rápido y descuidado. Luego, para cuando encuentre un problema, el próximo producto ya está a medio terminar, y en lugar de arreglar IBM 17, anuncian que IBM 18 se lanzará el próximo mes.

No quieren ser tu mentor. Si sabe demasiado sobre el producto, puede descubrir defectos que no se descubrirán si tiene que aprender el producto mientras lo prueba. Pueden argumentar que el 80% que usted enseña es todo lo que el usuario promedio aprenderá de todos modos, y el 20% restante vale la pena dar un reembolso o una actualización, ya que sabemos que no todos devolverán su producto o se quejarán. Quizás, efectivamente, al 5% le importen los problemas que omita. IBM y sus accionistas aún obtienen buenas ganancias.

Si a IBM le importa el dinero, el desarrollador ES más importante que el control de calidad. El problema es que te importa la calidad; Por eso eres un probador.

Puede intentar conseguir un trabajo en una empresa que tenga una reputación de muy alta calidad. Puede comprender que su trabajo es oponerse a los objetivos de la empresa, y que el suyo es evitar que lo haga e intentar adaptarse. O puede pasar a un campo diferente.

Elija lo que elija, buena suerte y sepa que al menos no está equivocado; simplemente no quieren que tengas razón.