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:
| Por outro lado, o formulário de bug do Test IO simplifica a documentação do tester com a seguinte estrutura:
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:
Os testers são obrigados a identificar e relatar esses bugs com precisão. | O Test IO categoriza bugs da seguinte forma:
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:
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:
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:
Gravações de tela devem atender aos seguintes critérios:
| Os testers do Test IO podem incluir anexos, como capturas de tela, gravações de tela e logs de travamento.
Capturas de tela:
Gravação de tela deve atender aos seguintes critérios:
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:
| 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:
| No Test IO, os testers freelancers podem realizar essas tarefas pagas e receber os seguintes bônus:
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.