Por acaso conheci algum administrador do sistema e, de acordo com ele, os caras de teste não têm preferências em uma organização em comparação com os desenvolvedores. Sem dúvida, os lançamentos de software não são possíveis sem os testadores, mas eu nunca coloquei minhas mãos em testes, pois não estou muito ciente disso. Nenhuma ofensa pretendida.
Respostas:
Na minha experiência, infelizmente, eles são frequentemente tratados como funcionários de segunda classe e, pior ainda, uma vantagem frívola para programadores.
Isso decorre de várias coisas:
Quando os testadores estão realizando seu trabalho corretamente, é fácil para todos, menos para os programadores, esquecer que eles existem. Assim como um administrador de rede, você só os percebe quando eles não estão realizando seus trabalhos ou fazendo-os mal. Portanto, da perspectiva do resto da organização, eles são lembrados apenas por seus erros.
É considerado erroneamente como um trabalho básico para pessoas que desejam ser programadores, mas ainda não estão qualificados para esses trabalhos. De fato, em uma empresa em que trabalhei, eles receberam títulos de Jr. Programmer, apesar dos pedidos de obter um cargo de perguntas e respostas. Mesmo o fato de estarem em um departamento de controle de qualidade não foi suficiente para fazer com que o RH mudasse.
Por causa do item 2, supõe-se que os testadores sejam todos de nível básico e devem ser pagos de acordo.
Ninguém gosta de ser criticado, e é muito comum que programadores defensivos não gostem de testadores porque seus trabalhos exigem que aponte erros do programador o dia todo. Como gerente, eu estava constantemente em uma missão de relações públicas para lembrar aos programadores que a equipe de controle de qualidade estava lá para fazer com que parecessem bons, e não incomodá-los.
Tende a ser um trabalho em que as pessoas entram por acidente e não por opção, pelo menos inicialmente. Não me lembro de nenhum plano de graduação em nenhuma das escolas que frequentei que preparou as pessoas para as perguntas e respostas sobre software. Eles existem, mas geralmente nas escolas profissionais de nível inferior, o que apenas contribui para a ideia de que são profissionais menos qualificados.
Os trabalhos de teste são muito mais prováveis do que os trabalhos de programação a serem enviados para o exterior. Pelo menos os programadores podem argumentar que é mais eficiente comunicar as necessidades de design localmente e que é valioso manter o conhecimento de como o aplicativo principal da empresa funciona dentro da empresa. Os testes, no entanto, são muito mais fáceis de modularizar e, portanto, mais fáceis de terceirizar.
Por todas as razões acima, os testadores tendem a ver a escrita na parede e a se mudar para outros trabalhos (como programação), especialmente os realmente bons. Isso significa que a maioria dos trabalhos de teste tende a receber mais pessoal de nível básico que ainda não o esgotou ou se mudou para outras coisas, o que infelizmente reforça várias das idéias acima.
Depende da empresa, mas geralmente. Eles geralmente são vistos como cidadãos de segunda classe e, em muitas empresas, o teste é visto como uma posição básica, da qual você passaria a se tornar um desenvolvedor de verdade.
Claro que isso é uma porcaria. Tendo trabalhado com alguns bons testadores, posso dizer que eles são valiosos e difíceis de encontrar. Alguém com uma mente que é criativa o suficiente para encontrar erros não óbvios e metódica o suficiente para fazer um trabalho completo.
Porém, uma exceção: conheci alguns profissionais de teste da Microsoft e soube que os testadores são cidadãos de primeira classe.
Trabalhei como testador funcional por um ano em um projeto bastante grande. Cada equipe de cerca de 10 membros tinha 2-3 testadores. Devo dizer que fomos tratados como igualmente importantes para o projeto como os desenvolvedores.
Encontrar bugs não é fácil. Primeiro, os testadores precisam entender o que o código deve fazer. Isso significa ler e entender os requisitos. A chave aqui é entender os requisitos - se os testadores não conseguirem entender os requisitos suficientemente bem para saber como escrever casos de teste positivos, você deve estar preocupado. Isso significa que os desenvolvedores escreveram algum código que faz o que eles assumiram. Essa suposição é a correta? Você não sabe até resolver os requisitos e pode agradecer a seus testadores por encontrar essa falha.
Segundo, os testadores precisam escrever casos de teste falsos, o que garante que o código não faça o que não deveria. Uma regra prática razoável é que você escreva de 5 a 10 casos de teste falsos para cada caso de teste positivo. Isso significa entender ainda mais os requisitos, e muitas vezes issoas informações são, ou estavam pelo menos em nosso projeto, confusas e ambíguas. (E não foi por causa do baixo esforço na coleta de requisitos - tínhamos algo em torno de 13.000 em nossa equipe.) Novamente, os desenvolvedores escreveram seu código usando suas suposições, ou pior, nem sequer consideraram isso. Então, o que o código faz sob essas condições que não são normais? Você não sabe até testá-lo. Talvez o programa não responda; talvez apenas trate; talvez destrua dados; talvez permita que o usuário execute comandos como usuário root. Faça o que fizer, você quer saber. Caso contrário, você poderá ler o título a seguir no jornal um dia - ERRO NO PROGRAMA DE BANDEIRA DA [NOME DA SUA EMPRESA] VAZ NÚMEROS DE CARTÃO DE CRÉDITO DOS CLIENTES.
Portanto, trate bem seus testadores. Trate-os bem. Afinal, eles são os que eliminam os bugs do seu software e facilitam sua vida e a nossa.
Bons testadores que conseguem analisar problemas com eficiência e podem fazer automação decente valem seu peso em ouro, pois há muitos testadores de caubói por aí (ao entrevistar um "testador" quando ele realmente riu quando percebeu que sabíamos que estava fazendo coisas no local enquanto é questionado em seu currículo).
Na minha equipe, o testador é tratado como igual - o que inclui responsabilidade e salário. Se você deseja um testador que clica no próximo dia inteiro - terceirize-o para um local mais barato (também fazemos isso).
Atualize depois de ler outras respostas: Existem muitos profissionais de controle de qualidade que amam o trabalho que fazem. Apenas para dar outra perspectiva, se você não se deparar com nenhuma posição respeitada no controle de qualidade, um exemplo aqui: Aplicativos incorporados / teste de aplicativos móveis para as principais montadoras. Eles garantem que os requisitos de negócios sejam completamente atendidos antes que um veículo seja lançado no mercado e que nenhum usuário experimente um painel de carro lento ou que não responda. Eles trabalham em estreita colaboração com gerentes e gerentes de nível superior, e também com os desenvolvedores, desde o planejamento do processo de controle de qualidade até os testes práticos em simuladores nas instalações de design. Eu não consigo pensar neles sendo discretos, eles lidam com enormes responsabilidades e propriedade e estão entre os melhores engenheiros.
agora minha resposta anterior, o outro lado:
Eu observei que os graduados em engenharia odeiam ser alocados para unidades de teste (contexto: Índia, grandes empresas de serviços de software onde tudo é orientado por 'requisitos de negócios'), uma vez que o consideram um ambiente de trabalho não técnico. Eles recebem planilhas do Excel com instruções como 'clique em todos os links da página da Web e verifique', são forçados a trabalhar com graduados de fluxos não técnicos (ciências, artes) que consideram uma humilhação e sentem que suas habilidades técnicas não são utilizado. Essas alocações são puramente baseadas nos requisitos da organização e, na maioria das vezes, uma atualização não tem o poder de negociar sua carreira. Portanto, se você procura emprego, visa uma empresa de TI tão grande, foi avisado. Você não pode fazer muito, praticamente, exceto sair da empresa na hora certa.
A menos que haja oportunidades para aprender testes automatizados, testes de carga / desempenho, etc., a carreira é estagnada até certo ponto. minha organização do que qualquer outra unidade. Eles trabalham com todas as verticais do setor como preenchimento ou cola, pois os testes são inevitáveis em projetos em todos os domínios.
Se você está confiante de que pode conduzir sua carreira da maneira que quiser, o teste não é nada discreto. Com 4-5 anos de experiência e um pouco de sorte, você pode obter uma exposição muito boa, às vezes interagindo com os usuários corporativos de nível superior. Você também pode ter uma boa noção do setor / domínio em que está trabalhando (em comparação com um desenvolvedor que se concentraria principalmente em alguma parte do sistema). Nesse ponto, pode-se optar por mudar também para uma função de analista de negócios.
Conheço empresas nas quais a equipe de controle de qualidade é responsável por lançamentos. Isso significa que eles têm o poder de bloquear uma liberação devido à falta de qualidade. Se um problema for relatado no campo, eles serão os primeiros na linha de fogo (logo após o engenheiro de campo).
Normalmente eles têm maior conhecimento de domínio. Eles tendem a conhecer melhor a funcionalidade geral do produto, enquanto os desenvolvedores se concentram em seus módulos / recursos.
Também conheço organizações de controle de qualidade em que eles precisam escrever suas próprias ferramentas de teste. Sem mencionar a automação de todo o material. Sou desenvolvedor e sempre valorizei os funcionários de controle de qualidade que testam meus recursos.
Pelo menos na minha organização, o controle de qualidade é tratado igualmente com os desenvolvedores. Eu acho que é por causa do domínio (telecom) onde o conhecimento de protocolo e arquitetura de rede é igualmente valorizado com habilidades de programação.
Sim. Goste ou deixe, são igualmente importantes, mas são sempre menos preferidos. Pode ser porque eles são fáceis de substituir.