Máquina de estados de defeitos

No último post foi comentado sobre a reportagem de defeitos, um pouco sobre a sua importância e algumas informações importantes de serem registradas ao se abrir um defeito.

E depois que ele foi aberto, o que acontece? Se há algo errado, espera-se que ao menos na maioria das vezes seja corrigido (volto a essa observação em um post sobre critérios de saída). Então de Aberto o bug vai para? Corrigido. Muito bem, é só isso? Claro que não! :) Agora você vai re-testar e ver se o bug realmente foi corrigido (e preferencialmente testar as funcionalidades que tem relação com a área em que foi encontrado o bug para garantir que ao corrigir um problema não foi(foram) criado(s) outro(s)). E agora sim ele está Verificado.

O ciclo de vida mais simples possível de um bug seria: Aberto – Corrigido – Verificado.

Se não há controle sobre a máquina de estados de um erro na sua empresa esse é um excelente ponto de início. Mas com o tempo (bem pouco tempo) esse ciclo vai se mostrar pobre e já não vai atender às necessidades de respostas do projeto. E então temos a oportunidade de elaborar mais um pouco. Ao invés de apresentar primeiro a clássica figura de máquina de estados, vamos a um jogo de perguntas e repostas. Se a pergunta q eu estiver fazendo não parece se encaixar na sua realidade, ou você acha que é exagero, então pra sua realidade ela provavelmente não serve e é provável que você possa abrir mão desse status.



Desvendando a máquina de estados

Claro que os nomes que serão utilizados aqui podem ser mudados, o que importa é a semântica. Vamos ao P&R (onde P onde ser Pergunta ou Problema ;) ).

Abri um defeito, ele está há dias para ser corrigido e eu tenho a sensação que ninguém está sequer olhando para ele.


Ou ainda, há um atraso considerável na correção dos defeitos abertos. Os defeitos parecem estar em um cesto e os desenvolvedores puxam qualquer um para resolver. Não sei qual o tempo médio de resposta de acordo com a prioridade/severidade indicadas no defeito.

Para essas, que tal incluirmos um estado intermediário entre Aberto e Corrigido?

Aberto – Designado – Corrigido

Nesse caso é interessante ainda ter um campo Designado Para. Assim é possível saber quem está responsável pelo bug naquele momento. Quando Aberto pelo time de testes, o bug será Designado para o time dev. Como comentado no post anterior, pode ser para o líder para que ele de acordo com o seu acompanhamento indique quem irá corrigir o bug ou pode ser direto para o desenvolvedor. Após a correção, quando o desenvolvedor marcar o bug como Corrigido, o campo Designado para vai conter o nome do testador que abriu o bug (preferencialmente) ou do líder de testes para que ele indique quem irá verificar a correção. O campo Designado para então é um campo ativo em todos os status. Sempre que a responsabilidade de verificação do bug mudar, o campo deverá refletir essa mudança.

Eu verifiquei o bug, tava certinho, mudei o status dele para Verificado. Mas não sei se essa correção já foi integrada no novo build que me deram para testar. O responsável pelo build tem um monte de defeitos para integrar e precisa saber que defeitos já foram integrados e quais ainda não foram já que a todo instante a equipe de desenvolvimento está entregando correções.

Podemos então incluir um status após Verificado. Integrado.

Aberto – Designado – Corrigido – Verificado – Integrado

Mas pode haver problemas na integração, certo? E como eu sinalizo isso?

Que tal incluir um status após o Integrado para sinalizar que o bug está realmente encerrado tendo sido verificado inclusive em produção.

Aberto – Designado – Corrigido – Verificado – Integrado – Fechado

Esse é “caminho feliz”, certo? Aquele em que o defeito foi detectado, corrigido eficazmente, verificado, integrado e não deu nenhum probleminha nessa seqüência. Mas e se eu quiser controlar os bugs que o desenvolvedor disse que estavam corrigidos e que na verdade não estavam? Volto eles para Aberto? Para designado?

Até poderia ser, mas que tal um status Reaberto para sinalizar claramente que a correção não foi efetiva? O Reaberto teria então o mesmo valor do Aberto e a partir daí, segue-se o fluxo normal.

E se eu abri um defeito, mas na verdade eu me equivoquei? Como faço para mandar ele pra Fechado?

Não faz! :) Cria um status Cancelado para indicar que não era um bug.

E logo no comecinho do post foi falado em bugs que não são corrigidos, critérios de saída... Não dá pra adiantar nada sobre isso?

Às vezes nem todos os bugs são corrigidos. Há uma negociação com o cliente e esses defeitos vão como Conhecidos. Veja bem, não é dizer que não tem defeitos, é sinalizar que eles existem, são conhecidos, mas o cliente está aceitando recebê-los mesmo assim.

Ou ainda, um defeito pode não ser corrigido na iteração corrente, mas na próxima iteração devido ao seu impacto em outras funcionalidades ou devido ao total de trabalho já previsto para determinada iteração. Pode ser um defeito Adiado.

Alguns outros campos podem dar suporte aos status, assim como o Designado Para, poderíamos usar um campo versão do build para indicar em que versão o bug foi Integrado, versão do release ou iteração para indicar a iteração em que será integrado o bug Adiado e por ai vai.

Abaixo uma figurinha da máquina de estados do Bugzilla. Há diferenças em relação ao post, mas como comentei antes, o que interessa é a semântica e não é porque o pessoal do Bugzilla desenhou que esse fluxo se encaixa na sua realidade, certo?

Como na maioria dos meus posts eu incentivo: pense, questione, reflita. Testar é essencial, não burocrático. Faça do seu trabalho o mais prazeiroso possível, torne suas atividades úteis. Evite burocracia :)