Gestão de defeitos no github

Segundo Rex Black, presidente do ASTQB (American Standards Testing and Quality Board), Fundador da empresa RBCS Consultants e autor de vários livros na área, risco é a possibilidade negativa de um evento ou saída indesejada. Um risco em específico é qualquer problema que pode ocorrer e diminuir as percepções do cliente ou usuários em termos da qualidade do produto ou do sucesso do cliente. Mas e como fazemos um paralelo do Lean, Riscos e Gestão de Defeitos de uma forma prática?

Na área de Testes temos 2 tipos principais de risco:

  • Riscos do Produto ou Riscos da Qualidade
  • Riscos de Projeto ou de Planejamento

O grande objetivo dos Testes é garantir qualidade ao sistema, e garantir a qualidade significa minimizar os riscos ao extremo e deixar o produto final com o menor número de erros possível. Há alguns que defendem que é possível inclusive eliminar todo o tipo de defeito atuando em melhorias do processo e testes mais eficazes.

Qualquer defeito gera um custo adicional para a empresa em termos de recursos gastos em suporte técnico, custos de operação, custos de parar a produção para correção dos defeitos, fora os custos da gestão de defeito e ainda todo o stress causado e a falta de confiança que uma falha pode gerar em 1 ou mais usuários de nosso sistema.

bugsssSe formos observar nos valores Lean, é preciso corrigir o processo e encontrar o fluxo de valor também nas tarefas de desenvolvimento. Para tal, é necessário evitar ao máximo lançar defeitos em produção por causa de alguns pontos essencialmente importantes:

  • Task Switching: é a mudança de tarefas diferenciadas dentro do flow do desenvolvimento ou, impedindo o flow. Defeitos ocasionam isso!
  • Partially Done Work: trabalho parcialmente entregue não gera um fluxo contínuo de entrega de valor, já que é necessário vários ping-pong de retrabalho entre os clientes-alvo e todos os envolvidos tanto no atendimento a eles, como no suporte, QA, DEVs, UXs e POs. Todos gastam tempo discutindo, avaliando e priorizando defeitos.
  • Waste: desperdício! E este é o ponto chave: defeitos são um grande desperdício! Vale muito mais a pena gastar um pouco mais de tempo na etapa de Think (do ciclo PDCA revisitado: Think-Build-Measure-Tweak)

Tudo bem! Mas os defeitos foram produzidos, e agora?

A questão é que nem sempre se consegue evitar que algumas falhas (ou defeitos) alcancem o ambiente de produção e, então é preciso uma forma de registrar e categorizar estas falhas para que se possa corrigir de acordo com o impacto que esta falha gera aos clientes no sistema e de acordo com a probabilidade de outro cliente obter a mesma falha. E, para isto é legal utilizar as ferramentas que estão ao nosso alcance e amadurecer o processo antes da seleção de qualquer tipo de ferramenta proprietária.

Ferramenta = Issues do Github

gestao-defeitos-github-tool

Como qualquer desenvolvedor gosta muito de usar o github, você pode usar o sistema de issues para inclusive para gerenciar os defeitos que vai encontrando… Mas com o aumento do time, aumento de novas features e o aumento da complexidade do sistema é natural acumular algumas “issues” no github que nunca são vistas ou priorizadas para correção. E ficam lá, meio que “abandonadas”.

Então você pode iniciar a gestão de defeitos de forma simples: continuar utilizando o github para gerenciar os defeitos e mais tarde integrar o github a alguma ferramenta paga para extrair relatórios gerenciais do repositório do github.

Passo a passo você pode criar um processo, que pode ainda não estar perfeito, mas é o pŕimeiro passo para implementar isso na prática.

Inicialmente a maioria das pessoas define a prioridade de cada issue, desta forma:

  • Priority [High]
  • Priority [Normal]
  • Priority [Low]

Mas estas tags são muito subjetivas, e o que é de High Priority para uma pessoa, pode ser normal para outra e isso causa muita confusão.

Desta forma criei uma solução simples: tags personalizadas que refletem mais a realidade do dia-a-dia de desenvolvimento e são mais auto-explicativas, são elas:

Frequência:

gestao-defeitos-tag-frequencia

São utilizadas para indicar a probabilidade/possibilidade de o erro ocorrer novamente, você deve ter um olhar assim para o defeito: “Pode acontecer de novo com algum outro usuário?”

Gravidade:

gestao-defeitos-tag-gravidade

São utilizadas para classificar o impacto que o defeito gera ao usuário. Será que com o defeito continuando na aplicação ele consegue continuar realizando as tarefas dele normalmente no software ou ele não consegue contornar? Será que existem alternativas no software para que ele consiga contornar o defeito mas continuar trabalhando com o software?

Desta forma, você consegue filtrar as issues pelas tags e saber exatamente o que vai corrigir. Ah… além disso você pode criar uma label [Bug] que separa os bugs do que são melhorias [Enhacement] e/ou itens onde é necessário melhorar a usabilidade [UX/UI].

Além disso, para conseguir categorizar a priorização, vocẽ pode utilizar labels para indicar de qual Feature é relacionado o Defeito, desta forma: “[Feature] Nome da Feature”

Há também a label “Monitoring”, para aqueles defeitos que só foram possíveis serem reproduzidos uma vez. Você pode então ficar de olho  para ver se eles ocorrem novamente e então analisar com maior cuidado.

gestao-defeitos-tag-monitoring

E também há o label “Support” para identificar defeitos que foram encontrados pelos clientes:

gestao-defeitos-tag-support

Outra vantagem é que os desenvolvedores podem subir um PR com a correção do defeito associando à issue! \o/

Github Milestone

Dentro do seu processo, você pode separar algumas “metas” para reduzir o déficit técnico e selecionar mês a mês quantos defeitos vai precisar corrigir dentro de uma Release ou mesmo separar os defeitos por Sprint.

gestao-defeitos-exemplo-milestone

Assim, a cada Release, você pode adicionar um conjunto dos defeitos que fica atrelado a uma Milestone de Bugs da Release. Semanalmente você consegue acompanhar a correção dos defeitos e saber se está em um ritmo bom de correção e se vai alcançar a sua meta.

Com a evolução da milestone também você também pode acompanhar a meta até a resolução dos defeitos que englobam ela.

Obrigada por apreciar o post!  =D
Acompanhe deixando seu contato aqui!

Leia mais em:

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s