Bug encontrado, bug reportado! (Parte II)

Continuando o post anterior...

Mais alguns conceitos interessantes sobre o registro de bugs que eu aprendi lendo o livro "Lessons Learned in Software Testing":

- Never exaggerate your bugs:

De acordo com o projeto e o tipo de sistema, é necessário ter um critério para definir o que seria um bug crítico ou não. Um erro não poderá ser categorizado como crítico sem ter fatos que comprovem essa escolha. Por exemplo, em um site de ecommerce, um erro durante a etapa de compra de produtos com certeza é crítico, principalmente porque acarreta prejuízo para a empresa. Mas tente ser coerente, e não classificar qualquer bug como crítico, apenas para ser corrigido urgentemente.

- Bug reports should be closed by testers:

Todo bug corrigido deverá ser testado novamente, a fim de indentificar se a correção foi realmente concluída. Caso o bug reportado não ocorra mais, este poderá ser fechado definitivamente pelo testador. Quanto antes for possível testar a correção, melhor será para o programador, que lembrará mais facilmente do código alterado, caso o bug não tenha sido realmente corrigido.

- Never use the bug-tracking system to monitor testers performance:

Não é possível medir a eficiência de um tester se baseando apenas na quantidade de bugs reportados. Quantidade não significa qualidade.

- Keep clear the difference between severity and priority:

A gravidade (severity) é referente ao impacto que o erro causa no sistema. A prioridade indica com que urgência o erro deverá ser corrigido. Geralmente quanto maior a gravidade do problema, maior a sua prioridade para correção.

Clicando nesse link você poderá ler sugestões de como reportar um bug na perspectiva de um desenvolvedor.

A comunidade TestExpert listou vários links sobre teste e qualidade de software. Para conferir basta clicar aqui.

Bug encontrado, bug reportado! (Parte I)

Saudações caçadores de bugs!

Tão importante quanto encontrar o bug, é reportá-lo de maneira direta e objetiva, para que outras pessoas envolvidas no projeto possam ler, entender e acompanhar.

Lendo o livro "Lessons Learned in Software Testing" dos escritores Cem Kaner, James Bach e Bret Pettichord, eu aprendi algumas lições sobre o conceito de reporte de bugs. Em breve, em outro post, pretendo comentar mais especificamente sobre o livro.

Abaixo, seguem as lições que eu considerei mais interessantes:

- You are what you write: 

Reportar um erro é bem mais que apenas descrever o que aconteceu. 

Por exemplo, se você simplesmente escrever: "Não é possível cadastrar  o produto.", haverá vários programadores furiosos questionando: esse bug acontece em qual ambiente, em quais circustâncias? É necessário algum pré-requisito para reproduzir?

Portanto, é importante informar a prioridade de correção, o ambiente em que foi encontrado, a sequência de ações necessárias, um resultado esperado, imagens, enfim, dados relevantes para os desenvolvedores e os outros envolvidos no projeto. Quanto melhor o conjunto de informações, mais fácil será para o programador identificar o mesmo erro e corrigi-lo posteriormente.   

Lembrando que clientes e diretores também poderão ler os bugs reportados. Então "The better your reports, the better your reputation."

- Make you bug report an effective sales tool: 

Uma maneira implícita de convencer o seu amigo desenvolvedor, que é realmente necessário corrigir um determinado bug, é adicionar o benefício que a correção resultaria, ou o custo que gera para a empresa caso não seja corrigido.  É claro que deve ser utilizado o bom senso, e não exigir que bugs com prioridades baixas sejam corrigidos imediatamente.

Por experiência própria, eu já negociei vários bugs. Felizmente, na empresa onde eu trabalho, a relação entre testers e desenvolvedores é muito amigável. Sempre conversamos sobre a importância da correção, e entramos em um acordo dependendo da necessidade e da urgência na entrega dos sistemas.

Ou seja, quando todos estão realmente envolvidos no projeto, há apenas um objetivo em comum: entregar o sistema da melhor maneira possível dentro do prazo estipulado.

- Report defects promptly:

Assim que o bug for identificado, é necessário registrá-lo. Se demorar muito para reportar, a chance de esquecer dados importantes aumenta e o erro levará mais tempo para ser corrigido.

- Always report nonreproducible erros; they may be time bombs: 

Você encontrou um bug, mas não consegue reproduzir? Não deixe de reportar o erro mesmo assim. Antes de fechar a tela com o erro, providencie imagens da cena do crime, para comprovar posteriormente que a falha realmente acontece.

- Every bug deserves its own report:

Mesmo que em uma única tela existam vários erros, cada erro deverá ser reportado separadamente, com suas respectivas informações.

- The summary line is the most important line in the bug report:

O título da descrição do bug deverá ser objetivo, direto. Deve ser uma breve descrição do erro, de maneira que apenas lendo o título já seja possível entender em qual parte do sistema acontece e o que acontece. Pense em um título que, em apenas algumas palavras, você consiga transmitir o erro e os stakeholders consigam entender, sem ter que visualizar mais detalhes. Também poderá ser adicionado o impacto ou a consequência do bug.

Existem outras considerações tão importantes quanto essas. Continua no próximo post! 

Curiosidade: Mensagens de Erros Bizarras

Enquanto isso no grupo "Testers Anônimos"...

Em uma sala obscura, testers, bug detectors, caçadores de bugs estão reunidos:

Timidamente, o primeiro tester se apresenta:

-"Olá, meu nome é Alexandre, e reportei 10 bugs em uma hora!

E então na sala ecoa aplausos e vários parabéns de pessoas orgulhosas da atitude do Alexandre!

Todos olham para o próximo tester a se apresentar:

- "Boa noite a todos! Meu nome é Maira, e… e… vai ser muito difícil o que eu vou dizer agora, mas tenho que ser forte e admitir: eu estou há 1 semana sem reportar bugs."

O silêncio reina na sala e todos ficam espantados pois é muito tempo sem identificar erros. O que será que está acontecendo? Será que a Maira deixou de ser eficiente, não está se dedicando tanto quanto deveria, ou simplesmente está acompanhando blogs como o naointendo.com.br durante o expediente de trabalho?

Vamos desconsiderar esses fatores, e considerar outros baseados em dados e relatórios mais concretos:

Desde o mês de janeiro eu gero relatórios contendo informações sobre a quantidade de bugs reportados e a quantidade de versões lançadas em cada produto desenvolvido. No início do ano, que foi o período em que mais houve lançamento de  sistemas, a quantidade de erros identificados era muito grande, e com o passar dos meses foi diminuindo gradativamente. Essa informação indica que o software está em um nível mais estabilizado. Outro dado que pode resultar nessa conclusão, é referente à quantidade de versões lançadas, que também diminui consideravelmente. No gráfico abaixo, a representação fica mais visível:

Então você, que tem experiência em identificar erros, mas que está há mais de uma semana sem reportar bugs, não fique desesperado. Considere se a qualidade do produto realmente melhorou, se o sistema atende aos requisitos e se os usuários estão satisfeitos. Será o resultado do esforço que foi aplicado principalmente nas primeiras versões do sistema.

E o interessante de manter essas informações em relatórios, é que posteriormente você poderá gerar um gráfico comparando a evolução durante os meses, e após enviar aos stakeholders.

Nota de esclarecimento: Eu não fico acessando blogs engraçados durante o expediente de trabalho.

Usabilidade e a Máquina do Tempo

Imagine que você tenha a máquina do tempo DeLorean, do filme "De Volta para o Futuro", mas ainda não sabe como programá-la para viajar no tempo. Então você acessa o Google e pesquisa o seguinte: "como voltar no tempo com DeLorean".

Clique em "Eu estou com sorte" e de maneira prática e rápida você encontra um tutorial explicando o procedimento necessário. Depois de muita preparação e estudo você programa a máquina do tempo para voltar para o ano de 1998. E então, você revê o jogo em que o Brasil perdeu para a França na Copa do Mundo, e se arrepende profundamente de ter escolhido esse ano. Desesperado, você tenta voltar para o futuro, mas infelizmente, o tutorial foi esquecido, obrigando a realizar a pesquisa novamente. Você abre seu navegador Opera (Firefox surgiu apenas em 2004, e Internet Explorer está fora de cogitação), digita o endereço do Google, e o navegador exibe a seguinte tela:

Independentemente do ano, o Google é um exemplo de simplicidade e usabilidade. É claro que fazer pesquisa é muito fácil, mas todos os aplicativos e sistemas, como o Chrome, Google Earth, Gmail, possuem a mesma lógica de funcionamento, um mesmo padrão de interação entre usuário e interface, focando principalmente em proporcionar facilidade para qualquer tipo de usuário. Sim, eu tenho uma paixão platônica pelo Google.

Ainda viajando no tempo, em 2000, ao acessar o site do Submarino você veria essa imagem (clique na imagem para ampliar):

E comparando com a o site atual do Submarino, é possível claramente perceber alterações na questão de usabilidade, principalmente porque o site é uma substituição do vendedor.

Na versão atual é possível perceber que:

- O campo de "Busca" ganhou muito mais destaque;

- O botão "Meu Carrinho" é de rápido e fácil acesso;

- Promoções e informações interessantes aos consumidores também ganham destaque na tela inicial;

- Central de atendimento ao cliente por telefone está no topo do site, agregando valor ao fator "Atendimento eficiente ao cliente";

- O menu ficou subdivido e não ocupa tanto espaço;

- O site exibe os últimos produtos visualizados (mesmo se você não estiver autenticado no site);

Enfim, é uma série de fatores que sem perceber, facilitam a aceitação do usuário. Entretanto, eu ainda acho que contém muita informação (mas é só a minha opnião).

O que nós podemos constatar é que a preocupação em facilitar o convívio do usuário com o sistema é um ponto determinante para que ele continue acessando seu site. E o usuário busca facilidade!

Para quem quiser brincar de voltar no tempo, visualizando os sites desde sua criação e suas alterações ao longo dos anos, poderá acessar o site http://web.archive.org/.

E só por curiosidade, durante a pesquisa de alguns dados, eu descobri que o site mais antigo do mundo é esse: http://symbolics.com/, criado em 1985.