Histórico da Página
Índice |
---|
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.
...
Aviso |
---|
Não confundir Teste Integrado com Teste de Integração! Apesar da nomenclatura parecida, o que a TOTVS entende como Teste Integrado é voltado à integração entre duas partes do mesmo sistema. Os testes escritos para a classe A, por exemplo, que busca informações do banco de dados, ou utiliza uma chamada de método de outra classe, é um teste integrado. Por outro lado, o Teste de Integração é algo específico da nossa área de T-TALK, que envolve realizar a comunicação entre dois, ou mais, sistemas com a finalidade de analisar o comportamento dos mesmos e da integração entre eles. |
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)
Foram definidos fluxos de tarefas que deverão ser realizadas dentro de um ciclo de 6 sprints:
- Desenvolvimento / Inovação
- Correção de Defeitos do Backlog
- Montagem de ambiente para Teste de Integração
- Qualidade
- Estabilização
É recomendado que esses fluxos sejam distribuídos da seguinte maneira:
- Sprints 1, 2 e 3:
- Desenvolvimento / Inovação
- Correção de Defeitos do Backlog
- Automação Teste de Interface
- Sprint 4:
- Desenvolvimento / Inovação
- Correção de Defeitos do Backlog
- Automação Teste de Interface
- Montagem de ambiente para Teste de Integração
- Sprint 5:
- Desenvolvimento / Inovação
- Correção de Defeitos do Backlog
- Automação Teste de Interface
- Qualidade
- Sprint 6
- Estabilização
Detalhamento dos fluxos
Desenvolvimento / Inovação
Esse fluxo é voltado ao 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.
Informações |
---|
A equipe de Framework T-TALK não possui equipe de QA dedicada. Portanto, ao dizer que o responsável por uma determinada atividade é um Tester, entende-se que é um outro desenvolvedor diferente daquele que tenha codificado uma determinada tarefa, ou que esteja escalado para atuar especificamente com testes naquela sprint. |
Esse não é um processo sequencial! Quando possível, não é preciso esperar que o desenvolvedor acabe todas as suas atividades para iniciar a codificação de um teste integrado automatizado. |
- 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.
- 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:
...
- sprints.
- Planejamento de Teste de Integração para Sprints Posteriores
- 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.
- Além disso, devem ser definidos todos os requisitos dos testes que serão executados.
...
- 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.
Também é importante já deixar pronto um ambiente adequado para testes.
- 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 (5).
- 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.
Correção de Defeitos do Backlog
Corrigir problemas críticos e não críticos que se encontram no backlog.
- Correção de defeitos críticos do backlog:
- Responsável: Desenvolvedor.
- Esse é o melhor momento para resolver esses defeitos.
- Essas correções devem ser aplicadas diretamente no ambiente do cliente
- 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.
Automação Teste de Interface
- Desenvolvimento de Testes de Interface
- Responsável: Tester/QA.
- É realizado apenas se for identificada viabilidade, e se fizer sentido.
- Escrever Casos de Teste no Kanoah
- Responsável: Tester/QA.
- Passo a passo do teste que será realizado.
- 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.
Montagem de ambiente para Teste de Integração
- 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çãoPreparar 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.
Qualidade
- 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
- Priorizar Testes de Integração
- 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.
- 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.
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.
...
- 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.
...
Informações |
---|
Se uma mesma funcionalidade não foi concluída em pelo menos duas linhas, não será possível realizar o teste de integração. Nesse caso, é preciso registrar uma tarefa de teste de integração com a informação de que o teste não pode ser realizado, visando manter a rastreabilidade. A intenção é que as sprints de inovação sejam focadas com os mesmos objetivos para todos os produtos, evitando que essa situação ocorra nesse momento. |
- 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.
- Deve gerar evidência:
- 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.
- Deve gerar evidência:
- 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.
- Deve gerar evidência:
- Deve gerar evidência:
- 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 Todo teste, com exceção dos testes unitários, 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 | ||||
---|---|---|---|---|
|
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 DefinirUnit Test Automation
- Qualidade de código: SonarCube
- Teste de Carga/Performance: Postman
- Teste Integrado: PWA (Protheus Web Automation)
Informações |
---|
O Plugin Advpl para SonarCube encontra-se em desenvolvimento |
DataSul
A Definir
Logix
Datasul
- Os testes devem ser realizados com a instalação do produto atualizada.
- Ferramentas de Testes:
- Teste unitário: Jasmine e JUnit.
- Teste Contínuo: Jenkins
- Teste Integrado: Protractor
- Teste de Carga/Performance: Postman
- Qualidade de código: SonarCube
Logix
A Definir
Calendário de liberações
O processo de testes deve estar sempre adequado ao calendário de liberações utilizado que está disponível no seguinte endereço para consulta interna de participantes: Conteúdo Complementar | Release
Processo de transição
Para facilitar a adaptação da equipe T-Talk o processo de testes seguirá as seguintes etapas no processo de implantação:
- Realização de um piloto na Sprint 24 que se iniciará no dia 02/05 com término previsto para o dia 16/05. Neste piloto serão selecionadas uma tarefa de cada linha (Protheus, Datasul, RM e Logix) para uso completo de todas as etapas definidas no processo.
- Eventuais necessidades de modificações no processo de testes poderão ser mapeadas e realizadas no decorrer da Sprint 24. Repare que o processo de testes é um guideline que será utilizado pela equipe.
- Após a realização do piloto, o processo de testes será implantado em sua totalidade a partir da Sprint 25 que se início no dia 16/05.
- É responsabilidade de toda a equipe avaliar se o processo de testes está sendo cumprido, mapear e sugerir mudanças no processo de testes visando sempre uma entrega com qualidade e a satisfação dos nossos clientes internos e externos.
...