Get best of the week

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

O testador tem muitas oportunidades para melhorar a qualidade do produto e tornar a equipe mais confortável. O principal é discutir quaisquer mudanças com a equipe e implementar apenas o que for conveniente e útil para todos.

Meu nome é Victoria Dezhkina, sou responsável por testar vários produtos na Diretoria de Big Data do X5 Retail Group. Na última parte do artigo, comecei a falar sobre como alteramos os processos na equipe de produtos "Sistema de automação para aquisição de uma rede de varejo". As liberações de produtos eram constantemente adiadas por vários dias e frequentemente saíam em bruto. Alteramos a ordem do layout do código e do planejamento de tarefas, o que nos permitiu reduzir o ciclo de liberação por vários dias, mas ainda tínhamos que elaborar o formato ideal para definir e aceitar tarefas, estabelecer pontos de teste no ciclo de liberação e aprender a priorizar problemas para corrigir defeitos.



O formato da formulação e aceitação de tarefas e defeitos


O método de definir a tarefa determina em grande parte a rapidez e a correção da tarefa. Você pode descrever tarefas de diferentes maneiras, por exemplo, usando histórias de usuários que refletem as necessidades do usuário final do sistema. Parece algo assim: "o usuário deseja receber um relatório pressionando o botão verde".

A desvantagem dessa abordagem é que ela não explica o que estará "sob o capô" desta decisão. As histórias de usuários deixam aos desenvolvedores muita liberdade e, às vezes, isso se torna um problema: a equipe começa a reinventar a roda ou vê algo trabalhoso demais. E, como em condições de desenvolvimento rápido, quase nunca há tempo suficiente para documentação completa, com essa abordagem, você obtém código criptográfico que complica bastante a integração de novos desenvolvedores no produto.

Discutimos várias opções de design para tarefas e defeitos e decidimos por uma abordagem "híbrida": caso de uso + subtarefas técnicas. O cliente comercial grava o caso de uso, ou seja, descreve as opções para o uso da nova funcionalidade, e o analista com o testador, com base nisso, são tecnicamente subtarefas para desenvolvedores. Na descrição da tarefa no Jira, adicionamos o caso de uso em que é feita, ou um caso de teste que permite reproduzir o erro, enquanto o nome e a descrição da tarefa principal permanecem "legíveis por humanos".

Vamos ver, por exemplo, o que há dentro do defeito com o nome "O usuário não entende como os erros que ocorrem ao escolher uma taxa de compra" são tratados. A descrição da tarefa contém:

  • um caso em que você pode reproduzir o erro;
  • resultado real e esperado;
  • subtarefas para o back-end e front-end com instruções claras para os desenvolvedores corrigirem. “Back-end: para esta API, forneça a resposta correspondente ao front-end” + uma matriz de opções mostrando quais respostas devem estar em cada uma das situações possíveis. "Front-end: para esta API, dependendo da resposta da parte traseira, emita o texto de erro correspondente" + matriz de opções.

Quando o desenvolvedor termina sua subtarefa, ele simplesmente a fecha. Se todas as subtarefas estiverem fechadas, o defeito será retornado para testar novamente. Se problemas adicionais forem detectados, a subtarefa correspondente será criada novamente.

A regra correspondente para a descrição do defeito é obtida :

  1. Crie uma tarefa com uma descrição de um problema funcional, um caso para reproduzir o erro e um link para o histórico, durante a verificação de qual defeito foi encontrado.
  2. . : , , API , use case . , , API, , , , , , .

Também nos recusamos a formar AC (critérios de aceitação) em nosso produto, pois no estágio de planejamento discutimos não apenas o que estamos desenvolvendo e testando, mas também como.

O que deu? Essa abordagem nos permitiu a qualquer momento entender o que havia de errado com a funcionalidade por parte do usuário, em que estágio o trabalho no defeito e, dependendo da carga nas costas e na frente, priorizar as subtarefas para o mesmo defeito de diferentes maneiras.

Como resultado, mesmo antes do início do desenvolvimento, toda a equipe entende qual parte de cada tarefa a afetará pessoalmente e, no final, cada tarefa contém informações: como foi desenvolvida, como foi testada, se havia documentação nela e também o que foi corrigido durante o processo de desenvolvimento.

Essa abordagem é usada apenas em nosso produto, porque acabou sendo a mais conveniente para nós. Outros produtos do X5 Big Data Directorate usam seus próprios esquemas: por exemplo, Histórias de usuários com AC.

Parece que nossa opção não contribui de modo algum para acelerar o desenvolvimento, porque requer mais etapas para começar. Mas isso não é verdade.

Organizamos o processo para que os testes fossem conduzidos em paralelo com o desenvolvimento. Graças a isso, o desenvolvedor não fica ocioso enquanto o testador trabalha e localiza a tarefa o máximo possível.Além disso, sempre vemos qual desenvolvedor em particular trabalhou na tarefa, como foi implementado - isso nos permite entender no futuro qual dos desenvolvedores lidará mais rapidamente com novos problemas semelhantes. A lógica é simples: quanto menos um desenvolvedor lida com coisas que não estão diretamente relacionadas à escrita de código, melhor e a localização mais precisa de um defeito permitem que você pense mais sobre possíveis conexões e problemas causados ​​por um erro específico.

Também pode surgir a questão de saber se as regras que estabelecemos em nosso produto não interferem na formação de padrões uniformes de teste e desenvolvimento no departamento. Na verdade, não: as regras gerais do departamento determinam o que a tarefa deve conter em um certo estágio de desenvolvimento e, em conformidade com esses requisitos, simplesmente elaboramos a tarefa em estágios anteriores.

Momentos de Teste


Discutimos por um longo tempo a questão de em que estágio realizar os testes. No início, havia uma ideia de verificar cada tarefa individual na ramificação local, mas com essa abordagem seria impossível verificar como essas tarefas funcionam juntas, e seus conflitos seriam revelados apenas no estágio do release montado, quando é tarde demais para mudar alguma coisa.

Portanto, concordamos em testar cada tarefa separadamente, mas em um banco de testes. Inicialmente, queríamos realizar várias tarefas ao mesmo tempo, mas acima eu já lhe disse quais riscos traziam essa ideia. Um de cada vez muito mais rápido. Esse é um efeito conhecido: reduzir o número de tarefas paralelas não diminui a velocidade, mas acelera o processo. No Kanban, por exemplo, existe um limite WIP (WIP está em andamento), que limita o número de tarefas que podem ser resolvidas simultaneamente por cada função.

Como resultado, estabelecemos cinco pontos em que os testadores estão envolvidos ativamente no processo de desenvolvimento:

  • Na fase de documentação. Garantimos que não haja problemas que entrem em conflito com a lógica do que já foi feito; corrigimos os detalhes da implementação de cada tarefa.
  • Na fase de definir o problema. Conversamos com o analista todos os casos possíveis relacionados à tarefa e os levamos em consideração ao formar a tarefa
  • Na fase de planejamento. Falamos sobre como a implementação planejada pode se encaixar na funcionalidade relacionada e quais problemas ela pode trazer. Coordenamos com o produto todos os defeitos críticos e complementamos o sprint.
  • Em preparação para o lançamento. Verificamos iterativamente cada tarefa em uma bancada de testes e, no dia anterior ao lançamento planejado, reunimos todas as tarefas e verificamos em uma bancada.
  • Após o lançamento. Verificamos como o lançamento funciona no prod.

No início, quando tínhamos lançamentos a cada 2 semanas, o esquema de trabalho era assim:



Tornou-se (lançamento uma vez por semana):



Regras para interação do back-end - teste - conexão do front-end


Quando muitos dados diferentes são enviados entre o back-end e o front-end na API, nem sempre é claro por que eles são necessários e como eles interagem. Por esse motivo, podem ocorrer avarias no front-end. Por exemplo, o número do cálculo, demanda cal, é transferido da parte traseira. Nominalmente, esse é um parâmetro, mas mais oito campos devem ser "atraídos" para o suporte para executar o cálculo junto com ele. Se você não os passar junto com o número do custo, essa operação não será executada no front end.

Para evitar tais situações, começamos a descrever os parâmetros passados, indicando-os nos comentários da subtarefa para o desenvolvimento da API em Jira, que explicava quais dados a parte traseira e a frente trocariam. Tentamos descrever todas as APIs na estrutura do Swagger, mas com sua ajuda ao gerar automaticamente a documentação, não foi possível transmitir ao front-end o que exatamente o back-end fará com os parâmetros passados. Portanto, concordamos que, se estamos falando de um parâmetro que não é apenas escrito no verso, mas usa outros parâmetros, é necessário descrever seu objetivo na tarefa.

Também começamos a controlar a designação de variáveis ​​para que na mesma API todos os campos fossem padronizados. Nosso produto consiste em microsserviços e cada um pode ter seus próprios nomes de campo. Em um campo com o nome do fornecedor pode ser fornecedor, em outro - supplierID, no terceiro nome, etc. Ao transferir esses dados para um componente do front-end, as dificuldades podem começar, então analisamos todos os parâmetros e começamos a padronizar todos os nomes de variáveis. Para fazer isso, coletamos uma tabela de resumo de todas as designações atuais, uma tabela de todos os componentes da frente e as variáveis ​​usadas por elas (com as quais o desenvolvedor do front-end ajudou muito) e as comparamos. Agora, todas as novas APIs recebem nomes de variáveis ​​padrão, e as APIs antigas são corrigidas quando as tarefas surgem para sua conclusão.

Acelere o reparo de defeitos


No estágio de definição da tarefa, o cliente comercial determina as prioridades - ele sabe melhor o que e em que ordem é necessária para o desenvolvimento do produto. Porém, após a instalação no dev, quando houver tarefas para corrigir defeitos, o testador confirmará suas prioridades.

Às vezes, é necessário alterar urgentemente as prioridades dessas tarefas - por exemplo, encontramos um pequeno defeito no back-end, sem o qual a equipe do front-end não pode começar a consertar.

Anteriormente, nessas situações, íamos imediatamente aos desenvolvedores e solicitávamos que alterassem a prioridade das tarefas, mas isso os distraía. Portanto, concordamos que entraremos em contato apenas em determinados horários - após o congelamento do código, até 5 vezes por dia. O que deu? Paramos de reduzir a produtividade dos desenvolvedores por chamadas súbitas, eliminamos o tempo de inatividade e aumentamos o tempo para o analista executar as tarefas.

Além disso, devido ao fato de que as tarefas não aparecem mais espontaneamente para os desenvolvedores, sempre sabemos quem tem que tipo de carga, quem costumava trabalhar em uma tarefa e será capaz de lidar com ela mais rapidamente. Como resultado, entendemos muito melhor se conseguiremos preparar o lançamento dentro do prazo ou não.

Essas medidas, juntamente com a lógica unificada de implementar o código no dev, release e prod, permitiramreduza o período de correção de defeitos de 3 dias para 3-4 horas.

resultados


Nos 9 meses de trabalho do nosso produto de automação de compras, conseguimos reduzir o ciclo de liberação de 2,5 semanas para 1 semana, com a possibilidade de lançamento diário, aumentando significativamente a estabilidade das versões.

O que mudou:

  1. Nós nos livramos da necessidade de corrigir defeitos após o desenvolvimento, pois levamos esse trabalho ao estágio de preparação de tarefas ao máximo.
  2. Reduzido o período de correção dos defeitos de 3 dias para 3-4 horas.
  3. Tivemos a oportunidade de lançar lançamentos "sob comando". Agora podemos fazer as malas a qualquer dia, executar as tarefas e, à noite, tudo estará pronto e depurado.
  4. Aumentamos a transparência dos processos para todos os participantes do processo: agora todos os desenvolvedores e testadores da equipe entendem o que está acontecendo no momento, estão ocupados com quais tarefas, quanto mais tempo é necessário para desenvolver e corrigir erros, etc.

BÔNUS: foi possível reduzir o nível de estresse da equipe (espero) e, graças ao trabalho coordenado da equipe (graças à entrega), pude facilmente ir para o controle remoto :-) Ao implementar

essas melhorias, seguimos várias regras:

  • Os testadores e desenvolvedores estão no mesmo barco (repita-o como um mantra!). Portanto, a primeira coisa que um testador precisa fazer é se dar bem com a equipe e descobrir o que mais a preocupa, alistar seu apoio. Meus aliados e parceiros na equipe eram o gerente de distribuição e os desenvolvedores.
  • Não existe uma solução ideal pronta, e ela precisa ser procurada. O testador não impõe suas regras a ninguém, ele se adapta à equipe e muda suas abordagens com ela, mantendo em mente a imagem de um futuro brilhante e introduzindo suavemente medidas para alcançá-la)).
  • Restrições e padronização muito severas não são um método. Se você exagerar, as equipes podem perder flexibilidade.

As regras de interação, que nos ajudaram a acelerar o desenvolvimento deste produto, não podem ser transferidas de forma pura para outros produtos da Diretoria - elas são organizadas de maneira diferente e as necessidades dos desenvolvedores são diferentes. Mas o princípio de criar essas regras será o mesmo: estabeleça a ordem do cálculo do código, encontre os pontos ideais para o teste, documente o código e a API.

Paralelamente ao trabalho dentro dos produtos, estamos desenvolvendo regras projetadas para facilitar a interação entre os produtos, e falaremos sobre isso nos seguintes materiais. Portanto, na Diretoria de Big Data, uma estratégia para o desenvolvimento da qualidade do produto está gradualmente sendo formada.

More articles:


All Articles