1. :six: Ferramentas de Teste
1.1. 6.1 Suporte de Ferramentas para Testes
1.1.1. As ferramentas de teste ajudam a facilitar várias atividades, incluindo:
1.1.1.1. Gerenciamento
1.1.1.1.1. p/ Gerenciamento de Teste
1.1.1.1.2. p/ Gerenciamento de Requisitos
1.1.1.1.3. p/ Gerenciamento de Incidentes
1.1.1.1.4. p/ Gerenciamento de Configuração
1.1.1.2. Teste Estático
1.1.1.2.1. p/ Processo de Revisão
1.1.1.2.2. p/ Análise Estática
1.1.1.2.3. p/ Modelagem
1.1.1.3. Projeto e Implementação
1.1.1.3.1. facilitam a geração de casos de teste e dados.
1.1.1.4. Execução e Cobertura:
1.1.1.4.1. permitem a execução de testes automatizados e medição da cobertura.
1.1.1.5. Teste Não Funcional
1.1.1.5.1. ajudam na realização de testes que não podem ser feitos manualmente.
1.1.1.6. DevOps
1.1.1.6.1. suportam o pipeline de entrega e automação de processos
1.1.1.7. Colaboração
1.1.1.8. Escalabilidade
1.2. 6.2 Benefícios e Riscos da Automação de Teste
1.2.1. Benefícios
1.2.1.1. Economia de Tempo: Reduz o trabalho manual repetitivo, como testes de regressão.
1.2.1.2. Prevenção de Erros: Aumenta a consistência e a repetibilidade dos testes.
1.2.1.3. Avaliação Objetiva: Facilita a medição de métricas complexas.
1.2.1.4. Acesso a Informações: Melhora o suporte ao gerenciamento e relatórios de teste.
1.2.1.5. Redução de Tempos de Execução: Acelera a detecção de defeitos e feedback.
1.2.1.6. Mais Tempo para Testadores: Permite que os testadores criem testes mais eficazes.
1.2.2. Riscos
1.2.2.1. Expectativas Irreais: Suposições erradas sobre os benefícios e usabilidade das ferramentas.
1.2.2.2. Estimativas Imprecisas: Dificuldade em prever tempo e custos para implementação e manutenção.
1.2.2.3. Uso Inadequado: Utilização de ferramentas de automação quando o teste manual é mais adequado.
1.2.2.4. Dependência Excessiva: Confiança excessiva na automação em detrimento do pensamento crítico.
1.2.2.5. Dependência do Fornecedor: Riscos associados a fornecedores de ferramentas que podem descontinuar suporte.
1.2.2.6. Compatibilidade: Problemas de integração com plataformas de desenvolvimento.
1.2.2.7. Escolha Inadequada: Seleção de ferramentas que não atendem a requisitos normativos.
1.3. Especificação do Teste
1.3.1. p/ Modelagem do teste
1.3.2. p/ Preparação de Dados de teste
1.4. Execução do Teste
1.4.1. p/ Execução
1.4.2. p/ testes unitários especificos
1.4.3. Comparadores
1.4.4. Medidores de cobertura
1.4.5. p/ Segurança
1.5. Performance e Monitoração
1.5.1. p/ Análise Dinâmica
1.5.2. p/ Teste de Performance/ Carga /Estresse
1.5.3. p/ Monitoração
2. Gerenciamento de Teste
2.1. 5.1.1 Objetivo e Conteúdo de um Plano de Teste
2.1.1. Definição
2.1.1.1. Um plano de teste documenta os objetivos, recursos e processos do projeto de teste
2.1.2. Funções principais
2.1.2.1. Documentação: Registra meios e cronograma para alcançar objetivos.
2.1.2.2. Critérios de Qualidade: Garante que as atividades de teste atendam aos critérios estabelecidos.
2.1.2.3. Comunicação: Serve como meio de comunicação entre equipe e stakeholders.
2.1.2.4. Conformidade: Demonstra alinhamento com políticas e estratégias de teste.
2.1.3. Importância do Planejamento
2.1.3.1. Orienta os testadores a enfrentar desafios relacionados a riscos, cronogramas e recursos.
2.1.4. Conteúdo Típico de um Plano de Teste
2.1.4.1. Contexto do teste: Escopo, objetivos, restrições, base do teste.
2.1.4.2. Premissas e restrições: Fatores que influenciam o projeto.
2.1.4.3. Stakeholders: Funções, responsabilidades e necessidades.
2.1.4.4. Comunicação: Formas e frequência de comunicação.
2.1.4.5. Registro de riscos: Riscos associados ao produto e ao projeto.
2.1.4.6. Abordagem de teste: Níveis, tipos, técnicas, métricas e critérios de entrada/saída.
2.1.4.7. Orçamento e cronograma: Recursos financeiros e cronologia do projeto
2.2. 5.1.2 Contribuição do Testador para o Planejamento de Iteração e Liberação
2.2.1. Planejamento de Liberação
2.2.1.1. Define o lançamento do produto e o backlog do produto.
2.2.1.2. Testadores participam da escrita de histórias de usuários e critérios de aceitação testáveis, análises de risco e estimativas de esforço de teste.
2.2.2. Planejamento de Iteração
2.2.2.1. Foca no backlog da iteração e nos aspectos funcionais e não funcionais das histórias de usuários.
2.2.2.2. Testadores realizam análise de risco, estimam esforço de teste e dividem histórias em tarefas, incluindo tarefas de teste.
2.3. 5.1.3 Critérios de Entrada e Critérios de Saída
2.3.1. Critério de Entrada
2.3.1.1. Definem quando começar um teste, no início de um nível de teste ou quando um conjunto de testes está pronto para execução
2.3.1.2. Condições que devem ser atendidas antes de iniciar uma atividade de teste. Se não forem atendidos, a atividade pode se tornar difícil, demorada e arriscada
2.3.1.3. Exemplos
2.3.1.3.1. Disponibilidade de recursos (pessoas, ferramentas, dados).
2.3.1.3.2. Material de teste (requisitos testáveis, casos de teste).
2.3.1.3.3. Nível de qualidade inicial (como aprovação de testes de fumaça).
2.3.2. Critérios de Saída
2.3.2.1. Definem quando parar de testar, no final de um nível de teste ou quando um conjunto de testes realizados atingiu um objetivo específico
2.3.2.2. Condições que definem quando uma atividade pode ser considerada concluída.
2.3.2.3. Exemplos
2.3.2.3.1. Medidas de precisão (cobertura de testes, número de defeitos não resolvidos).
2.3.2.3.2. Critérios de conclusão (execução dos testes planejados, relatórios de defeitos).
2.3.2.3.3. Esgotamento de tempo ou orçamento pode também ser um critério de saída.
2.3.3. Desenvolvimento Ágil
2.3.3.1. Os critérios de entrada são a Definição de Pronto (DoR)
2.3.3.2. Os critérios de saída são a Definição de Feito (DoD)
2.4. 5.1.4 Técnicas de Estimativa
2.4.1. A estimativa do esforço de teste envolve prever o trabalho necessário para alcançar os objetivos do projeto. É importante lembrar que as estimativas são baseadas em suposições e podem conter erros.
2.5. 5.1.5 Priorização de Casos de Teste
2.5.1. Objetivo: Organizar casos de teste em um cronograma de execução que defina a ordem em que devem ser executados.
2.5.2. Fatores de Priorização:
2.5.2.1. Priorização Baseada em Risco: Os testes são realizados primeiro nos casos que cobrem os riscos mais significativos, conforme identificado na análise de risco.
2.5.2.2. Priorização Baseada em Cobertura: Casos de teste que proporcionam a maior cobertura (como cobertura de instrução) são priorizados. Uma variante é a priorização de cobertura adicional, onde cada novo teste executado busca maximizar a cobertura adicional.
2.5.2.3. Priorização Baseada em Requisitos: A ordem de execução é definida com base nas prioridades dos requisitos dos stakeholders, executando primeiro os testes relacionados aos requisitos mais críticos.
2.5.3. Considerações
2.5.3.1. A priorização deve levar em conta dependências entre os casos de teste
2.5.3.2. A disponibilidade de recursos (ferramentas, ambientes, pessoas) também pode afetar a ordem de execução
2.6. 5.1.6 Pirâmide de Teste
2.6.1. Modelo
2.6.1.1. A pirâmide de teste ilustra que diferentes níveis de teste têm diferentes granularidades (escopo) e propósitos.
2.6.2. Camadas
2.6.2.1. Camada Inferior: Contém testes de unidade, que são pequenos, isolados e rápidos. Muitos testes são necessários para obter uma cobertura significativa.
2.6.2.2. Camada Superior: Compreende testes de alto nível, como testes de ponta a ponta, que são mais lentos e abrangem mais funcionalidade
2.6.3. Estruturas Variadas
2.6.3.1. O número e a nomenclatura das camadas podem variar, mas geralmente incluem testes de unidade, testes de integração e testes de interface do usuário
2.7. 5.1.7 Quadrantes de Teste
2.7.1. Definição
2.7.1.1. Os quadrantes de teste, desenvolvidos por Brian Marick, agrupam níveis e tipos de testes, ajudando a garantir que todas as abordagens necessárias sejam cobertas no desenvolvimento ágil.
2.7.2. Classificação dos Quadrantes:
2.7.2.1. Quadrante Q1: Tecnologia, Apoio à Equipe - Testes de componentes e integração; devem ser automatizados e parte do CI.
2.7.2.2. Quadrante Q2: Negócios, Apoio à Equipe - Testes funcionais e de aceitação; podem ser manuais ou automatizados e verificam critérios de aceitação.
2.7.2.3. Quadrante Q3: Negócios, Avaliação do Produto - Testes exploratórios e de usabilidade; geralmente manuais, focados na experiência do usuário.
2.7.2.4. Quadrante Q4: Tecnologia, Avaliação do Produto - Smoke tests e testes não funcionais; frequentemente automatizados.
2.8. 5.2 Gerenciamento de Risco
2.8.1. Importância
2.8.1.1. O gerenciamento de riscos ajuda organizações a aumentar a probabilidade de alcançar objetivos, melhorar a qualidade do produto e aumentar a confiança dos stakeholders.
2.8.2. Atividades Principais:
2.8.2.1. Análise de Risco: Identificação e avaliação de riscos.
2.8.2.2. Controle de Risco: Mitigação e monitoramento.
2.8.3. Definição de Risco
2.8.3.1. Risco é um evento potencial que pode causar um efeito adverso, caracterizado por probabilidade e impacto.
2.8.4. Tipos de Riscos:
2.8.4.1. Riscos do Projeto
2.8.4.1.1. Associados ao gerenciamento e controle do projeto
2.8.4.1.2. Riscos Potenciais
2.8.4.2. Riscos do Produto
2.8.4.2.1. Relacionados diretamente ao objeto sob teste, às características de qualidade do produto, como funcionalidades ausentes, erros e problemas de usabilidade.
2.8.4.2.2. Esxemplo: riscos às pessoas se o produto falhar (controle de trafego aéreo, por exemplo)
2.8.5. Análise de Risco do Produto
2.8.5.1. Visa concentrar o esforço de teste para minimizar riscos, inclui:
2.8.5.1.1. Identificação e avaliação de riscos.
2.8.5.1.2. Categorização e priorização de riscos.
2.8.5.1.3. Uso de abordagens qualitativas e quantitativas para avaliar riscos.
2.8.6. Resultados da Análise de Risco
2.8.6.1. Influenciam o escopo e as técnicas de teste, priorizando testes que identifiquem defeitos críticos precocemente
2.9. 5.2.1 Definição de Risco e Atributos do Risco
2.9.1. Risco é um possível evento, perigo, ameaça ou situação cuja ocorrência causa um efeito adverso. Um risco pode ser caracterizado por dois fatores:
2.9.1.1. Probabilidade: a probabilidade de ocorrência do risco (maior que zero e menor que um)
2.9.1.2. Impacto (dano): as consequências dessa ocorrência
2.10. 5.2.4 Controle de Risco do Produto
2.10.1. Definição: O controle de riscos envolve ações para mitigar e monitorar riscos identificados do produto.
2.10.2. Mitigação: Implementação de ações para reduzir riscos, como:
2.10.2.1. Seleção de testadores com habilidades adequadas.
2.10.2.2. Aplicação de independência nos testes.
2.10.2.3. Realização de análises estáticas e revisões.
2.10.2.4. Uso de técnicas e tipos de teste apropriados.
2.10.3. Monitoramento: Avalia a eficácia das ações de mitigação, coleta informações para melhorar a avaliação de riscos e identifica novos riscos.
2.10.4. Opções de resposta ao risco:
2.10.4.1. Mitigação
2.10.4.2. Aceitação
2.10.4.3. Transferência
2.10.4.4. Plano de contingência
2.11. 5.3 Monitoramento, Controle e Conclusão do Teste
2.11.1. Monitoramento de Testes:
2.11.1.1. Coleta de informações para avaliar o progresso e medir se os critérios de saída foram atendidos (cobertura de riscos, requisitos, etc.).
2.11.2. Controle de Testes:
2.11.2.1. Uso das informações coletadas para orientar ações corretivas e ajustar o plano de teste. Exemplos incluem:
2.11.2.1.1. Repriorizar testes conforme surgem problemas.
2.11.2.1.2. Ajustar cronograma para atrasos
2.11.3. Conclusão do Teste:
2.11.3.1. Coleta de dados sobre atividades concluídas para consolidar experiências e informações. Isso ocorre em marcos do projeto, como a finalização de um nível de teste ou um projeto.
2.12. 5.3.1 Métricas Usadas em Testes
2.12.1. As métricas ajudam a mostrar o progresso e a qualidade do objeto de teste. Exemplos incluem:
2.12.1.1. Métricas de Progresso do Projeto: Tarefas concluídas, uso de recursos.
2.12.1.2. Métricas de Progresso do Teste: Casos de teste executados, tempo de execução.
2.12.1.3. Métricas de Qualidade do Produto: Tempo de resposta, disponibilidade.
2.12.1.4. Métricas de Defeitos: Número e prioridade dos defeitos encontrados.
2.12.1.5. Métricas de Risco e Cobertura: Nível de risco residual, cobertura de requisitos.
2.13. 5.3.2 Relatórios de Teste
2.13.1. Resumir e comunicar informações sobre o teste
2.13.2. Relatórios de Progresso: Fornecem atualizações contínuas sobre o status do teste. Devem incluir:
2.13.2.1. Período de teste e progresso.
2.13.2.2. Impedimentos e soluções.
2.13.2.3. Métricas de teste.
2.13.2.4. Novos riscos.
2.13.3. Relatórios de Conclusão: Elaborados quando um nível ou projeto de teste é finalizado. Incluem:
2.13.3.1. Resumo do teste e avaliação da qualidade.
2.13.3.2. Desvios do plano de teste.
2.13.3.3. Riscos e defeitos não corrigidos.
2.13.3.4. Lições aprendidas.
2.14. 5.3.3 Comunicação do Status dos Testes
2.14.1. Métodos de Comunicação
2.14.1.1. O status dos testes pode ser comunicado de várias maneiras, dependendo das necessidades de gerenciamento e da equipe. As opções incluem:
2.14.1.1.1. Comunicação verbal.
2.14.1.1.2. Painéis (CI/CD, gráficos de burn-down).
2.14.1.1.3. Canais eletrônicos (e-mail, chat).
2.14.1.1.4. Documentação online.
2.14.1.1.5. Relatórios formais de testes.
2.14.2. Importância da Comunicação
2.14.2.1. A comunicação deve ser adaptada para atender diferentes interesses dos stakeholders, especialmente em equipes distribuídas onde a comunicação direta é limitada.
2.15. 5.4 Gerenciamento de configuração (CM)
2.15.1. Usado para gerenciar componentes individuais que fazem parte de um sistema
2.15.2. Inclui o controle de versões do código fonte
2.15.3. Desenvolvedores devem fazer correções a partir versão correta do código
2.15.4. E testadores devem testar a versão correta do código
2.15.5. Todos os itens do testware precisam ser identificados, controlados, rastreados para mudanças e possuir relacionamentos entre si
2.15.6. Este processo ajuda a manter o rastreamento dos itens que sofreram alteração
2.15.7. Partes principais deste processo
2.15.7.1. Identificação da Configuração
2.15.7.1.1. Identifica todos os itens individiuas que se referem ao controle de versão dentro do projeto
2.15.7.2. Controle da Configuração
2.15.7.2.1. Avaliação, coordenação, aprovação e implementação de mudanças nos itens de configuração
2.15.7.2.2. Garante que qualquer mudança seja controla e monitorada
2.15.7.3. Controle do Status
2.15.7.3.1. Registra e reporta o status atual de item
2.15.7.4. Auditoria de Configuração
2.15.7.4.1. Assegura que o processo de controle é usado
2.16. 5.5 Gerenciamento de Defeitos
2.16.1. Objetivo: Identificar e tratar defeitos durante o teste, desde sua descoberta até o fechamento do relatório.
2.16.2. Fluxo de Trabalho: Inclui registrar, analisar, classificar e decidir a resposta a cada anomalia. É crucial seguir um processo definido por todos os stakeholders.
2.16.3. Relatórios de Defeitos: Devem fornecer informações suficientes para resolver problemas e monitorar a qualidade do produto. Um relatório típico inclui:
2.16.3.1. Identificador exclusivo.
2.16.3.2. Título e resumo da anomalia.
2.16.3.3. Data, autor e ambiente de teste.
2.16.3.4. Descrição detalhada da falha e passos para reprodução.
2.16.3.5. Severidade e prioridade de correção.
2.16.3.6. Status atual do defeito.
2.17. Independência do teste
2.17.1. Não é indicado que apenas o Desenvolvedor teste o seu trabalho
2.17.2. Testadores independentes têm mais vantagens
2.17.2.1. Enxergam mais defeitos
2.17.2.2. São Imparciais
2.17.3. Níveis de independência
2.17.3.1. 1 Nenhum testador independente, os desenvolvedores testam seu próprio código
2.17.3.2. 2 Testadores independentes dentro de uma equipe de desenvolvimento
2.17.3.3. 3 Uma equipe de testes independente dentro da organização, que se reporta ao gerente do projeto
2.17.3.4. 4 Especialistas em testes para um objetivo específico de teste
2.17.3.5. 5 Equipe de testes terceirizada ou independente da organização
2.18. Tarefas do Líder de Teste
2.18.1. Também chamado de gerente ou coordenador de teste
2.18.2. Coordena a estratégia de teste
2.18.3. Escreve/revisa a estratégia de teste
2.18.4. Planeja os testes
2.18.5. Prepara um gerenciamento de configuração do testware
2.18.6. Introduz métricas
2.18.7. Decide o que será automatizado
2.18.8. Seleciona ferramentas de apoio
2.18.9. Escreve relatório de resumo
2.19. Tarefas do Testador
2.19.1. Revisa e contribui nos planos de teste
2.19.2. Cria especificações de teste
2.19.3. Configura o ambiente de teste
2.19.4. Prepara e adquire dados de teste
2.19.5. Executa os testes
2.19.6. Automatiza os testes
2.19.7. Mede desempenho dos componentes e sistemas
2.19.8. Reve os testes desenvolvidos por outras pessoas
2.20. Organização do Teste
2.20.1. Planejamento de Teste
2.20.1.1. Determina o escopo e risco, identificando os objetivos do teste
2.20.1.2. Define a abordagem do teste
2.20.1.3. Decide o que testar
2.20.1.4. Agenda as atividades
2.20.1.5. Aloca recursos
2.20.1.6. Define métricas
2.20.2. Estimativa do teste
2.20.2.1. Estima esforço do teste
2.20.3. Estratégia do Teste
2.20.3.1. Analítica
2.20.3.2. Baseada em modelos
2.20.3.3. Abordagem metódica
2.20.3.4. Compatível com processos ou padrões
2.20.3.5. Dinâmica e heurística
2.20.3.6. Baseada em conselhos
2.20.3.7. Regressão
2.20.4. Monitoração do Progresso do Teste
2.20.4.1. Permite uma visibilidade sobre as atividades do teste
2.20.4.2. Usa métricas para isto
2.20.5. Relatório do teste
2.20.5.1. Constituído de informações resumidas sobre o esforço do teste
2.20.6. Controle do Teste
2.20.6.1. Descreve qualquer orientação ou ação corretiva tomada
2.21. Estrutura Plano de Teste segundo IEEE
2.21.1. Identificador
2.21.2. Introdução
2.21.3. Itens de teste
2.21.4. Funcionalidades a serem testadas
2.21.5. Funcionalidades a não serem testadas
2.21.6. Abordagem
2.21.7. Critérios Pass/Fail
2.21.8. Critério para Suspensão e Requisitos pp/ Retomada
2.21.9. Entregas do Teste
2.21.10. Atividades de Teste
2.21.11. Necessidades do ambiente
2.21.12. Necessidades de Treinamento e Pessoal
2.21.13. Cronograma
2.21.14. Riscos e Contingências
2.21.15. Aprovações
3. Técnicas de Modelagem de Teste
3.1. 4.1 Visão geral
3.1.1. As técnicas de teste dão suporte ao Testador na análise do teste (o que testar) e no projeto do teste (como testar), são 3 técnicas:
3.1.1.1. As Técnicas de Teste Caixa-Preta
3.1.1.2. As Técnicas de Teste Caixa-Branca
3.1.1.3. As Técnicas de Teste Baseada na Experiência
3.2. 4.2 Técnicas de Teste Caixa-Preta
3.2.1. Características
3.2.1.1. Pode ser funcional ou não-funcional
3.2.1.2. Baseia-se muito na documentação/ não olha para o código fonte
3.2.1.3. Também referenciada como Baseada na especificação
3.2.2. Técnicas
3.2.2.1. Partição de Equivalência (EP)
3.2.2.1.1. Quebra os valores de entrada em partições (classes)
3.2.2.1.2. Reduz a quantidade de testes escolhendo uma pequena seleção de valores de cada participação
3.2.2.1.3. Se um valor de uma partição falha, qualquer outro valor dessa partição também poderá falhar
3.2.2.1.4. Exemplo: Se um campo aceita valores de 0 a 100, se testa alguns valores entre 0 e 100
3.2.2.2. Análise do Valor Limite (BVA)
3.2.2.2.1. Testa os valores nos limites das partições
3.2.2.2.2. Exemplo: Se um campo aceita números de 0 a 100, se testa -1, 0 e 100, 101
3.2.2.2.3. Para cada valor limite pode ser usado 2 ou 3 casos de teste
3.2.2.3. Tabela de Decisão
3.2.2.3.1. Uma forma de capturar requisitos do sistema que pode conter condições lógicas
3.2.2.3.2. Condições e ações do sistema são identificadas a partir dela
3.2.2.3.3. Cada coluna da tabela corresponde uma regra que define uma combinação de condições e ações que o sistema tem que realizar
3.2.2.3.4. Considera-se um teste por coluna para se ter uma cobertura de todas as combinações
3.2.2.4. Transição de Estados
3.2.2.4.1. Baseada no conceito de estados
3.2.2.4.2. O testador tem que ser capaz de visualizar os estados do SW, transição entre estados e o que dispara uma mudança de estado
3.2.2.4.3. Os testes são desenhados para cobrir a sequência típica de estados, exercitando a sequência de transições ou testando transições inválidas
3.2.2.5. Teste por Caso de Uso
3.2.2.5.1. Caso de Uso
3.2.2.5.2. Tem o propósito de encontrar defeitos usando o produto de forma similar a que seria usado no cenário real
3.3. 4.3 Técnicas de Teste Caixa-Branca
3.3.1. Características
3.3.1.1. São métodos usados para analisar o comportamento do software por meio do código
3.3.1.2. Baseada na análise da estrutura do componente ou sistema
3.3.1.3. Também referenciada como teste de estrutura ou baseada na estrutura
3.3.2. 4.3.1 Teste de Instrução e Cobertura de Instrução (antes teste de sentença)
3.3.2.1. Esta técnica se concentra em validar a execução das instruções no código.
3.3.2.2. O objetivo é projetar casos de teste que executem o maior número possível de instruções para alcançar uma cobertura adequada.
3.3.2.3. A cobertura de instruções é expressa como uma porcentagem, calculada pela razão entre as instruções exercidas e o total de instruções executáveis. Quando se atinge 100%, garante-se que todas as instruções foram executadas ao menos uma vez.
3.3.2.4. No entanto, essa cobertura não identifica defeitos dependentes de dados (por exemplo, uma divisão por zero que ocorre apenas quando o denominador é zero) e não assegura que todas as decisões lógicas foram testadas.
3.3.3. 4.3.2 Teste de Ramificação e Cobertura de Ramificação (antes teste de decisão ou desvio)
3.3.3.1. Este método avalia a cobertura das ramificações (decisões condicionais e incondicionais) no fluxo de controle do código.
3.3.3.2. O objetivo é modelar casos de teste que percorram todas as ramificações até alcançar uma cobertura satisfatória.
3.3.3.3. A cobertura de ramificação, também medida em percentual, se atinge ao executar todas as ramificações do código, o que assegura a execução de cada caminho condicional (verdadeiro ou falso).
3.3.3.4. A cobertura de ramificação é mais completa que a cobertura de instrução, pois, ao atingir 100% de cobertura de ramificação, também se alcança 100% de cobertura de instrução.
3.3.3.5. Ex: em um app se fizer sol mostrar uma msg / se fizer chuva mostra outra msg - Ramificação - 2 possibilidades - 2 saidas
3.3.4. 4.3.3 O valor do Teste Caixa-Branca
3.3.4.1. Um ponto forte das técnicas caixa-branca é que elas consideram toda a implementação do código, facilitando a descoberta de defeitos, mesmo em casos de especificações incompletas ou imprecisas.
3.3.4.2. Essas técnicas podem ser aplicadas em testes estáticos (análise do código sem execução real) e são úteis para pseudocódigo e lógicas complexas representadas por fluxogramas.
3.3.4.3. Embora os testes caixa-preta não ofereçam uma medida precisa de cobertura de código, as técnicas caixa-branca permitem mensurar objetivamente a cobertura, auxiliando na criação de testes adicionais para cobrir mais áreas e aumentar a confiança na qualidade do software.
3.4. 4.4 Técnicas de Teste Baseadas na Experiência
3.4.1. Características
3.4.1.1. Conhecimento e intuição das pessoas são usados para derivar os casos de teste
3.4.2. Técnicas
3.4.2.1. 4.4.1 Suposição de Erro
3.4.2.1.1. Baseada na experiência do testador
3.4.2.1.2. O testador pode supor onde potenciais problemas podem ser encontrados no SW
3.4.2.1.3. Também chamada advinhação de erros
3.4.2.2. 4.4.2 Testes Exploratórios
3.4.2.2.1. É o teste mais efetivo para encontrar defeito
3.4.2.2.2. Caracteristicas
3.4.2.2.3. Ad Hoc (latim)
3.4.2.2.4. Baseado nos objetivos de teste
3.4.2.2.5. Mais efetiva quando não existe especificação disponível
3.4.2.2.6. Técnica informal governada pelo tempo disponível, ou determinado
3.4.2.2.7. Basicamente busca assegurar que a maior parte das funcionalidades está funcionando sem ter que fazer todos os testes esperados
3.4.2.3. 4.4.3 Testes baseados em Lista de Verificação
3.4.2.3.1. Baseado em tecnicas já existente de alguém que tem conhecimento e adota certas tecnicas
3.4.2.3.2. Consistem na modelagem, implementação e execução de testes a partir de uma lista que abrange diversas condições de teste.
3.4.2.3.3. Elas suportam tanto testes funcionais quanto não funcionais, e precisam ser atualizadas regularmente para incorporar novos defeitos e evitar obsolescência.
3.4.2.3.4. Embora ofereçam diretrizes e consistência, listas de alto nível podem resultar em variabilidade nos testes, afetando a repetibilidade
3.4.2.3.5. Resumo do Processo: - Criação da Lista: Baseia-se em práticas comuns e conhecimento sobre SW - Execução dos Testes: O testador vai verificando cada item da lista. - Atualização: Após testar, a lista é ajustada conforme as descobertas.
3.5. 4.5 Abordagens de Teste Baseadas na Colaboração
3.5.1. Objetivo: Focar na detecção e prevenção de defeitos por meio de colaboração e comunicação entre equipes.
3.6. 4.5.1 Escrita Colaborativa de Histórias de Usuários
3.6.1. Definição: Uma história de usuário descreve um recurso valioso para o usuário ou comprador.
3.6.2. 3C das Histórias de Usuário:
3.6.2.1. Confirmação: Critérios de aceite que determinam a aceitação da história.
3.6.2.2. Cartão: Meio de descrição da história (ex: cartão físico ou digital).
3.6.2.3. Conversação: Discussões sobre o uso do software (documentadas ou verbais).
3.6.3. Formato Comum: "Como [ator], quero [meta], para que eu possa [valor]."
3.6.4. Técnicas Colaborativas: Brainstorming e mapeamento mental para construir histórias em equipe.
3.6.5. Características das Boas Histórias: Independentes, Negociáveis, Valiosas, Estimáveis, pequenas e Testáveis (INVEST).
3.7. 4.5.2 Critérios de Aceite
3.7.1. Definição: Condições que uma história deve atender para ser aceita pelos stakeholders.
3.7.2. Funções dos Critérios de Aceite:
3.7.2.1. Definir o escopo da história.
3.7.2.2. Chegar a um consenso entre stakeholders.
3.7.2.3. Descrever cenários positivos e negativos.
3.7.2.4. Servir como base para testes de aceite.
3.7.3. Formatos Comuns:
3.7.3.1. Orientado a Cenários: Exemplo: formato Given/When/Then.
3.7.3.2. Orientado por Regras: Listas de verificação ou mapeamentos tabulados.
3.8. 4.5.3 Desenvolvimento Orientado por Teste de Aceite (ATDD)
3.8.1. Definição: Abordagem que prioriza a criação de casos de teste antes da implementação.
3.8.2. Processo:
3.8.2.1. Workshop de Especificação: Análise e discussão da história e critérios de aceite.
3.8.2.2. Criação de Casos de Teste: Desenvolvidos a partir dos critérios de aceite, abrangendo cenários positivos e negativos.
3.8.3. Características dos Casos de Teste:
3.8.3.1. Escritos em linguagem natural.
3.8.3.2. Incluem pré-condições, entradas e pós-condições.
3.8.3.3. Devem cobrir todas as características da história, sem duplicação.
3.8.4. Automação: Casos de teste podem ser automatizados, tornando os testes de aceite requisitos executáveis.
3.9. Identificando as condições de teste e projetando os casos de teste
3.9.1. Durante a Análise de teste
3.9.1.1. Analisa a documentação de base de teste para determinar o que testar
3.9.1.2. Identifica cada Condição de Teste
3.9.1.2.1. É algum item ou evento que precisa ser verificado por um Caso de Teste
3.9.1.2.2. Exemplo de item: função ou elemento do sistema
3.9.2. Durante a Modelagem
3.9.2.1. Detalha a estratégia de teste considerando os riscos
3.9.2.2. Dados de teste e Casos de Teste são especificados e criados
3.9.2.3. Caso de Teste
3.9.2.3.1. Conjunto de valores de entrada, pré-condições de execução, resultados esperados e pós-condições de execução, desenvolvidos para cobrir certas condições de teste
3.9.2.4. Resultados esperados devem ser produzidos como parte da especificação de um caso de teste
3.9.3. Durante a Implementação
3.9.3.1. Casos de teste são desenvolvidos, implementados, priorizados e organizadas na especificação de procedimento de teste
3.9.4. Durante a Execução
3.9.4.1. Vários e scripts de testes automatizados formam uma sequência de execução de teste que define a ordem em que os procedimentos, e/ou os scripts automatizados serão executados e quem os executará
4. :three: Teste Estático
4.1. Técnicas estáticas
4.1.1. Examinam a documentação do projeto e código-fonte sem executá-los o SW
4.1.2. Compreende as atividades de revisão, inspeção e análise estática do código
4.1.3. Podem ser empregadas bem antes da execução do teste dinâmico
4.2. Revisões e o processo de teste
4.2.1. Através de revisões os defeitos podem ser identificados mais cedo
4.2.2. Tradicionalmente revisões são manuais, mas podem ser usadas ferramentas de apoio
4.2.3. Qualquer coisa pode ser revisada
4.2.3.1. Especificação de requisitos
4.2.3.2. Documentos do projeto
4.2.3.3. Especificações de teste
4.2.3.4. Código-fonte
4.2.3.5. Plano de teste, casos de teste e scripts de teste
4.2.3.6. Etc
4.2.4. Fases de uma revisão formal
4.2.4.1. Planejamento
4.2.4.2. Kick-off
4.2.4.3. Preparação individual
4.2.4.4. Reunião de revisão
4.2.4.5. Retrabalho
4.2.4.6. Acompanhamento
4.2.5. Papéis envolvidos em revisão formal
4.2.5.1. Gerente
4.2.5.1.1. Quem toma decisão de iniciar a revisão
4.2.5.1.2. Determina os objetivos da revisão
4.2.5.1.3. Aloca o tempo das pessoas para revisão
4.2.5.2. Moderador
4.2.5.2.1. Lidera, planeja e executa a revisão
4.2.5.2.2. Modera a reunião permitindo que os vários pontos de vista sejam apresentados
4.2.5.3. Autor
4.2.5.3.1. Quem criou o item a ser inspecionado/revisado
4.2.5.4. Revisores
4.2.5.4.1. Conhecidos como checadores ou inspetores
4.2.5.4.2. Procuram por defeitos no item sob revisão
4.2.5.5. Escrivão / Secretário
4.2.5.5.1. Registra os defeitos mencionados e qualquer sugestão
4.3. Análise estática por Ferramentas
4.3.1. Análise Estática
4.3.1.1. Técnica para analisar o código e procurar por erros de sintaxe, violações de padrões e outros possíveis erros no código-fonte sem executá-lo
4.3.1.2. Permite detectar defeitos antes da execução do teste
4.3.2. Pode ser usado compilador para analisar estaticamente o código
4.3.3. Exemplos de defeitos encontrados
4.3.3.1. Código inacessível
4.3.3.2. Variáveis não declaradas
4.3.3.3. Parâmetros incorretos
4.3.3.4. Procedimentos e funções não usadas
4.3.3.5. Violação de segurança
4.3.3.6. Erro de sintaxe
4.3.3.7. Etc
4.3.4. Fluxo de controle
4.3.4.1. Técnica básica para a realização da análise estática de código
4.3.4.2. É a representação gráfica de como o código escrito é executado
4.3.5. Complexidade ciclomática
4.3.5.1. É uma medida da complexidade de um fluxo de controle.
4.3.5.2. Identifica como o código é difícil de entender, testar e manter
4.3.5.3. Identifica o risco associado ao teste de um programa.
4.4. 3.1.3 Diferença entre testes estáticos e dinâmicos
4.4.1. Testes estáticos encontram defeitos diretamente; dinâmicos causam falhas que são analisadas posteriormente.
4.4.2. Testes estáticos aplicam-se a produtos não executáveis; dinâmicos, a executáveis.
4.4.3. Testes estáticos medem qualidade sem execução (ex.: manutenção); dinâmicos, dependem da execução (ex.: performance).
4.4.4. Teste estático encontra defeitos / Teste dinâmico encontra falhas
4.5. Defeitos Típicos Detectáveis por Teste Estático
4.5.1. Defeitos em requisitos, design e codificação, desvios de padrões, especificações de interface incorretas e vulnerabilidades de segurança.
4.6. 3.2 Processo de feedback e revisão
4.6.1. A norma ISO/IEC 20246
4.6.2. O feedback frequente dos stakeholders é crucial para identificar problemas de qualidade logo no início do SDLC, evitando retrabalho, perda de prazos e possíveis fracassos do projeto. Ele garante que os requisitos sejam compreendidos e implementados corretamente, permitindo que a equipe se concentre em recursos valiosos e reduza riscos.
4.7. 3.2.2 Atividades do Processo de Revisão
4.7.1. Início da Revisão: Garantir que todos os participantes estejam prontos, com acesso ao material necessário e compreendendo suas funções
4.7.2. Planejamento: Define-se o escopo da revisão, incluindo objetivos, produtos a serem revisados, critérios de qualidade e prazos
4.7.3. Revisão Individual: Cada revisor analisa o produto de trabalho para identificar anomalias e recomendações, utilizando técnicas específicas, como listas de verificação.
4.7.4. Comunicação e Análise de Problemas: As anomalias identificadas são discutidas em uma reunião de revisão, onde se decide seu status e as ações necessárias.
4.7.5. Correção e Relatório: Para cada defeito identificado, um relatório é gerado para monitorar ações corretivas. Uma vez atendidos os critérios de saída, o produto pode ser aceito e os resultados da revisão são documentados.
4.8. 3.2.3 Funções e Responsabilidades nas Revisões
4.8.1. Gerente: Define o que deve ser revisado e fornece recursos.
4.8.2. Autor: Cria e corrige o produto revisado.
4.8.3. Moderador: Facilita as reuniões de revisão.
4.8.4. Relator: Registra anomalias e decisões.
4.8.5. Revisor: Realiza a avaliação do produto.
4.8.6. Líder da Revisão: Organiza o processo de revisão.
4.9. 3.2.4 Tipos de revisão
4.9.1. Revisão Informal
4.9.1.1. Não existe processo formal
4.9.1.2. Muito empregada no início do ciclo de vida do SW e da documentação
4.9.1.3. Exemplo: o autor do documento faz a análise do seu próprio trabalho
4.9.2. Acompanhamento (Walkthrough)
4.9.2.1. É o autor que conduz a reunião
4.9.2.2. O autor apresenta o material em ordem lógica a um grupo
4.9.2.3. A reunião não tem restrição de tempo de duração
4.9.2.4. Principal propósito é a aprendizagem, treinar os envolvidos no projeto e obter o entendimento.
4.9.3. Revisões Técnicas
4.9.3.1. Inclui a Revisão por Pares (Peer review)
4.9.3.2. Inclui avaliações técnicas de artefatos específicos
4.9.3.3. É considerada formal porque é caracterizada por procedimentos documentados
4.9.3.4. Envolve encontros estruturados onde um par (ou pares) analisa o trabalho de outra pessoa
4.9.3.4.1. Devem ser lideradas por um moderador treinado, não sendo o autor do documento
4.9.3.5. Pode ser guiada por checklists
4.9.3.6. Podem ser conduzidas por um moderador treinado (que não seja o autor)
4.9.4. Inspeção
4.9.4.1. É um tipo mais formal de revisão
4.9.4.2. Ocorre por meio de uma reunião com pessoas envolvidas no projeto onde se analisa, verifica e testa artefatos do SW
4.9.4.3. Deve ser liderada por um moderador treinado, que não pode ser o autor
4.9.4.4. A preparação antecipada para a reunião é essencial
4.9.4.5. Tem papéis bem definidos nesta revisão
4.10. 3.2.5 Fatores de Sucesso para Revisões
4.10.1. Definir objetivos claros, escolher o tipo de revisão adequado, realizar revisões em partes pequenas, fornecer feedback e tempo de preparação, e garantir o suporte da gerência. Integrar revisões à cultura organizacional promove aprendizado e melhoria contínua.
5. Fundamentos do Teste
5.1. 1.1 O que é teste?
5.1.1. É um processo composto de várias atividades
5.1.1.1. Planejamento e controle
5.1.1.2. Seleção das condições de teste (itens de teste)
5.1.1.3. Modelagem dos casos de teste
5.1.1.4. Execução do teste
5.1.1.5. Verificação dos resultados
5.1.1.6. Avaliação dos critérios de conclusão
5.1.1.7. Relatar sobre o processo de teste e o sistema sob teste
5.1.1.8. Atividades de encerramento
5.1.2. Pode ter objetivos diferentes (encontrar defeitos, ganhar confiança, prevenir defeitos)
5.1.3. Deve acontecer o mais cedo possível no ciclo de vida do projeto
5.1.4. Inclui a revisão de documentos e códigos fonte
5.1.5. Enquanto o Teste destaca os defeitos identificando falhas, a depuração investiga a causa das falhas - encontrar os defeitos (realizada normalmente por programadores)
5.2. 1.1.1 Objetivos do teste
5.2.1. • Avaliar produtos de trabalho, como requisitos, histórias de usuários, projetos e código;
5.2.2. • Detectar falhas e defeitos;
5.2.3. • Garantir a cobertura necessária de um objeto de teste;
5.2.4. • Reduzindo o nível de risco de qualidade de sw inadequado;
5.2.5. • Verificar se os requisitos especificados foram atendidos;
5.2.6. • Verificar se um objeto de teste está em conformidade com os requisitos contratuais, legais e normativos;
5.2.7. • Fornecer informações aos stakeholders para que eles possam tomar decisões informadas;
5.2.8. • Fornecer informações aos stakeholders para que eles possam tomar decisões informadas;
5.2.9. • Criar confiança na qualidade do objeto de teste;
5.2.10. • Validar se o objeto de teste está completo e funciona conforme o esperado pelos stakeholders.
5.3. 1.1.2 Teste e depuração
5.3.1. São atividades distintas, mas complementares . O teste busca identificar problemas, enquanto a depuração se concentra em resolvê-los.
5.3.1.1. Depuração: É o processo que os devs fazem de investigar e corrigir as causas das falhas identificadas durante os testes/debug e corrigi-las)
5.3.1.2. Teste: É a atividade de avaliar o software para identificar falhas e defeitos - não corrige ao encontrar o defeito, geralmente documenta para o dev corrigir
5.4. 1.2.2 Testes e Garantia da Qualidade
5.4.1. Testes: concentra-se no produto, buscando identificar defeitos, aumentar a confiança e gerenciar riscos associados. É uma prática de controle de qualidade (QC) que avalia se o produto atende aos requisitos.
5.4.2. Garantia da Qualidade (QA): A QA foca nos processos, investigando as causas raízes dos defeitos, estudando o processo de testes e propondo melhorias. É uma abordagem preventiva que busca evitar a ocorrência de defeitos.
5.4.3. Relação entre as Áreas: Embora sejam áreas inter-relacionadas, teste e QA são distintas. O teste é uma ferramenta dentro do QC, enquanto a QA se ocupa de assegurar que os processos sejam eficazes.
5.4.4. Garantia da Qualidade
5.4.4.1. Gerenciamento de qualidade
5.4.4.1.1. Integrar e coordenar as atividades de qualidade em toda a organização.
5.4.4.1.2. Alinhar os objetivos de qualidade com as metas de negócios.
5.4.4.1.3. Monitorar e avaliar continuamente os processos de qualidade para garantir eficácia.
5.4.4.2. Garantia de qualidade
5.4.4.2.1. Prevenir defeitos por meio da melhoria contínua dos processos.
5.4.4.2.2. Estabelecer padrões e melhores práticas para o desenvolvimento e testes.
5.4.4.2.3. Promover uma cultura organizacional focada na qualidade.
5.4.4.3. Controle de qualidade
5.4.4.3.1. Identificar e corrigir defeitos no produto final antes da entrega.
5.4.4.3.2. Validar que o software atende aos requisitos especificados.
5.4.4.3.3. Aumentar a confiança na qualidade do produto final por meio de testes e avaliações.
5.4.4.4. Relação entre qualidade e teste
5.4.4.4.1. Integração: A QA define os processos que guiam os testes, enquanto os testes fornecem feedback essencial para a melhoria dos processos de QA.
5.4.4.4.2. Ciclo de Melhoria: Resultados de testes ajudam a identificar áreas de melhoria nos processos, promovendo a prevenção de defeitos.
5.4.4.4.3. Cultura de Qualidade: Ambos incentivam a colaboração da equipe em torno da qualidade, estabelecendo uma responsabilidade compartilhada.
5.5. 1.2.3 Principais termos
5.5.1. Erro
5.5.1.1. Ação humana que produz um resultado incorreto
5.5.1.2. Também conhecido como engano
5.5.1.3. Pode ser um erro de programação, interpretação ou documentação.
5.5.1.4. Exemplo: váriavel digitada com erro (ex: em vez do programador digitar $cliente digitou $cliete)
5.5.2. Defeito
5.5.2.1. Defeito em um componente ou sistema que leva o componente ou sistema falhar quando é executado
5.5.2.2. Uma imperfeição ou deficiência em um produto de trabalho que não atende aos seus requisitos ou especificações ou prejudica o uso pretendido.
5.5.2.3. Manifestação de um erro no software
5.5.2.4. Também conhecido como bug
5.5.2.5. Defeitos são geralmente associados a erros de codificação e podem ser identificados através de testes.
5.5.2.6. Exemplo: a variável $desconto foi declarada, mas não foi usada na rotina de cálculo do preço
5.5.3. Falha
5.5.3.1. Diferença indesejável entre o observado e o esperado (defeito encontrado)
5.5.3.2. Um evento em que um componente ou sistema não atende a seus requisitos dentro dos limites especificados.
5.5.3.3. Ocorre quando o software não funciona como esperado ou não atende aos requisitos especificados. Uma falha é o resultado de um erro que foi introduzido no código
5.5.3.4. Exemplo: uma ação que era para ocorrer não ocorreu devido a variável $cliente ter sido digitada incorretamente no código
5.6. 1.3 Os 7 príncipios de Teste
5.6.1. 1 Teste demonstra a presença de defeitos, não ausência
5.6.1.1. Mostrar que ele achou um defeito não que o SW está livre deles
5.6.1.2. Teste reduz a probabilidade de defeitos descobertos
5.6.2. 2 Teste exaustivo é impossível
5.6.2.1. Não é viavel testar tudo (tempo e dinheiro)
5.6.3. 3 Teste antecipado
5.6.3.1. Iniciar o testes o mais cedo possível
5.6.3.2. shift-left => promove a integração dos testes desde as etapas iniciais, como a concepção e o desenvolvimento.
5.6.4. 4 Os defeitos se agrupam
5.6.4.1. Algumas áreas do SW contêm mais defeitos que outras
5.6.5. 5 Os testes se degradam (Paradoxo do Pesticida)
5.6.5.1. Repetição contínua dos mesmos testes perde a eficácia
5.6.5.2. Se não mudar os testes não vai encontar novos defeitos / necessidade da inovação
5.6.5.3. Os testes param de funcionar
5.6.5.3.1. O que fazer? Renovar: criar cenários novos / usar outras tecnicas de abordagem, etc..
5.6.6. 6 Teste depende do contexto
5.6.6.1. Cada tipo de SW pode ser testado de forma diferente
5.6.6.1.1. Quanto maior o risco de uma funcionalidade maior e mais testes que ela precisa
5.6.7. 7 A ilusão da ausência de erros
5.6.7.1. SW sem defeitos não necessariamente vai satisfazer o usuário final
5.6.7.2. É necessário que os requisitos tenham sido desenvolvidos de acordo com a necessidade do usuário final
5.6.8. Quanto teste é suficiente?
5.6.8.1. Não testamos tudo porque não temos tempo
5.6.8.2. Testes exaustivos são impraticáveis
5.6.8.2.1. Não temos tempo
5.6.8.2.2. Usa muito Recursos
5.6.8.2.3. Custa caro
5.6.8.3. Os riscos vão dizer quanto tempo precisa ser alocado para os testes
5.6.8.4. Restrições de tempo e orçamento são consideradas
5.6.8.5. Testes devem ser focados em áreas específicas do SW onde existe um potencial maior de risco de falha
5.6.8.6. Executar primeiro os casos de teste mais importantes
5.6.8.6.1. Significa priorizar os testes
5.7. 1.4.1 Atividades e tarefas de Teste
5.7.1. Planejamento
5.7.1.1. Determina os objetivos de teste
5.7.1.2. Determina O QUE, PORQUE e COMO algo será testado
5.7.1.3. Determina abordagem/estratégia
5.7.1.4. Determina riscos
5.7.1.5. Determinar os recursos requeridos
5.7.1.6. Agenda as atividades
5.7.1.7. Especifica critérios de saída
5.7.2. Monitoramento & Controle do teste
5.7.2.1. Ajuda a alcançar o que foi planejado
5.7.2.2. Compara o progresso do Teste contra o Plano de Teste
5.7.2.2.1. Verificação contínua das atividades de teste e comparação com o plano
5.7.2.3. Ocorre durante todo o Teste
5.7.2.4. Pode tomar ações corretivas
5.7.3. Análise de teste
5.7.3.1. Responde à pergunta "o que testar?"
5.7.3.2. Transforma os objetivos de teste em Condições de Teste
5.7.3.2.1. Indicam “o quê” será testado
5.7.3.3. Revisa a base de teste (documentação sobre a qual os casos de teste são construídos)
5.7.3.4. Identificação dos recursos testáveis e definição das condições de teste, priorizando riscos.
5.7.3.5. Avalia a testabilidade
5.7.3.6. Considera a cobertura de testes
5.7.4. Modelagem de teste
5.7.4.1. Responde à pergunta "como testar?"
5.7.4.2. Modela o ambiente de teste
5.7.4.3. Inicia qui a fazer listas de casos de teste ou de possibilidade para testar (se detalhes)
5.7.4.4. Modela e prioriza condições de teste
5.7.4.5. Criação de condições e casos de teste, identificação de requisitos de dados e planejamento do ambiente de teste
5.7.5. Implementação do teste
5.7.5.1. Cria dados/massa de teste e criação do ambiente para os tetes
5.7.5.2. Cria os passos/procedimentos de teste
5.7.5.3. Transforma as Condições de teste em Casos de teste
5.7.5.3.1. Especificam em detalhes como iremos testar uma determinada condição de teste
5.7.5.3.2. Para cada condição de teste pode haver mais de um caso de teste
5.7.5.4. Desenvolve, implementa e prioriza casos de teste
5.7.5.5. Desenvole e prioriza procedimentos de teste
5.7.5.6. Escreve os scripts de teste
5.7.5.7. Verifica se o ambiente de teste está configurado
5.7.6. Execução do teste
5.7.6.1. É onde o teste de fato é realizado
5.7.6.2. Executa casos de teste manualmente ou usando ferramenta de automação
5.7.6.3. Registra as saídas da execução do teste
5.7.6.4. Checa os resultados
5.7.6.5. Gerenciamento dos defeitos
5.7.7. Conclusão de teste
5.7.7.1. Um relatório de conclusão do teste é criado e comunicado aos stakeholders.
5.7.7.2. O ambiente de teste é encerrado em um estado acordado.
5.8. 1.4.3 Testware
5.8.1. O testware é o conjunto de produtos de trabalho gerados durante as atividades de teste
5.8.1.1. Planejamento de Testes
5.8.1.1.1. Produtos: Plano de testes, cronograma de testes, registro de riscos e critérios de entrada/saída
5.8.1.1.2. Registro de Riscos: Lista de riscos com probabilidade, impacto e estratégias de mitigação.
5.8.1.2. Monitoramento e Controle de Testes
5.8.1.2.1. Produtos: Relatórios de progresso, documentação de diretrizes de controle e informações sobre riscos.
5.8.1.3. Análise de Teste:
5.8.1.3.1. Produtos: Condições de teste priorizadas e relatórios de defeitos.
5.8.1.4. Modelagem de Teste:
5.8.1.4.1. Produtos: Casos de teste priorizados, cartas de teste, itens de cobertura, requisitos de dados e ambiente de teste.
5.8.1.5. Implementação de Teste:
5.8.1.5.1. Produtos: Procedimentos de teste, scripts de teste automatizados, conjuntos de teste, dados de teste e elementos do ambiente de teste (stubs, drivers, simuladores).
5.8.1.6. Execução de Testes:
5.8.1.6.1. Produtos: Registros de testes e relatórios de defeitos.
5.8.1.7. Conclusão de Teste:
5.8.1.7.1. Produtos: Relatório de conclusão do teste, itens de ação para melhorias, lições aprendidas e solicitações de alteração.
5.8.2. É tudo o que nós produzimos para cada uma das etapas de teste (documentação)
5.9. 1.4.4 Rastreabilidade entre a Base de Teste e o Testware
5.9.1. Conecta os elementos da base de teste (informações que inspira o testes, como condições, requisitos, historias, especificações, etc) com os resultados e defeitos detectados, permitindo avaliar a cobertura dos testes a qualidade do produto, a eficácia do processo e o alinhamento com os objetivos de negócio
5.9.1.1. Base de teste
5.9.1.1.1. focado em informações e documentação que sustentam os testes.
5.9.1.2. Testware
5.9.1.2.1. inclui ferramentas, scripts e resultados gerados durante a execução dos testes
5.10. 1.4.5 Papeis/funções no Teste
5.10.1. Gerenciamento de testes
5.10.1.1. Principais atividades incluem planejamento, monitoramento e conclusão dos testes.
5.10.1.2. Guiar e liderar o time
5.10.2. Testador
5.10.2.1. Focado na execução técnica dos testes, esse papel abrange análise, modelagem, implementação e execução dos testes.
5.11. 1.5.1 Habilidades genéricas para testadores
5.11.1. Conhecimento sobre Testes: Entender técnicas de teste para aumentar a eficácia.
5.11.2. Meticulosidade e Atenção aos Detalhes: Ser cuidadoso e metódico para identificar defeitos difíceis.
5.11.3. Habilidades de Comunicação: Comunicar-se efetivamente com stakeholders, relatar e discutir defeitos.
5.11.4. Pensamento Analítico e Criativo: Usar análise crítica e criatividade para melhorar os testes.
5.11.5. Conhecimento Técnico: Utilizar ferramentas de teste adequadas para aumentar a eficiência.
5.11.6. Conhecimento do Domínio: Compreender o contexto do negócio para interagir com usuários e representantes.
5.12. 1.5.3 Independência dos testes
5.12.1. A independência dos testes aumenta a eficácia na identificação de defeitos, pois minimiza os vieses cognitivos entre autores e testadores.
5.12.1.1. Sem independência: Testes realizados pelo autor
5.12.1.2. Alguma independência: Testes por colegas do mesmo time
5.12.1.3. Alta independência: Testes por testadores da mesma organização.
5.12.1.4. Independência muito alta: Testes por testadores de fora da organização.
5.13. Necessidade dos testes
5.13.1. Testamos para construir confiabilidade
5.13.2. Menos defeitos = menor chance do SW falhar
5.13.3. Ajudam a aumentar a qualidade do SW qdo defeitos são encontrados e removidos
5.14. Psicologia do Teste
5.14.1. O testador tem propósito primário de achar defeitos e falhas no SW
5.14.2. A atividade de teste pode ser vista como destrutiva no desenvolvimento de SW
5.14.3. Uma boa comunicação é essencial entre Testador e Desenvolvedor
5.14.4. O Testador precisa reportar defeitos sem agredir o Desenvolvedor
5.14.5. Testador precisar ter habilidades
5.14.5.1. Bom comunicador
5.14.5.2. Curioso
5.14.5.3. Paciente
5.14.5.4. Meticuloso
5.14.5.5. Etc.
6. :two: Teste durante o SDLC = CVDS => ciclo de vida do desenvolvimento do SW
6.1. Modelos SDLC
6.1.1. Modelos Iterativos
6.1.1.1. Modelo em Espiral: Combina elementos de design e prototipagem, permitindo revisões contínuas.
6.1.1.2. Prototipagem: Desenvolve protótipos do software para obter feedback antes da finalização.
6.1.2. Modelos sequenciais
6.1.2.1. Modelo V
6.1.2.1.1. Modelo de ciclo de vida de desenvolvimento e Teste de SW
6.1.2.1.2. Mostra a relação do nível de teste com o nível de desenvolvimento
6.1.2.1.3. Cada atividade de desenvolvimento tem uma atividade de teste correspondente
6.1.2.1.4. Testadores devem ser envolvidos na revisão de documentos o mais cedo possível
6.1.2.1.5. É dividido normalmente em 4 níveis, mas pode ter mais dependendo da metodologia da organização
6.1.2.2. Modelo em Cascata
6.1.2.2.1. Fases distintas e sequenciais, onde cada fase deve ser concluída antes da próxima iniciar.
6.1.3. Modelo Incremental
6.1.3.1. Processo Unificado Racional (RUP) => é uma abordagem mais formal e estruturada, adequada para projetos maiores e mais complexos, que exigem rigor nas fases de desenvolvimento e controle de qualidade, garantindo que o sistema seja desenvolvido de maneira incremental, mas com uma forte ênfase na documentação e planejamento detalhado.
6.1.3.2. Divisão em Incrementos: Cada incremento é uma parte funcional do sistema, mas não precisa ser o sistema completo. Ao longo do tempo, esses incrementos vão se somando até formar o produto final completo.
6.1.3.3. Desenvolvimento e Teste Contínuos: Após a conclusão de cada incremento, ele é testado e validado.
6.1.3.4. Feedback e Ajustes: permitindo que o sistema seja ajustado conforme necessário
6.1.3.5. Entrega Gradual: os usuários podem começar a usar a funcionalidade básica do sistema em estágios iniciais, enquanto os desenvolvedores continuam a adicionar novas funcionalidades.
6.2. Métodos e Práticas Ágeis
6.2.1. ATDD (Desenvolvimento Orientado por Testes de Aceite): Foca em critérios de aceite definidos antes do desenvolvimento.
6.2.1.1. Foco: clientes e usuários / teste de aceitação pelo cliente/usuario
6.2.2. BDD (Desenvolvimento Orientado pelo Comportamento): Utiliza linguagem natural para descrever o comportamento do software.
6.2.2.1. PO define o comportamento, geralmente usando o formato "Dado-Quando-Então"
6.2.3. TDD (Desenvolvimento Orientado por Testes): Escreve testes antes do código, guiando o desenvolvimento.
6.2.3.1. Foco: Escrever testes de unidade antes de desenvolver o código.
6.2.4. DDD (Domain-Driven Design): Concentra-se em modelar o software em torno do domínio do problema.
6.2.4.1. Construida de maneira mais coletiva. Ex: Time que não tem PO, o time é o foco
6.2.5. XP (Extreme Programming): Enfatiza a flexibilidade e feedback rápido.
6.2.6. FDD (Feature-Driven Development): Foca na entrega de funcionalidades específicas.
6.2.7. Kanban e Lean IT: Métodos de gerenciamento visual e eficiência no fluxo de trabalho.
6.2.8. Scrum: Estrutura ágil que divide o trabalho em sprints.
6.3. 2.1.1 Impacto do SDLC nos Testes - SDLC (Software Development Life Cycle)
6.3.1. Escopo e Cronograma: Define quais atividades de teste são realizadas e quando, como níveis e tipos de teste.
6.3.2. Detalhamento da Documentação: O nível de detalhamento e a formalidade da documentação de teste variam conforme o modelo SDLC.
6.3.3. Técnicas e Abordagens de Teste: A escolha das técnicas de teste e metodologias (manuais ou automatizadas) é afetada pelo SDLC.
6.3.4. Automação de Testes: A extensão da automação de testes depende do modelo utilizado e da sequência de entregas.
6.3.5. Papel do Testador: As responsabilidades e envolvimento dos testadores mudam conforme as fases do SDLC.
6.4. 2.1.2 CVDS e boas práticas de testes
6.4.1. Para cada atividade de desenvolvimento de software, há uma atividade de teste correspondente
6.4.2. Diferentes níveis de teste (aceite, componente, integração..) têm objetivos de teste específicos e diferentes
6.4.3. A análise e a modelagem do teste, durante a fase de desenvolvimento correspondente do SDC, para que o teste possa aderir ao princípio do teste antecipado
6.4.4. Os Testadores estão envolvidos na revisão dos produtos de trabalho, de modo que esse teste antecipado e a detecção de defeitos possam apoiar a estratégia shift-left.
6.5. 2.1.4 DevOps e Testes
6.5.1. DevOps é uma abordagem organizacional que visa a criar sinergia, fazendo com que o desenvolvimento (incluindo os testes) e as operações trabalhem juntos para atingir um conjunto de objetivos comuns.
6.5.2. O DevOps exige uma mudança cultural em uma organização para preencher as lacunas entre o desenvolvimento (incluindo testes) e as operações, tratando suas funções com o mesmo valor.
6.5.3. O DevOps promove a autonomia da equipe, feedback rápido, cadeias de ferramentas integradas e práticas técnicas como Integração Contínua (CI) e Entrega Contínua (CD).
6.5.4. Benefícios do DevOps para Testes
6.5.4.1. Feedback Rápido: Permite avaliar rapidamente a qualidade do código e identificar impactos negativos de alterações.
6.5.4.2. Shift-Left: A prática de Integração Contínua (CI) incentiva os desenvolvedores a escrever código de alta qualidade com testes desde o início.
6.5.4.3. Automação: Facilitada por práticas como CI/CD, promove ambientes de teste estáveis e reduz a necessidade de testes manuais repetitivos.
6.5.4.4. Qualidade Não Funcional: Aumenta a visibilidade em´aspectos como performance e confiabilidade do software.
6.5.4.5. Minimização de Riscos: A automação de testes de regressão reduz o risco de falhas em versões novas.
6.5.5. Desafios do DevOps
6.5.5.1. Estabelecimento do Pipeline: É necessário definir e manter um pipeline de entrega eficaz.
6.5.5.2. Ferramentas de CI/CD: A introdução e manutenção dessas ferramentas requerem esforço e recursos.
6.5.5.3. Automação de Testes: Pode ser difícil de implementar e requer investimento em recursos
6.6. 2.1.5 Abordagem Shift-Left
6.6.1. Economia de Custos: Embora possa exigir investimento inicial em treinamento e recursos, a abordagem Shift-Left tende a economizar tempo e custos nas fases finais do projeto.
6.6.2. Aceitação dos Stakeholders: É fundamental convencer os stakeholders sobre os benefícios dessa abordagem para garantir sua implementação eficaz.
6.6.3. Boas práticas
6.6.3.1. Revisão da especificação sob a perspectiva de testes.
6.6.3.2. Escrever casos de teste antes de o código ser escrito e fazer com que o código seja executado em um conjunto de testes durante a sua implementação;
6.6.3.3. Usar a CI e, melhor ainda, a CD, pois ela vem com feedback rápido
6.6.3.4. Realizar testes não funcionais começando no nível de teste do componente, sempre que possível.
6.7. 2.2.1 Níveis (etapas) de Teste (CISA)
6.7.1. Componente/Unidade
6.7.1.1. Também conhecido como teste Componente ou de Módulo
6.7.1.2. Testa os componentes testáveis individualmente
6.7.1.3. Pode testar características funcionais e não-funcionais (comportamento, uso de memória, robustez, etc)
6.7.1.4. É normalmente realizado pelo desenvolvedor, mas pode ter um certo nível de independência
6.7.2. Integração
6.7.2.1. Realizado para encontrar defeitos nas interfaces e interações entre componentes ou sistemas
6.7.2.2. Geralmente é executado pelo desenvolvedor
6.7.2.3. Niveis
6.7.2.3.1. Teste de integração de sistemas
6.7.2.3.2. Teste de integração de componentes
6.7.2.4. Estratégias
6.7.2.4.1. Bottom-up
6.7.2.4.2. Top-down
6.7.2.4.3. Big-bang
6.7.3. Sistema
6.7.3.1. Testa o comportamento de um produto ou sistema completo
6.7.3.2. A meta é reduzir as chances de um defeito ser esquecido e acabar sendo achado pelo usuário final
6.7.3.3. Pode ser usado para investigar características:
6.7.3.3.1. Funcionais
6.7.3.3.2. Não-funcionais
6.7.3.3.3. Regras de negócio
6.7.3.4. Testadores começam usando técnicas baseadas na especificação (técnicas caixa-preta)
6.7.3.5. Depois pode usar técnicas baseadas na estrutura (caixa-branca) para checar elementos estruturais
6.7.4. Aceite
6.7.4.1. Também conhecido como Teste de Aceite do Usuário
6.7.4.2. É o último nível de teste realizado antes da liberação do produto
6.7.4.3. É comum o cliente realizar este tipo de teste ou pelo menos ser envolvido
6.7.4.4. Procura simular como produto será usado pelo cliente
6.7.4.5. Encontrar defeito não é a meta principal, a meta é garantir que o sistema está pronto para entrar em produção
6.7.4.6. Tipos
6.7.4.6.1. Alpha-teste
6.7.4.6.2. Beta-teste
6.8. 2.2.2 Tipos de testes
6.8.1. Funcional
6.8.1.1. Foca no que o sistema supostamente tem que fazer (funções dele)
6.8.1.2. Analisa as diversas formas como os usuários utilizam o sistema e cenários de negócio
6.8.1.3. É baseado no comportamento externo de um sistema e por isto emprega testes caixa-preta (ou baseados na especificação)
6.8.1.4. Muito usado no teste de sistema e de aceitação
6.8.2. Não-Funcional
6.8.2.1. Concentra-se em como o sistema trabalha
6.8.2.2. Executado para medir as características que podem ser quantificadas em uma escala variável
6.8.2.3. Tipos
6.8.2.3.1. Eficiência de Performance
6.8.2.3.2. Compatibilidade
6.8.2.3.3. Usabilidade
6.8.2.3.4. Confiabilidade
6.8.2.3.5. Segurança
6.8.2.3.6. Capacidade de Manutenção
6.8.2.3.7. Portabilidade
6.8.3. Caixa-Preta
6.8.3.1. Não olha para código fonte
6.8.3.2. Baseado em Especificações: O teste é fundamentado nas descrições de requisitos e funcionalidades do sistema, garantindo que todos os aspectos esperados sejam avaliados.
6.8.3.3. Foco no Comportamento: O principal objetivo é verificar se o sistema se comporta de acordo com suas especificações, avaliando como ele responde a diferentes entradas.
6.8.3.4. Desenvolvimento de Casos de Teste: Os testes são derivados de cenários descritos na documentação, como requisitos funcionais e não funcionais, fluxos de trabalho e casos de uso.
6.8.3.5. Não Considera Implementação: Os testadores não precisam conhecer o código-fonte ou a lógica interna do sistema
6.8.3.6. Identificação de Erros: Essa abordagem é eficaz para detectar erros em interfaces, interações e funcionalidades que podem não ser visíveis em testes de unidade ou integração.
6.8.4. Caixa-Branca / Estrutural
6.8.4.1. Analisa a estrutura interna e o comportamento do componente a ser testado
6.8.4.2. Requer algum conhecimento da estrutura interna para modelar casos de teste
6.8.4.3. Também conhecido como Teste Caixa-Branca
6.8.4.4. Cobertura de código é uma análise importante feita aqui
6.8.4.4.1. Qual é a extenção da estrutura do código que foi exercitada pela suíte de teste
6.8.4.5. Pode ser executado em todos os níveis de teste
6.9. 2.2.3 Testes de confirmação e Regressão
6.9.1. Relacionados a mudanças
6.9.1.1. Teste de confirmação / Reteste
6.9.1.1.1. Tem como objetivo verificar se um defeito identificado foi corrigido com sucesso
6.9.1.2. Teste de Regressão
6.9.1.2.1. Confirma que as alterações (incluindo correções) não causaram efeitos adversos em outros componentes do sistema ou em sistemas conectados.
6.9.1.2.2. Checa se outras funcionalidade no SW foram afetadas por uma mudança / correção
6.9.1.2.3. Aplica-se porque a correção de um defeito pode revelar ou criar outro defeito escondido no código
6.9.1.2.4. Pode ser apoiado por ferramentas de automação
6.10. 2.3 Teste de manutenção
6.10.1. Testar mudanças que podem ocorrer após o SW entrar em operação
6.10.2. Teste de Manutenção envolve a verificação de alterações em sistemas, que podem ser de diferentes categorias:
6.10.2.1. Corretivas: Para corrigir defeitos
6.10.2.2. Adaptativas: Para ajustar o sistema a mudanças no ambiente.
6.10.2.3. Melhorias: Para aumentar a performance ou capacidade de manutenção.
6.10.3. Gatilhos para executar teste de manutenção
6.10.3.1. Modificações: Aprimoramentos planejados (versões), alterações corretivas ou hot fixes
6.10.3.2. Atualizações de ambiente: Testes necessários quando o sistema migra para novas plataformas ou ao migrar dados de outros aplicativos.
6.10.3.3. Aposentadoria: Testes de arquivamento e procedimentos de recuperação podem ser necessários quando um sistema é desativado.
6.10.4. Teste de Regressão é muito utilizado aqui
6.10.4.1. Análise de impacto é usada para determinar quanto de regressão precisa ser feito