Vamos mostrar aqui as regras necessárias para abrir uma tarefa no desenvolvimento.

Esse procedimento deve ser executado pelas pessoas que trabalham no teste a cada vez que abrirem uma tarefa.

• Toda tarefa deve ser testada nas duas versões: Stable e Unstable.
• Colocar qual a versão foi encontrado o erro, se for na Unstable, deve obrigatoriamente vir "Unstable - " no início do título da tarefa.
• Colocar o corpo da tarefa que foi testado e achado o erro na Stable ou na Unstable, se for nas duas colocar as duas.
• O nome do modulo deve vir no começo dos módulos, no caso do E-Trade não precisa de colocar ele no começo.
  • PDV
  • Gourmet
  • Bridge
  • CCM
  • iFood
  • Mercos
  • Imendes
  • GourmetDroid
  • VR Pedidos
• Todo o título deve ser em maiúsculo no começo e demais minúsculos. Se cadastrarem o titulo ou corpo com tudo maiúsculo é serviço do teste mudar para o padrão de CamelCase.
• Deve-se categorizar quando for nódulos específicos, como PDV, Gourmet etc.
• Colocar sempre o cliente quando for da VR.
• Colocar sempre o Partner quando for de parceiros.
• Colocar sempre o técnico responsável.
• Não pode deixar o Partner ou outro técnico criar uma tarefa como Task, isso é dever apenas dos programadores, se vier a tarefa como Task o tester deve mudar para Feature.
• Se durante a versão corrente, ocorrer alguma grande mudança em alguma funcionalidade deve-se abrir sempre na unstable, mesmo que o bug seja encontrado na stable. Veja nesse vídeo que explico um pouco sobre isso.
• Cabe ao teste revisar o artigo que foi aberto pelo técnico ou partner e corrigir o título e corpo, deixando o mesmo mais inteligível para o programador, também colocando imagens ou outras informações complementares.
• Se o partner ou tecnico subir o banco em algum serviço, cabe o teste baixar o banco e guardar uma cópia até a tarefa ser concluída. Devendo depois de terminada descartar o banco do cliente, lembre-se que esse banco não deve ficar na nosso HD depois de terminado os testes. Deleta-los inclusive da lixeira. Cabe ao teste manter uma boa organização dos seus arquivos.
• Solicitação de relatórios devem ser rejeitadas, agora os relatórios devem ser feitos pela tela de relatório customizado, orientar o Partner a buscar informações sobre isso com o comercial.

Nesse vídeo abaixo tem uma conversa minha de da Rhiana sobre como abrir bug com alguns pontos desses comentados acima:

Outras informações importantes

• Nós usamos uma URL de teste a parte para o VR Pedidos, essa URL só deve ser usada pela equipe de Teste, os DEVs devem usar a URL normal de produção:
  • Landing Page: https://homo.vrpedidos.com.br
  • Admin: https://adminhomo.vrpedidos.com.br
  • Os dados de acesso são o mesmo da produção, ele replicou o banco de dados. Se precisarem de uma nova loja na administração terá que solicitar com o DEV.
  • Essa loja é mais para testar a parte admin do VR Pedidos, não dá para testar a parte de integração.

Responsabilidades

Partners

Temos duas pessoas trabalhando nos testes dentro dos partners, uma delas vai trabalhar com os bugs já resolvidos para testá-los e outra com possíveis bugs não confirmados.

Ludmilla

• Testa os bugs quando estão no Deploy (mesmo que o reporter esteja João Otávio)
• Revisa tarefas de features antes de mandar para frente para aprovação. Como ajustar textos, colocar prints, explicar melhor a necessidade, etc. Aqui a Ludmilla coloca o reporter no seu nome.
• Testar Features e Tasks do Deploy que estejam ou no seu nome como reporter ou no nome do João como reporter.

João Otávio

• Vai testar os possíveis bugs ainda não confirmados. Os técnicos quando em atendimento identificam um possível bug, eles passam isso para o João Otávio ele irá testar se realmente existe o bug ou não. Existindo é papel dele abrir o bug e colocar ele como Repórter.

Cliente final

Temos apenas a Flávia atendendo essa demanda.

Flávia

• Testar possíveis bugs de cliente final, colocando-os no seu nome como reporter.
• Testa bugs que estão no deploy no seu nome como reporter.
• Abre tarefas de cliente final e revisa os dados de tarefas abertas dos técnicos de cliente final. Coloca a tarefa como seu nome em reporter.
• Testa Features e Tasks que estejam no Deploy no seu nome como reporter.