Automatize testes do seu projeto sem escrever uma linha de código.
Já imaginou automatizar diversos testes do seu projeto, sem escrever uma linha de código? Pois é, isso é possível e vou contar com detalhes como fazer isso.
Você, como Engenheiro de Qualidade, possivelmente já passou por uma dessas situações:
- Foi contratado para uma vaga onde exigia que você fosse “automatizador de testes”, e depois da contratação, só atuou com testes manuais por não ter tempo para automatizá-los;
- Não conseguiu essa mesma oportunidade, por não saber automatizar testes; e,
- Não aprendeu automação na posição atual, por não tido “tempo” ou “oportunidade” para aprender (entre outros motivos).
Esses são alguns exemplos da realidade no mercado de desenvolvimento de software, que reage rapidamente às mudanças, entretanto, nem sempre isso é feito de forma organizada e planejada para garantir a qualidade do que está sendo desenvolvido.
Diante disso, esse problema afeta o bolso dos clientes e nosso também, pois investimos em cursos e treinamentos nos preparando para um ambiente que não está maduro o suficiente para nos receber e é esse ponto que vamos trabalhar.
Resiliência é a chave do sucesso em nossa profissão.
Antes de iniciármos, é importante que você esteja aberto para novos conhecimentos sobre testes, paciência, muita dedicação e mudança no seu modo de agir e pensar.
É importante lembrar da velha frase, “…quanto mais tarde testamos, mais lento e caro será o projeto para o cliente…”. Esse é um excelente argumento para convencer seus gestores e aplicar o que abordaremos adiante.
Na imagem acima, vemos a famosa pirâmide de testes, onde os unitários e componentes são os que mais necessitam de esforços, é por lá que começaremos automatizando sem escrever uma só linha de código.
Você deve estar se perguntando: Como programar meus testes, sem ao menos colocar a mão no código? E a resposta para esse questionamento é: Aplicando Pair Programming (Programação pareada ou em pares) com os desenvolvedores do seu time.
A programação pareada é uma técnica de desenvolvimento de software ágil em que dois programadores trabalham juntos em uma estação de trabalho. Um deles, o “controlador”, escreve o código, enquanto o outro, chamado de “observador”, analisa cada linha do código.
Evitando distrações e criando um ambiente colaborativo, em geral, a programação pareada se prova mais produtiva do que a isolada. Enquanto está analisando, o observador também considera a orientação estratégica do trabalho, dando ideias para melhorias e comenta sobre possíveis problemas futuros que devem ser resolvidos. Isso libera o controlador para concentrar toda a sua atenção nos aspectos táticos da tarefa atual. — Wikipedia
Dado que vivemos em meio a uma onda de transformação ágil, se você não aprendeu a surfar, a hora é agora.
Na minha experiência, pouco mais de 10 anos, atuando com qualidade de software, pude perceber que, a maior dificuldade dos desenvolvedores nessa tarefa, está na concepção dos cenários e escrita dos testes. Para resolver essa questão, quem é o cara que tem esse domínio? Isso mesmo: Você, Agile Tester!
Descobrimos quem vai automatizar os testes com você, ok? Vamos para os passos onde descobriremos com aplicar isso?
Partindo da premissa que atue no modelo ágil de desenvolvimento de software, podemos nos organizar com o time, apresentando o projeto de melhoria na qualidade, agendando uma reunião ou utilizando a cerimônia de retrospectiva para levantar essas ações.
As métricas da cobertura de testes do momento atual, também, são artefatos importantes para, depois de um determinado período, mensurar a evolução.
Dado os alinhamentos com a gestão e com o time, é hora de começar!
Agora, nesse primeiro momento, você e o desenvolvedor escolhido focarão na atividade, a medida em que necessitarem criar um método ou componente, farão primeiro a automação dos testes, conforme apresentado abaixo:
Nesse momento você implementará a técnica de TDD “Test-Driven Development” (Desenvolvimento guiado por testes) na sua equipe:
- Criando cenários de testes automatizados que falhem, numa primeira execução;
- Implementando os métodos da aplicação, fazendo com que os testes passem; e,
- Refatorando os dois códigos até que estejam de maneira aceitável, garantindo o funcionamento do software da melhor maneira possível.
Pronto, você já deu seu primeiro passo rumo a um projeto com automação de testes sem escrever uma só linha de código.
Após a execução dessa técnica, durante algumas iterações do time, você avaliará se estão prontos para dar o próximo passo, podendo ser uma das duas opções abaixo (muito parecidas) e ambas exigirão mudança cultural da empresa.
A primeira prática que podemos utilizar nesse segundo momento, é a implementação do BDD “Behavior-Driven Development” (Desenvolvimento guiado por comportamento), contribuindo com o time para um maior entendimento sobre o comportamento da aplicação de acordo com o negócio.
A segunda prática que podemos utilizar é o ATDD “Acceptance Test-Driven Development” (Desenvolvimento Orientado à Testes de Aceitação).
Os testes de aceitação são executados para validar a funcionalidade da aplicação. Imagine que você queira comprar um carro, você tem conhecimento sobre motores, no entanto, quer que o carro te leve de um lado para outro. Assim são os testes de aceitação, eles nos conduzem a realizar uma revisão das partes individuais, que funcionam corretamente trabalhando juntas, geralmente são testes de caixa preta, escritos em cenários especificados pelo cliente.
Discutir (Discuss):
- Durante a preparação do Backlog o PO (Product Owner), Desenvolvedores e QA (Quality Assurance) discutem a história do usuário usando exemplos de como ela será desenvolvida e quais são os possíveis cenários;
- O PO deverá registrar esses exemplos acordados como critério de aceitação para a história do usuário;
- O PO atualizará a história do usuário com os critérios de aceitação;
- O time de negócios analisará a história do usuário para verificar se atende aos requisitos;
- O PO buscará aprovação do cliente na história do usuário;
Refinar (Destill):
- O QA deverá refinar os exemplos descritos nos teste de aceitação;
- O QA apresentará casos de teste adicionais para aumentar a cobertura do teste.
Desenvolver (Develop):
- O desenvolvedor deverá desenvolver os recursos, colaborando com o QA para garantir que a funcionalidade esteja sendo construída de acordo com às expectativas dos casos de teste que estão sendo criados.
Demonstrar (Demo):
- Após, ou mesmo durante o desenvolvimento, o Desenvolvedor e o QA farão a demonstração do produto ao PO para validar novamente os testes de aceitação.
Um misto dessas 3 práticas (ATDD, BDD e TDD) também é possível, mas isso exigirá uma maior experiência e maturidade de toda a equipe.
Assim como o BDD, o ATDD poderá ser escrito utilizando o formato DADO, QUANDO e ENTÃO (Given, When e Then):
“DADO um contexto definido, QUANDO uma ação definida é realizada, ENTÃO espera-se que o sistema responda de uma forma definida.”
Cenário: Realizar cadastro
DADO que eu realize o meu cadastro na aplicação
QUANDO eu submeter o formulário
ENTÃO serei direcionado para o dashboard da aplicaçãoOs benefícios das atividades são inúmeros, citarei alguns aqui:
- Passagem do conhecimento de negócio por parte do Tester para o Desenvolvedor;
- Criação da cultura de responsabilidade da qualidade por parte de todos;
- O time passa a atuar na prevenção ao invés de correção de bugs;
- Cobertura de testes de acordo com as boas práticas apresentadas pela pirâmide de testes;
- Melhor qualidade dos testes automáticos, com a criação de cenários mais bem definidos e escritos;
- Testers que não automatizam, passarão a ter um contato próximo com o código e aprenderão a lógica da programação, principal conhecimento quando falamos em programação de softwares e testes, para posteriormente criar e dar manutenção;
- Desenvolvedores que não praticavam a criação de testes, aprendem a pensar com uma nova visão, a do testador/usuário da funcionalidade;
- Entrega de software que agregue valor ao cliente;
- Dar o primeiro passo, rumo a entrega contínua de software.
Para concluir, você não tem mais desculpas para projetos sem automação de testes, sabendo ou não programar, você poderá dar o primeiro passo, seguindo as sugestões acima.
Bibliografias:
- Test-Driven Development;
- Specification by Example;
- The Cucumber Book;
- ATDD by Example; e,
- Agile Testing.
Ficou com dúvidas, tem sugestões ou reclamações? Me procure nos canais da Bee Lab:
Ficarei grato por seu feedback!
Agradeço aos meus amigos que revisaram esse conteúdo: Bruno Nascimento de Figueiredo, Deborah Zavistanavicius, Ramilo Neves e minha esposa Camila Cardoso Meneghetti.
