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. [tweet]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.[/tweet]
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.
[tweet]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.[/tweet] Quando bem implementados, reduzem o custo total do sistema.
Veja também
- Testes bem feitos adicionam valor. Testes ruins são apenas custo.
- Livros que recomendamos: Unit Testing Principles, Practices and Patterns.
- Livros que recomendamos: Working Effectively with Legacy Code
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.
[tweet]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.[/tweet]. A “confirmação” de que o teste de aceitação está passando, facilita a “estabilização” do código, tornando o refactoring mais seguro.
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.
[tweet]Testes de aceitação bem feitos são indicativos menos “subjetivos” de quando uma implementação está realmente pronta.[/tweet] 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.