Este artigo nasceu de uma postagem no fórum interno de nosso escritório, uma pequena discussão, uma pequena adição, e então decidi colocá-lo na forma final aqui para facilitar a vinculação.
Sim, o post é capitão, esse é o comportamento esperado :) Eu só quero que ele seja coletado, organizado e geralmente disponível.
Introdução: encontre um gato
Existem erros nos produtos que desenvolvemos.
Às vezes os encontramos. Às vezes até escrevemos.
Para ajudar nossos colegas a melhorar seu produto.
E ficamos muito ofendidos quando nossos colegas nos escrevem: "Eu não entendo o nicrômio", "ele não toca para mim", "venha e mostre.
Às vezes eu digo isso.
Porque muitas vezes os insetos se parecem com a imagem “encontre um gato”.
Quem escreveu o bug sabe exatamente onde está o gato. Ele já encontrou. Ele não pode mais vê-lo.
E eu tenho que sentar, cavar no monitor e procurar uma porra de gato.
Muitas vezes, um vídeo é anexado a um bug. Afinal, o vídeo mostra tudo!
Tudo é o mesmo lá, apenas a grama ainda está balançando (movimentos do mouse) e os portões abertos (diálogos irrelevantes abertos).
Neste ponto, falo sobre as regras para registrar bugs, que tento seguir por mim mesmo e que recomendo a outras pessoas.
Minhas regras pessoais para registrar bugs
1) Palavras-chave no cabeçalho do bug
Para que você possa entender rapidamente a qual competência um bug pertence.
2) Passos para jogar
E é muito, muito importante. E sim, compilá-los leva mais tempo durante a gravação.
Porque muitas vezes, iniciando, anotando etapas e jogando fora as "extras", você entende que o bug nem sempre é reproduzido.
3) " comportamento esperado " vs " comportamento observado " nas etapas em que, de fato, ocorre um erro.
Isso é crítico. Porque nem sempre é o que uma pessoa espera ver, corresponde a como realmente é. Então você pode procurar o gato sem parar.
4) Screenshots são bons
As imagens fornecem um contexto visual, mostram ao desenvolvedor partes do produto com problemas e ele imediatamente entende a área de conhecimento necessária. A imagem a esse respeito funciona em conjunto com as palavras-chave (consulte o parágrafo 1)
5) O vídeo é bom, mas somente quando mostramos um bug de animação
E - o vídeo é algo com o qual você pode basicamente viver quando o autor do bug não pode escrever as etapas de reprodução.
Ou o erro é não determinístico e é necessária prova.
Em outros casos, o vídeo é redundante.
O vídeo para o bug deve ser para o bug. 10 segundos, sem abrir as janelas esquerdas.
6) Empilhar erros de rastreamento / console com execução explícita
Bem, quase todo mundo entende isso e aplica, eu escrevo apenas para completar a lista.
7) Um exemplo para reprodução .
Se estamos falando de algum tipo de sistema de desktop, precisamos de um arquivo no qual o problema seja reproduzido.
Na Web, é mais fácil - você pode frequentemente vincular uma demonstração on-line (ou um ambiente de armazenamento temporário expandido).
Isso é tudo em uma primeira aproximação.
Eu compartilho isso com outras pessoas - e muitas vezes elas acreditam em mim e começam a fazer o mesmo.
Mais exemplos e 20% dos detalhes, que ocupam 80% do artigo :)
Exemplos
Um exemplo de erro é como eu os escrevo, e qual é mais ou menos :)
O dxTreeView cria indicadores de carregamento redundantes no modo virtual
Mais ingressos (apenas uma seleção aleatória da lista de ingressos públicos gravada por nossa equipe)- Painel da Web - Os botões Redefinir e Enviar desaparecem no item personalizado Parâmetro após o envio do valor do parâmetro
Para reproduzir o problema, execute o projeto anexado, altere o valor do parâmetro no item personalizado Parâmetro e clique no botão Enviar.
Resultado real: Os botões Redefinir e Enviar desaparecem.
Resultado esperado: Os botões Redefinir e Enviar devem ser mostrados.
- Visualizador do painel da web - Os botões da barra de ferramentas são mostrados quando qualquer parte do controle é clicada em um monitor ativado por toque e as legendas dos itens são ocultadas
Execute o projeto e clique em qualquer parte do visualizador para reproduzir o problema.
Resultado real: os botões da barra de ferramentas são mostrados.
Resultado esperado: os botões da barra de ferramentas devem ser mostrados apenas ao passar o mouse sobre eles.
Como solução alternativa, execute o seguinte código (interno) no manipulador de eventos OnInit:
function onInit(s, e) { DevExpress.Dashboard.Internal.DashboardLayoutModeHelper.isTouch = false; }
- ASPxDashboardViewer / MVCxDashboardViewer - Uma exceção é gerada se você abrir painéis com guias (isso não é esperado, mas é óbvio no título do bug. Isso acontece, tudo bem.)
O controle ASPxDashboardViewer antigo e a extensão MVCxDashboardViewer não oferecem suporte ao item do painel de contêiner da guia em comparação com o ASPxDashboard / MVCxDashboard. Quando o ASPxDashboardViewer / MVCxDashboardViewer abre um painel com um contêiner de guias, ocorre uma exceção no lado do cliente. É necessário mostrar a mensagem pop-up correspondente em uma interface do usuário do painel.
- Web do painel - o painel de ligação permanece transparente em certos casos (aqui está o vídeo, porque é um bug muito ruim, tentamos capturá-lo por um ano e meio)
Passos para reproduzir:
- Crie um painel com um item. Verifique se o painel de encadernação se sobrepõe ao item quando aberto.
- Selecione o item
- Abra o painel de encadernação (por exemplo, clique no botão 'Opções') e mova o cursor sobre o painel até o momento em que o cursor foi colocado sobre o item. O painel de encadernação fica transparente (esperado)
- Clique no item do painel. Painel de encadernação fechado.
- Clique no botão 'Opções' novamente.
Resultado real:
O painel de encadernação é transparente.
Resultado esperado:
O painel de encadernação não é transparente.
A etapa principal é fechar o painel de encadernação clicando no item enquanto estiver transparente.
O screencast está anexado.
- Painel da Web - item de tela cheia - o Pivot opera incorretamente no estado maximizado
- Abra a demonstração RevenueAnalysis.
- Expanda a coluna "Bicicletas" do Pivot.
- Recolher a coluna "Bicicletas" do Pivot.
- Maximize o item do painel Dinâmico.
Resultado esperado: a coluna "Bicicletas" do Pivot deve ser recolhida no estado maximizado.
Resultado: a coluna "Bicicletas" do Pivot é expandida no item maximizado.
- A dica de ferramenta do gráfico pode ser cortada se um contêiner personalizado for usado
Passos para reproduzir:
- Use o contêiner do gráfico como o contêiner de dica de ferramenta;
- Mostre uma dica de ferramenta em alguns pontos próximos à borda do gráfico;
- ERRADO. A dica de ferramenta é mostrada fora do contêiner ou pode ser cortada dependendo da configuração de estouro do contêiner.
ESPERADO. A dica de ferramenta deve ser mostrada dentro de seu contêiner até ajustar o tamanho do contêiner.
E outros
Filosofias e pequenos detalhes definidores
Preparação da captura de tela
As fotos devem estar com grandes setas vermelhas ou mesmo com legendas.
A captura de tela deve fazer parte do corpo do bug, diretamente no texto.
Se o bug for relatado na maioria dos sistemas modernos, isso será feito simplesmente colando a imagem da área de transferência com Ctrl + V
Por que você não pode simplesmente dar um link para a imagem? Porque há uma perda de contexto. Se você olhar a figura, não verá o texto. Se você vir o texto, não verá a figura. Se você vê isso e aquilo - a probabilidade de algo clicar no cérebro é muito maior.
Um minuto de deformação profissional
É por isso que os painéis como um fenômeno de análise de dados estão se tornando populares :)
Quando uma pessoa vê os mesmos dados em diferentes formatos e de diferentes ângulos, o insight pode chegar a ele.
Veja Steven Few e outros autores para obter detalhes.
O tamanho da captura de tela é sempre um compromisso.
Quando pequeno, o problema é melhor visualizado e ocupa pouco espaço. Mas nem sempre é claro de onde essa peça veio.
Eles capturaram a área da tela um pouco mais - detalhes estranhos se encaixam. A tela na qual o pop-up foi aberto, na qual o erro. O navegador no qual o erro. Botão Iniciar para o Windows no qual o erro. O DPI do monitor no qual o erro ... ah, mas o erro em si não é mais visível. O gato se tornou dois pixels e indefinível mesmo dentro do círculo vermelho.
Onde parar de cortar uma captura de tela é sempre uma arte)
Exemplos de capturas de tela, de pequenas a grandes:
relatório de erro no Código Penal, a grade está quebrada
O problema é claramente visível, mas o contexto está perdido. Se não houvesse inscrição nas palavras de que estava perto da entrada principal, o soldador andaria pelo local com uma máscara, procuraria.
na comunicação pessoal, uma pergunta sobre a implementação do TreeView
É mostrado qual elemento eu tenho em mente (sinal de mais ... bem, vá traduzir melhor o botão estender :)), o contexto é visível (nova tela do assistente)
- O problema com o dimensionamento de demonstrações do painel em DPI = 125%
Pode-se ver que tipo de navegador e URL do site
As guias são desnecessariamente desfocadas, para não distrair. Um artigo foi deixado sobre o Windows 10 Creators Update (no qual o 125% de DPI se tornou o padrão em laptops de 15,6 ″) para que, olhando para esta captura de tela, eu lembrasse disso e fosse capaz de mostrar e falar sobre isso.
Vamos enfatizar novamente. Com ferramentas normais, o tempo de preparação para cada uma dessas capturas de tela é de 5 a 30 segundos.
Isso não é fruto de uma longa obra de arte. É rápido e eficiente. Você pode parar e levar cada um à perfeição ... mas, como regra, isso não é necessário.
Programas para tirar screenshots
- Yandex.Disk, eu amo muito sua captura de tela . Bem, aqui está. Por alguma razão, acabou sendo o melhor do que tentei fazer setas, circule com um pequeno quadrado e adicione inscrições legíveis. Todos os exemplos do artigo são feitos nele.
- Monosnap (gratuito, com um plano pago). Em princípio, muito nada, mas (subjetividade!) As setas são feias;
- ShareX (totalmente gratuito);
- Jing tem sido amplamente utilizado por nossos engenheiros de suporte técnico; saindo lentamente, porque ele escreve um vídeo em um flash desagradável.
- No Windows 10 - combinação integrada Win + Shift + S # Comentário do autor: muito bom
- captador de tela incorporado no Mac # ,
- GreenShot - Nº de vitória, #
- LightShot - Mac / Win #
- Captura do FastStone #
- FlameShot (Linux, no github discute a possibilidade do Windows)
- Ferramenta de recorte - Construído no Windows #
- gooncam #
- PicPick (Windows) #
- Espetáculo e KSnapshot (Linux) #
- Problem Steps Recorder - embutido no Windows, iniciado via PSR a partir da linha de comando
Anotamos o problema, não a solução
Este item surgiu como resultado de discussão interna. Muito inesperadamente, não ficou claro para todos, portanto - um exemplo.
Por exemplo, estou testando um designer de painel e vejo algo assim:
E eu estou escrevendo um bug:
"Não há rolagem horizontal"
Posso até escrever com etapas e o resultado esperado: smiley:
Resultado esperado : o nome da regra deve ser rolado horizontalmente.
resultado real : o nome da regra não é rolado
O bug é estruturado normalmente, mas isso não impede que o desenvolvedor me considere um idiota. E ele estará certo :)
Existem problemas: "o texto não é visível na íntegra; o texto é sobreposto ao ícone"
Mas, em vez de registrar esse problema, registrei minha solução para esse problema. Um dos muitos, e certamente não o melhor.
E essa substituição não ocorre tão raramente. Mesmo eu, às vezes entendo isso.
Afinal, eu sei exatamente como consertar isso. Então, eu vou escrever!
(Bem, às vezes eu realmente sei. E tento escrever minhas sugestões no corpo do bug, depois de realmente descrever o problema. Mas não como a única solução possível)
Exemplo profissional para reprodução
No desenvolvimento da área de trabalho, esse item é discutível. Por um lado, a utilidade de executar código de exemplo que reproduz o problema é clara para todos.
Por outro lado, a criação de um exemplo já aumenta significativamente o tempo necessário para escrever um bug, até um pedido.
Em geral, a meu ver, desta maneira: para casos complexos, é necessário; em casos simples, pode ser redundante.
Fui ensinado na universidade que, se o sistema de segurança se torna muito complexo e traz danos e inconvenientes, eles simplesmente param de usá-lo.
Se você exige que um exemplo seja feito para cada bug, em um mês eles receberão exemplos mesmo de bugs complexos)
Por outro lado, em erros simples, você pode treinar para dar exemplos ...
Em suma, a questão é discutível.
Vou adicionar um artigo de CTO do nosso escritório ao cofrinho há dez anos, onde ele explica por que pedimos exemplos aos nossos clientes.
Uma solicitação de exemplo de programas simples 10 por Julian
E há um momento com exemplos simplificados, citação:
Um exemplo altamente simplificado é certamente bom, mas também ruim. Houve casos repetidos que um exemplo simplificado:
- não cobre todos os cenários de um bug;
- não reflete o cenário real, o que pode levar a uma solução inadequada.
Idealmente, é melhor ter uma amostra simplificada e original.
Agora você sabe que:
- preparar exemplos é muito útil;
- é difícil;
- o principal é não exagerar.
Tempo de registro de bug
Acabou muitas cartas. Pode parecer um procedimento burocrático complicado, longo e tedioso.
Portanto, não deve ser difícil e longo.
A mediana do tempo de gravação de um bug que satisfaz os requisitos dos requisitos acima é de cerca de um minuto.
Sim, nos casos em que as etapas não reproduzem o bug; ou que eles não são todos importantes e queriam remover o excesso; ou um novo passo foi revelado no processo - então o tempo aumenta.
Mas a probabilidade de que seu bug seja corrigido e não seja fechado com o comentário "não pode ser reproduzido" está aumentando significativamente.
Oposição
O que eles me dizem quando compartilho minha visão:
o bug é óbvio
É óbvio para alguém que já encontrou um gato.
Sem uma descrição detalhada e etapas, todos os outros terão que procurá-lo. Tempo não determinístico.
Sim, minha esposa e VYudachev encontraram o gato nos primeiros três segundos. Dois da minha amostra.
E o resto das pessoas (cerca de uma dúzia), cujos monitores eu olhei, procuraram um gato por até cinco minutos.
Mas, em geral, cuspi e imediatamente abri um palpite.
E com erros mal escritos a mesma coisa.
o vídeo é suficiente, tudo é visível lá
Em primeiro lugar, para o leitor do bug, é muito tempo. Muito mais tempo do que ler a lista de etapas, rastreando-a por palavras-chave.
Em segundo lugar, para descobrir os mínimos detalhes, é necessário revisá-lo várias vezes, tentando parar, fazer uma pausa precisamente em momentos críticos.
Em terceiro lugar, muitas vezes em vídeos mal preparados, há muitos detalhes extras. E você não sabe o que é realmente supérfluo disso e o que não é. É necessário fechar a notificação do VKontakte para a reprodutibilidade do bug? .. Existe alguma interação com o sistema operacional que causou o bug de renderização? .. Posso usar um telegrama em vez do VKontakte? ...
(Para ser justo, aconteceu na minha prática que o autor do funcional encontrou outros erros no vídeo em anexo)
escreva bugs assim por muito tempo
Demora mais para escrever um bug com etapas, é verdade.
Frequentemente porque, anotando as etapas exatas, você involuntariamente começa a executar o trabalho de depuração.
Você está tentando dar algum passo ou é crítico.
Sim, você gasta seu tempo e salva outras pessoas.
Referências
A lista de requisitos para registrar bugs nasceu com base em mim:
se você rejeitar as especificidades do fórum-maillist-open-source, quase tudo é valioso. Incluindo o meu favorito "Descreva os sintomas do problema, não suas suposições" e "Seja explícito sobre sua pergunta";
O fim
Compartilhei essa opinião sobre a gravação de bugs com minhas equipes. Agora eu decidi alcançar um público maior.
Obrigado pela leitura.
Aqui está uma pista para a foto do gato ( tirada aqui ).
A propósito, a imagem não é minha, mas bem preparada - há uma flecha e há um aumento na área com um bug gato
UPD 28/06/2019
Programas de captura de tela dos comentários adicionados à lista geral
Erros de digitação corrigidos, causando discussão nos comentários