Testlio segue um processo de teste estruturado vinculado a espaços de trabalho. Os testers são atribuídos a espaços de trabalho específicos para realizar uma variedade de testes, como testes exploratórios, testes de pagamento, testes de regressão funcional, testes de localização, testes de acessibilidade, testes de usabilidade, testes de transmissão ao vivo e testes de SDK de instrumentação, nos quais realizam casos de teste de cima para baixo.

Se a etapa do caso de teste falhar, os testers devem enviar bugs ou problemas; se o bug já foi enviado, eles devem executar uma reprodução.

Os testers podem encontrar bugs duplicados ao enviar um problema, olhando os relatórios de outros testers ou pesquisando no ❝Navegador de Problemas❞. Se o título contiver no mínimo 30 caracteres, os testers receberão automaticamente sugestões de problemas semelhantes já relatados.

A Equipe de Teste seleciona testers com base em seus perfis e informações do dispositivo para corresponder aos requisitos do espaço de trabalho e os convida por e-mail em duas etapas. Primeiro, o convite é para o espaço de trabalho; a segunda etapa é para um ciclo em que o tempo, o dispositivo e o cronograma para teste são fornecidos.

Dependendo do espaço de trabalho, os testers podem ou não receber convites para um ciclo; tudo depende das necessidades do espaço de trabalho.

Os testers devem aceitar o convite para o ciclo a fim de serem incluídos nele. Deixar os convites expirarem é considerado um problema grave.

Após concluir o tempo designado para o teste, os testers precisam preencher uma pesquisa de feedback.

Depois de relatar um problema, o TL pode aprová-lo, solicitar informações adicionais ou encerrá-lo. Encerrar um problema equivale a uma rejeição e afetará a pontuação do tester.

Assim, os testers aguardam que outros identifiquem problemas e, em seguida, realizem uma reprodução, já que enviar um problema pode prejudicar a classificação/pontuação do tester se for fechado (rejeitado). Em contrapartida, se o bug for aceito, não há benefícios associados.

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.

Quando necessário, o formulário de bug ou problema da Testlio segue a seguinte estrutura:

Gravidade, recurso e etiquetas são listas suspensas para seleção de opções; as outras seções, exceto anexo, são modelos que os testers devem preencher manualmente. Isso se aplica a cada etapa com falha, bug enviado ou reprodução executada.

Cada problema deve ter um prefixo indicando a seção onde ocorre antes do título, a menos que seja especificado de outra 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.

A Testlio geralmente classifica problemas nas seguintes categorias:

Problemas funcionais exigem dois anexos para documentação.

O teste de localização requer a verificação tanto do problema de IU quanto do próprio conteúdo.

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 de funcionalidade na Testlio é classificada da seguinte forma:

Os testers determinam qual gravidade melhor se aplica ao problema com base em uma breve explicação de cada nível.

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.

O Testlio permite que os testers anexem arquivos relevantes aos seus relatórios de bug, como capturas de tela, gravações de tela e arquivos de log (crash, console e, às vezes, arquivos de log do Charles).

Arquivos de log são obrigatórios, e bugs funcionais devem ser acompanhados por dois anexos distintos.

Esses anexos devem ter nomes significativos para auxiliar o desenvolvedor que os baixar a diagnosticar o problema.

Enquanto uma captura de tela ou uma gravação de tela pode documentar facilmente bugs visuais, bugs funcionais exigem dois anexos por problema enviado.

Gravação de Tela:

Todos os problemas devem ter uma captura de tela da página (mesmo se o tester tiver anexado uma gravação de tela). Além disso, um arquivo de texto com um trecho de código HTML do problema deve ser adicionado. Em alguns casos, as informações na seção ❝Anexos no Relatório de Bug❞ podem ser suficientes.

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.

Testlio incentiva a comunicação entre testers e líderes de teste por meio do Chat da plataforma ou do canal específico do RocketChat para o espaço de trabalho. No entanto, os testers são adicionados a este Chat apenas se tiverem sido aprovados em um teste de certificação ou se for necessário para o espaço de trabalho.

O e-mail é utilizado para enviar aos testers solicitações de melhorias.

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.

A Testlio remunera os testers por hora, não por 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.

Na Testlio, os testers freelancers são remunerados com base nas horas atribuídas para realizar tarefas específicas dentro de um ciclo em um projeto determinado.

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.