Testador de software / engenheiro de QA

Clicar pelos mesmos percursos em cada versão para confirmar que não se partiu nada do que funcionava.

Transformar requisitos em casos, e casos em guiões que correm no pipeline.

Tentar aquilo que ninguém especificou: a entrada esquisita, a condição de corrida, o utilizador que faz o passo 3 antes do 2.

Pesar os erros em aberto, o risco, o prazo e o negócio, e dizer sim ou não.

Avaliar software cujo resultado não é determinístico — construir conjuntos de avaliação, apanhar regressões de comportamento, testar saídas nocivas.

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.

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.

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.

Refazer o posto

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.

Refazer o posto

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.

Movimento lateral

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.

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.