Avisa-me quando chegar um registo verificado a esta profissão → · Marque quais destas tarefas são suas (VOLO Pro, gratuito) → · Para uma equipa ou um curso de finalistas →
Testador de software / engenheiro de QA
Descobre como o software falha antes de os utilizadores o descobrirem — e é quem diz se está pronto para sair.
Encontra esta semana um erro que nenhum teste existente ou gerado teria apanhado, e escreve como te ocorreu. Esse texto é a tua descrição de funções.
Isto não é uma probabilidade de perder o emprego. Combina que parte da carga de tarefas do posto está exposta à automatização com até onde a adoção chegou de facto: serve para comparar profissões sobre uma base constante, e para mais nada.
Escrito para testadores manuais e engenheiros de automatização de testes em equipas de produto. Os testes de certificação em sistemas críticos (medicina, automóvel, aviação) e a QA de videojogos são outro caso.
O que está mesmo a mudar#
A unidade de análise é a tarefa, não o nome do posto. Um posto não é substituído: é a mistura de tarefas dele que se move.
Cada quadrado é uma tarefa. O tamanho é o peso que tem no trabalho; a cor, para onde a tarefa está a ir. Clique num quadrado para ver o que esse juízo não estabelece.
É o maior bloco de horas da maioria dos lugares de QA. Na Uber, os engenheiros de testes que executavam os guiões passaram a construir o contexto do sistema, e a empresa diz que os efetivos não cresceram na mesma proporção, e não que tenham diminuído; se as tarefas que restam conseguem absorver todas as pessoas cuja semana isto enchia não fica aqui estabelecido.
Os testes gerados confirmam o que o código faz e não o que devia fazer. As equipas que medem cobertura em vez de defeitos vão concluir que esta tarefa está resolvida, e é um problema de medição que prejudica os testadores.
A hipótese sobre onde olhar constrói-se tendo feito o trabalho de regressão que está a desaparecer. Esta tarefa está protegida por uma experiência que o circuito já não produz.
Em muitas equipas esta decisão é de um responsável de engenharia, e não de um testador. Onde é assim, protegê-la protege o lugar de outra pessoa.
Haver poucos praticantes é uma afirmação sobre agora. A disciplina é jovem que chegue para a sua dimensão final ser desconhecida, e pode acabar dentro das equipas de modelo em vez da QA.
É este o teu trabalho? Di-lo e esta página estreita-se à tua parte dele.
O nome de um posto é um pacote de tarefas compradas em conjunto, e não há duas pessoas com o mesmo pacote. Não é enviado nada para lado nenhum: fica neste navegador.
Mudanças recentes#
Um artigo de engenheiros da Uber sobre um sistema que corre nos pipelines da própria Uber. Diz que o DragonCrawl atinge uma taxa de sucesso de 91,6% em iOS e de 92,2% em Android em 1.013 testes automatizados que correm em contínuo em CI/CD, que reduziu a integração de um teste de 96–120 horas para menos de 4 e que poupou uma estimativa de 27 anos de trabalho de programadores em manutenção de testes; os engenheiros de testes que antes executavam guiões foram reposicionados como «Context Engineers» em vez de «Clickers», e a Uber diz ter conseguido uma garantia de qualidade escalável sem um crescimento proporcional dos efetivos. As poupanças de tempo são estimativas da própria Uber, e isto cobre testes móveis de ponta a ponta numa só empresa.
Uma empresa pô-lo em produção. Pode mover a linha de base, ponderado pela escala e por quanto esse contexto se parece com o teu.
Inquérito autodeclarado a 200 engenheiros seniores de grandes empresas dos EUA, do Reino Unido e da UE — e o relatório é publicado pela Lightrun, que vende ferramentas de depuração, por isso a conclusão e o produto apontam na mesma direção. As falhas da Amazon que cita (2 e 5 de março de 2026, atribuídas a alterações assistidas por IA implementadas sem aprovação, seguidas de uma revisão de segurança do código de 90 dias em 335 sistemas) são acontecimentos com relato independente; as percentagens não são. Apenas software de empresa.
Uma falha, um recuo, uma regulação ou um custo estão a travar a adoção. Pode baixar uma avaliação ou alargar a sua incerteza.
Um artigo de pessoal da Meta sobre a geração de testes na engenharia da própria Meta. Diz que a geração de testes de reforço baseada em LLM e guiada por mutações já está implantada no sistema de integração contínua da Meta, que o gerador anterior, baseado em cobertura, está implantado e tem evoluído regularmente na Meta há dois anos, que analisou 22 126 testes gerados nos fluxos de deteção e de reforço, e que, num estudo manual de 600 diffs com deteções fracas, os avaliadores baseados em regras e em LLM reduziram em cerca de 70% a carga de revisão humana. Os autores dizem que os próprios fluxos de deteção foram implantados sobretudo para recolher dados, e o artigo dá contagens inconsistentes das deteções confirmadas; a Meta constrói estas ferramentas para uso próprio.
Uma empresa pô-lo em produção. Pode mover a linha de base, ponderado pela escala e por quanto esse contexto se parece com o teu.
Um artigo de experiência revisto por pares, de autores universitários e da ByteDance, sobre uma ferramenta implantada numa grande empresa de internet de consumo. Diz que os testes de regressão de API para fluxos de negócio entre serviços continuam a ser em grande parte construídos e mantidos por engenheiros de QA, e que, numa implantação em produção de nove meses iniciada em março de 2025, a ferramenta gerou 3.196 casos de teste com uma taxa global de adoção do código de 85,4%. A adoção variou muito entre linhas de negócio; os autores construíram a ferramenta e mediram eles próprios a sua adoção.
Uma empresa pô-lo em produção. Pode mover a linha de base, ponderado pela escala e por quanto esse contexto se parece com o teu.
Um memorando federal que vincula as agências do executivo dos EUA. Entre as práticas mínimas de gestão de risco para IA de alto impacto, as agências têm de elaborar planos de testes prévios à implantação e de mitigação de riscos que reflitam os resultados esperados no mundo real; quando não conseguem aceder ao código-fonte, aos modelos ou aos dados, têm de usar métodos de teste alternativos, como consultar o serviço de IA e observar as saídas ou fornecer dados de avaliação ao fornecedor; e, depois da implantação, têm de realizar testes e uma revisão humana periódica dos casos de uso de IA, quando exequível. Vincula as agências, e não os testadores pelo nome, e só cobre usos de alto impacto.
Uma regulação, um subsídio ou uma compra pública estão a exigir ou a financiar a adoção: o espelho de uma restrição. Mostra que a adoção está a ser exigida, não que tenha acontecido, por isso um mandato nunca chega sozinho; dois independentes chegam.
Um artigo da equipa AI Red Team da Microsoft sobre o seu próprio trabalho a testar produtos de IA generativa quanto a falhas de segurança e de cibersegurança. Diz que, em outubro de 2024, a equipa tinha conduzido mais de 80 operações que cobriam mais de 100 produtos, que o volume tornava impraticáveis os testes totalmente manuais e que por isso construiu automatização, e que essas ferramentas não deveriam ser usadas com a intenção de tirar a pessoa do circuito, porque dar prioridade aos riscos, desenhar ataques e definir novas categorias de dano exigem critério humano. Trata-se de uma red team dedicada, e não da QA de produto, e a Microsoft vende os modelos e promove a sua ferramenta de código aberto.
Uma empresa pô-lo em produção. Pode mover a linha de base, ponderado pela escala e por quanto esse contexto se parece com o teu.
Uma empresa, melhoria de classes de testes unitários já existentes com filtros de compilação, aprovação e cobertura; 75% dos casos gerados compilaram, 57% passaram de forma fiável e 25% acrescentaram cobertura. Artigo escrito pela própria empresa; um contexto de maratona de testes limitada no tempo, e não de uso de rotina no pipeline.
Ensaio em pequena escala num contexto real. Diz-nos que as condições de implementação estão a ser testadas, não que se verificam, por isso um piloto nunca chega sozinho; dois independentes chegam.
O que isto significa para ti#
Entrar como testador manual é a entrada mais fraca deste sítio, porque é essa a tarefa que se vai mais depressa. Entra antes pela mentalidade adversária e pela disciplina nova: aprende a partir coisas que ninguém especificou, e aprende a avaliar sistemas baseados em modelos, onde quase não há ninguém com experiência e as equipas estão a contratar. Saber programar é já um mínimo do lugar e não uma especialidade dentro dele.
Se a tua semana é sobretudo regressão e manutenção de guiões, o lugar está a ser consolidado por baixo de ti e devias mexer-te antes de te mexerem. O teu verdadeiro ativo é o modelo que tens na cabeça de como este produto se parte; transforma-o em testes exploratórios, decisão de lançamento e avaliação das funcionalidades baseadas em modelos que a tua equipa quase de certeza está a acrescentar. São posições seniores, e são ocupadas por quem as reclamar primeiro.
As tuas opções#
Quatro direções, cada uma com as suas restrições reais e com uma coisa que podes testar esta semana. Continuar como estás é uma opção legítima; só tem de ser uma opção escolhida.
De executar testes a ser dono da qualidade
Alguém tem de decidir o que significa «testado que chegue», segurar a decisão de lançar e ser dono do trabalho exploratório. Esse papel sobrevive; o de executar não.
Exige que a equipa aceite o não de um testador, e isso depende de uma credibilidade que já tens de ter construído.
Encontra esta semana um erro que nenhum teste existente ou gerado teria apanhado, e escreve como te ocorreu. Esse texto é a tua descrição de funções.
Especializares-te em avaliar sistemas baseados em modelos
É novo, raro e está diretamente ao lado do que os testadores já fazem. As equipas que lançam funcionalidades com modelo precisam de alguém que assuma que estão partidas.
Exige estatística que podes não ter, à-vontade com um passa/chumba não determinístico, e ferramentas ainda imaturas.
Pega numa funcionalidade do teu produto que assente num modelo e escreve vinte entradas feitas para a fazer falhar ou comportar-se mal. Corre-as. Comunica o que encontraste como comunicarias qualquer erro.
Programador em testes ou engenharia de plataforma
Construir os pipelines, os ambientes e as ferramentas que permitem a toda a equipa testar é trabalho de engenharia com procura constante, e usa o conhecimento do testador sobre o que corre mal.
É um lugar de engenharia de software e vais ser julgado como tal; conta com seres avaliado em código.
Escolhe uma parte instável do pipeline de testes da tua equipa e arranja-a como deve ser. Se isso te deu mais gozo do que encontrar o erro, o caminho é real.
Perguntas frequentes#
A execução manual de testes é, e depressa. A qualidade como disciplina não é: alguém continua a ter de imaginar como o sistema falha, decidir se está pronto e — cada vez mais — avaliar software cujo comportamento não é determinístico, coisa que quase ninguém sabe fazer ainda. O lugar está a passar de executar testes para ser dono do risco, e de afirmar resultados fixos para avaliar comportamento. Quem faz essa mudança vale mais do que os testadores valiam; quem não a faz vai encontrar o lugar consolidado à sua volta.
O sinal é quem escreve a bateria de regressão da tua equipa este trimestre. Quando a bateria for gerada e se reparar sozinha depois de uma mudança de interface, o bloco de horas que financiava a maioria dos lugares de QA desapareceu — é essa a capacidade concreta que se moveu, e vais vê-la no teu próprio repositório antes de a veres em qualquer relatório.
A regressão manual e escrever casos de teste — as duas assinaladas como em automatização, e a regressão manual sozinha é o maior bloco de horas da maioria dos lugares de QA. Os testes exploratórios e a decisão de lançar não estão, mas nenhum é grande que chegue para absorver as pessoas cuja semana a regressão enchia.
É uma disciplina genuína e a crescer — conjuntos de avaliação, regressão de comportamento, instruções adversárias — e a mentalidade de QA transfere-se diretamente. A ressalva honesta é que é jovem que chegue para ninguém saber que dimensão virá a ter, e pode acabar assegurada dentro das equipas de modelo em vez da QA.
A estudar para isto?
Estes cursos levam até aqui. As páginas deles desdobram quais das suas competências se transferem e o que costuma faltar a quem se licencia.
Em que assentam estes juízos#
Dos 5 juízos de tarefa desta página, 5 apoiam-se num evento verificado e 0 são inferência da plataforma, cada um etiquetado onde aparece. Por detrás há 2 dimensões tecnológicas, uma trajectória reconstruída desde que os modelos de linguagem chegaram ao público e 7 eventos verificados.
Ver que tecnologias, como chegou aqui e o método →
Onde se situa na classificação oficial: competências, conhecimentos e profissões afins →
Outros cargos na mesma função#
Uma empresa divide o seu trabalho em funções antes de o dividir em cargos. Estes estão em Tecnologia e dados ao lado deste — um facto sobre organigramas, não um juízo de que sejam parecidos ou de que estejam a mudar na mesma direcção.
Programador de software júnior · Engenheiro de software experiente · Programador frontend · Programador backend · Engenheiro de dados · Engenheiro de aprendizagem automática · Investigador de IA · Analista de dados · Cientista de dados · Estatístico · Economista · Analista de negócio · Responsável de sistemas de negócio · Técnico de suporte informático / helpdesk · Analista de segurança (SOC) · Engenheiro de DevOps / engenheiro de plataforma / SRE · Engenheiro de redes · Redator técnico / engenheiro de documentação · Gestor de candidaturas a financiamento
