Syllabus CTFL Foundation Level

Syllabus CTFL Foundation Level

1. 1. Fundamentos do Teste

   • 1.1 Porque é necessário testar?
   • 1.2 O que é teste?
   • 1.3 Os sete princípios do teste
     • Princípio 1 – Teste demonstra a presença de defeitos
     • Princípio 2 – Teste exaustivo é impossível
     • Princípio 3 – Teste antecipado
     • Princípio 4 – Agrupamento de defeitos
     • Princípio 5 – Paradoxo do Pesticida
     • Princípio 6 – Teste depende do contexto
     • Princípio 7 – A ilusão da ausência de erros
   • 1.4 Fundamentos do processo de teste
   • 1.5 A psicologia do teste

2. 2. Teste durante o ciclo de vida do software

3. 3. Técnicas Estáticas

   • 3.1 Revisão e o Processo de Teste
     • Teste estático não necessita da execução do software. Teste dinâmico é a execução do código.
     • Revisão testa o produto do software (especificação, diagramas, código, casos de teste, etc), pode ser feito antes do teste dinâmico. Os benefícios são redução tempo do teste, menos defeitos, melhoria comunicação, etc.
     • Revisões encontram defeitos. Testes dinâmicos encontram falhas.
   • 3.2 Processo de Revisão
     • A forma como uma revisão é conduzida depende do seu objetivo, que pode ser encontrar defeitos, compreender, decidir ou tomar decisões. Podem ser formais ou informais.
     • 3.2.1 Fases de uma revisão formal
       • Planejamento
         •  Definir os critérios de revisão.  Selecionar a equipe.  Alocar as funções.  Definir os critérios de entrada e de saída para os diversos tipos de revisão formal (ex.: inspeção).  Selecionar quais as partes dos documentos será visto.  Checar os critérios de entrada (para diversos tipos de revisão formal).
       • Kick-off
         •  Distribuir os documentos.  Explicar os objetivos, processos e documentos para os participantes.
       • Preparação individual
         •  Análise da documentação para a reunião de revisão.  Anotar os defeitos em potenciais, questões e comentários.
       • Reunião de revisão
         •  Discussão ou registro, com resultados documentados ou anotações (para os tipos de revisões mais formais).  Anotar os defeitos, fazer recomendações para o tratamento de defeitos ou tomar decisões sobre os defeitos.  Examinar, avaliar e registrar questões durante as reuniões de acompanhamento.
       • Retrabalho
         •  Resolver defeitos encontrados, tipicamente feitos pelo autor.  Registrar os status atuais dos defeitos (para revisões formais).
       • Acompanhamento
         •  Checar se os defeitos foram encaminhados.  Obter métricas.  Checar os critérios de saída (para tipos de revisões formais).
     • 3.2.2 Papéis e responsabilidades
       • Gerente
         • toma decisão durante a realização da revisão, aloca tempo nos cronogramas de projeto e determina se o objetivo da revisão foi atingido
       • Moderador
         • a pessoa que lidera a revisão dos documentos, incluindo o planejamento da revisão, e o acompanhamento após a reunião. Se necessário, mediará entre os vários pontos de vista e é muitas vezes quem responderá pelo sucesso da revisão.
       • Autor
         • é a pessoa que escreveu ou que possui a responsabilidade pelos documentos que serão revisados.
       • Revisores ou Inspetores
         • indivíduos com conhecimento técnico ou de negócio, que identificam e descrevem os defeitos encontrados no produto em revisão. Podem ser escolhidos para representar diferentes funções e perspectivas no processo de revisão, e é parte integrante de qualquer reunião de revisão.
       • Redator
         • documenta todo o conteúdo da reunião, problemas e itens em aberto que foram identificados durante a reunião.
     • 3.2.3 Tipos de revisão
       • Revisão informal
         •  A documentação é opcional.  Principal propósito: uma forma de obter algum benefício a um baixo custo.
       • Acompanhamento
         •  Reunião conduzida pelo autor.  Na prática pode variar de informal para muito formal.  Principal propósito: aprendizagem, obtenção de entendimento e encontrar defeitos.
       • Revisões técnicas
         •  Documentado, processo de detecção de defeito, inclui colegas especialistas ou técnicos.  Idealmente são conduzidas por um moderador treinado (que não seja o autor).  Elaboração de um relatório de revisão.  Principais propósitos: discussão, tomada de decisões, avaliar alternativas, encontrar defeitos, resolver problemas técnicos e checar a conformidade da padronização das especificações.
       • Inspeção
         •  Conduzida pelo moderador (que não seja o autor).  Papéis definidos.  Utilização de métricas.  Processo formal baseado em regras e utilização de check-list.  Relatório de inspeção, lista de defeitos encontrados.  Principal propósito: encontrar defeitos.
       • Um único documento pode ser objeto para mais de uma revisão.
     • 3.2.4 Fatores de sucesso para as revisões
       •  Cada revisão tem um objetivo claramente definido.
       •  A pessoa adequada para os objetivos da revisão deve ser envolvida.
       •  Testadores são valorizados como revisores que contribuem para a revisão e aprendizado sobre o produto o que lhes permite preparar os testes facilmente.
       •  Defeitos encontrados são encorajados e expressados objetivamente.
       •  Técnicas de revisão são aplicadas de forma a combinar com o tipo e nível do software e revisores.
       •  Caso necessário, check-lists ou papéis são utilizados para aumentar a eficiência na identificação de defeitos.
   • 3.3 Análise Estática por Ferramentas
     • Análise estática pode localizar defeitos que são dificilmente encontrados em testes. Como as revisões, a análise estática encontra defeitos ao invés de falhas.
     • Benefícios
       •  Detecção de defeitos antes da execução do teste.  Conhecimento antecipado sobre aspectos suspeitos no código ou programa através de métricas, por exemplo, na obtenção de uma medida da alta complexidade.
       •  Identificação de defeitos dificilmente encontrados por testes dinâmicos.  Detecção de dependências e inconsistências em modelos de software, como links perdidos.
       •  Aprimoramento da manutenibilidade do código e construção.  Prevenção de defeitos, se as lições forem aprendidas pelo desenvolvimento.
     • Defeitos mais comuns descobertos
       •  Referência a uma variável com valor indefinido.  Inconsistências entre as interfaces dos módulos e componentes.
       •  Variáveis que nunca são usadas ou impropriamente declaradas.  Código morto.
       •  Falta de lógica ou lógica errada (loops infinitos).  Construções excessivamente complicadas.
       •  Violação de padrões de programação.  Vulnerabilidade na segurança.  Violação de sintaxe e de modelos.
     • Ferramentas de análise estática analisam o código do programa, gerando arquivos do tipo HTML e XML, por exemplo.
     • Ferramentas de análises estáticas são tipicamente usadas por desenvolvedores antes e durante o teste de componente e de integração e por projetistas durante a modelagem do software.

4. 4. Técnica de Modelagem de Teste

   • 4.1 Identificando as condições de testes e projetando os casos de testes
     • Durante a análise de teste
       • a documentação é analisada para determinar o que testar, essas condições de teste são definidas como um item ou evento que pode ser verificado por um ou mai casos de teste
       • estabelecer a rastreabilidade das condições de testes na volta até as especificações e requisitos permitem analisar o impacto quando os requisitos mudam
     • Durante a modelagem de teste
       • os casos de teste e os dados de teste são especificados e criados
       • um caso de teste consiste de um 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
     • Durante a implementação do teste
       • os casos de teste são desenvolvidos, implementados, priorizadas e organizadas na especificação de procedimento de teste
       • O procedimento de teste especifica a sequência de ações para a uma execução de teste
   • 4.2 Categorias das técnicas de modelagem de teste
     • O propósito da técnica de modelagem de teste é identificar as condições e os casos de testes
     • Classificar testes como caixa-preta ou caixa-branca é uma diferenciação clássica
     • Técnicas Caixa-Preta
       • técnicas baseadas em especificação
       • são uma forma de derivar e selecionar as condições e casos de testes baseados na análise da documentação
         • isto inclui testes funcionais e não funcionais, para um componente ou sistema sem levar em consideração a sua estrutura interna
     • Técnicas Caixa-Branca
       • técnicas estruturais ou baseadas em estrutura
       • são baseadas na estrutura interna de um componente ou sistema.
   • 4.3 Técnicas baseadas em especificação ou Caixa-Preta
     • 4.3.1 Partição de Equivalência
       • as entradas do software ou sistema são divididas em grupos que tenham um comportamento similar, podendo ser tratados da mesma forma
     • 4.3.2 Análise do Valor Limite
     • 4.3.3 Tabela de Decisão
     • 4.3.4 Teste de transição de estados
     • 4.3.5 Teste de Caso de Uso
   • 4.4 Técnicas baseadas em estrutura ou Caixa-Branca
     • 4.4.1 Teste e Cobertura de Sentença
     • 4.4.2 Teste e Cobertura de Decisão
     • 4.4.3 Outras técnicas baseadas na estrutura
   • 4.5 Técnicas baseadas na experiência
   • 4.6 Escolhendo as técnicas de teste

5. 5. Gerenciamento de Teste