As equipes da Unruly tem aplicado eXtreme Programming (XP) desde a sua fundação em 2006. O desenvolvimento de software na Unruly é feito com equipes pequenas sem testadores dedicados. Estas equipes tem uma abordagem test-first (teste antes) de desenvolver o código, criando validações automatizadas que podem ser executadas em ambientes similares aos de produção, ao invés de se apoiar numa fase de testes manuais.
Rachel Davies, Agile Coach na Unruly, apresentou uma palestra sobre teste contínuo no Agile Testing Day Netherlands 2015. O InfoQ.com entrevistou Davies para saber mais sobre a importância da abordagem de teste contínuo, como isto tem evoluído e as vantagens de negócio que esta abordagem traz à Unruly.
InfoQ.com: Por que os testes automatizados são tão importantes para suas equipes?
Davies: É tão importante porque as validações automatizadas são mais rápidas e mais confiáveis que pessoas validando o software manualmente. Os testes manuais são muitas vezes uma atividade pouco prazerosa. Queremos conseguir entregar as mudanças no produto no mesmo dia que a equipe de vendas as solicita. Para que isto seja possível, automatizamos os scripts de deploy das aplicações, que também tem testes automatizadas. Um computador pode executar tarefas repetitivas muito mais rápido que um ser humano, e por isso a automação ajuda a entregar soluções que agregam valor mais rapidamente.
InfoQ.com: Pode dar alguns exemplos de como os testes automatizados estão ajudando as equipes na Unruly a entregar valor ao negócio?
Davies: Uma pessoa de vendas pode pedir por uma mudança em sistemas em tempo real e queremos entregar isto em horas e não em dias. Temos uma situação incomum porque não há nenhum ambiente intermediário que o código deve passar. Ao invés disso, colocamos as mudanças direto no ambiente de produção porque queremos entregar valor mais rápido. Embora as novas mudanças do código estejam disponíveis no nosso ambiente de produção, temos muitas maneiras de não revelar aos nossos usuários online no mesmo instante. O que fazemos é trabalhar em pequenas etapas dos nossos testes automatizados para validar se o comportamento esperado está presente. Qualquer problema com testes lentos ou inseguros são discutidos durante as retrospectivas da equipe.
InfoQ.com: Durante anos se investiu em testes contínuos. O que fez com que eles valessem a pena serem feitos? Quais benefícios os testes contínuos trouxeram?
Davies: Ao ter uma abordagem test-first temos uma grande cobertura de testes para validar que as funcionalidades dos nossos produtos funcionam como esperado. Conseguimos rapidamente identificar se as mudanças quebram as validações automatizadas existentes. O monitoramento automatizado dos nossos serviços em tempo real nos ajudar a identificar condições que não havíamos previsto. Ao guiar nosso desenvolvimento com testes também ajuda nossas equipes a focar no que eles precisam entregar e a manter o produto rodando.
InfoQ.com: Durante o Agile Testing Day Netherlands foi falado sobre como são feitos os testes automatizados com validações que estão rodando continuamente em seu ambiente de produção em tempo real. Pode descrever como isto funciona?
Davies: Temos alertas do Nagios configurado para que a equipe receba notificações em varias situações dos nossos serviços. Recebemos notificações via SMS quando os problemas acontecem e temos grandes monitores na área de desenvolvimento exibindo a carga e o desempenho do software dos nossos ambientes em tempo real. Se estiver interessado, temos um post no blog de um de nossos desenvolvedores sobre monitoramento de mau-cheiros.
InfoQ.com: Pode nos contar um pouco mais de como os testes automatizados na Unruly evoluíram ao longo dos anos?
Davies: A empresa foi fundada em 2006 usando XP e práticas de TDD (desenvolvimento guiado por testes) e por isso os testes foram automatizados desde o início. Ao longo dos anos tivemos que expandir estes testes para navegadores e dispositivos móveis (já que os navegadores e as plataformas desenvolveram mais capacidades). O produto expandiu e há atualmente um grande movimento para web com sites mais "responsivos" tanto em desktop, tablets e celulares. Tablets não eram considerados em 2006.
Não adotamos o estilo de testes do BDD, que pode ser lido por pessoas não-técnicas, já que tivemos más experiências quando utilizamos o FiTnesse para automatizar os testes de aceitação. Nossos desenvolvedores conversam diretamente com os stakeholders (pessoas interessadas) e não com analistas de negócios. Os testes são escritos e lidos pelos desenvolvedores na mesma linguagem de programação que o código. Por isso tem pouco benefício escrevê-los no estilo do BDD.
InfoQ.com: Falou se que estão usando "Chaos Monkeys" nos testes. Pode nos contar mais sobre isso?
Davies: Inspirado pelos "Chaos Monkeys" de infraestrutura do Netflix, desenvolvemos "macacos" específicos para o nosso domínio para injetar erros potenciais no nível da aplicação do nosso ambiente de produção, como serviços não-responsíveis na latência crítica das aplicações. Esta abordagem nos ajuda a identificar e corrigir erros que não se manifestaria num ambiente de testes. Um dos nossos desenvolvedores, Alex Wilson, escreveu um post no blog sobre injeção de erros de aplicação em produção.
InfoQ.com: Existem outras técnicas de teste que parecem promissoras, técnicas que suas equipes estão pensando em experimentar?
Davies: Devemos nos beneficiar ao gastar mais tempo em testes exploratórios manuais. O definição clássica é "aprendizado, projeto de testes e execução de testes de forma simultânea." do conhecido livro "Lessons Learned in Software Testing" (sem tradução para o português) dos autores Cem Kaner, James Bach e Bret Pettichord (2002). Este é diferente da validação automatizada e ao invés disto explora ativamente o comportamento dos sistemas sem um script para aprender como o sistema se comporta em maneiras não pensadas anteriormente.
InfoQ.com: Se uma empresa estiver interessada em testar publicações contínuas, quais seriam seus conselhos?
Davies: Comece com a automatização de todos os testes de regressão e não fique apenas com na visão do BDD. Comece automatizando as validações básicas de sanidade e gradualmente aumente a cobertura dos testes. Comece com aqueles que tiverem lógica de negócio mais críticas ou com áreas com maior incidência de erros.