A automação de testes de regressão nem sempre é a melhor solução, argumentou Brendan Connolly na Online Testing Conference de 2018. Conolly apresentou o "Manifesto dos Testes de Regressão Manual" e mostrou como isso pode ser usado para diferenciar os testes de features dos testes de regressão e decidir quando automatizá-los ou não.
O manifesto dos testes de regressão manual é modelado sobre os valores apresentados no manifesto ágil. É uma declaração de propósito aberta, uma estrutura para discutir a qualidade e explorar como os testadores contribuem para isso.
Connolly mencionou que parece haver uma necessidade enorme para resolver definitivamente o problema dos "testes", especialmente os de regressão, comprar a ferramenta certa, automatizar todos os testes, deixar a IA lidar com isso. Não que essas coisas não tenham valor, apenas parece que estamos tentando aplicar o mesmo tipo de abordagem prescritiva aos testes contra a qual as pessoas se uniram durante a era do desenvolvimento de software em cascata, argumentou Connolly.
O manifesto dos testes de regressão manual possui cinco valores:
- Comportamento mais que Bugs
- Consistência mais que Correção
- Intenção mais que Implementação
- Conformidade mais que Complexidade
- Comum mais que Completo
Connolly afirmou que, assim como o manifesto ágil, não é que não haja valor nos itens à direita, mas sim que valorizamos mais os itens à esquerda.
A revolução ágil demonstrou o valor da comunicação e da colaboração, ao invés de mais processos e ferramentas. O teste e o espaço de controle de qualidade precisam desse mesmo foco; é difícil porque o teste é um processo íntimo e pode ser uma luta encontrar as palavras certas.
Brendan Connolly, engenheiro sênior de qualidade da Procore Technologies, falou sobre testes de regressão manual na Online Testing Conference de 2018. O InfoQ falou com Connolly após sua palestra.
InfoQ: Por que precisamos de um manifesto para testes de regressão manual?
Brendan Connolly: A comunicação da habilidade e da intenção que impulsionam nossas motivações como testadores é a porta de entrada para mostrar valor. Algo que pode ser um desafio é expressar como e por que os testes e seus resultados desejados mudam ao longo do ciclo de vida do desenvolvimento de software.
O teste de regressão é uma das áreas frequentemente mal interpretadas pelos testadores e pela gerência. O conselho típico é automatizar essa dor, mas nem todos os contextos têm essa opção, ou o ROI pode simplesmente não estar lá. Só porque é um teste de regressão não o qualifica imediatamente como uma boa opção para automação. Então, para dar clareza e permitir conversas, acredito que auxilia ter uma declaração de propósito aberta.
InfoQ: Qual é a ideia por trás do "Comportamento mais que Bugs"?
Connolly: Pode ser difícil, especialmente para um testador mais novo, sentir que está contribuindo caso não encontre bugs.
O tempo para procurar problemas e erros é durante o teste de funcionalidades. O teste de regressão significa minimizar as interrupções; não queremos que novas funcionalidades interrompam inadvertidamente a funcionalidade existente. Se você iniciar o teste de regressão procurando por bugs, o que acabará fazendo é gastar bastante tempo testando novamente a funcionalidade. Na minha experiência, é mais provável que se encontre problemas menores não relacionados às alterações mais recentes ou se redescubra erros antigos que os times optaram por ignorar.
Sim, você encontrou um bug, mas a menos que seja crítico e realmente relacionado às mudanças atuais, tudo que realmente aconteceu foi introduzir uma distração. Qualquer bug encontrado durante a regressão será pesado contra a pressão para liberar. Isso pode prejudicar sua credibilidade com seu time, já que vai parecer que está mais focado em encontrar bugs do que conseguir novas funcionalidades para os clientes.
É mais importante garantir isso e liberar o comportamento que os clientes esperam e dependem, um comportamento que seja mantido diante das mudanças.
InfoQ: Qual é o significado do valor "Comum mais que Completo"?
Connolly: Em algum momento da carreira de quase todos os testadores, haverá o questionamento se tudo foi testado. Na realidade, não há sentido em um projeto quando os testadores não estão fazendo concessões; os testadores se esforçam ao máximo para reduzir a maioria dos riscos no tempo disponível.
O teste de regressão não significa garantir que todas as condições de limite tenham sido verificadas. Não é sobre usabilidade, desempenho ou segurança. Tudo isso é importante, mas a hora de testá-los não é apenas antes do lançamento.
Quando os testadores aceitam a responsabilidade de testes completos, é provável que a culpa venha logo em seguida. Como testadores, precisamos mudar essa discussão para ter uma estratégia completa; uma estratégia em que o componente de teste de regressão garante que a experiência principal de nossos clientes esteja funcionando conforme o planejado.
InfoQ: Como podemos usar o manifesto para melhorar o teste de regressão manual?
Connolly: O manifesto dos testes de regressão manual fornece algumas coisas. Primeiro, ajuda a definir uma linha clara que diferencia os testes de funcionalidades dos testes de regressão, uma diferença que costuma ser um desafio para os testadores e para a gerência. Cada princípio central do manifesto se concentra em dois elementos onde ambos têm valor no teste. Ao contrastar seu valor relativo, definimos expectativas para testes durante todo o ciclo de lançamento. Não que um seja ruim e o outro seja bom, é que há um tempo para cada um e os testadores precisam lidar com essa diferença.
Em segundo lugar, fornece uma estrutura para começar a discutir a qualidade e como os testadores contribuem para isso. É fácil para as pessoas classificarem os testadores como destruidores nefastos de software, quando, na verdade, provavelmente amamos o software que estamos testando tanto quanto ou mais que os desenvolvedores. Não temos o vínculo do criador, mas passamos incontáveis horas trabalhando com ele, apenas tentando garantir seu sucesso. Os times gastam muito tempo discutindo padrões e práticas de codificação, mas o código é muito mais tangível e mensurável do que o teste e a qualidade. Não há uma linguagem comum para os testadores, portanto, cada testador precisa encontrar sua própria voz para expressar suas motivações.
O que realmente espero é que esse manifesto forneça uma faísca para os testadores refletirem sobre o que estão fazendo atualmente, para definir o que significa qualidade para eles e seus times em cada estágio do ciclo de vida de desenvolvimento (em inglês, SLDC). Então, seja capaz de comunicar com mais facilidade o que estão tentando realizar, para que possam expressar melhor e fazer emergir os problemas a seus times.