Objetivo

Esse documento tem o objetivo de apresentar o processo de Testes e Qualidade realizado pela equipe de Framework T-TALK. 

O processo segue as melhores práticas de cada uma das linhas de produto envolvidas, e os conceitos propostos pela engenharia corporativa (04. Processo Desenvolvimento Ágil | Execução do Sprint).
Dessa maneira, garantimos qualidade, segurança e inovação nas integrações configuradas entre duas, ou mais, linhas.

Termos e Nomenclaturas

Os termos deve, não deve, requerido, pode, não pode, recomendado, opcional devem ser interpretados como descritos no padrão RFC-2119.

Abaixo, encontram-se termos técnicos que são mencionados e seus significados de maneira simplificada: 

• Teste Unitário: Verifica o funcionamento de um pedaço do sistema ou software isoladamente ou que possam ser testados separadamente. Um pedaço pode ser uma classe, um método, um programa. 
• Teste de Qualidade de Código: Verifica o código fonte dos programas em consonância com padrões, melhores práticas, instruções não executadas e outras.
• Code Review: Leitura do código por outro desenvolvedor, a fim de encontrar problemas e possíveis melhorias.
• Teste Integrado: Combinação de dois ou mais componentes do sistema, para verificar se eles funcionam corretamente juntos. 
• Teste de Interface: É uma maneira de realizar um teste integrado. Através desse verifica-se se os dados são processados e apresentados ao usuário de forma correta, conforme as especificações.
• Teste de Carga/Performance: Verifica se o sistema atende aos níveis de desempenho e tempo de resposta definidos como aceitáveis.
• Teste de Regressão: Verifica se os outros componentes do sistema, de versões anteriores, continuam funcionando após a entrada de um novo componente. 
• Teste Sistêmico: O Teste Sistêmico é uma fase do processo de teste de software em que o sistema, já completamente integrado, é verificado quanto a seus requisitos num ambiente com padrões similares a um ambiente de produção.
• Teste de Integração: Verifica se as operações que envolvem dois, ou mais, sistemas estão se comportando conforme o esperado.
  
  

Funcionamento

As tarefas de teste, e seus responsáveis, variam dependendo se a equipe está em uma sprint de desenvolvimento ou estabilização.

A cada três sprints de desenvolvimento, é realizada uma sprint de estabilização.

Sprint de Desenvolvimento (1 e 2)

Essas sprints são focadas no desenvolvimento de novas funcionalidades (inovação).

Engloba testes unitários, qualidade de código, integrados e, quando for viável, a realização de testes de integração. 

• Desenvolvimento de testes unitários:
  • Responsável: Desenvolvedor.
  • Os casos de testes são especificados na própria ferramenta/Framework utilizado (Mais detalhes em Especificidades das Linhas).
  • Deve ser codificado de maneira a ser um teste automatizado, seguindo o Framework de testes mais adequado para o cenário. Ou seja, todo teste unitário deve ser automatizado.
  • Deve ser feito para novas funcionalidades.
  • Pode seguir as práticas do TDD (Recomendável).
  • Pode ser feito para funcionalidades antigas que forem revisitadas (Recomendável).
• Execução de testes unitários:
  
  • Responsável: Desenvolvedor.
  • A execução desses testes deve gerar um relatório, que deve ser anexado na subtarefa de Teste Unitário ao ser concluída.
• Execução de Teste de Qualidade de Código:
  • Responsável: Desenvolvedor.
  • É executado através de ferramenta que atenda a linguagem e estrutura do sistema (Mais detalhes em Especificidades das Linhas).
  • A execução desses testes deve gerar um relatório, que deve ser anexado na subtarefa de Teste de Qualidade de Código ao ser concluída.
• Code Review:
  
  • Responsável: Tester/QA.
  • É um momento de análise de possíveis problemas ou melhorias, envolvendo uma comunicação mais próxima entre o tester e desenvolvedor.
• Correção de Defeitos críticos no Backlog:
  • Responsável: Desenvolvedor.
  • Deve ser evitado trazer correção de defeitos para sprints de inovação, apenas casos críticos.
• Analisar Viabilidade do Desenvolvimento de Teste Integrado:
  • Responsável: Tester/QA.
  • Identificar se o teste pode ser feito de maneira automatizada (Recomendável).
• Desenvolvimento de Testes Integrados:
  • Responsável: Tester/QA.
  • É realizado apenas se for identificada viabilidade.
• Escrever Casos de Teste no Kanoah:
  • Responsável: Tester/QA.
  • É realizado apenas se o teste for manual.
  • Passo a passo do teste que será realizado.

Execução de Testes Integrados:

• Responsável: Tester/QA.
• Deve ser feito de maneira manual. 
  • Deve gerar evidência:
    • Essa evidência pode ser documento padrão com printsAnalisar Viabilidade do Desenvolvimento de Testes de Integração:

• Analisar Viabilidade do Desenvolvimento de Testes de Integração:
  
  • Responsável: Tester/QA.
  • Identificar se o teste pode ser feito de maneira automatizada (Recomendável).

• Execução de Testes de Integração
  • Responsável: Tester/QA.
  • Deve ter o ambiente previamente configurado para que seja executado nas Sprints 1 e 2. 
• Correção de Bugs: 
  • Responsável: Desenvolvedor.
  • Corrigir os bugs que foram encontrados durante testes integrado.

Sprint de Desenvolvimento (3).

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 próxima sprint, caso ainda não seja possível realizá-lo.

• Planejamento do ambiente do Teste de Integração:
  • Definir quais são os requisitos aceitáveis para que um ambiente de sistemas integrados reflita, o mais próximo possível, um ambiente utilizado pelo cliente.

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 é o planejamento do ambiente de testes de integração. 

• Preparar ambiente para Teste de Integração:
• Preparar o ambiente de acordo com os requisitos definidos previamente.

Sprint de Desenvolvimento (5).

Essa sprint tem como objetivo focar no desenvolvimento de novas funcionalidades e engloba também a realização 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.

• • Definir Suíte de Testes para Teste de Regressão:
    • Responsável: Tester/QA.
    • Identificar quais os casos de testes passados devem ser realizados na próxima sprint, 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.
  • 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:
    • Responsável: Tester/QA.
    • É realizado apenas se o teste for manual.
    • Passo a passo do teste que será realizado.
  • Criar todas as tarefas referentes aos testes que serão executados na próxima sprint no JIRA:
    
    • 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

Essa sprint é focada em encontrar e solucionar problemas.

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

• Executar de Testes de Integraçã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 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:

• Todo teste unitário deve ser automatizado.
• Todos os outros testes devem priorizar a automação, porém podem ser feitos de maneira manual dependendo de viabilidade/complexidade
• Os frameworks atuais de desenvolvimento de testes apresentam uma estrutura organizada para a escrita do caso de teste no próprio código, não sendo necessário o uso do Kanoah ou de qualquer outro tipo de documento formal.
• Se o framework de teste não apresentar uma estrutura para definição do caso de teste, pode ser utilizado o Kanoah.
• Todo teste manual deve ter seu passo a passo explicado no Kanoah, e esse documento deve ser atualizado toda vez que for identificada uma suíte de testes de regressão que não corresponda a realidade atual.
• Todo teste deve gerar evidência, e essa sempre deve ser anexada na tarefa ao marcá-la como concluída. É válido: Documento padrão de evidências com prints de tela ou relatório gerado automaticamente pelo framework de teste.
• É possível paralelizar diferentes tarefas de teste, elas não são dependentes das demais.

Âncora
linhas linhas

Especificidades das Linhas

Configurador / Monitor / Diagnóstico (FrontEnd)

• Durante as sprints de estabilização, devem ser executados testes apontando para APIs de, no mínimo, duas linhas.
• Ferramentas de Testes:

• • Teste unitário: Jasmine e Karma
  • Qualidade de código: SonarCube / JSLint
  • Teste Integrado: Protractor
  • Teste de Carga/Performance: Protractor

RM

• Novas funcionalidades que podem gerar impacto nas existentes podem ser feitas em branches "requisitos" separadas
  
  • Após testes integrados, de integração e regressão, deve ser feito o merge dessa funcionalidade para a branch "atual"
• Com exceção do teste unitário, todos os demais testes devem ser feitos em um ambiente montado a partir de RESTORE, visando ter o mesmo ambiente que o cliente irá receber
• Ferramentas de Testes:
  • Teste unitário: NUnit
  • Qualidade de código: SonarCube
  • Teste de Carga/Performance: Postman

Protheus

• Toda codificação é uma nova branch no GIT, que possui o mesmo nome que a tarefa do JIRA(ex. ISSUE/SPRINT99/DEAI1-9999)
  • Após testes integrados, de integração e regressão, deve ser feito o merge das novas funcionalidades para a branch "master"
• Os testes devem ser realizados utilizando o binário específico para testes
• Os testes devem ser realizados com a lib (framework) inteira e atualizada.
• Ferramentas de Testes:
  
  • Teste unitário:A Definir
  • Qualidade de código: SonarCube 
  • Teste de Carga/Performance: Postman
  • Teste Integrado: PWA (Protheus Web Automation)
    
    

DataSul

A Definir

Logix

A Definir