Get best of the week

Como organizar os testes para acelerar e estabilizar os lançamentos de produtos. Parte 1

Se o trabalho em equipe não for acordado, ocorrerão colisões constantemente entre participantes individuais do processo e equipes inteiras, e os produtos ou microsserviços da empresa no mesmo produto interferirão entre si, usando recursos e infraestrutura comuns. O resultado serão avarias, conflitos e desacelerações permanentes. Lançamentos rápidos e previsíveis nessas condições serão inatingíveis.

Meu nome é Victoria Dezhkina, estou envolvido em testes no Departamento de desenvolvimento e manutenção de produtos de big data X5 Retail Group. Vou lhe contar como mudamos o processo de teste em uma de nossas equipes de produtos, a fim de acelerar a preparação de lançamentos pela metade e aliviar a equipe de estresse. Agora, estamos introduzindo essa abordagem para testar em outros produtos da empresa.



A Diretoria de Big Data do X5 Retail Group está desenvolvendo 13 produtos hoje, 4 deles no departamento de monetização, onde os produtos são voltados para o mercado externo e qualquer erro, seja um defeito em um produto ou um recurso lançado tardiamente, tem um efeito econômico e leva à perda de clientes . De fato, são equipes internas que ganham no mercado externo e seguem as regras das pequenas empresas dentro de uma grande empresa.

Todos os nossos produtos variam significativamente em seus objetivos e, portanto, exigem abordagens diferentes para desenvolvimento e teste, mas eles têm muito em comum: eles usam a mesma infraestrutura (Kubernetes, Greenplum, servidores de teste) e desenvolvedores de diferentes equipes de produtos às vezes se substituem por um tempo Férias.

Em tal situação, o papel dos acordos aumenta acentuadamente: se uma parte da equipe não sabe o que a outra está fazendo e cada equipe tem suas próprias regras, os problemas surgirão inevitavelmente.

Por exemplo, dois produtos usam a mesma infraestrutura de teste de carga e precisam urgentemente de realizar testes. Sem notificar um ao outro, eles fazem isso ao mesmo tempo e, como resultado, obtêm resultados falsos, porque o DBMS foi "estabelecido" e por quem não está claro. Eles queriam economizar tempo nas negociações e, como resultado, perderam muito tempo sem nenhum resultado.
A perda de dados não é excluída. Suponha que um dos produtos ocupe um servidor de teste gratuito sem avisar ninguém sobre isso. Oficialmente, o hardware é considerado gratuito, então outro produto entra lá e apaga acidentalmente todos os dados de teste do primeiro. Obviamente, não se trata de dados do usuário, mas apenas de teste, mas ainda assim um caso desagradável.

Pode simplesmente não haver trabalhadores suficientes se o trabalho não for planejado com antecedência. Por exemplo, agora o teste de estresse em nossa Diretoria trabalha em um formato de serviço, ou seja, selecionamos o especialista apropriado para as equipes, mediante solicitação. Se várias equipes, sem aviso prévio, vierem a exigir testes de carga em um dia, talvez não haja testadores suficientes.

Parece que a saída mais fácil nessa situação é estabelecer regras uniformes para a interação de todos os produtos. Mas o problema é que todos os produtos são diferentes. Alguns deles destinam-se a usuários internos, ou seja, especialistas de outros departamentos da empresa, por exemplo, serviços de precificação ou estudo da demanda. A outra parte é desenvolvida para usuários externos - por exemplo, para fornecedores. Esses produtos têm critérios de qualidade e lógica de arquitetura completamente diferentes.

Os produtos em diferentes estágios de prontidão também não aceitam a mesma abordagem: no estágio inicial em que o produto está testando idéias, a prioridade é entender a funcionalidade do usuário e a ausência de ameaças à segurança corporativa. Quando um produto oferece suporte, outros requisitos vêm em primeiro lugar: conveniência do usuário, estabilidade da funcionalidade existente, velocidade de resposta a defeitos e total conformidade com a política de segurança corporativa.

Esses dois fatores - trabalho conjunto no mesmo território e recursos exclusivos do produto - definem a tarefa para nós : desenvolver regras que permitam às equipes não interferir umas com as outras, mas ao mesmo tempo não vincularão testadores e desenvolvedores a mãos e pése eles não reduzirão o desenvolvimento de produtos diferentes para um modelo, invadindo todas as vantagens da abordagem ágil e de produto pela raiz.

Vou dizer algumas palavras sobre por que os testadores desempenham um papel de liderança na criação de padrões de interação nas equipes de produtos. O fato é que, devido às especificidades do nosso trabalho, vemos todo o produto, enquanto os desenvolvedores geralmente se concentram em uma pequena área. Somos os primeiros a perceber problemas e oferecer soluções para eles, mas a solução final é trabalhada em conjunto com os desenvolvedores.

Já escrevemos como esse trabalho coletivo está acontecendo : na fase inicial, precisamos literalmente compor um único dicionário para não ficar confuso em termos. Mas isso é apenas o começo. Em seguida, temos que concordar com uma massa de nuances muito diferentes.

Vou contar como isso aconteceu no exemplo de um de nossos produtos - um sistema de automação de compras para uma rede de distribuição. Sua tarefa é garantir a operação de todos os processos desde o momento em que a loja precisa de certos bens até o momento em que os recebe.

Quais processos mudaram em nosso produto


Quando chegamos ao produto, os lançamentos eram lançados a cada 2 semanas, mas estavam quase sempre atrasados ​​por alguns dias, e o dia do lançamento sempre significava que ficaríamos definitivamente no trabalho e, até o último, estabilizaríamos a versão existente. Era necessário mudar alguma coisa.

É importante observar que a mudança é uma causa comum. Qualquer que seja o seu iniciador, o testador ou os próprios desenvolvedores não podem prescindir do consentimento de toda a equipe e de fortes aliados. Quaisquer alterações precisam ser discutidas por toda a equipe para coletar o maior número possível de idéias e não perder possíveis riscos. O gerente de entrega e produto do nosso produto e antes de mim trabalhava sistematicamente para melhorar os processos, tanto do lado técnico quanto do produto. Tendo chegado à equipe, examinei o processo pelo lado dos testes e juntos pensamos em uma "estratégia de mudanças" acordada. O primeiro ponto foi uma mudança no layout do código.

Layout de código


O procedimento de cálculo é uma das principais "dores" do desenvolvimento da equipe, e há problemas muito diferentes aqui. Por exemplo, uma equipe tem apenas uma ramificação com um código e a correção de erros não para por aí. Ou existem várias ramificações, mas tarefas com funcionalidade sobreposta podem aparecer no ambiente de teste ao mesmo tempo; como resultado, os testadores não poderão localizar o defeito ou verificar algumas das novas funções bloqueadas pelo defeito de uma das tarefas. E sobre desenvolvedores desesperados que não consideram algo ruim corrigir rapidamente as pequenas coisas no produto sem avisar os outros, geralmente não digo nada.

Para evitar tudo isso, precisávamos determinar o número de ramificações e ambientes, além de concordar com o procedimento para colocar o código à prova.

A maneira mais fácil seria dividir o processo em duas ramificações com o código "limpo" e "sujo". Mas tivemos que atender a muitas condições:

  • « », « »
  • ,
  • .

Passamos duas horas discutindo um novo esquema de trabalho e chegamos ao seguinte: começamos três ramos, dois deles (release e master) estarão com código limpo. No "mestre" está a versão atual do produto, no "release" - recursos prontos para lançamento. No Dev, o teste ocorre, eis as tarefas prontas para o teste, o desenvolvimento ocorre localmente. A distribuição para cada ramificação ocorre de acordo com o testador. Aqui está:



O que isso nos deu em termos de teste:

  • O tempo de teste para cada tarefa individualmente foi reduzido em 20%. Não era mais necessário iniciar a verificação novamente, se uma nova tarefa fosse lançada no teste sem aviso, novas tarefas não bloqueavam a verificação das já executadas e o tempo para a localização de defeitos acelerado.
  • No dia planejado para corrigir a liberação, 1-2 tarefas permaneciam desmarcadas em vez de 4 (ou seja, o tempo para verificá-las era reduzido pela metade).
  • O tempo para teste de integração e teste de liberação de candidatos foi reduzido de 6 horas para 2 (contando o reteste).
  • O número de defeitos encontrados no estágio de liberação diminuiu. Anteriormente, na primeira versão, encontramos mais de 10, mas agora não mais que 4. O tempo para o novo teste diminuiu em 2 horas.
  • Houve uma oportunidade de continuar o desenvolvimento em paralelo com os testes.

O tempo total que gastamos em testes, adiando o lançamento para o produto, foi reduzido em 8 horas. Apenas duas horas discutindo um novo esquema para trabalhar com a equipe - e conseguiu economizar um dia inteiro de trabalho, que costumava ser gasto a cada duas semanas. Não é ruim?

Mas os problemas continuaram.

  • , .
  • - , , .
  • .
  • , .

Conclusão: continuamos a trabalhar no dia do lançamento.

Nos reunimos novamente. Parte dos problemas foi resolvida refinando o processo de desenvolvimento e adicionando o CI:



instalamos a implantação automática em todos os ambientes por quase um mês, mas isso acelerou o tempo de quase 2 dias úteis. A equipe está caminhando para isso há muito tempo, o gerente de distribuição e os próprios desenvolvedores estavam envolvidos nisso, mas até agora eles não conseguiram duas coisas: para que a distribuição para todos os ambientes seja uniforme e que ao mesmo tempo o controle de versão seja preservado. A implantação automática violou o princípio principal do teste "a qualquer momento, o testador deve saber o que há em cada ambiente" ou desacelerou os desenvolvedores que não podiam concluir o desenvolvimento da tarefa sem permissão para realizar o teste.

Este é um dilema difícil. Ignore o primeiro princípio e, em vez de acelerar, você obtém uma redução acentuada na previsibilidade de liberações e tarefas desinfladas erroneamente. Por exemplo, se um defeito já for corrigido em conjunto com uma "tarefa limpa", ao executar uma tarefa fixa, ele certamente pegará a defeituosa. Portanto, você terá que aguardar a correção do defeito da tarefa relacionada, adiando a data de lançamento ou corrigir novamente o defeito já corrigido.

O lançamento automático não é uma pessoa, você não concorda com isso. Portanto, resolvemos o problema com os erros restantes de uma maneira diferente - uma abordagem especial para o planejamento e, em seguida, adicionando outra posição.

Planejamento para desenvolvimento e teste


Inicialmente, ao planejar, a equipe e eu discutimos se a tarefa era clara para os desenvolvedores, quanto tempo levaria e se cabíamos no sprint. O testador estimou quanto tempo o teste levaria.

Ao mesmo tempo, não discutimos todos os erros que podem ocorrer: não os previmos com antecedência e não os incluímos na lista de tarefas possíveis. Como resultado, quando esses casos saíram durante o processo de teste, eles foram adicionados como uma tarefa separada, eles precisaram de tempo para trabalhar e aumentaram o volume da liberação, e às vezes eram encontrados apenas no candidato à liberação, no estágio de teste conjunto de tarefas, adiando a implementação indefinidamente. Reunimo-nos para três - um testador, entrega e produto, e pensamos em um novo esquema de interação.

Agora pronunciamos todos os erros possíveis antes de iniciar o desenvolvimento. Levei para me tornar um aluno chato, que na fase de planejamento pergunta tudo e mais: "O que acontecerá se o serviço de terceiros cair?", "E se ficarmos nulos, mas não 0?", "E se não obtivermos todos os dados? "," E se os pechenegues atacarem? " e assim por diante, mas agora estávamos prontos para tudo.

Também começamos a conversar sobre como implementar essa ou aquela tarefa e como testá-la. Isso permitiu reduzir a iniciativa (a invenção de todos os tipos de bicicletas, por exemplo) e deu a cada membro da equipe uma compreensão do que seus colegas estavam fazendo. A propósito, isso nos permitiu abandonar os critérios de aceitação (CA).

Para evitar que a discussão no novo formato se torne muito complicada, começamos a fazer isso não com duas semanas de antecedência, mas por uma semana.

O novo layout de código e o agendamento de tarefas foram apenas os primeiros passos. Na próxima parte do artigo, que será lançada amanhã, falarei em detalhes sobre como mudamos toda uma série de processos na equipe:

  • O formato para definir e aceitar tarefas e defeitos: eles deixaram histórias de usuários para o híbrido "caso de uso + tarefa técnica" mais conveniente para nós.
  • Momento do teste: cinco pontos foram definidos no ciclo de lançamento, no qual os testadores controlam ativamente o processo de criação do produto.
  • As regras de interação da conexão “backend - testing - frontend”: desenvolvemos um esquema que nos permitiu verificar todos os dados que são transmitidos entre o backend e o frontend.
  • Aceleração do trabalho de correção de defeitos: regras estabelecidas sobre como priorizar tarefas de depuração para não distrair os desenvolvedores mais uma vez.

Essas medidas nos permitiram reduzir o ciclo de lançamento de 2,5 semanas para 1. O aumento na velocidade pode parecer pequeno, mas a principal conquista foi que nossos lançamentos se tornaram mais estáveis ​​e previsíveis - tivemos a oportunidade de lançar lançamentos "sob comando": podemos nos reunir em qualquer dia, execute as tarefas e à noite tudo estará pronto e depurado.

More articles:


All Articles