Histórico da Página
...
| 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 cinco sprints de desenvolvimento, é realizada uma sprint de estabilização seguindo o padrão de desenvolvimento ágil utilizado para a liberação de releases.
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
- Sprint 4:
- Desenvolvimento / Inovação
- Correção de Defeitos do Backlog
- Montagem de ambiente para Teste de Integração
- Sprint 5:
- Desenvolvimento / Inovação
- Correção de Defeitos do Backlog
- 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.
- 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 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.
- Correção de Bugs:
- Responsável: Desenvolvedor.
- Corrigir os bugs que foram encontrados durante testes integrado.
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.
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.
Sprint de Desenvolvimento (3).
- 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.
- 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.
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.
...
Sprint de Desenvolvimento (5).
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas