Tipos de bug (resumo)

O que é um bug, quais tipos de bug distinguimos e como

determinar o correto para o seu bug
Um bug é um problema relacionado ao software. Se algo em um site ou aplicativo não
funcionar conforme o esperado, esse “erro” é chamado de bug . Aqui no teste IO,
distinguimos entre os seguintes tipos de bug:
• Bugs funcionais
• Bugs de conteúdo
• Bugs visuais
• Sugestões de usabilidade

Bugs funcionais
Os bugs funcionais estão relacionados à funcionalidade de um
software, por exemplo, um botão não envia um formulário, a pesquisa
não reage à entrada do usuário, um aplicativo trava, etc. Cada vez que
você executa uma ação e o site / o aplicativo não responde conforme o
esperado, pode ser um problema funcional.
Como determinar se o comportamento do aplicativo é um bug funcional:

• Tente descobrir se um recurso foi projetado de uma maneira

particular ou se está realmente corrompido. Teste-o sozinho e
em combinação com outros recursos para detectar diferenças de
potencial.
• Pense nas intenções do cliente e considere que o produto pode
funcionar da maneira como foi implementado.
• Encontre evidências de que algo não está funcionando como
deveria e apoie sua afirmação.
• Exemplo: a funcionalidade de uma loja virtual funciona de maneira
diferente de outras lojas virtuais que você conhece. Isso não
significa que a funcionalidade está quebrada. Os clientes podem
implementar seus produtos como quiserem.
• Exemplo: se você alegar que um campo do formulário não foi
validado e que é um bug, certifique-se de que haja alguma
indicação de que o campo se destina a ser validado. Você pode
fornecer essa evidência mostrando que o campo é validado em
alguns casos, mas não em outros. Se você não fornecer
nenhuma evidência, é uma afirmação não comprovada.
• Um problema visual ou de conteúdo torna-se um problema
funcional quando atrapalha uma funcionalidade e, portanto, deve
ser relatado como um bug funcional.
• Se uma parte da funcionalidade funciona consistentemente da
mesma maneira em diferentes cenários e sem problemas óbvios,
provavelmente foi intencional (não é um bug).
Avaliação de Severidade

Qual nível de gravidade é apropriado para um bug funcional depende de

uma série de fatores: o impacto funcional do problema, a extensão do
problema, existem soluções alternativas ou é um obstáculo, existem
perdas potenciais e notáveis de vendas e você pode comparar isso bug
para outros bugs da mesma gravidade. Assim, no teste IO, distinguimos
entre três níveis de gravidade para bugs funcionais:
Baixo:
• Impacto mínimo no uso do produto.
• O produto mostra um comportamento indesejado, mas o uso geral
não é afetado.
• Poucos usuários, produtos ou itens estão preocupados.
• Um recurso / parte da funcionalidade está corrompido ou
indisponível, mas uma solução alternativa fácil resolve o
problema.
Alto:
• Impacto sério no uso do produto, mas a funcionalidade principal
está intacta.
• Um grande número de usuários, produtos ou itens está envolvido.
• Funcionalidades não triviais estão interrompidas ou indisponíveis e
não existe solução alternativa.
• Funcionalidades importantes estão interrompidas ou indisponíveis,
mas existe uma solução alternativa (portanto, não é um
obstáculo).
Crítico:
• O bug impede a funcionalidade central do aplicativo / site.
• Um impedimento evita que o usuário continue com o processo
principal, por exemplo, o processo de checkout.
• O bug causa uma perda potencial e notável de vendas para o
cliente.
Com base em avaliações comuns, preparamos uma lista de casos que
têm níveis de gravidade fixos: Leve-me à Folha de Avaliação de Bug!
Reveja a lista cuidadosamente e verifique-a regularmente para
atualizações futuras.

Bugs de conteúdo
Os bugs de conteúdo estão relacionados ao conteúdo real de sites ou
aplicativos: texto, rótulos, imagens, vídeos, ícones, links, dados, etc.
Portanto, bugs de conteúdo típicos são:
• Links ou imagens quebrados (404s) (a menos que estejam
localizados no menu de navegação, cabeçalho, rodapé ou uma
navegação breadcrumb, que são bugs pouco funcionais)
• Redirecionamentos defeituosos em geral
• Texto ausente, por exemplo, em uma dica de ferramenta vazia
 • Conteúdo ausente, por exemplo, área de conteúdo vazia
• Conteúdo ausente, por exemplo, se 4 de 5 ícones têm uma dica de
ferramenta, 1 não
• Traduções ausentes, por exemplo, algum botão em um site em
inglês com rótulos em francês
• Alguns produtos estão faltando nos resultados da pesquisa, mas a
própria função de pesquisa funciona
• Dados ausentes
Observe que erros de ortografia não são considerados bugs de conteúdo
em nossa plataforma e não podem ser enviados como tal.

Visual Bugs
Os bugs visuais estão relacionados às interfaces gráficas do usuário de
sites ou aplicativos, por exemplo:
• Problemas de estrutura de layout, como textos / elementos
desalinhados
• Um problema de design responsivo, por exemplo, um elemento é
exibido em um dispositivo móvel, mas não em outro
• Texto / elementos se sobrepõem involuntariamente
• Texto / elementos são cortados
Atualização de um conteúdo ou bug visual para um
bug funcional
Assim que um conteúdo ou um bug visual impedir uma funcionalidade,
ele deve ser relatado como um bug funcional , mesmo que não seja a
função em si que está com defeito.
Um caso importante para quando um bug de conteúdo deve ser
submetido como um bug funcional é quando ocorre em um componente
funcional do produto - nomeadamente problemas de ligação no menu de
navegação, cabeçalho, rodapé ou uma navegação breadcrumb. Esses
problemas são normalmente bugs funcionais baixos .

Problemas repetitivos
Quando um conteúdo ou problema visual ocorre repetidamente, ele só
pode ser enviado uma vez , embora cada ocorrência possa ter um URL,
link, imagem diferente, etc. Isso também é o caso se as ocorrências
estiverem na mesma página ou em páginas diferentes . Este único
relatório de bug deve indicar que outros URLs, links, imagens, etc.
também estão preocupados.
Relatórios de bug individuais para cada ocorrência do problema não
devem ser enviados e serão rejeitados. Por exemplo, apenas um
relatório deve ser enviado para os seguintes problemas de conteúdo:
Algumas fotos de produtos em várias páginas de detalhes de produtos de
uma loja online estão quebradas, alguns links para download de manuais
em PDF em várias páginas de detalhes de produtos levam a 404
páginas, algumas descrições de produtos estão em um idioma diferente
do resto da loja virtual, algumas dicas não contêm nenhuma informação,
alguns links que pertencem ao mesmo grupo estão quebrados, etc.
Os seguintes problemas visuais também devem ser enviados apenas
uma vez: alguns textos ou imagens são maiores do que suas caixas,
vários campos de entrada não são grandes o suficiente para conter seus
textos padrão que, por sua vez, não são completamente visíveis, vários
teasers se sobrepõem involuntariamente a outros elementos, etc. .
Para obter informações mais detalhadas sobre cada tipo de bug e sua
documentação na plataforma de teste IO, visite os seguintes artigos:
• Bugs funcionais
• Bugs de conteúdo
• Visual Bugs

Anexos de relatório de bug

O que você precisa anexar ao enviar um relatório de bug?

Cada bug deve ser documentado com pelo menos um anexo. Com seu
(s) anexo (s), você fornece evidências de que o bug ocorre em seu
dispositivo, sistema operacional e / ou navegador. Observação: os
anexos NÃO substituem as informações escritas em seu relatório.
Os anexos são uma visualização do problema e servem como prova.
Captura de tela ou screencast?
Em geral, a maioria dos bugs funcionais exige que um screencast seja
ilustrado de maneira adequada e eficaz. A menos que as instruções ou o
líder da equipe peça anexos específicos, use a seguinte regra prática
para determinar se uma captura de tela ou um screencast é necessário
para o bug:
• Sempre que uma ação for necessária para acionar um bug ou
quando um processo precisar ser ilustrado, carregue um
screencast. Capturas de tela como imagens estáticas são
instantâneas e não podem ilustrar a causa raiz.
• Quando a natureza de um bug é estática, por exemplo, para
problemas de GUI estática, uma captura de tela é suficiente e
uma visualização melhor do que um vídeo.
Requisitos gerais de fixação
• Novos anexos devem ser criados para cada relatório de bug ou
reprodução.
 •É proibido copiar anexos de outros relatórios de bug ou
reproduções.
• Os anexos devem mostrar todas as informações relevantes do bug
para servir como prova.
• Todas as informações relevantes devem ser exibidas em inglês (ou
alemão opcional se o idioma do relatório de bug for alemão), por
exemplo, a data, informações do sistema e mensagens de erro.
• O conteúdo do site não pode ser alterado, por exemplo, usando o
serviço Google Translator para traduzir o site para um idioma
diferente, pois isso pode levar a um comportamento inesperado.
• Não mostre nenhuma informação sobre outros clientes IO de teste
que possam estar relacionados ao IO de teste (por exemplo, e-
mails de convite ou nomes de guias do navegador). Mostrar
aplicativos instalados de outros clientes é permitido.
• Se você se referir a vários navegadores ou dispositivos, faça
upload de um anexo para cada um deles.
• Para testes de site, o campo URL deve estar visível nos anexos.
• A data atual deve estar visível nos anexos.
• A data pode estar em qualquer formato de data comum, por
exemplo, DD / MM ou MM / DD.
• A resolução deve ser alta o suficiente, para que o texto e os
elementos possam ser facilmente identificados.
• A seção gravada da tela deve ser grande o suficiente para fins de
orientação.
• O tamanho máximo do arquivo para anexos é 25 MB.
• Um log de travamento é obrigatório para relatórios de bug sobre
travamentos de aplicativos. O vídeo que documenta a falha deve
corresponder ao registro de falha anexado, ou seja, os tempos
devem ser coerentes.
Mostrando a data atual

Ao exibir a data atual em seu anexo, você prova que a gravou nessa
data. A lista a seguir sugere onde encontrar a data:
• Windows : Exibindo a barra de tarefas ou combinando no
calendário
• Mac : exibição do ícone de calendário no Dock ou na barra de
menus
• iOS e Android : deslize para baixo no centro de notificação no
início de sua gravação.
Mais informações: TecRevue
O que precisa ser incluído em uma captura de tela?
Regras específicas para captura de tela:

•A captura de tela deve estar no formato de arquivo JPG ou PNG.

• Destaque o bug em sua captura de tela.
 • Ao
provar um bug por meio de uma captura de tela em um
dispositivo móvel, uma segunda captura de tela mostrando a
data deve ser carregada (a carga da bateria e a hora devem
coincidir com a primeira captura de tela).
Recomendamos ferramentas de gravação no seguinte artigo: Ferramentas
de captura de tela
O que precisa ser incluído em um screencast?
Os screencasts devem ser os mais curtos possíveis, mas tão longos
quanto necessário. Isso significa que você deve deixar de fora as etapas
que não causam o bug. Por exemplo, quando o botão “Adicionar ao
carrinho” em uma página de detalhes do produto de uma loja virtual está
com defeito, geralmente é irrelevante como você navegou pela loja virtual
para chegar à página de detalhes do produto. A última etapa de
navegação, a etapa que aciona o bug e o próprio bug geralmente
são relevantes.
Exemplo 1: Bug no site, testado no dispositivo Desktop

Etapas para produzir um screencast :

1. Vá para a página onde ocorre o bug.
2. Comece sua gravação.
3. Recarregue a página.
4. Execute a ação que desencadeia o bug.
5. Espere até que o bug ocorra.
6. Pare a gravação.
Exemplo 2: Bug no aplicativo, testado em dispositivo móvel

Etapas para produzir o screencast:

1. Execute o aplicativo e vá para a página onde apenas mais uma
etapa de navegação é necessária para chegar à página onde
ocorre o bug.
2. Comece sua gravação.
3. Deslize para baixo no centro de notificação para mostrar a data
atual por alguns segundos.
4. Execute a última etapa de navegação para chegar à página
certa.
5. Execute a ação que desencadeia o bug.
6. Espere até que o bug ocorra.
7. Pare a gravação.
Os líderes de equipe podem enviar a você uma solicitação de
informações solicitando uma gravação externa ou adicional. Isso é feito
para obter uma melhor compreensão do bug ou em caso de dúvida
devido ao bug não ser reproduzível.
Regras específicas do screencast:

• Os screencasts devem ter o formato de arquivo MP4.

 •O tempo máximo para um screencast é de 60 segundos, a menos
que seu bug exija a exibição de um processo de carregamento
ou entradas manuais longas necessárias.
• Seus cliques / toques / toques devem ser visíveis (necessário
apenas para gravações em Android e desktop).
• Faça sua gravação de uma só vez. Não pause sua gravação no
meio.
• Não corte partes do screencast resultante no meio. Se necessário,
corte apenas o início ou o final do arquivo.
• A taxa de quadros deve ser alta o suficiente para identificar suas
ações e analisar o curso dos eventos.
• O som não deve ser gravado se não houver instruções em
contrário.
• Se você encontrar um bug em que um aplicativo ou site continua
carregando “indefinidamente” sem qualquer mensagem de erro
ou travamento, mostre a velocidade da sua internet no início e no
final do seu screencast, por exemplo, via https://fast.com/ e
mostre que você não use um proxy ou VPN no final do seu
screencast.
Recomendamos ferramentas de gravação no seguinte artigo: Ferramentas
de screencast

Screencasts
Como faço para gravar minha tela?

Criação de screencasts
Você é livre para escolher qualquer ferramenta para criar screencasts. É
importante que você forneça um vídeo .mp4 de qualidade apropriada
(resolução e apresentação).
Navegadores recentes devem ser capazes de reproduzir seu vídeo.

Seu screencast deve mostrar apenas o bug relatado +/- 10 segundos -

tente evitar screencast com mais de 1 minuto . Você deve ter os sons
desligados, a menos que seja necessário para o relatório.

Ferramentas sugeridas para desktops

Screencast-O-Matic (gratuito) >> http://screencast-o-matic.com
• Os vídeos podem ser criados como arquivos .mp4
• Até 15 minutos por vídeo
• Boa qualidade de vídeo
• Windows e Mac OS
• Atualização opcional com mais funções