Olá queridos leitores. Hoje gostaríamos de coincidir com o lançamento do curso "Python QA Engineer" . Antecipando possíveis perguntas, advertimos que o artigo não menciona uma palavra sobre Python, mas, no entanto, achamos esse material útil para testadores e, portanto, decidimos compartilhá-lo com você.
O teste de todos os mínimos detalhes do código não é viável; portanto, o teste de regressão deve realizar uma verificação abrangente e se concentrar em uma área específica em sua totalidade. O objetivo principal é garantir que nem um único erro de regressão prejudique um processo comercial crítico. É esse esforço que possibilita capitalizar na automação. Uma abordagem de teste automatizada, com o objetivo de reduzir os erros de regressão, ajudará a percorrer um longo caminho no sentido de criar boas relações com os clientes e aumentar o valor da marca.
Minha equipe é responsável por testar um aplicativo contábil que usa cálculos sofisticados e registra lançamentos contábeis no sistema contábil. Tudo isso é um fluxo de trabalho, e o fechamento de livros todos os meses é o mais importante.
Em cada release, há algumas alterações nos cálculos, por exemplo, para a conta, pode ser necessário aumentar o débito ou crédito, ou o valor existente pode ser dividido entre as duas contas. Tais mudanças em um aplicativo complexo, que possui muitas dependências internas e externas, geralmente levam a comportamentos imprevisíveis, incluindo erros de regressão, em locais inesperados e aparentemente não relacionados.
Vamos lidar com um erro de regressão, às vezes é chamado de incidente crítico ou problema de produção. Depois de trabalhar por vários anos na indústria de software, você percebe que o erro de regressão vazou para a produção é muito mais importante do que uma nova função que não funciona corretamente. O fato é que a nova função ainda está oculta; portanto, quando é quebrada, o impacto no componente de negócios é mínimo, enquanto que com um erro de regressão, o usuário depende da função de trabalho e provavelmente não possui uma versão de backup do sistema de trabalho.
Erros de regressão são causados por alterações que não foram levadas em consideração pelo gerente de projeto ou pelo proprietário do produto durante os testes de aceitação; arquiteto, desenvolvedor durante a revisão de código no estágio de design ou implementação; ou por um analista de controle de qualidade e testador em casos de teste. Todas as redes de segurança perderam um erro e o usuário o encontrou. Se um erro em uma atualização recente foi detectado em qualquer um dos estágios acima, ou seja, equipes, partes interessadas ou qualquer outro link presente em sua organização, ele foi revisado antes do lançamento ou, pelo menos, avaliado quanto à sua criticidade.
Os erros de regressão acarretam vários custos: correção urgente, multas por violação potencial do contrato de nível de serviço e, o mais importante, danificam a confiança de seus usuários em seu produto. Eles podem decidir que um novo lançamento quebrará algo que já funciona.
Tornou-se importante para minha equipe verificar absolutamente tudo.
No entanto, é sabido que isso não é possível, ou pelo menos muito caro e demorado. Portanto, “testar tudo” se concentrou nas duas coisas a seguir: processos críticos de negócios e a crença de que o comportamento nos principais processos críticos de negócios será o mesmo da versão mais recente, antes da mudança. Em geral, queríamos garantir que, na versão mais recente, um erro de regressão não aparecesse no processo crítico de negócios.
Avaliamos nossas abordagens típicas do teste automatizado para verificar os cálculos e para verificar se toda a lógica está descrita no código para automação de teste. Essa abordagem levantou uma pergunta clássica: "Quem está testando o código do testador?" Se o caso de teste não teve êxito, havia a mesma chance de o problema estar no código do testador. Além disso, a cada alteração no aplicativo, o código de teste também precisa ser atualizado e essas alterações ocorrem com frequência.
Além disso, graças aos testes automatizados, garantimos um conjunto fixo de entradas e um conjunto conhecido de saídas. Devido à complexidade do aplicativo, era impossível enviar todos os conjuntos possíveis de dados de entrada por vez. Também foram necessários vários conjuntos de dados para o final do mês, trimestre e ano. O agendamento era um problema sério, porque leva muito tempo para gerar um conjunto enorme de dados de entrada e scripts correspondentes.
Havia outra variável: dados do usuário. Tínhamos um privilégio especial: recebíamos cópias de backup dos dados do usuário todos os meses. A qualidade do teste depende diretamente dos dados usados para o teste, e os dados da produção são sempre melhores que os dados gerados, portanto nosso privilégio era uma enorme vantagem que não queríamos perder.
Identificação e implementação de testes de regressão
Nossa idéia era usar testes automatizados, o que requer a manutenção mínima necessária e fortalece a confiança das partes interessadas de que o lançamento será de qualidade adequada.
Portanto, precisávamos de uma estratégia de teste para casos de negócios críticos, o que garantiria a ausência de erros de regressão e, é claro, que poderíamos rapidamente colocar em prática.
Nosso processo de preparação ficou assim:
- Backup de banco de dados da produção, restaurado duas vezes;
- Dois sistemas de teste são instalados que funcionam em paralelo:
- Um com um código de produção;
- Outro com a versão atual do aplicativo em teste.
Essa abordagem fornece dois sistemas idênticos com diferenças de código em apenas uma versão:
Ter dois sistemas é muito importante, pois ajuda a entender que qualquer problema surge apenas devido às alterações de código mais recentes.
Os testes são separados; portanto, do processo padrão "executar uma ação e obter uma reação", passamos ao fato de que as ações são executadas de um ponto para outro, mantendo o fluxo de trabalho, após o qual os relatórios de erros são comparados. Essa é a chave para detectar erros inesperados.
Quando o testador se concentra em uma nova função ou em algum tipo de alteração, o teste acaba se concentrando especificamente nela, ou seja, a relevância de uma alteração específica é verificada. O teste de regressão é diferente, pois deve verificar se nada mais foi alterado. Essa diferença é refletida nos cenários de automação. Como os scripts de teste de funções específicas não são adequados para a pesquisa de erros de regressão, é necessária uma abordagem diferente aqui.
Por exemplo, se você estiver trabalhando com um sistema de gerenciamento de pedidos, precisará de um script para fazer pedidos com muitos dados de entrada para fazer pedidos para dois sistemas de teste instalados (de preferência trabalhando em paralelo), em seguida, você obtém um relatório sobre os pedidos do dia anterior e compara cada valor. Todos os pedidos são confirmados ou aprovados (esta ação) e relatórios, como pedidos diários confirmados, pedidos de estoque, relatórios de armazém, pedidos de cada transportadora, tipo de remessa, tipo de pagamento etc. será comparado em dois sistemas. Isso continua durante todo o fluxo de trabalho. Você pode combinar ações, como fazer e confirmar pedidos, e comparar relatórios em estágios separados.
Outro exemplo é o sistema de gerenciamento de hotéis, no qual ações individuais são definidas como processos críticos de negócios, como check-in, cobrança em um restaurante e recebimento de estoque. Todos esses processos receberão suas próprias ações e relatórios. A diferença neste sistema em comparação com o exemplo anterior é que os conjuntos de testes podem ser executados em paralelo e não há necessidade de concluir a etapa antes de iniciar a próxima.
A comparação dos dois relatórios é um momento de verdade e deve ser impecável, no sentido de que nenhuma das partes interessadas deve ter dúvidas sobre sua correção. A diferença nos relatórios é a diferença real.
Para esta operação, usamos a interface de serviço da web. Todos os relatórios são enviados em paralelo em dois sistemas, como resultado, a resposta recebida no formato JSON é comparada.
A comparação ocorre em três frentes:
- Origem (produção) menos destino (aplicativo em teste);
- Alvo menos fonte;
- Comparação de valores para obter a interseção.
Este método funcionará para largura fixa XML, XLS, CSV ou qualquer outro formato. Precisamos garantir que não haja registros desnecessários, que não haja registros ausentes e que todos os valores dos registros correspondam.
Essa é a essência da abordagem sobre a qual estamos falando. Tudo isso é informação legível no aplicativo, que é emitido como um relatório ou, em alguns casos, funcionando como uma interface para outros aplicativos.
O sucesso dessa abordagem está em uma ferramenta ou utilitário de comparação que processa casos relacionados ao seu aplicativo. Você pode considerar-se sortudo se encontrar algo adequado "pronto para uso"; caso contrário, é importante entender que o investimento em um instrumento desse tipo vale a pena, pois trará bons resultados.
Depois de toda a conversa sobre automação, você precisa inserir um comentário. Como são esperadas algumas diferenças nos relatórios, uma vez que devem estar lá conforme necessário, todos os resultados também devem ser analisados manualmente. Deve haver resultados bem-sucedidos claros da aprovação nos casos de teste; no entanto, os resultados mal sucedidos também devem ser analisados e sua validade deve ser confirmada. Como estamos falando de erros de teste de regressão, eles devem ser corrigidos antes do lançamento. Obviamente, existem algumas exceções que são tratadas de acordo com o aplicativo.
Configuração do programa
Todos os aplicativos são diferentes, e a instalação e configuração deles também acontece de maneiras diferentes. Para preparar o aplicativo para teste, algumas etapas adicionais podem ser necessárias, portanto, elas devem ser levadas em consideração no momento e no lugar certo para a execução dos testes. Aqui está um conjunto de etapas típicas:
“Confunda” dados da produção excluindo identificadores de e-mail ou outras informações confidenciais ou substituindo-os por dados fictícios;
Obtenha os dados no formato correto para executar o teste;
Adapte as configurações ao ambiente de controle de qualidade, por exemplo, alterando os relacionamentos de integração.
A única coisa que vale a pena lembrar é que as etapas acima devem ser executadas para ambas as instalações. Lembre-se de que antes de iniciar o conjunto de testes, as configurações devem ser idênticas.
Freqüentemente, ações que não sejam a solicitação de um relatório podem retornar um objeto, por exemplo, uma ação, como criar ou modificar um pedido, pode retornar um novo objeto de pedido. Nesse caso, você precisa comparar dois objetos e não esperar a comparação dos relatórios. Isso pode ajudar a identificar o erro nos estágios iniciais na raiz.
Também é recomendável que você divida o conjunto inteiro em conjuntos menores, por exemplo, agrupando transações e relatórios relacionados. Os conjuntos podem ser executados em paralelo para economizar tempo de execução. No entanto, para um aplicativo com um fluxo de trabalho típico, isso só funciona se você puder dividir os casos vertical e horizontalmente ou vice-versa.
As variações podem começar com as tecnologias - JSON, XML ou escaladores (int / string / float) e expandir até que o aplicativo em teste e produção reaja com diferentes estruturas, mas ainda esteja em conformidade com a arquitetura. Por exemplo, a versão de produção pode usar o arquivo JAR antigo, que opera em um formato específico, e na nova versão o arquivo JAR foi atualizado e agora o formato de resposta foi alterado, portanto, sua comparação mostrará inconsistências. Para compará-los corretamente, você precisa de um plug-in temporário.
Provavelmente haverá poucas situações desse tipo. Nesses casos, às vezes é mais fácil ajustar o design ou considerá-los no contexto de uma solução alternativa.
Existem várias opções para lidar com essas comparações:
Ignore alguns campos, como identificadores e datas;
Ignore diferenças numéricas inferiores a 0,0001;
Ignore a distinção entre maiúsculas e minúsculas;
A estrutura muda em duas respostas.
Melhorando o teste de regressão
O teste de regressão deve ser holístico e focar em toda uma área. Esse saldo ajudará a capitalizar a automação. Uma abordagem de teste automatizada ajudará a reduzir o número de erros de regressão e ajudará no caminho para boas relações com os clientes e aumentará o valor da marca.
Agora, em um ritmo de constante avanço, nossa equipe quer tentar abandonar as duas instalações de sistema idênticas que usamos agora e implementar a mesma estratégia em uma instalação. Queremos manter as respostas de realizações passadas e usá-las para comparação. A abordagem de teste sempre pode ser aprimorada. Deseje-nos boa sorte!
A tradução foi preparada especialmente para os alunos do curso "Python QA Engineer" .