Estudo CTFL

Anmerkungen:

• Empresas utilizam software para gerenciar e controlar suas atividades dia a dia. precisar garantir qualidade. Evitar Prejuizos finanaceiros para as empresas e qualidade de atendimento que pode ser impactado por erros em software. Ex.: Emissão de Nota Fiscal, Emissão de Pedidos.  Softwres de operação critica: Bancos, Aeroportos..

1. Falhas ocorrem

   Anmerkungen:

   • - Nao Emitir pedidos - Vendas Impactadas - Perda de Produtividades dos usuários. - softwre queijo suiço - Perda de Qualidade do Software
   1. Causas

      Anmerkungen:

      • - Pressão de Entrega - Conhecimento dos envolvidos - Sistemas mais complexos - Pessoas sem treinamento em suas funções - Falta de difinição de requisitos - Se voce esta com pressa apresse a construção dos requisitos não o planejamento. - Pobre comunicação
2. Erro, Defeito ou Falha

   Anmerkungen:

   • - Erro Ação Humana cometida pelos envolvidos no ciclo de produção do software.] - Defeito, manifestção de um erro no software, conhecido como um bug. Se executado pode acontecer uma falha no sistema. - Falha, é a diferença indesejável entre o observado e o esperado. produz um resultado incorreto nao esperado ou então nao realiza o que se esperava. São causadas por defeitos no software. Podemos dizer: Falha é um evento, defeito é um estado do software causado por um erro, Lembrar que falhas tambem podem ser causadas por condições do ambiente ex.: radiotividade, magnetismo e poluição, etc...
   1. Espaço Nave mercury
   2. Terminologia de Teste Diferentes

      Anmerkungen:

      • Para este treinamento foi utilizado ISEB ISTQB - Melhorar comunicação entre a equipe padronizando os termos.
   3. Custo dos Defeitos

      Anmerkungen:

      • Regra 10 de Myers, Custo da correção dos defeitos. Quanto mais cedo descobrirmos e corrigirmos um defeito menor é o custo para o projeto.
      1. Propagação dos Erros

         Anmerkungen:

         • Aumento Exponencial  do retrabalho

Anmerkungen:

• Exemplo do limite de prova de agua, voce precisa ver ao quanto ele suporta em sua especificação - A confiabilidade do software é o tempo medio entre falhas, quanto maior o tempo entre falhas maior e a confiabilidade do software.

1. Papeis Importante do teste de software

   Anmerkungen:

   • Teste propiciam no aumento da qualidade do software diminuindo a chance de falhas ocorrerem. - Os teste podem acontecer em Documentos antes de serem desenvolvidos. - Identificar falhas antes que o software chege a produção. Quan - O setor de testes não deve ser encarado como Custo mas como Prevenção e investimento
2. Teste & Qualidade

   Anmerkungen:

   • teste nao constroi por sis so a qualidade do sistema, mas tem a função de ajudar a aumentar a qualidade do software atraves de detectar os defeitos e este defeitos serem corrigidos. Medir Qualidade pode ser dos defietos encontraados e avaliar se os requisitos atendem a necessidade do usuario. E da avalização dos requisitos não funcionais, usuabilidade, portabilidade... Seguintes Atividades devem ser realizadas para testes bem desenhados e executados reduzem os riscos dos softwares falharem. - liçoes aprendidads - Plano de ação - identifacar raizes dos problemas - processos aprimorados - realziar atividades de garantia de qualidade para verificar se estao seguindo os processos.
   1. Avaliar a Qualidade

      Anmerkungen:

      • Muitos defeitos VS Poucos defeitos Não podemos afirmar que quantos menos defeitos encontrados melhor sera a qualidade do software. - Qualidade custa menos  Mais qualidade  = produção mais rapida = Mais produtividades Leitura Slides 33 Teste Exaustivo é impraticavel - requer muitos recursos, custo, toma muito tempo. Ex.: Exemplo dos 480 mil testes necessitamos de uma alternativa acessivel rapida...
   2. O que Testar?

      Anmerkungen:

      • Avaliar a consequencia da falha gerada - risco potencial em implicações financeiras (Custo de suporte, possiblidade de ação legal) - Perda de vida se falhar - Perda de Imagem e confiabilidade - Software sendo liberado tarde para o mercado - Levar em consideralçao as restrições do projeto como tempo e orcamento.
      1. Compartilhar os riscos com stakeholders
      2. Priorização dos Testes

         Anmerkungen:

         • Priorizar os testes sempre pelos mais importantes para que cxaso voce precise para os testes, pelo menos os testes mais importantes teham sidos cobertos.

Anmerkungen:

• Testar e analisar um programa com a intenção de descobrir erros e defeitos (Glendolf Myers) Programador Constroi e Testador destroi. - Ver Teste dinamicos e estáticos

1. Melhor Abordagem

   Anmerkungen:

   • Meta = Encontrar defeitos Criterio de sucesso = Sistemas com falhas Resultado = Sistema com menos defeito
2. Abordagem tradicional

   Anmerkungen:

   • Meta = Mostrar que o sistema funciona Critério de Sucesso = Sistema em funcionamento correto Resultado = Sistema com Defeitos
3. Paradoxo do Teste

   Anmerkungen:

   • Melhor maneira de construir a confianca e tentar destrui-la
4. Atividades do Teste
   1. Teste Dinamico

      Anmerkungen:

      • teste deve estar construido teste mais utilizado peloas empresas de desenvovimento de teste - Planejamento e controle - Seleção das condições do teste (o que testar, cenarios) - modelagem dos CTs - Execução dos testes - Verificação dos resultados - avaliação do s criterios de conclusão - Relatar sobre o prcesso e o sistema sobre o teste, o que funcionou - Atividades de fechamento e relatorios de gerenciais.
   2. Teste Estático

      Anmerkungen:

      • teste antes de o software ser construido por revisao, inspeção e análise estática do código. Codigo fonte, durante a construção do software.
   3. Objetivos do Teste

      Anmerkungen:

      • Encontrar os defeitos Prevenir defeitos Ganhar confiança Processo de testeÇ - Testes durante o desenvolviemnto - Teste de aceite - Teste de manutenção - Durante o teste oepracional
   4. Teste x Depuração

      Anmerkungen:

      • Testes visam encontrar as falhas e relata a falha ao programador - Depuração e o artificio que o programador utiliza para encontrar o problema, causa raiz.

Anlagen:

• Os Sete princípios-chave em Teste de Software

Anmerkungen:

• E o processo executado paralalemente com o desenvolvimento de software. Devemos utiliza-lo para planejar as atividades de teste como Recursos, tempo, estratégia, Cenarios e CTs etc... O processo de teste pode ser customizado. Poemos utilizar o processo para testes dinamicos e estatico

1. Planejamento

   Anmerkungen:

   • - Elaborar os Plano de teste, casos de teste, alinhar com o cliente - Plano de teste é um Documento que discreve o escopo, a abordagem, os recursos e cronograma das atividades de teste. Abordagem e estrategia, indica as tecnicas utilizadas e os tipos de testes. Objetivos principais: - Verificar Missão - Definir objetivos do teste - Especificar as atividades de teste Ver modelo de Plano de Teste disponivel no slide 53
   1. Controle do Teste

      Anmerkungen:

      • E a atividade de comparar o progresso atual contra o que foi planejado. - medir e analisar os resultados - Monitorar e documentar progresso - Iniciar ações corretivas - Tomar decisões. responsabilidade do gerente de projeto de teste. A equipe deve sempre envolver a equipe principalemte o analisate de teste.
   2. Lista de Principais Atividades

      Anmerkungen:

      • Identicar os obejtivos - Determinar escopo - Determinar a Abodagemdo teste - Determinar os recursos requeridos - Implementar a politica de teste - Agendar atividades de analise e modelagem  - Agendar implementação execução e a avalização do teste - Determinar os critérios de finalização (Saida)
   3. Ver Modelo Pl. de Teste
2. Analise e Modelagem de Teste

   Anmerkungen:

   • Planejar as condições de teste, Escrever os casos de teste para explorar as funcões, transação, caracteristica, atributo de qualidade ou elemento estrutural. - na modelagem de teste identificamos os itens (funionalidades) a serem testados, identificando os casos de testes. As etapas de analise e modelagem de teste e implementação e execução do teste estão intimamente ligadas, uma diz o que testar e a outra como.
   1. Principais Atividades

      Anmerkungen:

      • Revisar a base de teste (documentos de requisitos) - Procurar os resitos mau definidos - identificar condições de teste - Priorizar as condições de teste - avaliar a testabiliade (verificar se e possivel testar os requisitos, ex.: imiprimir 100 notas fiscais em ate 30 segundos). - Modelar o ambiente de teste (set up), identifcar infraestrutura necessaria e ferramentas.
3. Implementação e Execução

   Anmerkungen:

   • Transformar as condições de teste em casos de teste e configurar o ambiente para a execução. Criar os casos de testes com os passos necessarios para se obter o resultado esperado. Teste positivos e negativos para cada condição de teste.
   1. Principais Atividades

      Anmerkungen:

      • - Criar os casos de teste - priorizar os casos de teste - Criar dados de testes - Escrever os procediemntos de teste - Escrever cripsts de teste - Criar as suites de teste - verificar e atestar se o ambiente de teste foi configurado corretamente. - Executar os casos de teste de acordo com a seq. planejada - Registrar as saidas da execução do teste, criar evidencias dos testes. - Checar os resultados. - Analisar incidentes para estabelecer a sua causa rais- Repetir quando necessario as atividades de teste como resultado de ações tomadas para cada defeito.- Registrar o nivel alcançado de cobertura de teste para medir critérios de saida.
   2. Ver Modelo de TC
4. Critérios de Finalização

   Anmerkungen:

   • A definição de Criterio de Finalização ou Critério de Saida é  um conjunto de condições genéricas e especificas acordas pelos envolvidos no projeto que permite que um processo seja oficialmente considerado completado. Podem ser definidos em termos de: - Eficacia (Cobertura ou requisitos) - Restrições de tempo ou orcamento - Porcentagem de teste executado sem gerar incidentes - Numero de defeitos.
   1. Exemplos de Critérios

      Anmerkungen:

      • 1 - Todos os casos de testes executados 2 - Todo os casos de testes aprovados  3 - Sem incidentes para resolver 4 - Sem incidentes serios para resolver 5 - Cobertura pre definida alcancada (Cobertura de código, Cobertura de Funcionalidade) 6 - Confiabilidade (MTBF) requerida.
   2. Quando parar de Testar

      Anmerkungen:

      • Encontrar o ponto de equilibrio. O ponto de equilibrio normalmente acontece quando já identificamos cerca de 94% dos defeitos existentes no software. maturidade e necessaria para realizar tais medições.
   3. Avaliação do critério de saida e relat.

      Anmerkungen:

      • Se os criteriod e testes especificados anteriormentes nao forem atingidos então certos testes devem ser repetidos ou criar novos casos de testes..
5. Encerramentos de Teste

   Anmerkungen:

   • Esta atividade consiste em reunir as documentações, informações, desempenho das atividades, consolidar experiencias realizar reunião de lições aprendidas e atualizar e armazenar o testware. Testware é toda a documentação gerada pelo processo de teste, plano de teste, CTS, base de daos, etc...
   1. Principais Atividades

      Anmerkungen:

      • - Checar se o que foi planejado foi  entregue - Analizar os defeitos encontrados (Identifica causas raizes e elabora planos de ação) - Finalizar e armazenar o testware para reutilização - realizar reunião de lições aprendidas. Discutir sempre fatos e nunca discutir pessoas.. se não sera lavagem de roupa suja
6. Processo de Desenv. X Teste

   Anmerkungen:

   • O teste não é uma fase do ciclo de desenvolvimento de software, é parte de todas as fases.

Anmerkungen:

• Cuidade em reportar os defitos, pois podemos ser interpretados errados.

1. Relacionamento entre Desenv. e Testadores

   Anmerkungen:

   • Programador quer terminar o sistema enquanto testador quer quer que todos os defeitos sejam corrigidos. E pode ser pontos de conflitos. Muito importante que todos trabalhem juntos e numa meta comum.
   1. Comunicação Objetiva e não Subjetiva

      Anmerkungen:

      • Reporte das falhas se moda objetiva colocando versões e evidência do problema. Direto e sem opnião própria.
2. Bons Anlista de Teste

   Anmerkungen:

   • - Boas habilidade de comunicação - Boas habilidades de observação - Habilidade para lidar com pessoa - Ser Curioso - Ser paciente  - Ser confiável - ser meticuloso - Ser um investigador nato. - Ter muita atenção nos detalhes - Ser criativo para identificar prováveis locais de falha
3. Teste Independente

   Anmerkungen:

   • E indicado que haja equipe de teste separado da equipe desenvolvimento, pois teem visões diferentes e quem desenvolve muitas vezes são envolvidos pelo sistema de maneira a olhar sempre o resultado que se espera e não notam falhas que estão a frente dos olhos. Por isso uma equipe comuma visão holistica do todo que o software precisa realizar, deve esta responsavel por realizar os testes.
   1. Niveis de Independência

1. Principais Envolvidos

   Anmerkungen:

   • Gestor da qualidade Lider do prjeot de teste Arquiteto de teste Analista de teste Testador Usuários
2. Principais Organizações

   Anmerkungen:

   • BSTQB CTFL ISEB CTFL QAI CSTE ALATS CBTS
3. Normas e Padrões

   Anmerkungen:

   • BS7925-1 define um glassario de teroms sobre testes de software BS7925-1 Definie os padrões para o processo de teste de software IEEE 829 Define normas e padrões para o processo de teste e qualidade do prduto ISO 9126 Define as caracteristicas da qualidade do software.
4. Norma IEEE 829

   Anmerkungen:

   • A norma IEEE 829 mostra as documentações necessarias para o prcessod e teste. Especificações: - Plano de teste- Espaecificação de projeto de teste- Especificação de cado de teste- Especificação de procedimento de teste (passo para execução) Relatorio:- Diario de teste- relatprio de incidentes de teste- relatorio resumo de teste- Relatorio de encaminhamento de item de teste (Em caso de equipe distintas de desnvolvimento ou de teste )

1. Definição de Requisitos

   Anmerkungen:

   • Definição: - Se os requisitos nao tem nem software nem teste. - Requisito e o que o sistema deve ter para atender plenamente ao proposito para o qual foi criado. - uma condição ou capacidade de resolver um problema, para suprir um sistema que satisfaça um contrato ou um padrão.
   1. 56% dos erros Iniciam em requisitos
2. Níveis de Requisitos
   1. Requisitos de Negócio (O quê)

      Anmerkungen:

      • requisitos de negócio organiza as caracteristicas e necessidades identificadas descritivamente de maneira que sejam clara e objetiva o que se pretende da aplicação.
      1. Requisitos Funcionais (O quê)

         Anmerkungen:

         • Requisitos funcionais são fucionalidades identificadas necessarias a partir do requisitos de negocios que descreve os requisitos necessarios para atender necessidades de um deteermionado negocio. Ex: manter clientes, manter filmes, reallizar locações, realizar devoluções etc..
         1. Especificação Técnica (Como)

            Anmerkungen:

            • Detalhamento das classes e metodos que sera implementadas para a construção do software.
      2. Requisitos Não Funcionais (Restrições do como)

         Anmerkungen:

         • Requisito não fucionais são requisitos que não discrevem uma funcionlidade do sistema mas exigências de resultados de saida das aplixações . Ex: Emitir Relatprio do sistema no maximo 5 segundos, Deve ser executado por meio da Web. Restrições de como fazer, nao representam funcionalidades da aplicação mas como devem ser apresentadas.
3. Modelo V

   Anmerkungen:

   • teste nao e uma fase mas um processo integrado ao ciclo do desnvolvimento do software. Ocorre paralelamente. Beneficios do modelo V:  Prmite a identificação de riscos e estratégias para remosção e mitigação sejam realizadas no tempo certo e de manier eficiente. entre 50 a 70% das falhas podem ser encontradas por meio das revisões dos documentos.
   1. Por que existe Níveis

      Anmerkungen:

      • O teste e dividido em niveis por que cada nivel de teste possui um objetivo diferente. estes niveis de teste classificam os teste de acordo a etapa de desenvolvimento em que são realizados.
   2. Quando Iniciamosos Testes

      Anmerkungen:

      • Devemos iniciar o quanto antes for possivel dentro do ciclo de desnvolvimento. Após a construção teriamos o planejamento pronto e poderiamos iniciar os testes ganhando tempo ao projeto.

Anmerkungen:

• Teste Unitário Teste de Integração Teste de Sistema Teste de aceitação Ex: Robo de Lego

1. Unitário

   Anmerkungen:

   • Testes feitos pelo programador Teste isoladamente os menores componentes do software, classe , função. Testa se as funcionalidades desenvolvidas atendem o que deve fazer. Empresas utilizam Checklists Nesta fase sao feitos testes funcional e não funcional devem ser validados.
   1. TDD (Test Driven Development)

      Anmerkungen:

      • Os testes sao modelados antes dos códigos serem escritos.  1 Escreve o casos de teste 2 Execute o teste 3 Refatore o código
2. Integração

   Anmerkungen:

   • Busca de erros que podem acontecer durante a integração das diferentes unidades componentes do software. Acontecem de maneira recursiva. Slide 29 Um Driver, programa responsável para que outros executem estes testes por outros e os resultados são apresentados para os testadores. Um STUB, Simular dados de testes para testar componentes ou unidades.
   1. Integração de Componentes
   2. Integração de Sistemas
   3. Estratégias

      Anmerkungen:

      • Top Down Bottom Up Big bang
      1. Bottom up

         Anmerkungen:

         • Bottom up ou ascendente.  Cada módulo e testado individualmente, primeiro pelos modulos mais baixos da hierarquia, e segue testando subindo para os acima. Sempre nesta abordagem utiliza-se DRIVERS de teste.
      2. Top Down

         Anmerkungen:

         • O teste acontece de cima para baixo na hierarquia e sempre utilizando STUBS, simulando testes e no final todo o sistema é testado.
      3. Big Bang

         Anmerkungen:

         • Sugere testar cada unidade ou modulo individualmente e somente depois realizar os testes de integração. Não é muito indicada.
3. Sistema

   Anmerkungen:

   • Testar o comportamento funcional definido pelo escopo do projeto. Validar as regras de negócio Testes de validação (CAIXA PRETA) testados sempre pela equipe de teste e não mais pelos programadores. Acontecem após aos testes de aceitação. Testar considerando um ambiente mais próximo possivel ao ambiente de produção, ao qual o sistema funcionará e sera utilizado. Colocar o teste a prova.
   1. Teste Integrado com outro Sistema

      Anmerkungen:

      • O teste de integração de sistema esta entre o teste de sistema e o teste de aceitação. - tem o objetivo de validar as interfaces entre componetes de alto nivel. 
4. Aceitação

   Anmerkungen:

   • Teste de aceitação e um teste formal relacionado as necessidades do usuário. E realizado para estabelecer se um determinado sistema satisfaz ou não os critérios de aceite do cliente. Não e foco do teste de aceitação PROCURAR erros.
   1. Conceitos de Aceitação

      Anmerkungen:

      • E importante para assegurar que o sistema esta em condições minimas de aceitação para que o sistema seja utilizado. - Os testes de aceitação sao de responsabilidade do cliente e do usuário e ver se atende suas necessidades. teste de alto nivel são enviadas para o usuario  executar. - Apesar de esta etap ser a ultima no modulo V, mas os testes podem ser anteciapdos interativamente com o usuario (feedback antecipado). - Fazes de teste de aceitação 1 teste de aceitação de usuario 2 - teste de aceitação operacional 3 - Alfa teste e Beta teste.
   2. UAT

      Anmerkungen:

      • User Acceptance Test Envolver o usuario e importante pois podem aparecer erros que somente eles serão capazes de encontrar. Estes teste devem ser realizados no ambiente do usuario. Tendem-se a ser teste mais rapidos. Validar as funciolidades principais 
   3. OAT

      Anmerkungen:

      • Operational acceptance testing Teste de aceite por quem ira administra-lo.  Os teste sao realizados pelo administradores do cliente com acompanhamento dos testers.
   4. Alfa ou Beta Teste

      Anmerkungen:

      • São empregados quando o sistema visa ser usado por muitos clientes. Alfa aconrece em um ambiente controlado. Beta acontece e lançado para os clientes utilizarem e geralmente não sao acompanhados pela equipe de desenv. do software.

Anmerkungen:

• Para Avaliar cada objetivo dos diferentes níveis de testes são utilizados.

1. Alvo do Teste

   Anmerkungen:

   • Diferentes Tipos de Testes sáo utilizados para avaliar Funcionalidades, Confiabilidade, Usabilidade, Estrutura do sistema, Mudanças no Software.
2. Teste Funcionais

   Anmerkungen:

   • Teste funcioal ou caixa preta, Verifica as entradas e as saidas obitidas e que o resultado esteja correto conforme os requisitos funcionais, casos de usos etc. Validar com dados válidos e inválidos.  Este tipo de teste pode ser aplicado em todos os niveis de teste.
3. Testes Não Funcionais

   Anmerkungen:

   • Requisitos não funcionais analisa os aspectos que são importantes ainda que não estejam realacionados diretamente as funções que o sistema desempenha. Teste de Performance, de carga, Stress, Recuperação de falhas, Instalação.
4. Testes Estruturais

   Anmerkungen:

   • Teste estrutural ou caixa branca, é feita sempre pelos desenvolvedores. Tem por objetivo de executar quase todos os caminhos e condições de parada de um fluxo de eventos associados aos componentes testado.  Cobertura do código escrito. Mais comum no nivel de teste estrutural mas pode ser utilizados nos demais.
5. Testes de Confirmação
6. Reteste

   Anmerkungen:

   • Retestes, e a execução do teste novamente após o defeito apontado ter sido corrigido, por isso retestes dos casos de testes para certificar que foi corrigido.
7. Regressão

   Anmerkungen:

   • Regressão: Testas a principais funcionalidades da parte onde houve alterações. Não podemos garantir que todas as falhas serão identificadas. A definição do teste de regressão e certificar que o sistema após ter sofrido alterações não regrediu a qualidade.
   1. Automatização

Anmerkungen:

• Testa as alterações feitas em um sistema operacional ou o impacto das mudanças em sistemas que estão em operação. Não é um tipo de teste nem uma técnica mas faz parte da fase do ciclo de desenvolvimento do software. Problemas que podem ocorrer são : - Falta de rastreabilidade das mudanças - Dificuldade de compreensão do codigo - Ausência de automatização de testes

1. Analise de Impacto

   Anmerkungen:

   • 1 Testar as mudanças realizadas no software. 2 Realizar testes de regressão Avaliar os riscos O escopo do teste de manutenção esta relacionado ao risco de mudança.

1. Teste Estática

   Anmerkungen:

   • Envolve examinar a documentação dos projetos e outras informações sobre os produtos de software sem executá-los. Compreende as atividades de revisão, inspeção e analise estática do código. Muito importante, objetivo é identificar defeitos.
   1. Técnicas Utilizadas

      Anmerkungen:

      • Inspeção Visual Leitura cruzada Inspeção Cada tipo de teste tem por objetivo buscar tipos diferentes de defeitos.
2. Revisões e Processo de Teste

   Anmerkungen:

   • 56 % dos defeitos podem ser identificados na etapa de requisitos. Portanto o propósito de revisar as documentações desde a fase de levantamento de requisitos é impedir que os defeitos prossigam para as fases posteriores.
   1. Custo Relativo

      Anmerkungen:

      • O custo aumenta exponecialmente quando o erro não é identificado nas fases iniciais e segue para as fases seguintes. Durante todas as fases podemos trabalhar com as revisões.
   2. Propagação de Erros

      Anmerkungen:

      • Analogia do corte e costura, tecido seguiu para as demais atividades com manchas e somente foi identificado depois de ter passado pelo corte e custura, aumentando os custos uma vez que o defeito só foi pego tardemente.
   3. Por que Revisar?

      Anmerkungen:

      • - Encontrar defeitos o mais cedo possivel - Mais de 60% do erros nos componentes podem ser identificados através de inspeções. - Reduzir os defeitos entregues no software. - Construir e motivar equipes  - Melhorar a especificação a modelagem e o código. Depois de analise dos erros identificados, como a análise da causa raiz, ajudando apontar as causas a serem melhoradas a fim de mitigar os erros no futuro. Revisões ajudam tambem a melhorar os padrões e procedimentos de desnvolvimento de software.
   4. Quando e o que revisar?

      Anmerkungen:

      • - Revisões podem ser manuais ou automatizados por ferramentas. - Qualquer produto pode ser revisado, qualquer documentos escrito e também os códigos fontes. - As revisões podem ser aplicadas entre fases - Revisões são realizadas bem antes da execução do teste dinâmico.
   5. O que as revisões encontram

      Anmerkungen:

      • Revisões encontram defeitos em vez de falhas. Defeitos típicos encontrados são: - Omissão (Qulquer informação necessaria que tenha sido omitida) - Fato incorreto (E uma informação contraditoria ao conhecimento e definido em outro documento, fato incorreto) - Inconsistência (Informação repetida mas escrita de forma diferente em outra parte da documentação) - Ambiguidade (Leva a multiplas interpretações) - Informação estranha (Qualquer informação estranha que não tem a ver com o assunto ) - Miscelânea ()
   6. Critérios para bons requisitos

      Anmerkungen:

      • - Completude(Documento completo) - Não ambíguo (As informações não estão ambiguas) - Verificável (A informação é testável e mensurável. "O sistema deve ser rapido", rápido quanto?) - Necessario e suficiente (Qual a pior coisa a acontecer se este requisito for retirado ) - Viável e Realista (Os requisitos podem ser implementados com o orçamento e a tecnologia disponíveis?)
   7. Benefícios

      Anmerkungen:

      • Encontra defeitos mais cedo no ciclo de vida do software. - reduz risco da propagação dos erros (Remove de 80 a 95 % dos defeitos em cada estágio) - Encurta os prazos do desenvolvimento - Reduz em torno de 10 vezes dos defeitos identificados no teste dinâmico. - O custo do defeito e reduzido de 50 a 80% - Reduz defeitos a um fator de 10 - Reduz em torno de 28 vezes o custo de manutenção.

1. Tipos de Revisão

   Anmerkungen:

   • - Revisão Técnica (Revisão por pares) - revisão de acompanhamenteo - Inspeção Tipos de Formalidade - Formal - Informal
2. Revisões Informais

   Anmerkungen:

   • - Dois analistas podem conduzir a mesma revisão de formas diferentes. - Não e indicada de que, quem fez a docuementação revise seu proprio trabalho.
3. Revisões formais

   Anmerkungen:

   • - Revisões por pares - existe um padrão de de especidicações e é analisado se as documentações estão em conformidade. - Checklist e relatório da revisão são opcionais.
   1. Revisões Técnicas

      Anmerkungen:

      • São objetivos:  - Discutir - Tomar decisões - Encontrar defeitos - Resolver problemas técnicos e verificar a conformidade com padrões e esécificações - O grau de formaidade varia de acordo com a sua utilização @ Revisões técnicas são mais apropriadas durante a fase de design do processo de desenvolvimento d e software.
   2. Acompanhamento (Walkthrough)

      Anmerkungen:

      • E uma revisão do material onde o principal objetivo e treinar os envolvidos no projeto a fim de ensinar os envolvidos para obter o entendimento. O cliente pode participar. Fraqueza do walkthrough e não identificar defeitos mas somente treinar.
   3. Inspeções

      Anmerkungen:

      • - E o tipo mais formal e que atinge os melhora resultados. - A principas meta das inspeções e detectar defeitos, a segunda meta e fonrnecer sugestões de melhoria sobre o escopo a se inspecionado. - Ispeções trazem excelente resultados quando utilizadas nas fases do ciclo de vida de software.
      1. Regras

         Anmerkungen:

         • Deve existir um Moderador que não pode ser o autor do documento, ele ira conduzir a reunião. Principais participantes: Moderador, Autor do Doc., o usuário, um par do autos do documento e demais interessados. - Reunião limitado a 3 e no maximo 7 participantes. - Preparação antecipada para a reunião Deve ter o formato: - Declarar os critérios de entrada e saida - Procurar e registrar defeitos - Registrar indocadores
      2. Processo Formal de Rev.
      3. Planejamento

         Anmerkungen:

         • - Defiinir criterios de entrada e saida - Reuniões de inspeções devem durar em torno de 90 minutos podendo chegar ate 2 horas em casos mais complexos. - identificaue os papeis e particiapente da reunião e estabeleça tempo e o local para revisão. - participantes devem se preparar com antecedência para a reunião.
      4. Kick-off (Reunião de partida)

         Anmerkungen:

         • - Esta etapa ocorre justamente com o planejamento da inspeção - Neste momento que o material a ser inspecionado deve ser distribuido para os participantes - Um checklist deve ser criado contendo os itens importantes que os participantes usarão para inspecionar os documentos. - É importante certificar-se que os critérios de entrada tenham sidos cumpridos (Ex: que a especificação funcional tenha sido concluída pela equipe de desenvolvimento)
      5. Preparação

         Anmerkungen:

         • Esta etapa é a mais importante. Todos os revisores convocados para a inspeção decem ler o material antes da da reunião e realizar suas análises, buscando o entendimento do conteúdo documento, procurando por problemas (De escopo, técnicos, de comportamento, regras não definidas adequadamente), defeitos e melhorias. - Os envolvidos devem conhecer o negocio. - Normalmente, dependendo da senioridade, gasta-se de 1ha 2h para leitura do material. - Devem anotar os defeitos suspeitos,tomar nota sobre duvidas para serem esclarecidas. - Em certas situações, o moderador pode pode pedir para dividir a equipe para tratar de aspectos diferentes como usabilidade, performance etc..
      6. Reunião de Revisão

         Anmerkungen:

         • Moderador e responsavel por abrir a reunião. E importante que o moderador apresente o objetivo da inspeção e lembra o que está sendo inspecionado e o documento ou produto e não pessoas. - Todos devem estar preparados para analisar criticamente os artefatos. - Todos devem discutir criticamente sobre as não conformidades.encontradas. - Se existirem pessoas que não estão preparados, a reunião deve ser cancelada e remarcada para outra data. Durante a reunião lembre-se que: -  O objetivo é achar os problemas e não resolv~e-los - O que está sendo avaliado é o produtos e não o seu autor - O autor está presente para esclarecer e não para justificar. - Reuniões não devem ultrapassar 90 minutos - os tempos devem ser registrados. - Ao final da reunião é decidido se é necessário a re-inspeção no documento. *DICA* - Sugestões durante a reunião e se aprovadas devem ser incorporadas ao documento, mas não precisam ser registrados em nehum controle paralelo.
      7. Retrabalho

         Anmerkungen:

         • - O autor deve corrigir os defeitos encontrados e incorparar as sugesões de melhoria realizadas e aprovadas durante a inspeção. - O autor corrige as não conformidades encontradas e anota na lista de não conformidades a ação tomada. - Boa prática é registrar o tempo gasto para cada correção de defeito.
      8. Acompanhamento

         Anmerkungen:

         • - Após a reunião de inspeção, o moderador deve fazer um acompanhamento dos trabalhos junto o autor do documento. Nesta etapa o moderador checa se todos os defeitos principais foram corrigidos. - E que todos os defeitos tenham sidos registrados para futuras estatísticas e assegurar que os critérios de saida foram atingidos. - Caso tenham decidido durante a reunião que uma reinspeção é necessario, então é necessario agendar uma nova reunião de inspeção.
      9. Papéis e Responsabilidades

Anmerkungen:

• Técnica de teste automatizada que busca erro de sintaxe, violações de padrões e outros possíveis erros no código fonte. Deve ser utilizada por programadores durante a programação e testes unitário. Avalia a complexidade do codigo escrito. Ajuda na padronização do código durante a programação, pois um codigo despadronizado se torna complexo para uma futura manutenção no código.

1. Valor

   Anmerkungen:

   • -A analise estatica pode identificar defeitos que são mais dificeis de serem localizados pelo teste unitário do sistema. - Como nas revisões, a analise estatica encontra defeitos ao invés de falhas. - As ferramentas geram saidas em HTML ou XML das analises de códigos. - Calcula métricas com uma medida de alta complexidade, indicando que determinado trecho de codigo seja reescrito. - Melhora a manutenção do código atraves da padronização do código. - Custo beneficio pois os problemas são encontradis anteriormente e são mais barato para consertar.
2. Tipos de Defeitos Encont.

   Anmerkungen:

   • Lista de defeitos podem ser encontrados atraves de uma ferramenta de analise estatica. Variaveis nao declaradas - Tipos de parametros incorretos - Procediemtnos e funcões não usadas - Possiveis violações de limites de vetores - Violação de segurança - Interfaces incosistentes entre modulos e componentes - Uso incorreto de variaveis - verificação de sintaxe -Violação de padrões de codificação - Uso de variaveis sem definilas primeiro - Variaveis declaradas e nunca utilizadas.
3. Técnica Fluxo de Controle
4. Complexidade Ciclomática

   Anmerkungen:

   • A complexidade ciclomática é uma medida da complexidade de um fluxo de controle. Ela identifica como o código é dificil de entender, testar e manter. Tambem identifcia o risco associado ao teste de um programa. COMPLEXIDADE CICLOMÁTICA = NÚMERO DE DECISOES +1 Obs.: Na formula acima, e representado o nivel de complexidade de um fluxo de controle a partir da quantidade de IFs aninhados +1, por exemplo, em um codigo com dois IFs dizemos que tem grau de complexidade Nivel 3 (IF 1 + IF2 +1)
   1. Teste Baseado em Risco

      Anmerkungen:

      • E avaliado o risco de determinado código falha. Quanto maior a compexidade ciclomatica de um codigo, maios o risco envolvido e maior a complexidade do próprio código. Tem impresas que não autorização manter códigos que tenham complexidade acima de 50 por exemplo.

Anmerkungen:

• Vimos o teste estático no modulo 3, agora veremos o Teste Dinâmico.

1. Introdução

   Anmerkungen:

   • Software sempre possuirão defeitos. Portanto é de resposnsabiliade da equipe de teste desnhar testes que, revelam defeitos, podem ser usados para avaliar a performance, usabilidade e confiabilidade do software. O analisata deve planejar para testar, selecionar as condições de teste, monitorar o processo de teste para assegurar que os recursos e tempo alocados estão sendo utilizados de maneira efetiva.
2. Definição

   Anmerkungen:

   • Primeiro precisamos identificar as possibiidades de teste que deveremos escrever para testar o software. Seria o "O QUE". E depois de escritos o que iremos testar partimos para o "O COMO", então os casos de testes são escritos.
3. O Processo

   Anmerkungen:

   • Os requisitos e especificações formam a base de teste. E a partir da base de teste, temos as condições do teste e priorizamos os testes (O que) A partir das condições de teste partimos para os casos de testes (Como), e depois seguimos com os scripts de testes (Como) e podemos então criar o cronograma de execução. (Quando)
4. Condições de Teste

   Anmerkungen:

   • Condições de Teste: é um item ou evento de um componente ou sistema que pode ser verificado por um ou mais casos de teste, como por exemplo: Função, transação, caracteristicas, atributo de qualidade ou elemento. Para um gerencimento, as condições de teste podem ser agrupados por objetivos de teste ou ainda por função. O melhor é considerar os testes por requisito, e classifica-los por nivel de risco que a condição de teste seja priorizada numa situação de falta de tempo ou orcamento.
   1. Rastreabilidade Por Req.

      Anmerkungen:

      • Caso o requisito sofra alterações, saberemos quais os casos de teste precisam ser atualizados. Codigo req - Descrição RF 01 - CT 01 - Cadastrar cliente válido   
   2. Priorização das Cond. de Testes

      Anmerkungen:

      • Após a identificação as condições de teste precisam ser selecionadas e priorizadas. A condições de teste podem ser priorizadas considederando alguns critérios - Prioridade importancia - Severidade do impacto - Probabilidade de ocorrer falhas - Custo da ocorrência Ver Planilha Exemplo slide 14
   3. Casos de Teste

      Anmerkungen:

      • Caso de teste e um conjunto especifico de entrada de dados, condições de execução e resultado esperado com a finalidade de avaliar os requisitos especificados do sistema. Um bom caso de teste é aquele que apresenta uma elevada probabilidade de revelar um erro ainda não descoberto. Estrtutra tipica de um caso de teste: 1 - identificador do CCT 2 - Condições de teste 3 - Especificações de entrada 4 - Resultados esperados 5 - Ambiente necessário 6 - Exigências especiais 7 - interpendências Os resultados esperados devem estar bem especificados para que a decisão do testador não opte por uma decisão plausivel que induza à aceitar quando não se tem claro o que se espera do CT executado. Ver exemplos Slide 17
      1. Oráculo do Teste

         Anmerkungen:

         • O Oráculo do teste é a fonte utilizada para determinar os resultados esperados e compará-los com os resultados reais produzidos pelo software em teste. O oraculo pode ser Manual de usuario, especiificação, conhecimento especializado. Mas jamais poderá ser baseado no codigo escrito, pois ja pode conter falhas. Entende-se que o resultado esperado do teste pode ser previstos Se não for possivel, provavelmente é por que estamos testando  de forma errada ou estamos testando algo errado. Tipos de Resultados Esperado são: - Valores de saida - Transição de estados - Mudança de dados - Tempo de resposta do sistema
      2. Critérios de Qualidade

         Anmerkungen:

         • Para entedner os requisitos de qualdiade, um caso de teste deve ser: - Efetivo - Economico - Repetível - Rastreável - Autoexplicativo
5. Script de Teste

   Anmerkungen:

   • Procedimento de teste: é a especificação de um conjunto de casos de teste colocados em uma ordemde execução. Procedimento é mais usado quando os testes são feitos Manualmente e o termo SCRIPT  é mais udado quando os teste são realizados automaticamente. Como elaborar uma script de teste? - A maneira bem usual é você manter no documento apenas a sequ~encia de execução dos casos de teste, os passos necessarios para configuração ambiente de testes e base de dados, setup de ferramentas e outra atividades necessarias para a execução dp teste.
6. Cronograma

   Anmerkungen:

   • É um esuqema para executar os procedimentos de teste. Todos os casos de teste devem ser sequenciados na ordem em que serão executados. Após isso, é necesario estimarmos um tempo previsto paara cada execução e definir quando será executado e por quem. - os testes podem ser automaricos ou manuais. - Considerar os testes de regressão no cronograma para garantir que as alterações não causaram novos defeitos. - os teste mais importantes devem ser priorizados por primieiro.

1. Teste Caixa Preta

   Anmerkungen:

   • É o teste em que o componente de software a ser testado é abordado como se fosse uma caixa preta, ou seja não se considera o comportamento interno do mesmo. É um teste baseado no que o sistema faz.  O componente de software a ser testado  pode ser um componente, um conjunto de programas ou componentes, requisitos, funcionalidades etc.. Mais comumente aplicado no nível de teste de sistema, mas poe ser aplicavel a todas as fases ou estágios do teste. Teste baseado na especificação do sistema. Pode ser aplicado tanto em teste não funcional ou funcional.
   1. Partição de Equivalência

      Anmerkungen:

      • É uma técnica que parte de um domínio de entrada ou de saída para o quela se presume, com base na especificação, que o comportamente de um compoente ou sistema seja o mesmo. Esta técnica é extramamente util para selecionar casos de teste representativos e não testarmos duas vezes o mesma condição de uso do sistema. Devemos separar as partilçoes validas e inválidas para ser objetivo na cobertura de testes sem repetir testes que ja cobriram as partições.
   2. Análise de Valor Limite

      Anmerkungen:

      • É a técnica de modelagem de teste de caixa preta na qual os casos de teste são projetados com base nos valores limite de cada partição de equivalência. Nesta técnica sempre teremos para cada limite teremos sempre um teste inválido e dois válidos para o limite inferior e para o superior. * Esta técnica complementa a técnica de PARTIÇÃO DE EQUICALÊNCIA. * As experência nos mostra que os erros são mais suscetíveis acontecer nos valores limites das partições - Sempre devemos testar os valores limites das classes de equivalência (Partições).
   3. Tabela de Decisão

      Anmerkungen:

      • É uma técnica que pode ser utilizada quando existirem direntes combinações de entradas no software que resultam em diferentes acoes que o software deve realizar. O desafio da tabela de decisão é organozar as combinações de valores de entradas no sistema e para cda combinações unica definir qual será a ação que o software deverá fazer. Ela é utilizada para regra regras de negócio complexo.
   4. Diagrama de transição de Estados

      Anmerkungen:

      • Um sistema pode exibir respostas diferentes dependendo da sua condição atual. - Estado, pode ser descrito como uma posição finita do software. Cada software pode possuir um numero finito de diferentes estados e a transição de um estado para o outro é deterinada pelas regras de negócio do próprio sistema. - É uma técninca de modelagem caixa-preta na qual os casos de teste são modelados para executar transições de estados válidos e inválidos. A estrutura básica da técnica de transição de estados sãoÇ - Estado - Transição - Evento - Ação - Estado Inicial - Estado Final Temos diferentes maneiras de exprimir os possiveis estados versus eventos.  Pode ser por Tabela Estados x Eventos, tabela transições x estados, Circulos com setas...
   5. Teste de Caso de Uso

      Anmerkungen:

      • Caso de Uso: É um método para mapear e descrever requisitos e seus comportamentos. Um Caso de uso é composto: - Ator - Descrição - Pré-condições - Pós -condições
2. Teste Caixa Branca

   Anmerkungen:

   • O teste caixa branca analisa a estrutura interna do componente, analisa o codigo. Deve ser feita por alguem com conhecimento do codigo e do negocio. É aplicado principalmente no nivel de teste unitário e de integração e é realizado pela equipe de desenvolvimento. Em algumas situações os casos de testes são criados antes mesmo do desenvolvimento, através da técnica TDD. Podem ser funcionais ou não funcionais. 100% do godigo deve ser testado por teste unitário. E indicado que um software para teste deva ser utilizado.
   1. Cobertura e Modelagem

      Anmerkungen:

      • Técnicas de teste caixa-branca servem para dois propósitos: - Medir a cobertura dos teste - facilitar a modelagem de casos de teste estruturais. A cobertura de teste mede, de forma especifica, a quantidadede testes realizados por um conuunto de casos de teste (derivados de tecnicas formais)   As formas de contar os itens testados ou itens cobertos pelo teste são: - Tecnica de Partição de equivalência - Técnica de análise de valor limite - Técnica de tabela de decisão 100% de cobertura não significa um sistema 100% testado.
   2. Teste de Sentença

      Anmerkungen:

      • Statement Test. É uma técnica de modelagem de teste caixa-branca na qual os casos de teste são modelados para executar as sentenças(Comandos) - A cobertura de teste avalida desta tecninca é pelo percentual de comando executáveis que foram exercitados por um conjunto de casos de teste.
   3. Teste de Decisão

      Anmerkungen:

      • E uma tecnica de modelagem de teste caixa-branca na qual os casos de teste são modelados para executar os resultados de decisão. IF, ELSE, DO, WHILE, REPEAT, UNTIL, CASE. * Pode ser referencoado como teste de branch. O teste de decisão é um teste mais aprofundado que o teste de sentença. Podemos afirmar que o teste de decisãoé mais eficiente que a cobertura de sentença. 100% da cobertura de decisão é 100% de cobertura de senteça, mas não é vice-versa.
   4. Outras Técnicas

      Anmerkungen:

      • Teste de Fluxos de dados, é teste de modelagem de teste caixa-branca na qual casos de teste são modelados para executar definições e utilizar pares de variaveis. - teste de sequência de codigo linear e salto, Técnica para desenhar casos de teste onde lacos ou loops, sao identificados e casos de teste são desenvolvidos para testar sequncias lineares de codigo que começam em um ponto especifico no codigo e podem terminar pulando parte do código. 
3. Técnica Experiência

   Anmerkungen:

   • Teste com base de conhecimento de uma pessoa, experiência, imaginação e intuição. - Alguns defeitos são dificeis de encontrar usando uma tecnica mais sistematica - Nem todos os defeitos são identificados com técnicas formais. - Não é possivel medir o nivel de cobertura alcançado pelo teste.
   1. Adivinhaçao de Erros

      Anmerkungen:

      • Error Guessing Esta técnica usa a experiencia do testador para identifcar erros. - Não use esta tecnica com primeira escolha. - Para deixar esta tecnica mais estruturada, faca o seguinte: - Vrie uma lista de todos os possiveis defeitos - Crie teste para medir esses defeitos. Não há regras para a utlização desta técnica. Situações tipicas para se tesstar com esta tecnica podem incluir: Divisão por zero Campo em branco Data Inexistente Data final maior que a data inicial Campos obrigatórios com valores nulos Uso de caracteres especiais em campos que não os aceitam. Um checklist pode ser utilizado como base para o teste.
   2. Teste Exploratório

      Anmerkungen:

      • É uma abordagempratica em que os testadores estão envolvidos no planejamento minimo e execução maxma do teste, ou seja, não há muito planejamento de teste. O foco preferencial é a execução. - um aspecto chave desta abordagem de teste é a aprendizagem por parte do testador sobre o software, o seu uso, seus pontos fortes e suas fraquezas. - Esta e uma abordagem maus util quando não há especificação formal do software equando o tempo é muito limitado.

Anmerkungen:

• O trabalho da equipe de teste é trabalhar em dois grandes blocos: - Teste e Controle da qualidade - Garantia da Qualidade Ao montar uma equipe de teste certifique-se de que você é competente, tem uma boa equipe e seja politicamente suportado para o seu papel.

1. Teste Independente

   Anmerkungen:

   • Mito que devemos independente "Desenvolvedores não testam ou não deveriam testar". A responsabilidade de entregar o codigo funcionando e do programador e por ser uma atividade mental, naturalmente erros pode acontecer. Por isso equipes de teste são mais eficazes do que o próprio desenvolvedor em relação ás atividades, pois geram mais mehores resultados quando trabalham em um conjunto e de forma colaborativa com a equipe de desenvolvimento. Não confundir teste independente com a ausência de realização de testes pela equipe de desenvolvimento.
   1. Niveis de Indep. de teste

      Anmerkungen:

      • Nivel 1 - Somente os desenvolvedores são responsaveis pelos teste. (Não recomendado) - Nivel 2 - testadoes independentes dentro da equipe de desnvolvimento (Teste Amigo) - Nivel 3 - Equipe de teste independente - Nivel 4 - Especialistas em teste independente para um objetivo especifico de teste com teste de usabilidade, seg, ou certificação Nivel 5 - Equipe de teste terceirizada ou independente da organização.
   2. Vantagens e Desvantagens

      Anmerkungen:

      • vantagens ^ - Testes feitos com um nivel mais criterioso. Desvantagem: - Se for tratado com independencia total, pode causar isolamento da equipe de desnvolvimento. - Desenvolvedores podem perder o senso de responsabilidade pela qualidade do software.
   3. Niveis de Indep.

      Anmerkungen:

      • Niveis de independência: Os niveis de independencia abaixo: - Teste de aceitação (Equipe de testes) - Teste integrado (Equipe de testes) - Teste de sistema (Equipe de teste) - Teste de integração (Equipe de Desenv.) - Teste Unitário (Equipe de desenv.)
2. Lider de Teste

   Anmerkungen:

   • O lider de teste e tambem conhecido como gerente de teste ou coordenador de teste de teste. Se a empresa for muito grande e a equipe de testes tambem, as atividades de gestçai de teste podem ser desdobrados em dois papeis: Gerente de teste e lider de teste. Geralmente o lider de teste e responsavel por: - Elaborar e manter politica de teste - manter contato com cliente - Planejamento de teste - Documentação do teste - Monitoramento e controle - Prover treinamento para a equipe de analistas de teste - Aquisição de ferrramentas - Etc...
3. Testador

   Anmerkungen:

   • Conhecido tembém como o Analista de teste. Ele pode ser especialista em alguma area especifica de teste como: Automação Performance Usabilidade Seguranca Ou pode trabalhar de forma mais horinzontal realizando: Analise de teste Modelagem de teste Execução de teste Ger. do ambiente de teste Ger. dos dados de teste

Anmerkungen:

• Todos os projetos requerem um conjunto de planos de planos e estratégias que definem como os teste serão realizadosÇ Nivel da Organização --> Politica de teste Nivel do Projeto --> Plano de teste mestre Ou Sub dividir  Plano de teste unitário, Plano de teste do sistema, Plano de teste de aceitação.

1. Fatores

   Anmerkungen:

   • Fatores que influenciam o planejamento de teste. - A politica teste da empresa - Escopo dos testes - Objetivo do teste - Riscos do Projeto - Restrições - Disponibilidade de recursos.
2. Plano de Teste

   Anmerkungen:

   • Itens do plano de teste segundo a norma IEEE 829. (O Plano de teste é um documento que descreve basicamente o escopo, a aboradagem, os recursos e o ronograma das atividades de teste.) itens que deve conter no Plano de teste  - Identificação do plano de teste. - Introdução - Etc...
3. Padrão IEEE829

   Anmerkungen:

   • Padrão de referencia para planejas as atividades de teste.
4. Critérios de Finalização

   Anmerkungen:

   • Critérios de Saida (Finalização) é um conjunto de condições genericas e especificas, acordadas pelos stakeholders (interessados), que permite que um processo seja oficialmente considerado completo. - Definir um critério que sirva de parametro para que haja a decisão de finalização do teste. Seja por custo, tempo, limite de defeitos, foi completado a correção de todos os defeitos. * Estes criterios devem ser definidos no plano de teste.

Anmerkungen:

• Esta etapa e a que mais gera mais desconforto, pois apos dar uma estimativa vc se compromete com os prazos. Mas e uma necessidade ter as estimativas pois custos precisam ser aferidos, o orcamento, recursos. Estimativas nao sao exatas, mas deve estar entre +- 10%. Como Estimar? Não tem milagre, precisa ser utilizado por estatistica, a base historia pode ser utilizada como base. outras técnicas podem ser, Auxilio de especialista, Feeling dos participantes do projeto, analise por pontos de funcção ou linhas de código. E indicado que para facilitar a estimativa, quebre as atividades em pacotes menores para estimar.

1. Fatores

   Anmerkungen:

   • O esforço de teste pode depender de varios fatores: - Caracteristica do produto (Qualidade da especificação, a complexidade do negocio e a tecnica do produto) - caracteristica do processo de desnvolvimento (a maturidade da organização, ferramentas utilizadas, habilidade das pessoas envolvidas, pressão de tempo) - Os resultados dos testes (numero de defeitos, a quantidade de retrabalho) Uma vez que a estimativa esteja finalizada, os recursos necessarios e cronograma podem ser finalizados.

Anmerkungen:

• Estratégias de teste descrevem em alto nivel o que é necessario para desempenhar o teste: as principais atividades, as técnicasde teste que serão usadas, as ferramentas, qualqeur restrição para o teste e qualquer suporte requerido. Temos as abordagens analitica baseada em riscos e as atividades serão realizadas mais cedo durante o ciclo de desenvolvimento. - Abordagem dinamica, normalmente os testes só iniciarão após a construção do software. Os diferentes tipos de abordagens são: - Analitica - Baseada em modelos - Abordagem metódica - Compativel com processos ou padrões - Dinâmica e heuristica - Baseada em conselhos - Regressão Não existe uma tecnica mais indicada, deve ser utilizada com base do contexto.Slide 35

Anmerkungen:

• Realizamos a monitoração do progresso de teste para saber o status do projeto em um dado ponto do tempo.  Avaliamos o projeto de teste em relação: - Ao cronograma de teste - E ao orcamento definido Na imagem ao lado temos os possiveis indicadores a ser utilizado para monitorar as atividades de teste.

Anmerkungen:

• E a resposta aos problemas encontrados atraves do monitoramento e relatorio. o processo de controle envolve realizar ações para por o projeto nos trilhos novamente.

Anmerkungen:

• O conceito é organizar os itens do software de modo a saber em qual estado o software se encontrava nos momento chave do desnevolvimento, como por exemplo quando o sistema foi enviado entrege ao cliente e quando o sistema foi enviado para a area de teste. Um mal gerencomaente de config. são  - Nao conseguir reproduzir uma flha reportada pelo cliente. - Uma alteração acaba sobrescrevendo outras - Falhas são corrigidas e reaparecem - Testes são executadas em versões não estáveis. Iten de configuração e controle: - Baseline (E uma foto de uma versão de um artefato ou de um sistema no repositorio do projeto)

Anmerkungen:

• Risco e um evento ou condição incerta que, se ocorrer, provocará um efeito positivo ou negativo nos objetivos do projeto.

1. Riscos e Testes

   Anmerkungen:

   • Devemos priorizar os testes considerando sempre os riscos.
2. Tipos de Riscos

   Anmerkungen:

   • Exemplo da empresa de bebidas que o modulo de alto risco e o de faturamento. Identificando os riscos: - Avaliar problemas ja enfrentados em outros projetos - Reuniões de brainstorming com envolvidos - Rever a documentação do software - Utilizar uma lista de verificação com os riscos conheciso.
3. Medindo Riscos

   Anmerkungen:

   • Podemos priorizar os riscos identificados medindo a probabilidade versus imapcto. Medida de Risco (Criticdade) = Probabilidade x Impacto Outra opção é a Matriz de Priorização. Na matriz podemos pontuar os riscos identificados numa ordem de importancia a fim de que concentremos os esforcos prmieiro nos que tem riscos mais importante. Os riscos classificados com criticidade alta e média deverão ter atenção maior durante o projeto de testes.
4. Ações
5. Testes Baseados em Riscos

   Anmerkungen:

   • O teste pode ajudar na identificação de novos riscos. - teste e usado para reduzir a probabilidade de um risco ocorrer ou reduzir seu imapcto - Teste fornece feedback sobre o risco residual. Pratica: Situação 1  Situação 2 ver slide 66
6. Conclusão

   Anmerkungen:

   • Priorizar os testes de modo que, sempre que você para o teste, você tenha a certeza que realizaou o melhor teste no tempo disponivel.

Anmerkungen:

• Incidente é: Qualquer diferença entre o resultado obitido e o esperado. As causas podem ser: - Um defeito no software - Um defeito no teste - O ambiente de testes estava mal configurado - O teste foi executado de forma incorreta - Falta de documentação

1. Principios Basicoc

   Anmerkungen:

   • - Todos os incidentes devem ser registrados - Devem ser rastreável - devem ser geridos atraves de um processo formal de gerenciamento. - Os incidente podem ser identificados em qualquer ponto do desnvolvimento - revisão - Codificação - teste Incidentes podem ser levantados contra produto do ciclo de vida: - Documento de requisito - Especificação - Código fonte - Material de teste - Helps e manuais de usuario
2. Beneficio
3. Relatório de Incidente
4. Dicas para reportar incidentes

   Anmerkungen:

   • Uma boa pratica e associar cada defeito ao seu caso de teste.
5. Macro Fluxo

   Anmerkungen:

   • Slide 76
6. Atributos dos Defeitos (Taxonomia)

   Anmerkungen:

   • Taxnomia é a forma como classificamos os defeitos,, melhor sera a gestão dos defeitos, pois as metricas coletadas terão informações mais precisas sobre a origem do problema, ocasionando uma eficaz melhoria do processo.
7. Ciclo de Vida dos Incidentes

Anmerkungen:

• As ferramentas são classificadas de acordo  com as atividades de teste que elas suporrtam: - Gerenciamento do teste - Teste estático - Execução do teste - Outras

1. Ferramentas

   Anmerkungen:

   • Podemos classificar as ferramentas de teste em sete tipos: 1 Ferramentas para gerenciamento do teste 2 Ferramentas para testes estáticos 3 Ferramentas de suporte para especificação de teste 4 Ferramenta de suporte para execução e registro 5 - Ferramenta de performance e monitoração 6 Ferramenta de suporte para áreas de aplicação específicas 7 Ferramenta de suporte utilizando outras ferramentas
   1. Gerenciamento do teste

      Anmerkungen:

      • - Permitem rastreabilidade - Fornecem Suporte e registros e logs sobre o andamento do teste - Fornecem relatórios de análises - Ferramentas diferem em sua facilidade de uso, precisão das informações e portabilidade dos resultados para a distribuição. - Ferramentas podem ter diferentes integrações que auxiliam na restreabilidade, automatização etc...
   2. Gerencimento de Incidentes

      Anmerkungen:

      • Cobrem todas as atividades que imos sobre o gerenciamento de incidentes.  Conhecidos tambem como ferramentas de bug tracking. Permite o momitoramento dos busgs encontrados e seus respectivos status.
   3. Gerenciamento de configuração

      Anmerkungen:

      • Garantem a integridade dos softwares e do testware. - Armazenam informações sobre as versões do testware e builds do software. Exemplos de ferramentas: Subversion CVS
   4. Ferramentas para testes estáticos

      Anmerkungen:

      • - Armazenam as informações sobre o processo de revisão - Amrazenam e comunicam os comentarios de revisão - Fornecem relatórios sobre defeitos e esforço. Exemplos de ferramentas: Crystal Flawfinder Yasca
   5. Execução e registro de Teste

      Anmerkungen:

      • Permitemque testes sejam executados automaticamente, quantas vezes forem necessarias, checando se o teste passou ou falhou. Basicamente é possivel autoatizar os teste de duas formas: - Por meio da captura e replay das telas A automação por meio da captura e replay das telas armazenam todos os elementos da tela, todas as informações inderidas no sistema e todas as ações realizadas. Há limitações pois funciona como um filme e não possibilita derivar em varios testes. - Por meio de scripts. A automação por scripts tem vantagens pois e possivel programar para que um mesmo script execute dois testes diferentes, a medida que é possivel trocar os dados de entrada e resultados esperados. Isso elimina bastante trabalho para gravar o teste.
      1. Oráculo de teste

         Anmerkungen:

         • Durante o exame de certificação pode aparecer o termo "oráculo de teste". Esse é o mome dado para a fonte de dados onde o script automatizado buscará quais são os valores de entradda e o resultado esperado. Exemplo de ferramentas são Testcoimplete e IBM Rational
      2. Teste Unitário

         Anmerkungen:

         • Permitem a criação de drives ou stubs que simulam partes ainda não desenvolvidas do sftware, interagindo com a parte já pronta do sistema. Exemplos de ferramentas:  Junit Nunit Punit
      3. Medição de cobertura

         Anmerkungen:

         • São usadas primordialmente por desenvolvedores. - permite medir quanto do software sob teste foi executado por um conjunto de testes. O grande benefício detes tipo de ferramenta é mostrar de forma objetiva quanto do software foi exercitado por um conjunto.  O conceito foi explicado no modulo 4
      4. Segurança

         Anmerkungen:

         • ferramentas que simulam ataques contra o software em teste.
      5. Comparação de Teste
   6. Especificação de Teste
      1. Modelagem de teste

         Anmerkungen:

         • Podem gerar automaticamente casos de teste com base em dados de entrada padronizado. São mais dificeis de serem implementados. Exemplos de ferramentas: Allpairs teste case generation TestComposer AGEDIS
      2. Preparação de dados
   7. Performance e Monitoração

      Anmerkungen:

      • S'ao ferramentas de analise dinamica, estas ferramentas localiza defeitos que s'ao visiveis apenas quando o software está realmente sendo executado. São ferramentas geralmente utilizadas por programadores. Outras ferramentas são testes de performance, estresse e carga: - Gerador de carga, são script predeterminado que simula um numeor de usuarios acessando o sistema. - Componente de medição e análise, Enquanto o conjunto de scripts é executado, o componente realização medição coletando diversas métricas tais como: Numero de usuarios simulados, numeor e tipode operações geradas pelos usuarios simulados, tempos de resposta aos pedidos de determinada operação, etc...  Estes é um teste complicado, pois vc precisa saber o hardware, banda larga etc... que podem influenciar nos resultados. Ferramentas de Monitoração sao utilizadas para acompanhar o status do software em andamento.
   8. Suporte para outras áreas especificas

      Anmerkungen:

      • Normalmente as ferramentas são especializadas para um tarefa especifica, para um ambiente especifico ou para uma aplicação especifica. Muitas outras ferramentas são usadas para apoiar as atividades de teste. Word, excel etc...
   9. Outras Ferramentas

Anmerkungen:

• Benefícios: - Redução de atividades repetitivas - Maior consistência e repetibilidades - A avaliação objetiva (principalemnte a cobertura, desempenho, etc...) - Comunicação simplificada - Os testes autoatizados podem ser executados fora do horario Riscos: - Expectativas não realistas - Subestimar tempo, custo e esforço de desenvolvimento, execução e manutenção - uso da ferramenta para testes inadequados - Subestimar quando esforço é necessario para ganhar experi~encia para que os beneficios possam ser alcançados. - Subestimar o esforço necessario para manter os ativos (Scripts automatizados podem precisar de atualizações a cada mudança nos dados ou interface do usuario)

1. Ferramentas

   Anmerkungen:

   • A duas formas de automatizar os testes: Uma é por meio da captura e replay das telas e a outra é por meio de scripts. Manutenção dos testes gravados é muito despendiosa. Testes por Scripts: Deve existir um programador que entenda a linguagem utilizada para desenvolver os scripts e se for feito por que não seja especialista na linguagem e ferramenta  pode se tornar dificultoso. Por isso, não é facil automatizar pois somente os melhores casos de teste devem ser automatizados, e para isso um processo de teste deve estar bem maduro na organização.
   1. Performance

      Anmerkungen:

      • O teste funcional tenta identificar defeitos funcionais no software. Ja o teste de performance nao valida as funcionalidades, mas os requisitos não funcionais. desta forma, o teste de performance se preocupa com questões de desempenho do sistema, se a rotina esta sendo executada em determinado tempo etc...
2. Esforço

   Anmerkungen:

   • A equipe deve investir fortemente no desenvolvimento de casos de teste automatizados com o objetivo de colhes os frutos na execução do teste repetitivo, de baixa manutenção e automatizadoao longo dos meses e anos. Normalmente entre 2 e 10 vezes o esforço de teste manual.
3. Implantando Ferramenta de testes