Não existem QA’s balas-de-prata / uma crítica sobre automação de testes

Por volta de 2016 (segundo algumas referências de conversas de corredor) o mundo de tecnologia da informação em terras brasileiras sofreu um choque com a implementação da cultura ágil no seu dia-a-dia quase que da noite para o dia. O manifesto ágil em si nasceu em 2001 e é composto por 12 itens simples e nada técnicos. Porém junto com a implementação do ágil, surgiu uma idéia (que não está escrita em lugar nenhum) de que o testador deve ser um automatizador de testes.

Vamos imaginar por exemplo, uma indústria que fabrica peças de carro. Ela certamente deve ter um processo de teste de qualidade, que pode ser tanto manual, parcialmente automatizado como 100% automatizado.

No caso do teste manual é literalmente batendo o martelinho para se testar a resistência. Você pode ter uma esteira que lhe traga a próxima peça ou uma máquina para te ajudar a poupar tempo com atividades-não-fim, assim como você pode ter um robô que faça simplesmente (quase) tudo. Em cima disto é feito todo um trabalho análise de resultados e relatório que resultará na liberação ou não da comercialização do produto à fim de se evitar o tão temido recall. Sem dúvida o tester tanto de software quanto de produtos físicos, tem uma responsabilidade gigantesca para evitar prejuízos e proteger a imagem de qualquer empresa.

Ainda não tive a oportunidade de comprar um robô que limpe a casa, mas certamente ele não deve passar pano no chão, limpar os cantos e rodapés, muito menos limpar tudo do jeito que eu quero, lendo meus pensamentos.
É necessário um operador para parametrizar até os robôs mais complexos, e imagino que seja este o papel do QA em tempos de times ágeis e não criar o robô.

Um script de teste (literalmente codificado) é um software. Se um software codificado por um programador que possui formação e experiência na sua área, está sujeito a ter bugs, porque um script de teste (software “backend” sem interface visual e interação com usuário, provavelmente uma espécie batch rodando numa IDE) feito por um testador que não possui (e as vezes nem quer ter) conhecimento e experiência com programação, seria isento de bugs?

Devemos lembrar que sempre que o software principal for modificado, seja por implementação de nova feature ou refactor, é muito provável que o “software” de teste precise de alterações também.

Quando falamos de teste automatizado, é necessário que o software principal esteja em pleno funcionamento para que o script de teste seja concebido, ou seja, durante os testes (quase que manuais) do script de teste, o software principal será duramente testado 🤷‍♂. Claro todo este esforço será recompensado para regressões futuras…

A pró-atividade de uma pessoa buscar meios para automatizar processos do seu dia-a-dia é extremamente louvável. Seja um macro no excel ou uma engenhoca feita de fita-crepe, arame, palitos de sorvete e arduíno. Porém não se deve esperar, muito menos impor, que os testadores hajam como engenheiros construtores de robôs.

No DevOps se usam tantas ferramentas para integração/entrega contínua, construção de software (build), monitoramento e etc, que não necessitam serem codificadas, então porque na automação de testes deveria ser diferente?