1. Consideram o aumento da complexidade dos testes como algo bom
2. Chamam de "decomposição do SUT" o fator que permite a manipulação do SUT pelo TAS
3. É esperado de um TAE
3.1. Conhecer padrões de codificação, documentação e melhores práticas
3.1.1. Regras AUTOSAR para MathWorks Matlab / Simulink®
3.1.1.1. Arquitetura para Sistemas Automotivos Abertos. Descreve módulos básicos e uma metodologia de desenvolvimento
3.1.2. MISRA para C ou C++
3.1.2.1. Facilitar a portabilidade e a confiabilidade de código no contexto de sistemas embarcados
3.1.3. Padrão de codificação JSF para C ++
3.1.3.1. Should, Will and Shall (obrigatório) são usados para dizer como é uma codificação em C++ que seguem boas práticas
3.1.3.2. * Joint Strike Fighters
3.2. Que tenha habilidades, experiências e especializações em engenharia de software
3.3. Entenda o ciclo de vida de desenvolvimento do software
3.4. Projetar um TAS onde informações possam ser extraídas facilmente ou automaticamente relatadas ao gerenciamento de projetos
3.5. Fornecer insumos para a análise do ROI, fornecendo avaliações técnicas e comparações de diferentes arquiteturas e abordagens de automação de teste com relação ao tempo, custos, esforços e benefícios
3.6. TAE precisa apoiar um TAM nas estimativas, fornecendo boas estimativas para o tempo e a complexidade de um projeto TAA
3.7. abordar questões de usabilidade para um TAS
3.8. Ao perceber que novas features serão implementadas no SUT, solicitar feedback de modeladores de teste com perícia de domínio e determinar se o TAS atual atenderá às necessidades dos novos recursos
4. Atenção total
4.1. Execução automatizada é apenas uma parte da automação de testes
4.2. Comparar resultados, controlar e configurar pré-condições de teste
4.3. Testes de API são testes em código, não de serviços!
4.4. Adoram siglas!
4.5. Testabilidade é o sucesso do projeto
4.6. Em sistemas embutidos, não preciso separar automação de testes do SUT
4.6.1. Dizem que nem todos os fatores de sucesso são necessários
4.7. Na estratégia de testes, olhe pra GUI e API para validar consistência dos resultados
4.8. Consideram viável começar a automação pequena e simples, mesmo para SUTs grandes e complexos
5. Extras
5.1. Falhas de tradução
5.1.1. 1.1. Não fica claro se devo ou não separar o software de teste do SUT
5.1.2. 1.2. Ativar facilmente a solução de problemas na verdade trata-se de troubleshooting, ou seja, quando encontro um erro, deve ser fácil identificar o motivo
5.1.3. 1.2. Rastrar o teste automatizado
5.1.4. 3.2.1. Requisitos de captura necessários para definir um TAA apropriado deveria ser ˜Capturar os requisitos"
5.2. Erros em figuras
5.2.1. Figura 1. Automação de Este ao invés de Geração de Teste
6. Siglas
6.1. SUT é o sistema em teste, ou seja, aquele que estou testando
6.2. TAS é solução de automação de testes
6.3. TAA é arquitetura de automação de testes
6.4. TAE é o engenheiro de automação de testes
6.5. TAF framework de automação de testes
6.6. TAM é o gerente de automação de testes
6.7. gTAA é a arquitetura genérica de automação de testes
6.8. SDLC é o ciclo de desenvolvimento de software
7. Mnemônicos
8. Capítulo 1 (4 páginas)
8.1. Mindset
8.1.1. Testware é usado em todo o ciclo de automação de testes. Ele é mais do que apenas scripts de teste, incluem...
8.1.1.1. Documentação
8.1.1.2. Ambientes
8.1.1.3. Software
8.1.1.4. Dados de teste
8.1.1.5. Software
8.1.2. Um TAF legal possui
8.1.2.1. Facilidade de identificar o motivo da falha, ou seja, facilitar a solução de problemas
8.1.2.1.1. A causa pode ser
8.1.2.2. Relatórios
8.1.2.3. Abordar corretamente o ambiente de testes, ou seja, controle total dele
8.1.2.4. Documentar os casos de teste automatizados, ou seja, o que e como estamos automatizando
8.1.2.5. Fácil de rastrear os casos de teste e métodos
8.1.2.6. Manutenibilidade
8.1.2.7. Casos de testes constantemente atualizados
8.1.2.8. Fáceis de implementar, retirar (quando não forem mais úteis) e alterar
8.1.2.9. Recuperar-se quando uma falha ocorrer e pular pro próximo teste
8.1.3. Objetivos, vantagens e desvantagens
8.1.3.1. Objetivos da Automação: - Custo, - tempo, + frequência, + eficiência, + cobertura e + testes impossíveis de se fazer manualmente
8.1.3.1.1. Tempo real, paralelo e remotos são considerados impossíveis de se fazer manualmente
8.1.3.2. Vantagens da Automação: + Complexidade dos testes, - erros humanos, feedback rápido, + confiança no sistema
8.1.3.3. Desantagens da Automação: + Custos configuração inicial, testers mais técnicos, manutenção dos scripts, scripts ficarem complexos e erros de automação
8.1.4. Fatores de sucesso a longo prazo
8.1.4.1. TAA
8.1.4.1.1. Alinhada com a arquitetura do produto
8.1.4.1.2. Definir requisitos funcionais e não funcionais é o mais importante
8.1.4.1.3. Preza por manutenibilidade
8.1.4.2. Testabilidade
8.1.4.2.1. Desacoplar dados da GUI nos testes de GUI
8.1.4.2.2. Métodos públicos nos testes de API
8.1.4.2.3. Devo começar a automatizar a partir dos componentes com maior testabilidade
8.1.4.2.4. É a chave para o sucesso
8.1.4.2.5. * Requisito não-funcional
8.1.4.3. * Antes do início do projeto, analise todos eles. Isso mostrará as chances de sucesso do projeto.
8.1.5. Estratégia de testes
8.1.5.1. Manutenção e consistência do SUT
8.1.5.2. Devo considerar os custos, benefícios e riscos
8.1.6. Conceitos comuns
8.1.6.1. Há mais que execução automatizada na automação de testes
8.1.6.2. Nem tudo pode ser automatizado
8.1.6.3. Scripts de teste não fazem testes exploratórios
8.1.6.4. Podemos ter tanto código no TAF quanto no SUT
8.1.6.5. Bad smells
8.1.6.5.1. Testes sensíveis a mudança de layout
8.1.6.5.2. Testes sensíveis a alteração de dados criados por outros testes, dependência entre testes
8.1.6.5.3. Testes sensíveis a informações do ambiente, como hora, localicação e etc. Use simuladores, mano!
8.2. Termos
8.2.1. Abordagens de teste
8.2.1.1. Interface pública de código (classe, libs, etc)
8.2.1.2. interface de usuário (GUI, CLI)
8.2.1.3. serviços ou protocolos
9. Dicas de brother
9.1. Quando não entender algo no Syllabus, olhe para a versão americana dele
9.2. Saiba diferenciar: TAS, TAF, TAA e gTAA
9.2.1. TAS é o ambiente de testes e os scripts
9.2.2. TAF é usado para criar um TAS
9.2.3. TAA refere-se a forma com que o TAS foi organizado
9.2.4. gTAA é um modelo de TAA que pode ser usado em muitos TAS
9.3. Decore as 7 camadas do gTAA e seus componentes. Além de sua imagem!
9.3.1. Camadas do gTAA.png
10. Capítulo 2 (5 Páginas)
10.1. Atenção total
10.1.1. Geralmente as TAT não atendem 100% às necessidades
10.1.2. Testabilidade é o sucesso do projeto
10.1.3. Níveis de intrusão fazem testes ficarem mais simples mas aumentam custos e riscos
10.1.4. A maior parte da automação deve começar antes do SUT estar disponível. Nesse caso, o TAE deve especificar as interfaces que ele precisa e estimar o esforço e tempo
10.1.5. TAE precisa especificar ao desenvolvedor quais são as interfaces necessárias para automação
10.1.6. Interfaces alternativas ou personalizadas são aquelas construídas para possibilitar testes antes que as reais sejam construídas.
10.1.7. Lembre-se de verificar a compatibilidade do SUT com o TAS desde o início
10.2. Mindset
10.2.1. O que influencia a automação?
10.2.1.1. Interfaces do SUT
10.2.1.1.1. * Como controlo o SUT através da automação de testes
10.2.1.2. Softwares de Terceiros
10.2.1.2.1. Podemos usar uma API caso a automação faça sentido
10.2.1.3. Níveis de intrusão
10.2.1.3.1. Nenhum: Consigo automatizar testes sem alterar o SUT Médio: Preciso alterar o SUT para conseguir automatizar Alto: Uso de hardware
10.2.1.3.2. * Falhas podem surgir pelas alterações feitas no SUT para possibilitar a automação, não aconteceriam em produção * Quanto maior o nível de intrusão, mais fácil é de automatizar
10.2.1.4. Tamanho e complexidade do SUT
10.2.1.4.1. Consideram viável começar a automação pequena e simples, mesmo para SUTs grandes e complexos
10.2.1.5. Arquitetura do SUT
10.2.1.5.1. Exige diferentes TAS, ou TAS híbridos (ex. TAS que suporta Python e C++, ou Web e Desktop)
10.2.2. Antes do SUT estar pronto
10.2.2.1. Se já conheço os requisitos funcionais e não funcionais, elenco o que irei automatizar a partir deles
10.2.2.2. Durante a arquitetura e a modelagem técnica, devo fazer testes na interface
10.2.3. Testabilidade
10.2.3.1. Desenvolvedor implementa isso, mas o TAE pode ajudar.
10.2.3.2. Modelagem disso consiste em
10.2.3.2.1. Observabilidade, ou seja, a interface possui elementos para validar se o SUT comporta-se como esperado
10.2.3.2.2. Controle (ou, capacidade), a interface é visível ao TAS e ele a pode controlar
10.2.3.2.3. Arquitetura claramente definida, o TAS tem acesso a todos os níveis do SUT
10.2.3.3. Interfaces usadas para testar aplicações ainda não prontas podem ser Planilhas, Mocks, Controladores e Simuladores
10.2.4. Seleção de ferramentas
10.2.4.1. É o TAM que faz isso, com ajuda do TAE
10.2.4.2. O que o TAE faz
10.2.4.2.1. Identifica, analisa e estima
10.2.4.2.2. Recomenda qual é a TAT mais apropriada
10.3. Termos
10.3.1. Quando não há interfaces disponíveis ao usuário (por exemplo, durante a construção de um componente). Criamos interfaces personalizadas, chamamos isso de Ganchos de Teste.
10.3.2. Eficácia é achar o bug certo, eficiência é fazer com pouco esforço
11. Capítulo 3 (21 páginas)
11.1. Mindset
11.1.1. gTAA é uma TAA que tornou-se um modelo que pode ser usada em um ou muitos TAS ;)
11.1.1.1. Define os componentes, conceitos, interfaces e recursos para usuários de um TAS
11.1.1.2. Camadas de um gTAA
11.1.1.2.1. Se essas camadas forem manuais, não necessitamos abordar essas camadas
11.1.1.2.2. Se essas camadas forem automatizadas, então usamos
11.1.2. Um TAS e seu respectivo TAA deve obedecer ao SOLID
11.1.2.1. Responsabilidade única
11.1.2.1.1. Quem loga é um componente diferente do que executa os testes, por exemplo
11.1.2.2. Extensão
11.1.2.2.1. Um componente está aberto a extensão mas fechado à modificação
11.1.2.2.2. Se tenho que tratar 3 arquivos diferentes com IFs, quando tiver um quarto, terei de criar mais um IF. Mas se fizer um laço que leia todos os arquivos existentes, posso adicionar quantos eu quiser, sem mexer no código inicial!
11.1.2.3. Substituição
11.1.2.3.1. Um componente pode ser substituído por outro desde que esse outro tenha o mesmo comportamento
11.1.2.4. Segregação de componentes
11.1.2.4.1. É melhor ter componentes mais específicos do que um componente geral multiuso
11.1.2.5. Inversão de dependência
11.1.2.5.1. Um componente deve depender de abstrações, não de objetos reais
11.1.2.5.2. Construtor espera receber uma interface de um objeto, então posso passar qualquer objeto que implemente aquela interface!
11.1.3. Modelagem do TAA
11.1.3.1. Requisitos de captura necessários para definir um TAA apropriado
11.1.3.1.1. Abordagem de testes
11.1.3.2. Comparar e contrastar diferentes abordagens de projeto / arquitetura
11.1.3.2.1. TAE deve olhar para as camadas do gTAA
11.1.3.3. Identificar áreas onde a abstração pode trazer benefícios
11.1.3.3.1. Permite a independência de fornecedores, facilidade de uso do TAS por não técnicos e etc.
11.1.3.4. Entenda as tecnologias SUT e como elas se interconectam com o TAS
11.1.3.4.1. Paradigmas de interação TAS a SUT, quando em API ou Serviços
11.1.3.5. Compreender o ambiente SUT
11.1.3.5.1. Podem ser softwares ou hardwares, que interagem com usuários, outros softwares ou mesmo com o ambiente.
11.1.3.5.2. TAS deve adaptar-se e simular as condições que validem as saídas do SUT dado uma entrada qualquer
11.1.3.6. Tempo e complexidade para uma determinada implementação de arquitetura de testware
11.1.3.6.1. Estimativa baseada em analogia, como pontos de funções, estimativa de três pontos, Wide Band Delphi e estimativa de testes
11.1.3.6.2. Estimativa pelo uso de estruturas de divisão de trabalho, como as encontradas em software de gerenciamento ou modelos de projeto
11.1.3.6.3. Estimativa paramétrica, como Modelo de Custo Construtivo (COCOMO)
11.1.3.6.4. Estimativas baseadas em tamanho, tais como Análise de Ponto de Função, Análise de Ponto de Estória ou Análise de Caso de Uso
11.1.3.6.5. Estimativas de grupo, como o Planning Poker
11.1.3.7. Facilidade de uso para uma determinada implementação de arquitetura de testware
11.1.3.7.1. Modelagem orientada ao testador
11.1.3.7.2. Facilidade de utilização do TAS
11.1.3.7.3. Suporte do TAS para outras funções no desenvolvimento de software, garantia de qualidade e gerenciamento de projetos
11.1.3.7.4. Organização eficaz, navegação e busca dentro ou com o TAS
11.1.3.7.5. Documentação útil, manuais e texto de ajuda para o TAS
11.1.3.7.6. Relatórios práticos por e sobre o TAS
11.1.3.7.7. Desenhos iterativos para abordar o feedback do TAS e insights empíricos
11.2. Termos
11.2.1. Analistas de Teste
11.2.2. Analisadores de Teste Técnicos
11.2.3. Configuração de teste -> Local e Configuração de teste virtual -> Nuvem
11.3. Atenção total
11.3.1. TAE é quem projeta, desenvolve, implementa e mantém o TAS
11.3.2. gTAA são conceitos, etapas e abordagens recorrentes na automação de testes
11.3.3. Entenda todos os pontos do SOLID
11.3.4. gTAA não predefine nenhum método, tecnologia, ferramenta ou abordagem de desenvolvimento (OO, Estruturada, etc)
11.3.5. Na Execução, considera a possibilidade de injeção de falha no SUT
11.3.6. Geração automática baseada em permutação pura e simples não é recomendada. Use riscos, etc
11.3.7. Tudo ter que ser analisado cuidadosamente, óbvio
11.3.8. SUTs podem ser: - um software - um software autônomo que funciona apenas em relação a outro software - um hardware - um componente ambiental (também hardware)
11.3.8.1. O TAS pode, nesses casos, simular os ambientes dos hardwares ou os usuários dos softwares
11.3.9. Estimativa paramétrica, como COCOMO, é baseado em linhas de código. Possui três formas de medir: básico, intermediário e avançado
11.3.10. Recomendam ter um caso de teste manual e um caso de teste automatizado para aumentar a abstração
11.3.11. Recomendam o uso de ferramentas que geram modelos a partir de scripts automatizados
11.3.12. Validação completa e exata são idênticas, mas a exata tem mais detalhes
11.3.13. Script linear é gravação sem alteração do scripts. Já o estruturado é reutilizável.
11.3.14. No DDT scripts que consomem um arquivo externo é chamado "controle"
11.3.15. Acreditam que os arquivos do DDT permitem omitir os "procedimentos de teste negativos"
11.3.16. Nos testes baseados em palavras-chave os arquivos do DDT são chamados de ‘arquivos de definição de teste'.
11.3.17. Testes baseados em modelo são gerados automaticamente, não são executados automaticamente.
11.3.18. Todas as interfaces precisam ser testáveis
11.3.19. Acreditam que o código do TAA deve ser versionado junto com o do SUT para "seguir o mesmo modelo de revisão"
11.3.20. Acreditam que o TAS precisa ser testado, com testes de capacidade básica (interação entre SUT e TAS)
11.3.21. Os aspetos de reuso são estabelecidos antes do TAA eser definido
11.4. Abordagens para Automação de Testes
11.4.1. Criar sequências de teste
11.4.1.1. Casos de teste diretamente como scripts
11.4.1.1.1. Captura e reprodução pode ser usada aqui
11.4.1.2. Procedimentos posteriormente convertidos em scripts de teste manualmente
11.4.1.2.1. Script de teste estruturado
11.4.1.3. Procedimentos posteriormente convertidos em scripts de teste automaticamente
11.4.1.3.1. Script de teste estruturado
11.4.1.4. Ferramenta gera procedimentos ou extrai scripts de testes a partir de modelos de teste, automaticamente
11.4.1.4.1. Testes baseados em modelos
11.4.1.5. * 1 tem menos e 4 tem mais abstração e automação
11.4.2. Abordagens
11.4.2.1. Abordagem de captura e reprodução
11.4.2.1.1. Ferramentas são usadas para capturar interações com o SUT
11.4.2.1.2. Valida-se os resultados da execução
11.4.2.1.3. Prós e contras
11.4.2.2. Scripts lineares
11.4.2.2.1. Prós e contras
11.4.2.2.2. Não partem de casos de teste, os testers "conhecem" o procedimento. Faço os passos enquanto a ferramenta gerar o script a partir das ações e tira screenshots.
11.4.2.2.3. Ferramentas executam o script gerado
11.4.2.2.4. Posso adicionar verificações como comentários no código ou usar a linguagem de programação pra isso
11.4.2.3. Script estruturado
11.4.2.3.1. Prós e contras
11.4.2.3.2. Em comparação ao script linear, essa tem uma biblioteca de scripts. E seus scripts são reutilizáveis.
11.4.2.4. Teste orientado a dados
11.4.2.4.1. Prós e contras
11.4.2.4.2. Usa um script estruturado, chamado "controle", que consome um arquivo de dados externo e executa o teste "n" vezes, onde "n" é o número de linhas do arquivo.
11.4.2.5. Testes por palavras-chave
11.4.2.5.1. Prós e contras
11.4.2.5.2. Baseia-se na técnica de script orientada a dados.
11.4.2.5.3. Os arquivos são chamados ‘arquivos de definição de teste'.
11.4.2.5.4. Existe apenas um script de controle
11.4.2.5.5. Os arquivos de palavras-chave também conterão instruções de alto nível (as palavras-chave)
11.4.2.5.6. As palavras-chave devem ser escolhidas para serem significativas para o Analista de Testes além de representar interações de negócios de alto nível com um sistema.
11.4.2.5.7. Os analistas de teste podem adicionar testes "automatizados" simplesmente especificando-os em um arquivo de palavras-chave
11.4.2.6. Script direcionado a processo
11.4.2.6.1. Prós e contras
11.4.2.6.2. Representam casos de uso do SUT
11.4.2.6.3. Fluxos de alto-nível
11.4.2.7. Teste baseado em modelo
11.4.2.7.1. Prós e contras
11.4.2.7.2. Geração automática de casos de teste. Não executam eles automaticamente.
11.4.2.7.3. s
11.5. Considerações Técnicas sobre o SUT
11.5.1. Interfaces do SUT
11.5.1.1. Precisam ser testáveis: Observabilidade, Controle e Arquitetura clara
11.5.2. Dados SUT
11.5.2.1. Podem ser de um arquivo de configuração, de um usuário ou de um sistema externo
11.5.2.2. Devem ser configuráveis, para que tenhamos a possibilidade de altera-los e testar melhor
11.5.3. Configurações SUT
11.5.3.1. Pode ser uma configuração de teste ou configuração de teste virtual
11.5.3.2. Também pode-se usar simuladores e/ou emuladores de componentes
11.5.4. Padrões SUT e configurações legais
11.5.4.1. Respeitar os requisitos legais e/ou de normas de modo
11.5.4.2. Exemplo: Requisitos de privacidade para os dados de teste ou requisitos de confidencialidade que afetam as capacidades de log
11.5.5. Ferramentas e ambientes de ferramentas usados para desenvolver o SUT
11.5.5.1. Olhar para ferramentas do SUT e ver se conseguimos compatibilidade/rastreabilidade
11.5.6. Testar interfaces no produto de software
11.5.6.1. Não desabilitar as interfaces de teste, elas podem ajudar no debug de falhas em prod. Cuidado com riscos de segurança relacionados a elas.
11.6. Considerações para processos de desenvolvimento e qualidade
11.6.1. Requisitos de controle e execução -> Teste interativo, a execução do teste em modo batch ou a execução de teste totalmente automatizada
11.6.2. Requisitos de relatório -> Relatórios de teste fixos, parametrizados ou definidos em diferentes formatos e layouts
11.6.3. Papéis e direitos de acesso -> Fornecer um papel e sistema de direitos de acesso
11.6.4. Panorama de ferramenta estabelecida -> Código do TAA deve ser versionado junto com o do SUT
11.7. Desenvolvimento do TAS
11.7.1. Observações
11.7.1.1. Segue o mesmo flow de um prodjeto de desenvolvimento, inclusive com revisões
11.7.1.2. O SUT é afetado pela estratégia de testes, quando precisa ser alterado para testabilidade, por exemplo
11.7.2. Ciclo de Vida do TAS (Baseado no SDCL)
11.7.2.1. Análise
11.7.2.1.1. Requisitos devem ser coletados antes
11.7.2.2. Desenho
11.7.2.3. Desenvolvimento
11.7.2.4. Teste
11.7.2.4.1. Através de testes de capacidade básicos
11.7.2.5. Implantação
11.7.2.6. Evolução
11.7.2.6.1. Adição de testes ou manutenção dos já existentes quando o SUT muda
11.7.3. Compatibilidade TAS/SUT
11.7.3.1. Equipe
11.7.3.1.1. Membros com mesmo mindset e prontos a trabalhar com conjunto
11.7.3.2. Processo
11.7.3.2.1. Processos iguais com sincronização da automação e desenvolvimento do software
11.7.3.3. Tecnologia
11.7.3.3.1. Tecnologias semelhantes ou, quando isso não é possível, o uso de adaptadores, invólucros ou outras formas de intermediários
11.7.3.4. Ferramentas
11.7.3.4.1. Uso das mesmas ferramentas para facilitar a gestão do processo
11.7.4. Sincronização TAS/SUT
11.7.4.1. Requisitos
11.7.4.1.1. Que abordam o desenvolvimento do SUT
11.7.4.1.2. Que abordam os testes do SUT
11.7.4.2. Fases de desenvolvimento
11.7.4.2.1. Para ter o TAS pronto quando necessário para testar o SUT
11.7.4.3. Rastreamento de defeitos
11.7.4.3.1. Pois os defeitos podem estar relacionados
11.7.4.4. Evolução SUT/TAS
11.7.4.4.1. Qualquer alteração aplicada a um SUT ou a um TAS pode afetar o outro
11.7.4.4.2. Abordagens SUT/TAS
11.7.4.4.3. Abordagens SUT/TAS/Testes manuais
11.7.4.5. Reutilização do TAS
11.7.4.5.1. Reaproveitamento de seus artefatos
11.7.4.5.2. Os requisitos para reutilização resultam da relevância dos artefatos TAS para as outras variantes
11.7.4.5.3. Os aspetos de reuso são estabelecidos antes do TAA eser definido
11.7.4.5.4. TAS pode ajudar a aumentar a capacidade de reutilização, por seguir, atualizar, revisar, documentar os artefatos e corrigir falhas
11.7.4.5.5. Reutilização é principalmente uma questão para o TAA
11.7.5. Apoio a outros sistemas-alvo
11.7.5.1. Refere-se à capacidade do TAS para testar diferentes configurações de um produto de software
11.7.5.2. Impactam o TAS em qualquer nível de teste
11.7.5.2.1. Número e interligação de componentes do SUT
11.7.5.2.2. Ambientes (software e hardware) nos quais os componentes do SUT são executados
11.7.5.2.3. Tecnologias, linguagens de programação ou sistemas operacionais utilizados para implementar os componentes do SUT
11.7.5.2.4. Bibliotecas e pacotes que os componentes do SUT estão usando
11.7.5.3. Nível de componente e integração
11.7.5.3.1. Ferramentas usadas para implementar os componentes do SUT
11.7.5.4. A capacidade de um TAS para testar diferentes configurações de produto de software é determinada quando o TAA é definido
11.7.5.5. A manutenção e melhorias para esta variabilidade é uma preocupação de longo prazo no ciclo de vida do TAS
12. Capítulo 8 (4 páginas)
12.1. Opções para melhorar a automação de teste
12.1.1. scripts
12.1.1.1. simples estruturada às abordagens baseadas em dados e às mais sofisticadas orientadas por palavras-chave
12.1.1.2. Isso aumenta a capacidade de manutenção do testware
12.1.1.3. Esperas
12.1.1.3.1. Espera em um hard-coded, fixo
12.1.1.3.2. Espera dinâmica por sondagem, inteligente
12.1.1.3.3. assinar o mecanismo de evento do SUT
12.1.2. verificação
12.1.2.1. adote um conjunto de métodos de verificação padrão para uso em todos os testes automatizados
12.1.3. arquitetura
12.1.3.1. alterar a arquitetura para apoiar melhorias da testabilidade do SUT.
12.1.4. pré e pós-processamento
12.1.4.1. pré- processamento (configuração) e pós-processamento (desmontagem). Isso economiza as tarefas sendo
12.1.5. documentação
12.1.5.1. Recursos não usados devem ser eliminados, os não conhecidos ainda devem seu implementados
12.1.6. suporte a ferramentas
12.1.6.1. Ao atualizar o SUT, execuat en==c==ci
12.1.7. Execução de Teste
12.1.7.1. Quando o teste demora muito tempo, pode ser necessário testar simultaneamente em sistemas diferentes
12.2. Planejando a implementação da melhoria da automação de teste
12.2.1. Identificar alterações nos componentes do ambiente de teste
12.2.2. Aumente a eficiência e a eficácia das bibliotecas de funções principais do TAS
12.2.3. Funções de múltiplos alvos que agem sobre o mesmo tipo de controle para consolidação
12.2.4. Refatorar o TAA para acomodar mudanças no SUT
12.2.5. Convenções de nomenclatura e padronização
12.2.6. Avaliação de scripts existentes para revisão ou eliminação de SUT
12.3. Termos
12.4. Atenção total
13. Capítulo 7 (3 páginas)
13.1. Verificando componentes automatizados do ambiente de teste
13.1.1. Verificar se o ambiente de teste automatizado está funcionando como esperado
13.1.2. Por exemplo, antes de iniciar os testes automatizados
13.1.3. Etapas
13.1.3.1. Instalação, configuração, adequação e personalização da ferramenta de teste
13.1.3.1.1. Cada um dos componentes do TAS precisa ser contabilizado para garantir desempenho confiável e repetitivo
13.1.3.1.2. No núcleo de um TAS estão
13.1.3.1.3. O uso do repositório (Git, por exemplo) e o processo para atualizar para uma nova versão do TAS devem ser os mesmos que para as ferramentas de desenvolvimento padrão
13.1.3.2. Testar scripts com aprovações e reprovações conhecidas
13.1.3.2.1. É importante verificar a geração correta de arquivos de log e métricas de desempenho, bem como a configuração e desmontagem automatizada do caso ou script de teste.
13.1.3.2.2. Também é útil executar alguns testes dos diferentes tipos e níveis de teste (testes funcionais, testes de desempenho, testes de componentes, etc.).
13.1.3.2.3. Isso também deve ser realizado no nível da estrutura.
13.1.3.3. Repetibilidade na configuração ou desmontagem do ambiente de teste
13.1.3.3.1. Para garantir que o TAS funcione adequadamente em cada ambiente, é necessário ter uma abordagem sistemática para carregar e descarregar o TAS de qualquer ambiente
13.1.3.3.2. O gerenciamento de configuração dos componentes do TAS garante que uma determinada configuração pode ser criada de forma confiável.
13.1.3.4. Configuração do ambiente de teste e componentes
13.1.3.5. Conectividade contra sistemas ou interfaces internas e externos
13.1.3.5.1. verificações ou pré-condições para garantir que a conectividade com sistemas internos e externos, interfaces, etc
13.1.3.6. Nível de intrusão de ferramentas de teste automatizadas
13.1.3.6.1. Para maior compatibilidade, colocamos componentes dentro do SUT, isso é intrusão. Alta intrusão é quando os componentes influenciam na performance do SUT.
13.1.3.6.2. Tipos
13.2. Termos
13.3. Atenção Total
13.3.1. O TAS muitas vezes será fortemente acoplado com o SUT
13.4. Testar todos os componentes funcional e não funcionalmente
13.4.1. Compreensão da degradação do desempenho da estrutura
13.4.2. A utilização de recursos do sistema que podem indicar problemas como vazamentos de memória
13.4.3. Interoperabilidade dos componentes dentro ou fora do quadro
13.5. Verificando o Conjunto de Testes Automatizado
13.5.1. Testar quanto à integridade, consistência e comportamento correto
13.5.2. Etapas
13.5.2.1. Executar scripts de teste com aprovações e reprovações conhecidas
13.5.2.2. Verificar a suíte de testes
13.5.2.2.1. Valide a versão e configuração do SUT
13.5.2.3. Verificar novos testes que se concentram em novos recursos do framework
13.5.2.3.1. Monitorar para ver que realmente funciona
13.5.2.4. Considerar a repetibilidade dos testes
13.5.2.4.1. Ao repetir testes, o resultado ou veredito do teste deve ser sempre o mesmo
13.5.2.4.2. Condições de corrida não considerados testes que não dão um resultado confiável
13.5.2.4.3. Problemas podem estar no caso de testes, na estrutura ou até no SUT
13.5.2.5. Avaliar se há pontos de verificação suficientes no conjunto de testes automatizado ou casos de teste.
13.5.2.6. Avaliar se há pontos de verificação suficientes
13.5.2.6.1. A evidência pode incluir registro no início e no final de cada caso de teste, registrando o status de execução de teste para cada caso de teste concluído, verificação de que as condições de pós foram alcançadas, etc
14. Capítulo 6 (9 páginas)
14.1. Critério para automação
14.2. Implementar a automação em testes de regressão
14.3. Fatores a serem considerados ao implementar a automação no teste de novos recursos
14.3.1. É mais fácil automatizar novas features
14.3.2. Nenhuma funcionalidade do TAS deve influenciar negativamente o Testware existente
14.3.3. O TAS existente continuará a atender às necessidades atuais do SUT após as mudanças?
14.3.4. As novas funcionalidades do SUT serão testáveis? Pois precisam ser!
14.4. Fatores a considerar testando ao implementar automação de confirmação
14.4.1. Testes de confirmação são candidatos a automação como complementares, podem ser implementados a qualquer momento
14.4.2. Podem ser implementados como novos testes ou como parte de testes antigos
14.4.3. O rastreamento de testes de confirmação automatizados permite relatórios adicionais de tempo e número de ciclos gastos na resolução de defeitos.
14.4.4. A análise de impacto pode ser necessária para determinar o escopo apropriado dos testes de regressão
14.5. Identificar etapas necessárias para implementar a automação em testes de regressão
14.5.1. Suíte de teste de regressão cresce à medida que os testes funcionais de hoje se tornam testes de regressão de amanhã
14.5.2. Perguntas ao começar a automação de testes de regressão
14.5.2.1. Com que frequência os testes devem ser executados?
14.5.2.1.1. A mesma dos testes regressivos manuais
14.5.2.2. Qual é o tempo de execução para cada teste para o conjunto de regressão?
14.5.2.2.1. Começar implementando a automação em testes mais demorados, assim cada teste seja executado de forma mais rápida e eficiente
14.5.2.3. Há sobreposição funcional entre os testes?
14.5.2.3.1. Um teste automatizado equivale a vários manuais agrupados
14.5.2.4. Os testes compartilham dados?
14.5.2.4.1. Sim, para não duplicar dados. Os testes devem avaliar perspectivas diferentes, óbvio.
14.5.2.5. Os testes são dependentes um do outro?
14.5.2.5.1. Sim
14.5.2.6. Que pré-condições são necessárias antes da execução do teste?
14.5.2.6.1. Sim, precisam fazer parte do processo de automação
14.5.2.7. Qual a percentagem de cobertura do SUT que os testes representam?
14.5.2.7.1. O máximo que conseguir. Ampliamos a cobertura dos unitários e de integração
14.5.2.8. Os testes são executados atualmente sem falha?
14.5.2.8.1. Antes de automatizar, teste para ver se os testes passam
14.5.2.9. O que deve acontecer quando os testes de regressão demorarem muito?
14.5.2.9.1. Faça a execução simultânea de casos de teste
14.6. ROI
14.6.1. Disponibilidade de ferramentas no ambiente de teste para automação de teste
14.6.2. Correção de dados de teste e casos de teste
14.6.3. Escopo do esforço de automação de teste
14.6.4. Educação da equipe de teste para a mudança de paradigma
14.6.5. Papéis e responsabilidades
14.6.6. Cooperação entre desenvolvedores e engenheiros de automação de testes
14.6.7. Esforço paralelo
14.6.8. Relatório de automação de testes
14.7. Atenção total
14.7.1. Não deixe o Testware existente quebrar!
14.7.2. Qualquer mudança exige análise de impacto nos Testwares existentes
14.7.3. Eles acham normal dependência entre casos de teste
14.7.4. Nem todos os testes podem ou devem ser automatizados
14.7.5. A automação não é recomendada para um sistema próximo ao fim de seu ciclo de vida, pois haverá pouco valor na realização de uma iniciativa de tão curta duração.
15. Capítulo 5 (7 páginas)
15.1. Mindset
15.1.1. Métricas do TAS são separadas das métricas de teste do SUT (para testes funcionais e não funcionais)
15.1.2. Métricas de teste do SUT são coletadas pelo TAM
15.1.3. Tipos de Métricas
15.1.3.1. Internas: eficácia e eficiência do TAS em seus objetivos. Defeitos, complexidade e desempenho dos scripts de teste
15.1.3.1.1. Métricas de script de ferramenta
15.1.3.1.2. Densidade de defeitos de código de automação
15.1.3.1.3. Velocidade e eficiência dos componentes TAS
15.1.3.2. Externas: impacto do TAS nas atividades de teste
15.1.3.2.1. Benefícios de automação
15.1.3.2.2. Esforço para construir testes automatizados
15.1.3.2.3. Esforço para analisar incidentes de teste automatizados
15.1.3.2.4. Esforço para manter testes automatizados
15.1.3.2.5. Relação entre falhas e defeitos
15.1.3.2.6. Tempo para executar testes automatizados
15.1.3.2.7. Número de casos de teste automatizados
15.1.3.2.8. Número de resultados de aprovação e falha
15.1.3.2.9. Número de falhas falsas e resultados de falso-passe
15.1.3.2.10. Cobertura de código
15.2. Implementação da Medição
15.2.1. Onde a abstração é combinada com testware estruturado, quaisquer aprimoramentos feitos subjacentes a ele podem ser utilizados por todos os scripts de teste automatizados de nível mais alto
15.2.2. Recursos de automação que suportam medição e geração de relatórios
15.2.2.1. Precisa ter um recurso de análise para levar em conta os resultados dos testes anteriores, para que ele possa destacar tendências
15.2.3. Integração com outras ferramentas de terceiros
15.2.3.1. Informações da execução de casos de teste automatizados são usadas em outras ferramentas podemos prover informações em formatos conhecidos pelas ferramentas
15.2.4. Visualização de resultados
15.2.4.1. Faze-los de forma gráfica, para gestão
15.3. Registro do TAS e do SUT
15.3.1. Os logs de teste são uma fonte que são frequentemente usados para analisar problemas potenciais
15.3.2. O que é importante ter no log?
15.3.2.1. Qual caso de testes está executando?
15.3.2.2. Passou ou Falhou?
15.3.2.3. Logs em alto nível (tempo)
15.3.2.4. O SUT quebrou? O que ocorreu?
15.3.2.5. Quantos vezes os casos de teste foram executados em testes não funcionais?
15.3.2.6. Se forem entradas aleatórias, registras o grupo de parâmetros usados em cada teste
15.3.2.7. Registrar todos os passos com evidências
15.3.2.8. Usar cores para sucesso, alerta ou falha
15.3.2.9. O log do SUT deve ter logs bem descritivos, logar interações do cliente e também registro da configuração do ambiente
15.4. Relatório de Automação de Testes
15.4.1. Deve ter
15.4.1.1. Visão geral dos resultados da execução, do sistema que está sendo testado e do ambiente em que os testes foram executados
15.4.1.2. Quais testes falharam e as razões para a falha
15.4.1.3. Responsável pelo teste
15.4.2. Também são usados para diagnosticar falhas dos componentes do TAF
15.4.3. Devem ser publicados (em ferramentas, sites, listas, e-mails, etc) para todos os interessados nos resultados da execução
15.4.4. Se tiverem fácil acesso, serão visualizados, entendeu?
15.5. Atenção total
15.5.1. Analisar falhas da execução de testes automatizados pode ser mais complexo do que para um teste executado manualmente
15.5.2. O esforço de manutenção pode superar os benefícios obtidos pelo TAS, isso é um dos motivos de projetos falhos
15.5.3. O código de automação pode ter defeitos
15.5.4. Sobre métricas, as tendências (ou seja, a forma como as medidas mudam ao longo do tempo) que podem ser as mais valiosas
15.5.5. verificação do teste é obtida pela comparação de elementos específicos do resultado do teste com um resultado esperado predefinido
15.6. Termos
15.6.1. Defeitos de fiabilidade são aqueles que nunca seriam encontrados nos testes manuais
15.6.2. EMTE esforço de teste manual equivalente
15.6.3. Buffers cíclicos são frequentemente usados para arquivos de log no SUT, quebrar o log em pequenas partes
16. Capítulo 4 (7 páginas)
16.1. Implantação do TAS
16.1.1. Piloto
16.1.1.1. Preciso identificar um projeto adequado, planejar a forma com que o piloto será executado, conduzi-lo e avaliar os resultados
16.1.1.1.1. Quando os resultados são avaliados, já podemos implantar!
16.1.1.2. * garantir que o TAS alcance benefícios planejados
16.1.1.3. Objetivos
16.1.1.3.1. Mais detalhes do TAS, aderência ao contexto, encontrar padrões, definir métricas para monitoramento, avaliar benefícios e identificar as habilidades necessárias
16.1.1.4. Dicas
16.1.1.4.1. Envolva a gestão (de modo que se comprometam) e faça com que o projeto piloto seja referência para outros projetos
16.1.1.4.2. Envolva na implantação todos os que participaram da construção do TAS
16.1.2. Implantação
16.1.2.1. Identificar os projetos iniciais (pois não posso implantar o piloto em todos), depois implantar, monitorar e avaliar o TAS. Implementar nos demais projetos.
16.1.2.2. Tipos
16.1.2.2.1. Incremental, por etapas (ou ondas)
16.1.2.2.2. Adaptação e aperfeiçoamento dos processos
16.1.2.2.3. Fornecimento de treinamento, coaching e mentoring
16.1.2.2.4. Diretrizes, listas de verificação e FAQs
16.1.2.2.5. Deve haver uma maneira automatizada de coletar informações sobre o uso real do TAS. Não só o uso em si, mas também quais partes do TAS (certas funcionalidades) estão sendo utilizadas
16.1.2.2.6. Monitorar o uso do TAS e ver se é realmente usado. Usadas para recalcular o business case
16.1.2.2.7. Realizar reuniões de avaliação e retrospectiva com as diferentes equipes que utilizam o TAS, para melhorar
16.1.2.2.8. Melhorias são identificadas e implementadas com base no feedback da equipe e na monitoração do TAS
16.1.2.3. Um novo TAS ou uma nova versão é implantado no início do projeto ou ao atingir um marco
16.1.2.3.1. Para mitigar o risco do TAS não funcionar e interromper os processos
16.1.2.3.2. Se o TAS tiver de ser corrigido/alterado, a implantação será feita independentemente da fase de desenvolvimento do SUT
16.1.2.4. Modos
16.1.2.4.1. Implementação inicial
16.1.2.4.2. Implementação de manutenção
16.1.3. Manutenção da Automação
16.1.3.1. Tipos de manutenção
16.1.3.1.1. Preventiva
16.1.3.1.2. Corretiva
16.1.3.1.3. Perfeita
16.1.3.1.4. Adaptativa
16.1.3.2. Escolha e abordagem
16.1.3.2.1. Depende da complexidade do TAS, tamanho e risco da mudança
16.1.3.2.2. No TAS, tudo tem de ser documentado, scripts modularizados, componentizados, portáveis, geridos pela confirguação.
16.1.3.2.3. Considerações
16.1.3.3. * pode afetar todas as camadas e componentes de um TAS. Logo, ANÁLISE DE IMPACTO neles!
16.2. Riscos
16.2.1. Técnicos
16.2.1.1. Não seja abstrato demais
16.2.1.2. Dados complexos demais
16.2.1.3. Dependência de libs e componentes
16.2.2. Implantação
16.2.2.1. Pessoas certas para a coisa certa
16.2.2.2. SUT alterado
16.2.2.3. Atrasos
16.2.2.4. Observabilidade
16.2.3. Projeto
16.2.3.1. Migração para um ambiente diferente
16.2.3.2. Implantação no ambiente destino
16.2.3.3. Novas entregas do SUT
16.3. Atenção total
16.3.1. O TAS se adequa ao contexto, não o contrário
16.3.2. Não selecione um projeto crítico como piloto, mas também, não escolha um trivial
16.3.3. TAS bom é aquele alinhado o com o contexto e que funcione como planejado
16.3.4. Treinamento e workshops devem ser fornecidos aos usuários antes que eles realmente usem o TAS
16.3.5. TAS precisam ser precisam ser modulares, escaláveis, compreensíveis, confiáveis e testáveis.
16.3.6. Eficiência do tempo é o principal fator que contribui para o sucesso da automação de testes
16.3.7. Quanto a documentação, alguém a escreve e outro a mantém
16.3.8. Apenas o código da ferramenta de teste pode ser documentado automaticamente, os demais são feitos manualmente
16.4. Termos
16.4.1. Um marco pode ser o congelamento de código ou o fim de um sprint
16.4.2. Manutenção refere-se ao TAS em operação