Conocí a algunos administradores de sistemas y, según él, a los chicos de pruebas no se les dan preferencias en una organización en comparación con los desarrolladores. Sin duda, las versiones de software no son posibles sin los probadores, pero nunca he puesto mis manos en las pruebas, así que no estoy muy al tanto. Sin intención de ofender.
Respuestas:
En mi experiencia, desafortunadamente, a menudo son tratados como empleados de segunda clase y, lo que es peor, un beneficio frívolo para los programadores.
Se deriva de una serie de cosas:
Cuando los evaluadores están haciendo su trabajo correctamente, es fácil para todos, excepto para los programadores, olvidar que incluso existen. Al igual que un administrador de red, solo los notas cuando no están haciendo su trabajo o si los están haciendo mal. Entonces, desde la perspectiva del resto de la organización, son recordados solo por sus errores.
Se considera erróneamente como un trabajo de nivel de entrada para las personas que aspiran a ser programadores, pero que aún no están calificadas para esos trabajos. De hecho, en una compañía en la que trabajé se les dieron títulos de trabajo de Jr. Programmer a pesar de sus súplicas para obtener un título de trabajo de preguntas y respuestas. Incluso el hecho de que estuvieran en un departamento de control de calidad no fue suficiente para que RR.HH. cediera en eso.
Debido al n. ° 2, se supone que todos los evaluadores son personas de nivel de entrada y deben pagarse en consecuencia.
A nadie le gusta que lo critiquen, y es muy común que a los programadores defensivos les disgusten los probadores porque sus trabajos requieren que señalen los errores del programador todo el día. Como gerente, estaba constantemente en una misión de relaciones públicas para recordarles a los programadores que el equipo de control de calidad estaba allí para que se vieran bien, no para narrarlos.
Tiende a ser un trabajo en el que la gente se mete por accidente y no por elección, al menos inicialmente. No recuerdo ningún plan de estudios en ninguna de las escuelas a las que asistí que preparó a las personas para preguntas y respuestas sobre el software. Existen, pero generalmente en las escuelas vocacionales de gama baja, lo que solo contribuye a la idea de que son profesionales menos calificados.
Los trabajos de prueba son mucho más propensos que los trabajos de programación que se enviarán al extranjero. Al menos los programadores pueden argumentar que es más eficiente comunicar las necesidades de diseño localmente y que es valioso mantener el conocimiento de cómo funciona la aplicación insignia de la empresa dentro de la empresa. Sin embargo, las pruebas son mucho más fáciles de modularizar y, por lo tanto, más fáciles de externalizar.
Por todas las razones anteriores, los evaluadores tienden a ver la escritura en la pared y a pasar a otros trabajos (como la programación), especialmente los realmente buenos. Esto significa que la mayoría de los trabajos de prueba tienden a contar con más personas de nivel de entrada que aún no se han agotado o se han movido a otras cosas, lo que desafortunadamente refuerza varias de las ideas anteriores.
Depende de la empresa, pero generalmente. A menudo son vistos como ciudadanos de segunda clase, y en muchas empresas, las pruebas son vistas como una posición de nivel de entrada desde la cual luego pasaría a convertirse en un desarrollador real.
Esto es, por supuesto, basura. Después de haber trabajado con algunos buenos evaluadores, puedo decir que son valiosos y difíciles de conseguir. Alguien con una mente lo suficientemente creativa como para encontrar errores no obvios y lo suficientemente metódica para hacer un trabajo completo.
Sin embargo, una excepción: he conocido a algunos tipos de pruebas de Microsoft, y escuché que los evaluadores son ciudadanos de primera clase.
He trabajado como probador funcional durante un año en un proyecto bastante grande. Cada equipo de unos 10 miembros tenía 2-3 eran evaluadores. Debo decir que fuimos tratados igual de importantes para el proyecto que los desarrolladores.
Encontrar errores no es fácil. Primero, los probadores tienen que entender lo que se supone que debe hacer el código. Eso significa leer y comprender los requisitos. La clave aquí es comprender los requisitos: si los evaluadores no pueden comprender los requisitos lo suficientemente bien como para saber cómo escribir casos de prueba positivos, debe preocuparse. Esto significa que los desarrolladores han escrito un código que hace lo que asumieron. ¿Es esta suposición la correcta? No lo sabrá hasta que haya resuelto los requisitos, y puede agradecer a sus evaluadores por encontrar ese defecto.
En segundo lugar, los probadores tienen que escribir casos de prueba falsos, lo que garantiza que el código no haga lo que se supone que no debe hacer. Una regla general razonable es que escriba 5-10 casos de prueba falsos para cada caso de prueba positivo. Esto significa comprender los requisitos aún más, y a menudo estoLa información es, o al menos en nuestro proyecto, confusa y ambigua. (Y no fue por el bajo esfuerzo para reunir los requisitos: teníamos algo así como 13,000 solo en nuestro equipo). Nuevamente, los desarrolladores habrán escrito su código utilizando sus suposiciones, o peor aún, ni siquiera consideraron esto en absoluto. Entonces, ¿qué hace el código en estas condiciones que no son normales? No lo sabes hasta que lo hayas probado. Quizás el programa no responde; tal vez simplemente se bloquea; tal vez destruye datos; tal vez le permite al usuario ejecutar comandos como usuario root. Hagas lo que haga, quieres saberlo. De lo contrario, puede que se encuentre leyendo el siguiente titular en el periódico un día: INGRESE EN EL NÚMERO DE TARJETA DE CRÉDITO DEL CLIENTE DE [NOMBRE DE SU COMPAÑÍA].
Así que trata bien a tus evaluadores. Trátalos bien. Después de todo, ellos son los que eliminan los errores en su software y hacen que su vida y la nuestra sean más fáciles.
Los buenos probadores que pueden analizar los problemas de manera eficiente y pueden hacer una automatización de prueba decente valen su peso en oro, ya que hay tantos probadores de vaqueros por ahí (al entrevistar a un "probador" una vez que se echó a reír al darse cuenta de que sabíamos que estaba haciendo cosas en el acto mientras lo interrogan en su CV).
En mi equipo, el evaluador es tratado como un igual, lo que incluye responsabilidad y salario. Si desea un probador que haga clic en el siguiente todo el día, subcontrate a un lugar barato (también lo hacemos).
Actualice después de leer otras respuestas: hay muchos profesionales de control de calidad que aman el trabajo que hacen. Solo para dar otra perspectiva si no ha encontrado ninguna posición de control de calidad respetada, un ejemplo aquí: aplicaciones integradas / pruebas de aplicaciones móviles para fabricantes de automóviles líderes. Se aseguran de que los requisitos comerciales se cumplan por completo antes de que un vehículo sea lanzado al mercado y ningún usuario experimente un tablero de automóvil lento o que no responda. Trabajan en estrecha colaboración con los gerentes y la gerencia de nivel superior, y también con los desarrolladores, comenzando desde la planificación del proceso de control de calidad hasta las pruebas prácticas en vivo en simuladores en la instalación de diseño. No puedo pensar que sean de bajo perfil, manejan enormes responsabilidades y propiedad y están entre los mejores ingenieros.
ahora mi respuesta anterior, la otra cara:
He observado que los graduados de ingeniería odian que los asignen a las unidades de prueba (contexto: India, grandes empresas de servicios de software donde todo se basa en 'requisitos comerciales'), ya que lo consideran un entorno de trabajo no técnico. Se les dan hojas de Excel con instrucciones como "haga clic en todos los enlaces de la página web y verifique", se ven obligados a trabajar con graduados de corrientes no técnicas (ciencias, artes) que consideran humillantes y sienten que sus habilidades tecnológicas no lo son. utilizado Estas asignaciones se basan exclusivamente en los requisitos de la organización, y una mayoría de las veces, no tiene el poder para negociar su carrera profesional. Por lo tanto, si es un buscador de trabajo que apunta a una empresa de TI tan grande, se le ha advertido. No se puede hacer mucho, prácticamente, excepto salir de la empresa en el momento adecuado.
A menos que haya oportunidades para aprender pruebas automatizadas, pruebas de carga / rendimiento, etc., la carrera está estancada hasta cierto punto. Personalmente, sé que las oportunidades para tareas en el sitio (= cargas de dinero desde el punto de vista de un programador offshore) son más para la unidad de prueba en mi organización que cualquier otra unidad. Trabajan con todas las verticales de la industria como relleno o pegamento, ya que las pruebas son inevitables en proyectos en todos los dominios.
Si está seguro de que puede conducir su carrera de la manera que desee, las pruebas no son nada de bajo perfil. Con 4-5 años de experiencia y un poco de suerte, puede obtener una muy buena exposición, a veces interactuando con los usuarios comerciales de alto nivel. También puede tener una buena idea de la industria / dominio en el que está trabajando (en comparación con un desarrollador que se centraría principalmente en alguna parte del sistema). En este punto, uno puede elegir cambiar a un rol de analista de negocios también.
Conozco empresas donde el equipo de control de calidad es responsable de los lanzamientos. Esto significa que tienen el poder de bloquear un lanzamiento debido a la falta de calidad. Si se informa un problema en el campo, son los primeros en la línea de fuego (mucho después del ingeniero de campo).
Por lo general, tienen un mayor conocimiento del dominio. Tienden a conocer mejor la funcionalidad general del producto, mientras que los desarrolladores se concentran en su módulo / características.
También sé de organizaciones de control de calidad donde tienen que escribir sus propias herramientas de prueba. Sin mencionar la automatización de todo el material. Soy un desarrollador, y siempre he valorado a los chicos de QA que prueban mis características.
Al menos en mi organización, el control de calidad se trata por igual con los desarrolladores. Creo que es debido al dominio (telecomunicaciones) donde el conocimiento de la arquitectura de red y protocolo se valora igualmente con las habilidades de programación.
Si. Me gusta o lo dejo son igualmente importantes, pero siempre son menos preferidos. Puede ser porque son fáciles de reemplazar.