LO
Testador de software / engenheiro de QA — tarefas, uma a uma
A unidade de análise é a tarefa, não o nome do cargo. Cada uma das seguintes traz a sua direção, se o juízo assenta em prova ou numa inferência da plataforma, o raciocínio e o que não estabelece.
Todas as tarefas desta página#
Testes de regressão manuais
A automatizar-se≈ Inferência da plataformaClicar pelos mesmos percursos em cada versão para confirmar que não se partiu nada do que funcionava.
A regressão com guião já era automatizável; o que mudou é que os agentes conseguem agora operar uma interface real a partir de uma descrição em linguagem simples e reparar os seus próprios guiões quando a interface muda, o que eliminou a carga de manutenção que mantinha as equipas nos testes manuais. É o maior bloco de horas da maioria dos lugares de QA e está a ir depressa.
É explicitamente o maior bloco de horas da maioria dos lugares de QA. Nada do que resta é grande que chegue para absorver as pessoas cuja semana ele enchia.
Escrever casos de teste e automatização
A automatizar-se≈ Inferência da plataformaTransformar requisitos em casos, e casos em guiões que correm no pipeline.
Gerar testes a partir de uma especificação ou do próprio código é um dos usos mais eficazes das ferramentas de geração de código, e uma cobertura que teria levado um sprint aparece agora numa tarde. Os testes gerados são superficiais da mesma maneira que o código gerado é — confirmam o que o código faz e não o que devia fazer — e é por isso que a tarefa seguinte conta mais.
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.
Testes exploratórios e adversários
Continua a ser levada por uma pessoa✓ Com provaTentar aquilo que ninguém especificou: a entrada esquisita, a condição de corrida, o utilizador que faz o passo 3 antes do 2.
Os testes gerados derivam da especificação ou do código, por isso partilham os seus pontos cegos. Encontrar a falha que ninguém imaginou exige um modelo de como utilizadores e sistemas reais se comportam mal, construído com experiência sobre este produto e este domínio. As ferramentas alargam a busca; a hipótese sobre onde olhar continua humana, e é aí que estão os erros caros.
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.
Decidir se sai
Continua a ser levada por uma pessoa✓ Com provaPesar os erros em aberto, o risco, o prazo e o negócio, e dizer sim ou não.
É uma decisão pela qual se responde e com consequências organizativas, e as equipas não mostraram qualquer vontade de a delegar. Os painéis resumem o estado; a decisão sobre que nível de risco esta versão, esta base de clientes e esta semana aguentam é tomada por uma pessoa em cujo critério a equipa confia.
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.
Testar sistemas com um modelo lá dentro
Tarefa nova≈ Inferência da plataformaAvaliar software cujo resultado não é determinístico — construir conjuntos de avaliação, apanhar regressões de comportamento, testar saídas nocivas.
A maioria dos produtos novos tem um modelo no circuito e não pode ser testada afirmando um resultado fixo. Desenhar avaliações, as instruções adversárias e a regressão de comportamento são uma disciplina nova com poucos praticantes, e a mentalidade de QA — assumir que está partido e descobrir como — transfere-se diretamente.
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.