1. Análsie e Modelagem de Teste
1.1. TÉCNICA Teste caixa-preta
1.1.1. Parcionamento de Equivalência
1.1.2. Análise de Valor Limite (BVA)
1.1.3. Teste de Tabela de Decisão
1.1.4. Teste de Transição de Estado
1.1.4.1. Cobertuda de todos os estados
1.1.4.2. Cobertura de transições válidas 0-switch
1.1.4.3. Cobertura de todas as transições
1.2. TÉCNICA Teste caixa-branca
1.2.1. Teste de Instruções e Cobertura de Instrução
1.2.1.1. Passar por todas as linhas do código Passa pelas linhas do código ao menos uma vez
1.2.2. Teste de Ramificação e Cobertura de Ramificação
1.2.2.1. Ao fazer o teste de RAMIFICAÇÃO dentro desse teste faz o teste INSTRUÇÃO (ao contrário não acontece) Passa pelas linhas do código + as ramificações/condições
1.3. TÉCNICA Teste Baseados na Experiência
1.3.1. Suposição de Erro
1.3.1.1. Ex.: o testador já trabalhou com um software parecido em outra empresa, logo ele já possuí um certo conhecimento e consegue SUPOR os possíveis erros. O Testador pode criar uma lista com base na regra de negócios e assim ticar.
1.3.2. Teste Exploratório
1.3.2.1. Quando há pouca especificação sobre o objeto de teste Aprender mais sobre o software Explorar Testes baseados em sessões (tempo definido de 30 a 120 minutos) + carta de teste
1.3.3. Teste Baseado em Lista de Verificação
1.3.3.1. Testes baseados em lista de verificação (checklist) Exemplo: heurísticas de Nielsen, um livro XYZ
1.4. ABORDAGENS de Teste Baseadas na Colaboração
1.4.1. Escrita colaborativa de histórias de usuários
1.4.1.1. 3C Cartão - história do usuário Conversão - critérios de aceite Confirmação - Como... Quero... Para que ...
1.4.2. Critérios de Aceite
1.4.2.1. São condições que fazem parte das histórias de usuário Orientado a cenários Dado Quando Então Orientado por regras
1.4.3. ATDD Desenvolvimento Orientado por Teste de Aceite
2. Gerenciamento das Atividades de Teste
2.1. 5.1 Planejamento de Teste
2.1.1. Objetivo e conteúdo de um plano de teste
2.1.1.1. Plano de teste → Pq está testando?
2.1.2. Contribuição do testador para o planejamento de iteração e liberação
2.1.2.1. Iteração = ciclo de trabalho sprint Liberação = soma de algumas sprints (entrega)
2.1.3. Critérios de entrada e critérios de saída
2.1.3.1. Critérios de ENTRADA define condições prévias para começar Definição de PRONTO (DoR) Antes Pronto → O item está preparado para ser trabalhado.
2.1.3.2. Critérios de SAÍDA → define o que deve ser alcançado para que uma atividade seja declarada como concluída Definição de FEITO (DoD) Depois Feito → O item foi finalizado conforme os critérios de qualidade.
2.1.4. Técnicas de estimativa
2.1.4.1. Estimativa Baseada em Índices
2.1.4.1.1. Métricas → coletadas de projetos anteriores
2.1.4.2. Extrapolação
2.1.4.2.1. Baseada SDLC iterativos (mais cedo possível)
2.1.4.3. Windeband Delphi (Ágil)
2.1.4.3.1. Baseada na experiência de especialistas
2.1.4.4. Estimativa de Três Pontos
2.1.4.4.1. Otimista [ 1 ] Provável [ *4 ] Pessimista [ 1 ] + Otimista 4x Provável + Pessimista ____ 6
2.1.5. Priorização de casos de teste
2.1.5.1. Risco
2.1.5.1.1. Priorização baseada em RISCO: → os casos de teste que abrangem os riscos mais importantes são executados primeiro
2.1.5.2. Cobertura
2.1.5.2.1. Priorização baseada em COBERTURA: → os casos de teste que atingem a maior cobertura são executados primeiro
2.1.5.3. Requisitos
2.1.5.3.1. Priorização baseada em REQUISITOS: → os testes relacionados aos requisitos mais importantes são executados primeiro.
2.1.6. Pirâmide de teste
2.1.6.1. Teste de Interface do Usuário
2.1.6.1.1. Teste de Tela + Lento + Integrado
2.1.6.2. Teste de Serviço
2.1.6.2.1. Teste de Integração
2.1.6.3. Teste de Unidade
2.1.6.3.1. Teste de Componentes + Rápido + Isolado
2.1.7. Quadrantes de teste
2.1.7.1. Tentar memorizar
2.1.7.2. Q1 → Tecnologia apoia a equipe → Testes Unitários → Teste de Componentes
2.1.7.3. Q 2 → Negócios apoia a equipe → Testes Funcionais → Protótipos
2.1.7.4. Q 3 → Negócios avalia o produto → Testes Exploratórios → Usabilidade → Aceite
2.1.7.5. Q 4→ Tecnologia avalia o produto → Performance e Carga → Segurança
2.2. 5.2 Gereciamento de Risco
2.2.1. Definição de risco e atributos do risco
2.2.1.1. ANÁLSIE DE RISCO Probabilidade → chance de acontecer Impacto → dano caso aconteça CONTROLE DE RISCO Ação de mitigar o risco tomar ações para reduzir a probabilidade de um risco ocorrer ou diminuir o impacto
2.2.2. Riscos do projeto e riscos do produto
2.2.2.1. Risco do Projeto → problema no andamento do projeto Risco do Produto → ISO 25010 falha, vulnerabilidade do produto/software * Características de qualidade do produto
2.2.3. Análise de risco do produto
2.2.3.1. A análise de Risco do Produto envolve a identificação e avaliação dos riscos associados ao próprio produto a ser testado.
2.2.3.2. Do ponto de vista do testador é de conscientização do risco do produto → Análise de risco → Identificação de riscos Identica-se por meio: workshops, entrevistas, diagramas e stakholders
2.2.4. Controle de risco do produto
2.2.4.1. O Controle de Risco do Produto envolve ações práticas para gerenciar os riscos identificados durante a análise.
2.2.4.2. Mitigação → reduzir o imapacto e/ou probabilidade do risco
2.3. 5.3 Monitoramento, Controle e Conclusão do Teste
2.3.1. Métricas usadas em teste
2.3.1.1. São abordadas diversas métricas usadas em testes para avaliar a qualidade do software e a eficiência do processo de testes.
2.3.2. Relatório de teste: objetivo, conteúdo e público-alvo
2.3.2.1. Relatório de Teste → progresso do teste → gerado durante a execução dos testes Relatório de Conclusão → gerado ao final do ciclo de testes → resumo do teste Público-alvo → usar a linguagem de acordo com o público
2.3.3. Comunicação do status dos testes
2.3.3.1. O melhor meio de comunicar o status do teste varia de acordo com o público e contexto Ex.: comunicação verbal, documentação on-line, board
2.4. 5. 4 Gerenciamento de Configuração (CM)
2.4.1. Identificar, controlar, rastrear produtos de trabalho → Versionamento: versões do software → Artefatos, rastreabilidade
2.4.2. Pipeline e DevOps ( usar a automação de teste ) CI (integração contínua)→ desenvolvimento e teste CD (entrega contínua) → desenvolvimento, teste e produção
2.5. 5.5 Gerenciamento de Defeitos cai o conceito
2.5.1. Fluxo do defeito em qualquer fase do SDLC → abrir, analisar, atribuir para quem vai corrigir → usado desde o teste estático até o teste dinânico → reteste (por quem encontrou) → regressão
3. Suporte de Ferramentas para Testes
3.1. 6.1 Suporte de Ferramentas para Testes
3.1.1. Ferramentas de teste que dão suporte aos testes e facilitam as atividades de teste
3.2. 6.2 Benefícios e Riscos da Automação de Teste
3.2.1. Ao implementar uma ferramenta o ideal é: → Prova de conceito → Projeto piloto (em ambiente controlado) → Treinar os funcionários
3.3. Reforço das Normas
3.3.1. Parte I 29119-1 → Vocabulário → Conceitos → Definições
3.3.2. Parte II 29119-12 → Processos de Teste
3.3.3. Parte III 29119-3 → Documentção de Teste → Testware
3.3.4. Parte IV 29119-4 → Técnicas de Teste *Caixa-Preta *Caixa-Branca *Baseada em Esperiência
3.3.5. ISO 20246 → Engenharia de Software e Sistema
3.3.6. ISO 25010 → 8
4. Fundamentos de Teste
4.1. 1.1 O que é teste
4.1.1. Objetivos do teste
4.1.1.1. + Importante →Detectar falhas e defeitos →Mostrar a presença não ausência de defeitos
4.1.2. Teste e depuração
4.1.2.1. Teste → Encontra e registra defeitos/falhas Depuração →Encontra a falha e corrige - Reproduz a falha - Encontra a causa - Corrige a causa
4.2. 1.2 Por que os testes são necessários?
4.2.1. Contribuições para o sucesso dos testes
4.2.1.1. Investir em teste reduz custos
4.2.2. Controle de Qualidade (QC) Garantia da Qualidade (QA)
4.2.2.1. QC (Produto) Testes usados para corrigir defeitos QA (Processo) Testes fornecem feedback
4.2.3. Erros, Defeitos, Falhas e Causas-raiz
4.2.3.1. Erro → Estático ou Dinânico O próprio autor encontra Defeito → Estático (não executa o software) Encontrado por outro Falha → Dinânimo (executa o software) Encontrado por outro Causa Raiz → o que causou o erro/defeito/falha
4.3. 1.3 Princípios de teste
4.3.1. O teste mostra a presença, não a ausência de defeitos.
4.3.1.1. Mostram a presença de defeito, mas não provam a ausência de defeitos
4.3.2. Testes exaustivos são impossíveis
4.3.2.1. É impossível testar TUDO Tempo X Custo
4.3.3. Testes antecipados economizam tempo e dinheiro
4.3.3.1. Os defeitos são removidos no início do SDLC (testar o quanto antes)
4.3.4. Os defeitos se agrupam
4.3.4.1. Um pequeno número de componentes geralmente contém mais defeitos (agrupamento de defeitos)
4.3.5. Os testes se degradam
4.3.5.1. Executar sempre os mesmos testes reduz a eficácia na detecção de novos defeitos EXCETO: em testes de regressão automatizados
4.3.6. Os testes dependem do contexto
4.3.6.1. Não existe uma abordagem universal, depende do contexto Ex.: Avião 90% Navegação 10% Entretenimento
4.3.7. Falácia da ausência de defeitos
4.3.7.1. Não adianta a verificação estar OK se a validação (não ocorrer), ou seja, não atende as expectativas dos stakholderes
4.4. 1. 4 Atividades de teste, Testware e Papéis de teste
4.4.1. Atividades e tarefas de teste
4.4.1.1. Planejamento do Teste [Gerente]
4.4.1.1.1. Definição de estratégia, escopo, recursos e cronograma
4.4.1.2. Monitoramento e Controle de Teste [Gerente]
4.4.1.2.1. Acompanhamento do progresso, ajustes conforme necessário
4.4.1.3. Análise de Teste -Testador-
4.4.1.3.1. Identificação de condições de teste a partir dos requisitos
4.4.1.4. Modelagem de Teste -Testador-
4.4.1.4.1. Criação de casos de teste e critérios de aceitação
4.4.1.5. Implementação do Teste - Testador-
4.4.1.5.1. Preparação do ambiente e dados de teste
4.4.1.6. Execução de Teste -Testador-
4.4.1.6.1. Realização dos testes e registro dos resultados
4.4.1.7. Conclusão de Teste [Gerente]
4.4.1.7.1. Relatório final, revisão de lições aprendidas e arquivamento
4.4.2. Processo de teste no contexto
4.4.2.1. As atividades de teste são parte integrante dos processos de desenvolvimento
4.4.3. Testware
4.4.3.1. → Tudo o que o profissional de teste produz Produtos de trabalho produzidos durante o processo de teste para uso no planajamento, projeto, execução, avaliação e relatórios de teste
4.4.4. Rastreabilidade entre a Base de Teste e o Testware
4.4.4.1. Base de Teste → conhecimento e tudo que se usa de informação para criar teste
4.4.4.2. Testware → tudo que é produzido nos testes
4.4.4.3. Rastreabilidade → capacidade de estabelecer conexões explicitas entre produtos de trabalho relacionados ou itens de produtos de trabalho
4.4.5. Papéis no teste
4.4.5.1. Testador
4.4.5.1.1. Atividades técnicas → Análise, Modelagem, Implementação e Execução de teste
4.4.5.2. Gerente de Teste
4.4.5.2.1. Assume responsabilidade geral pelo processo de teste, equipe e liderança → Planejamento | Monitoramento e Controle | Conclusão de teste
4.5. 1.5 Habilidades essenciais e boas práticas em testes
4.5.1. Habilidades genéricas necessárias para testes
4.5.1.1. Conhecimento sobre testes
4.5.1.2. Meticulosidade, cuidado
4.5.1.3. Boas habilidades de comunicação
4.5.1.4. Pensamento analítico, crítico
4.5.1.5. Conhecimento técnico
4.5.1.6. Conhecimento do domínio
4.5.2. Abordagem de equipe completa
4.5.2.1. Todos são responsáveis pela qualidade → Testadores, Negócios, Devs
4.5.2.2. Testador colabora com representantes do negócio para ajudá-los a criar testes de aceite adequados
4.5.3. Independência dos testes
4.5.3.1. ✅ Benefício: Testadores independentes costumam identificar falhas diferentes das encontradas pelos desenvolvedores, graças a diferentes perspectivas, experiências e ausência de viés. ⚠️ Desvantagem: A independência pode dificultar a comunicação e a colaboração, gerando isolamento, atritos com o time de desenvolvimento e até a atribuição de culpa em caso de atrasos.
4.5.3.1.1. + Independente para encontrar/relatar falhas/defeitos Testes por equipe externa à organização
4.5.3.1.2. - Independente para encontrar/relatar falhas/defeitos Testes por equipe de QA interna
5. Testes ao longo do SLDC
5.1. 2.1 Testes no contexto de um Ciclo de Vida de Desenvolvimento de Software
5.1.1. Modelo de Desenvolvimento
5.1.1.1. SEQUENCIAL
5.1.1.1.1. → Cascata → Em V
5.1.1.2. ITERATIVO ágil
5.1.1.2.1. → Espiral → Prototipagem
5.1.1.3. INCREMENTAL
5.1.1.3.1. → Processo Unificado Racional (RUP)
5.1.2. Impacto do ciclo de vida de desenvolvimentode software nos testes [SDLC]
5.1.2.1. Desenvolvimento Sequencial
5.1.2.1.1. nas fases iniciais, os testadores normalmente participam das revisão de requisitos, da análise de teste e projeto de testes
5.1.2.2. Iterativo e Incremental
5.1.2.2.1. supõe-se que a cada iteração entrega-se um protótipo funcional ou um incremento de produto
5.1.2.3. Ágil
5.1.2.3.1. presupõe que podem ocorrer mudanças ao longo do projeto. documentação mais leve
5.1.3. SDLC e boas práticas de teste
5.1.3.1. para cada atividade de desenvolvimento deverá ter uma atividade de teste
5.1.3.1.1. para que haja o controle de qualidade
5.1.3.1.2. diferentes níveis de teste tem objetivos específicos
5.1.4. Teste como um motivador para o desenvolvimento de software
5.1.4.1. abordagens de desenvolvimento de teste de software
5.1.4.1.1. TDD
5.1.4.1.2. ATDD
5.1.4.1.3. BDD
5.1.5. DevOps e Testes
5.1.5.1. promove a colaboração contínua entre desenvolvimento, operações e qualidade
5.1.5.1.1. CI → Integração Contínua promove a aboragem Shift-left
5.1.5.1.2. CD → Entrega Contínua
5.1.6. Abordagem Shift-Left
5.1.6.1. antecipar as atividades de teste para as fases iniciais do desenvolvimento SDLC
5.1.6.1.1. isso não significa que os testes posteriores no SDLC devam ser ignorados
5.1.7. Retrospectivas e melhoria de processos
5.1.7.1. Retrospectiva → reunião pós-projeto coletar feedback, avaliar e propor melhorias
5.2. 2.2 Níveis de Teste e Tipos de Teste
5.2.1. Níveis de Teste → estágio do teste no SDLC
5.2.1.1. C
5.2.1.1.1. Componente [teste de unidade]
5.2.1.2. I
5.2.1.2.1. Integração de Componente [teste de integração de unidade]
5.2.1.3. S
5.2.1.3.1. Sistemas
5.2.1.4. I
5.2.1.4.1. Integração de Sistemas
5.2.1.5. A
5.2.1.5.1. Aceite
5.2.2. Tipos de Teste → atvididades de teste
5.2.2.1. Teste Funcional
5.2.2.1.1. É possível realizar o testes desde o início do SDLC Ex.: analisar o layout logo no início no desenho da tela
5.2.2.2. Teste Não Funcional
5.2.2.2.1. Quão bem o sistema se comporta
5.2.2.3. Teste Caixa-Preta
5.2.2.3.1. Comportamento → baseado em especificações
5.2.2.4. Teste Caixa-Branca
5.2.2.4.1. Lógica interna [código] → baseado no código e na estrutura interna
5.2.3. Testes de Confirmação e Teste de Regressão
5.2.3.1. são necessários em todos os níveis de testes
5.2.3.1.1. Confirmação
5.2.3.1.2. Regressão
5.3. 2.3 Teste de Manutenção
5.3.1. ocorre quando um sistema já em produção precisa ser modificado, seja para correções, melhorias ou adaptações.
5.3.1.1. os fatores são:
5.3.1.1.1. Modificação
5.3.1.1.2. Atualizações ou migrações
5.3.1.1.3. Aposentadoria
6. Teste Estático
6.1. 3.1 Noções básicas de Teste Estático
6.1.1. Noções básicas de Teste Estático
6.1.1.1. Não executa o software, analisa: → documentos → diagramas → ferramenta análise estática
6.1.1.2. Definição de pronto → pronto para a próxima etapa
6.1.1.3. Encontra os defeitos antes de executar o programa → análise estática pode identificar problemas antes dos testes dinâmicos
6.1.2. Produtos de trabalho examináveis por testes estáticos
6.1.2.1. Qualquer produto que pode ser lido e compreendido → documentos → código-fonte → planos e casos de teste → há ferramentas que podem realizar o teste estático
6.1.3. Valor do teste estático
6.1.3.1. No começo do SDLC o teste estático se faz necessário (antecipa os testes / Shift-left ) → encontra um código inacessível → padrões de projetos não implementados conforme o desejado → um método/função que nunca é chamado (código inacessível)
6.1.3.2. O teste estático é mais barato que o teste dinâmico → os testes estáticos resultam em menos defeitos de código e em um menor esforço geral de desenvolviemnto → gasta-se menos tempo e esforço para corrigir defeitos posteriormente no projeto
6.1.4. Diferenças entre testes estáticos e testes dinâmicos
6.1.4.1. Teste Estático → encontram ERRO e DEFEITOS
6.1.4.1.1. → requisitos → projeto → código → ambiguidade → interface (comunicação/troca de dados)
6.1.4.2. Teste Dinânico → encontram FALHAS
6.2. 3.2 Processo de feedback e revisão
6.2.1. Benefícios do feedback antecipado e frequente dos stakeholders
6.2.1.1. Feedback constante dos stakholders no SDLC → detecção precoce de defeitos → ajustes rápidos e contínuos → melhoria da qualidade do software → redução de retrabalho → maior alinhamento com os requisitos do cliente
6.2.2. Atividades do processo de revisão
6.2.2.1. ISO 20246
6.2.2.1.1. Planejamento
6.2.2.1.2. Início da revisão
6.2.2.1.3. Revisão individual
6.2.2.1.4. Comunicação e Análise de problemas
6.2.2.1.5. Correção e Relatório
6.2.3. Funções e responsabilidades nas revisões
6.2.3.1. Gerente
6.2.3.1.1. → cuida dos recursos (equipe e tempo para revisão) → divide o que deve ser revisado
6.2.3.2. Autor
6.2.3.2.1. → cria e corrige o produto de trabalho em análise
6.2.3.3. Moderador
6.2.3.3.1. Facilitador → garante e medeia o andamento das reuniões → gerencia o tempo e possibilita que todos possam falar
6.2.3.4. Relator
6.2.3.4.1. Registrador → documenta o que foi discutido → sobre decisões → sobre anomalias
6.2.3.5. Revisor
6.2.3.5.1. Testa (teste estático) → realiza revisões
6.2.3.6. Líder da revisão
6.2.3.6.1. Lidera vários revisores de um projeto → decide quem estará envolvido → organiza quando e onde a revisão será realizada
6.2.4. Tipos de revisão prova (ligar colunas)
6.2.4.1. As revisões podem ser formais e informais depende do contexto do SDLC
6.2.4.1.1. Revisão Informal
6.2.4.1.2. Walkthroungh tradução → acompanhamento
6.2.4.1.3. Revisão Técnica
6.2.4.1.4. Inspeção
6.2.5. Fatores de sucesso para revisões
6.2.5.1. → ter um objetivo claro → escolher o tipo de revisão apropriado → revisõs em pequenas partes → fornecer feedback das revisões