O Guia Definitivo de
Testes Contínuos

04. Gestão de Bugs e Incidentes¶

A gestão de incidentes é um ponto básico de eficiência dentro de uma equipe de desenvolvimento. Pela forma como os bugs são gerenciados, é fácil dizer se os testadores e desenvolvedores de uma organização sentem ou não que fazem parte da mesma equipe, com os mesmos objetivos. Essa afirmação não é dirigida apenas aos desenvolvedores, instando-os a colaborar melhor com os testadores, mas também aos testadores. Os testadores devem evitar reclamar (como às vezes fazem) quando um bug que reportaram não é corrigido e devem entender que nem tudo precisa ser corrigido, dependendo da visão global da equipe.

Uma prática ruim de gestão de incidentes que sempre nos incomoda na Abstracta é que, com as centenas de ferramentas disponíveis para a gestão de incidentes, algumas equipes ainda escolhem o e-mail como o canal designado para reportar bugs. Ou pior, não usam nada e o testador simplesmente dá um tapinha no ombro do desenvolvedor após encontrar um bug.

Qual é o problema de reportar bugs sem registrá-los com uma ferramenta adequada?

Basicamente, é impossível fazer o acompanhamento, manter um registro, saber o status de cada incidente (se já foi resolvido, verificado etc.) ou até mesmo, se houver uma equipe de testadores, ter claro o que já foi reportado por outro testador para não ser reportado novamente.

Claro, mesmo ao usar uma ferramenta de gestão de incidentes, ainda haverá a necessidade de conversar cara a cara, mas elas ajudam a adicionar esclarecimentos. Por exemplo, pode-se comentar e mostrar diretamente, no momento, o que aconteceu e, assim, comunicar de forma mais eficaz.

O esquema a seguir resume um possível ciclo de vida de um bug (poderia haver mil variações disso de acordo com a estrutura da equipe, o tamanho etc.).

Um dos erros mais típicos na gestão de incidentes que nossa equipe viu ao trabalhar com diferentes empresas em ambientes tradicionais e ágeis tem a ver com o momento em que um bug é considerado "corrigido" e o desenvolvedor o marca como fechado.

É importante lembrar que o testador deve verificar novamente se um bug foi devidamente corrigido antes de fechá-lo!

Primeiro, o testador o reporta e depois o desenvolvedor o corrige, mas quem deve, em última análise, determinar se ele foi resolvido é o testador que o reportou em primeiro lugar. E se o desenvolvedor acha que ele desapareceu, mas, ao testar mais a fundo, ele ainda está lá? E se um novo bug foi criado em seu lugar? Um testador deve sempre voltar e verificar se o bug não existe mais, a fim de minimizar o risco.

Existem várias outras variações válidas desse esquema. Por exemplo, poderia haver alguém com a responsabilidade de revisar os incidentes que chegam e decidir quais corrigir e quais não corrigir. Essa situação poderia funcionar dentro do fluxo acima, seja o testador ou o desenvolvedor quem marca um bug como "resolvido", "não será corrigido", ou, por meio de um diálogo (via ferramenta ou outro meio), tanto o testador quanto o desenvolvedor poderiam decidir juntos qual é a decisão apropriada, mostrando um acordo mútuo entre os dois.

Neste ponto, você pode estar se perguntando: "Por que isso é importante para os testes contínuos?" Como afirmado anteriormente, este é o principal ponto de interação entre testadores e desenvolvedores, estejam eles sob o mesmo teto ou em países distantes. Além disso, existem ferramentas como o Jira que permitem a rastreabilidade entre os problemas reportados na ferramenta e o código, o que, para aproveitar ao máximo esses recursos, exige que tudo esteja bem mecanizado.

As equipes de teste mais maduras têm uma máquina de resolução de incidentes perfeitamente azeitada (usando uma ferramenta de gestão de incidentes designada), já que a maior interação entre testadores e desenvolvedores está no vai e vem desses mecanismos.