Principais tópicos do exame CTFL

1. Técnicas de Modelagem de Teste

1.1. Identificando as condições de teste e projetando os casos de teste

1.1.1. Durante a Análise de teste

1.1.1.1. Analisa a documentação de base de teste para determinar o que testar

1.1.1.2. Identifica cada Condição de Teste

1.1.1.2.1. É algum item ou evento que precisa ser verificado por um Caso de Teste

1.1.1.2.2. Exemplo de item: função ou elemento do sistema

1.1.2. Durante a Modelagem

1.1.2.1. Detalha a estratégia de teste considerando os riscos

1.1.2.2. Dados de teste e Casos de Teste são especificados e criados

1.1.2.3. Caso de Teste

1.1.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

1.1.2.4. Resultados esperados devem ser produzidos como parte da especificação de um caso de teste

1.1.3. Durante a Implementação

1.1.3.1. Casos de teste são desenvolvidos, implementados, priorizados e organizadas na especificação de procedimento de teste

1.1.3.2. Procedimento de Teste

1.1.3.2.1. Especifica a sequência de ações para a uma execução de teste. Se os testes são executados por uma ferramenta, a sequência de ações é especificada por um script automatizado

1.1.4. Durante a Execução

1.1.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á

1.2. Categorias de Técnicas

1.2.1. Caixa-Preta

1.2.1.1. Características

1.2.1.1.1. Pode ser funcional ou não-funcional

1.2.1.1.2. Baseia-se muito na documentação

1.2.1.1.3. Também referenciada como Baseada na especificação

1.2.1.2. Técnicas

1.2.1.2.1. Partição de Equivalência

1.2.1.2.2. Análise do Valor Limite

1.2.1.2.3. Tabela de Decisão

1.2.1.2.4. Transição de Estados

1.2.1.2.5. Teste por Caso de Uso

1.2.2. Caixa-Branca

1.2.2.1. Características

1.2.2.1.1. Baseada na análise da estrutura do componente ou sistema

1.2.2.1.2. Também referenciada como teste de estrutura ou baseada na estrutura

1.2.2.2. Teste de Sentença/Comando

1.2.2.2.1. Usa um modelo do código fonte que identifica as linhas de sentença

1.2.2.2.2. Exemplo: IF x > 0 THEN y END IF - neste caso, y é uma sentença que pode ser executada dependendo da condição x

1.2.2.2.3. Os casos de teste devem exercitar as sentenças

1.2.2.3. Teste de Decisão

1.2.2.3.1. Usa um modelo do código fonte para identificar decisões individuais e seus resultados

1.2.2.3.2. Também chamado Teste de Ramificação

1.2.2.3.3. Exemplo: IF x > 0 THEN y END IF - neste caso, o caso de teste deve testar condição x > 0

1.2.2.3.4. A cobertura de decisão é mais eficiente que a cobertura de sentenças: 100% da cobertura de decisão garante 100% da cobertura de sentença, mas não vice-versa.

1.2.3. Baseadas na experiência

1.2.3.1. Características

1.2.3.1.1. Conhecimento e intuição das pessoas são usados para derivar os casos de teste

1.2.3.2. Técnicas

1.2.3.2.1. Suposição de Erros

1.2.3.2.2. Teste Exploratório

2. Gerenciamento de Teste

2.1. Independência do teste

2.1.1. Não é indicado que apenas o Desenvolvedor teste o seu trabalho

2.1.2. Testadores independentes têm mais vantagens

2.1.2.1. Enxergam mais defeitos

2.1.2.2. São Imparciais

2.1.3. Níveis de independência

2.1.3.1. 1 Nenhum testador independente, os desenvolvedores testam seu próprio código

2.1.3.2. 2 Testadores independentes dentro de uma equipe de desenvolvimento

2.1.3.3. 3 Uma equipe de testes independente dentro da organização, que se reporta ao gerente do projeto

2.1.3.4. 4 Especialistas em testes para um objetivo específico de teste

2.1.3.5. 5 Equipe de testes terceirizada ou independente da organização

2.2. Tarefas do Líder de Teste

2.2.1. Também chamado de gerente ou coordenador de teste

2.2.2. Coordena a estratégia de teste

2.2.3. Escreve/revisa a estratégia de teste

2.2.4. Planeja os testes

2.2.5. Prepara um gerenciamento de configuração do testware

2.2.6. Introduz métricas

2.2.7. Decide o que será automatizado

2.2.8. Seleciona ferramentas de apoio

2.2.9. Escreve relatório de resumo

2.3. Tarefas do Testador

2.3.1. Revisa e contribui nos planos de teste

2.3.2. Cria especificações de teste

2.3.3. Configura o ambiente de teste

2.3.4. Prepara e adquire dados de teste

2.3.5. Executa os testes

2.3.6. Automatiza os testes

2.3.7. Mede desempenho dos componentes e sistemas

2.3.8. Reve os testes desenvolvidos por outras pessoas

2.4. Organização do Teste

2.4.1. Planejamento de Teste

2.4.1.1. Determina o escopo e risco, identificando os objetivos do teste

2.4.1.2. Define a abordagem do teste

2.4.1.3. Decide o que testar

2.4.1.4. Agenda as atividades

2.4.1.5. Aloca recursos

2.4.1.6. Define métricas

2.4.2. Critério de Entrada

2.4.2.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.4.3. Critérios de Saída

2.4.3.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.4.4. Estimativa do teste

2.4.4.1. Estima esforço do teste

2.4.5. Estratégia do Teste

2.4.5.1. Analítica

2.4.5.2. Baseada em modelos

2.4.5.3. Abordagem metódica

2.4.5.4. Compatível com processos ou padrões

2.4.5.5. Dinâmica e heurística

2.4.5.6. Baseada em conselhos

2.4.5.7. Regressão

2.4.6. Monitoração do Progresso do Teste

2.4.6.1. Permite uma visibilidade sobre as atividades do teste

2.4.6.2. Usa métricas para isto

2.4.7. Relatório do teste

2.4.7.1. Constituído de informações resumidas sobre o esforço do teste

2.4.8. Controle do Teste

2.4.8.1. Descreve qualquer orientação ou ação corretiva tomada

2.5. Estrutura Plano de Teste segundo IEEE

2.5.1. Identificador

2.5.2. Introdução

2.5.3. Itens de teste

2.5.4. Funcionalidades a serem testadas

2.5.5. Funcionalidades a não serem testadas

2.5.6. Abordagem

2.5.7. Critérios Pass/Fail

2.5.8. Critério para Suspensão e Requisitos pp/ Retomada

2.5.9. Entregas do Teste

2.5.10. Atividades de Teste

2.5.11. Necessidades do ambiente

2.5.12. Necessidades de Treinamento e Pessoal

2.5.13. Cronograma

2.5.14. Riscos e Contingências

2.5.15. Aprovações

2.6. Gerenciamento de configuração

2.6.1. Usado para gerenciar componentes individuais que fazem parte de um sistema

2.6.2. Inclui o controle de versões do código fonte

2.6.3. Desenvolvedores devem fazer correções a partir versão correta do código

2.6.4. E testadores devem testar a versão correta do código

2.6.5. Todos os itens do testware precisam ser identificados, controlados, rastreados para mudanças e possuir relacionamentos entre si

2.6.6. Este processo ajuda a manter o rastreamento dos itens que sofreram alteração

2.6.7. Partes principais deste processo

2.6.7.1. Identificação da Configuração

2.6.7.1.1. Identifica todos os itens individiuas que se referem ao controle de versão dentro do projeto

2.6.7.2. Controle da Configuração

2.6.7.2.1. Avaliação, coordenação, aprovação e implementação de mudanças nos itens de configuração

2.6.7.2.2. Garante que qualquer mudança seja controla e monitorada

2.6.7.3. Controle do Status

2.6.7.3.1. Registra e reporta o status atual de item

2.6.7.4. Auditoria de Configuração

2.6.7.4.1. Assegura que o processo de controle é usado

2.7. Riscos e testes

2.7.1. Riscos do Projeto

2.7.1.1. Associados ao gerenciamento e controle do projeto

2.7.1.2. Riscos Potenciais

2.7.1.2.1. Fatores organizacionais

2.7.1.2.2. Questões técnicas

2.7.1.2.3. Questões relacionadas a fornecedores

2.7.2. Riscos do Produto

2.7.2.1. Relacionados diretamente ao objeto sob teste

2.7.2.2. Esxemplo: riscos às pessoas se o produto falhar (controle de trafego aéreo, por exemplo)

2.8. Gerenciamento de incidente

2.8.1. Incidente

2.8.1.1. qualquer evento significante, não planejado que ocorre durante os testes e que requer investigação e/ou correção

2.8.1.2. Possível defeito no SW, mas requer investigação para determinar se é um defeito

2.8.2. Detalhes do incidente que podem ser registrados

2.8.2.1. Data

2.8.2.2. Resultados esperados e atuais

2.8.2.3. Identificação do item de teste

2.8.2.4. Descrição

2.8.2.5. Escopo e grau de impacto

2.8.2.6. Severidade do impacto no sistema

2.8.2.7. Prioridade

2.8.2.8. Status

2.8.2.9. Recomendações

2.8.2.10. Histórico de alterações

3. Ferramentas de Suporte a Teste

3.1. Ferramentas p/ o gerenciamento do teste

3.1.1. p/ Gerenciamento de Teste

3.1.2. p/ Gerenciamento de Requisitos

3.1.3. p/ Gerenciamento de Incidentes

3.1.4. p/ Gerenciamento de Configuração

3.2. Ferramentas p/ Teste Estático

3.2.1. p/ Processo de Revisão

3.2.2. p/ Análise Estática

3.2.3. p/ Modelagem

3.3. Ferramentas para Especificação do Teste

3.3.1. p/ Modelagem do teste

3.3.2. p/ Preparação de Dados de teste

3.4. Ferramentas para Execução do Teste

3.4.1. p/ Execução

3.4.2. p/ testes unitários especificos

3.4.3. Comparadores

3.4.4. Medidores de cobertura

3.4.5. p/ Segurança

3.5. Ferramentas de Performance e Monitoração

3.5.1. p/ Análise Dinâmica

3.5.2. p/ Teste de Performance/ Carga /Estresse

3.5.3. p/ Monitoração

4. Mapa desenvolvido pela TIEXAMES

4.1. www.tiexames.com.br

4.2. Exclusivo para assinantes do curso CTFL da TIEXAMES

4.3. Não redistribua este mapa

4.4. Excelente ferramenta para revisão do conteúdo para o exame CTFL

4.5. Faça melhorias se achar necessário para seus estudos

4.6. Decorar este mapa por não ser suficiente para passar no exame

4.7. Não contempla todo o conteúdo do curso, apenas o essencial

5. Fundamentos do Teste

5.1. Principais termos

5.1.1. Erro

5.1.1.1. Ação humana que produz um resultado incorreto

5.1.1.2. Também conhecido como engano

5.1.1.3. Exemplo: váriavel digitada com erro (em vez do programador  digitar $cliente digitou $cliete)

5.1.2. Defeito

5.1.2.1. Defeito em um componente ou sistema que leva o componente ou sistema falhar quando é executado

5.1.2.2. Manifestação de um erro no software

5.1.2.3. Também conhecido como bug

5.1.2.4. Exemplo: a variável $desconto  foi declarada, mas não foi usada na rotina de cálculo do preço

5.1.3. Falha

5.1.3.1. Diferença indesejável entre o observado e o esperado (defeito encontrado)

5.1.3.2. Exemplo: uma ação que era para ocorrer não ocorreu devido a variável $cliente ter sido digitada incorretamente no código

5.2. Papel do Teste

5.2.1. Reduzir o risco de um problema ocorrer durante o uso operacional do SW

5.2.1.1. Quando falhas ocorrem geram perdas para os clientes / usuários

5.3. Necessidade dos testes

5.3.1. Testamos para construir confiabilidade

5.3.2. Menos defeitos = menor chance do SW falhar

5.3.3. Ajudam a aumentar a qualidade do SW qdo defeitos são encontrados e removidos

5.4. Quanto teste é suficiente?

5.4.1. Não testamos tudo porque não temos tempo

5.4.2. Testes exaustivos são impraticáveis

5.4.2.1. Não temos tempo

5.4.2.2. Usa muito Recursos

5.4.2.3. Custa caro

5.4.3. Os riscos vão dizer quanto tempo precisa ser alocado para os testes

5.4.4. Restrições de tempo e orçamento são consideradas

5.4.5. Testes devem ser focados em áreas específicas do SW onde existe um potencial maior de risco de falha

5.4.6. Executar primeiro os casos de teste mais importantes

5.4.6.1. Significa priorizar os testes

5.5. O que é teste?

5.5.1. É um processo composto de várias atividades

5.5.1.1. Planejamento e controle

5.5.1.2. Seleção das condições de teste (itens de teste)

5.5.1.3. Modelagem dos casos de teste

5.5.1.4. Execução do teste

5.5.1.5. Verificação dos resultados

5.5.1.6. Avaliação dos critérios de conclusão

5.5.1.7. Relatar sobre o processo de teste e o sistema sob teste

5.5.1.8. Atividades de encerramento

5.5.2. Pode ter objetivos diferentes (encontrar defeitos, ganhar confiança, prevenir defeitos)

5.5.3. Deve acontecer o mais cedo possível no ciclo de vida do projeto

5.5.4. Inclui a revisão de documentos e códigos fonte

5.5.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.6. 7 príncipios

5.6.1. 1 Teste demonstra a presença de defeitos

5.6.2. 2 Teste exaustivo é impossível

5.6.3. 3 Teste antecipado

5.6.3.1. Iniciar o testes o mais cedo possível

5.6.4. 4 Agrupamento de defeitos

5.6.4.1. Algumas áreas do SW contêm mais defeitos que outras

5.6.5. 5 Paradoxo do Pesticida

5.6.5.1. Testes quando repetidos podem encontrar novos defeitos

5.6.6. 6 Teste depende do contexto

5.6.6.1. Cada tipo de SW pode ser testado de forma diferente

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.7. Processo de Teste

5.7.1. Planejamento & Controle

5.7.1.1. Planejamento

5.7.1.1.1. Determina os objetivos de teste

5.7.1.1.2. Determina O QUE, PORQUE e COMO algo será testado

5.7.1.1.3. Determina abordagem/estratégia

5.7.1.1.4. Determina riscos

5.7.1.1.5. Determinar os recursos requeridos

5.7.1.1.6. Agenda as atividades

5.7.1.1.7. Especifica critérios de saída

5.7.1.2. Controle

5.7.1.2.1. Ajuda a alcançar o que foi planejado

5.7.1.2.2. Compara o progresso do Teste contra o Plano de Teste

5.7.1.2.3. Ocorre durante todo o Teste

5.7.1.2.4. Pode tomar ações corretivas

5.7.2. Análise & Modelagem

5.7.2.1. Transforma os objetivos de teste em Condições de Teste

5.7.2.1.1. Indicam “o quê” será testado

5.7.2.2. Revisa a base de teste (documentação sobre a qual os casos de teste são construídos)

5.7.2.3. Avalia a testabilidade

5.7.2.4. Modela e prioriza condições de teste

5.7.2.5. Modela o ambiente de teste

5.7.2.6. Considera a cobertura de testes

5.7.3. Implementação & Execução

5.7.3.1. Implementação

5.7.3.1.1. Transforma as Condições de teste em Casos de teste

5.7.3.1.2. Desenvolve, implementa e prioriza casos de teste

5.7.3.1.3. Desenvole e prioriza procedimentos de teste

5.7.3.1.4. Cria dados para teste

5.7.3.1.5. Escreve os scripts de teste

5.7.3.1.6. Verifica se o ambiente de teste está configurado

5.7.3.2. Execução

5.7.3.2.1. É onde o teste de fato é realizado

5.7.3.2.2. Executa casos de teste manualmente ou usando ferramenta de automação

5.7.3.2.3. Registra as saídas da execução do teste

5.7.3.2.4. Checa os resultados

5.7.4. Avaliação de critérios de saída & Relatórios

5.7.4.1. Assegura que qualquer critério de saída tem sido alcançado pelas atividades de teste executadas

5.7.4.2. Se critérios de saída não foram alcançados, mais testes podem ser necessários

5.7.5. Encerramento de teste

5.7.5.1. Coleta os resultados do teste e documentação relacionada para arquivamento

5.7.5.2. Checa que as entregas planejadas de fato foram entregues

5.7.5.3. Checa se defeitos encontrados durante o teste foram corrigidos

5.8. Psicologia do Teste

5.8.1. O testador tem propósito primário de achar defeitos e falhas no SW

5.8.2. A atividade de teste pode ser vista como destrutiva no desenvolvimento de SW

5.8.3. Uma boa comunicação é essencial entre Testador e Desenvolvedor

5.8.4. O Testador precisa reportar defeitos sem agredir o Desenvolvedor

5.8.5. Testador precisar ter habilidades

5.8.5.1. Bom comunicador

5.8.5.2. Curioso

5.8.5.3. Paciente

5.8.5.4. Meticuloso

5.8.5.5. Etc.

6. Teste durante o ciclo de vida do SW

6.1. Modelo V

6.1.1. Modelo de ciclo de vida de desenvolvimento e Teste de SW

6.1.2. Mostra a relação do nível de teste com o nível de desenvolvimento

6.1.3. Cada atividade de desenvolvimento tem uma atividade de teste correspondente

6.1.4. Testadores devem ser envolvidos na revisão de documentos o mais cedo possível

6.1.5. É dividido normalmente em 4 níveis, mas pode ter mais dependendo da metodologia da organização

6.2. Níveis de Teste

6.2.1. Unitário

6.2.1.1. Também conhecido como teste Componente ou de Módulo

6.2.1.2. Testa os componentes testáveis individualmente

6.2.1.3. Pode testar características funcionais e não-funcionais (comportamento, uso de memória, robustez, etc)

6.2.1.4. É normalmente realizado pelo desenvolvedor, mas pode ter um certo nível de independência

6.2.2. Integração

6.2.2.1. Realizado para encontrar defeitos nas interfaces e interações entre componentes ou sistemas

6.2.2.2. Geralmente é executado pelo desenvolvedor

6.2.2.3. Niveis

6.2.2.3.1. Teste de integração de sistemas

6.2.2.3.2. Teste de integração de componentes

6.2.2.4. Estratégias

6.2.2.4.1. Bottom-up

6.2.2.4.2. Top Down

6.2.2.4.3. Big-Bang

6.2.3. Sistema

6.2.3.1. Testa o comportamento de um produto ou sistema completo

6.2.3.2. A meta é reduzir as chances de um defeito ser esquecido e acabar sendo achado pelo usuário final

6.2.3.3. Pode ser usado para investigar características:

6.2.3.3.1. Funcionais

6.2.3.3.2. Não-funcionais

6.2.3.3.3. Regras de negócio

6.2.3.4. Testadores começam usando técnicas baseadas na especificação (técnicas caixa-preta)

6.2.3.5. Depois pode usar técnicas baseadas na estrutura (caixa-branca) para checar elementos estruturais

6.2.4. Aceitação

6.2.4.1. Também conhecido como Teste de Aceite do Usuário

6.2.4.2. É o último nível de teste realizado antes da liberação do produto

6.2.4.3. É comum o cliente realizar este tipo de teste ou pelo menos ser envolvido

6.2.4.4. Procura simular como produto será usado pelo cliente

6.2.4.5. Encontrar defeito não é a meta principal, a meta é garantir que o sistema está pronto para entrar em produção

6.2.4.6. Tipos

6.2.4.6.1. Alpha-teste

6.2.4.6.2. Beta-teste

6.3. Tipos de testes

6.3.1. Funcional

6.3.1.1. Foca no que o sistema supostamente tem que fazer (funções dele)

6.3.1.2. Analisa as diversas formas como os usuários utilizam o sistema e cenários de negócio

6.3.1.3. É baseado no comportamento externo de um sistema e por isto emprega testes caixa-preta (ou baseados na especificação)

6.3.1.4. Muito usado no teste de sistema e de aceitação

6.3.2. Não-Funcional

6.3.2.1. Concentra-se em como o sistema trabalha

6.3.2.2. Executado para medir as características que podem ser quantificadas em uma escala variável 

6.3.2.3. Tipos

6.3.2.3.1. Teste Performance

6.3.2.3.2. Teste de carga

6.3.2.3.3. Teste de Estresse

6.3.2.3.4. Teste de recuperação de falhas

6.3.2.3.5. Teste de Segurança

6.3.2.3.6. Teste de Usabilidade

6.3.2.3.7. Teste de Instalação

6.3.3. Estrutural

6.3.3.1. Analisa a estrutura interna e o comportamento do componente a ser testado

6.3.3.2. Requer algum conhecimento da estrutura interna para modelar casos de teste

6.3.3.3. Também conhecido como Teste Caixa-Branca

6.3.3.4. Cobertura de código é uma análise importante feita aqui

6.3.3.4.1. Qual é a extenção da estrutura do código que foi exercitada pela suíte de teste

6.3.3.5. Pode ser executado em todos os níveis de teste

6.3.4. Relacionados a mudanças

6.3.4.1. Reteste

6.3.4.1.1. Quando um defeito é corrigido o reteste assegura que este de fato foi corrigido

6.3.4.1.2. Também conhecido como teste de confirmação

6.3.4.2. Teste de Regressão

6.3.4.2.1. Checa se outras funcionalidade no SW foram afetadas por uma mudança / correção

6.3.4.2.2. Aplica-se porque a correção de um defeito pode revelar ou criar outro defeito escondido no código

6.3.4.2.3. Pode ser apoiado por ferramentas de automação

6.4. Teste de manutenção

6.4.1. Para testar mudanças que podem ocorrer após o SW entrar em operação

6.4.2. Teste de Regressão é muito utilizado aqui

6.4.2.1. Análise de impacto é usada para determinar quanto de regressão precisa ser feito

7. Técnicas Estáticas

7.1. Técnicas estáticas

7.1.1. Examinam a documentação do projeto e código-fonte sem executá-los

7.1.2. Compreende as atividades de revisão, inspeção e análise estática do código

7.1.3. Podem ser empregadas bem antes da execução do teste dinâmico

7.2. Revisões e o processo de teste

7.2.1. Através de revisões os defeitos podem ser identificados mais cedo

7.2.2. Tradicionalmente revisões são manuais, mas podem ser usadas ferramentas de apoio

7.2.3. Qualquer coisa pode ser revisada

7.2.3.1. Especificação de requisitos

7.2.3.2. Documentos do projeto

7.2.3.3. Especificações de teste

7.2.3.4. Código-fonte

7.2.3.5. Plano de teste, casos de teste e scripts de teste

7.2.3.6. Etc

7.2.4. Fases de uma revisão formal

7.2.4.1. Planejamento

7.2.4.2. Kick-off

7.2.4.3. Preparação individual

7.2.4.4. Reunião de revisão

7.2.4.5. Retrabalho

7.2.4.6. Acompanhamento

7.2.5. Papéis envolvidos em revisão formal

7.2.5.1. Gerente

7.2.5.1.1. Quem toma decisão de iniciar a revisão

7.2.5.1.2. Determina os objetivos da revisão

7.2.5.1.3. Aloca o tempo das pessoas para revisão

7.2.5.2. Moderador

7.2.5.2.1. Ldera, planeja e executa a revisão

7.2.5.2.2. Modera a reunião permitindo que os vários pontos de vista sejam apresentados

7.2.5.3. Autor

7.2.5.3.1. Quem criou o item a ser inspecionado/revisado

7.2.5.4. Revisores

7.2.5.4.1. Conhecidos como checadores ou inspetores

7.2.5.4.2. Procuram por defeitos no item sob revisão

7.2.5.5. Escrivão / Secretário

7.2.5.5.1. Registra os defeitos mencionados e qualquer sugestão

7.3. Tipos de revisão

7.3.1. Revisão Informal

7.3.1.1. Não existe processo formal

7.3.1.2. Muito empregada no início do ciclo de vida do SW e da documentação

7.3.1.3. Exemplo: o autor do documento faz a análise do seu próprio trabalho

7.3.2. Acompanhamento (Walkthrough)

7.3.2.1. É o autor que conduz a reunião

7.3.2.2. O autor apresenta o material em ordem lógica a um grupo

7.3.2.3. A reunião não tem restrição de tempo de duração

7.3.2.4. Principal propósito é a aprendizagem, treinar os envolvidos no projeto e obter o entendimento.

7.3.3. Revisões Técnicas

7.3.3.1. Inclui a Revisão por Pares (Peer review)

7.3.3.2. Inclui avaliações técnicas de artefatos específicos

7.3.3.3. É considerada formal porque é caracterizada por procedimentos documentados

7.3.3.4. Envolve encontros estruturados onde um par (ou pares) analisa o trabalho de outra pessoa

7.3.3.4.1. Devem ser lideradas por um moderador treinado, não sendo o autor do documento

7.3.3.5. Pode ser guiada por checklists

7.3.3.6. Podem ser conduzidas por um moderador treinado (que não seja o autor)

7.3.4. Inspeção

7.3.4.1. É um tipo mais formal de revisão

7.3.4.2. Ocorre por meio de uma reunião com pessoas envolvidas no projeto onde se analisa, verifica e testa artefatos do SW

7.3.4.3. Deve ser liderada por um moderador treinado, que não pode ser o autor

7.3.4.4. A preparação antecipada para a reunião é essencial

7.3.4.5. Tem papéis bem definidos nesta revisão

7.4. Análise estática por Ferramentas

7.4.1. Análise Estática

7.4.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

7.4.1.2. Permite detectar defeitos antes da execução do teste

7.4.2. Pode ser usado compilador para analisar estaticamente o código

7.4.3. Exemplos de defeitos encontrados

7.4.3.1. Código inacessível

7.4.3.2. Variáveis não declaradas

7.4.3.3. Parâmetros incorretos

7.4.3.4. Procedimentos e funções não usadas

7.4.3.5. Violação de segurança

7.4.3.6. Erro de sintaxe

7.4.3.7. Etc

7.4.4. Fluxo de controle

7.4.4.1. Técnica básica para a realização da análise estática de código

7.4.4.2. É a representação gráfica de como o código escrito é executado

7.4.5. Complexidade ciclomática

7.4.5.1. É uma medida da complexidade de um fluxo de controle.

7.4.5.2. Identifica como o código é difícil de entender, testar e manter

7.4.5.3. Identifica o risco associado ao teste de um programa.