Guia de Ocorrências
Tipos de TESTE e de BUG no SITE
Regras Gerais
- 1. As ocorrências do Crowdtest devem ser registradas da mesma forma em que se registraria em um projeto não remunerado por falhas. Em outras palavras, é importante ter bom senso e pensar em facilitar a vida de quem irá corrigir a falha. Portanto, deve-se evitar replicar falhas variando pequenos parâmetros com a finalidade de conseguir mais aprovações. A equipe do Crowdtest vai reprovar e eventualmente vetar usuários com conduta inadequada.
- 2. A equipe do Crowdtest se reserva o direito de atualizar este guia no momento em que achar adequado, respeitando as versões utilizadas em cada projeto. Regras não serão modificadas durante a execução de um projeto.
- 3. Casos não previstos neste guia serão definidos pela equipe Crowdtest.
- 4. Todas as orientações deste guia devem ser seguidas à risca, sob pena de reprovação da ocorrência pela equipe do Crowdtest.
- 5. A classificação da ocorrência é feita pelo testador, sendo que a equipe do Crowdtest tem autonomia para alterar a classificação de acordo com seu entendimento.
- 6. A equipe do Crowdtest tem autonomia para reprovar uma falha ou melhoria.
- 7. O cliente do Crowdtest é soberano sobre as ocorrências, portanto, cabe a ele a classificação final de uma ocorrência e sua aprovação ou reprovação.
- 8. Somente serão consideradas para fins de remuneração as ocorrências registradas pelo testador no site do Crowdtest. Não serão válidas as ocorrências não registradas pelo testador no site do Crowdtest.
- 9. Somente serão consideradas válidas e, portanto, somente serão remuneradas ou pontuadas as falhas/melhorias que forem:
- • inéditas, ou seja, que ainda não tenham sido apontadas anteriormente por nenhum outro USUÁRIO do mesmo projeto ou prêmio;
- • completas, com todos os campos obrigatórios do formulário de nova ocorrência preenchidos. Os campos obrigatórios do formulário de ocorrência são:
- I. Título;
- II. Descrição;
- III. Passos para Reprodução;
- IV. Resultados Esperados;
- V. Funcionalidade;
- VI. Tipo;
- VII. Navegador (quando visível na interface);
- VIII. Dispositivo móvel (quando visível na interface);
- IX. S.O. (sistema operacional);
- X. Anexos (arquivos de evidências em vídeo ou imagem) – O campo Anexos deve conter arquivos de vídeo ou conjunto de screenshots contendo todas as ações realizadas para a reprodução da falha, desde a página inicial da aplicação testada até a ocorrência do bug.
- • reproduzíveis pelo validador da CROWDTEST.
Sobre Registro de Ocorrências e Validação
- 1. Atenção ao idioma! Erros de idioma podem levar à reprovação da ocorrência relatada. Não é permitido o uso de gírias ou abreviações.
- 2. Durante a fase de validação das ocorrências relatadas, a equipe do Crowdtest poderá solicitar informações adicionais sobre o registro. Essas informações serão enviadas ao testador através do campo “Comentários” e as mesmas deverão ser respondidas pelo mesmo campo. Caso a equipe do Crowdtest não receba retorno sobre as informações solicitadas em 48h a falha reportada será reprovada.
- 3. Instruções para o preenchimento do Formulário de Nova Ocorrência.
- 3.1. Preenchimento do Título.
- O título deve ser capaz de dar uma ideia concisa e clara da ocorrência encontrada. O título da ocorrência deve permitir que outros testadores identifiquem se a ocorrência encontrada já foi registrada (evitando, assim, ocorrências duplicadas).
- 3.2. Preenchimento da Descrição.
- A descrição deve conter uma explicação detalhada da ocorrência encontrada.
- 3.3. Preenchimento dos Passos para reprodução.
- Os passos para reprodução devem ser bem detalhados e sem ambiguidades e redundância. Não assuma que determinados passos são óbvios e serão entendidos pelo revisor. Caso existam pré-condições para a reprodução da ocorrência, as mesmas devem ser detalhadas. Este campo deve ser utilizado para convencer de que a ocorrência existe e é reproduzível.
- Coloque cada passo separado por marcadores. É mais simples de entender os passos quando estão com marcadores do que apenas texto. Ex.:
- 1. Acessar a “Tela de Cadastro de Usuários”;
- 2. Não informar os campos obrigatórios;
- 3. Clicar em [Salvar];
- É melhor que…
- “Acesse a tela de cadastro de usuário sem informar os campos obrigatórios e clique em salvar.”
- Vale ressaltar que o vídeo com a evidência do problema não substitui a descrição do passo-a-passo do problema.
- 3.4. Preenchimento dos Resultados Esperados.
- Descrição do que é esperado após a execução dos passos e uma comparação com o que é atualmente exibido pelo sistema que difere do resultado esperado.
- 3.5. Preenchimento das Informações Adicionais.
- Detalhar qualquer outra informação que achar relevante para o entendimento da ocorrência relatada.
- 3.6. Preenchimento da Funcionalidade.
- Associar a funcionalidade correspondente à ocorrência encontrada.
- Caso o testador veja a necessidade de inclusão de uma nova Funcionalidade em um projeto, deverá enviar um e-mail para crowd@crowdtest.com.br com o nome do projeto e o caminho onde a funcionalidade se encontra.
- 3.7. Preenchimento do Tipo.
- Associar o tipo da ocorrência encontrada de forma correta e que caracterize realmente o tipo da ocorrência. A seguir são descritos cada tipo de ocorrência:
- • Bug Conhecido: são falhas previamente registradas e conhecidas, que podem ou não ter sido reproduzidas pelo cliente.
- • Falhas Impeditivas: impedem o uso de alguma funcionalidade do software. Não existem saídas ou alternativas para contorná-las.
- • Falhas Funcionais: produzem um comportamento ilógico ou inesperado da aplicação onde o resultado obtido é diferente do esperado. A diferença entre uma falha funcional e uma falha impeditiva é que as falhas funcionais podem ser contornadas.
- • Falhas de Texto: qualquer ocorrência relacionada ao uso incorreto de algum idioma.
- • Falhas de Interface (GUI): são aquelas relacionadas à interface gráfica, à apresentação do software, exceto as falhas de texto. Exemplos: componentes desalinhados, renderização incorreta de interface, cores inconsistentes com guia de estilos, etc.
- • Melhorias: não são propriamente falhas, mas sim sugestões para o aprimoramento do software. As sugestões são dadas com base na experiência do USUÁRIO e nos padrões de mercado.
- • Segurança: são falhas que possibilitam acessar o sistema sem fazer uso de autenticação devida, sendo possível acessar funcionalidades, coletar dados, modificar dados, modificar o comportamento da aplicação ou interromper o funcionamento da aplicação.
- • Teste executado: também não é uma falha, mas sim a execução de passos ou fluxos contidos nas instruções do projeto, e estipulados pelo cliente.
- • Vale ressaltar que nem todos os tipos de ocorrências estarão presentes em todos os projetos. Por exemplo, pode ocorrer de em um projeto só poderem ser registradas ocorrências funcionais.
- 3.8. Preenchimento do Navegador.
- Selecionar o navegador no qual a ocorrência aconteceu. Fiquem atentos aos tipos de navegadores autorizados para testes em cada projeto.
- 3.9. Preenchimento do Dispositivo Móvel.
- Selecionar o dispositivo móvel no qual a ocorrência aconteceu. Fiquem atentos aos tipos de dispositivos móveis autorizados para testes em cada projeto.
- 3.10. Preenchimento do Sistema Operacional (S.O.).
- Selecionar o S.O. no qual a ocorrência aconteceu. Fiquem atentos aos sistemas operacionais autorizados para testes em cada projeto.
- 3.11. Preenchimento dos Anexos.
- Os anexos podem receber qualquer tipo de arquivo, mas o principal uso deles é para evidenciar a ocorrência. As evidências das ocorrências são obrigatórias para todos os tipos (Exceto quando especificado nas instruções sobre a não obrigatoriedade).
- Para evidenciar podem ser anexados screenshots ou vídeos. Utilize arquivos com os seguintes formatos: MP4, AVI, WMV, PNG, JPG e GIF.
- Podem ser utilizados serviços de hospedagem de vídeos na Internet, caso o limite de upload não seja suficiente.
- Vale ressaltar que a inclusão de anexos não elimina a necessidade de preencher os demais campos com o detalhamento esperado.
- 4. Convenções para Abertura de Ocorrências.
- 4.1. Ocorrências sobre a Indisponibilidade do Software ou Site.
- 4.1.1. Caso o site/software esteja totalmente indisponível não será considerado como uma ocorrência.
- 4.1.2. Caso o site/software estiver parcialmente disponível será considerado uma ocorrência por página.
- 4.2. Ocorrências Relacionadas a Links.
- 4.2.1. Problemas com links diferentes de uma mesma funcionalidade serão consideradas ocorrências diferentes. Exemplo: um combo box com uma lista de links e todos os links falham.
- 4.2.2. Links para sites externos (fora do escopo do projeto) que apresentarem problemas serão classificados com o tipo funcional.
- 4.2.3. Problemas com o mesmo link, mesmo que originados de componentes diferentes no mesmo software serão classificados com o tipo funcional.
- 4.3. Ocorrências Relacionadas ao Texto.
- 4.3.1. Cada erro ortográfico será considerado independentemente. Exemplo: um parágrafo com quatro erros ortográficos terá quatro ocorrências do tipo texto.
- 4.3.2. A codificação de caracteres deve ser autodetectada pelo navegador. Não pode ser especificada pelo usuário.
- • Caso ainda assim ocorram problemas de codificação, temos:
- I. Se o problema for o site inteiro, somente será considerada uma ocorrência.
- II. Se o problema variar por página, será considerada uma ocorrência por página.
- 4.3.3. Erros gramaticais devem ser embasados com uma referência que define a regra violada.
- 4.4. Ocorrências Relacionadas a Formulários.
- 4.4.1. Campos sem limite de tamanho serão considerados como ocorrências do tipo funcional.
- 4.4.2. Campos sem validação serão considerados ocorrências do tipo funcional.
- 4.4.3. Ausências de hints (dicas) nos campos de formulário serão consideradas como melhorias. Será permitida uma ocorrência de ausência de links por página ou interface do software/site alvo dos testes.
- 4.5. Ocorrências Relacionadas a Código Fonte.
- 4.5.1. Erros no código Javascript: se o erro no código Javascript gerar uma anomalia no sistema, a classificação de tipo da ocorrência deverá ser a mesma da anomalia.
- 4.5.2. Erros no código Javascript que não geram anomalia no sistema deverão ser classificados como melhorias.
- 4.5.3. Erros no código HTML: se o erro no código HTML gerar uma anomalia no sistema, a classificação de tipo da ocorrência deverá ser a mesma da anomalia.
- 4.5.4. Erros no código HTML que não geram anomalias no sistema deverão ser classificados como melhoria.
- 4.5.5. Erros no código CSS: se o erro no código CSS gerar uma anomalia no sistema, a classificação de tipo da ocorrência deverá ser a mesma da anomalia.
- 4.5.6. Erros no código CSS que não geram anomalias no sistema deverão ser classificados como melhoria.
- 4.6. Ocorrências Relacionadas à Configuração.
- 4.6.1. Ocorrências relacionadas a resoluções abaixo de 1024×768 não serão consideradas, exceto quando explicitado no projeto.
- 4.6.2. Ocorrências relacionadas a Javascript desabilitado não serão consideradas.
- 4.6.3. Ocorrências relacionadas a pop-ups desabilitadas não serão consideradas.
- 4.6.4. Ocorrências relacionadas a complementos de navegadores web (e.g. plugins Java ou Flash) desabilitados não serão consideradas.
- 4.6.5. Ocorrências relacionadas à ausência de um certificado digital válido não serão consideradas.
- 4.7. Ocorrências relacionadas a Sistemas Operacionais.
- 4.7.1. No caso de uma mesma ocorrência ser encontrada em todos os sistemas operacionais listados no projeto ou liberação, apenas a primeira ocorrência registrada será considerada, as outras serão consideradas duplicadas.
- 4.7.2. No caso de uma mesma ocorrência ser encontrada em apenas alguns dos sistemas operacionais listados no projeto ou liberação, será considerada uma ocorrência por navegador, caso sejam devidamente registradas.
- 4.8. Ocorrências relacionadas a Navegadores Web.
- 4.8.1. No caso de uma mesma ocorrência ser encontrada em todos os navegadores listados no projeto ou liberação, apenas a primeira ocorrência registrada será considerada, as outras serão consideradas duplicadas.
- 4.8.2. No caso de uma mesma ocorrência ser encontrada em apenas alguns dos navegadores listados no projeto ou liberação, será considerada uma ocorrência por navegador, caso sejam devidamente registradas.
- 4.9. Ocorrências relacionadas a Banco de Dados.
- 4.9.1. Ocorrências relacionadas a dados preenchidos incorretamente nos softwares ou sites-alvo dos testes não serão consideradas.
- • Exemplo: um produto com a descrição incorreta ou com erros de idioma em um site de comércio eletrônico.
- 4.10. Ocorrências relacionadas ao campo Data.
- 4.10.1. Conforme o contexto do sistema, a aplicabilidade do campo data poderá variar:
- • Para data de nascimento, se o sistema irá aceitar que o usuário seja cadastrado com mais de 100 anos de idade;
- • Se irá aceitar uma data que seja anterior ao dia atual;
- • Se um determinado período poderá ser aceito no passado ou no futuro;
- • O formato de preenchimento deste campo.