Resumo

Durante o meu fluxo de desenvolvimento de automações para validação de produtos me deparei com inconsistências que não estavam relacionados a minha demanda mas que afetavam o produto que eu atuava. Eu sinceramente ainda tenho dificuldades de concluir mapas mentais sobre o problema ao se deparar com essa situação, resolver informalmente, mapear (bug ou não?), tantas variáveis que eu tenho a necessidade abordar aqui.

DISCLAMER: Este conteúdo não se baseia em teorias aprofundadas sobre Quality Assurance, mas sim na experiência indívidual de um profissional.

Problema Atual

Bugs encontrados durante o desenvolvimento
Dúvida sobre como lidar
Incerteza de quem endereçar este problema para a solução

Consequências

Problemas não mapeados que podem escalar de gravidade
Retrabalho
Maior custo (tempo x dinheiro)

Vamos ver como isso evolui!

Visibilidade

A primeira dúvida que eu tive quando me deparei com bugs durante o desenvolvimento foi um conflito sobre dar ou não visibilidade para aquela falhar encontrada. No meu caso, não há motivo para não mapear, demanda a parte, mas o fluxo é o mesmo e o intuito de um teste automatizado é validar um fluxo compensando a repetição que é mais custoso de se fazer manualmente.

Quem é o dono desse problema?

E como eu decidi mapear o bug, como eu consigo identificar a área responsável pelo problema? Entendo que seja o mesmo fluxo de se mapear o bug de uma demanda, investigar logs, conversar com desenvolvedores, um produto que por exemplo é um SAAS provavelmente vai possuir uma divisão entre Front e Serviço (Backend), identificando se o problema é gerado localmente no front ou já vem do serviço dessa maneira, o dono do problema é o time de backend que precisa analisar.

Incognita

Até o momento tudo sem problemas, identificou um bug, tomou a decisão de mapea-lo, achou a fonte que originou o problema, existe mais uma preocupação? Sim, é um pensamento partindo de uma estrutura unificada ou bem contextualizada para todas as partes do produto. Mas se o caso for em um produto maior, de proporções escálaveis, responsabilidades cada vez mais separadas para melhor organização de uma grande fluxo de estruturas, pode se tornar um desafio entender de como funcionaria isso. Se trata de uma experiência muito indívidual, de caso para caso, e na minha o mais importante é reforçar, quem é o dono do problema (ownership de responsabilidade), é essencial que mesmo que um time de front que as demandas aconteçam sem conflitos, existir uma ponte entre o front e o serviço para auxiliar a entender o problema. E isso pode até causar uma estranheza, pois o outro time pode estar trabalhando em uma demanda e você identificou no seu lado da camada, esse bug pode ser resolvido e ter gerado retrabalho pois não vai ser mais reproduzivel no momento que cair na prioridade do outro time, por isso é importante que a figura do PO consiga contextualizar aquele bug para não cair em um limbo e só descobrir no momento, é como um parente furar fila e ficar do seu lado, vocês estão juntos, mas concorrendo pela vez.