Automação, Porque é tão dificil implementar?

Importante ressaltar que neste topico iremos tratar sobre estrategias e formas de implementação de automação, não falaremos sobre ferramentas, bibliotecas, linguagens de programação, visto que existe uma grande variedade de ferramentas e linguagens utilizadas atualmente de forma eficiente, a melhor ferramenta será aquela que faz sentido ao projeto/cliente no momento.

Atualmente o mercado tem exigido como uma skill básica a automação, porém o problema não está exatamente nessa estratégia de testes, mas sim em como o mercado trata a automação em si, o mais normal é um cliente decidir possuir automação sobre o projeto dele ou a necessidade de ter esse tipo de teste em seu escopo, mas quando começar a realizar o código, não há planejamento, não há uma esteira definida, não há um Q.A atuando junto com o DevOps, apenas uma produção de código de forma aleatoria e desordenada.

Então voltamos para o titulo desse artigo, porque é tão dificil implementar a automação?

A resposta é mais simples do que parece, se a empresa não consegue responder Porque DEVO implementar a automação? É porque não há uma noção da função automação naquele momento, o que deve ser questionado é: será o melhor momento para começar a automatizar? No último artigo falamos sobre fluxos de processos e entendemos que deve ser simples e objetivo, aqui a premissa deve ser a mesma, a automação deve ser objetiva, qual e o intento da automação dentro do seu negocio? Onde ela será aplicada? O que devemos rastrear ? Como vamos metrificar?

Aqui devemos ter uma reunião com o cliente ou representante do cliente e entender se ele saber o que é esperado da automação, como funciona, sanar duvidas e deixar sempre claro que: Automação não é bala de prata e não deve substituir nos testes manuais, pois são muito mais sensiveis e caros. Depois de entender essas questões, devesse planejar, como utilizar isso de forma eficiente? como distribur dentro do meu atual fluxo de testes ? Automatizaremos as maiores dores dos clientes, a parte mais cara ou que pode render mais prejuizos? Devem passar nas esteiras de testes semana? Apenas quando houver realese ? Junto com testes de regressão ? Como será feito com novos projetos ?

Algumas empresas quando são cobradas de desenvolver automação, criam um scrip de testes sem um planejamento real de como ele será feito, isso serve apenas para volumizar casos de testes e dependendo do cenário não será bem visto ou produtivo, aqui o planejamento de como será usado deve se priorizado para fazer sentido em sua aplicação e então todo o plano de automatização deve ser entregue para aprovação. Dê preferencia para um documento completo contendo tudo que for decidido, desde o que sera automatizada, a quais ferramentas seram implementadas, qual devera ser o fluxo de revisão, aprovação, criação de branch, quantas pessoas iram trabalhar juntos etc..

Outro ponto que constantemente é deixado de lado é: atuação do Q.A com o DevOps, se a empresa houver arquiteto de testes será ele responsável por essa parte da implementação sem monopolizar conhecimento, senão houver então: o senior, especialista ou apenas o responsavel pela automação tem que estar junto, porém o q.a deve de alguma forma atuar pareando com o DevOps quando o assunto for automação nas esteiras, CI/CD, manutenção, ambiente etc..para desenhar a melhor forma de produzir as esteiras de testes, que irão desde quantas vezes os testes vão passar, quem deve receber os relatorios, quais actions devem ser ativados, manutenção de ambiente, produção de massa etc... Lembrando que ter um ambiente separado com massa controlada para a automação é o ideal, limpeza constante do ambiente também deve ser feito, pois dependendo do seu nicho, produtos ou itens corrompidos podem quebrar e sinalizar um teste falso.

Saber onde alocar os testes dentro do fluxo atual também deve ser bem planejado para que não existe apenas uma pessoa responsável para aplicar a automação ou que a esteira deve ser passada de forma correta quando houver datas excepcionais, como fim de projeto, realeses etc... Já ouvi apresentação onde automação seria passado em testes exploratórios e no fim não faria sentido, aqui devemos compreender o que é automação é, para que queremos os resultados, senão houver esse entendimento não haverá utilidade e não atrapalhará o fluxo.

Por fim e mais importante como devemos metrificar o avanço e resultado desses testes, devemos entender que automação não deve ser vista da mesma forma que o código de um desenvolvedor, metrificar sua funcionalidade por bugs registrados ou quanto dos scrips de testes foram codificados, não diz que é a melhor forma de ter essa skill, quando se foi feito o planejamento sobre automação, também devesse definir como apresentar os resultados, entender os gaps para correção de forma simples, normalmente OKRs podem responder a esse tipo de metrificação, porém devesse verificar qual a melhor ténica que faça mais sentindo de forma coerente para registrar esses resultados, um erro muito comum também é medir X % do sistema deve ser automazido e não quais os maiores problemas devem ser automatizado.

O que muitas vezes e ignorado é que a automatização para ser funcional e maximizar os testes, tem que ser muito bem planejada, podendo ser divida em 4 partes: Planejamento, Devops, Metricas e apresentação, não ignorar principalmente a primeira etapa para que se entenda como isso será aplicado de forma coerente.

Algumas dicas que podem ser lembradas são:

Mantenha seu codigo simples e curto;

Quanto mais simples e independente seu código for, melhor para se dar a manutenção;

Quanto mais o Q.A estiver junto do planejamento e DevOps melhor;

Não acumule Scrip de testes, isso criará expectativas e cobranças desnecessárias;

Entenda os conceitos de automação, não apenas de código;

Pesquise ferramentas, bibliotecas, frameworks, formas de linguagens;

POO é uma boa forma de programar, porém Page Objetcs pode fazer mais sentido aqui;

Automação so deve andar quando o cliente entender como funciona e como será utilizada.

Não trate automação como se fosse um código de desenvolvedor.

Links de referências:

https://web.dio.me/articles/fluxo-de-processos-dentro-da-qualidade?back=%2Farticles&page=1&order=oldest

https://www.microsoft.com/pt-br/microsoft-viva/what-is-okr-objective-key-results

https://blog.onedaytesting.com.br/piramide-de-teses/