Olá pessoal, meu nome é Sergey. Estou testando o front-end do Yandex.Market. Sei que entre os leitores da Habr existem muitos especialistas em TI que estão de alguma forma conectados ao processo de liberação e aos testes. Eu tenho uma pergunta para você. Já aconteceu na sua prática que os recursos não rolam por um longo tempo na produção? Você conhece os lançamentos inchados e suas verificações volumétricas?
Eu acho que todo mundo tinha isso. Eu vim para a Yandex há 3 anos, nossa equipe era muito jovem, os processos não estavam totalmente estabelecidos. E eu me deparei com esses problemas cara a cara.
Como estava
Naquela época, nossas equipes de produtos não tinham uma área de responsabilidade específica e estavam envolvidas apenas no projeto para o qual foram criadas. Então eles se separaram. Os testes também não estavam ligados às equipes de desenvolvimento. Ele existia como um serviço e conectado ao projeto, conforme necessário.
As tarefas eram verificadas apenas pelas mãos, os testes de integração eram instáveis, a porcentagem de cobertura com autotestes era pequena. O cheque durou muito tempo. O conjunto de tarefas prontas para o cálculo crescia constantemente e podia atingir tamanhos enormes.
Quanto aos lançamentos, um dos gerentes estava envolvido na montagem e cálculo. Realizamos reuniões com todos os gerentes e decidimos o que cairia no próximo lançamento e o que poderia ser adiado.
Eles verificaram os lançamentos aleatoriamente: quem teve tempo para verificá-los, ele verificou. A ênfase estava no teste de regressão manual, que poderia durar vários dias. E isso apesar do fato de o lançamento ter executado um pacote de autotestes e de um departamento que os escreveu e deu suporte.
Portanto, o problema resolvido caiu em teste e pode ser testado em até 2 dias. Então ela entrou no lançamento, foi verificado por mais 4 dias. No instante, a tarefa acabou no máximo em uma semana. Poucas pessoas gostaram, foi necessário mudar alguma coisa. E a coisa mais importante a mudar são os processos.
Contorno
A primeira coisa que fizemos foi introduzir uma divisão em contornos - equipes de especialistas de várias áreas. Diferentemente das equipes anteriores, os contornos não se separam após o final do projeto. Eles continuam a gerar novos projetos e idéias dentro de sua área de responsabilidade.
De 1 a 3 testadores são responsáveis pelos testes em cada circuito. Cada testador de circuito responsável está presente em todas as etapas do desenvolvimento do produto, desde uma ideia até uma análise.
Em serviço
Para estruturar o trabalho dos lançamentos, introduzimos duas funções em nossa equipe de teste: um assistente de lançamento e um testador de lançamento. Como mestre de lançamento, temos 4 testadores de plantão por vez, todos estão envolvidos no dever de lançamento. Para cada uma dessas funções, organizamos um cronograma de tarefas.
As tarefas que surgem em serviço têm precedência sobre o teste dos recursos do produto nos circuitos. Para que os testadores não precisem esperar muito tempo sem interrupção, o serviço de liberação é organizado da seguinte maneira: um turno está de serviço de segunda a quarta-feira, o segundo - de quarta a final de sexta-feira. Em cada turno - 4 pessoas, 2 pessoas por plataforma.
A documentação
E a documentação? Não temos muito, mas é. Por exemplo, ao implementar os recursos, nós, juntamente com os desenvolvedores e o gerente, determinamos o número ideal de autotestes. Se não podemos automatizar algo, ou se um recurso requer postagem imediata sem autotestes, escrevemos um caso no conjunto de testes de todos os casos de verificação de mercado e, se necessário, incluí-lo no conjunto de testes de liberação dos testes de regressão.
Se checarmos as correções e constatarmos que o autoteste não foi gravado, também definiremos a tarefa de desenvolvê-lo, e a edição ocorrerá imediatamente com o teste escrito nele.
Ao organizar cada experimento, temos uma lista de verificação, pois não sabemos antecipadamente se o experimento será bem-sucedido.
Uma lista de verificação é um conjunto de verificações positivas nos recursos de uma experiência. O testador de versão usa-o em todas as versões enquanto o experimento está funcionando. Essa lista de verificação também pode ficar em branco para futuras tarefas de automação, se a experiência for bem-sucedida e a distribuirmos para 100% dos usuários.
Ao verificar os lançamentos, usamos vários kits de teste, dependendo da complexidade e plenitude do lançamento. Temos pequenos conjuntos de testes e conjuntos com o número máximo de casos de teste. Qual suíte de teste usar, o testador de versão decide.
Em algumas áreas, também usamos a lista de verificação positiva para desenvolvedores. Com isso, o desenvolvedor pode verificar a tarefa e prever gargalos no desenvolvimento de recursos. Se o testador mudou no projeto, isso ajudará o novo especialista a ingressar rapidamente no projeto. As listas de verificação são gravadas antes do início do desenvolvimento, imediatamente após o agendamento da tarefa.
Isso é tudo pelas docas.
Como testamos tarefas
Utilizamos várias técnicas de design de teste: classes de equivalência, valores de limite, teste em pares, cenários do usuário. A experiência do testador também é muito importante. O mercado é uma máquina grande e você precisa saber como todas as suas peças funcionam para reparar ou melhorar alguma coisa. Por exemplo, temos 4 tipos de cartões de mercadorias e 6 tipos de problemas de mercadorias. Sem saber disso, é simplesmente impossível testar qualitativamente a tarefa de alterar essas páginas.
Um papel importante na verificação de tarefas é desempenhado pelos autotestes. Executamos autotestes funcionais para todas as tarefas que implementamos, analisamos falhas e relatamos bugs.
Em casos especiais, quando a tarefa afeta muitos componentes do mercado, também executamos testes de tela - eles nos ajudam a detectar bugs.
Quando a verificação da tarefa é concluída, deixamos um comentário de que está tudo bem e que a tarefa pode ser lançada. No comentário, indicamos quantos testes foram escritos ou dizemos que não são necessários, e convertemos a tarefa no status "liberação pendente".
Em seguida, a tarefa é escolhida pelo assistente de liberação e enviada à liberação junto com outras tarefas comprovadas. Tentamos encher os lançamentos com tarefas para que eles sejam verificados em 8 horas pelas mãos de 4 testadores: 2 para a versão touch do Market e 2 para a versão para desktop. Nosso objetivo é lançar pelo menos 5 lançamentos. Ou seja, a velocidade de entrega da tarefa ao produto em comparação com o que era, aumentou 5 vezes.
Como verificamos os lançamentos
Começamos a verificar o lançamento verificando os testes automáticos e os testes de tela. Depois de analisar os relatórios, podemos capturar imediatamente até 90% dos problemas. Analisamos o travamento dos testes: se eles estão relacionados a um bug ou são quebrados por um ticket na versão, procuramos a tarefa na qual esse travamento é reproduzido e solicitamos reparos. Se isso não for feito, a tarefa não se enquadra no release.
Os testes também podem morrer sozinhos. Nesse caso, desligamos o teste da execução de autoteste e iniciamos a tarefa de corrigi-lo e criar o mox, se necessário.
Dependendo das tarefas do release, podemos usar o kit de teste de release completo ou recusar completamente a regressão manual. A decisão é tomada pelos testadores de liberação.
Se a versão tiver várias edições pequenas, a verificação da tarefa será realizada localmente e a regressão manual será substituída pela verificação dos relatórios de teste automático.
Independentemente da integridade do release e das tarefas, a equipe de testadores de release verifica os experimentos atualmente sendo mostrados para diferentes porcentagens de usuários em produção. Uma lista de verificação escrita por um testador de experimento é usada.
Quando todas as verificações são concluídas, o testador de versão deixa um comentário onde lista todas as atividades de versão e, se necessário, grava tarefas para corrigir testes quebrados.
O mestre de lançamento analisa os relatórios de disparo (teste de carga) e, se ele vê um aumento nos erros, reinicia-os. Se isso não ajudar, ele procura o culpado ou procura ajuda do desenvolvedor de plantão.
Se tudo estiver bem com os resultados da filmagem, o assistente de lançamento abre os gráficos do mercado e começa a lançar o lançamento em produção. Você precisa seguir os gráficos para não perder o crescimento de erros.
Se o release é o responsável pelo crescimento de erros, o mestre do release o reverte e entende os motivos. Se os agendamentos forem normais, ele conclui o lançamento e começa a coletar um novo a partir de tarefas prontas.
Lutando pelo melhor
Apesar de tudo funcionar bem, você deve sempre se esforçar pelo melhor. Estamos à beira de uma entrega contínua futura mais brilhante, onde as tarefas serão testadas e lançadas em produção paralelamente umas às outras, sem um estágio intermediário na forma de uma liberação. Isso permitirá que você não se distraia com o relógio nas versões e acelere significativamente a entrega de funcionalidade aos usuários.
Decidimos mudar para o CD em etapas. O primeiro passo foi a introdução de um monorepositório, que combina a implementação da funcionalidade para ambas as plataformas - o toque e a área de trabalho - em uma versão. Essa abordagem tem vantagens para o desenvolvimento e o teste. Passamos muito menos tempo testando o componente. As tarefas agora estão em um só lugar, facilitando a navegação. É mais fácil para o gerente navegar, pois ele sabe o momento exato da implementação da tarefa de liberação no prod e não há folga entre a implantação das plataformas.
O próximo passo para o CD será a introdução da “ferida verde”. Para cada ticket verificado pelo testador, serão lançados 2 tipos de testes para ambas as plataformas: testes funcionais e testes de tela. Todos os testes precisam ter moki. Se os testes para uma das plataformas falharem, a tarefa não será considerada verificada. Se o teste falhar, você precisará entender por que isso aconteceu. Somente na ausência de testes de queda e na conclusão bem-sucedida de todas as verificações, a tarefa será enviada ao produto.
Obrigado pela atenção. Espero que nossa experiência tenha sido útil para você, estou esperando por você nos comentários.