Conversei com dezenas de engenheiros de controle de qualidade de diferentes empresas e cada um deles falou sobre o fato de usar sistemas e ferramentas diferentes para rastrear erros. Também experimentamos vários deles e decidi compartilhar a solução que encontramos.
Introdução
Eu serei banal. Os erros aparecem e são detectados em vários estágios do processo de desenvolvimento. Portanto, você pode dividir os erros em categorias, dependendo da hora em que foram detectados:
- Deficiências . Esses são os erros que os desenvolvedores cometeram ao ver novas funcionalidades. Esses erros são encontrados durante a pesquisa ou teste de aceitação de novos recursos nos estandes de desenvolvimento das equipes.
- Erros na regressão . Esses são defeitos que encontram testes de regressão manual ou testes automáticos de interface do usuário e API no suporte à integração de código.
- Erros com uma venda . Esses são problemas que funcionários ou clientes encontraram e contataram o suporte técnico.
Por onde começamos, ou Jira
Há dois anos, tínhamos uma equipe dedicada de testadores que testaram o produto manualmente após integrar o código de todas as equipes. Até esse momento, o código foi testado por desenvolvedores em estandes de desenvolvedores. Os erros encontrados pelos testadores foram registrados na lista de pendências em Jira. Os erros eram armazenados em uma lista de pendências comuns e movidos de sprint para sprint com outras tarefas. Cada sprint obteve dois ou três erros e foi reparado, mas a maioria permaneceu na parte inferior da lista de pendências:
- Uma das razões pelas quais os erros são acumulados na lista de pendências é que eles não interferem nos usuários. Esses erros têm baixa prioridade e não serão corrigidos.
- Além disso, se a empresa não tiver regras claras e compreensíveis para estabelecer bugs, os testadores poderão adicionar o mesmo problema várias vezes, porque não conseguiram encontrar o relatório de bugs já adicionado nesta lista.
- Outro motivo pode ser que testadores inexperientes estão envolvidos no projeto. É um erro para os testadores iniciantes inserir no rastreamento de erros todos os erros encontrados durante a operação. Os testadores inexperientes consideram que o objetivo do teste é procurar bugs, em vez de fornecer informações sobre a qualidade do produto e impedir o aparecimento de defeitos.
Vou dar um exemplo simples. Ao criar relatórios nos campos de entrada da data, a data é substituída por padrão. Ao alterar a data no pop-up, você pode selecionar novamente novamente hoje e o campo de entrada da data será limpo.
Suspeito que, durante toda a vida de nossa rede, ninguém, exceto os testadores, não tenha reproduzido esse erro. Esses erros compõem a maioria dos erros que não são corrigidos.
Com essa abordagem, quando todos os erros encontrados são inseridos, alguns deles são duplicados e a maioria desses erros não é reparada.
- Os testadores são desmotivados, porque os erros encontrados não são corrigidos pelos desenvolvedores. Ficamos com a sensação de que o trabalho não faz sentido.
- É difícil para o proprietário do produto gerenciar uma lista de pendências com muitos bugs.
Adeus Jira, viva Kaiten
Na primavera de 2018, abandonamos Jira e nos mudamos para Kaiten. A mudança de ferramentas foi causada por razões pelas quais Andrei Arefiev escreveu no artigo
"Por que a Dodo Pizza começou a usar Kaiten em vez de um monte de Trello e Jira". Depois de mudar para o Kaiten, nossa abordagem para trabalhar com bugs não mudou:
- As imperfeições foram registradas nos painéis de comando e os desenvolvedores decidiram independentemente repará-las ou não.
- Os erros encontrados na regressão (executados por uma equipe dedicada de testadores) foram reparados na ramificação de liberação e não liberaram o código até que todos os problemas fossem corrigidos. Decidimos que seria mais lógico manter e coletar informações sobre esses problemas no canal de testadores no Slack. Os testadores escreveram uma mensagem que continha uma legenda, uma lista de bugs com logs e os nomes dos desenvolvedores que executaram a tarefa. Com a ajuda de emoji, eles mudaram o status e, nas negociações, discutiram, aplicaram capturas de tela e sincronizaram. Esse formato é adequado para testadores. Alguns desenvolvedores não gostaram desse método, porque no bate-papo havia outra correspondência em paralelo e essa mensagem foi exibida e não era visível. Nós o consertamos, mas isso não simplificou muito a vida.
- Os bugs encontrados no produto foram registrados na lista de pendências, Product Owner, priorizados e selecionados aqueles que iremos reparar.
Tempo de experiência ou não
Decidimos experimentar os formatos e criamos um quadro separado em Kaiten, no qual mantivemos bugs e mudamos de status. Simplificamos o estabelecimento de um relatório de erro para gastar menos tempo. Ao adicionar um cartão ao Kaiten, os testadores marcaram os desenvolvedores. Uma notificação foi enviada para o correio deles sobre isso. Colocamos esta placa em um monitor pendurado no corredor próximo ao local de trabalho, para que os desenvolvedores pudessem ver o progresso e o processo de teste se tornar transparente. Essa prática também não se enraizou, porque o principal canal de comunicação é o Slack. Nossos desenvolvedores não verificam o correio com frequência. Portanto, essa solução parou de funcionar rapidamente e retornamos ao Slack.
Traga as formigas de volta
Após um experimento fracassado em Kaiten, alguns desenvolvedores ainda estavam contra o formato da mensagem no Slack. E começamos a pensar em como rastrear bugs com folga e resolver problemas que impediam os desenvolvedores. Como resultado de pesquisas, deparei-me com um aplicativo para Slack, Workast, que ajuda a organizar o trabalho com crianças pequenas no messenger. Nós pensamos que este aplicativo permitirá que você gerencie o processo de trabalhar com bugs com mais flexibilidade. Esse aplicativo tinha suas vantagens: mudança de status e atribuição aos desenvolvedores com o clique de um botão, as tarefas concluídas foram ocultadas e a mensagem não cresceu para um tamanho enorme.
Portanto, os problemas resolvidos procuraram no aplicativo Todo e solicitavam retornar "formigas". Após o término do período de avaliação do aplicativo Workast, decidimos abandoná-lo. Porque ao usar esse aplicativo, chegamos à mesma coisa que quando usamos o Jira. Havia alguns bugs que passavam de regressão a regressão nesta lista. E com cada iteração, havia mais deles. Talvez valesse a pena finalizar o processo de trabalhar com essa extensão, comprá-lo e usá-lo, mas não o fizemos.
Nossa maneira perfeita de lidar com bugs agora
No final de 2018 - início de 2019, várias mudanças ocorreram em nossa empresa que afetaram o processo de trabalhar com bugs.
Em primeiro lugar, não tínhamos uma equipe dedicada de testadores. Todos os testadores se dispersaram em equipes de desenvolvimento, para fortalecer a competência das equipes de teste. Graças a isso, começamos a encontrar erros mais cedo, antes da integração do código de comando.
Em segundo lugar, abandonamos o teste de regressão manual em favor do automático.
Em terceiro lugar, adotamos uma "política de erro zero". No artigo "
#zerobugpolicy ou como corrigimos bugs ", o
bevzuk detalha como selecionamos os bugs que
corrigimos .
Hoje, o processo de trabalhar com erros é o seguinte:
- Deficiências . Os testadores relatam o problema aos analistas ou gerentes de produto. Eles andam, mostram, reproduzem, explicam como isso afetará os clientes e decidem se precisam ser reparados antes do lançamento, ou podem ser reparados mais tarde, ou talvez não valha a pena reparar.
- Os erros na regressão que os auto-testes encontrados são reparados pela equipe que tocou nesta parte do sistema e não liberaremos esse código até resolvermos o problema. Os testadores corrigem esses erros em um formato arbitrário no canal de lançamento no Slack.
- Erros com uma venda . Esses erros vão diretamente para os proprietários da tarefa. Os analistas executam erros na Matriz Prioritária do bug e o adicionam ao backlog ou corrigem por conta própria, acumulando estatísticas de hits sobre esse problema.
Sumário
Em resumo, basicamente abandonamos o sistema de rastreamento de bugs . Usando essa abordagem para trabalhar com bugs, resolvemos várias dificuldades:
- Os testadores não estão chateados porque os erros que eles encontram e acionam no rastreamento de bugs não são corrigidos.
- Os testadores não dedicam tempo a uma instituição e a uma descrição completa dos erros que ninguém lê.
- O PO é mais fácil de gerenciar pendências em que não há carga morta.
Não quero dizer que rastrear bugs é inútil. Os erros que levamos ao trabalho são rastreados como qualquer outra tarefa. Mas um sistema de rastreamento de bugs não é um atributo de teste necessário. Ele não precisa ser usado apenas porque a maioria das empresas o utiliza e, portanto, é habitual no setor. Você precisa "pensar com sua cabeça" e experimentar ferramentas para seus processos e necessidades. É ideal trabalharmos sem um sistema de rastreamento de bugs agora. Durante meio ano desse trabalho, nunca pensamos em retornar a ele e novamente obter todos os erros lá.
E como o processo de trabalhar com bugs é organizado em sua empresa?