Alinhamento de propósito é fundamental para autonomia de atuação. Mesmo times técnicos competentes tem mais chances de falhar se não estiverem em “sintonia” com a intenção de suas implementações. Sem alinhamento, as entregas técnicas ficam mais frágeis e “imprevistos previsíveis” ocorrem com mais frequência, forçando, muitas vezes, os times a contrair dívidas técnicas para atender expectativas de prazo dificultadas pelo retrabalho.
Uma das maneiras mais eficientes que conhecemos para gerar alinhamento com os times técnicos é a explicitação clara dos objetivos através de critérios explícitos de aceitação. Esses critérios, se bem definidos, autorizam a escrita de testes automatizados de aceitação que são base para evolução correta do software.
A ideia é estabelecer um ciclo virtuoso de desenvolvimento de software, iniciando com testes automatizados de aceitação, e seguido pela implementação cuidadosa e detalhista suportada por testes de unidade.
Testes de aceitação com critérios claros são essenciais para alguma garantia de entrega do resultado e, mais que isso, garantir que esse resultado não seja prejudicado no futuro por regressão. Quando bem implementados, reduzem o custo total do sistema.
Veja também
A forma mais comum de implementação de testes de aceitação é end-to-end, geralmente, partindo da interface do sistema utilizando tecnologias como Cucumber, Selenium, Jasmine, entre outras. Entretanto, principalmente em sistemas backend, a implementação dos testes de integração pode ocorrer pela validação das interfaces públicas.
Um “efeito colateral” de testes de aceitação é que eles permitem a escrita de código, suportada por testes automatizados, para problemas com design complexo ou indefinido.. A “confirmação” de que o teste de aceitação está passando, facilita a “estabilização” do código, tornando o refactoring mais seguro.
Veja também
Definir objetivos e critérios de aceitação, permite a escrita de bons testes automatizados e ajuda no alinhamento de propósito, autorizando autonomia de atuação. É uma forma eficiente de tornar o time mais capaz, acelerando a aprendizagem, não só dos objetivos a serem alcançados, mas também sobre Arquitetura e Design do sistema. Além disso, converte torna parte da documentação de requisitos “viva”, colaborando para aumento da confiança e reduzindo a burocracia.
Veja também
- Quando não há confiança, a burocracia emerge.
Testes de aceitação bem feitos são indicativos menos “subjetivos” de quando uma implementação está realmente pronta. Não é raro que, durante o próprio processo de desenvolvimento, fiquem explícitas outras condições para a entrega – o que é bom, afinal indica maior apropriação das motivações e assertividade para o negócio.
Testes de aceitação automatizados são mais demorados para fazer, rodar e são mais frágeis. Com uma boa cobertura de testes de unidade e integração eu não conseguiria um bom resultado de qualidade? Pensando em uma equipe sem QA.
Olá Renan,
Sim, Martin Fowler defende que dentro da distribuição da suíte de testes End-to-End deve representar somente 10%. Porem, isto não quer dizer que não haja importância, pois este tipo de teste é o que possui a maior proteção contra regressões.
O Post está sugerindo agregar ainda mais valor a estes tipos de testes, ja que através de uma dinâmica de Alinhamento de Proposito devemos utilizar testes de aceitação para tornar visivel possíveis problemas como de Design, Arquitetura, Requesitos e entre outros.
Com certeza, unit testing e integration permanacem importantes para a qualidade das suas entregas.
Obrigado pelo seu comentário.