Todas as coleções
Começando
Test IO vs Outras Plataformas de Teste
Comparação entre as Plataformas uTest e Test IO para Testers
Comparação entre as Plataformas uTest e Test IO para Testers

Entenda rapidamente as diferenças entre as plataformas uTest e Test IO.

Nikola Jonic avatar
Escrito por Nikola Jonic
Atualizado há mais de uma semana

Apresentação

A testagem de software desempenha um papel vital na garantia da qualidade e confiabilidade dos produtos de software. Plataformas de teste baseadas na multidão, como uTest e Test IO, permitem que testers freelancers contribuam com suas habilidades para diversos projetos de teste.

Este artigo compara as diferenças entre as plataformas uTest e Test IO, focando especificamente nos processos de teste, tipos de bugs, gravidade de bugs funcionais, anexos, pagamentos e comunicação de teste.

Aspecto

uTest

Test IO

Processos de Teste

A uTest segue um processo de teste estruturado, que normalmente inclui a integração ao projeto, a execução de casos de teste, o relato de bugs e o encerramento do ciclo de teste. Os testers recebem casos de teste específicos e os executam dentro do ambiente designado. Após a execução, eles enviam relatórios detalhados de bugs para a plataforma.

Se um relatório de bug for rejeitado, isso afeta negativamente a pontuação do tester, dependendo do tipo de rejeição recebida.

Os testers têm a possibilidade de contestar bugs rejeitados pelos clientes.

Placeholders são proibidos.

Os testers podem usar qualquer dispositivo registrado, desde que atenda aos requisitos do ciclo de teste.

O Engenheiro de Testes seleciona os testers para participar de um teste.

O Test IO adota um processo ágil de teste que envolve planejamento, execução e feedback contínuo. Os testers participam de ciclos de teste que correspondem ao seu idioma, dispositivos e localização. Enfatizamos testes exploratórios em tempo real e manuais, permitindo que os testers descubram e relatem bugs no momento.

Para começar a contribuir para um ciclo de teste, os testers precisam iniciar sessões de teste com antecedência e confirmar que leram e compreenderam as instruções das funcionalidades em escopo.

Ao enviar um bug, para identificar duplicatas, a lista de ❝Bugs Semelhantes❞ no lado direito do formulário de bug mostrará os bugs já enviados no teste atual. Além disso, você pode procurar e filtrar os bugs na lista de Bugs Conhecidos para realizar essa verificação.

Se um relatório de bug for rejeitado, isso afeta negativamente a pontuação do tester com base no tipo de rejeição recebida.

Os testers têm a opção de contestar bugs rejeitados pelos Líderes de Equipe. Uma vez que um relatório é contestado, ele fica bloqueado para revisão pela Equipe de Disputa de Bugs.

Relatórios de espaço reservado são altamente proibidos.

Com base nos dispositivos registrados no Perfil do Tester e outras informações, o sistema seleciona um dos dispositivos e o convida a participar do teste. Dependendo dos assentos disponíveis para cada ciclo, pode ser que você não consiga escolher um dispositivo diferente daquele selecionado pelo sistema. Não é possível mudar para outro dispositivo após receber o convite para um específico. Portanto, você só pode enviar bugs encontrados nesse dispositivo.

Formulário de Bug

O formulário de bug da uTest é estruturado da seguinte forma:

  1. Tipo de Problema

  2. Frequência

  3. Prioridade

  4. Fonte

  5. Ambiente

  6. Ações Realizadas

  7. Resultados Esperados

  8. Resultados Reais

  9. Mensagens de Erro

  10. Informações Adicionais do Ambiente

  11. Anexo.

Por outro lado, o formulário de bug do Test IO simplifica a documentação do tester com a seguinte estrutura:

  1. Título do Bug

  2. Tipo de bug com severidade para bugs funcionais

  3. Campo de URL (onde o bug ocorre)

  4. Passos (ações realizadas)

  5. Resultado real

  6. Resultado esperado

  7. Anexos

Você não precisa seguir um formato específico para construir um título. No entanto, é necessário que responda ao que aconteceu, onde o bug ocorreu e quando foi acionado.

Em nosso formulário de bug, não é necessário adicionar o número da etapa; nosso formulário já o fornece. Você pode arrastá-los e rearranjá-los conforme desejar.

Exceto para o navegador durante o teste de site, as informações do dispositivo são obtidas do dispositivo selecionado ao aceitar participar de um ciclo de teste, o que não pode ser alterado posteriormente.

Tipos de Bugs

A uTest classifica bugs em categorias como:

  • Funcionalidade

  • Usabilidade

  • Segurança

  • Desempenho

  • Problemas de Localização.

Os testers são obrigados a identificar e relatar esses bugs com precisão.

O Test IO categoriza bugs da seguinte forma:

  • Funcionais

  • Visuais

  • Conteúdo

  • Usabilidade

  • Bugs de Caso de Teste.

Não realizamos testes de segurança.

Aqui estão mais especificações. Bugs de conteúdo estão relacionados a todos os tipos de informações, não apenas texto (por exemplo, traduções; erros de digitação não são relatados). Portanto, imagens e botões ausentes são considerados bugs de conteúdo em vez de bugs visuais.

Bugs funcionais, como carregamento infinito, podem ser considerados bugs funcionais se afetarem diretamente os usuários finais, por exemplo, ao acessar conteúdo ou progredir em uma tarefa.

Por outro lado, durante ciclos de teste de desempenho, que são executados conforme a demanda, o carregamento infinito é tratado como um problema de desempenho e relatado como tal. Portanto, medir a velocidade da Internet e os arquivos .har faz parte dos anexos necessários para incluir no relatório.

A Gravidade dos Bugs Funcionais

A gravidade dos Bugs no uTest é classificada como:

  • Crítico

  • Alto

  • Médio

  • Baixo

Você decide qual gravidade se aplica melhor ao problema.

Na Test IO, oferecemos cenários específicos para orientá-lo na seleção correta da gravidade; são apenas três:

  • Baixo

  • Alto

  • Crítico

Os cenários que fornecemos ajudarão a analisar o problema de maneiras diferentes, considerando a funcionalidade comprometida e o impacto potencial do bug nos usuários finais. Por exemplo, bugs que param totalmente o sistema são considerados críticos, enquanto se houver uma solução fácil e intuitiva, como recarregar a página, a gravidade correta será baixa.

Anexos no Relatório de Bug

A uTest permite que os testers anexem arquivos relevantes, como capturas de tela, gravações de tela e arquivos de log, aos seus relatórios de bugs.

Capturas de tela devem seguir as seguintes diretrizes:

  • Destaque

  • Formato JPG ou PNG.

  • Não utilize ferramentas de desenho à mão

  • Capture a tela completa

  • Feche guias desnecessárias

  • Orientação vertical.

Gravações de tela devem atender aos seguintes critérios:

  • Sem ruído

  • Tela inteira

  • Deve corresponder às ações realizadas

  • Somente formato mp4

  • Mantenha curto

Os testers do Test IO podem incluir anexos, como capturas de tela, gravações de tela e logs de travamento.

Capturas de tela:

  • Destaque

  • Formato JPG ou PNG.

  • Recomendamos não usar desenhos à mão, mas sim formas como quadrados, retângulos e setas.

  • Capture a tela completa.

  • As guias ou aplicativos desnecessários não devem ser visíveis, e mais importante, as informações dos clientes do Test IO não devem ser visíveis (por exemplo, notificações com ID de ciclo de teste e nome do cliente).

  • A orientação mostrada na captura de tela deve ser a mesma do usuário durante o teste.

Gravação de tela deve atender aos seguintes critérios:

  • Sem ruído

  • Tela inteira

  • O comprimento para relatórios de bugs é de 60 segundos, enquanto para Histórias do Usuário e reproduções é de 15 segundos.

  • As etapas gravadas devem incluir apenas a última etapa de navegação, a ação que aciona o bug e o próprio bug.

  • Apenas formato mp4

  • Toques/cliques devem ser visíveis em desktops e dispositivos Android.

Para testes de desempenho, são necessários arquivos .har.

Comunicação de Teste

A uTest promove a comunicação entre testers, gerentes de projeto e desenvolvedores por meio de um sistema de mensagens dedicado. Os testers podem buscar esclarecimentos sobre requisitos e interagir com as partes interessadas ao longo do ciclo de teste.

O Test IO enfatiza a comunicação em tempo real, permitindo que os testers colaborem e discutam problemas por meio do chat de teste, comentários nos relatórios de bugs, servidor Discord e plataformas de e-mail entre testers, líderes de equipe (TL), Gerentes de Sucesso do Cliente (CSMs) e clientes. Os testers podem fazer perguntas, buscar esclarecimentos e receber feedback instantâneo dos mencionados interessados, pois podem solicitar informações sobre as tarefas dos testers.

Pagamento por Bug

Na uTest, o pagamento depende do valor atribuído ao bug:

  • Um Pouco Valioso (Não será Corrigido)

  • Um Pouco Valioso

  • Muito Valioso

  • Excepcionalmente Valioso

O pagamento do Test IO depende do tipo de tarefa realizada. Existem tarefas diretamente relacionadas aos Ciclos de Teste. Em contraste, outras, como Reproduções, Confirmação de Correção de Bug e Confirmação de Relatório de Bug, podem ser realizadas sem participar do ciclo de teste ao qual o relatório pertence.

No entanto, dentro de um ciclo de teste, o pagamento varia de acordo com o tipo e a gravidade do bug, bem como as especificações do dispositivo.

Tarefas Pagas e Bônus

Na uTest, os testers podem realizar:

  • Casos de Teste

  • Relato de Bugs

  • Pesquisas de Usabilidade

No Test IO, os testers freelancers podem realizar essas tarefas pagas e receber os seguintes bônus:

  • Relato de Bugs

  • Reprodução de Bugs

  • Histórias do Usuário

  • Casos de Teste

  • Confirmação de Correção de Bug

  • Confirmação de Relatório de Bug

  • Bônus de Participação em Projetos Especiais

  • Sessões de Atividade Pagas

  • Relatórios de Compra

  • Feedback de Teste (pago em alguns casos raros)

  • Bônus de Gostar de Bug

Em vez de esperar que o cliente aceite ou rejeite seu trabalho no Test IO, você é pago assim que o Líder da Equipe aceita seu bug ou execução.

"Em resumo, tanto uTest quanto Test IO proporcionam experiências únicas para os testers, abrangendo processos de teste, tipos de bugs, avaliação de gravidade, anexos e comunicação durante o teste.

Existem várias diferenças notáveis entre uTest e Test IO. A uTest adota um processo estruturado com casos de teste atribuídos, onde os testers enviam relatórios de bugs usando um formulário específico. Contestar bugs rejeitados é permitido, mas essa ação impacta suas pontuações. Por outro lado, o Test IO prioriza testes exploratórios em tempo real, envolvendo os testers em feedback contínuo e colaboração ao longo dos ciclos de teste alinhados com seus perfis. O Test IO simplifica o processo de relato de bugs com títulos, tipos e níveis de gravidade simplificados, permitindo a rearrumação dos passos. As estruturas de pagamento também diferem, com a uTest categorizando os valores dos bugs, enquanto o Test IO baseia os pagamentos em tipos de tarefas, gravidade e especificações do dispositivo. Além disso, canais de comunicação e prazos de pagamento variam entre as duas plataformas.

Os testers desempenham um papel crucial no aprimoramento da qualidade do software e garantem a satisfação do usuário final, independentemente da plataforma.

Isto respondeu à sua pergunta?