A Test IO está empenhada em apoiar o crescimento dos testers. Para assegurar que sua carreira de testes siga um caminho de sucesso, decidimos compartilhar com você os erros mais comuns que nossos testers cometem nos primeiros dias de suas carreiras de teste. Mesmo testers experientes às vezes cometem erros, e é com base nesses equívocos que eles aprendem.

É bastante tentador experimentar de tudo ao realizar testes, inclusive seguir passos incomuns que um usuário normal nunca faria. Quando esse impulso ocorre, recomendamos pausar antes de enviar um relatório de bug. Reflita se seus passos correspondem ao comportamento de um usuário comum ou se o bug que você encontrou será relevante para nossos clientes. Avalie sempre se o seu bug impactará o fluxo de uso de um usuário comum.

A seguir, apresentamos alguns exemplos dos erros mais comuns que compilamos para você.
​

Frequentemente, nossos testers desejam confirmar se a Assinatura de E-mail ou o fluxo de Registro aceita e-mails inválidos. Verificar se o servidor aceita e-mails inválidos é perfeitamente aceitável e uma ação útil para nossos clientes. No entanto, antes de prosseguir com essa prática, assegure-se de compreender a diferença entre e-mails inválidos e inexistentes. Alguém poderia pensar que são a mesma coisa, mas não são. Por favor, leia este artigo para entender o que são e-mails inválidos.

Por outro lado, e-mails inexistentes representam aqueles que não foram criados por você (ou outra pessoa) e, portanto, não existem no sistema. Uma tentativa de validar um e-mail inexistente provavelmente não causará nenhuma reação do servidor, pois será considerado válido se seguir o padrão da estrutura de e-mail. Esse comportamento é esperado e não é considerado um bug.

A solução::

A validação do navegador representa a validação de entrada HTML feita pelo navegador com base nos atributos dentro do elemento de entrada.

Aqui está um exemplo de validação de e-mail do navegador em HTML 5:
​

A validação do navegador envolve a verificação de entrada HTML feita pelo navegador com base nos atributos dentro do elemento de entrada.

Um exemplo comum de validação de e-mail no navegador em HTML5 é quando você visualiza uma linha vermelha de zigue-zague sob a palavra digitada incorretamente no campo do formulário. Isso indica a presença de validação do navegador, realizada sem o uso de JavaScript.

No entanto, é importante observar que relatar bugs relacionados a essa validação não está dentro do escopo do ciclo de proba executado pela Test IO, e tais bugs serão rejeitados.

A solução:

Às vezes, nossos testers não leem minuciosamente as instruções de proba, levando à rejeição de seus bugs ou, no pior cenário, recebendo um aviso de nossa Equipe de Conformidade. Um dos erros mais comuns ocorre quando os testers não usam um proxy quando é necessário. Nossa investigação revelou o seguinte problema para os testers:

Em testes recorrentes, os testers geralmente leem as instruções de proba uma vez. Quando o próximo proba do mesmo cliente, para o mesmo produto, chega, eles presumem que a estratégia de teste deve permanecer a mesma e que ler as instruções seria uma perda de tempo precioso. Aqui é onde eles erram. O mesmo título de proba não implica que o acesso ao ambiente de proba segue o mesmo caminho.

Com frequência, nossos clientes desejam separar o tráfego causado pelos testers do tráfego dos usuários reais, e, nesses casos, usamos um proxy. Outra situação é obter acesso ao ambiente de preparação, que é bloqueado para qualquer pessoa sem a devida autorização - com o proxy habilitado. Se um tester esquece de habilitar o proxy, o ambiente de preparação emitirá erros 403 ou 1020. Relatar tais bugs resultará em rejeições por não seguir as instruções de proba.

A solução:

Às vezes, nossos testers, sem intenção, atualizam todos os bugs de Conteúdo e Visual para Funcionais devido à falta de experiência em determinar quais bugs devem ser atualizados para Funcionais. Isso resulta em rejeições, muitas vezes por motivos "Fora do Escopo", prejudicando significativamente a Qualidade e Classificação do tester.

solução:

Essa prática não é exclusiva de nossos novatos, mas também é observada em nossos testers experientes, na maioria das vezes, de forma não intencional. Nossos testers participam de vários testes ao longo da semana e, ocasionalmente, esquecem de se inscrever para testar as versões Beta do sistema operacional.

A solução:

Às vezes, os testers buscam a rapidez ao relatar bugs e, nesse ímpeto, podem escolher o dispositivo errado por engano. Caso não corrijam essa seleção para o ambiente correto antes da verificação do líder da equipe, bons bugs correm o risco de serem rejeitados.

A solução:

Durante a fase inicial de testes, os testers frequentemente recebem solicitações de informações para aprimorar seus relatórios de bug. Nesse período, a impaciência para saber o resultado do envio pode levar os testers a cair na armadilha de enviar vários comentários no Relatório de Bug ou até mensagens no chat do ciclo de proba para informar o TL sobre as mudanças realizadas. Essa situação pode parecer familiar, pois todos já estiveram lá e aprenderam com os erros. No entanto, incentivamos você a agir com mais astúcia e a aprender conosco.

A solução:

Uma das vantagens da tecnologia moderna é que você não precisa falar todos os idiomas do mundo para testar um produto em uma língua estrangeira. É permitido o uso de ferramentas de tradução de terceiros, como o Google Tradutor, durante os testes. No entanto, é crucial garantir que o bug identificado não seja causado pelo próprio Google Tradutor. Em algumas situações, a ferramenta pode modificar o ambiente, levando nossos testadores a relatar bugs que, na verdade, não existem. Em outros casos, os testadores podem identificar um bug real que não tem relação com o Google Tradutor, mas esquecem de desativar a ferramenta ao registrar a ocorrência. Quando isso acontece, o líder de teste rejeitará o bug por não seguir nossos padrões.

A solução:

Este comportamento ocorre em testes nos quais solicitamos aos nossos testadores que submetam um Bug Funcional com o título ❝PASS❞ para confirmar que o fluxo de trabalho descrito nas instruções do teste foi bem-sucedido. Não é permitido incluir reproduções em bugs com esse status, e esses envios serão rejeitados.

A solução:

Normalmente, a filtragem e a ordenação são abordadas em conjunto porque auxiliam os usuários na manipulação de grandes conjuntos de itens (produtos, filmes, ingressos, etc.); contudo, suas implementações diferem significativamente. A funcionalidade de filtragem reduz uma coleção de itens com base em critérios específicos, como tamanho, cor, marca, e similares. Por outro lado, a funcionalidade de ordenação organiza um conjunto de dados de acordo com diferentes critérios, como do menor para o maior ou do mais recente para o mais antigo.

Compreender essas diferenças é crucial, uma vez que os bugs encontrados nessas funcionalidades pertencem a tipos diferentes. Por exemplo, enquanto problemas com a funcionalidade de ordenação são considerados bugs funcionais, a maioria dos problemas relacionados à filtragem são classificados como bugs de conteúdo.

A solução:

A lista de erros mais comuns não se limita aos casos mencionados. Para obter mais informações sobre erros comuns e receber excelentes dicas, recomendamos que ouça nosso episódio de podcast:
​

​