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. Atenção total
3.1. Execução automatizada é apenas uma parte da automação de testes
3.2. Comparar resultados, controlar e configurar pré-condições de teste
3.3. Testes de API são testes em código, não de serviços!
3.4. Adoram siglas!
3.5. Testabilidade é o sucesso do projeto
3.6. Em sistemas embutidos, não preciso separar automação de testes do SUT
3.6.1. Dizem que nem todos os fatores de sucesso são necessários
3.7. Na estratégia de testes, olhe pra GUI e API para validar consistência dos resultados
3.8. Consideram viável começar a automação pequena e simples, mesmo para SUTs grandes e complexos
4. Extras
4.1. Falhas de tradução
4.1.1. 1.1. Não fica claro se devo ou não separar o software de teste do SUT
4.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
4.1.3. 1.2. Rastrar o teste automatizado
4.1.4. 3.2.1. Requisitos de captura necessários para definir um TAA apropriado deveria ser ˜Capturar os requisitos"
4.2. Erros em figuras
4.2.1. Figura 1. Automação de Este ao invés de Geração de Teste
5. Siglas
5.1. SUT é o sistema em teste, ou seja, aquele que estou testando
5.2. TAS é solução de automação de testes
5.3. TAA é arquitetura de automação de testes
5.4. TAE é o engenheiro de automação de testes
5.5. TAF framework de automação de testes
5.6. TAM é o gerente de automação de testes
5.7. gTAA é a arquitetura genérica de automação de testes
5.8. SDLC é o ciclo de desenvolvimento de software
6. Mnemônicos
7. Capítulo 1 (4 páginas)
7.1. Mindset
7.1.1. Testware é usado em todo o ciclo de automação de testes. Ele é mais do que apenas scripts de teste, incluem...
7.1.1.1. Documentação
7.1.1.2. Ambientes
7.1.1.3. Software
7.1.1.4. Dados de teste
7.1.1.5. Software
7.1.2. Um TAF legal possui
7.1.2.1. Facilidade de identificar o motivo da falha, ou seja, facilitar a solução de problemas
7.1.2.1.1. A causa pode ser
7.1.2.2. Relatórios
7.1.2.3. Abordar corretamente o ambiente de testes, ou seja, controle total dele
7.1.2.4. Documentar os casos de teste automatizados, ou seja, o que e como estamos automatizando
7.1.2.5. Fácil de rastrear os casos de teste e métodos
7.1.2.6. Manutenibilidade
7.1.2.7. Casos de testes constantemente atualizados
7.1.2.8. Fáceis de implementar, retirar (quando não forem mais úteis) e alterar
7.1.2.9. Recuperar-se quando uma falha ocorrer e pular pro próximo teste
7.1.3. Objetivos, vantagens e desvantagens
7.1.3.1. Objetivos da Automação: - Custo, - tempo, + frequência, + eficiência, + cobertura e + testes impossíveis de se fazer manualmente
7.1.3.1.1. Tempo real, paralelo e remotos são considerados impossíveis de se fazer manualmente
7.1.3.2. Vantagens da Automação: + Complexidade dos testes, - erros humanos, feedback rápido, + confiança no sistema
7.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
7.1.4. Fatores de sucesso a longo prazo
7.1.4.1. TAA
7.1.4.1.1. Alinhada com a arquitetura do produto
7.1.4.1.2. Definir requisitos funcionais e não funcionais é o mais importante
7.1.4.1.3. Preza por manutenibilidade
7.1.4.2. Testabilidade
7.1.4.2.1. Desacoplar dados da GUI nos testes de GUI
7.1.4.2.2. Métodos públicos nos testes de API
7.1.4.2.3. Devo começar a automatizar a partir dos componentes com maior testabilidade
7.1.4.2.4. É a chave para o sucesso
7.1.4.2.5. * Requisito não-funcional
7.1.4.3. * Antes do início do projeto, analise todos eles. Isso mostrará as chances de sucesso do projeto.
7.1.5. Estratégia de testes
7.1.5.1. Manutenção e consistência do SUT
7.1.5.2. Devo considerar os custos, benefícios e riscos
7.1.6. Conceitos comuns
7.1.6.1. Há mais que execução automatizada na automação de testes
7.1.6.2. Nem tudo pode ser automatizado
7.1.6.3. Scripts de teste não fazem testes exploratórios
7.1.6.4. Podemos ter tanto código no TAF quanto no SUT
7.1.6.5. Bad smells
7.1.6.5.1. Testes sensíveis a mudança de layout
7.1.6.5.2. Testes sensíveis a alteração de dados criados por outros testes, dependência entre testes
7.1.6.5.3. Testes sensíveis a informações do ambiente, como hora, localicação e etc. Use simuladores, mano!
7.2. Termos
7.2.1. Abordagens de teste
7.2.1.1. Interface pública de código (classe, libs, etc)
7.2.1.2. interface de usuário (GUI, CLI)
7.2.1.3. serviços ou protocolos
8. Capítulo 8 (4 páginas)
8.1. Opções para melhorar a automação de teste
8.1.1. scripts
8.1.1.1. simples estruturada às abordagens baseadas em dados e às mais sofisticadas orientadas por palavras-chave
8.1.1.2. Isso aumenta a capacidade de manutenção do testware
8.1.1.3. Esperas
8.1.1.3.1. Espera em um hard-coded, fixo
8.1.1.3.2. Espera dinâmica por sondagem, inteligente
8.1.1.3.3. assinar o mecanismo de evento do SUT
8.1.2. verificação
8.1.2.1. adote um conjunto de métodos de verificação padrão para uso em todos os testes automatizados
8.1.3. arquitetura
8.1.3.1. alterar a arquitetura para apoiar melhorias da testabilidade do SUT.
8.1.4. pré e pós-processamento
8.1.4.1. pré- processamento (configuração) e pós-processamento (desmontagem). Isso economiza as tarefas sendo
8.1.5. documentação
8.1.5.1. Recursos não usados devem ser eliminados, os não conhecidos ainda devem seu implementados
8.1.6. suporte a ferramentas
8.1.6.1. Ao atualizar o SUT, execuat en==c==ci
8.1.7. Execução de Teste
8.1.7.1. Quando o teste demora muito tempo, pode ser necessário testar simultaneamente em sistemas diferentes
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. Refatorar o TAA para acomodar mudanças no SUT
8.2.5. Convenções de nomenclatura e padronização
8.2.6. Avaliação de scripts existentes para revisão ou eliminação de SUT
8.3. Termos
8.4. Atenção total
9. Capítulo 7 (3 páginas)
9.1. Verificando componentes automatizados do ambiente de teste
9.1.1. Verificar se o ambiente de teste automatizado está funcionando como esperado
9.1.2. Por exemplo, antes de iniciar os testes automatizados
9.1.3. Etapas
9.1.3.1. Instalação, configuração, adequação e personalização da ferramenta de teste
9.1.3.1.1. Cada um dos componentes do TAS precisa ser contabilizado para garantir desempenho confiável e repetitivo
9.1.3.1.2. No núcleo de um TAS estão
9.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
9.1.3.2. Testar scripts com aprovações e reprovações conhecidas
9.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.
9.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.).
9.1.3.2.3. Isso também deve ser realizado no nível da estrutura.
9.1.3.3. Repetibilidade na configuração ou desmontagem do ambiente de teste
9.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
9.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.
9.1.3.4. Configuração do ambiente de teste e componentes
9.1.3.5. Conectividade contra sistemas ou interfaces internas e externos
9.1.3.5.1. verificações ou pré-condições para garantir que a conectividade com sistemas internos e externos, interfaces, etc
9.1.3.6. Nível de intrusão de ferramentas de teste automatizadas
9.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.
9.1.3.6.2. Tipos
9.2. Termos
9.3. Atenção Total
9.3.1. O TAS muitas vezes será fortemente acoplado com o SUT
9.4. Testar todos os componentes funcional e não funcionalmente
9.4.1. Compreensão da degradação do desempenho da estrutura
9.4.2. A utilização de recursos do sistema que podem indicar problemas como vazamentos de memória
9.4.3. Interoperabilidade dos componentes dentro ou fora do quadro
9.5. Verificando o Conjunto de Testes Automatizado
9.5.1. Testar quanto à integridade, consistência e comportamento correto
9.5.2. Etapas
9.5.2.1. Executar scripts de teste com aprovações e reprovações conhecidas
9.5.2.2. Verificar a suíte de testes
9.5.2.2.1. Valide a versão e configuração do SUT
9.5.2.3. Verificar novos testes que se concentram em novos recursos do framework
9.5.2.3.1. Monitorar para ver que realmente funciona
9.5.2.4. Considerar a repetibilidade dos testes
9.5.2.4.1. Ao repetir testes, o resultado ou veredito do teste deve ser sempre o mesmo
9.5.2.4.2. Condições de corrida não considerados testes que não dão um resultado confiável
9.5.2.4.3. Problemas podem estar no caso de testes, na estrutura ou até no SUT
9.5.2.5. Avaliar se há pontos de verificação suficientes no conjunto de testes automatizado ou casos de teste.
9.5.2.6. Avaliar se há pontos de verificação suficientes
9.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
10. Capítulo 6 (9 páginas)
10.1. Critério para automação
10.2. Implementar a automação em testes de regressão
10.3. Fatores a serem considerados ao implementar a automação no teste de novos recursos
10.3.1. É mais fácil automatizar novas features
10.3.2. Nenhuma funcionalidade do TAS deve influenciar negativamente o Testware existente
10.3.3. O TAS existente continuará a atender às necessidades atuais do SUT após as mudanças?
10.3.4. As novas funcionalidades do SUT serão testáveis? Pois precisam ser!
10.4. Fatores a considerar testando ao implementar automação de confirmação
10.4.1. Testes de confirmação são candidatos a automação como complementares, podem ser implementados a qualquer momento
10.4.2. Podem ser implementados como novos testes ou como parte de testes antigos
10.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.
10.4.4. A análise de impacto pode ser necessária para determinar o escopo apropriado dos testes de regressão
10.5. Identificar etapas necessárias para implementar a automação em testes de regressão
10.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ã
10.5.2. Perguntas ao começar a automação de testes de regressão
10.5.2.1. Com que frequência os testes devem ser executados?
10.5.2.1.1. A mesma dos testes regressivos manuais
10.5.2.2. Qual é o tempo de execução para cada teste para o conjunto de regressão?
10.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
10.5.2.3. Há sobreposição funcional entre os testes?
10.5.2.3.1. Um teste automatizado equivale a vários manuais agrupados
10.5.2.4. Os testes compartilham dados?
10.5.2.4.1. Sim, para não duplicar dados. Os testes devem avaliar perspectivas diferentes, óbvio.
10.5.2.5. Os testes são dependentes um do outro?
10.5.2.5.1. Sim
10.5.2.6. Que pré-condições são necessárias antes da execução do teste?
10.5.2.6.1. Sim, precisam fazer parte do processo de automação
10.5.2.7. Qual a percentagem de cobertura do SUT que os testes representam?
10.5.2.7.1. O máximo que conseguir. Ampliamos a cobertura dos unitários e de integração
10.5.2.8. Os testes são executados atualmente sem falha?
10.5.2.8.1. Antes de automatizar, teste para ver se os testes passam
10.5.2.9. O que deve acontecer quando os testes de regressão demorarem muito?
10.5.2.9.1. Faça a execução simultânea de casos de teste
10.6. ROI
10.6.1. Disponibilidade de ferramentas no ambiente de teste para automação de teste
10.6.2. Correção de dados de teste e casos de teste
10.6.3. Escopo do esforço de automação de teste
10.6.4. Educação da equipe de teste para a mudança de paradigma
10.6.5. Papéis e responsabilidades
10.6.6. Cooperação entre desenvolvedores e engenheiros de automação de testes
10.6.7. Esforço paralelo
10.6.8. Relatório de automação de testes
10.7. Atenção total
10.7.1. Não deixe o Testware existente quebrar!
10.7.2. Qualquer mudança exige análise de impacto nos Testwares existentes
10.7.3. Eles acham normal dependência entre casos de teste
10.7.4. Nem todos os testes podem ou devem ser automatizados
10.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.
11. Capítulo 5 (7 páginas)
11.1. Mindset
11.1.1. Métricas do TAS são separadas das métricas de teste do SUT (para testes funcionais e não funcionais)
11.1.2. Métricas de teste do SUT são coletadas pelo TAM
11.1.3. Tipos de Métricas
11.1.3.1. Internas: eficácia e eficiência do TAS em seus objetivos. Defeitos, complexidade e desempenho dos scripts de teste
11.1.3.1.1. Métricas de script de ferramenta
11.1.3.1.2. Densidade de defeitos de código de automação
11.1.3.1.3. Velocidade e eficiência dos componentes TAS
11.1.3.2. Externas: impacto do TAS nas atividades de teste
11.1.3.2.1. Benefícios de automação
11.1.3.2.2. Esforço para construir testes automatizados
11.1.3.2.3. Esforço para analisar incidentes de teste automatizados
11.1.3.2.4. Esforço para manter testes automatizados
11.1.3.2.5. Relação entre falhas e defeitos
11.1.3.2.6. Tempo para executar testes automatizados
11.1.3.2.7. Número de casos de teste automatizados
11.1.3.2.8. Número de resultados de aprovação e falha
11.1.3.2.9. Número de falhas falsas e resultados de falso-passe
11.1.3.2.10. Cobertura de código
11.2. Implementação da Medição
11.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
11.2.2. Recursos de automação que suportam medição e geração de relatórios
11.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
11.2.3. Integração com outras ferramentas de terceiros
11.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
11.2.4. Visualização de resultados
11.2.4.1. Faze-los de forma gráfica, para gestão
11.3. Registro do TAS e do SUT
11.3.1. Os logs de teste são uma fonte que são frequentemente usados para analisar problemas potenciais
11.3.2. O que é importante ter no log?
11.3.2.1. Qual caso de testes está executando?
11.3.2.2. Passou ou Falhou?
11.3.2.3. Logs em alto nível (tempo)
11.3.2.4. O SUT quebrou? O que ocorreu?
11.3.2.5. Quantos vezes os casos de teste foram executados em testes não funcionais?
11.3.2.6. Se forem entradas aleatórias, registras o grupo de parâmetros usados em cada teste
11.3.2.7. Registrar todos os passos com evidências
11.3.2.8. Usar cores para sucesso, alerta ou falha
11.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
11.4. Relatório de Automação de Testes
11.4.1. Deve ter
11.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
11.4.1.2. Quais testes falharam e as razões para a falha
11.4.1.3. Responsável pelo teste
11.4.2. Também são usados para diagnosticar falhas dos componentes do TAF
11.4.3. Devem ser publicados (em ferramentas, sites, listas, e-mails, etc) para todos os interessados nos resultados da execução
11.4.4. Se tiverem fácil acesso, serão visualizados, entendeu?
11.5. Atenção total
11.5.1. Analisar falhas da execução de testes automatizados pode ser mais complexo do que para um teste executado manualmente
11.5.2. O esforço de manutenção pode superar os benefícios obtidos pelo TAS, isso é um dos motivos de projetos falhos
11.5.3. O código de automação pode ter defeitos
11.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
11.5.5. verificação do teste é obtida pela comparação de elementos específicos do resultado do teste com um resultado esperado predefinido
11.6. Termos
11.6.1. Defeitos de fiabilidade são aqueles que nunca seriam encontrados nos testes manuais
11.6.2. EMTE esforço de teste manual equivalente
11.6.3. Buffers cíclicos são frequentemente usados para arquivos de log no SUT, quebrar o log em pequenas partes
12. Capítulo 4 (7 páginas)
12.1. Implantação do TAS
12.1.1. Piloto
12.1.1.1. Preciso identificar um projeto adequado, planejar a forma com que o piloto será executado, conduzi-lo e avaliar os resultados
12.1.1.1.1. Quando os resultados são avaliados, já podemos implantar!
12.1.1.2. * garantir que o TAS alcance benefícios planejados
12.1.1.3. Objetivos
12.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
12.1.1.4. Dicas
12.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
12.1.1.4.2. Envolva na implantação todos os que participaram da construção do TAS
12.1.2. Implantação
12.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.
12.1.2.2. Tipos
12.1.2.2.1. Incremental, por etapas (ou ondas)
12.1.2.2.2. Adaptação e aperfeiçoamento dos processos
12.1.2.2.3. Fornecimento de treinamento, coaching e mentoring
12.1.2.2.4. Diretrizes, listas de verificação e FAQs
12.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
12.1.2.2.6. Monitorar o uso do TAS e ver se é realmente usado. Usadas para recalcular o business case
12.1.2.2.7. Realizar reuniões de avaliação e retrospectiva com as diferentes equipes que utilizam o TAS, para melhorar
12.1.2.2.8. Melhorias são identificadas e implementadas com base no feedback da equipe e na monitoração do TAS
12.1.2.3. Um novo TAS ou uma nova versão é implantado no início do projeto ou ao atingir um marco
12.1.2.3.1. Para mitigar o risco do TAS não funcionar e interromper os processos
12.1.2.3.2. Se o TAS tiver de ser corrigido/alterado, a implantação será feita independentemente da fase de desenvolvimento do SUT
12.1.2.4. Modos
12.1.2.4.1. Implementação inicial
12.1.2.4.2. Implementação de manutenção
12.1.3. Manutenção da Automação
12.1.3.1. Tipos de manutenção
12.1.3.1.1. Preventiva
12.1.3.1.2. Corretiva
12.1.3.1.3. Perfeita
12.1.3.1.4. Adaptativa
12.1.3.2. Escolha e abordagem
12.1.3.2.1. Depende da complexidade do TAS, tamanho e risco da mudança
12.1.3.2.2. No TAS, tudo tem de ser documentado, scripts modularizados, componentizados, portáveis, geridos pela confirguação.
12.1.3.2.3. Considerações
12.1.3.3. * pode afetar todas as camadas e componentes de um TAS. Logo, ANÁLISE DE IMPACTO neles!
12.2. Riscos
12.2.1. Técnicos
12.2.1.1. Não seja abstrato demais
12.2.1.2. Dados complexos demais
12.2.1.3. Dependência de libs e componentes
12.2.2. Implantação
12.2.2.1. Pessoas certas para a coisa certa
12.2.2.2. SUT alterado
12.2.2.3. Atrasos
12.2.2.4. Observabilidade
12.2.3. Projeto
12.2.3.1. Migração para um ambiente diferente
12.2.3.2. Implantação no ambiente destino
12.2.3.3. Novas entregas do SUT
12.3. Atenção total
12.3.1. O TAS se adequa ao contexto, não o contrário
12.3.2. Não selecione um projeto crítico como piloto, mas também, não escolha um trivial
12.3.3. TAS bom é aquele alinhado o com o contexto e que funcione como planejado
12.3.4. Treinamento e workshops devem ser fornecidos aos usuários antes que eles realmente usem o TAS
12.3.5. TAS precisam ser precisam ser modulares, escaláveis, compreensíveis, confiáveis e testáveis.
12.3.6. Eficiência do tempo é o principal fator que contribui para o sucesso da automação de testes
12.3.7. Quanto a documentação, alguém a escreve e outro a mantém
12.3.8. Apenas o código da ferramenta de teste pode ser documentado automaticamente, os demais são feitos manualmente
12.4. Termos
12.4.1. Um marco pode ser o congelamento de código ou o fim de um sprint
12.4.2. Manutenção refere-se ao TAS em operação
13. É esperado de um TAE
13.1. Conhecer padrões de codificação, documentação e melhores práticas
13.1.1. Regras AUTOSAR para MathWorks Matlab / Simulink®
13.1.1.1. Arquitetura para Sistemas Automotivos Abertos. Descreve módulos básicos e uma metodologia de desenvolvimento
13.1.2. MISRA para C ou C++
13.1.2.1. Facilitar a portabilidade e a confiabilidade de código no contexto de sistemas embarcados
13.1.3. Padrão de codificação JSF para C ++
13.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
13.1.3.2. * Joint Strike Fighters
13.2. Que tenha habilidades, experiências e especializações em engenharia de software
13.3. Entenda o ciclo de vida de desenvolvimento do software
13.4. Projetar um TAS onde informações possam ser extraídas facilmente ou automaticamente relatadas ao gerenciamento de projetos
13.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
13.6. TAE precisa apoiar um TAM nas estimativas, fornecendo boas estimativas para o tempo e a complexidade de um projeto TAA
13.7. abordar questões de usabilidade para um TAS
13.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
14. Dicas de brother
14.1. Quando não entender algo no Syllabus, olhe para a versão americana dele
14.2. Saiba diferenciar: TAS, TAF, TAA e gTAA
14.2.1. TAS é o ambiente de testes e os scripts
14.2.2. TAF é usado para criar um TAS
14.2.3. TAA refere-se a forma com que o TAS foi organizado
14.2.4. gTAA é um modelo de TAA que pode ser usado em muitos TAS
14.3. Decore as 7 camadas do gTAA e seus componentes. Além de sua imagem!
14.3.1. Camadas do gTAA.png
15. Capítulo 2 (5 Páginas)
15.1. Atenção total
15.1.1. Geralmente as TAT não atendem 100% às necessidades
15.1.2. Testabilidade é o sucesso do projeto
15.1.3. Níveis de intrusão fazem testes ficarem mais simples mas aumentam custos e riscos
15.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
15.1.5. TAE precisa especificar ao desenvolvedor quais são as interfaces necessárias para automação
15.1.6. Interfaces alternativas ou personalizadas são aquelas construídas para possibilitar testes antes que as reais sejam construídas.
15.1.7. Lembre-se de verificar a compatibilidade do SUT com o TAS desde o início
15.2. Mindset
15.2.1. O que influencia a automação?
15.2.1.1. Interfaces do SUT
15.2.1.1.1. * Como controlo o SUT através da automação de testes
15.2.1.2. Softwares de Terceiros
15.2.1.2.1. Podemos usar uma API caso a automação faça sentido
15.2.1.3. Níveis de intrusão
15.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
15.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
15.2.1.4. Tamanho e complexidade do SUT
15.2.1.4.1. Consideram viável começar a automação pequena e simples, mesmo para SUTs grandes e complexos
15.2.1.5. Arquitetura do SUT
15.2.1.5.1. Exige diferentes TAS, ou TAS híbridos (ex. TAS que suporta Python e C++, ou Web e Desktop)
15.2.2. Antes do SUT estar pronto
15.2.2.1. Se já conheço os requisitos funcionais e não funcionais, elenco o que irei automatizar a partir deles
15.2.2.2. Durante a arquitetura e a modelagem técnica, devo fazer testes na interface
15.2.3. Testabilidade
15.2.3.1. Desenvolvedor implementa isso, mas o TAE pode ajudar.
15.2.3.2. Modelagem disso consiste em
15.2.3.2.1. Observabilidade, ou seja, a interface possui elementos para validar se o SUT comporta-se como esperado
15.2.3.2.2. Controle (ou, capacidade), a interface é visível ao TAS e ele a pode controlar
15.2.3.2.3. Arquitetura claramente definida, o TAS tem acesso a todos os níveis do SUT
15.2.3.3. Interfaces usadas para testar aplicações ainda não prontas podem ser Planilhas, Mocks, Controladores e Simuladores
15.2.4. Seleção de ferramentas
15.2.4.1. É o TAM que faz isso, com ajuda do TAE
15.2.4.2. O que o TAE faz
15.2.4.2.1. Identifica, analisa e estima
15.2.4.2.2. Recomenda qual é a TAT mais apropriada
15.3. Termos
15.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.
15.3.2. Eficácia é achar o bug certo, eficiência é fazer com pouco esforço
16. Capítulo 3 (21 páginas)
16.1. Mindset
16.1.1. gTAA é uma TAA que tornou-se um modelo que pode ser usada em um ou muitos TAS ;)
16.1.1.1. Define os componentes, conceitos, interfaces e recursos para usuários de um TAS
16.1.1.2. Camadas de um gTAA
16.1.1.2.1. Se essas camadas forem manuais, não necessitamos abordar essas camadas
16.1.1.2.2. Se essas camadas forem automatizadas, então usamos
16.1.2. Um TAS e seu respectivo TAA deve obedecer ao SOLID
16.1.2.1. Responsabilidade única
16.1.2.1.1. Quem loga é um componente diferente do que executa os testes, por exemplo
16.1.2.2. Extensão
16.1.2.2.1. Um componente está aberto a extensão mas fechado à modificação
16.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!
16.1.2.3. Substituição
16.1.2.3.1. Um componente pode ser substituído por outro desde que esse outro tenha o mesmo comportamento
16.1.2.4. Segregação de componentes
16.1.2.4.1. É melhor ter componentes mais específicos do que um componente geral multiuso
16.1.2.5. Inversão de dependência
16.1.2.5.1. Um componente deve depender de abstrações, não de objetos reais
16.1.2.5.2. Construtor espera receber uma interface de um objeto, então posso passar qualquer objeto que implemente aquela interface!
16.1.3. Modelagem do TAA
16.1.3.1. Requisitos de captura necessários para definir um TAA apropriado
16.1.3.1.1. Abordagem de testes
16.1.3.2. Comparar e contrastar diferentes abordagens de projeto / arquitetura
16.1.3.2.1. TAE deve olhar para as camadas do gTAA
16.1.3.3. Identificar áreas onde a abstração pode trazer benefícios
16.1.3.3.1. Permite a independência de fornecedores, facilidade de uso do TAS por não técnicos e etc.
16.1.3.4. Entenda as tecnologias SUT e como elas se interconectam com o TAS
16.1.3.4.1. Paradigmas de interação TAS a SUT, quando em API ou Serviços
16.1.3.5. Compreender o ambiente SUT
16.1.3.5.1. Podem ser softwares ou hardwares, que interagem com usuários, outros softwares ou mesmo com o ambiente.
16.1.3.5.2. TAS deve adaptar-se e simular as condições que validem as saídas do SUT dado uma entrada qualquer
16.1.3.6. Tempo e complexidade para uma determinada implementação de arquitetura de testware
16.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
16.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
16.1.3.6.3. Estimativa paramétrica, como Modelo de Custo Construtivo (COCOMO)
16.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
16.1.3.6.5. Estimativas de grupo, como o Planning Poker
16.1.3.7. Facilidade de uso para uma determinada implementação de arquitetura de testware
16.1.3.7.1. Modelagem orientada ao testador
16.1.3.7.2. Facilidade de utilização do TAS
16.1.3.7.3. Suporte do TAS para outras funções no desenvolvimento de software, garantia de qualidade e gerenciamento de projetos
16.1.3.7.4. Organização eficaz, navegação e busca dentro ou com o TAS
16.1.3.7.5. Documentação útil, manuais e texto de ajuda para o TAS
16.1.3.7.6. Relatórios práticos por e sobre o TAS
16.1.3.7.7. Desenhos iterativos para abordar o feedback do TAS e insights empíricos
16.2. Termos
16.2.1. Analistas de Teste
16.2.2. Analisadores de Teste Técnicos
16.2.3. Configuração de teste -> Local e Configuração de teste virtual -> Nuvem
16.3. Atenção total
16.3.1. TAE é quem projeta, desenvolve, implementa e mantém o TAS
16.3.2. gTAA são conceitos, etapas e abordagens recorrentes na automação de testes
16.3.3. Entenda todos os pontos do SOLID
16.3.4. gTAA não predefine nenhum método, tecnologia, ferramenta ou abordagem de desenvolvimento (OO, Estruturada, etc)
16.3.5. Na Execução, considera a possibilidade de injeção de falha no SUT
16.3.6. Geração automática baseada em permutação pura e simples não é recomendada. Use riscos, etc
16.3.7. Tudo ter que ser analisado cuidadosamente, óbvio
16.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)
16.3.8.1. O TAS pode, nesses casos, simular os ambientes dos hardwares ou os usuários dos softwares
16.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
16.3.10. Recomendam ter um caso de teste manual e um caso de teste automatizado para aumentar a abstração
16.3.11. Recomendam o uso de ferramentas que geram modelos a partir de scripts automatizados
16.3.12. Validação completa e exata são idênticas, mas a exata tem mais detalhes
16.3.13. Script linear é gravação sem alteração do scripts. Já o estruturado é reutilizável.
16.3.14. No DDT scripts que consomem um arquivo externo é chamado "controle"
16.3.15. Acreditam que os arquivos do DDT permitem omitir os "procedimentos de teste negativos"
16.3.16. Nos testes baseados em palavras-chave os arquivos do DDT são chamados de ‘arquivos de definição de teste'.
16.3.17. Testes baseados em modelo são gerados automaticamente, não são executados automaticamente.
16.3.18. Todas as interfaces precisam ser testáveis
16.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"
16.3.20. Acreditam que o TAS precisa ser testado, com testes de capacidade básica (interação entre SUT e TAS)
16.3.21. Os aspetos de reuso são estabelecidos antes do TAA eser definido
16.4. Abordagens para Automação de Testes
16.4.1. Criar sequências de teste
16.4.1.1. Casos de teste diretamente como scripts
16.4.1.1.1. Captura e reprodução pode ser usada aqui
16.4.1.2. Procedimentos posteriormente convertidos em scripts de teste manualmente
16.4.1.2.1. Script de teste estruturado
16.4.1.3. Procedimentos posteriormente convertidos em scripts de teste automaticamente
16.4.1.3.1. Script de teste estruturado
16.4.1.4. Ferramenta gera procedimentos ou extrai scripts de testes a partir de modelos de teste, automaticamente
16.4.1.4.1. Testes baseados em modelos
16.4.1.5. * 1 tem menos e 4 tem mais abstração e automação
16.4.2. Abordagens
16.4.2.1. Abordagem de captura e reprodução
16.4.2.1.1. Ferramentas são usadas para capturar interações com o SUT
16.4.2.1.2. Valida-se os resultados da execução
16.4.2.1.3. Prós e contras
16.4.2.2. Scripts lineares
16.4.2.2.1. Prós e contras
16.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.
16.4.2.2.3. Ferramentas executam o script gerado
16.4.2.2.4. Posso adicionar verificações como comentários no código ou usar a linguagem de programação pra isso
16.4.2.3. Script estruturado
16.4.2.3.1. Prós e contras
16.4.2.3.2. Em comparação ao script linear, essa tem uma biblioteca de scripts. E seus scripts são reutilizáveis.
16.4.2.4. Teste orientado a dados
16.4.2.4.1. Prós e contras
16.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.
16.4.2.5. Testes por palavras-chave
16.4.2.5.1. Prós e contras
16.4.2.5.2. Baseia-se na técnica de script orientada a dados.
16.4.2.5.3. Os arquivos são chamados ‘arquivos de definição de teste'.
16.4.2.5.4. Existe apenas um script de controle
16.4.2.5.5. Os arquivos de palavras-chave também conterão instruções de alto nível (as palavras-chave)
16.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.
16.4.2.5.7. Os analistas de teste podem adicionar testes "automatizados" simplesmente especificando-os em um arquivo de palavras-chave
16.4.2.6. Script direcionado a processo
16.4.2.6.1. Prós e contras
16.4.2.6.2. Representam casos de uso do SUT
16.4.2.6.3. Fluxos de alto-nível
16.4.2.7. Teste baseado em modelo
16.4.2.7.1. Prós e contras
16.4.2.7.2. Geração automática de casos de teste. Não executam eles automaticamente.
16.4.2.7.3. s
16.5. Considerações Técnicas sobre o SUT
16.5.1. Interfaces do SUT
16.5.1.1. Precisam ser testáveis: Observabilidade, Controle e Arquitetura clara
16.5.2. Dados SUT
16.5.2.1. Podem ser de um arquivo de configuração, de um usuário ou de um sistema externo
16.5.2.2. Devem ser configuráveis, para que tenhamos a possibilidade de altera-los e testar melhor
16.5.3. Configurações SUT
16.5.3.1. Pode ser uma configuração de teste ou configuração de teste virtual
16.5.3.2. Também pode-se usar simuladores e/ou emuladores de componentes
16.5.4. Padrões SUT e configurações legais
16.5.4.1. Respeitar os requisitos legais e/ou de normas de modo
16.5.4.2. Exemplo: Requisitos de privacidade para os dados de teste ou requisitos de confidencialidade que afetam as capacidades de log
16.5.5. Ferramentas e ambientes de ferramentas usados para desenvolver o SUT
16.5.5.1. Olhar para ferramentas do SUT e ver se conseguimos compatibilidade/rastreabilidade
16.5.6. Testar interfaces no produto de software
16.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.
16.6. Considerações para processos de desenvolvimento e qualidade
16.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
16.6.2. Requisitos de relatório -> Relatórios de teste fixos, parametrizados ou definidos em diferentes formatos e layouts
16.6.3. Papéis e direitos de acesso -> Fornecer um papel e sistema de direitos de acesso
16.6.4. Panorama de ferramenta estabelecida -> Código do TAA deve ser versionado junto com o do SUT
16.7. Desenvolvimento do TAS
16.7.1. Observações
16.7.1.1. Segue o mesmo flow de um prodjeto de desenvolvimento, inclusive com revisões
16.7.1.2. O SUT é afetado pela estratégia de testes, quando precisa ser alterado para testabilidade, por exemplo
16.7.2. Ciclo de Vida do TAS (Baseado no SDCL)
16.7.2.1. Análise
16.7.2.1.1. Requisitos devem ser coletados antes
16.7.2.2. Desenho
16.7.2.3. Desenvolvimento
16.7.2.4. Teste
16.7.2.4.1. Através de testes de capacidade básicos
16.7.2.5. Implantação
16.7.2.6. Evolução
16.7.2.6.1. Adição de testes ou manutenção dos já existentes quando o SUT muda
16.7.3. Compatibilidade TAS/SUT
16.7.3.1. Equipe
16.7.3.1.1. Membros com mesmo mindset e prontos a trabalhar com conjunto
16.7.3.2. Processo
16.7.3.2.1. Processos iguais com sincronização da automação e desenvolvimento do software
16.7.3.3. Tecnologia
16.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
16.7.3.4. Ferramentas
16.7.3.4.1. Uso das mesmas ferramentas para facilitar a gestão do processo
16.7.4. Sincronização TAS/SUT
16.7.4.1. Requisitos
16.7.4.1.1. Que abordam o desenvolvimento do SUT
16.7.4.1.2. Que abordam os testes do SUT
16.7.4.2. Fases de desenvolvimento
16.7.4.2.1. Para ter o TAS pronto quando necessário para testar o SUT
16.7.4.3. Rastreamento de defeitos
16.7.4.3.1. Pois os defeitos podem estar relacionados
16.7.4.4. Evolução SUT/TAS
16.7.4.4.1. Qualquer alteração aplicada a um SUT ou a um TAS pode afetar o outro
16.7.4.4.2. Abordagens SUT/TAS
16.7.4.4.3. Abordagens SUT/TAS/Testes manuais
16.7.4.5. Reutilização do TAS
16.7.4.5.1. Reaproveitamento de seus artefatos
16.7.4.5.2. Os requisitos para reutilização resultam da relevância dos artefatos TAS para as outras variantes
16.7.4.5.3. Os aspetos de reuso são estabelecidos antes do TAA eser definido
16.7.4.5.4. TAS pode ajudar a aumentar a capacidade de reutilização, por seguir, atualizar, revisar, documentar os artefatos e corrigir falhas
16.7.4.5.5. Reutilização é principalmente uma questão para o TAA
16.7.5. Apoio a outros sistemas-alvo
16.7.5.1. Refere-se à capacidade do TAS para testar diferentes configurações de um produto de software
16.7.5.2. Impactam o TAS em qualquer nível de teste
16.7.5.2.1. Número e interligação de componentes do SUT
16.7.5.2.2. Ambientes (software e hardware) nos quais os componentes do SUT são executados
16.7.5.2.3. Tecnologias, linguagens de programação ou sistemas operacionais utilizados para implementar os componentes do SUT
16.7.5.2.4. Bibliotecas e pacotes que os componentes do SUT estão usando
16.7.5.3. Nível de componente e integração
16.7.5.3.1. Ferramentas usadas para implementar os componentes do SUT
16.7.5.4. A capacidade de um TAS para testar diferentes configurações de produto de software é determinada quando o TAA é definido
16.7.5.5. A manutenção e melhorias para esta variabilidade é uma preocupação de longo prazo no ciclo de vida do TAS