🚻 😘 🛃 Por que e como estamos testando a atualização 🎅 🖖🏻 🛠️

Neste artigo, explicarei por que é tão importante não esquecer os testes de atualizações de produtos e como esse processo funciona em nossa empresa. A estabilidade da atualização é uma questão de reputação do produto e confiança do usuário em suas inovações. Pela minha própria experiência, posso dizer que, às vezes, antes de iniciar uma atualização, por exemplo, no telefone, prefiro esperar pelo menos um dia e ler os comentários (eles sempre são relevantes apenas para a versão mais recente). Se os comentários forem abusivos, a probabilidade de eu decidir atualizar tende a zero. A classificação do aplicativo devido a comentários negativos cai e não é tão fácil restaurá-lo, porque você precisa interessar o usuário na instalação de uma nova atualização, que ele agora temerá.

Com o que os usuários geralmente não estão satisfeitos?

o aplicativo não funciona após a atualização. Por exemplo, ele simplesmente não sabe o que fazer com os dados no formato antigo;
bônus, descontos, salvamentos de usuários (jogos, lojas, cafés) foram perdidos;
o novo recurso para o qual a atualização é anunciada não funciona;
um novo recurso funciona, mas alguns dos antigos caíram;

Todos esses problemas são relevantes tanto para o aplicativo móvel quanto para o sistema DLP que estamos testando em casa. Mais sobre o que estamos lidando.

O que lançamos e o que precisa ser atualizado

Nossa empresa fornece aos clientes uma solução para proteção contra vazamento de informações corporativas, com a capacidade de configurar separadamente para cada organização, com base em suas necessidades. Os principais elementos do sistema são suas configurações (por quais critérios os intrusos serão pesquisados) e eventos (incidentes registrados).

O produto consiste em várias partes. Neste artigo, consideraremos o servidor de análise e armazenamento de incidentes do InfoWatch Traffic Monitor. O produto é executado no sistema operacional da família Linux e possui seu próprio banco de dados. O oficial de segurança usa o console da web para o trabalho. Atualmente, duas distribuições Linux diferentes e dois bancos de dados são suportados. O sistema pode ser instalado de várias maneiras: multifuncional, quando todos os componentes em uma máquina; e instalação distribuída quando os componentes do sistema existem em diferentes máquinas físicas.

Além da funcionalidade declarada do sistema, devemos garantir uma atualização das versões principais N-1 e N-2 para N, bem como atualizações de todas as versões secundárias - patches e hotfixes de cada versão. Isso ocorre pelo fato de nossos clientes geralmente terem uma infra-estrutura de TI bastante complicada; a atualização pode demorar muito, portanto é importante limitar o número de atualizações, não fazê-las com muita frequência, evitando o tempo de inatividade.

Todas essas condições fornecem um conjunto suficientemente grande de configurações de nosso produto, para cada uma das quais devemos garantir uma atualização bem-sucedida. Com isso, entende-se uma atualização, como resultado:

dados do usuário não são perdidos
recursos antigos não estão quebrados
novos recursos estão disponíveis para uso

Nesse caso, a prioridade dos requisitos da lista acima está em ordem decrescente de importância. Por exemplo, se você transferir prioridades do plano de trabalho com sistemas DLP para o plano de aplicativos do usuário mencionado acima, salvar o usuário do jogo provavelmente será mais importante do que a capacidade de iniciar um novo jogo. E o usuário dos aplicativos de pedidos de alimentos não se importa com a beleza do novo menu se o botão "Enviar pedido" parar de funcionar.

Considere o exemplo da nossa tabela de atualização quando a versão principal 3. for lançada. Para a versão 1.0.0, dois patches e três hotfixes foram lançados, e para a versão 2.0.0 havia dois hotfixes.

1.0.0	2.0.0	3.0.0
1.0.1	2.0.1
1.0.2	2.0.2
1.1.0
1.1.1
1.2.0

No total, no exemplo, temos nove versões, das quais devemos atualizar para a nova versão 3.0.0. Existem dois sistemas operacionais e dois bancos de dados para cada versão do nosso produto. Essa. Um total de 27 configurações atualizadas são liberadas. E se usarmos também métodos de instalação diferentes, esse número pode ser facilmente multiplicado por dois, como resultado, obtemos 54.

Cada um de nossos lançamentos contém vários recursos sérios (do ponto de vista do impacto no produto). Os métodos de ajuste do sistema podem mudar, os sistemas de análise são refinados, os incidentes são complementados com novos dados, a versão dos ambientes, por exemplo, a versão do sistema operacional ou banco de dados, etc.

Historicamente ...

Em tempos imemoriais, desenvolvemos uma abordagem de pesquisa ao testar atualizações de produtos. Ele se provou nas condições de um bom conhecimento do produto e um pequeno número de ambientes e configurações testadas. Mas o tempo passou, a equipe cresceu e mudou sua composição: testadores e desenvolvedores vieram e foram, e alguns recursos não documentados foram esquecidos com segurança.

Planejar testes de pesquisa sem um bom conhecimento do produto é uma tarefa ingrata, cheia de consequências como:

Testar atualizações a cada vez levava um tempo diferente. Mais frequentemente, o tempo foi alocado de acordo com o princípio residual, pois a atualização foi testada quando o produto já está estabilizado e os retoques finais permanecem antes do lançamento.
Às vezes, alguns ambientes eram esquecidos.
, , . , , , «» - .

A preparação preliminar também foi realizada principalmente a critério do testador, que conseguiu a tarefa e, às vezes, sem levar em consideração todas as alterações na versão.

Além dos recursos internos do processo de teste, o fato de a documentação não descrever as alterações ocorridas com a funcionalidade do produto adicionou combustível ao incêndio. Portanto, poderíamos testar não o que estava mudando, mas o que não foi afetado pela versão atual.

Como resultado, era impossível entender claramente no relatório de teste de atualização quais verificações foram realizadas, com quais valores etc.

No entanto, por algum tempo, ficamos satisfeitos com os resultados dos testes de pesquisa: não havia tantos defeitos militares para a atualização e não havia recursos para as mudanças para a vantagem teórica.

Algo deu errado

A situação mudou quando defeitos críticos de atualização para nossos clientes, no entanto, surgiram. Na maioria das vezes, eles foram encontrados em algum lugar fora dos principais cenários de atualização e foram associados a situações em que, por exemplo, um elemento de tecnologia de análise criado e funcionando na versão anterior bloqueou a atualização ou alguns eventos foram perdidos no banco de dados do cliente ou no cenário mais crítico quando após a atualização, alguns dos serviços não foram iniciados e recebemos um produto inoperante. Defeitos relacionados à base também começaram a aparecer em nossos clientes.

Nesta situação, o processo atual não nos satisfaz mais. Algo tinha que ser mudado.
Começamos formulando problemas que, em nossa opinião, nos impediam de testar melhor a atualização. Após a discussão, a seguinte lista de problemas foi formada:

;
, ;
, , , , ;
, ;
;
. ? ? ? ?

Além disso, para cada problema identificado, tentamos encontrar uma solução válida. Além de resolver problemas específicos que formulamos para nós mesmos, decidimos, no decorrer das discussões, apresentar requisitos para o próprio processo de teste, nos quais gostaríamos de trabalhar mais.

O processo deve ser mais aberto e transparente, para isso abandonamos completamente os testes de pesquisa em favor de casos de teste.

Para criar os casos de teste necessários, precisamos de informações sobre alterações entre versões. Essas informações precisam ser solicitadas aos desenvolvedores e analistas de produtos.

Na nova abordagem, usamos uma combinação de verificações nos objetos do sistema (inalteradas e alteradas durante a atualização) + verificações de fumaça do funcional (antigas e novas ou alteradas antigas).

Para a atualização, a opção mais difícil de instalar o sistema será selecionada - instalação distribuída. Para todos os SO e DB. As opções mais simples são omitidas como casos especiais.

Essa combinação de verificações nos dará a oportunidade de testar os seguintes componentes do sistema:

DB
Web (front-end, back-end);
Componentes Linux

Como resultado, a solução para cada um dos nossos problemas foi apresentada da seguinte maneira:
Não há informações suficientes sobre as alterações na versão atual. Conhecimento insuficiente do sistema, informações insuficientes sobre o sistema. Juntamente com analistas e desenvolvedores, determinamos as áreas de mudança do produto entre as versões atualizadas e atualizadas.

O teste de atualizações se transforma em regressão. O teste funcional é realizado, não os objetos e operações do sistema neles. Testaremos a atualização em casos de teste na forma de testes de fumaça da verificação funcional + de dados.

imagem

Relatórios incompreensíveis. Cobertura e resultados podem ser obtidos em casos de teste.

O processo é opaco. Após resolver cada problema individual, formou-se um novo processo, justificado por nossas necessidades e também fixado de forma que todos os membros da equipe pudessem agora se familiarizar com seus princípios.

Novo processo

Como resultado, construímos um processo bastante eficaz.

Dividimos os testes em vários estágios, que deram ainda mais bônus não planejados, descritos abaixo:

Treinamento.
- Analisamos as mudanças no sistema, preparadas em conjunto com analistas e desenvolvedores para mudar áreas.
- De acordo com os resultados da análise, compilamos uma lista de objetos do sistema preparados para testar atualizações.
- Para cada objeto do sistema, o conjunto necessário de estados, status e parâmetros é determinado.
- Criamos stands com a versão necessária (atualizada) do produto.
- , .
- ( ).
- smoke- , .
:
- ;
- (, , , );
- , .
- .
- -, .
- .
- , .
- Verificações de operações em objetos (criação, edição, exclusão).
- Verificando a interação de objetos com outros objetos (detecção).

Prós e contras da abordagem

Atingimos nosso objetivo, a saber:

O processo tornou-se transparente. Sabemos que estamos testando como, quanto tempo levará e quais artefatos serão produzidos. Recebemos critérios objetivos pelos quais era possível dar nosso veredicto sobre uma atualização do produto que funcionava ou não.
Os relatórios ficaram claros. A presença de casos de teste e um relatório sobre os resultados da passagem permitiram relatar rapidamente ao gerente de projeto e ao diretor técnico sobre a qualidade da montagem criada.
Cobertura maior e mais compreensível do que com uma abordagem de pesquisa.
Agora estamos testando uma alteração nos dados e na funcionalidade. Graças à capacidade de resposta de analistas e desenvolvedores, podemos dizer com um alto grau de precisão o que mudou no sistema e onde há o risco de detectar um defeito.

Mas, ao rodar em torno de uma nova estratégia de teste, não podemos deixar de encontrar o óbvio menos da nova abordagem - um aumento significativo no tempo de teste.

Começamos a gastar tempo não apenas em testes diretos, como foi o caso dos testes de pesquisa. Novos custos de tempo foram associados principalmente à preparação para testes, a saber:

análise de mudanças;
criação, preenchimento, manutenção de stands para atualização;
atualizar kits de teste antigos e criar novos.

Esse sinal de menos pode se tornar decisivo para a decisão de abandonar a nova metodologia, se não for um "mas".

Toda a preparação, e este é o estágio que consome mais tempo, pode ser realizada assim que a composição final do lançamento for formada, mesmo sem um produto acabado. Assim, “espalhamos” a preparação de acordo com o plano de teste, sem sobrecarregar o período de pré-liberação excessivamente saturado. Ainda era necessário passar nos testes do produto estabilizado acabado.

No total, de acordo com os resultados da primeira etapa das melhorias, recebemos o seguinte: começamos a passar mais tempo testando, mas ao mesmo tempo temos um processo transparente, uma exibição clara dos resultados e mais cobertura, o que nos permite:

detecte mais defeitos como resultado da verificação de atualizações do produto em seu departamento;
reduzir o número de defeitos ao atualizar nossos clientes pelos engenheiros de implementação;
reduzir o número de defeitos recebidos do suporte técnico.

Qual é o próximo? - sobre otimização

Poderia muito bem ter sido resolvido sobre isso, mas tempo é sempre dinheiro. Além disso, já de acordo com os resultados da primeira invasão da nova metodologia, as formas de otimizar os custos de tempo tornaram-se mais claramente visíveis.

Fomos de duas maneiras:

otimização baseada na análise das execuções de teste: aqui estávamos envolvidos na identificação de dependências óbvias e implícitas dos resultados dos testes nos ambientes utilizados. Foi assim que os testes funcionais foram realizados.
automação de teste. Então nossa equipe de automação veio em socorro.

Vou falar um pouco mais sobre cada caminho.

Primeira maneira: otimização com base na análise das execuções de teste.

Dessa forma, optamos por otimizar os testes de atualização entre as principais versões, ou seja, entre aqueles em que houve uma mudança significativa na funcionalidade.

A primeira coisa que notamos foram os testes que dependem do banco de dados e somente dele. Conseguimos entender quais verificações são suficientes para serem feitas uma vez em cada base e excluí-las completamente de nossas combinações com o sistema operacional.

O segundo passo foi o "colapso" de verificações volumétricas da funcionalidade antiga em uma lista de verificação. Nas primeiras iterações, a funcionalidade, independentemente de aparecer na versão atual, na versão anterior ou sempre, contava com seu próprio teste de pleno direito. Agora, os testes completos dependem apenas de novos recursos, enquanto a funcionalidade antiga está marcada na lista de verificação.

Além disso, a mesma lista de verificação foi muito útil para nós ao lançar patches e hotfixes, onde, além de atualizações entre as principais versões, também é importante verificar se há atualizações dentro da versão.

A segunda maneira: automação de teste

Antes de tudo, quero fazer uma reserva de que não concebemos a atualização da automação de teste porque geralmente é aceita e geralmente é boa, mas porque a atualização é o tipo de teste que não pode ser excluído em nenhum release, seja importante lançamento, patch ou hotfix. Escolhemos esse caminho para reduzir o tempo de teste de atualizações para versões menores, como patches e hotfixes, ou seja, versões entre as quais a composição do funcional não muda. Nesse caso, a automação de teste parecia muito eficiente.

Nesse estágio, testar atualizações ao liberar patches e hotfixes é quase totalmente automatizado.

As atualizações de teste quando as principais versões são lançadas são divididas entre testes manuais e automatizados. Verifica manualmente as áreas alteráveis afetadas pelos recursos. Os testes para áreas invariáveis são perseguidos automaticamente; na maioria das vezes, é mais a reutilização de autotestes já escritos para versões anteriores, com pouca atualização para uma nova.

Para iniciar o processo de automação dos casos de teste, tivemos que refiná-los ainda mais, pois a linguagem dos testes de um testador manual permite muito mais dificuldades do que um autoteste pode suportar. Ou seja, também alocamos tempo para a preparação de testes para automação, que realmente renderam quase a primeira execução.

Sumário

Tivemos um processo de pesquisa para testar atualizações. Em algum momento, ele deixou de nos satisfazer por causa de uma queda notável na qualidade da atualização. Não escolhemos um substituto para o teste de pesquisa como uma técnica pronta, mas o formamos com base nos problemas que identificamos. A formação de uma nova metodologia, que usamos e continuamos a melhorar, foi influenciada por soluções preparadas para problemas, bem como por desejos gerais para o processo de teste.

Eu não acho que, nessa situação, inventamos uma bicicleta quando seguimos o caminho de criar nosso próprio processo personalizado especificamente para o nosso projeto e os recursos do nosso produto. Se desmontarmos o processo em suas partes constituintes, obteremos, em geral, técnicas geralmente aceitas e amplamente utilizadas.

Apesar do resultado dos trabalhos que reunimos em um artigo não muito volumoso, todo o processo, desde a compreensão do problema até a introdução de novas soluções e otimização dos testes, levou quase dois anos.

Tentamos descrever honestamente aqui todos os prós e contras, bem como as armadilhas de nossas decisões, para que a narrativa não pareça exclusivamente uma história de sucesso "foi ruim - tornou-se boa".

Esperamos que você ache nossa experiência útil.

Autor do material:tryzhova (Ryzhova Tatyana).

Por que e como estamos testando a atualização