...

• Planejar requisitos para ambiente deste e documentar no Kanoah
  • Identificar quais são as principais características necessarias nesse ambiente, para que seja possível testar a nova funcionalidade, e deixá-lo mais próximo o possível da realidade do cliente.
  • Documentar os requisitos encontrados.
• Preparar ambiente para Teste de Integração
  • Preparar o ambiente de acordo com os requisitos definidos previamente.

Qualidade

------------------------

Essa sprint continua focada no desenvolvimento de novas funcionalidades (inovação); porém já inclui etapas de planejamento de teste de integração que será executado na Sprint 6, caso ainda não seja possível realizá-lo.

Image Removed

Sprint de Desenvolvimento (4).

Nesta sprint, considerando que o planejamento dos testes de integração foi realizado na sprint 3, a próxima etapa que será executada é a preparação do ambiente de testes de integração. 

Image Removed

Sprint de Desenvolvimento (5).

Essa sprint tem como objetivo focar no desenvolvimento de novas funcionalidades e engloba também o planejamento de testes de regressão. 

Dessa forma, é necessário dedicar mais pessoas para a função de Tester e diminuir um pouco a carga de novos desenvolvimentos.

Também é importante já deixar pronto um ambiente adequado para testes.

Image Removed

• Definir Suíte de Testes para Teste de Regressão
:
• em página do Kanoah com referências para esses testes
  • Responsável: Tester/QA.
  • Identificar quais os casos de testes passados devem ser realizados na
próxima
• • sprint de estabilização, para teste de regressão
, sejam manuais ou automatizados
• • .
Caso seja selecionado um caso de teste que não esteja atualizado, esse também é o momento de atualizá-lo.
• • Priorizar Testes de Integração
    
    • Principalmente aqueles que foram apenas planejados e não executados (Devemos tentar evitar essa situação!)
  • Criar página do Kanoh referenciando os testes escolhidos
  • Criar tarefas no JIRA, referentes aos testes que serão executados 
• Atualizar Casos de Teste:
  • Após leitura do caso de teste no Kanoah,
ou ferramenta automatizada,
• • entender se o mesmo exige atualização. 
  • Caso esteja desatualizado, esse é o momento de alterar o documento
, ou realizar alguma codificação no caso de teste automatizado.
• Analisar Viabilidade do Desenvolvimento de Testes de Performance/Carga:
  
  • Responsável: Tester/QA.
  • Identificar se o teste pode ser feito de maneira automatizada (Recomendável).
• Desenvolvimento de Testes:
  • Responsável: Tester/QA.
  • É realizado apenas se for identificada viabilidade.
Escrever Casos de Teste no Kanoah:
• Definir Casos de Teste e as métricas esperadas para o teste de performance/carga no Kanoah
• • Responsável: Tester/QA
.
• É realizado apenas se o teste for manual.
• Passo a passo do teste que será realizado.
Criar todas as tarefas
• • Criar página no Kanoah 
  • Criar tarefas no JIRA, referentes aos testes que serão executado

executados na próxima sprint no JIRA:
• Desenvolvimento de Testes de Performance/Carga
• • Responsável: Tester/QA.
• Todos os casos de testes que foram preparados devem gerar issues, a serem colocadas no topo do backlog.

Sprint de Estabilização

• • É realizado apenas se for identificada viabilidade.E

Estabilização

Esse fluxo é focado Essa sprint é focada em encontrar e solucionar problemas.

Engloba execução de testes de Integração, Interface, regressão e carga/performance. 

Image Removed

...

Image Added

...

• Deve gerar evidência:
  • Essa evidência pode ser um relatório gerado pela própria ferramenta/framework de teste, como o documento padrão com prints de tela ou vídeos.

...

• Execução de Testes de Regressão:
  • Responsável: Tester/QA.
  • Pode ser feito de maneira automatizada (Recomendável).
    • Deve gerar evidência:
      • Essa evidência pode ser um relatório gerado pela própria ferramenta/framework de teste, como o documento padrão com prints de tela ou vídeos.
  • Pode ser feito de maneira não automatizada (Não Recomendável):
    • Deve gerar evidência:
      • Essa evidência deve ser o documento padrão com prints de tela.
• Execução de Testes de Performance/Carga:
  • Responsável: Tester/QA.
  • Pode ser feito de maneira automatizada (Recomendável):
    • Deve gerar evidência:
      • Essa evidência pode ser um relatório gerado pela própria ferramenta/framework de teste, como o documento padrão com prints de tela ou vídeos.
    • Pode ser feito de maneira não automatizada (Não Recomendável):
      • Deve gerar evidência:
        • Essa evidência deve ser o documento padrão com prints de tela.
• Correção de Bugs:
  • Responsável: Desenvolvedor.
  • Corrigir os bugs que foram encontrados durante testes de Integração, Regressão e Performance/Carga.
• Correção de defeitos críticos do backlog:
  • Responsável: Desenvolvedor.
  • Esse é o melhor momento para resolver esses defeitos.
• Correção de defeitos não críticos do backlog:
  • Responsável: Desenvolvedor.
  • A intenção é limpar, o máximo possível, os defeitos que foram abertos no backlog, mesmo que não apontados como algo crítico.

Regras Gerais

Nos processos desenhados acima, foi possível encontrar algumas regras gerais, como:

...