teste de software i - principais conceitos_v02

Curso de Teste de Software

Teste de Software I – Principais Conceitos

1

Mônica C. Vaz

Trabalho Atual

Analista de Qualidade (Processo de Quality Assurance, Test Management, Treinamento e Consultoria em Casos de testes);

Formação

UEPG – Análise de Sistemas em 1996;

UEPG – Pós Graduação em Ciências da Computação em 1998;

Certificação

Six Sigma – Green Belt;

CBTS – Certificação Brasileira de Teste de Software em 2008;

2

Participantes...

1. Nome

2. Atividade atual

3. Experiência com Testes

4. Expectativa com o Curso

3

• Introdução aos conceitos de teste de

software – alinhamento da equipe;

• Entender os ganhos de um processo

documentado de testes;

• Identificar melhorias no processo atual;

Objetivo do treinamento

4

•Equipe estressada; •Atraso no projeto; •Perda de oportunidade; •Descrédito da equipe de qualidade; •Retrabalho; •Aumento do custo do projeto; •Frustração de expectativas;

Um processo imposto...

5

AGEND

A

1º dia

Planejamento de Testes - Conceitos básicos de teste ; Tipos de testes; Ciclo

de vida de testes ; Papéis e responsabilidades;

Casos de Testes – Conceitos de Requisitos de testes, Cenários de testes,

Casos de testes; Análise de risco dos testes x Prioridade; Técnicas de cobertura

de testes;

2º dia

Gestão de Testes - Estimativa de esforço; Custo do defeito; Testes de

Verificação x Validação; Log de execução; Report e Fluxo de defeitos;

Sumário final de testes – Lições Aprendidas e Recomendações; Métricas de

Testes;

Agenda

6

Conceitos para o Planejamento

de testes

7

O que é Teste de Software?

“Avaliar se o software está fazendo o que deveria fazer, de acordo com os seus requisitos, e não

está fazendo o que não deveria fazer”;

– Garantir que o produto funciona; – Garantir que o produto atende aos requisitos; – Garantir que o produto funciona, atende aos requisitos e não tem defeitos;

8

Qualidade no PMBOK – áreas de conhecimento

Entregar um resultado de acordo com o escopo, no prazo, no custo definido,

com qualidade

O que / Quando / Quanto /

Como

9

Dimensões da qualidade

Confiança: O sistema é resistente a falhas durante a execução, isto é, não entra em “loop”, não interrompe a execução por falta de recursos, etc.

Funcionalidade: O sistema se comporta conforme esperado e definido nos seus requisitos.

Performance: O sistema tem um tempo de resposta adequado e aceitável mesmo quando submetido a um volume alto de processamento

10

Dimensões de Qualidade

3. Tipos de Testes

(O que testar)

1. Técnicas de Testes

(Como testar)

2. Níveis de Testes

(Quando testar)

11

1. Técnicas de Teste: COMO TESTAR?

Caixa BRANCA Estrutural

• Caixa PRETA Funcional Determinar se os requisitos foram atendidos;

Verifica apenas os resultados produzidos e não requer conhecimento interno

do sistema, apenas conhecimento dos requisitos do negócio;

Realizado pelos testadores;

Determinar defeitos na estrutura interna ou no código;

São realizados pelos programadores;

1. Técnicas de Testes

(Como testar)

12

2. Níveis de Teste: QUANDO TESTAR?

Teste de Aceite (UAT)

Teste de Sistema

Teste de Integração

Teste Unitário

Os níveis de teste definem o momento do ciclo de vida do software em que são realizados os testes.

2. Níveis de Testes

(Quando testar)

13

Teste Unitário

Objetivos:

• Testar os componentes individuais (ex: classes, métodos, ...) certificando-se de que as entradas e saídas são válidas;

• Reduzir o custo dos defeitos encontrados;

Execução:

• São executados pelos desenvolvedores, durante o processo de construção, no ambiente de desenvolvimento

14

Objetivos:

É executado para garantir que as unidades ou aplicações que

foram testadas funcionem corretamente quando integrados.

Execução:

• São executados pelos desenvolvedores, durante o

processo de construção, no ambiente de

desenvolvimento;

Teste Integrado

15

Objetivos:

• Demonstrar que o sistema executa de modo funcional e operacional as funções especificadas

• Verificar a Integração dos componentes de software com o ambiente operacional similar ao de produção (hardware, software, processo, pessoas);

Execução:

Executados pelos testadores em Ambiente de testes.

Teste de Sistema

16

Teste de Aceite (UAT)

Objetivo:

• Verificar se a solução atende aos objetivos do negócio e a seus requisitos, no que diz respeito à funcionalidade e usabilidade.

Execução: • Os testes de aceite são executados pelos usuários e podem

ser de duas categorias: Teste alfa: geralmente nas instalações da equipe de

desenvolvimento e testes; Teste beta: feito pelo usuário, geralmente em suas instalações,

sem a supervisão da equipe de teste;

17

Focam aspectos diferentes de um software;

Dependendo da técnica e do nível de teste, selecionamos os tipos adequados.

3. Tipos de Teste: O QUE TESTAR?

3. Tipos de Testes

(O que testar)

18

Teste Funcional

• Verifica todas as funcionalidades do sistema em termos

de regras de negócio, incluindo entrada de dados,

processamento e resposta.

• Verifica o funcionamento das condições válidas e

inválidas.

• É baseado nas técnicas de caixa-preta, isto é,

verificar o sistema e seu processo interno pela

sua interação através da análise dos resultados.

19

Teste de Regressão

Re-execução de teste feitos após uma

manutenção corretiva ou evolutiva.

Tem como propósito garantir que qualquer falha tenha

sido reparada e que nenhuma operação que funcionava

anteriormente tenha falhado após os reparos, ou seja, que

as novas características adicionadas não criaram

problemas com as versões anteriores ou com outros

sistemas.

20

Teste de Segurança

Segurança: é um processo necessário para garantir a confidencialidade das informações e a proteção dos dados contra o acesso indivíduo de terceiros.

Segurança em nível de aplicação, incluindo acesso aos dados ou às funções do negócio;

Segurança em nível de sistema, incluindo o acesso ao sistema feito localmente ou remotamente

21

Teste de Volume

Verifica se o sistema suporta altos volumes de dados numa única transação

O teste de volume submete grandes quantidades de dados ao sistema para determinar se limites que causam a falha do software são alcançados.

Este tipo de teste também identifica o volume máximo persistente que o sistema pode suportar por um dado período.

22

Teste de Usabilidade

Testa a forma de uso do software, verificando a facilidade

que o software possui de ser claramente entendido e

facilmente operado pelos usuários.

Verifica:

A facilidade de operação do sistema pelo usuário;

A facilidade de entendimento das funções do sistema pelo

usuário, através da utilização de manuais, help on-line,

agentes e assistentes eletrônicos, etc.

23

Teste de Stress

Tipo de teste de confiabilidade destinado a avaliar como o sistema responde

em condições anormais.

Verificar se o sistema funciona corretamente e sem erros sob as seguintes

condições de estresse:

- Pouca ou nenhuma memória disponível no servidor (RAM e HD).

- Número máximo real, ou fisicamente suportado, de clientes conectados ou simulado.

- Múltiplos usuários realizando as mesmas transações contra os mesmos dados ou

contas.

24

Teste de Desempenho

O teste de desempenho mede e avalia o tempo de resposta, o número de transações e outros requisitos sensíveis ao tempo.

Verificar comportamento do sistema para funções de transações ou de negócio designadas sob as seguintes condições:

◦ Carga normal de trabalho

◦ Carga limite de trabalho.

25

Teste de Instalação

Garantir que o software possa ser instalado

(completamente, de forma personalizada ou atualizado)

sob condições apropriadas;

Verificar que, uma vez instalado, o software funciona

corretamente.

26

Verifica a resistência a falhas e a compatibilidade técnica em relação a linguagem, sintaxe, banco de dados (novos e legado)

Teste de Integridade

Resumo – Dimensões de Qualidade

28

Tipos de Testes

(O que testar)

Técnicas de Testes

(Como testar)

Níveis de Testes

(Quando testar)

•Caixa Branca

•Caixa Preta

•Unitário

•Integração

•Sistema

•Aceitação

•Funcional

•Regressão

•Segurança

•Volume

•Usabilidade

•Stress

•Desempenho

•Instalação

•Integridade

Exercício 1

Identifique os tipos de testes para atender aos requisitos do sistema „Venda de Livros pela Internet‟ Tempo: 20 minutos Equipe: Duplas

29

Ciclo de Vida do Processo

de Teste

31

TESTE

= EXECUÇÃO

Teste ??

Executar Testes

Quando as pessoas pensam

em teste, normalmente a

primeira coisa que vem a

mente é a sua execução

A Execução dos Teste é uma das etapas do Processo!

32

Fonte: Teste de software, de Emerson Rios e Trayahú Moreira (Rio de Janeiro, Alta Books, 2003)

2 Planejamento

3 Preparação

1Procedimentos

Inicias

4 Especificação

5 Execução

6 Entrega

Modelo 3P x 3E

33

Planejamento: Plano de Testes

Ambiente e Ferramentas

Contratação

Especificação:

Casos de Testes

Execução:

Relatório de Log

e Relatório de

Incidentes

Entrega: Relatório

Sumário

Documentos - Processo de Teste

34

Padrão IEEE 829

Norma mundial que trata da

documentação de cada etapa do processo

de teste de software.

• Tem por objetivo descrever os documentos necessários para apoiar a

atividade de teste de software.

• Os documentos descritos neste padrão abrangem o planejamento,

especificação e a geração de relatórios de testes;

35

Define quais as técnicas e tipos de testes que serão

aplicados em cada nível de teste.

Análise dos riscos do projeto de testes, traçando a estratégia

para atender aos objetivos e critérios de aceitação dos testes.

Define o escopo do teste bem como o cronograma.

Define dos responsáveis pelas atividades.

Critérios de aceitação dos testes

Métricas que serão coletadas

Necessidades de ambiente de testes

1. Plano de Teste

36

Principais Informações: Identificação do Plano de Teste Introdução Itens de Testes Funcionalidades a serem testadas Funcionalidades que não devem ser testadas Abordagem dos testes Critérios de conclusão dos testes Critérios para interrupção e retomada dos testes; Entregas Ambiente de teste Responsabilidades Pessoal (equipe, treinamento, local etc.) Cronograma Riscos do processo de teste (mitigação e contingência) Aprovação

37

1. Plano de Teste - template

Especificar os caminhos para testar o software;

2. Caso de Testes

Diz a lenda que um certo dia um testador foi até o programador

mestre e disse:

“Todos os meus testes sempre passam. Não mereço um

aumento?”

Então o mestre respondeu: “Se todos os seus testes passam,

sempre que são executados, você precisa escrever testes

melhores...”

38

Principais informações:

Pré-condições de execução

Prioridade do teste

Entradas de usuário / dados do teste

Ações do usuário / sistema

Resultados esperados para um objetivo específico

2. Caso de Testes - Template

39

3. Relatório de Log

Objetivo: fornecer um registro cronológico das

ocorrências de todo o processo de execução dos

testes.

Principais informações: quem executou, quando

executou, resultado obtido com a execução;

40

4. Relatório de Incidentes

Objetivo: documentar qualquer evento ocorrido durante a

execução dos testes que requeira algum tipo de

investigação ou correção.

Principais informações:

Descrição do incidente, data de abertura, responsável,

status, severidade, prioridade, causa do defeito...

41

5. Relatório Sumário de Teste

Objetivo:

Avaliar os resultados e atividades de teste e comparar

com cronograma previsto.

Principais Informações:

Variações ocorridas (prazo, esforço), Sumário do resultado

(qtde casos de testes testados, qtde incidentes, ocorrências

não resolvidas, ...), Métricas, Lições aprendidas.

42

Equipe de Testes - Formação

43

Matriz de Responsabilidades

Etapas Atividades LT AT AN TE

Planejamento Elaborar Estratégia de Teste E P

Elaborar Plano de Teste E P

Preparação Disponibilizar infra-estrutura e ferramentas A E P

Disponibilizar Pessoal E P

Especificação/

Execução

Elaborar Casos de Teste e Script de Teste A P E

Executar os Testes E

Acompanhar o andamento dos testes E

Entrega Avaliar e arquivar a documentação de teste A E P

Responsabilidades

E Execução das atividades

P Participa na execução (co-responsável)

A Acompanha / é informado dos resultados

Equipe de Testes - Responsabilidades

44

Discussão em grupo...

Por que é importante ter um processo de testes

documentado?

46

•Controle do que está sendo testados

•Sabe-se o quanto foi testado.

•Reduz a duplicação de esforço depois ter uma base de

documentação já criada (reaproveitamento)

•Não se deixa perder o conhecimento adquirido durante o

processo de testes

•Torna-se mais fácil a manutenção do software.

•Facilita o acompanhamento e a gerencia do teste

•É um meio eficaz de comunicação na equipe de teste.

•Fornece aos clientes evidência da qualidade do software

•Diminui a dependência entre membros da equipe de teste.

Por que é importante ter um processo de testes

documentado?

47

Dificuldades para ter uma documentação de testes

Discussão em grupo...

48

Dificuldades para ter uma documentação de testes

•Resistência à elaboração de documentos faz parte da

cultura de profissões técnicas;

•Nem sempre a informação necessária ao planejamento e

projeto do teste está facilmente disponível;

•Desconhecimento de padrões de documentação pelos

testadores;

•Normalmente, as ferramentas que auxiliam o processo de

documentação do teste são caras e complexas;

•Falta de consciência da importância da documentação.

•Falta de planejamento de esforço para documentação dos

processos de testes;

49

Conceitos para a Preparação dos

Casos de testes

50

O que é um Caso de Teste?

É uma situação diferenciada e única de comportamento no sistema, com o objetivo de identificar um defeito não previsto em todo o

ciclo de desenvolvimento.

51

Padrão de Qualidade do Caso de Teste

Efetivo: Testar o que se planejou testar

Econômico: Sem passos desnecessários

Reutilizável: Possa ser repetido

Rastreável: Possa identificar o requisito a ser testado

Autoexplicativo: Possa ser testado por qualquer pessoa

52

Derivação do Caso de Teste

Os casos de testes são derivados de uma

especificação formal que define os requisitos.

Requerimentos Casos de Uso Casos de Testes

53

Exemplo Exemplo de um Caso de Teste

Caso de Teste Objetivo 002_01_IncluirCliente Verificar o cadastro de cliente com sucesso.

Pré Condição: 1. Executar o caso de teste 001_01_ListagemComDados

Procedimentos:

Passo Ação Resultado Esperado

1 Clicar no botão "Incluir" É exibida a tela "Incluir/Alterar Cliente

001-02" com os campos Nome, Endereço,

Bairro, Estado, Cidade, Cep e Telefone e

botões "Salvar" e "Fechar"

2 Informar os campos obrigatórios > Clicar no

botão "Salvar"

O sistema limpa os campos da tela e

emite a mensagem "Cadastro efetuado

com sucesso." no topo da tela

"Incluir/Alterar Cliente 001-02".

Pós Condição: Cliente cadastrado com sucesso na base de dados.

54

... antes de elaborar casos de testes

• Definição de cenários de testes

•Organiza as idéias do que deve ser testado;

•Avalia a cobertura dos testes antes do esforço

da preparação;

•Revisa os requisitos de testes;

55

Exemplo

Cenário 1: Pesquisa válida de livro

Caso de Testes 1: Pesquisa por título

Caso de Testes 2: Pesquisa por autor

existente

Caso de Testes 3: Pesquisa todos os livros

Caso de Testes 4: Pesquisa livros

inexistentes

Cenário 2: Pesquisa inválida de

livro

Caso de Testes 1: Campo obrigatório

em branco

Caso de Testes 2: Pesquisa autor

inválido

Requisito 1: Pesquisar livro

Cada caso de testes terá um conjunto de passos ou procedimentos para a realização

da pesquisa. Exemplo:

- Informar o título válido

- Clicar no botão „Pesquisar‟

- Sistema retorna a lista de livros para o título pesquisado

- Clicar em „Fechar‟ 56

Técnicas de Testes O que é uma técnica de teste?

• Padrões que auxiliam na identificação dos

cenários de testes de acordo com o requisito a

ser testado.

57

No mínimo quantos casos de

testes podem ser levantados para

a tela abaixo?

Título:

Autor:

Pesquisar Voltar

Tela Pesquisar obra

58

Resposta Título Autor Resultado

V V Pesquisa OK

V - Pesquisa OK

- V Pesquisa OK

- - Msg erro

V I Msg erro

I V Msg erro

I - Msg erro

- I Msg erro

I I Msg erro

Fazendo este exercício, implicitamente você está utilizando

uma técnica de testes.

Técnicas de testes funcionais

1. Equivalência de Classe

2. Valor Limite

3. Tabela de Decisão

Técnicas de testes funcionais 1. Equivalência de Classe

Regra:

Menor ou igual a 16 anos não contrata funcionário

Maior que 16 a 18 anos contrata em tempo parcial

Maior que 18 a 55 anos contrata em tempo integral

Maior que 55 anos não contrata

0 16 18 55

5 17 30 60

1. Resultado - Equivalência de Classe

Técnica para redução da quantidade de casos de testes, que pode ser utilizada de

forma intuitiva.

No mínimo 4 casos de testes para comprovar que a regra de negócio está sendo

atendida;

Caso de testes Idade entrada Resultado

CT1 5 Não contrata

CT2 17 Contrata tempo parcial

CT3 30 Contrata tempo integral

CT4 60 Não contrata

2. Valor Limite

Regra:

Menor ou igual a 16 anos não contrata funcionário

Maior que 16 a 18 anos contrata em tempo parcial

Maior que 18 a 55 anos contrata em tempo integral


0 16 18 55

-1, 0, 1 15, 16, 17 17, 18, 19 54, 55, 56 98, 99, 100

99

2. Resultado – Valor Limite

Caso de testes Idade entrada Resultado

CT1 -1 Idade inválida

CT2 0 Não contrata

CT3 1 Não contrata











CT14 100 Idade inválida

3. Tabela de Decisão

Regra mais complexa:

Menor ou igual a 16 anos não contrata

Maior que 16 a 18 anos e solteiro tempo parcial

Maior que 16 a 18 anos e casado tempo integral

Maior que 18 a 55 anos e solteiro tempo parcial

Maior que 18 a 55 anos e casado tempo integral


3. Resultado - Tabela de Decisão

Regra1 Regra2 Regra3 Regra4 Regra5 Regra6

Condição

Idade 15 17 17 30 30 60

Estado Civil Solteiro Solteiro Casado Solteiro Casado Solteiro

Ação

Contratação Não Parcial Integral Parcial Integral Não

Pode-se utilizar a tabela de decisão com a técnica „Valores Limites‟ para

aumentar a quantidade de valores testados.

Exercício 2

Utilizando as técnicas de testes „Valores Limites‟, levante a quantidade de casos de testes necessários para atender à regra do negócio

Tempo: 20 minutos

Equipe: duplas

67

Exercício 2 - Regra

"... o cálculo do desconto por dependente é feito da

seguinte forma: a entrada é a idade do dependente

que deve estar restrita ao intervalo [0; 24]. Para

dependentes até 12 anos o desconto é de 15%.

Entre 13 e 18 o desconto é de 12%. Dos 19 aos 21

o desconto é de 5% e dos 22 aos 24 de 3%. O

sistema deve aceitar uma idade máxima válida de

99 anos".

...

68

• Definir prioridade para os casos de testes:

Orientações para elaboração dos casos de

testes

69

- Direciona a execução dos

casos de testes;

- Apoia o gerente de testes e

gerente de projeto na tomada

de decisão (mudança de

escopo, prazo) e implantação;

Para que serve

• Não misture diferentes ações em um mesmo passo, nem utilize as

conjunções “se” ou “ou”. Cada passo deve conter uma entrada/ tarefa

clara para o testador.

• O nome do caso de testes deve corresponder exatamente à situação

que está sendo testada; Cada caso de testes deve testar somente uma

transação do início ao fim. Nova transação requer novo caso de teste;

• Devem ser elaborados pelo menos 1 caso de testes para o „Fluxo

Principal‟, para cada „Fluxo Alternativo‟ . Exceções e Regras devem ser

combinadas de acordo com cada cenário de testes;

• Devem ser testados os limites das funcionalidades;

70

Orientações para elaboração dos casos de

testes - continuação

BOAS PRÁTICAS:

• Crie Checklists com as principais regras e

referências para criação dos casos de testes;

• Utilize testes padrões para serem aplicados pela

equipe de desenvolvimento;

71

Desafios da Elaboração dos Casos de

Testes

Uma abordagem que não avalie o software de forma adequada e efetiva;

Uma abordagem totalmente negativa ou destrutiva – talvez nunca seja considerado aceitável;

Evitar dois extremos potenciais:

72

Estimativa de Esforço

74

Como pode ser estimado esforço:

Ferramenta Use Case Point (UCP) - planejamento do esforço com base na

quantidade e complexidade dos requisitos;

Entrada de dados:

Quantidade de Use Cases;

Quantidade de fluxo principal + alternativos;

Exemplo de planilha para cálculo de esforço de testes (link)

75

../Usar/Estimativas de testes.xls

Gestão de Testes e Defeitos

76

Quando o custo da correção dos defeitos for maior do que

o custo da ocorrência do defeito...

Custo da Qualidade

77

Quando os testes devem parar?

Quanto custa um defeito?

• A regra 10 de Myers indica que o custo da correção de um defeito tende a ser cada vez maior quanto mais tarde ele for descoberto.

78

Verificação: realizar inspeções/revisões sobre os produtos

gerados pelas diversas etapas do processo de teste.

• Revisão de Requisitos

• Revisão do Projeto (Design)

• Inspeção de Código

Verificação

Verificação x Validação

Validação: avaliar se o sistema atende aos requisitos do

projeto (usuário)

• Testes

79

Processo de avaliação da qualidade dos artefatos produzidos durante o

ciclo de desenvolvimento visando a redução de custos, antecipando os

desvios e rastreando a qualidade dos artefatos a medida que são

construídos.

4

DE:

PARA:

Teste de Verificação / Quality Assurance

Através de:

Checklists

Reuniões de revisão

Revisão em pares

80

Um processo de verificação:

Apoia a análise de ambiguidade e / ou descrições superficiais dos requisitos;

Ajuda a estabelecer processos;

Determina programas de medida para avaliar processos;

Identifica fraquezas em processos e os aperfeiçoa;

81

•O objetivo do projeto é construir um brinquedo que

cause emoção e possa ser usado por crianças

• Deverá ter subidas e descidas íngremes de forma que o

usuário sinta medo

• O veículo deve poder levar crianças e ter no mínimo 4

rodas

• O veículo deve rodar sobre trilhos em alta velocidade

• Deve ter um mecanismo de proteção para os Passageiros

Requisitos do cliente

82

Rampas Íngremes

Trilhos

Proteção

Utilizado por criança

4 rodas

Requisito atendido...

mas ..... O que óbvio para um não é necessariamente óbvio para o outro!

83

O que o usuário precisava...

84

Exemplos de Métricas

• % de defeitos detectados para cada fase de inspeção (Requisito, Análise

e Design, Construção, Teste);

• % de artefatos com defeitos;

• % de defeitos detectados por criticidade;

• Esforço médio para correção dos defeitos (Retrabalho);

• Ganho na antecipação da detecção dos defeitos;

85

Teste de Verificação / Quality Assurance

Progresso da Execução

86

87

Acompanhamento da execução

• Acompanhamento de cronograma por prioridade

de teste;

• Reports de acompanhamento para todos os

envolvidos (periodicidade pré definida);

• Controle dos casos de testes que estão

bloqueados por defeitos;

• Planejamento de ciclos de testes

Status execução por Projeto

10

12

5

20

15

2

16

2

5

1

5

1

14

10

20

55

21

0

0

5

10

15

20

25

Projeto / Release A Projeto / Release B Projeto / Release C Projeto / Release D

Passed

Failed

Blocked

No Run

Not Completed

Projeto A - Execução por risco

10

25

22

5

12

2 1

10

25

16

5 58

0

5

10

15

20

25

Passed Failed Blocked No Run Not

Completed

Alto

Médio

Baixo

88

Reports de execução - exemplo

89

Fluxo do Defeitos - exemplo

Acompanhamento de defeitos

Status dos defeitos por Prioridade

10

35

3

25

2 35

3

12

2

54

10 9

0

5

10

15

20

25

30

Open Assigned Pending

Retest

Failed

Retest

Closed

1-Critical

2-High

3-Medium

4-Low

Defeitos por Prioridade

Defeitos por Categoria

90

Reports de defeitos - exemplo

Projeto A - Defeitos por fase de teste

20

35

30

21

15

3

0

5

10

15

20

25

30

35

40

Closed Open Pending

Retest

Failed Retest

Unitário

Sistema

Aceitação

Defeitos por Fase de teste

91


Idade dos defeitos

92


Métricas de defeitos utilizando ferramentas

93


Sumário Final dos testes e Coleta

de Métricas

95

O que não pode ser medido, não pode ser melhorado!

96

97

Efetividade dos Testes

Mede a qualidade dos testes realizados antes do sistema ser implantado,

comparando a quantidade de defeitos encontrados na fase „Test‟ com relação

aos defeitos detectados em „Produção‟.

Densidade de Defeitos

Mede a qualidade do projeto de acordo com a quantidade de defeitos

encontrados na fase „Test‟ e „Produção‟, de acordo com o seu tamanho em

UCP.

98

Como Calcular

Efetividade dos Testes = A / (A+B)

Densidade de Defeitos = (A + B) / UCP

◦Considerar:

◦A = Defeitos encontrados nas atividades de testes

◦B = Defeitos encontrados em produção

Exemplo:

UCP = 300 (aproximadamente 20 Use Cases)

Total de Defeitos em Teste de Sistema = 100

Total de Defeitos em Teste de Aceitação = 45

Defeitos Produção = 2

TEI = (100 + 45) / (100 + 45 + 2) 98,6

DD = (100 + 45 + 2) / 300 0,49

Importante medir, analisar e estabelecer metas

Indicadores de qualidade – Efetividade de testes

88%

90%

94% 94%

80%

70%

75%

80%

85%

90%

95%

100%

Release 1 Release 2 Release 3 Release 4 Release 5

Efetividade dos testes - Releases 2010

99

0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

Release 1 Release 2 Release 3 Release 4 Release 5

Densidade de defeitos - Releases 2010

Série1

100

Indicadores de qualidade – Densidade de defeitos

101

Defeitos por categoria - 2008

965; 8%

7865; 68%

1206; 10%

1617; 14%


2351; 19%

6672; 54%

1794; 14%

1650; 13%


893; 12%

5059; 66%

913; 12%

794; 10%

Identifica onde está a maior causa dos defeitos.

Indicadores de qualidade – Defeitos por categoria

Grande quantidade de defeitos sendo detectados somente no final do projeto

Defects - Base 2010

566 645442 505

2469

3352

707

300

1300

2300

3300

Requirements Analysis Design UT/UIT SIT/ST UAT Post

Implementat ion

19% 6%

67%

8%

Identifica quando os erros estão sendo detectados.

102

Indicadores de qualidade – Fase do projeto

Voltando ao 'Relatório Sumário de Teste'

Gerado ao final do projeto:

• Variações ocorridas (prazo, esforço)

• Sumário do resultado (qtde casos de testes executados,

qtde incidentes encontrados x corrigidos)

• Métricas coletadas

• Lições aprendidas e recomendações para melhoria do

processo

103

Melhoria do processo...

Exemplos de Lições Aprendidas em Projetos (link)

104

../Usar/Lições Aprendidas.doc

Gradativo

Adequado

Apoio gerência sênior

Resumo

Processos

Pessoas

Ferramentas

Qualidade não é uma fase do ciclo de desenvolvimento de software...

É parte de todas as fases!

Bibliografia

Base de Conhecimento em Teste de Software - 2a.

Edição (Rios, Emerson; Cristalli, Ricardo; Moreira,

Trayahú & Bastos, Aderson. - S.Paulo, Martins Fontes,

2007)

• Testes de Software (Molinari, Leonardo. - S.Paulo,

Érica, 2003.)

• The Rational Unified Process - An Introduction

(Kruchten, Philippe. - Boston, Addison Wesley,

1999.)

• Testes Funcionais de Software (Molinari, Leonardo. –

Florianópolis, Visual Books, 2008)

107

Avaliação do Treinamento

Deixe sua opinião com relação ao conteúdo do

treinamento, pontos fortes e oportunidades de

melhoria…

108

Obrigada

Nome do professor

e-mail do professor Mônica C. S. Vaz

[email protected]

teste de software i - principais conceitos_v02

Documents