Faculdade de Tecnologia FATEC Centro Paula de Souza

Transcrição

1 Faculdade de Tecnologia FATEC Centro Paula de Souza Disciplina - Teste de Software 14 Gestão da Atividade de Teste Prof. Edson Saraiva de Almeida Maio/2017 Atividades de Teste 1-Definir a estrutura organizacional Estabelece como a equipe será organizada 2-Estratégia de teste Como os dados de teste devem ser selecionados? Como decidir se um programa P foi suficientemente testado? 3-Técnica de Estimativa Consultar os envolvidos que tenham experiências na tarefa a ser realizada. Analisar métricas de projetos análogos da organização ou da indústria. 4-Estratégia de automação Planejar a abordagem de programação e de organização dos scripts de teste 5-Comunicação da estratégia de teste - Plano de Teste 6-Monitoração de progresso e controle O processo de planejamento e o próprio plano servem como veículo de comunicação da estratégia de teste para os envolvidos no projeto o registro desta discussão é documentada no plano de teste. Relatórios são produzidos para comparar o status atual com o planejado. 2 1

2 Estrutura Organizacional Estabelece como a equipe será organizada A definição do processo de teste implica em formalizar uma equipe que será responsável pelo planejamento e a condução das atividades de teste na organização. Equipe independente A equipe de teste pode ser formada de membros internos do projeto mas não diretamente envolvidos na codificação ou membros externos. Equipe Colaborativa A qualidade é responsabilidade de toda a equipe Como estabelecer a melhor estrutura organizacional A decisão será determinada por considerações de custos, cronograma, níveis de maturidade da organização envolvida e da criticidade da aplicação.. 3 Estrutura Organizacional CIO Equipe diretamente subordinada a gerência de nível superior Equipe de Qualidade (teste) Gerencia de Projeto 1 Gerencia de Projeto 2 Gerencia de Projeto 3 Equipe de desenvolvimento de software Equipe de desenvolvimento de software Equipe de desenvolvimento de software 4 2

3 Estrutura Organizacional CIO Gerencia de Projeto 1 Gerencia de Projeto 2 Gerencia de Projeto 3 Equipe de desenvolvimento de software Equipe de desenvolvimento de software Equipe de desenvolvimento de software Equipe subordinada a gerência de projeto Equipe de Qualidade (teste) 5 Estrutura Organizacional CIO Gerencia de Projeto 1 Gerencia de Projeto 2 Gerencia de Projeto 3 Fabrica de Teste Equipe de desenvolvimento de software Equipe de desenvolvimento de software Equipe de desenvolvimento de software Equipe de teste terceirizada independente da equipe de desenvolvimento 6 3

4 Estrutura Organizacional - colaborativa Desenvolvedores, analistas de negócio e testadores realizam um trabalho colaborativo, todos tem responsabilidade sobre a qualidade do produto, cada equipe tem membros com perfil diferentes, em grandes organizações alguns especialistas podem ser compartilhados entre muitas equipes Programadores Analistas de negócios Testadores CRISPIN, Lisa; GREGORY, Janet. Agile testing: A practical guide for testers and agile teams. Pearson Education, Estrutura Organizacional - consequências Equipe independente diretamente subordinada a gerência de nível superior Muitas organizações resistem a oferecer independência organizacional a uma equipe com objetivo de avaliar a qualidade. Equipe independente de teste Isolamento da equipe de teste da equipe de desenvolvimento, ressentimentos e pressões por prazo podem sugerir que a equipe independente traz mais problemas do que benefícios. Quando subordinada a gerência de nível superior ou de projeto se um defeito não é detectado pela equipe de desenvolvimento a responsabilidade será atribuída a equipe independente de teste Equipe colaborativa Atitude positiva e mais colaborativa para as atividades de teste. A descoberta de falhas deve ser o objetivo de toda a equipe e não somente dos testadores 8 4

5 Atividades de Teste 1-Definir a estrutura organizacional Estabelece como a equipe será organizada 2-Estratégia de teste Como os dados de teste devem ser selecionados? Como decidir se um programa P foi suficientemente testado? 3-Técnica de Estimativa Consultar os envolvidos que tenham experiências na tarefa a ser realizada. Analisar métricas de projetos análogos da organização ou da indústria. 4-Estratégia de automação 5-Plano de Teste 6-Monitoração de progresso e controle Planejar a abordagem de programação e de organização dos scripts de teste O processo de planejamento e o próprio plano servem como veículo de comunicação da estratégia de teste para os envolvidos no projeto o registro desta discussão é documentada no plano de teste. Relatórios são produzidos para comparar o status atual com o planejado. 9 Estratégia de Teste Como os dados de teste devem ser selecionados? Envolve estabelecer alguma estratégia para redução do tamanho do domínio de entrada (técnica de caixa-branca/caixa-preta/erros). Priorização dos requisitos Como decidir se um programa p foi suficientemente testado Envolve estabelecer os critérios de aceitação para os testes de unidade, integração, sistema e aceitação de acordo com a análise de riscos para o projeto. 10 5

6 Estratégia de Teste exemplo para o teste unitário Como os dados de teste devem ser selecionados? Será utilizada a técnica de caixa branca critério todas as arestas Como decidir se um programa p foi suficientemente testado Será considerado concluído quando 100% dos métodos públicos que implementam as funcionalidades com prioridade alta obtiverem satisfatório. Critério de aceitação (conclusão) CA1 Será considerado concluído quando 100% dos métodos públicos que implementam as funcionalidades com prioridade alta obtiverem satisfatório para o critério todas as arestas. 11 Estratégia de Teste Priorizar os requisitos O esforço de teste é direcionado para os requisitos com maior prioridade. Evidencias - análise de cobertura Rastreabilidade (REQ x CT ) cobertura de requisitos. Rastreabilidade (REQ x scripts de teste) cobertura de código 12 6

7 Estratégia de Teste priorização dos requisitos Matriz de prioridades (potencial de exposição a falhas e análise do perfil operacional de uso) 13 Priorização dos Requisitos Tabela de classificação da prioridade Criticidade Alto Importante Moderado Baixo Descrição As funções selecionadas afetam itens críticos relacionados ao desempenho do sistema As funções selecionadas afetam partes importantes para o desempenho do sistema As funções selecionadas afetam o desempenho do sistema, mas estratégias de contorno podem ser implementadas para compensar as perdas pelo não atendimento. As funções selecionadas têm efeito observável no desempenho do sistema, mas somente criam inconvenientes para o usuário IEEE Std IEEE Standard for Software Verification and Validation,

8 Priorização dos Requisitos Requisito UC05-Liberação de Acesso UC01-Cadastra Usuário UC02-Consulta Usuário UC03-Altera Usuário UC04-Exclui Usuário UC06-Cadastra Perfil UC07-Consulta Perfil UC08-Exclui Perfil UC09-Altera Perfil Prioridade Alta Importante Importante Importante Importante Baixo Baixo Baixo Baixo Critério de aceitação 15 Estabelecer os critérios de aceitação para as fases de TU, TI e TS/TA Requisitos de usuário Preparação dos testes de aceitação Executa os Testes de Aceitação Requisitos de Sistema Preparação dos testes de sistema Executa o Teste de Sistema 1) Teste de CP classes de equivalência 2) 100% do FB dos UC considerados críticos obtiveram satisfatórios Projeto detalhado Preparação dos Testes de Integração Executa o Teste de Integração 1) Teste de CP CE e Teste de CB Todos Comandos 2)100% das interfaces que implementam o fluxo básico dos UC considerados críticos obtiveram satisfatórios Codificação Execução do Teste de Unidade 1) Teste de CB 2) 100% dos métodos públicos obtiveram satisfatórios CRAIG, Rick David; JASKIEL, Stefan P.; JASKIEL, Stefan P. Systematic software testing. Boston: Artech House,

9 Estratégia de Teste Exemplo de critérios de aceitação Sistema de controle de estacionamento requisitos de usuário Req1 O sistema deve permitir o cadastro de clientes da rede com as seguintes informações: CPF, nome, endereço, telefone de contato Req2 O sistema deve permitir o cadastro de veículos por cliente com as seguintes informações: placa, modelo, código do cliente (CPF), tamanho. Os veículos são classificados pelo tamanho em utilitário, médio e pequeno. Um cliente pode ter um ou mais veículos cadastrados no seu nome Req3 A rede de estacionamentos possui vários endereços, os clientes podem estacionar em qualquer um deles. O sistema deve permitir o cadastro de endereços do local de estacionamento com as seguintes informações: código do estacionamento, endereço, telefone Req4 Registrar a entrada - quando o cliente deixa o veículo para estacionar, o funcionário da recepção identifica o cliente pela placa e registra a data e hora de entrada do veículo e o endereço do estacionamento (local da estadia) prioridade alta. Req5 Registrar a saída - quando o cliente retornar para retirar o veiculo, o funcionário registra a data e hora da saída. O sistema acumula a demanda de uso independentemente do local de estadia utilizado - prioridade alta. Req6 - O pagamento é realizado mensalmente de acordo com a demanda de uso pelo cliente. Ao final do mês o cliente solicita o relatório relacionando as despesas com estacionamento para cobrança. Em seguida o funcionário emite um boleto de cobrança com data de vencimento para o dia 05 do mês seguinte. O cliente pode pagar em qualquer endereço da rede de estacionamentos. Ao efetivar o pagamento a estadia referente ao mês pago é atualizada como quitada. 17 Estratégia de Teste - Critérios de Aceitação Sistema de Controle de Estacionamento - critérios de aceitação por fase de teste Teste unitário: CA1 - será considerado concluído quando 100% dos casos de teste que verificam os métodos públicos que implementam as funcionalidades com prioridade alta (Req4 e Req5) obtiverem satisfatório, para o critério todas as arestas. CA2 - será considerado concluído quando 100% dos casos de teste que verificam os métodos publicos que implementam as funcionalidades com prioridade importante, moderada e baixa obtiverem satisfatório para o critério classes de equivalência, classes validas. Teste de integração: CA3 - será considerado concluído quando 100% dos métodos que implementam as chamadas entre os módulos (integração chamada das APIs) das funcionalidades classificadas com prioridade alta obtiverem satisfatório. (Req4 e Req5 ) para o critério classes de equivalência. CA4 será considerado concluído quando 100% dos casos de teste que verificam os métodos que implementam as chamadas entre os módulos (integração chamada das APIs) das funcionalidades classificadas com prioridade importante, moderada e baixa obtiverem satisfatórios para o critério classes de equivalência, classes validas. Teste de sistema: CA5 - será considerado concluído quando 100% dos casos de teste especificados para as funcionalidades classificadas com prioridade alta (Req4 e Req5) obtiverem satisfatórios para o critério teste funcional sistemático. CA6 será considerado concluído quando 100% dos casos de teste especificados para as funcionalidades com prioridade importante, moderado e baixo obtiverem satisfatório para o critério classes de equivalência, classes validas. 18 9

10 Como obter evidencias caixa preta Modelo de rastreabiliade UC05 Cadastrar veiculo de usuário do estacionamento F Rastreabilidade UC X CT CT01Req4_registrar_estadia_com_sucesso CT02Req4_registrar_estadia_com_ placa_nao_cadadastrada Árvore de cenários de casos de uso 19 Evidências - análise de cobertura Teste de sistema: será utilizada a técnica de caixa-preta critério teste funcional sistemático será considerado concluído quando 100% dos casos de teste especificados para as funcionalidades classificadas com prioridade alta (Req4 e Req5) obtiverem satisfatórios. CT01Req4RegistrarEstadia_com_sucesso CT02Req4RegistrarEstadia_com_sucesso CT03Req4RegistrarEstadia_com_placa_não_cadastrada CT04Req4RegistrarEstadia_com_placa_não_cadastrada CT05Req4RegistrarEstadia_com_placa_branco CT06Req4RegistrarEstadia_digitando_aspas_para_placa 20 10

11 Caixa-Preta especificação do CT ID Objetivo Pré-condição CT01Req4_registrar_estadia_com_sucesso Verificar o comportamento do sistema no registro de entrada de um veículo no estacionamento com sucesso Sistema no estado de espera para registrar entrada de um veículo, a placa YYY-3434 esta registrada no sistema Procedimentos 1-O atendente digita a placa YYY-3434 do cliente para registrar a data e o horário de entrada Resultados Esperados O sistema apresenta uma tela solicitando a confirmação dos dados do veículo 2 O atendente confirma a operação O sistema envia uma mensagem informando que o registro foi realizado com sucesso. IEEE Std 829 Software Test Documentation 21 Estratégia define os objetivos Teste de Unidade Diminuir a quantidade de defeitos nas próximas fases Teste de integração Garantir a integração de módulos desenvolvidos por equipes distribuídas ou pelo risco identificado para alguns módulos Teste de Sistema Minimizar o número de defeitos encontrados pelo cliente Considerando a prioridade dos requisitos Potencial de exposição a falhas e perfil operacional de uso

12 Estratégia define os objetivos Tipos de teste Critérios de aceitação Nível de automação Funcional, ciclo de negócio, stress, volume, desempenho, usabilidade, distribuição, regressão, etc. Cobertura de teste baseada em código (100% dos métodos públicos satisfatórios), cobertura de teste baseada em requisitos (100% dos requisitos considerados críticos satisfatórios), número de defeitos Estratégia de automação 23 Teste de Regressão Manutenção de Software Priorização Reteste total Análise de impacto: os casos de testes são selecionados considerando entidades modificadas no código tais como funções, variáveis, macros Randômica Manter um conjunto de casos de teste de regressão previamente analisados 24 12

13 Atividades de Teste 1-Definir a estrutura organizacional Estabelece como a equipe será organizada 2-Estratégia de teste Como os dados de teste devem ser selecionados? Como decidir se um programa P foi suficientemente testado? 3-Técnica de Estimativa Consultar os envolvidos que tenham experiências na tarefa a ser realizada. Analisar métricas de projetos análogos da organização ou da indústria. 4-Estratégia de automação Planejar a abordagem de programação e de organização dos scripts de teste 5-Comunicação da estratégia de teste - Plano de Teste 6-Monitoração de progresso e controle O processo de planejamento e o próprio plano servem como veículo de comunicação da estratégia de teste para os envolvidos no projeto o registro desta discussão é documentada no plano de teste. Relatórios são produzidos para comparar o status atual com o planejado. 25 Técnicas de Estimativa Fatores que afetam o esforço de teste Esforço para especificar Esforço para especificar, executar, quantidade de execuções, programação dos scripts Exemplo-30 minutos por caso de teste Esforço para executar Exemplo 3 minutos por caso de teste Quantidade de execuções Esforço de automação Exemplo - 3 execuções antes da liberação Esforço para programação dos scripts 26 13

14 Esforço para Especificar CT Quantidade de casos de teste F Priorizar CT: Testar somente o fluxo básico Testar o FB e alternativo críticos para o negócio Testar o FB e alternativos das funções mais utilizadas Árvore de cenários de casos de uso 27 Esforço para Especificar CT Requisitos de Usuário Sistema de controle de estacionamento Req1 O sistema deve permitir o cadastro de clientes da rede com as seguintes informações: CPF, nome, endereço, telefone de contato (CRUD 4 casos de uso). Req2 O sistema deve permitir o cadastro de veículos por cliente com as seguintes informações: placa, modelo, código do cliente (CPF), tamanho. Os veículos são classificados pelo tamanho em utilitário, médio e pequeno. Um cliente pode ter um ou mais veículos cadastrados no seu nome (CRUD 4 casos de uso). Req3 A rede de estacionamentos possui vários endereços, os clientes podem estacionar em qualquer um deles. O sistema deve permitir o cadastro de endereços do local de estacionamento com as seguintes informações: código do estacionamento, endereço, telefone (CRUD 4 casos de uso). Req4 Registrar entrada - quando o cliente deixa o veículo para estacionar, o funcionário da recepção identifica o cliente pela placa e registra a data e hora de entrada do veículo e o endereço do estacionamento (local da estadia) (1 Caso de Uso). Req5 Registrar saída - quando o cliente retornar para retirar o veiculo, o funcionário registra a data e hora da saída. O sistema acumula a demanda de uso independentemente do local de estadia utilizado (1 Caso de Uso). Req6 - O pagamento é realizado mensalmente de acordo com a demanda de uso pelo cliente. Ao final do mês o cliente solicita o relatório relacionando as despesas com estacionamento para cobrança. Em seguida o funcionário emite um boleto de cobrança com data de vencimento para o dia 05 do mês seguinte. O cliente pode pagar em qualquer endereço da rede de estacionamentos. Ao efetivar o pagamento a estadia referente ao mês pago é atualizada como quitada. (3 casos de uso) 28 14

15 Esforço para Especificar CT considerando os Requisitos de Sistema Sistema de Controle de Estacionamento Requisitos de Sistema - 17 Casos de Uso Supondo 1 caso de teste para o fluxo e básico e um caso de teste para o fluxo alternativo 34 casos de teste Supondo que cada caso de teste demore 30 minutos para ser especificado = 1020 minutos ou 17h Supondo que cada caso de teste demore 3 minutos para ser executado = 102 minutos ou (1.7) 2h 3 baterias de execução 2h x 3 = 6h Custo total 23h x R$ 30,00 = R$ 690,00 Considerando 1homem/hora = 2,8 = 3 dias 29 Esforço para Especificar CT considerando os Requisitos de Sistema Total de casos de uso 464, total de fluxos básicos e alternativos

16 Esforço para Especificar CT nível de detalhamento Abordagem O esforço exigido com a atividade de teste esta intimamente relacionado com a abordagem utilizada na Especificação dos Casos de Testes Nível de detalhamento O nível de detalhamento na elaboração da documentação dos casos de teste tem implicações com o nível de experiência do testador na execução do teste manual Automação de scripts Nível de experiência do programador na automatização dos scripts (teste automatizado). 31 Esforço para Especificar CT nível de detalhamento Conhecimento do negócio Claramente pessoas que conheçam muito bem o processo de negócio a ser testado podem receber uma documentação de teste menos detalhada Dependência Diminuir a dependência gerando uma documentação com detalhes suficientes, que permitam a execução da atividade independentemente das pessoas que irão executá-la. Terceirização Isto pode favorecer a terceirização em casos onde a organização não possua recursos suficientes para atender um aumento repentino do esforço de teste 32 16

17 Especificação do Caso de Teste - detalhado 33 Especificação do Caso de Teste - resumido 34 17

18 Atividades de Teste 1-Definir a estrutura organizacional Estabelece como a equipe será organizada 2-Estratégia de teste Como os dados de teste devem ser selecionados? Como decidir se um programa P foi suficientemente testado? 3-Técnica de Estimativa Consultar os envolvidos que tenham experiências na tarefa a ser realizada. Analisar métricas de projetos análogos da organização ou da indústria. 4-Estratégia de automação Planejar a abordagem de programação e de organização dos scripts de teste 5-Comunicação da estratégia de teste - Plano de Teste 6-Monitoração de progresso e controle O processo de planejamento e o próprio plano servem como veículo de comunicação da estratégia de teste para os envolvidos no projeto o registro desta discussão é documentada no plano de teste. Relatórios são produzidos para comparar o status atual com o planejado. 35 Estratégia de Automação de Teste Objetivo Teste unitário/integração no nível de API Reduzir o nível de manutenção dos scripts causados por mudanças no sistema de software sob teste Massa estática mantida pelo script de teste Teste de Sistema Massa estática mantida pelo script de teste Teste unitário/integração no nível de API Teste de Sistema Utilizando a técnica de programação dos scripts Data-driven ou Keyword-driven Utilizando a técnica de programação dos scripts Data-driven ou Keyword-driven 36 18

19 Organização dos Scripts de Teste Uma classe de teste por caso de uso quando existe um número significativo de métodos e existe o desejo de que a especificação de cada função do sistema sob teste fique /************************** /* teste na camada de serviço CT01FBCadastrarCliente_com_sucesso( ) /*************************** /* teste na camada de domínio 37 Organização dos Scripts de Teste Uma classe de teste por classe quando não existem muitos métodos a serem testados ou nas fases iniciais da programação dos scripts na medida que o número de scripts aumenta pode-se desejar um organização por inicialização ou CT01FBCadastrarCliente_com_sucesso(

20 Organização dos Scripts de Teste Uma classe de teste por inicialização quando um grupo de casos de teste necessitam de um padrão CT01FBCadastrarCliente_com_sucesso( 39 Estratégia de Automação de Teste Automação Deve ser iniciada o mais cedo quanto possível Esforço Deve ser considerado nas estimativas do desenvolvimento GUI Teste em camadas múltiplas diminui o esforço no teste de GUI 40 20

21 Estratégia de Automação de Teste Alocação do esforço de automação Testes Manuais GUI Teste de Aceitação No nível de API Teste de Unidade / Teste de Componentes 41 Atividades de Teste 1-Definir a estrutura organizacional Estabelece como a equipe será organizada 2-Estratégia de teste Como os dados de teste devem ser selecionados? Como decidir se um programa P foi suficientemente testado? 3-Técnica de Estimativa Consultar os envolvidos que tenham experiências na tarefa a ser realizada. Analisar métricas de projetos análogos da organização ou da indústria. 4-Estratégia de automação Planejar a abordagem de programação e de organização dos scripts de teste 5-Comunicação da estratégia de teste - Plano de Teste 6-Monitoração de progresso e controle O processo de planejamento e o próprio plano servem como veículo de comunicação da estratégia de teste para os envolvidos no projeto o registro desta discussão é documentada no plano de teste. Relatórios são produzidos para comparar o status atual com o planejado

22 Documentação IEEE Std 829 Formalização A documentação é parte integrante da formalização de um processo de teste Mecanismos de documentação Existem várias maneiras de se documentar a atividade de teste. IEEE Std 829 Software Test Documentation oferece uma descrição da documentação de teste e dos seus relacionamentos com o processo de teste. 43 Documentação - IEEE Std 829 Plano de Teste Documento descrevendo o escopo, abordagem, recursos e cronograma das atividades de teste, identifica os itens de teste, características que serão testadas, as tarefas, responsabilidades, riscos e plano de contingência, define grau de independência organizacional desejado. Especificação do projeto de teste documento especificando os detalhes da abordagem de teste para uma característica ou combinação de características identificando os testes associados. Especificação do caso de teste documento especificando entradas, resultados previstos, e um conjunto de condições para execução

23 Documentação - IEEE Std 829 Especificação de procedimentos de teste Um documento especificando a sequência de ações para execução do teste (setup do ambiente, reinicialização) Relatório de transmissão Relatório de liberação para teste. Log de teste Um registro cronológico dos detalhes relevantes sobre a execução do teste. 45 Documentação - IEEE Std 829 Relatório de incidente de teste um documento relatando qualquer evento ocorrido durante a atividade de teste que mereça investigação Relatório resumo de teste um documento resumindo as atividades de teste, os resultados, e uma avaliação. Documentação do projeto Dependendo do tamanho do projeto, ou da natureza das atividades de teste, nem todos estes documentos devem ser produzidos, para um pequeno projeto pode não ser necessários escrever um documento de projeto de teste

24 Documentação - Plano de Teste Escopo de teste Qual a abrangência do esforço de teste Objetivos de teste Quais são os objetivos do teste Riscos Para o projeto. Restrições Orçamento, limitações de prazos Testabilidade Quais aspectos são mais ou menos testáveis, priorização do esforço 47 Documentação - Plano de Teste Ambiente Preparação do ambiente de teste Cobertura Nível de cobertura alcançado Cronograma do projeto x teste Analise, projeto, codificação comparado com os vários marcos definidos para a atividade de teste Análise de custo Benefícios de continuar a execução de teste em termos da probabilidade de encontrar defeitos 48 24

25 Atividades de Teste 1-Definir a estrutura organizacional Equipe independente 2-Estratégia de teste Como os dados de teste devem ser selecionados? Como decidir se um programa P foi suficientemente testado? 3-Técnica de Estimativa Consultar os envolvidos que tenham experiências na tarefa a ser realizada. Analisar métricas de projetos análogos da organização ou da indústria. 4-Estratégia de automação Planejar a abordagem de programação e de organização dos scripts de teste 5-Comunicação da estratégia de teste - Plano de Teste 6-Monitoração de progresso e controle O processo de planejamento e o próprio plano servem como veículo de comunicação da estratégia de teste para os envolvidos no projeto o registro desta discussão é documentada no plano de teste. Relatórios são produzidos para comparar o status atual com o planejado. 49 Monitoração do Progresso Retorno Para equipe de teste do andamento das atividades Visibilidade Análise de cobertura Coletar dados Sobre os resultados dos testes Permitir a análise de cobertura funcional e de código Estimativas futuras 50 25

26 Monitoração do Progresso Total de casos de uso 464, total de fluxos básicos e alternativos Análise de cobertura evidencias da cobertura funcional Como decidir se um programa P foi suficientemente testado a decisão gerencial é estabelecida por uma análise de cobertura funcional 52 26

27 Análise de cobertura evidencias da cobertura de código Análise de cobertura de código 53 Monitoração do Progresso Taxa de defeitos 54 27

28 Monitoração do Progresso Analise de severidade 55 Monitoração do Progresso 56 28

29 Monitoração do Progresso 300 Progresso do Projeto Número de Produtos de Trabalho Concluídos realizado planejado 0 57 Monitoração do Progresso Relatório resumo de teste 58 29

30 Gerenciamento de Incidentes Deferred (adiado) - significa que o bug deve ser corrigido nas próximas versões. 59 Gerenciamento de Incidentes Breve descrição do defeito Severidade Coletar evidencias Verificar se o defeito é reproduzível Solicitar o parecer do desenvolvedor 60 30

31 Gerenciamento de Incidentes Descrição do defeito 61 Gerencia de Configuração Estagio de commit 62 31

32 Bibliografia DELAMARO, Márcio Eduardo; MALDONADO, José Carlos; JINO, Mário. Introdução ao teste de software GRAHAN, D., et.al. Foundations of Software Testing: ISTQB Certification, London: Thomson Learning, 2007 (cap 5) PRESSMAN, R.S., Engenharia de Software, 8ª.ed., São Paulo: McGrawHill, 2006 (cap 13) BECK, K., Test-Driven Development: by example, Addison-Wesley, 2003 CRISPIN, Lisa; GREGORY, Janet. Agile testing: A practical guide for testers and agile teams. Addison-Wesley Professional, JURISTO, N.; MORENO, A. M.; STRIGEL, W. Software Testing Practices in Industry. IEEE Software, vol. 23, nº 4, p , July/Aug., MESZAROS, G., xunit Test Patterns: Refactorin Test Code, Addison Wesley,