Abordagens eficazes de automação de testes para pipelines modernos de CI/CD

Artigos da página inicial do InfoQ Abordagens eficazes de automação de testes para pipelines modernos de CI/CD

Este item em japonês

31 de maio de 2023 20 minutos de leitura

por

Craig Risi

revisados ​​pela

Matt Campbell

A ascensão do CI/CD teve um impacto enorme no mundo dos testes de software. Com os desenvolvedores exigindo pipelines para fornecer feedback rápido sobre se a atualização de software foi bem-sucedida ou não, isso forçou muitas equipes de teste a revisitar suas abordagens de automação de teste existentes e encontrar maneiras de acelerar sua entrega sem comprometer a qualidade. Esses dois fatores muitas vezes se contradizem no mundo dos testes, já que o tempo costuma ser o maior inimigo na busca de um testador para ser o mais minucioso possível na obtenção da cobertura de teste desejada.

Então, como as equipes lidam com essa mudança significativa para garantir que sejam capazes de entregar testes automatizados de alta qualidade e, ao mesmo tempo, cumprir a expectativa de que o pipeline de CI retorne feedback rapidamente? Bem, existem muitas maneiras diferentes de ver isto, mas o que é importante compreender é que as soluções são menos técnicas e mais culturais - com a abordagem aos testes a necessitar de mudar em vez de grandes melhorias técnicas nas estruturas de teste.

Talvez a coisa mais óbvia a fazer seja mudar para a esquerda. A ideia de "mudança para a esquerda" (onde os testes são movidos mais cedo no ciclo de desenvolvimento - principalmente no nível de design e testes unitários) já é comum na indústria, impulsionada por muitas organizações e está se tornando cada vez mais comum. Ter um forte foco em testes unitários é uma boa maneira de testar o código rapidamente e fornecer feedback rápido. Afinal, os testes unitários são executados em uma fração do tempo (pois podem ser executados durante a compilação e não requerem nenhuma integração adicional com o resto do sistema) e podem fornecer uma boa cobertura de testes quando bem feitos.

Já vi muitos testadores evitarem a noção de teste de unidade porque ele escreve testes para um componente muito pequeno do código e há o perigo de que coisas importantes sejam perdidas. Muitas vezes, isso é apenas um medo devido à falta de visibilidade no processo ou à falta de compreensão dos testes unitários, em vez de uma falha nos próprios testes unitários. Ter uma base sólida de testes unitários funciona porque eles podem ser executados rapidamente à medida que o código é construído no pipeline de CI. Faz sentido ter o maior número possível e cobrir todos os tipos de cenários possíveis.

O maior problema é que muitas equipes nem sempre sabem acertar. Em primeiro lugar, o teste unitário não deve ser tratado como uma atividade de caixa de seleção, mas sim abordado com a análise adequada e o comprometimento com o design de teste que os testadores normalmente aplicariam. E isso significa que, em vez de apenas deixar os testes unitários nas mãos dos desenvolvedores, você deve envolver os testadores no processo. Mesmo que um testador não seja forte em codificação, ele ainda pode ajudar a identificar quais parâmetros procurar nos testes e os locais certos para garantir a entrega dos resultados corretos para a funcionalidade integrada a ser testada posteriormente. Excluir o envolvimento de seus especialistas em testes na abordagem de testes unitários significa que é possível que os testes unitários falhem algumas áreas importantes de validação. Muitas vezes é por isso que você pode ouvir muitos testadores dando uma má impressão nos testes de unidade. Não é porque os testes unitários sejam ineficazes, mas simplesmente porque eles muitas vezes não cobrem os cenários certos.

Um segundo benefício de envolver os testadores antecipadamente é adicionar visibilidade ao esforço de testes unitários. A quantidade de tempo (e, portanto, de dinheiro) potencialmente desperdiçada pelas equipes que duplicam os esforços de teste porque os testadores acabam simplesmente testando algo que já foi coberto pelos testes automatizados é provavelmente bastante alta. Isso não quer dizer que a validação independente não deva ocorrer, mas não deve ser excessiva se os cenários já tiverem sido cobertos. Em vez disso, o testador pode se concentrar em ser capaz de fornecer melhores testes exploratórios, bem como concentrar seus próprios esforços de automação em testes de integração nos casos extremos que, de outra forma, ele nunca teria coberto.