Às vezes, minha equipe de controle de qualidade relata erros, mas nem eu nem eles temos alguma idéia de como reproduzi-los. Isso leva a sessões de depuração muito longas e frustrantes que às vezes nem produzem resultados.

Meu software está fortemente vinculado a hardware proprietário, para que os erros possam vir de várias direções ao mesmo tempo.

Devo esperar mais deles do que "seu software travou quando eu apertei um botão" ou devo imaginar o que aconteceu?

EDITAR:

Um colega de trabalho apontou que provavelmente somos todos desenvolvedores aqui, portanto os resultados podem sofrer um pequeno viés

O controle de qualidade deve sempre tentar tornar os bugs o mais fácil possível de reproduzir e a descrição do bug deve conter as etapas executadas.

No entanto, se eles não conseguirem reproduzir facilmente os bugs, eles ainda devem ser inseridos no banco de dados de bugs com títulos / títulos adequados e uma descrição completa do que fizeram para causar o bug. A descrição do bug deve indicar claramente que eles não podem reproduzi-lo (talvez com algum comentário parecido com "tentei cinco vezes, aconteceu uma vez"). Dessa forma, se outra pessoa vir o mesmo bug, ela poderá adicionar ao banco de dados de bugs com suas descobertas e você obterá o máximo de informações possível, o que pode ser vital para poupar seu tempo, rastreando o problema.

Além disso, você pode filtrar as informações - pode haver muitos bugs em sistemas diferentes que você sabe que estão todos vinculados a (por exemplo) uma área do código - se o controle de qualidade não reportar nada (pois eles não podem reproduzi-los) ), essas informações não chegam a você.

Parece que seu departamento de controle de qualidade está fazendo muitos testes exploratórios (ou seja, eles não têm um bom plano de teste).

O teste exploratório é bom e identifica áreas problemáticas, mas a partir daí eles devem definir casos de teste reproduzíveis (ou seja, um plano de teste) para executar, revelando erros específicos.

Há várias razões pelas quais uma reprodução correta é necessária (não apenas boa, mas necessária):

1. Você precisa se reproduzir novamente para poder depurar / rastrear a causa.
2. O controle de qualidade precisará verificar a correção assim que terminar.
3. Passes de teste adicionais precisarão fazer regressões em bugs anteriores.
4. Os erros conhecidos podem ser descartados se a exposição for muito pequena ou se a reprodução for muito improvável.

Assim, como SteveCzetty observa: Feche-o como não reproduzido e volte ao trabalho.

Se o bug não puder ser reproduzido de forma consistente, como o controle de qualidade saberá se foi corrigido?

Sim, você deve esperar mais deles. Eles devem ser capazes de dizer:

1. Iniciou nova instância do programa
2. Pressionei o botão A
3. Insira "texto de teste" no campo NOME DO TESTE no Formulário 1
4. Pressione o botão B
5. Observou que o programa falhou com esta mensagem (consulte a captura de tela em anexo).

Se tudo o que eles dizem é "caiu", não são muito bons. Mesmo que as etapas acima não sejam 100% reproduzíveis, uma amostra grande o suficiente dessas falhas pode ajudar a diminuir a causa, assim que um padrão for detectado.

Meu conselho é ler esses bugs e dar a eles um bom pensamento antigo. Se você não conseguir descobrir uma causa potencial, esqueça-a por enquanto.

O controle de qualidade deve documentar todos os problemas encontrados, mesmo que eles não tenham idéia de como isso aconteceu. O trabalho do controle de qualidade é tentar reproduzir os problemas, mas, realisticamente, isso nem sempre é possível. Às vezes, isso não tem nada a ver com o que eles fizeram nos últimos 10 minutos. Algo entrou em um estado inválido há um dia e ficou aparente por causa de uma das últimas 10 etapas.

Com esses erros "1 em 1000", o controle de qualidade deve tentar reproduzi-los um pouco. Se eles não obtiverem sucesso, devem documentar o bug e tentar um pouco mais.

A razão pela qual eles devem inserir o bug com bastante antecedência é que o programador conhece o código muito melhor que o controle de qualidade e pode saber imediatamente o problema. Pode ser o código que eles refatoraram. Poderia ser a função que eles implementaram pela metade e depois esqueceram. Eles podem não ter idéia, mas não faz sentido o testador desperdiçar algumas horas tentando reproduzir um problema que é óbvio para a pessoa que o codificou. O testador sempre pode adicionar mais detalhes ao bug posteriormente.

O bug deve incluir o máximo de informações possível. Tudo o que o testador puder lembrar sobre a preparação para o problema deve ser anotado com detalhes dolorosos. Quaisquer logs de falhas, instantâneos de banco de dados ou capturas de tela relevantes também devem ser anexados.

Se o bug nunca for reproduzido, ótimo! Não faz mal tê-lo no banco de dados. Se o programa for lançado e um usuário relatar um erro semelhante posteriormente, você poderá comparar a experiência deles com o que está no relatório e procurar outras similaridades.

Na minha experiência, os erros mais interessantes não são encontrados nos planos de teste a seguir. Às vezes, você precisa deixar as coisas cozer por algumas semanas para alinhar a lua e as estrelas, causando um erro desagradável. Se o controle de qualidade puder fazer algum trabalho de detetive e encontrar algumas causas possíveis, dê um tapinha nas costas. Mas, às vezes, quem sabe o que aconteceu?

Muitos bugs não são reproduzíveis até você saber como corrigi-los. Isso não significa que eles não precisam ser consertados. Corrigi um bug no ano passado que ainda não sei como reproduzir. Requer alguma combinação bizarra de um erro de transmissão com tempo preciso, juntamente com dados de lixo muito específicos em um determinado local de memória na pilha. Infelizmente, um de nossos clientes tem a "sorte" de entrar nessa condição o tempo todo.

Portanto, incentive o controle de qualidade a incluir etapas de reprodutibilidade sempre que possível, mas não as culpe se não puderem. Às vezes, ajudará você a saber onde adicionar o log. Às vezes, tudo o que faz é dizer o que não causa o erro, mas um relatório de erro é sempre útil.

Se você quer dizer que o controle de qualidade deve incluir as etapas para reproduzir o erro, se puderem, a resposta é sim. Se você quer dizer que eles devem apenas gravar bugs, eles são capazes de se reproduzir, absolutamente não. Bugs são bugs, se eles só acontecem à meia-noite na lua cheia ou toda vez que você olha para ele. Alguns erros são não determinísticos (o exemplo clássico é uma variável não inicializada, onde o valor captado é semi-aleatório), o que não significa que eles não devam ser registrados, investigados e, se possível, corrigidos.

Bugs não reproduzíveis geralmente devem ter uma baixa prioridade, mas definitivamente devem ser registrados.

OMI, você deveria. O controle de qualidade não fará o trabalho deles se não puderem dar a você nenhuma etapa de reprodução. Não perca seu tempo tentando reproduzir algo que não pode, basta fechá-lo como "Não é possível reproduzir" e seguir em frente.

Seu tempo é muito mais valioso que isso.

Um relatório de erro deve conter:

• Passos para reproduzir
• Comportamento real
• Comportamento esperado

Por exemplo:

• Excluí todos os fornecedores do banco de dados (usando DELETE * FROM tSuppliers), abri a caixa de diálogo do fornecedor e cliquei na lista suspensa Fornecedor.
• A lista continha a seguinte mensagem: GUPOS ERROR #0000000: SOMETHING WENT WRONG!. Quando cliquei na mensagem, o aplicativo desapareceu da tela e do Gerenciador de tarefas.
• Eu esperava ver uma lista vazia ou (de preferência) uma mensagem como "Nenhum fornecedor encontrado". Clicar na lista vazia ou na mensagem não terá efeito. Obviamente, o aplicativo não deve desaparecer sem aviso prévio, sob nenhuma circunstância.

Então, sim - deve conter as etapas para reproduzir. O fato de eles não sentirem a necessidade de incluir isso parece indicar que eles acham que seu trabalho é "interromper o software", em vez de identificar falhas.

O controle de qualidade deve poder reproduzir os erros com base nas etapas inseridas. Se eles tentaram muito, ainda não conseguiram se reproduzir, ainda assim devem inserir os erros com os detalhes que possuem com o registro de data e hora, para que os desenvolvedores possam dar uma olhada no aplicativo e nos logs de depuração para obter mais detalhes.

O dinheiro está em jogo aqui. Por que qualquer membro da equipe deveria ser capaz de criar uma tarefa mal definida e com poucas chances de sucesso que sobrecarrega um desenvolvedor (com sorte) altamente remunerado?

Não se trata de hierarquia, hierarquia, arrogância, nós vs. eles ou algo assim. Trata-se apenas de investir em atividades que agregam valor ao produto.

Quando for possível demonstrar que um problema afeta negativamente e de forma mensurável o valor do produto, ele deve ser investigado, reproduzido e corrigido. Corrija o pipeline de defeitos do produto para filtrar o ruído.

sua equipe de controle de qualidade é uma merda

Vá até eles e peça para lerem um documento que qualquer testador profissional deve ter impresso bem dentro de seus cérebros (eu fui testador uma vez e ainda o tenho no meu cérebro): Como relatar erros de maneira eficaz .

Particularmente, aponte-os para a seção "Mostre-me como me mostrar" :

Esta é a era da Internet. Esta é a era da comunicação mundial. Esta é a época em que posso enviar meu software para alguém na Rússia com o toque de um botão, e ele pode me enviar comentários sobre o mesmo com a mesma facilidade. Mas se ele tiver um problema com o meu programa, ele não poderá me colocar diante dele enquanto ele falhar. "Mostre-me" é bom quando você pode, mas geralmente não pode.

Se você precisar relatar um bug para um programador que não pode estar presente pessoalmente, o objetivo do exercício é permitir que ele reproduza o problema. Você deseja que o programador execute sua própria cópia do programa, faça as mesmas coisas e faça com que falhe da mesma maneira. Quando eles podem ver o problema acontecendo diante de seus olhos, eles podem lidar com isso ...

Se eles começarem a gritar com você, reclamando que "os bugs podem vir de várias direções ao mesmo tempo" , diga a eles que eles sugam ainda mais do que você pensava antes. Diga a eles que a testabilidade é um recurso que eles devem avaliar entre outros recursos do projeto e devem investir esforços para obter esse recurso corretamente.

• As melhorias de testabilidade que se pode obter quando há um testador profissional focado nele podem ser muito parecidas com mágica. Aprendi isso alguns meses atrás. O engenheiro de controle de qualidade que trabalhava com nossa equipe me forneceu algumas solicitações de testabilidade para desenvolver alguns componentes em nosso aplicativo. As coisas sobre as quais ele perguntou faziam muito pouco sentido para mim, mas eu dei a ele assumindo que ele sabia melhor como profissional. Logo depois que terminei, ele encontrou uma ferramenta que reduzia os esforços de teste por ordem de magnitude . Ele disse que a maior parte foi baseada nesses pedidos enigmáticos que eu implementei, vai entender.