Syllabus CTAL TAE

Get Started. It's Free
or sign up with your email address
Rocket clouds
Syllabus CTAL TAE by Mind Map: Syllabus CTAL TAE

1. 1. Introdução (30 min)

1.1. 1.1 Propósito

1.1.1. Testware

1.1.1.1. Criação de Testware

1.1.1.1.1. Software

1.1.1.1.2. Documentação

1.1.1.1.3. Casos de teste

1.1.1.1.4. Ambiente de teste

1.1.1.1.5. Dados de teste

1.1.1.2. Atividades de teste

1.1.1.2.1. Interfaces públicas, módulos ou bibliotecas do SUT (Teste de API)

1.1.1.2.2. Interface de usuário do SUT (teste de GUI ou CLI)

1.1.1.2.3. Teste através de serviço ou protocolo

1.1.2. Objetivos

1.1.2.1. Melhorar a eficiência do teste

1.1.2.2. Cobertura de funções mais ampla

1.1.2.3. Reduzir o custo total do teste

1.1.2.4. Fazer testes que os testadores manuais não podem

1.1.2.5. Reduzir o período de execução do teste

1.1.2.6. Aumentar a frequência de teste a partir da redução do tempo nos ciclos de teste

1.1.3. Vantagens

1.1.3.1. Mais testes podem ser executados por compilação

1.1.3.2. Criar testes que não podem ser feitos manualmente (em tempo real, remoto, testes paralelos)

1.1.3.3. Aumentar a complexidade dos testes

1.1.3.4. Aumentar a velocidade de execução dos testes

1.1.3.5. Reduzir os erros humanos na execução dos testes

1.1.3.6. Elevar a eficácia e eficiência dos recursos de teste

1.1.3.7. Feedback mais rápido sobre a qualidade do software

1.1.3.8. Maior confiabilidade do sistema (repetibilidade, consistência)

1.1.4. Desvantagens

1.1.4.1. Custos adicionais envolvidos

1.1.4.2. Investimento inicial para configurar o TAS

1.1.4.3. Necessita de tecnologias adicionais

1.1.4.4. Ter equipe com habilidades de desenvolvimento e automação

1.1.4.5. Manutenção do TAS em andamento

1.1.4.6. Concentração na automatização de casos de testes às custas da sua execução.

1.1.4.7. Os testes podem se tornar mais complexos

1.1.4.8. Erros podem ser introduzidos pela automação

1.1.5. Limitações

1.1.5.1. Alguns testes manuais não podem ser automatizados

1.1.5.2. A automação só verifica resultados interpretáveis pela máquina

1.1.5.3. Não substitui testes exploratórios

1.2. 1.2 Fatores de sucesso na automação

1.2.1. Test Automation Architeture (TAA)

1.2.1.1. Alinhada com a arquitetura de um produto de software

1.2.1.2. Modelado para suportar testes automatizados

1.2.2. Testabilidade do SUT

1.2.2.1. SUT deve suportar teste automatizados

1.2.2.2. Identificar as partes do SUT que podem ser automatizadas

1.2.3. Estratégia de Automação de teste

1.2.3.1. Considerar os custos da implementação

1.2.3.2. Comparar resultado dos testes de GUI com testes de API

1.2.4. Framework de Automação de Teste

1.2.4.1. Implementar instalações de reporte

1.2.4.2. Ativar facilmente a solução de problemas

1.2.4.3. Abordar adequadamente o ambiente de teste

1.2.4.4. Documentar os casos de teste automatizados

1.2.4.5. Rastrear o teste automatizado

1.2.4.6. Fácil manutenção

1.2.4.7. Manter testes automatizados atualizados

1.2.4.8. Fácil implantação

1.2.4.9. Retirar os testes conforme necessário:

1.2.4.10. Monitorar e restaurar o SUT

1.2.5. Boas práticas

1.2.5.1. Não criar código sensível à interface

1.2.5.2. Não criar automação com dependência de dados

1.2.5.3. Não criar automação sensível ao contexto

2. 2. Preparando-se para a automação (165 min)

2.1. 2.1 Fatores que influenciam a automação

2.1.1. Interfaces do SUT

2.1.1.1. Decomposição do SUT en vária camadas testáveis

2.1.2. Software de terceiros

2.1.2.1. Uso de APIs

2.1.3. Níveis de intrusão

2.1.3.1. Níveis altos de intrusão podem gerar alarmes falsos

2.1.4. Arquiteturas diferentes do SUT

2.1.5. Tamanho e complexidade do SUT

2.1.6. Automação de um SUT em desenvolvimento

2.1.6.1. Criar a partir dos requisitos funcionais e não funcionais

2.2. 2.2 Avaliação e seleção de ferramentas

2.2.1. O TAE auxilia o TM na escolha da ferramenta

2.2.2. Recursos da ferramenta x Necessidade do SUT

2.2.3. Relação custo-benefício

2.2.4. Compatibilidade da ferramenta x Componentes do SUT

2.3. 2.3 Modelagem: testabilidade e automação

2.3.1. Observabilidade

2.3.1.1. Ter casos de teste mapeáveis

2.3.2. Controle

2.3.2.1. Fornecer interfaces que podem ser usadas para teste (elementos UI, chamadas de função, elementos de comunicação )

2.3.3. Arquitetura definida

2.3.3.1. Controle e visibilidade em todos os níveis do teste.

3. 3. Arquitetura genérica de automação de teste (270 min)

3.1. 3.1 Introdução ao gTAA

3.1.1. 3.1.1 Camadas

3.1.1.1. 3.1.2 Geração

3.1.1.1.1. Criação manual de casos de teste

3.1.1.2. 3.1.3 Definição

3.1.1.2.1. Definição e implementação de conjuntos de teste e/ou casos de teste

3.1.1.3. 3.1.4 Execução

3.1.1.3.1. Executa o teste / Gera logs e relatórios

3.1.1.4. 3.1.5 Adaptação

3.1.1.4.1. Adapta o código para diferentes componentes ou interfaces do SUT

3.1.2. 3.1.6 Configuração do TAS

3.1.3. 3.1.7 Gerenciamento de Projeto TAS

3.1.3.1. Modelos de teste

3.1.3.2. Especificações: dados de teste, casos de teste

3.1.3.3. Scripts de teste

3.1.3.4. Motores de execução de teste

3.1.3.5. Adaptadores de teste para o SUT

3.1.3.6. Simuladores e emuladores para o ambiente SUT

3.1.3.7. Resultados de testes e relatórios de testes

3.1.4. 3.1.8 Gerenciamento TAS

3.1.4.1. Relatórios de teste

3.1.4.2. Logs e os resultados dos testes extraídos facilmente ou automaticamente

3.2. 3.2 Modelagem TAS

3.2.1. 3.2.1 Introdução a modelagem

3.2.1.1. Abordagens

3.2.1.1.1. Tipo de teste

3.2.1.1.2. Fase do projeto a ser automatizada

3.2.1.1.3. Nível de teste a ser suportado

3.2.1.1.4. Compatibilidade SUT - TAS

3.2.1.2. Modelagem x Camadas

3.2.1.2.1. Geração

3.2.1.2.2. Definição

3.2.1.2.3. Execução

3.2.1.2.4. Adaptação

3.2.1.3. Abstrações

3.2.1.3.1. Permitem maior flexibilidade do TAS

3.2.1.3.2. Melhora visualização ex: Relatórios

3.2.1.3.3. Aumenta a vida útil do TAS

3.2.1.4. Conexão SUT x TAS

3.2.1.4.1. Níveis

3.2.1.4.2. Paradigmas

3.2.1.5. Compreender o ambiente SUT

3.2.1.5.1. Computador com SUT e TAS

3.2.1.5.2. Computadores em rede individuais para um SUT e TAS

3.2.1.5.3. Dispositivos de teste adicionais ex: conversor de televisão.

3.2.1.5.4. Dispositivos de teste em rede

3.2.1.5.5. Simuladores para simular o ambiente físico do SUT

3.2.1.6. Tempo e complexidade para implementação de testware

3.2.1.6.1. Estimativa baseada em analogia,

3.2.1.6.2. Estruturas de divisão de trabalho

3.2.1.6.3. Estimativa paramétrica

3.2.1.6.4. Baseadas em tamanho

3.2.1.6.5. Estimativas de Grupo

3.2.1.7. Facilidade de uso X Arquitetura de testware

3.2.1.7.1. Modelagem orientada ao testador

3.2.1.7.2. Facilidade de utilização do TAS

3.2.1.7.3. Suporte do TAS ao gerenciamento de projetos e desenvolvimento

3.2.1.7.4. Organização eficaz, navegação e busca

3.2.1.7.5. Documentação útil, manuais e texto de ajuda

3.2.1.7.6. Relatórios práticos por e sobre o TAS

3.2.1.7.7. Desenhos para abordar o feedback do TAS e insights empíricos

3.2.2. 3.2.2 Abordagens para automatizar casos de teste

3.2.2.1. Abordagem de captura e reprodução

3.2.2.1.1. Prós: Fácil de configurar e usar.

3.2.2.1.2. Contra: Difíceis de manter

3.2.2.2. Scripts lineares

3.2.2.2.1. Prós: Fácil de implementar

3.2.2.2.2. Contras: Scripts difíceis de manter

3.2.2.3. Scripts estruturados

3.2.2.3.1. Prós: Reutilização de scripts

3.2.2.3.2. Complexo de implementar

3.2.2.4. Teste orientado a dados

3.2.2.4.1. Prós: Bom pra testar variedade de dados

3.2.2.4.2. Contras: gerenciar arquivos de dados

3.2.2.5. Palavras chave

3.2.2.5.1. Prós: Alto nível de abstração e reutilização de código

3.2.2.5.2. Contras: Não indicado para sistemas simples

3.2.2.6. Direcionado a processo

3.2.2.6.1. Prós: Uso de cenários e fluxos

3.2.2.6.2. Contras: Difícil de ser modelado corretamente

3.2.2.7. Baseado em modelo

3.2.2.7.1. Prós: permite que a abstração se concentre na essência do teste

3.2.2.7.2. Contras: ferramentas escassas de modelagem e de teste

3.2.3. 3.2.3 Considerações técnicas do SUT

3.2.3.1. Interfaces do SUT

3.2.3.1.1. Comunicação entre interfaces internas e externas

3.2.3.2. Dados SUT

3.2.3.2.1. Pode usar dados internos, de usuários e de outros sistemas

3.2.3.3. Configurações SUT

3.2.3.3.1. Diferentes dispositivos e Sistemas operacionais

3.2.3.4. Padrões SUT e configurações legais

3.2.3.4.1. Deve respeitar politicas de privacidade

3.2.3.5. Ferramentas e ambientes de ferramentas

3.2.3.5.1. Comunicação com ferramentas de gerenciamento

3.2.3.6. Testar interfaces no produto de software

3.2.3.6.1. Deixar interfaces no produto final para fins de testes de manutenção

3.2.4. 3.2.4 Considerações para processos de desenvolvimento e qualidade

3.2.4.1. Controle de execução de teste: batch/interface

3.2.4.2. Relatórios: Dinâmicos / fixos / diferentes layouts

3.2.4.3. Direitos de acesso

3.2.4.3.1. Certificados / política de segurança

3.3. 3.3 Desenvolvimento TAS

3.3.1. Introdução desenvolvimento TAS

3.3.1.1. Segue as mesmas regras de desenvolvimento de um software

3.3.2. Compatibilidade TAS - SUT

3.3.2.1. Processo

3.3.2.1.1. Coordenar desenvolvimento do SUT, TAS e dos testes

3.3.2.2. Equipe

3.3.2.2.1. Integração entre as esquipes de TAS e do SUT

3.3.2.3. Tecnológica

3.3.2.3.1. Iteração contínua entre TAS e SUT

3.3.2.4. Ferramentas

3.3.2.4.1. Facilidade de intercâmbio de ferramentas

3.3.3. Sincronização TAS - SUT

3.3.3.1. Requisitos

3.3.3.1.1. Desenvolvimento

3.3.3.1.2. SUT

3.3.3.2. Fases de desenvolvimento

3.3.3.3. Rastreamento de defeitos

3.3.3.4. evolução

3.3.4. Reutilização TAS

3.3.4.1. Revisá-lo sempre que necessário

3.3.4.2. Manter documentação atualizada

3.3.5. Apoio a Variedade de Sistemas Alvo

3.3.5.1. lidar com variações técnicas

4. 4. Processos de implantação de contingência (150 min)

4.1. 4.1 Abordagem de implementação

4.1.1. 4.1.1 Projeto Piloto

4.1.1.1. Identificar

4.1.1.1.1. Não selecionar projeto crítico

4.1.1.1.2. Não selecionar projeto trivial

4.1.1.1.3. Incluir gerência

4.1.1.2. Planejar

4.1.1.2.1. Criar plano de execução

4.1.1.2.2. Alocar recursos

4.1.1.2.3. envolver desenvolvedores na implantacão

4.1.1.3. Conduzir

4.1.1.3.1. Analisar funcionalidade

4.1.1.3.2. Analisar TAS X processos

4.1.1.4. Avaliar

4.1.2. 4.1.2 Implantação

4.1.2.1. Implantação incremental

4.1.2.2. Adaptação/aperfeiçoamento de processos

4.1.2.3. implementação melhorias:

4.1.2.4. lições aprendidas

4.1.3. 4.1.3 TAS no ciclo de vida do software

4.1.3.1. Início do projeto /marco/fim de um sprint

4.2. 4.2 Avaliação de risco e estratégia de mitigação

4.2.1. riscos do produto ou do projeto

4.2.1.1. demasiada abstração/bibliotecas indisponíveis

4.2.2. riscos típicos do projeto

4.2.2.1. Atrasos na introdução da automação

4.2.3. possíveis pontos de falha

4.2.3.1. migração de ambiente

4.3. 4.3 Manutenção da automação

4.3.1. Tipos de manutenção

4.3.1.1. Preventiva

4.3.1.2. Corretiva

4.3.1.3. Perfeita

4.3.1.4. Adaptativa

4.3.2. Escopo e abordagem

4.3.2.1. critérios

4.3.2.1.1. Tamanho e complexidade do TAS

4.3.2.1.2. Tamanho da mudança

4.3.2.1.3. Riscos a mudança

4.3.2.2. componentes de terceiros

5. 5. Relatórios de automação de testes e métricas (165 min)

5.1. 5.1 Seleção de métricas TAS

5.1.1. Métricas Externas

5.1.1.1. Beneficios da automação

5.1.1.2. Esforço pra construir

5.1.1.3. Analisar falhas

5.1.1.4. manter testes automatizados

5.1.1.5. Relação entre falhas e defeitos

5.1.1.6. Tempo para executar

5.1.1.7. Números de aprovação e falha

5.1.1.8. Falhas falsas e resultados de falso-passe

5.1.1.9. Cobertura de código

5.1.2. Métricas internas

5.1.2.1. Script de ferramenta

5.1.2.1.1. linhas de código e complexidade ciclomática

5.1.2.2. Densidade de defeitos de código de automação

5.1.2.2.1. boas práticas de codificação

5.1.2.3. Velocidade e eficiência dos componentes TAS

5.1.2.3.1. O TAS não deve afetar o desempenho do SUT

5.2. 5.2 Implementação da medição

5.2.1. Recursos que suportam medição e geração de relatórios

5.2.2. ferramentas de terceiros (planilhas, XML, documentos, bancos de dados)

5.2.3. Visualização de resultados (painéis de controle, gráficos)

5.3. 5.3 Registro do TAS e do SUT

5.3.1. TAS

5.3.1.1. prints, logs, data/hora, status, contadores

5.3.2. SUT

5.3.2.1. Informação de configuração ( Firmware, SO)

5.3.2.2. Data/hora interação

5.4. 5.4 Relatório de automação de testes

5.4.1. Conteúdo

5.4.2. Publicação

6. 6. Transição de teste manual para ambiente automatizado (120 min)

6.1. 6.1 Critérios para automação

6.1.1. Frequência de uso

6.1.2. Complexidade para automatizar

6.1.3. Maturidade do processo de teste

6.1.4. Adequação com o ciclo de vida do produto

6.1.5. ambiente de teste flexível

6.1.6. Educação da equipe para o paradigma

6.2. 6.2 Automação em testes de regressão

6.2.1. Frequência de execução do teste

6.2.2. Tempo de execução do teste

6.3. 6.3 Automação em testes de novos recursos

6.3.1. adaptação ao crescimento do software

6.4. 6.4 Automação em testes de confirmação

6.4.1. Podem ser posteriormente incorporados no escopo de teste

7. 7. Verificação do TAS (120 min)

7.1. 7.1 Componentes automatizados em um ambiente de teste

7.1.1. Configuração

7.1.2. Testar scripts com aprovações e reprovações conhecidas

7.1.3. carregar e descarregar o TAS de qualquer ambiente

7.1.4. comunicação com sistemas externos

7.2. 7.2 verificando conjunto de testes automatizados

8. 8. Melhoria contínua (150 min)

8.1. 8.1 Opções para melhorar a automação de teste

8.1.1. Scripts

8.1.1.1. hard coded

8.1.1.2. sondagem

8.1.2. Execução de Teste

8.1.3. Verificação

8.1.4. Arquitetura

8.1.5. Pré e pós-processamento

8.1.6. Documentação

8.1.7. Recursos TAS

8.1.8. Atualização e aprimoramento do TAS

8.2. 8.2 Planejando a implementação da melhoria da automação de teste

8.2.1. Identificar alterações nos componentes do ambiente de teste

8.2.2. Aumente a eficiência e a eficácia das bibliotecas de funções principais do TAS

8.2.3. Funções de múltiplos alvos que agem sobre o mesmo tipo de controle para consolidação

8.2.4. Funções de múltiplos alvos que agem sobre o mesmo tipo de controle para consolidação

8.2.5. Funções de múltiplos alvos que agem sobre o mesmo tipo de controle para consolidação

8.2.6. Avaliação de scripts existentes para revisão ou eliminação de SUT

9. Siglas

9.1. 1. CLI: Command Line Interface

9.2. 2. EMTE: Equivalent Manual Test Effort

9.3. 3. gTAA: Generic Test Automation Architeture

9.4. 4. GUI: Graphical User Interface

9.5. 5. TAA: Test Automation Architeture

9.6. 6. TAE: Test Automation Engineer

9.7. 7. TAF: Test Automation Framework

9.8. 8. TAM: Test Automation Manager

9.9. 9. TAS: Test Automation Solution

9.10. 10. UI: User Interface