BIGtheme.net http://bigtheme.net/ecommerce/opencart OpenCart Templates
23/08/2017 - 11:48 AM

Bug e sua priorização em equipes Ágeis

Antes de iniciarmos a questionar quais formas e como priorizar devemos entender a diferença entre: Erro, Defeito e Falha.

Segundo o Syllabus CTFL: O ser humano está sujeito a cometer erros, este erro produz um defeito (bug) no código, sistema ou documento, se este defeito for executado irá ocorrer uma falha.

Devemos diferençar melhorias de bugs, um exercício que pode ser feito neste momento é:

Melhoria é tudo que já existe e funciona, porém quer-se adequar a algum padrão, cor ou estilo, alterar a experiência do usuário ou em aspecto lógico alterando performance e ganhando qualidade.
Bug é tudo que já existe porém não está funcionando como previsto.
(Lembrando que este é um previ resumo, pois este assunto é muito abrangente)

Priorização de Bugs: Como deve priorizar bugs? Com base em qual matriz traço a priorização? Sprint e Bugs? Priorizar bugs durante a sprint? São muitas as perguntas, neste texto a seguir colocarei alguns pontos importantes quanto a minha concepção destas questões

..:: Como devo priorizar Bugs? ::..

O processo natural de priorização dos bugs vem as decorrer que equipes ficam maduras o suficiente para entender a complexidade e impacto ao cliente do problema, alguns guias e boas práticas podem ser inclusas no processo para ajudar na maturidade da equipe. Algumas empresas e autores descrevem uma matriz de priorização como sendo um dos pontapé iniciais para esse processo, esta matriz possua dois aspecto: Frequência e Gravidade.

Figura 1 – Matriz de Priorização de Bugs

Nesta matriz utilizei o conceito de Nível de Criticidade onde N1 é o mais crítico e N4 é o menos crítico, mas isto pode ser alterado conforme um pré-padrão que as empresas possuem. O que deve ficar claro é que tudo está em mudança e consequentemente alterações nesta matriz iram ocorrer conforma a maturidade. O time tem toda autonomia para contestar que: Exemplo: Ocorre Sempre e Consegue realizar tarefa é N4 em vez de N3.

Utilizando esta matriz poderemos já tirar um peso dos ombos em relação a como tratar os bugs e priorizar.

..:: Sprints e Bugs::..

Quando a feature está dentro da sprint e ela é fechada e o QA realiza os testes e constata que existe um bug,deve-se abrir um bug na ferramenta de gestão de bugs? A feature deve ser reprovada e o desenvolvedor deve fazer os reparos antes da sprint terminar? Creio que dentro da comunidade esta questão já está dissolvida: Se a feature está dentro da sprint, foi finalizada, QA encontra problema, ela deve ser reprovada e o Desenvolvedor deve realizar os reparos antes de finalizar a sprint, como deve ser previsto na Planning da equipe, toda feature possui obstáculos e o QA é um (kkk), brincadeiras a parte, toda feature possui seu impacto e complexidade assim como probabilidade de ocorrer falhas durante os testes, então bugs relacionados a features dente de sprints devem ser resolvidos dentro da sprint sem necessidade de abertura de bugs na ferramenta de gestão de bugs.

..:: Bugs de Backlog em Sprint ::..

Aqui o bicho pega! Não existe consenso e nem forma correta, o que existe é um certo padrão informal criado pela comunidade onde 20% da sprint fica locada para bugs de backlog.

..:: Bugs durante Sprint ::..

Aplicação morreu, cliente está ligando desesperado… O cliente tem que esperar a próxima Sprint? NÃO! Devemos levar em consideração com base na Matriz de Priorização de bugs mostrada acima que N1 é o nível mais crítico, e que a equipe deve parar qualquer atividade e resolver este problema, claro esta atitude vai de encontro ao que a empresa definiu como crítico.

 

Informações importantes:
A Matriz de priorização inserida acima foi criada com base em uma palestra ministrada por Barbara Cabral e foi realizada adaptações e alterações.

Sobre Luiz Lohn

Luiz Lohn
Mobile QA Engineer, trabalha há mais de 4 anos com qualidade e teste de software. Atualmente na SocialBase trabalha com automação e testes manuais de Aplicativos Móveis. Fundador do site QUATEST e coordenador do GUTS-SC

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *