…se os desenvolvedores não escrevem testes de unidade e de integração/APIs?
A ideia deste post veio de algumas experiências que tive ao longo da carreira, onde testadores e desenvolvedores trabalhavam em “silos” ao invés de trabalharem juntos em busca do desenvolvimento de softwares de qualidade.
Nesse contexto, se esperava dos integrantes do “time de testes” que estes não só realizassem testes manuais, mas também que escrevessem scripts de testes de aceitação automatizados, para garantir um bom conjunto de testes de regressão, os quais auxiliariam em um menor tempo de feedback após alterações na aplicação.
Por outro lado, e principalmente devido a esta divisão dos times em “silos”, os desenvolvedores pouco se preocupavam com a escrita de testes de unidade e testes de integração/APIs, e muito menos com a utilização de práticas, tais como o desenvolvimento guiado por testes (também conhecido como TDD), prática esta, que ajuda em um melhor design da aplicação. Para eles, testar era coisa do “time de testes/QA”.
Atualmente, vivemos uma bela transformação no que diz respeito à evolução das práticas de desenvolvimento de software, onde cada vez mais empresas e profissionais estão engajados na cultura de desenvolvimento de software de forma ágil e enxuta.
O primeiro valor do Manifesto Ágil diz: valorizar indivíduos e interações mais que processos e ferramentas.
Além disso, destaco também alguns dos princípios por trás deste manifesto. São eles:
- Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
- Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e suporte necessário e confie neles para fazer o trabalho.
- O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através da conversa face a face.
- Contínua atenção à excelência técnica e bom design aumenta a agilidade.
- As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
Se pararmos para analisar cada um destes itens com relação ao contexto que estou lhes trazendo, é possível perceber algumas questões que não fazem nenhum sentido nos dias de hoje, como por exemplo, a separação de times em silos, a desconfiança entre times, e a não partilha de conhecimentos.
Profissionais com foco em qualidade e teste de software devem ser capazes de ajudar a disseminar a cultura e o valor por trás dos testes automatizados, em todas as suas camadas (veja a pirâmide dos testes), assim, obtendo maior engajamento por parte dos desenvolvedores para a colocar tais atividades em prática, em conjunto.
E profissionais com foco em desenvolvimento de aplicações devem ser capazes de ajudar profissionais de QA com relação a práticas de código limpo, padrões, revisões, e utilização de ferramentas que ajudam nestas atividades, para que estes possam desenvolver scripts de testes de aceitação mais robustos e de fácil manutenção.
Também, quando falo da cultura de desenvolvimento de software de forma enxuta, me refiro, principalmente, a questão da eliminação de desperdícios, onde o quanto antes descobrirmos problemas na aplicação, menos estaremos desperdiçando tempo e recursos. Portanto, profissionais com diferentes focos, devem trabalhar juntos e se ajudar, para que no fim, além de entregarem aplicações de excelente qualidade, também se sintam satisfeitos, parte de um time, confiáveis e sintam que fazem a diferença.
Não vou responder a pergunta inicial deste post: Os testadores devem escrever testes de aceitação automatizados se os desenvolvedores não escrevem testes de unidade e de integração/APIs? Minha ideia com este post é que você, que está lendo, reflita, e então encontre você mesmo a resposta.
Aguardo teu feedback e tenha uma ótima semana!
=D
TALKING ABOUT TESTING 
Então tá, o primeiro comentário vai ser meu mesmo =P … e vou fazer link com outro post que lancei no mesmo dia deste (https://medium.com/@walmyrlimaesilv/what-is-a-deployment-pipeline-and-how-it-helps-software-development-teams-6cb29917ceea#.xa8trwhj1). Neste outro post, meu amigo e colega de profissão, Elias Nogueira, me perguntou em um tweet: “O integration está separado de regression por algum motivo técnico?” E isso me fez pensar que tal separação ocorre, em alguns casos, pelo fato do não entendimento do ‘jeito certo de ser fazer testes automatizados’, onde acaba-se criando uma pirâmide de testes invertida, também conhecida como software testing ice-cream cone (https://watirmelon.com/2012/01/31/introducing-the-software-testing-ice-cream-cone/), onde existem muitos testes de UI (basicamente mantidos por um time de QA) e poucos ou quase nenhum testes nas outras camadas da aplicação. Alguém concorda? Discorda? Aguardo comentários!
Primeiro, ótimo post de reflexão 🙂
O que pode ter confundido eu e algumas pessoas no outro post (do Medium) não é o fato de ter um integration test, mas sim um regression test como nome específico mesmo, uma vez que, conceitualmente, sempre teremos um regression testing para todas as camadas. Mas são só nomenclaturas. Depois da tua resposta ficou claro 🙂
O que eu gosto muito de fazer é um regression com uma série de smoke em todas as camadas, para depois sim disparar as suites completas de cada fase/tipo de teste/item do pipeline. A referência é este slide 7: http://www.slideshare.net/elias.nogueira/acelerando-o-feedback-e-deploy-com-automao-de-testes
Abraço!
Já passei por uma situação assim: existiam pouquíssimos testes unitários por alguns motivos (a plataforma era muito complexa, precisa de muitos mocks e o time precisa de um pouco mais de treinamento para aprender a escrever testes melhores). Dada a correria de projeto, tomar as ações necessárias para melhorar a cobertura de testes unitários não foi possível, então os QAs investiram em automatizar na camada de UI. No fim, os testes foram muito válidos porque conseguimos pegar alguns problemas antes de ir pra Produção, porém o feedback era lento (alguns desses problemas poderiam ter sido alertados por testes unitários e corrigidos imediatamente ao invés de só na fase seguinte) e tínhamos uma suíte bem grande que demorava bastante pra executar (depois paralelizamos a execução).
Em resumo, acho que precisamos dos testes de UI nesses casos (algum teste automatizado é melhor que nenhum) mas é importante tentar equalizar o time pra investir na construção de testes em conjunto e olhando para todas as camadas a fim de não ter o sorvete (ou o cupcake https://www.thoughtworks.com/insights/blog/introducing-software-testing-cupcake-anti-pattern) e perseguir sempre a pirâmide.
🙂