Meu nome é Maria Snopok, sou a gerente da direção de automação do Departamento de Testes do Departamento de Desenvolvimento e Suporte de Produtos de Big Data do X5 Retail Group. Neste artigo, compartilharei nossa experiência com a implementação de autotestes e redução dos custos associados. Esperamos que esta informação seja útil para equipes que estão lutando para fazer a transição para testes automatizados.
Como chegamos aos autotestes
Antes do advento da automação, trabalhei como gerente de teste em um de nossos produtos. Quando um modelo de teste bastante grande foi formado lá, começamos a distribuir o conjunto de testes de regressão para toda a equipe de desenvolvimento - se ela for responsável pelo lançamento, ela também está testando. Essa regressão de equipe resolveu as seguintes tarefas:
- os desenvolvedores que haviam lidado anteriormente com suas partes separadas de funcionalidade foram capazes de ver o produto completo;
- fizemos a regressão mais rápida e liberamos com mais frequência devido a isso;
- não reduzimos mais o recurso - a qualidade melhorou.
Mas era caro, porque os testes eram realizados por especialistas caros - desenvolvedores e analistas, e começamos a caminhar para a automação.
Os testes de fumaça foram os primeiros a serem executados - verificações simples para garantir que as páginas abram, carreguem, não travem e que todas as funcionalidades básicas estejam disponíveis (até agora sem verificar a lógica e os valores).
Em seguida, automatizamos scripts positivos de ponta a ponta. Esta etapa trouxe o máximo benefício: os testes possibilitaram verificar se os principais processos de negócio do produto estavam funcionando, mesmo que houvesse erros nos cenários negativo, alternativo e secundário.
E finalmente chegamos à automação de verificações de regressão avançadas e cenários alternativos.
Em cada uma dessas etapas, enfrentamos uma série de dificuldades que retardaram seriamente e complicaram todo o processo. Que soluções práticas nos ajudaram a agilizar e facilitar o trabalho dos automobilistas?
Quatro maneiras de reduzir custos em autotestes
1. Combine os formatos dos atributos de teste na costa
Os desenvolvedores e testadores automatizados precisam concordar com antecedência sobre as regras para nomear elementos HTML para seu uso subsequente como localizadores em autotestes. É desejável ter o mesmo formato para todos os produtos. Desenvolvemos requisitos para entender como nomear atributos, mesmo antes de o recurso ser transferido para o desenvolvimento; esse entendimento existe tanto do lado dos desenvolvedores quanto do lado dos testadores. Concordamos que a cada elemento html visível é atribuído um atributo data-qa personalizado, pelo qual o testador o pesquisará. O atributo é nomeado de acordo com o seguinte padrão:
[nome da tela] [nome do formulário / tabela / widget] [nome do item]
Exemplo:
data-qa = "plu-list_filter-popover_search-input"
data-qa = "common_toolbar_prev-state"
É fácil isolar esse atributo simplesmente da documentação e do layout, e todos sabem qual deve ser seu significado. Quando um desenvolvedor executa uma tarefa para trabalhar, ele, de acordo com essas regras, atribui atributos data-qa a todos os elementos visíveis da página - cabeçalhos, botões, links, seletores, linhas e colunas de tabelas, etc. Como resultado, o testador pode começar a escrever autotestes mesmo no processo de desenvolvimento de um recurso, com base em apenas para o layout e documentação, pois já sabe como os atributos serão nomeados.
A introdução de atributos de teste nos permitiu reduzir os custos de desenvolvimento e suporte de autotestes em uma média de 23% em relação ao período anterior, reduzindo os custos de atualização de testes e localização de elementos para autotestes.
2. Escrevemos testes manuais para que sejam fáceis de automatizar
Testadores manuais e engenheiros de automação vivem em universos diferentes. Os manuais têm como objetivo verificar vários objetos de teste próximos diferentes com um script. Os automáticos, por outro lado, tendem a estruturar tudo e verificar apenas objetos do mesmo tipo em um único teste. Por esse motivo, os testes manuais nem sempre são fáceis de automatizar. Quando recebemos caixas manuais para automação, enfrentamos uma série de problemas que não nos permitiam automatizar os scripts resultantes palavra por palavra, porque eles foram escritos para fácil execução por uma pessoa viva.
Se um automatizador está profundamente imerso no produto, ele não precisa de casos "manuais", ele pode escrever um script para automação. Se ele chega ao produto "de fora" (em nosso Departamento, além dos testadores, as equipes também têm o teste como um serviço dedicado), e já existe um modelo de teste e scripts preparados por testadores manuais, você pode ficar tentado a instruí-lo a escrever autotestes em com base nesses casos de teste "manuais".
Não ceda a isso: o máximo que um automatizador pode usar casos de teste manuais é apenas para entender como o sistema funciona do ponto de vista do usuário.
Nesse sentido, é necessário inicialmente preparar testes manuais para que possam ser automatizados e para isso lidar com problemas comuns.
Problema 1: simplificando casos manuais.
Solução: detalhando os casos.
Vamos imaginar a descrição de um caso manual:
- abre a página da lista de versões de revisão
- clique no botão criar
- Preencha o formulário
- clique no botão "criar"
- certifique-se de que a versão de revisão seja criada
Este é um cenário ruim para a automação, porque não especifica o que exatamente precisa ser aberto, com quais dados preencher , o que exatamente esperamos ver e em quais campos ver. As instruções "certifique-se de que a versão foi criada com êxito" não são suficientes para a automação - a máquina precisa de critérios específicos para garantir que a ação seja bem-sucedida.
Problema 2: ramificação do caso.
Solução: o caso deve ter apenas um cenário linear.
As construções com "ou" geralmente aparecem em caixas manuais. Por exemplo: "abra a revisão 184 sob o usuário 1 ou 2". Isso é inaceitável para automação, o usuário deve ser claramente indicado. Conjunções "ou" devem ser evitadas.
Problema 3: irrelevância do caso.
Solução: verifique os casos antes de enviá-los para a automação.
Esta é a maior dor para nós: se a funcionalidade muda com frequência, os testadores não têm tempo para atualizar os casos de teste. Mas se um testador manual encontrar um caso irrelevante, não será difícil para ele corrigir rapidamente o script. Um automatizador, especialmente se ele não estiver imerso no produto, não será capaz de fazer isso: ele simplesmente não entenderá por que o case não está funcionando bem e o perceberá como um bug de teste. Passará muito tempo no desenvolvimento, após o que a funcionalidade testada foi cortada há muito tempo e o script é irrelevante. Portanto, todos os scripts para automação devem ser verificados quanto à relevância.
Problema 4: pré-condições insuficientes.
Decisão:pilha completa de dados auxiliares para execução do caso.
Os testadores manuais tendem a embaçar seus olhos e, como resultado, ao descrever as pré-condições, eles perdem algumas nuances que são óbvias para eles, mas não óbvias para os automatizadores que não estão tão familiarizados com o produto. Por exemplo, eles escrevem: "abra uma página com conteúdo calculado." Eles sabem que para calcular esse conteúdo é necessário executar um script de cálculo, e o automatizador, que vê o projeto pela primeira vez, decidirá que é necessário pegar algo já calculado.
Conclusão: nas condições prévias é necessário escrever uma lista exaustiva de ações que devem ser realizadas antes de iniciar o teste.
Problema 5: várias verificações em um cenário.
Decisão:não mais do que três verificações por cenário (exceto para cenários caros e difíceis de reproduzir).
Os testadores manuais geralmente desejam economizar dinheiro em caixas, especialmente quando são pesadas, e testar o máximo possível em um cenário, acumulando uma dúzia de testes nele. Isso não deveria ser permitido, pois tanto no teste manual quanto no automatizado, essa abordagem gera o mesmo problema: o primeiro teste falhou, e todos os demais são considerados como não aprovados ou não iniciam no caso da automação. Portanto, em scripts de autoteste, de 1 a 3 verificações são permitidas. As exceções são cenários realmente difíceis que requerem pré-cálculos demorados, bem como cenários difíceis de reproduzir. Aqui você pode comprometer a regra, embora seja melhor não fazê-lo.
Problema 6: cheques duplicados.
Solução: não há necessidade de automatizar a mesma funcionalidade continuamente.
Se tivermos a mesma funcionalidade em várias páginas, por exemplo, um filtro padrão, então não faz sentido verificá-lo em todos os lugares durante o teste de regressão, basta olhar em um lugar (a menos, é claro, que estejamos falando de um novo recurso). Os testadores manuais escrevem scripts e testam esse tipo de coisa em cada página, simplesmente porque olham cada página isoladamente, sem entrar no funcionamento interno dela. Mas os automatizadores devem entender que testes repetidos da mesma coisa são uma perda de tempo e recursos, e é muito fácil para eles detectar tais situações.
A solução dos problemas acima nos permitiu reduzir o custo de desenvolvimento de autotestes em 16%.
3. Sincronização com equipes de produto na questão de refatoração, redesenho, mudanças significativas na funcionalidade, de modo a não escrever testes "na mesa"
Em nosso departamento de Big Data, onde são desenvolvidos 13 produtos, existem dois grupos de automatizadores:
- automatizadores diretamente nas equipes de produto;
- um serviço de fluxo de automação fora das equipes de produto, engajado no desenvolvimento da estrutura e componentes comuns e trabalhando em solicitações de produtos com testes funcionais prontos.
Os automatizadores de fluxo inicialmente não estavam tão envolvidos com o produto e antes não participavam das reuniões diárias da equipe, porque tomaria muito do seu tempo. Uma vez que essa abordagem nos decepcionou: nós acidentalmente aprendemos de fontes de terceiros que uma equipe iria refatorar seu produto (quebrar o monólito em microsserviços), e é por isso que alguns dos testes que escrevemos são enviados para o arquivo. Foi muito doloroso.
Para evitar que isso aconteça no futuro, foi decidido que, pelo menos uma vez por semana, um automatizador do stream comparecerá às reuniões da equipe de desenvolvimento para se manter atualizado sobre o que está acontecendo com o produto.
Também concordamos que os testes são automatizados apenas para a funcionalidade que está pronta para produção e não sofre alterações frequentes (regressão). Devemos ter certeza de que pelo menos nos próximos três meses não ocorrerá refatoração ou retrabalho importante, caso contrário os automatizadores simplesmente não terão tempo para testes.
As economias de custo resultantes da implementação dessas medidas são mais difíceis de calcular. Demoramos para desenvolver autotestes como base, que perderam seu valor devido à transição planejada de parte da funcionalidade para microsserviços. Se soubéssemos dessa transição com antecedência, não cobriríamos a funcionalidade variável com autotestes. A perda total (também conhecida como economia potencial) é de 7%.
4. Atualizar um testador manual para um engenheiro de automação
Existem poucos automatizadores de teste no mercado de trabalho, especialmente os bons, e estamos ativamente procurando por eles. Também atualizamos ativamente os testadores manuais existentes que desejam e têm conhecimento básico de automação. Em primeiro lugar, mandamos essas pessoas para cursos de linguagem de programação, porque precisamos de automatizadores e autotestes completos, e dos gravadores, em nossa opinião, existem mais desvantagens do que vantagens.
Paralelamente ao aprendizado de uma linguagem de programação, uma pessoa aprende a escrever scripts estruturados e corretos sem problemas a partir do ponto 2, ler e analisar os resultados dos relatórios de autoteste, corrigir pequenos erros em localizadores, métodos simples, manter testes prontos e só então escrever seus próprios. Todo o desenvolvimento ocorre com o apoio de colegas experientes do serviço de stream. No futuro, eles podem participar da finalização do framework: nós temos nossa própria biblioteca, escalável para todos os projetos, ela pode ser melhorada adicionando algo nosso.
Essa direção de redução de custos está em sua infância, portanto é muito cedo para calcular a economia, mas há todos os motivos para acreditar que o treinamento de pessoal ajudará a reduzir significativamente os custos operacionais. E, ao mesmo tempo, dará aos nossos testadores manuais a oportunidade de desenvolver.
Resultado
Agora automatizamos cerca de 30% dos testes em cinco produtos, o que levou a uma redução de 2 vezes no tempo de teste de regressão.
Este é um bom resultado, pois o tempo é muito importante para nós: não podemos testar indefinidamente e não podemos dar o produto sem conferir; a automação, por outro lado, nos permite fornecer o volume necessário de inspeções de produto no momento ideal. No futuro, planejamos aumentar a porcentagem de autotestes para 80-90% a fim de lançar lançamentos com a maior freqüência possível, mas ao mesmo tempo não para cobrir projetos com autotestes onde o teste manual é ainda mais lucrativo.