Ir para conteúdo principal
Todas as coleçõesComeçandoIniciante
Disputas de bugs – exemplos bons e ruins
Disputas de bugs – exemplos bons e ruins

Aprenda rapidamente a diferença entre uma disputa eficaz e uma não tão eficaz.

Kostya avatar
Escrito por Kostya
Atualizado há mais de um ano

"Uma Disputa de Bug é uma funcionalidade projetada para lhe dar a oportunidade de enviar uma solicitação aos nossos Gerentes de Disputa para uma revisão final, caso você acredite que seu bug é legítimo ou tenha sido rebaixado sem motivo".

Apresentação

Receber a rejeição de um bug nunca é fácil de aceitar, mas nossos testers experientes sabem como lidar com isso. Eles entendem quando e como apresentar com sucesso uma Disputa de Bug para obter uma revisão final do relatório pelos Gerentes de Disputa. A funcionalidade de Disputa de Bug foi projetada para oferecer a oportunidade de enviar uma solicitação aos nossos Gerentes de Disputa para a revisão final, caso você acredite que seu bug é legítimo ou tenha sido rebaixado sem motivo aparente. Encontre mais informações sobre a funcionalidade de Disputa de Bug aqui.

Quando deve enviar uma Disputa de Bug

Para evitar receber um bloqueio de Disputa por um mês, é crucial ter certeza de que está enviando uma Disputa de Bug apenas para problemas dos quais você tem 100% de certeza. Embora possa parecer que estamos tentando assustar, esse não é nosso objetivo. Queremos incentivá-lo a refletir sobre o bug que enviou e as razões de rejeição ou rebaixamento fornecidas no comentário do Líder de Equipe.

Faça a si mesmo perguntas como: "Será que deixei algo passar? Enviei um registro de console para respaldar minha alegação sobre o bug? Existe a possibilidade de eu ter esquecido algo para incluir no relatório de bug? Eu compreendi corretamente o produto?". Após responder a essas perguntas, terá a resposta sobre se deve ou não enviar uma Disputa de Bug.

O que deve conter uma boa Disputa de Bug

Já pensou em entrar com uma reclamação no tribunal? Apresentar uma Disputa de Bug não é muito diferente. Ambos precisam incluir:

  • Saudação oficial para o revisor

  • Explicação do motivo pelo qual você está entrando em contato

  • Justificativa do porquê você acredita que seus direitos foram prejudicados

  • Provas adicionais, como anexos, links e registros

  • Proposta de solução para o problema

  • Saudação oficial no encerramento

Resolução de Disputas: Papel dos Gerentes de Disputa

O papel dos gerentes de disputa é assegurar a equidade na resolução de disputas entre líderes de equipe e testers.

Se ambas as partes apresentarem argumentos válidos e o peso de suas alegações for igual, a vantagem é dada ao tester, e os gerentes de disputa tomam decisões a favor do tester. Nestes casos, as preocupações dos testers têm prioridade.

No entanto, se uma disputa for rejeitada, isso indica razões legítimas para a rejeição, e o tester deve aprender com essa experiência.

Os gerentes de disputa se esforçam para manter um equilíbrio de equidade para os testers, sempre considerando as regras e a qualidade do relatório de bug, aplicando sua ampla experiência ao revisar disputas de bugs. O objetivo deles é serem o mais justos possível em seu processo de tomada de decisão.

Um exemplo positivo da Disputa de Bug

Acima, você viu o que é necessário para tornar sua Disputa de Bug bem-sucedida. Agora, vamos observar como isso funciona na prática. O exemplo abaixo aborda um cenário do mundo real. Às vezes, os testers não precisam usar todos os elementos mencionados acima para provar que o problema é válido. No exemplo positivo a seguir, você verá que o tester utilizou apenas 4 elementos:

  1. A saudação ❝Olá, Equipe de Disputa❞

  2. O motivo pelo qual o tester considera o problema um bug

  3. As possíveis consequências e o público afetado se o bug não for corrigido

  4. A saudação oficial no encerramento é ❝Por favor, revejam! Obrigado!❞

Levando em consideração que o tester foi o mais conciso possível e tão detalhado quanto necessário, podemos concluir que encontrar o equilíbrio certo é a chave para o sucesso. Além disso, aumentar as chances de uma disputa bem-sucedida pode envolver fornecer informações adicionais que não foram incluídas no relatório de bug inicial. Por exemplo, uma segunda gravação de tela ou registro de console pode ser carregada no Google Drive e compartilhada como um link na Disputa.

Um exemplo negativo da Disputa de Bug

Entrar em uma Disputa de Bug com raiva ou usando palavras duras nunca é uma boa ideia. Você pode tentar, mas isso resultará em uma rejeição, um aviso ou até mesmo uma proibição de nossa plataforma. Portanto, considere quais são os possíveis cenários ao agir de forma rude, não profissional ou violenta. Parece ruim, não é? Alguns dos nossos testers, por outro lado, não leem ou esquecem nossas regras, o que leva a rejeições de Relatórios de Bug e Disputas de Bug. No caso mostrado abaixo, o tester escreveu:

  • O título e o resultado real devem ser semelhantes.

    O título tem como objetivo fornecer uma breve descrição de quando, onde e o que acontece. Deve ser o mais conciso possível e tão descritivo quanto necessário. Por outro lado, nos Resultados Reais, os testers devem explicar em detalhes qual é o problema, destacar o escopo do problema, outras páginas afetadas (se houver), etc. Compartilhar todos esses detalhes no título do Relatório de Bug seria impossível.

  • O vídeo mostra exatamente a sequência de todas as etapas e mostra o problema descrito.

    A gravação de tela não deve apresentar todas as etapas necessárias para reproduzir o bug. Apenas as duas últimas etapas devem ser mostradas no vídeo.

O que estava faltando na Disputa de Bug ?

  • Saudação oficial no início

  • Conhecimento sobre nossas regras

  • Conhecimento sobre nossos padrões de qualidade de Relatório de Bug

  • Informações adicionais para sustentar a alegação sobre a gravidade do bug​​

Alguns exemplos de falhas comuns dos testers ao enviar uma Disputa de Bug incluem:

  1. Enviar apenas ❝Por favor, revejam!❞ na Disputa de Bug

  2. Escrever ❝Obrigado, TL. Entendi!❞ pensando que estão respondendo a um comentário ao Relatório de Bug

  3. Tratar o Gerente de Disputa como TL

  4. Mentir sobre solicitações não respondidas, etc.

Tenha em mente que analisamos o histórico de cada relatório de bug. O caminho da verdade e do trabalho árduo é a única garantia de que consideraremos você para possíveis promoções no futuro. Se sua intenção é construir uma carreira conosco, assegure-se de estar dando os passos certos nessa direção.

Isto respondeu à sua pergunta?