Usando a análise de lacunas no processo de teste para alinhar desenvolvedores e Testadores

é uma crença amplamente difundida de que desenvolvedores e testadores se dão como giz e queijo. Os desenvolvedores costumam olhar para os testadores, vendo-os como um arrasto inflexível e inútil no desenvolvimento de novos códigos que não fornecem detalhes claros em seus tickets de bugs. Da mesma forma, os testadores costumam ver os desenvolvedores irritados por não mantê-los informados sobre as mudanças de código e por promover novas mudanças durante os ciclos de teste. É por isso que a análise de lacunas no processo de teste de QA pode ser especialmente benéfica para alinhar desenvolvedores e testadores.

embora essa visão possa ser apócrifa, muitas vezes é o caso de desenvolvedores e testadores não se comunicarem bem. Muitas vezes, a comunicação só acontece por meio de gerenciamento (gerentes de projeto e gerentes de linha) ou por meio de tickets no Jira. O resultado é que o teste geralmente acaba sendo inadequado. Em particular, muitas vezes o novo código é mal testado ou não é testado. A pesquisa mostrou que este novo código não testado é a maior fonte de futuros bugs e falhas. É aqui que entra em jogo o conceito de Análise de lacunas de teste.

neste blog, vamos explorar o que é a análise da lacuna de teste, mostrar como ela pode ajudar a identificar o código que precisa ser testado e explorar se essa abordagem é a panacéia que pode preencher a lacuna entre desenvolvedores e testadores.

o que é Análise de lacuna de teste?

quando você desenvolve um sistema de software pela primeira vez, é fácil ter certeza de que está testando todo o sistema. Os testadores são capazes de pegar as especificações do código e usar uma combinação de testes planejados e exploratórios para garantir que testem todas as partes móveis da base de código. No entanto, a maioria dos softwares não é estática. As empresas fazem lançamentos periódicos monolíticos de código de longa duração ou empregam algum nível de integração contínua e implantação contínua (CI/CD). Em ambos os casos, a base de código está mudando constantemente. No entanto, muitas vezes os casos de teste não são atualizados na mesma taxa. Às vezes, os testadores simplesmente não sabem que uma alteração de código foi feita. Outras vezes, a mudança de código é enviada logo após um determinado conjunto de testes ter sido executado. Esses testes parecem ter passado, mas a mudança de código pode tê-los quebrado.

a análise de lacunas de teste é o processo de identificação dessas lacunas onde o novo código foi implantado, mas ainda não foi testado. Isso requer uma combinação de análise estática de todas as alterações de código e análise dinâmica de todos os testes atuais. Ao comparar essas duas análises, você pode ver facilmente onde existem lacunas. Ou seja, áreas de novo código que foram testadas adequadamente. Normalmente, isso é feito plotando o código usando uma forma de diagrama de árvore onde o código é dividido em blocos funcionais, abaixo de cada bloco estão as classes constituintes, abaixo desses estão os métodos e funções reais. Em cada nível da hierarquia, o tamanho relativo do bloco indica a quantidade de código. Ao sobrepor a árvore que mostra as alterações de código com a árvore que mostra o estado atual do teste, é fácil identificar as áreas onde há cobertura de teste ausente.

um mapa em árvore mostrando código inalterado( cinza), código revisado/novo que é testado (verde), código revisado que não foi testado (laranja) e novo código que não foi testado (vermelho).

Por Que a análise de lacunas de teste pode ser importante no processo de teste?Em um artigo de 2013, pesquisadores da Universidade Técnica de Munique realizaram um estudo para analisar a correlação entre novos códigos não testados e futuros bugs de software. Eles trabalharam com a Munich Re (uma grande companhia de seguros), monitorando seu sistema de TI de longa duração por meio de 2 Lançamentos. Durante o lançamento, eles estabeleceram qual código era novo e também analisaram qual código foi testado e qual código foi lançado não testado. Depois disso, eles monitoraram o sistema por um longo tempo e rastrearam todos os bugs relatados de volta à fonte original. Eles descobriram duas coisas-chave. Em primeiro lugar, cerca de um terço de todo o código estava sendo lançado sem teste. Em segundo lugar, quando eles rastrearam os bugs que descobriram em geral entre 70 e 80% de todos os bugs estavam em código não testado. O gráfico abaixo mostra isso com mais clareza.

como você pode ver, o antigo código testado não tinha bugs. O novo código testado tinha entre 22 e 30% dos bugs e os bugs restantes foram distribuídos de maneira bastante uniforme entre o novo código não testado e o antigo código não testado. No entanto, como o novo código representou apenas 15% do Código geral, você pode ver que o novo código não testado foi responsável por um número desproporcionalmente alto de bugs.

a análise de lacunas de teste foi projetada para identificar este novo código não testado. No entanto, também pode ajudá-lo de outras maneiras. Por exemplo, porque monitora o que você está testando, ele pode identificar áreas de código existente que estão desatualizadas (por exemplo, eles ainda estão sendo testados, mas não estão realmente sendo chamados por nenhum código). Também pode destacar em quais áreas você precisa concentrar seus recursos de teste. Ao executá-lo regularmente, os gerentes podem melhorar o planejamento do teste, concentrando-se no teste de novo código e tentando garantir uma cobertura uniforme do teste.

Devs e Testadores alinhados através da análise da lacuna de teste

a análise da lacuna de teste é claramente um conceito poderoso. Mas também está claro que nem todas as equipes se beneficiarão igualmente com isso. As equipes que mais se beneficiarão são aquelas que mantêm bases de código de longa duração com lançamentos monolíticos periódicos. Em bases de código de longa duração, os desenvolvedores costumam trabalhar em código que foi escrito por outras pessoas. Os testadores podem estar contando com planos de teste produzidos várias versões antes. Tomados em combinação, esses fatores podem significar que ninguém está bem claro qual código está sendo testado ou como esse código interage com outras partes do sistema. Aqui, o TGA pode permitir que os testadores vejam exatamente qual código mudou, o que lhes permite se concentrar nisso. Eles também podem identificar código no sistema existente que não foi testado.

as equipes que usam CI / CD também podem se beneficiar dessa abordagem, pois permitirá que os testadores identifiquem rapidamente exatamente qual código é alterado e, portanto, permitam que se concentrem nisso. Ele também pode evitar o problema mencionado acima, onde um pedaço de código é alterado logo após ter sido testado e, em seguida, é liberado com as alterações não testadas.

por outro lado, as equipes que estão trabalhando em código novo ou de curta duração se beneficiarão menos, uma vez que, por definição, a maioria dos códigos não será testada no início. Aqui é importante usar metodologias de teste padrão para garantir que seu teste seja bom. Pode, no entanto, ser útil para essas equipes começarem a monitorar a cobertura do teste usando TGA, pois isso lhes permitirá evitar problemas futuros.

quais são os problemas potenciais?

existem alguns problemas com o TGA. Um dos maiores está relacionado ao fato de não poder dizer qual código está sendo chamado ativamente na base de código. Os desenvolvedores geralmente adicionam novo código em preparação para versões futuras, mas como isso está inativo, o pacote de testes não pode chamá-lo. Como resultado, esse código sempre aparecerá como novo código não testado. Igualmente, muitas grandes bases de código contêm blocos de código antigo ou órfão. Estes devem ser limpos periodicamente, mas novamente distorcerão a imagem para a análise da lacuna de teste.

outra observação importante é que só porque um pedaço de código é testado não impede que esse código desencadeie bugs em outro lugar. Alguns dos piores bugs são aqueles em que uma pequena mudança em um pedaço de código faz com que uma função ou método falhe em um bloco de código totalmente não relacionado. Portanto, é vital continuar fazendo testes exploratórios e testes de regressão. O que o TGA pode fazer é identificar áreas em sua base de código existente que não estão sendo testadas corretamente durante o teste de regressão.

que outras alternativas ajudam a preencher a lacuna?

a análise de lacunas de teste é definitivamente uma ferramenta útil para algumas equipes. No entanto, existem outras maneiras de evitar uma incompatibilidade entre o que seus testadores estão testando e o que seus codificadores estão codificando. Uma maneira é usar uma automação de teste mais inteligente que seja capaz de identificar onde e quando as coisas mudaram, tanto no front-end, mas também, o mais importante, no back-end. Aqui na Functionize, nossos testes usam impressões digitais inteligentes, juntamente com aprendizado de máquina e autocura, para reduzir a manutenção do teste. Isso permite que os testes se adaptem proativamente às alterações de front-end, bem como monitorem coisas como Chamadas de servidor, tempos de resposta e se os botões/funções estão realmente visíveis. Isso significa que seus testadores não serão pegos por alterações feitas no código de back-end ou alterações de design/CSS que alteram o layout de front-end. Nosso sistema inteligente também pode criar testes monitorando como os usuários estão interagindo com o sistema. Isso ajuda a garantir que haja menos lacunas na cobertura do teste. Uma das nossas ferramentas mais recentes permite que você escreva novos testes em inglês simples. Estes são analisados pela nossa ferramenta de Processamento De Linguagem Natural e convertidos em testes utilizáveis. Isso significa que, durante o desenvolvimento, os desenvolvedores podem simplesmente especificar o que precisará ser testado usando o Inglês normal, fechando ainda mais a lacuna entre as duas disciplinas.

conclusões

a análise de lacunas de teste ajuda a identificar qual código está sendo lançado não testado e, portanto, pode ajudá-lo a concentrar seus recursos de teste de forma mais eficaz. Sem surpresa, verifica-se que o código não testado tem muito mais probabilidade de conter bugs e, portanto, qualquer ferramenta que possa ajudar a garantir que esse código seja testado corretamente é útil. No entanto, como vimos, o TGA só pode complementar as melhores práticas existentes. É vital manter seus testes de regressão e testes exploratórios. Muitos dos benefícios do TGA também podem ser alcançados usando ferramentas de teste inteligentes. Mas, no geral, a principal coisa a evitar é isolar sua equipe de teste do trabalho de seus desenvolvedores. Para citar erroneamente um velho ditado, você deve se certificar de que a mão esquerda sabe o que a mão direita está fazendo!