BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Automação de testes: Prevenir ou remediar?

Automação de testes: Prevenir ou remediar?

Favoritos

Pontos Principais

  • Testes automatizados de interface do usuário (UI) não é tudo isso que parece ser
  • Testes exploratórios ainda tem muitos benefícios em relação à automação
  • Dividindo o trabalho em pequenas tarefas ajuda você a lançar mais rápido
  • Tendo um time que entende o que Agile significa pode ajudá-los a tomar melhores decisões
  • Concedendo tempo aos times para aprender no trabalho é a melhor maneira de favorecer uma cultura de aprendizado contínuo dentro da organização

Introdução

Uma série de equipes tendem a ver automação de testes como uma forma de aumentar a velocidade de entrega do software, porém isto é frequentemente percebido como sendo um gargalo dentro das equipes, mas e se olharem profundamente em suas práticas de desenvolvimento como um todo, eles poderiam obter melhores resultados.

Prevenindo bugs

Testes, e especialmente testes automatizados na de interface do usuário (UI), tendem a ocorrer apenas no pipeline de entrega do software, geralmente na tentativa de capturar bugs que poderiam parar o ambiente de produção e afetar os usuários finais (como um germe!). Testar nesse caso detecta os sintomas de um bug, e a correção implantada pelos desenvolvedores é a cura. Isto é como se esperássemos que nossos sistemas fiquem doentes para então tentamos agir e fazer algo a respeito.

Essa abordagem pode funcionar bem para equipes, entretanto, o ambiente atual de trabalho mais do que nunca nos direciona a produzir mais e mais rapidamente com menos pessoas. Contudo , essa abordagem não é sustentável a longo prazo. É o ponto na qual a abordagem de prevenção entra no lugar da abordagem de cura.

Realizando alguns ajustes ao modo como desenvolvemos nossos sistemas, podemos detectar problemas até mesmo antes deles ocorrerem, ou melhor ainda, minimizar a geração de bugs. Isso significa que estamos prevenindo a criação de bugs, ao invés de futuramente tentar remediar a causa. Como diz o velho ditado, prevenir é melhor do que remediar.

Iniciei em uma equipe mobile que criou e gerenciou nosso produto VOD (vídeo sob demanda). Naquele tempo, todos os testes eram executados manualmente e tínhamos uma média de duas à três entregas por ano para cada plataforma. Sabíamos e queríamos aumentar a velocidade das coisas, e um dos gargalos mais óbvios eram os testes. Cada ciclo de testes de regressão poderia levar aproximadamente duas semanas, isto quando nenhum problema fosse encontrado. Se um problema fosse encontrado, a equipe de desenvolvimento precisaria entender o problema, identificar uma correção, e então aplicá-la. Podendo então resultar em uma invalidação de qualquer teste já existente de tal modo que todo o processo deveria ser iniciado novamente, fazendo com que o ciclo de testes demorasse duas vezes mais.

Foi onde buscamos automatizar mais nossos testes de UI. Queríamos começar com pequenos testes para avaliar se isso poderia levar-nos na direção que queríamos, e optamos apenas por automatizar novas funcionalidades. Uma vez provado, buscamos automatizar áreas existentes do sistema ou problemas já conhecidos.

Usamos 3 amigos para entender como uma equipe, o que queríamos desenvolver e quais seriam os pontos chave de aceitação para as novas funcionalidades. Isso nos deu um ponto de início de como dividir uma funcionalidade e quais comportamentos dos usuários automatizar.

Então identificamos ferramentas das quais poderíamos utilizar para automatizar nossos testes (Calabash e eventualmente Appium), e executar os testes em ambientes reais. Nesse caso, isso foi em dispositivos reais ao invés de emuladores, o que resultou na criação de nosso próprio parque de dispositivos móveis para testes, mas também permitir que isso se expandisse em por toda a empresa.

Mais detalhes podem ser encontrados em uma série de três partes no meu blog: Automating BBC iPlayer mobile testing part one: 3 amigos para identificar casos de uso, part two: automation process, e part three: legacy vs new features.

Os benefícios que a automatização de testes nos trouxe.

Primeiramente, a automação ajudou muito pois agora poderíamos percorrer rapidamente simples cenários e receber feedbacks da forma que desejamos. Porém com o passar do tempo, e depois da primeira série de bugs, começamos a encontrar cada vez menos problemas.

Também notamos que ainda estávamos enfrentando problemas dado que não podíamos automatizar alguns cenários; por exemplo, qualquer funcionalidade relacionada com usabilidade tinha de ser testada manualmente. Desta forma chegamos a uma solução híbrida onde a automação poderia ser executada em cenários chaves rapidamente, como por exemplo, permitindo a equipe saber que não haviam quebrado nenhuma funcionalidade óbvia e permitindo testes exploratórios pudessem ser executados para novas funcionalidades, que poderiam ser automatizados se necessário. Sendo assim, é difícil de testar; estávamos propensos a cometer erros durante os testes ou simplesmente demorar muito para ser feito manualmente.

Um benefício inesperado indiretamente ligado a nossa jornada de automação foi que começamos a ter lançamentos mais rapidamente, criando um grande foco no que estávamos querendo alcançar. Isto resultou que começamos a dividir as novas funcionalidades em pequenos pedaços que poderiam ser trabalhados independentemente, e em seguida automatizados. Isso permitiu lançar esses pequenos pedaços no ambiente de produção e rapidamente e receber feedbacks dos usuários. Primeiramente isso não era visível, pois ainda estávamos tentando identificar cenários de automação. Foi apenas com uma retrospectiva que a equipe conseguiu ver que isso foi exatamente o que eles fizeram sem intenção. Simplesmente, começamos a dividir o trabalho em pequenas partes que tinham valor para o usuário final.

Investigando nosso estilo de desenvolvimento

Começamos a perceber que os testes automatizados de UI não estavam dando o retorno que queríamos. Por causa disso, começamos a olhar outras áreas do nosso processo de desenvolvimento para ver se poderíamos fazer qualquer melhoria. Mas um dos nossos problemas como uma equipe era que estávamos muito próximos dos processos para ver objetivamente o que estava funcionando e o que não estava. Para contornar isso, trouxemos um coach em agile para ajudar nossas equipes. Na verdade, trouxemos dois; um para ajudar nossa equipe a entender o processo que eles usavam, e o outro, um coach de engenharia, para ajudar a entender melhor o que realmente estávamos construindo em nossos sistemas.

Uma visão externa da equipe permitiu chamar a atenção sobre partes do nosso sistema sem o medo de ofender ninguém e a fazer simples perguntas para sabermos os motivos por trás dos nossos métodos de trabalho e quebrar a ideia de "sempre fizemos dessa maneira". Por exemplo, tínhamos o costume de ter colunas no nosso quadro para gerenciar nosso trabalho a fazer como coluna de backlog, próximo, dev, aguardando-testes, em teste, e feito, mas nunca havíamos questionado o porquê das colunas próximo e aguardando-testes. Nossos coaches foram aptos a ajudar questionando o porquê de deixarmos trabalhos nessas colunas, e o porquê desenvolvimento e testes eram vistos como duas atividades distintas. A abordagem dos coaches não foi somente para alterar processos, mas para vermos quais problemas estavam causando (perda de valor esperando em filas marcadas como próximo e aguardando-testes) e permitindo a equipe ver o trabalho pronto eliminando as colunas dev e testes, substituindo-as por uma simples e autoexplicativa coluna em progresso. Mais informações sobre os benefícios ao mudar para esse método de trabalho estão disponíveis no meu último post In test column.

O que aprendemos

Um dos maiores problemas que encontramos foi que tínhamos uma cultura de cargos acontecendo nas equipes, em termos de nossa prática de desenvolvimento ágil. Simplesmente por termos standups, trabalhar em pequenos times e lançar versões no final de cada sprint não significa que realmente éramos ágeis. Isto apenas significa que tínhamos algumas cerimônias que nos faziam parecer "ágeis". Descobriu-se que nem todo mundo tinha certeza do porquê fizemos o que fizemos, e até mesmo quais os supostos benefícios. Uma das primeiras coisas que fizemos foi esclarecer o que agile significava; isto é mais sobre entrega de software sustentável baseado em comentários objetivos, o oposto de apenas fazer o mais rápido possível, entregando seja o que for, torcendo o melhor por isso. Mesmo com clube de livros e discussões facilitadas com as equipes fizemos isso para trazer um melhor entendimento conjunto sobre a equipe. Isso ajudou os membros da equipe a ter uma melhor compreensão dos princípios por trás das práticas agile e a tomar melhores decisões no modo que eles trabalham.

Também começamos a olhar como realmente estávamos construindo nossos sistemas no nível do código, e experimentamos ver como nossos desenvolvedores estavam fazendo commit do código, qual a frequência e quão grande era o commit. Não era para culpar o desenvolvedor, mas para ajudá-los entendendo como um grupo afeta o código fonte, e tentar encorajar hábitos produtivos no desenvolvimento; assim como vários commits pequenos e focados durante o dia, ao contrário de grandes commits no final do dia. Mas caso fizessem um grande commit, isso era aceitável, mas deixe os outros desenvolvedores saberem porque fizeram isso, para que eles também possam aprender também.

Uma das nossas maiores mudanças com as equipes foi encorajar programação em pares, pois nenhum desenvolvedor jamais estaria trabalhando em uma funcionalidade sozinho. Isso acelerou revisões de código, consecutivamente as pessoas estavam menos prováveis a pegar atalhos quando elas eram responsáveis por algo. Isso também ajudou no aprendizado dos nossos membros mais juniores, fazendo com que fossem produtivos mais cedo do que nos métodos tradicionais dos projetos onde são inspecionados por membros mais experientes.

Meu conselho para um estilo de desenvolvimento mais saudável e mais produtivo

Trabalhe em equipe, e na equipe identifique como é um processo de desenvolvimento saudável e produtivo. Um método útil para iniciar essas discussões seria criar um clube de vídeo para a equipe. Isso permite que a equipe tenha algum tempo nas atividades do dia-a-dia em que possam utilizar aprendendo sobre novas ferramentas ou novas formas de criar software. No final de cada sessão, uma discussão em equipe é promovida pelo líder da sessão (gerente de projetos, líder técnico, ou a pessoa que trouxe a ideia para a equipe) para explorar a ideia de como a equipe poderia usar os conceitos para ajudar a equipe a tentar algo novo.

Escolha então um conceito para trabalhar com uma clara ideia de qual deve ser o resultado. Se pegarmos como exemplo teste unitário, o que significa teste unitário para a equipe? O que bons testes unitários trás para a equipe? Uma vez que você tenha essas respostas, desenvolvam múltiplas ideias em como você poderia alcançar isso então você pode escolher qual delas permite você testar seus resultados rapidamente e objetivamente. Na verdade, você quer claramente verificar se o novo processo ou técnica que você usou ajudou você a alcançar seus resultados ou se está fora do prazo. Se isso funcionou, ótimo. Se não, então você precisa parar? Fazer mais? Ajustá-lo? Você também quer decidir quem na verdade vai executar o experimento, e como eles vão comunicar isso de volta para o resto da equipe.

Lembre-se, se você quer que qualquer novo processo ou ideia tenha efeito dentro de uma equipe, todos eles necessitam de suporte com isso; caso contrário qualquer sinal de dificuldade a ideia irá parar ou será disseminada lentamente, com apenas as pessoas que investiram nisso tendo qualquer benefício.

Sobre o autor

Jitesh Gosai tem mais de 15 anos de experiência trabalhando com testes em uma larga variedade de empresas desde fábrica de dispositivos móveis até criadores de sistemas operacionais e desenvolvedores de aplicativos. Atualmente ele é o principal tester no setor de Rádio e TV trabalhando com as equipes de mobile, tv e web dentro da BBC para ajudar a identificar quais as melhores abordagens para os seus testes, e como os times devem se mover para DevOps e além.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT