No artigo da semana passada nós explicamos quais são os testes que uma organização DevOps pode ter e o que eles fazem. Você pode conferi-lo clicando aqui! Hoje iremos mostrar como se deve implementar esses testes em 3 cenários diferentes.
Novos Projetos
Testes DevOps
Projetos novos representam uma chance de alcançar os ideais descritos… Nesse estágio, o custo de mudança é baixo e, estabelecendo algumas regras básicas e criando uma infraestrutura simples de teste, você pode iniciar muito bem seu processo de integração continua. Nessa situação, o mais importante é começar a escrever testes de aceitação automatizados desde o começo. Para fazer isso você deve:
- Escolher a plataforma de tecnologia e as ferramentas de teste.
- Preparar uma compilação automatizada e simples.
- Trabalhar com histórias que seguem os princípios INVEST* (elas devem ser Independentes, Negociáveis, Valiosas, Estimáveis, Pequenas e Testáveis), com critério de aceitação.
Você pode implementar um processo estrito quando:
- Clientes, analistas e testadores definem o critério de aceitação.
- Testadores trabalham com os desenvolvedores para automatizar os testes de aceitação baseando-se no critério de aceitação.
- Desenvolvedores codificam o comportamento para satisfazer o critério de aceitação.
- Se qualquer teste automatizado falhar (unitário, de componente ou de aceitação), a prioridade dos desenvolvedores passa a ser corrigi-lo.
É muito mais simples adotar esse processo no início de um projeto do que resolver algumas iterações depois que você precisar de testes de aceitação. Nesses estágios tardios, você não apenas precisa tentar descobrir novas maneiras de implementar os testes de aceitação – já́ que a estrutura para eles não existe em seu framework – mas também terá́ de convencer desenvolvedores céticos a seguir o processo de maneira diligente. Condicionar um time a testes automatizados é mais simples no início do projeto.
No entanto, é essencial que todos no time, incluindo clientes e gerentes de projeto, estejam convencidos desses benefícios. Conhecemos projetos que foram cancelados porque o cliente sentiu que se perdia muito tempo com testes de aceitação automatizados. Se os clientes realmente preferem sacrificar o conjunto de testes de aceitação automatizados para chegar ao mercado rapidamente, eles podem tomar essa decisão – mas as consequências devem ser expostas de forma clara.
Finalmente, é importante ter certeza de que seus critérios de aceitação são cuidadosamente escritos de forma que expressem o valor de negócio que a história entrega do ponto de vista do usuário. Automatizar cegamente critérios de aceitação mal escritos é uma das maiores causas da geração de conjuntos de testes de aceitação de difícil manutenção. Para cada critério de aceitação que você escreve, deve ser possível escrever um teste de aceitação automatizado que prove que o valor descrito é entregue ao usuário. Isso significa que testadores devem ser envolvidos na escrita dos requisitos desde o início, garantindo que um conjunto de testes de aceitação automatizados coerente e de fácil manutenção é mantido ao longo da evolução do sistema.
Ao comparar bases de código que foram desenvolvidas com testes de aceitação automatizados desde o início com aquelas em que testes de aceitação foram uma ideia tardia, nós quase sempre vemos melhor encapsulamento, intenção clara, melhor separação de preocupações e melhor reuso de código no primeiro caso. Este é realmente o círculo virtuoso: testar no tempo certo resulta em um código melhor.
No meio do projeto
Testes DevOps
Embora seja sempre prazeroso iniciar um projeto a partir do zero, na realidade quase sempre estamos trabalhando com um time grande e com pouco recursos desenvolvendo sobre uma base de código que muda rapidamente, sob pressão de entrega.
A melhor maneira de introduzir testes automatizados é iniciar com os casos de uso da aplicação mais comuns, mais importantes e de alto valor. Isso irá demandar conversas com o cliente para identificar claramente onde está o valor real de negócio e, em seguida, defender esta funcionalidade em oposição a regressões com os testes. Baseado nessas conversas você deve automatizar testes que cubram os caminhos esperados destes cenários de alto valor.
Além disso, é útil maximizar o número de ações que estes testes cobrem. Faça-os cobrir cenários um pouco mais abrangentes do que você normalmente faria com testes de aceitação por histórias. Preencha quantos campos forem necessários e pressione a maior quantidade de botões possíveis para satisfazer as necessidades do teste. Essa estratégia dá uma cobertura maior da funcionalidade testada nesses testes essenciais, mesmo que eles não mostrem falhas ou mudanças em detalhes no sistema. Por exemplo, você saberá que o comportamento básico de seu sistema está funcionando, mas pode não perceber o fato de que algumas validações não estão. Isso tem a vantagem de tornar os testes manuais um pouco mais eficientes, já que você não terá de testar todos os campos. você terá certeza de que compilações que passarem por seus testes automatizados funcionarão corretamente e entregarão valor de negócio mesmo se alguns aspectos de seu comportamento não são exatamente como você gostaria.
Esta estratégia significa que, já que você está automatizando apenas o caminho esperado, precisará executar uma grande quantidade de testes manuais para garantir que seu sistema está funcionando como deveria. você descobrirá que os testes manuais irão mudar rapidamente, já́ que irão testar funcionalidades novas ou recentemente atualizadas. No momento que você descobrir que está testando a mesma funcionalidade manualmente várias vezes, verifique se é provável que ela o mude novamente. Se não, automatize o teste. Da mesma forma, se descobrir que está perdendo muito tempo consertando alguns testes específicos, você pode assumir que a funcionalidade em teste está mudando. Novamente, verifique com o cliente e o time de desenvolvimento se este é o caso. Se sim, normalmente é possível fazer o framework de testes ignorar o teste, lembrando de detalhar o máximo possível o comentário no qual ele será ignorado para que você possa saber quando habilitar o teste novamente. Se suspeitar que o teste não será mais utilizado na forma que está, apague-o, você sempre poderá recuperá-lo do controle de versão, caso esteja enganado.
Quando você é pressionado pelos prazos, não poderá fazer muito esforço para lidar com cenários complexos com muitas interações. Nessa situação, é melhor utilizar uma variedade de dados de teste para garantir cobertura. Especifique claramente o objetivo de seu teste, descubra o script mais simples que satisfaça esse objetivo e complemente com o maior número de cenários possíveis de acordo com o estado da aplicação no início do teste.
Sistemas legados
Testes DevOps
Michael Feathers, em Trabalho eficaz com Código Legado (Bookman Editora, 2013), afirma, de maneira provocativa, que sistemas legados são aqueles que não possuem testes automatizados. Essa é uma definição útil e simples (no entanto, controversa). Essa definição simples implica uma regra simples: teste o código que você modifica.
Primeira camada do teste
A primeira prioridade ao lidar com tal sistema é criar um processo automatizado de compilação, se não existir, e então criar uma estrutura de testes funcionais automatizados à sua volta. A criação de um conjunto de testes automatizados será́ mais fácil se há documentação ou, melhor ainda, membros do me que trabalhou no sistema legado disponíveis. No entanto, em geral este não é o caso.
Frequentemente, os patrocinadores do projeto são relutantes em permitir que o time de desenvolvimento use o tempo para algo que lhes parece uma atividade de baixo valor: criar testes para o comportamento de um sistema que já́ está em produção. “Isso já não foi testado no passado pelo time de QA?”. Então é importante manter o foco nas ações de alto valor do sistema. É fácil explicar ao cliente o valor de criar conjuntos de testes de regressão para proteger essas funções do sistema.
É importante reunir-se com os usuários do sistema para identificar seus usos de alto valor. Utilizando as mesmas técnicas, crie um conjunto abrangente de testes automatizados para cobrir essa principal funcionalidade de alto valor. você não deve perder muito tempo fazendo isso, já́ que isso é um esqueleto para proteger as funções legadas. Serão adicionados novos testes incrementalmente mais tarde para o novo comportamento. Estes são apenas smoke tests para o sistema legado.
Segunda camada do teste
Uma vez que estes smoke tests estão em vigor, você pode iniciar o desenvolvimento de histórias. É útil, neste ponto, usar uma abordagem em camadas para os testes automatizados. A primeira camada deve ser de testes simples e de rápida execução para problemas que impeçam que você execute testes uteis e desenvolva qualquer funcionalidade em que está trabalhando.
A segunda camada testa a funcionalidade fundamental para uma história específica. Na medida do possível, novos comportamentos devem ser desenvolvidos e testados da mesma maneira como descrevemos para um novo projeto. Histórias com critério de aceitação devem ser criadas para novas funcionalidades, e testes automatizados devem ser obrigatórios para a conclusão dessas histórias.
Às vezes isso pode ser mais difícil do que parece. Sistemas planejados para ser testados tendem a ser mais modulares e fáceis de testar do que aqueles que não o são. No entanto, isso não deve desviá-lo de seu objetivo.
Um problema específico desses sistemas legados é que o código não é muito modular e bem estruturado. Portanto, é comum que uma mudança em uma parte do código afete o comportamento em outra parte. Uma estratégia útil nessas circunstâncias é a inclusão de uma validação cuidadosa do estado da aplicação ao final do teste. Se você tiver tempo, pode testar caminhos alternativos da história. Finalmente, pode escrever testes de aceitação verificando e há condições excepcionais ou protegendo-se contra modos comuns de falha ou efeitos colaterais indesejados
Quer implementar testes na sua organização? Entre em contato conosco, nós podemos te ajudar!
Newsletter HNZ
Fique por dentro de nossos conteúdos se cadastrando na nossa newsletter semanal! Clique aqui!
