Escrever software \u00e9 dificil. Manter um software atualizado e em funcionamento
\nsem defeitos, \u00e9 ainda mais dificil.<\/p>\n
Uma das ferramentas mais importantes para que isso ocorra, isto \u00e9, a cria\u00e7\u00e3o Eles podem ser criados por qualquer pessoa que use de fato o software, qualquer N\u00e3o importando quem escreveu, todo e qualquer bug merece um relat\u00f3rio e uma A conta \u00e9 simples: se o bug tivesse sido encontrado durante a etapa de desenvolvimento, o desenvolvedor gastaria 2 horas para resolv\u00ea-lo e adicionar Se o bug \u00e9 encontrado em produ\u00e7\u00e3o, ser\u00e3o gastos, aproximadamente, 20 horas para Certo, bugs s\u00e3o caros, mas e da\u00ed? Bem, se podemos resolver o bug em desenvolvimento Maus relat\u00f3rios de bugs deixar\u00e3o os desenvolvedores e<\/strong> usu\u00e1rios irritados. Bugs Uma m\u00e1xima importante \u00e9:<\/p>\n \n Um bom relat\u00f3rio de bug descreve o problema de forma que o desenvolvedor familiarizado com o projeto pode entender e resolv\u00ea-lo, sem falar com a pessoa que o escreveu<\/strong>.\n<\/p><\/blockquote>\n Esta \u00e9 uma tradu\u00e7\u00e3o generalizada de uma [postagem do martiancraft][martincraft-bug-report]. Realmente, devo concordar com o t\u00edtulo.<\/p>\n Pequena est\u00f3ria: uma certa vez, trabalhando com um cliente – sem expertise t\u00e9cnica, decidiu que gostaria de escrever seus pr\u00f3prios relat\u00f3rios de bugs. \u00d3timo, pensei, uma coisa a menos que terei de fazer. Este cliente nunca havia utilizado ou mesmo visto um relat\u00f3rio de bug.<\/p>\n Quando ele come\u00e7ou a escrev\u00ea-los, ele colocava t\u00edtulos estranhos, descri\u00e7\u00f5es que n\u00e3o mencionavam como reproduzir o mesmo e tentava explicar problemas de desenho da tela, utilizando palavras – sem um simples screenshot<\/em> se quer. Tudo bem, pensei, ele apenas precisa aprender a escrever melhores relat\u00f3rios de erros e nossa vida ser\u00e1 muito mais f\u00e1cil. Enviei alguns links para ele e a situa\u00e7\u00e3o melhorou.<\/p>\n Os bugs eram corrigidos mais rapidamente, pois gast\u00e1vamos menos tempo tentando entender o que ele quis dizer com aquilo. Facilitou a comunica\u00e7\u00e3o sobre outras funcionalidades que ele queria para seu produto. Entre diversas outras coisas.<\/p>\n Ent\u00e3o, confiem em mim: um bom<\/strong> relat\u00f3rio de erros \u00e9 essencial para a vida do desenvolvedor e do maior interessado, o cliente<\/strong>.<\/p>\n Ent\u00e3o, o que todo bom relat\u00f3rio de bugs deve conter?<\/p>\n Apenas um problema por relat\u00f3rio de defeito<\/strong>. Apenas. Um. Problema. Por. Relat\u00f3rio.<\/p>\n N\u00e3o existe forma de deixar isto mais claro. Quando voc\u00ea tem um ou mais defeitos em um mesmo relat\u00f3rio de bugs, isto confunde o desenvolvedor, dificulta a corre\u00e7\u00e3o e dificulta principalmente o teste da corre\u00e7\u00e3o.<\/p>\n Outra: os dois problemas andam juntos, s\u00e3o corrigidos juntos e aprovados juntos. Em uma equipe, estes problemas poderiam ter sido resolvidos em paralelo, fechados com timelines<\/em> distintas (um bug era f\u00e1cil, o outro dif\u00edcil) e com maior qualidade.<\/p>\n Nunca reporte mais de um bug em um \u00fanico relat\u00f3rio. Nunca<\/strong>. Mesmo se eles forem relacionados. Cada bug \u00e9 importante o suficiente para merecer seu pr\u00f3prio relat\u00f3rio.<\/p>\n Um bom t\u00edtulo<\/strong> \u00e9 essencial para avalia\u00e7\u00e3o r\u00e1pida do problema. T\u00edtulos que n\u00e3o esclarem a situa\u00e7\u00e3o, ou mascaram o problema real, s\u00e3o as formas erradas de come\u00e7ar a escrever um relat\u00f3rio de erros.<\/p>\n Um bom t\u00edtulo ajuda o desenvolvedor a realizar a triagem do bug, algo como: “ah \u00e9 s\u00f3 um texto na tela”, “faltou uma valida\u00e7\u00e3o aqui e ali” e “rapaz…tenho menor ideia do que diabos \u00e9 isso”. N\u00e3o s\u00f3 ajuda a identificar a criticidade do bug, mas tamb\u00e9m mais ou menos de onde vem o problema, facilitando a delega\u00e7\u00e3o da resolu\u00e7\u00e3o para um ou outro desenvolvedor ou time.<\/p>\n J\u00e1 as descri\u00e7\u00f5es s\u00e3o os lugares para se dar detalhes sobre o bug. Contexto, informa\u00e7\u00f5es do ambiente, passos para reprodu\u00e7\u00e3o do bug, dados para reprodu\u00e7\u00e3o do bug<\/strong>, temperatura do ar, press\u00e3o atmosf\u00e9rica e humor do chefe no dia.<\/p>\n Sem essas informa\u00e7\u00f5es cruciais, fica muito mais dif\u00edcil reproduzir o bug, tornando o mais caro para a empresa e para o cliente.<\/p>\n Exemplos:<\/p>\n RUIM<\/strong>: “Texto fora do padr\u00e3o”;<\/p>\n<\/li>\n BOM<\/strong>: “Texto do t\u00edtulo ‘Pesquisa’ est\u00e1 desformatado”;<\/p>\n<\/li>\n RUIM<\/strong>: “N\u00e3o consigo salvar imagens”;<\/p>\n<\/li>\n Acho que deu para entender.<\/p>\n Certo, temos nossos bugs, mas como recriar a situa\u00e7\u00e3o? A primeira coisa que um desenvolvedor far\u00e1, \u00e9 tentar recriar a situa\u00e7\u00e3o para ver se o erro encontrado n\u00e3o \u00e9 espor\u00e1dico, se tem rela\u00e7\u00e3o com as mar\u00e9s ou a lua, ou se \u00e9 realmente um defeito encontrado consistentemente.<\/p>\n Defeitos espor\u00e1dicos, como, “relat\u00f3rio n\u00e3o pode ser gerado durante os meses que possuem 31 dias” existem e s\u00e3o leg\u00edtimos, mas o desenvolvedor primeiro ir\u00e1 procurar se ele n\u00e3o vem de uma m\u00e1 configura\u00e7\u00e3o ou algum passo errado que o usu\u00e1rio possa ter executado no momento de usar a aplica\u00e7\u00e3o. Vamos dizer que um erro \u00e9 encontrado em apenas 1\/10 das vezes em que se executam uma tarefa, aleatoriamente. O desenvolvedor testou 9 vezes, mas o erro n\u00e3o se apresentou. O que ele ir\u00e1 pensar? Que n\u00e3o existe erro algum e talvez o usu\u00e1rio estivesse em uma vers\u00e3o antiga, ou o conjunto de dados mudou.<\/p>\n Mesmo que o respons\u00e1vel por reportar o defeito n\u00e3o saiba exatamente<\/strong> quais a\u00e7\u00f5es foram realizadas, em detalhes, para incluir no relat\u00f3rio, um conjunto m\u00ednimo de passos ajuda muito.<\/p>\n Exemplo:<\/p>\n A diferen\u00e7a entre os dois \u00e9 gritante.<\/p>\n Quanto ao comportamento esperado, ele tamb\u00e9m \u00e9 fundamental para quem for testar o bug e confirmar que o mesmo est\u00e1 resolvido. Al\u00e9m dos passos de testes, o comportamento esperado \u00e9 o prego no caix\u00e3o do defunto – ele trat\u00e1 a certeza para o desenvolvedor de que o problema morreu.<\/p>\n Informa\u00e7\u00f5es de contexto s\u00e3o cada vez mais importantes, conforme os mesmos s\u00e3o distribu\u00eddos por uma gama muito maior de clientes – a web, por exemplo.<\/p>\n Um bom contexto cont\u00e9m:<\/p>\n Em casos extremos, como aplica\u00e7\u00f5es gr\u00e1ficas ou desktops, qual placa de v\u00eddeo, qual resolu\u00e7\u00e3o utilizada, etc. Quanto maior o n\u00famero de detalhes, mais f\u00e1cil.<\/p>\n N\u00e3o confunda prioridade com criticidade. Prioridade \u00e9 o quanto um bug impacta no dia a dia do usu\u00e1rio. Um bug cr\u00edtico em uma funcionalidade usada apenas uma vez no ano, \u00e9 muito importante, mas um bug de severidade m\u00e9dia em uma ferramenta utilizada todos os dias<\/strong> tem prioridade muito maior de resolu\u00e7\u00e3o.<\/p>\n Ah, os screenshots. Eles s\u00e3o muito \u00fateis para provar que o usu\u00e1rio n\u00e3o est\u00e1 ~~louco~~ sonhando. Brincadeiras \u00e0 parte, os screenshots colocam o desenvolvedor numa m\u00e1quina do tempo e na m\u00e1quina do usu\u00e1rio. Principalmente<\/strong> se o bug envolver qualquer tipo de tela ou interface de usu\u00e1rio.<\/p>\n N\u00e3o \u00e9 t\u00e3o dif\u00edcil, ent\u00e3o, sempre que poss\u00edvel, tire um screenshot, desenhe em cima dele, aponte uma seta para o problema. O desenvolvedor ser\u00e1 muito grato.<\/p>\n Existe ciclo de vida natural de um bug, que varia de empresa para empresa, mas o mais simples geralmente acontece assim:<\/p>\n Este \u00e9 o fluxo m\u00ednimo que temos de trabalho. Quando o bug resolvido chegar na “mesa” do relator, ele deve separar um tempo para fazer o teste da resolu\u00e7\u00e3o, o quanto antes melhor e dar andamento nos processos.<\/p>\n Se outro<\/strong> defeito foi encontrado, crie outro bug. A maior parte das ferramentas atuais permitem que voc\u00ea referencie bugs e\/ou tarefas, facilitando o desenvolvedor a acompanhar o hist\u00f3rico.<\/p>\n Escrever relat\u00f3rios de erros n\u00e3o \u00e9 dif\u00edcil. \u00c9 um processo em que se colabora com a constru\u00e7\u00e3o do software, ent\u00e3o deve ser minimamente organizado e coerente. Desenvolvedores n\u00e3o tem bolas de cristal e n\u00e3o s\u00e3o hackers do tipo Matrix, onde vem tudo em c\u00f3digo o tempo todo.<\/p>\n Um bom relat\u00f3rio de bugs \u00e9 certamente apreciado e muito mais legal de ser resolvido do que um mau relat\u00f3rio. Seja bonzinho e nos ajude a te ajudar :D.<\/p>\n Escrever software \u00e9 dificil. Manter um software atualizado e em funcionamento sem defeitos, \u00e9 ainda mais dificil. Uma das ferramentas mais importantes para que isso ocorra, isto \u00e9, a cria\u00e7\u00e3o e manuten\u00e7\u00e3o de um bom software, com o m\u00ednimo de defeitos (nenhum software \u00e9 perfeito), \u00e9 sem d\u00favida, os relat\u00f3rios de defeitos, ou bug reports. … <\/p>\n
\ne manuten\u00e7\u00e3o de um bom software, com o m\u00ednimo de defeitos (nenhum software \u00e9 perfeito), \u00e9 sem d\u00favida, os relat\u00f3rios de
\ndefeitos, ou bug reports<\/em>.<\/p>\n
\nque ele seja. Alguns relat\u00f3rios de bugs (chamaremos apenas de bugs, daqui por)
\ndiante ser\u00e3o escritos por desenvolvedores, que notar\u00e3o comportamentos estranhos
\nainda na etapa de desenvolvimento. Outros ser\u00e3o escritos por testadores profissionais,
\nque ganham o p\u00e3o procurando a desgra\u00e7a alheia. E outros bugs, ser\u00e3o encontrados
\napenas quando o nosso software estiver em produ\u00e7\u00e3o – pelo usu\u00e1rio final.<\/p>\n
\ninvestiga\u00e7\u00e3o formal. O quanto antes, melhor. Bugs tendem a ficar cada vez mais
\ncaros, conforme o tempo passa. Estima-se que um bug descoberto em produ\u00e7\u00e3o custa 10 vezes mais o valor do que se ele tivesse sido encontrado antes – durante o desenvolvimento.<\/p>\n
\num teste de unidade, afim de garantir que o mesmo n\u00e3o retorne para assombrar ningu\u00e9m,
\nanos depois.<\/p>\n
\nresolv\u00ea-lo. Sen\u00e3o mais. Tudo em produ\u00e7\u00e3o \u00e9 mais dif\u00edcil.<\/p>\n
\ne uma das principais formas de se resolver um bug \u00e9 criando um bug report<\/em>,
\nbons relat\u00f3rios de bugs facilitam a vida dos desenvolvedores, na hora de encontrar
\no danado e resolv\u00ea-lo de uma vez por todas.<\/p>\n
\ncom t\u00edtulos e descri\u00e7\u00f5es inadequadas ser\u00e3o muito mais dif\u00edceis de serem resolvidos,
\npois s\u00e3o mais dif\u00edceis de serem encontrados, terem o comportamento exato reproduzido,
\nassim por diante.<\/p>\nApenas um problema por relat\u00f3rio<\/h2>\n
T\u00edtulo e Descri\u00e7\u00e3o<\/h2>\n
\n
Passos detalhados e comportamento esperado<\/h2>\n
\nDefeitos consistentes s\u00e3o rapidamente avaliados pois temos certeza de quais passos realizar para reproduzir o erro. Sem os passos, o desenvolvedor dever\u00e1 contar com a sorte para reproduzir o danado – tarefa tediosa e que pode n\u00e3o resolver o problema.<\/p>\n\n
\n
Contexto<\/h2>\n
\n
Prioridade<\/h2>\n
Screenshots<\/h2>\n
Quando fechar um bug<\/h2>\n
\n
Pensamentos finais<\/h2>\n
Links interessantes<\/h2>\n
\n