Testes
Features e Bugs

Após o desenvolvimento das features ou correção de bugs, são realizados testes individuais com cada ticket buscando validar o funcionamento correto e garantir que todos os requisitos foram seguidos.

Os testes são realizados sempre a partir de tickets do tipo Test que são abertos dentro de Bugs e Features. O andamento dos tickets é acompanhado pelo Product Owner e ao identificar necessidade de teste de uma feature ou bug, realiza a abertura do ticket de Test e o mantém em situação New já associando à um analista de teste. Ao encerrar a correção de um bug ou desenvolvimento de todas as stories de uma feature, o desenvolvedor é responsável por alterar a situação do ticket de teste para Backlog.

Responsabilidade: Analista de testes

1. Board e Novos testes

Quando o ticket de teste é alterado para o Backlog, o analista de testes será notificado por e-mail e pode iniciar os testes. O ticket de teste é responsabilidade do analista de testes atribuído e deve ter a situação alterada conforme o status correto. As situações utilizadas para este ticket são:

New: A feature/bug está em desenvolvimento (Inclui FIX) e o teste ainda não pode ser realizado
Backlog: O ticket está pronto para ser testado
Doing: O analista de testes está realizando testes com o ticket
Blocked: Alguma situação impediu o andamento dos testes, mas ainda está sob responsabilidade do analista de testes
Done: Teste finalizado

Após início dos testes o ticket pode ser gerenciado através do Board de Testes.

Cada feature/bug tem somente um ticket de teste que será utilizado para testar TUDO, inclusive caso existam FIX após os testes.

2. Validação Inicial

Para realizar os testes é necessário que o analista valide algumas situações inicialmente. Essas situações são referentes à entrega final do desenvolvimento:

Em caso de features todas as Stories precisam estar em status Done no Redmine.
O link do Merge Request que será testado deve estar na descrição do ticket da feature/bug dentro de uma seção chamada Merge Request.
- O merge request que será testado precisa ser o Merge Request do bug/feature e não de stories
Avaliar se Merge Request de cada ticket está dentro das definições para Merge:
- Deve conter somente 1 commit
- Arquivo de changelog
- Não ter commits "para trás" da branch de destino
  - Se houverem muitos commits para trás, é necessário pedir para o desenvolver fazer rebase

Obs: Caso algum dos requisitos não seja atendido deve ser realizado contato com algum desenvolvedor para ajustar.

3. Ambientes de teste

> Ambientes Testing iTFlex

Os testes podem ser realizados através dos ambientes Testing da iTFlex.

Estes ambientes são compartilhados e devem ser alocados através do bot. Ao alocar um servidor testing será criado um pipeline no CI/CD e é necessário aguardar o término. O Pipeline faz algumas ações de forma automatizada: volta snapshot dos servidores, gera pacotes no repo com a branch informada, configura os servidores para utilizar este branch e verifica novas atualizações. Após esse processo é necessário acessar os servidores e realizar a atualização da aplicação manualmente:

ssh fwflex-testing-1-fw01
itflex-packages update itflex

Após utilização é necessário executar a liberação do ambiente no bot.

> Ambiente local criado manualmente

Também é possível realizar os testes em outro ambiente que não seja de testes da iTFlex. Neste caso é necessário tomar cuidado com atualizações de branchs de teste para outras branchs de teste. O ideal é que o ambiente esteja sempre na versão stable e seja atualizado para a branch de testes.

Para realizar testes desta forma é necessário gerar pacotes através do bot: bot testing-rpm deploy <branch>

Após finalização do pipeline é possível ajustar a máquina para receber atualizações do novo repo e atualizar:

itflex-packages set-repo <branch>
itflex-packages update itflex

4. O que testar?

Os testes devem abordar os pontos:

Requisitos do ticket
- Os tickets de Feature contam com uma seção "Definição de conclusão - Testes". Todos os tópicos devem ser totalmente atendidos
  - Em features mais complexas esta seção também pode estar presente nas Stories
- Os bugs precisam estar corrigidos e o problema não acontecer mais
Padrões do produto
- Validar questões gerais do produto, como:
  - Erros de português
  - Funcionamento dos campos e botões
  - Validação de campos onde necessário
  - Auditoria
  - Erros ao aplicar

5. Conclusão dos testes

Apontamentos

Necessário realizar o apontamento das horas trabalhadas no ticket de teste com o tipo de apontamento Testes.

Sucesso

Caso o teste seja concluído com sucesso e nenhum problema tenha sido detectado, o ticket de teste deve ser passado para o status Done.

Falha - Bugs

Caso o bug não tenha sido resolvido é necessário colocá-lo novamente na sprint correção.

Adicionar NOTA ou Checklist no ticket do bug com o problema encontrado e explicando a situação ocorrida
Alterar Situação do ticket de teste para NEW
Alterar Situação do ticket de bug para Backlog

Caso necessário pode ser agendada uma call rápida com os desenvolvedor envolvidos no ticket para alinhamento.

Falha - Features

Caso algum problema seja detectado é necessário abrir um ticket de fix e associá-lo à sprint pois as correções tem prioridade sobre os outros tickets

Abrir ticket de FIX DENTRO do ticket de teste
- Acessar ticket de teste e clicar em Adicionar na seção Subtarefas
- Tipo: Fix
- Título: FIX - nome da feature
- Situação: Backlog
- Sprint: sprint atual
- Adicionar as correções necessárias em forma de tópicos utilizando o CHECKLIST do ticket
- Adicionar prints se possível
Alterar Situação do ticket de teste para NEW

Quando as correções forem realizadas o ticket de teste será colocado no Backlog pelo desenvolvedor e todo o processo deve ser realizado novamente.

Caso hajam novas correções a serem feitas, um novo ticket de FIX deve ser aberto seguindo os mesmos padrões.

Exemplos de tickets de teste e FIX: 47054, 47041, 46582