Skip to content
Tipos de TESTE e de BUG no SITE
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:
III. Passos para Reprodução;
IV. Resultados Esperados;
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;
“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.
Belo Horizonte, 01 de Dezembro de 2018
