As equipas de software têm mais liberdade do que nunca. Têm acesso a uma grande variedade de ferramentas, e muitas delas são gratuitas. Existe uma abundância de componentes de código aberto disponíveis para criar aplicações. E, o melhor de tudo, muitos empregadores incentivam as equipas a configurar os seus próprios sistemas de desenvolvimento, metodologias e membros da equipa a trazerem as suas próprias ferramentas.
A liberdade de utilizar as ferramentas, os métodos e as tecnologias de que mais gosta e que melhor conhece contribuirá provavelmente de forma positiva para a produtividade da sua equipa — até ao momento em que atingir os limites da autonomia da equipa.
Evite um estrangulamento nos testes
O meu amigo Jan liderava uma equipa de software muito competente numa empresa de desenvolvimento de software à medida. Compreendiam realmente como ser ágeis. E tinham um problema de qualidade. Aceleraram tão bem o seu ciclo de lançamento que os testes se tinham tornado um estrangulamento.
E resolveram o estrangulamento ignorando os testes. Jan, evidentemente, compreendia o que era necessário fazer. Descarregou o Robot Framework, utilizou-o para criar uma estrutura personalizada de automatização de testes para a equipa e integrou-a no seu processo de integração contínua. Gradualmente, foi adicionando cada vez mais testes e alargou a estrutura com um grande número de palavras-chave de alto nível para facilitar a criação de scripts de teste.
Entretanto, as outras equipas — e eram muitas — enfrentavam desafios semelhantes e resolviam-nos à sua maneira, utilizando o Selenium ou qualquer outra ferramenta da sua escolha.
As equipas precisam de uma estrutura de automatização para todos
Os pessimistas dizem que todas as soluções contêm a semente de um novo problema. Jan depressa descobriu que se tinha tornado engenheiro de automatização de testes a tempo inteiro. É certo que as suas bibliotecas eram fáceis de utilizar — para ele — e que a sua arquitetura de testes era fácil de compreender — para ele. Em todas as outras equipas, havia um colega na mesma situação. Um deles mudou de emprego. A programadora que o substituiu decidiu reescrever tudo, pois não gostava da forma como a automatização tinha sido criada e achava difícil compreendê-la. À medida que muitas equipas começaram a comunicar estes desafios aos seus gestores, surgiu a pergunta óbvia: porque é que não existe consistência entre as equipas?
Era necessário fazer alguma coisa. A solução era óbvia: vamos criar uma equipa centralizada de automatização de testes que sirva as equipas de desenvolvimento, fornecendo uma única estrutura de automatização para todos. Na prática, a equipa era constituída por Jan e outro programador. Foi nessa altura que a verdadeira luta começou.
Partilhe a metodologia, não apenas as ferramentas
Os testes falhavam frequentemente. O mesmo acontecia com a estrutura. As equipas de desenvolvimento tinham dificuldade em alterar as suas práticas para se adaptarem às ferramentas, e a equipa responsável pelas ferramentas tinha dificuldade em acomodar todas essas necessidades diferentes. A complexidade da estrutura continuava a aumentar. O estrangulamento dos testes tinha-se transformado num estrangulamento das ferramentas de automatização de testes.
As ferramentas internas partilhadas são uma ideia excelente, mas é difícil fazê-las funcionar. Para ter sucesso, a ferramenta tem de ser gerida como um produto real e tem de ser devidamente testada. Paradoxalmente, as estruturas internas de automatização de testes apresentam frequentemente erros. Mas existe um desafio ainda maior. Para beneficiar das ferramentas partilhadas em grande escala, também é necessária uma metodologia partilhada.
A história de Jan é típica — e ainda não terminou. Estão agora a ponderar o próximo passo: regressar a equipas autónomas e aceitar o custo, investir mais nas ferramentas partilhadas e estabelecer uma metodologia consistente, ou selecionar uma ferramenta comercial e concentrar-se apenas na metodologia. Nenhuma destas escolhas está errada, mas cada uma terá consequências diferentes.