Clinica sobre conceitos básicos de teste de software

Transcrição

Clinica de Teste de
Software
Emerson Rios
[email protected]
1
Primeira Empresa Brasileira com certificação Nível 2
Bibliografia
2
3
4
5
Agenda do curso:
• Alongamento para a competição
• O que é teste
• O que é defeito
• Testando sem técnica
• O caso da caneta
• Terminologias e conceitos
• Projeto e processo de teste
• A visão da norma ISO/IEC 29119
• Como melhorar os seus testes?
• MPT – Melhoria de Processo de Teste
6
Alongamento para a competição
7
O que é Teste de Software?
8
Introdução
Exemplo de Requisito
• O campo salário deve ser sempre
maior do que R$1.000,00
Autores usados nesta definição
ISO – International Standard
Organization
Martin Pol
Emerson Rios/Trayahu Moreira
Glenford Myers
9
O que é
teste de
software
?
ISO/IEC
• Testar software é a atividade de comparar o que
um item de teste faz com o que é esperado que
faça (ISO/IEC-29119) (visão do requisito do
software)
10
O que é
teste de
software
?
Martin Pol
•
Em linhas gerais, podemos dizer que o objetivo dos testes é
encontrar defeitos: desta forma os testes são conduzidos para
demonstrar a ausência de qualidade expressa pela presença de
defeitos, para tal se faz necessário um processo (planejamento,
especificação, execução, análise de resultados), considerando-se
sempre os riscos do negócio e a qualidade do produto. (visão do
processo, projeto, requisito, risco do negócio e a qualidade para o
negócio)
Obs.: Foram condensadas as três definições existentes no livro
numa única definição.
Fonte: Software Testing – A Guide to the Tmap Approach – Martin
Pol e outros.
11
O que é
teste de
software
?
Rios & Moreira
• Verificar se o software é executado de forma
controlada e está fazendo o que deveria fazer, de
acordo com os seus requisitos, e não está
fazendo o que não deveria fazer. (visão do
requisito)
Observação: Foram condensadas as duas definições existentes no
livro em uma única definição.
Teste de Software – Emerson Rios e Trayahu
Moreira – Editora Altabooks – 2ª edição
12
O que é
teste de
software
?
O que diz o papa
(Glenford Myers)
• Teste de software é um processo, ou um grupo
de processos, definidos para garantir que um
código faz o que ele foi desenhado para fazer, e
não faz nada que não foi especificado para fazer.
(visão do projeto e do requisito)
The Art of Software Testing – Glenford Myers – 2ª
edição (primeiro livro publicado sobre teste de
software – 1979)
13
O que é
teste de
software
?
Conclusão
•
•
•
•
•
Considerando-se todas as definições dadas sobre
teste de software podemos concluir o seguinte:
Testamos para verificar se o software está fazendo o
que foi pedido que ele fizesse num requisito;
O teste deve ser considerado um projeto;
É importante termos um processo de teste;
Testamos para garantir que o negócio não vai correr
riscos provocados por defeitos em produção;
Testamos para assegurar a qualidade do software.
14
Ufa!
Agora eu
sei a
resposta
Processo de Teste
Planejar
Planejar
Testes
Testes
Requisitos
Projetar
Testes
Visões:
Requisito
Qualidade/Riscos
Projeto
Executar
Testes
Analisar
Resultados
Gerenciar
Defeitos
15
www.iteste.com.br
Eu estava triste e
deprimido. A minha
mulher tinha me
trocado por um
desenvolvedor. Agora
os meus filhos estavam
sendo criados por um
desenvolvedor. Nada
me animava e eu
estava a beira de uma
depressão. Só tinha
consolo no trabalho.
Então eu testava ....
Testava ... Testava..
Carlinhos, o testador
Então um dia uma coisa
maravilhosa me
aconteceu. Eu encontrei
um defeito, tão crítico,
tão severo, tão
importante para que o
negócio não corresse
risco, que os
desenvolvedores
tiveram que fazer horas
extras para corrigi-lo.
O negócio foi salvo, e
eu sai da minha
depressão.
16
A definição sobre o que é teste de software pode ser vista no filme
acessado pelo link abaixo:
O que é teste de software?
http://www.youtube.com/watch?v=w47wtSC7b7c&feature=youtu.be
Ver o artigo completo ou o link acima na área de download da iTeste
(www.iteste.com.br ) ou no blog do Emerson na Editora Altabooks
(http://blog.altabooks.com.br ).
17
O que é defeito?
18
História
O ENIAC (Electronic Numerical
Integrator and Computer),
primeiro computador digital
completamente eletrônico
(1947), também contribuiu ao
uso da palavra. Ele era movido
a válvulas e, assim, atraía
milhares de insetos. Como
dezenas a centenas de válvulas
queimavam a cada hora o
computador, que ocupava o
espaço de uma sala, era aberto
frequentemente e montes de
insetos mortos eram varridos
para fora. Diz-se que esses
insetos provocavam Curto
Circuitos nas placas do ENIAC
levando a falhas nos
programas.
Fonte: Wikipédia
19
Custo econômico
dos defeitos
Em 2002, um estudo financiado pelo NIST constatou que
erros de software custam anualmente US$ 59 bilhões à
economia dos Estados Unidos. O estudo também estimou que
mais de um terço desse valor, ou aproximadamente US$ 22,2
bilhões, poderia ser economizado caso fossem realizados
investimentos em uma melhor infraestrutura de testes.
NIST – National Institute of Standards and Technology
Fonte: Wikipédia
20
Muitas palavras para definir
apenas uma coisa?
•
•
•
•
•
•
•
•
•
Defeito
Falha
Problema
Incidente
Anomalia
Variância
Inconsistência
Bug
Erro
21
Muitas palavras para definir
apenas uma coisa?
•
•
•
•
•
•
•
•
•
Defeito
Falha
Problema
Incidente (norma ISO 29119)
Anomalia (IEEE 829)
Variância
Inconsistência
Bug (ver defeito)
Erro
22
Definição de defeito
Fonte da definição
Descrição de defeito
ISO/IEC 29119
Qualquer condição que causa um desvio de um
resultado baseado no que diz um requisito, um
documento de especificação, um documento do
usuário, um padrão, ou conforme a experiência ou
percepção do técnico, que requeira investigação.
Obs.: Defeitos podem ser encontrados em produtos de
software ou artefatos de software.
Martin Pol e outros
Defeito ou falha é o resultado de um erro residente
num código ou num documento.
Rios & Moreira
Defeito é uma diferença entre o resultado produzido e
o especificado, quando as especificações existem e
estão corretas.
Ron Patton
Um defeito ocorre quando o software não faz alguma
coisa que pela especificação do produto deveria fazer
Ou faz alguma coisa que a especificação diz para não
fazer.
Ou faz alguma coisa que a especificação não
menciona.
23
Explicação mais detalhada
Termo
Definição
Defeito
Já definido
Erro
Falha humana que provoca o
aparecimento de um defeito
Bug
Ver defeito
Incidente
A norma ISO diz que o testador
registra um incidente que
apenas virá defeito quando é
reconhecido como tal
Anomalia
Igual a incidente (definido pela
norma IEEE 829:2008)
24
Seqüência de eventos
Erro pode ser
cometido
pelo
desenvolved
or ou pelo
usuário
Erro
Incidente ou
anomalia
Defeito ou
Bug
25
Visão geral dos
processos de teste
Plano de
Teste
Projeto e
implementação
Requisitos
de
ambiente
Indicadores
Diretivas
Resultados
da execução
Especificações
de teste
Nenhuma
ocorrência
Execução
Ocorrência
ou
resultado
do re-teste
Montagem
do
ambiente
Relatório de
ambiente
implantado
Registro
de
incidentes
26
Visão geral dos
processos de teste
Plano de
Teste
Projeto e
implementação
Requisitos
de
ambiente
Indicadores
Diretivas
Resultados
da execução
Especificações
de teste
Nenhuma
ocorrência
Execução
Ocorrência
ou
resultado
do re-teste
Montagem
do
ambiente
Relatório de
ambiente
implantado
Registro
de
incidentes
27
Ciclo de vida do defeito
Encontrar
defeito
Reportar defeito
Solucionar
defeito (1)
RELATÓRIOS DE GESTÃO
Fonte: Tmap Nexst for result –driven test
Tim Koomen e outros – UTN Publishers
(1) Em inglês o termo usado foi Procedure
28
Nunca é demais lembrar
O custo da correção do defeito
Especificação
Projeto
Construção
Teste
Produção
29
www.iteste.com.br
Bibliografia
Autores usados no micro curso
ISO/IEC 29119 – International Standard
Organization
Martin Pol e outros – Software Testing - A Guide to
Tmap Approach – Editora Addison Wesley
Emerson Rios/Trayahu Moreira – Teste de Software
– Editora Altabooks – 2ª Edição
Ron Patton – Software Testing – Editora SAMS
30
Quando eu estou
triste e deprimido...
A receita que o
médico me passou
foi: encontre um
defeito de uma em
uma hora.
31
A definição sobre o que é defeito pode ser vista no filme acessado pelo
link abaixo:
http://youtu.be/c84ryqx03t8
32
Teste de Software
A intuição e a técnica
33
Exemplo Simples
Você deverá testar o seguinte
requisito:
O programa deverá somar dois números que
devem ter um ou dois dígitos. Quando o número
for digitado, ele deve aparecer na tela, e após
serem digitados os dois números, deve surgir o
valor da soma na tela. A funcionalidade somar
deve ser uma opção do menu na tela.
34
O que diz a intuição?
Você chamou o programa, colocou os valores e ele fez a
soma corretamente.
O programa está correto?
? 4
? 3
7
? _
35
Primeira visão
Tudo bem. O programa fez o que o requisito
pediu, porém:
1.Defeito de usabilidade: Não tem nenhuma
informação na tela dizendo que você está usando o
programa correto ou a funcionalidade correta.
2. Defeito de usabilidade: Não tem nenhuma instrução
na tela sobre o que fazer.
3. Defeito de usabilidade: Como você sai dessa tela?
4. Defeito de design: A soma não está alinhada com os
números.
5. Muitos outros defeitos poderiam ser alinhados
? 4
? 3
7
? _
36
Relatando os defeitos
Os defeitos ou incidentes devem ser
registrados e enviados para os
desenvolvedores que os aceitarão
ou não. Correções deverão ser
feitas para a próxima rodada de
testes.
Sugerimos que cada defeito seja
registrado individualmente.
37
Segunda visão
Os testes da primeira visão foram
completos?
Considere o seguinte: Matematicamente existem
39601 testes possíveis de serem feitos usando este
mesmo programa. Temos números entre -99 e 99, o
que incluindo 0 dariam 199 números. Para cobrirmos
todo o universo teríamos 1992 = 39.601. Nós usamos
apenas duas dessas possibilidades.
? 4
? 3
7
? _
38
Segunda visão
CT
Resultado
esperado
Notas
99+99
198
Maior número possível
-99+-99
-198
Não houve menção a nos
negativos
99+-14
85
Maior número em primeiro
-38+99
61
Maior número em segundo
9+9
18
Dois maiores dígitos
0+0
0
Programas muitas vezes falham
com 0
0+23
23
Problemas com 0
-78+0
-78
Problemas com 0
Valores limítrofes é uma conhecida técnica de teste que usamos quando
colocamos os valores máximos e mínimos 99,-99 nas operações de soma.
Pergunta: Será que com esses casos de teste cobrimos todo o universo
39
de Casos de Testes
Terceira visão
CT
Resultado
esperado
Notas
100 + 100
Mensagem de
erro
Embora o requisito limite em dois
dígitos pode ser que o programa
aceite
<Enter>+<En
ter>
Erro - msg
Será que aceita campos em branco
123456+0
Erro - msg
Explorar os limites do campo
1,2 + 3
3,2 ou erro de
definição?
O requisito não fala em número
decimal. Talvez seja um incidente
Mensagem de
erro
O certo seria só aceitar valores
numéricos
A=B
Teclas de
controle +
teclas de
controle
40
Terminamos os testes?
Acho que precisamos ainda de
mais um caso de teste.
O valor da soma será armazenado
em algum arquivo?
41
Conclusões
O número de casos de teste a serem criados e
executados muitas vezes vai depender do prazo de
teste ou de outros fatores.
Além disso, não basta a nossa intuição, precisamos
escrever cada um dos casos de teste.
A mensagem é simples, quanto mais casos de teste
usarmos tanto mais profundo será o nosso teste e
tanto maior será a qualidade do software.
42
Eu quero testar mas
não sei por onde
começar...
Um bom começo
seria escrever os
casos de teste
associados a cada
uma das
funcionalidades ou
requisitos do
software.
43
A definição sobre o que intuição e técnica pode ser vista no filme
acessado pelo link abaixo:
http://www.youtube.com/watch?v=yM3Y18nUsfo&feature=channel
44
O caso da caneta
• Nós somos uma equipe e nos foi dado o
encargo de testar um lote de canetas
esferográficas, como esta acima, o que
vocês acham que deveríamos fazer para
conduzir esses testes, ou seja, como
esses testes deveriam ser conduzidos?
45
Teste da caneta esferográfica
Lista de testes propostos
Testes a serem executados
Testar o prendedor
Parar de usar e voltar a usar
Apertar a mola para ver se está funcionando direito
Estressar a mola
Verificar a carga
Desmontar/montar
Verificar o conforto para escrever
Verificar o nível de resistência da caneta jogando ela no chão
Escrever em diversos tipos de papel
Escrever e depois passar o liquid paper
Verificar se borra a escrita
Verificar se fica um borrão grudado na ponta
Avaliar a durabilidade da carga
Verificar se a escrita falha
Colocar a caneta em diferentes temperaturas (e escrever)
46
Terminologias e conceitos
47
Terminologias
Teste Dinâmico
Teste que para ser executado
precisa de um código de programa
Teste Estático
Teste que para ser executado não
precisa de um código de
programa, exemplo, revisão,
verificação, inspeção.
48
Terminologias
Teste Baseado em
Especificação (Teste Caixa
Preta ou Teste Funcional)
Teste executado com base numa
especificação ou requisito.
Item de Teste
Sistema, software ou produto de
trabalho (ex. requisito,
especificação, etc.) que é objeto
de teste
49
Terminologias
Teste Baseado na Estrutura
(Teste
Caixa Branca)
Teste no qual as entradas (dos
casos de teste) são derivadas do
exame da estrutura do item de
teste
Teste de regressão
É o reteste de um software ou
parte do software após o mesmo
sofrer uma alteração ou correção.
50
Terminologias
Teste de Carga
Busca avaliar o comportamento do
software após ser submetido a um
grande volume de dados, conforme
definido nos requisitos.
Teste de performance
Busca mostrar o comportamento do
software a medida que vai sendo
submetido a uma carga maior de
dados, conforme definido nos
requisitos.
51
A importância do teste de
software
• Porque é importante testarmos
corretamente os softwares?
52
Defeitos podem ser
perigosos
53
Empresa não consegue
vender porque o software
deu um problema
Veja o
desconsolo
da
vendedora
Palestrante tenta
comprar um produto
na loja Tok & Stok
mas o software
(Oracle/Java) não
deixa.
Natureza do
problema:
Palestrante queria
comprar dois
presentes para dois
casamentos que
iriam ocorrer,
coincidentemente,
no mesmo dia, e, o
sistema não deixava
usar o mesmo CPF.
54
Defeitos custam caro
55
Os software têm defeitos
7
Atendem
Não Atendem
93
Apenas uma parcela pequena das aplicações
entregues atendem aos requisitos funcionais e de
tempo de resposta e performance
75% da responsabilidade pelos problemas recaem
sobre a área de desenvolvimento
Fonte: Gartner Group - 2001
56
O custo dos defeitos
“The Economic Impact of Inadequate Infraestruture for Software Testing”
 O custo dos defeitos atinge aproximadamente 1% do PIB
americano
 A falta de uma infra-estrutura robusta e padronizada de testes
pode acarretar os seguintes problemas:
- Aumento de falhas devido a baixa qualidade
- Aumento dos custos de desenvolvimento (re-trabalho)
- Perda do tempo de mercado no lançamento de um
produto
- Aumento dos custos de suporte do produto
57
Por que os projetos de
desenvolvimento falham?
(ou estão sempre cheios de defeitos)?
 Falha na gerência de requisitos
 Comunicação imprecisa ou ambigua
 Grande complexidade
 Arquitetura frágil
 Inconsistências não detectadas em requisitos, projetos e
implementações
 Testes insuficientes
 Avaliação subjetiva do status do projeto
 Falhas na administração dos riscos
 Alterações sem controle
 Insuficiência de automação
Fonte: Capers Jones: Patterns of Software System Failure and Success
58
Por que o processo
tradicional de testes não
atendia?
 Nem todos os requisitos são testados
 Organizações independentes de teste ainda pouco usadas
 Informalidade no processo de testes
 Pouca importância atribuida ao processo de testes
 Defeitos só detectados em produção, onde custam de 100 a
1000 vezes mais para serem consertados
 Abordagens únicas para novas tecnologias
 Falta de automação de testes
 Falta de metodologia de teste
59
Custo do Defeito
60
Verdades sobre o
conceito de teste
 Testar é um exercício de gerência de risco
 Treinamento em teste reduz custos a longo prazo
 Melhorar os testes reduz custos
 Ligar os documentos de desenvolvimento aos documentos de teste melhora
os resultados
 Deve ser mantida uma relação entre os requisitos e as condições de teste
 Sempre teste o ambiente de teste
 É melhor encontrar um defeito nas primeiras fases do que em produção
 As ferramentas de teste não necessariamente melhoram o processo já
existente.
61
Conceitos históricos
Detecção
Demonstração
Descobrir defeitos, erros e deficiências do software
Liberar sistema mesmo
Definir capacidades e limitações
correndo riscos
Fornecer informações sobre a qualidade dos
Garantir que o produto funciona
componentes, sistemas e outros produtos
Testes feitos pelos
desenvolvedores
Prevenção
Trabalho nas especificações do
software
Gerar informações que
previnem ou reduzem os
defeitos
Detectar defeitos nas fases
iniciais
Identificar riscos e problemas de
forma a evitá-los no futuro
Metodologias, processos, etc.
Testes feitos por testadores
Demonstração Detecção
Mostrar que
Encontrar
funciona
defeitos
Década
de 60
Década
de 70/80
Prevenção
Gerenciar a
qualidade
Década
de 90
Por que os testes
mudaram?
62
Níveis de Teste
 Teste Unitário ou Teste de componente –
normalmente feito pelo programador.
 Teste de Integração – normalmente feito pelo
analista de sistemas para um módulo ou conjunto
de programas ou casos de uso em ambiente de
desenvolvimento.
 Teste de Sistemas – normalmente feito pelo
analista de testes (caso de testes) em ambiente de
testes.
 Teste de Aceitação – normalmente feito pelo
usuário em ambiente de homologação,
63
Características de qualidade dos softwares –
ISO/IEC 25010
1.
2.
3.
4.
5.
6.
7.
8.
Funcionalidade
Performance
Compatibilidade (inter-operabilidade)
Usabilidade
Confibilidade (maturidade, disponibilidade)
Segurança
Manutenibilidade
Portabilidade
A norma ISO/IEC 25010 substitui a antiga norma ISO/IEC 9126
64
Norma ISO/IEC 25010
Características
SubCaracterísticas
Integridade
Funcionalidade
Correção
Completeza
Tempo
Performance
Recursos
Capacidade
Compatibilidade
Usabilidade
Co-existência
Interoperabilidade
Facilidade de uso
Acessabilidade, etc...
Maturidade
Confiabilidade
Disponibilidade
Tolerância a falhas
Recuperação
Confidencialidade
Segurança
Integridade
Autencidade
Responsabilidade
Manutenibilidae
Modularidade, reusabilidade, testabilidade....
Portabilidade
Adaptabilidade, Facilidade de instalação,....
65
Tipos de teste x características de
qualidade
Tipo de Teste
Descrição
Característica de qualidade
Funcionalidade
Testa as funcionalidades do
software
Funcionalidade
Interface
Testa ligações com outros
sistemas
Compatibilidade
Carga e estresse
Testa grandes volumes de
entradas e o comportamento
do software (tempo de
resposta e funcionamento)
Performance
Produção
Testa os procedimentos de
produção
Portabilidade
Recuperação
recuperação e de re-início
Confiabilidade
Regressão
Testa as funcionalidades e
outros procedimentos após
uma alteração
Todas
Segurança
segurança
Segurança
Etc.
66
Revisão
67
Revisão
O que é erro, defeito (bug), incidente e anomalia?
Mostrar o ciclo de vida de um defeito
Quando é mais barato a correção de um defeito?
Quais são os níveis de teste?
Cite duas características de qualidade dos softwares (ISO 25010)
Relacione as características citadas anteriormente a um tipo de
teste
68
Processos de Teste
69
Teste de software é
um projeto, acredite
em mim.
em mim.
em mim.
em mim.
70
E tem mais, deve
ser um projeto
paralelo e integrado
ao projeto de
desenvolvimento
71
Definindo projeto
O que vocês acham que aconteceu quando o software entrou em produção?
72
Definindo projeto
D
Projeto é um processo único, consistente, com um conjunto único e
coordenado de atividades, com dada de início e término, conduzidas
para atingir um objetivo, com requisitos especificados, incluindo
restrições de tempo, custo e recursos (ISO 10006)
Projeto é um empreendimento temporário, conduzido para criar um
produto ou serviço ou resultado único (PMI – Project Management
Institute – PMBok 2008) (Gerenciando Projetos de Teste de Software
– Editora ArtImagem)
73
Por que os projetos falham?
Algumas causas do insucesso dos projetos:
•Problemas de comunicação;
•Não cumprimento dos prazos;
•Mudanças de escopo constantes;
•Escopo não definido adequadamente;
•Concorrência entre o dia-a-dia e o projeto na utilização dos
recursos;
•Estimativas incorretas ou sem fundamento;
•Riscos não avaliados corretamente;
•Não cumprimento do orçamento;
•Problemas com fornecedores;
•Retrabalho em função da má qualidade do produto.
Fonte: Estudo de Benchmarking em Gerenciamento de Projetos – Brasil 200974
Ciclo de vida de um projeto
Evolução do custo e pessoal no ciclo de vida de um projeto (Fonte:
PMBOK ® )
75
Teste x desenvolvimento
Planejamento
Projeto
Lógico
Projeto
Físico
Construção
Ciclo de
desenvolvimento
de sistemas
Ciclo de Testes
Passado
Ciclo de Testes
Presente
Ciclo de Testes
Futuro
76
Ciclo de vida do projeto de teste e o ciclo de vida
de gestão do projeto
77
Processo (básico) de Teste
Planejar
Planejar
Testes
Testes
Projetar
Testes
Executar
Testes
Analisar
Resultados
Gerenciar
Defeitos
78
Etapas de
Desenvolvimento e Tipos
de Teste
Requisitos
do Negócio
Teste de
Aceitação
Desenho
Lógico da
Aplicação
Teste de
Sistema
Desenho
Físico da
Aplicação
Teste de
Integração
Construção
Teste
Unitário
79
Integração entre os projetos de
teste e de desenvolvimento
Gerência de Requisitos
Teste
Desenvolvimento
Verificação
Especificação
P
L
A
N
E
J
A
M
E
N
T
O
Execução (1)
Teste
Unitário
Desenho
Lógico e
Físico
Construção
Teste de
Sistema e
Teste de
Integração
Execução (2)
Implantação
P
L
A
N
E
J
A
M
E
N
T
O
Teste de
Aceitação
Entrega
Entrega
Teste
Desenvolvimento
80
Metodologia de
Testes
Visão Geral
Etapas de
Suporte
Preparação
Produtos
Etapas de
Realização
Requisitos
Planejamento
Especificação
Planos de Teste
Especificação
Planejamento
Casos de Teste
Execução
Scripts ou procedimentos
de teste
81
O que é e para que servem os processos?
82
O que é e para que servem os processos?
Na engenharia de software, o processo tem
como meta entregar um produto de software de
maneira eficiente, previsível e que corresponda
às necessidades de negócio. Geralmente inclui
análise de requisitos, programação e testes,
entre outras tarefas. (Wikipédia)
83
E os processos de teste de software, para
que servem?
84
Processo de Teste
Planejar
Planejar
Testes
Testes
Requisitos de
Teste
Projetar
Testes
Executar
Testes
Analisar
Resultados
Gerenciar
Defeitos
85
Principais Documentos dos
Projetos de Teste
(IEEE 829:2008)
•
•
•
•
•
Plano Master de Teste
Plano de Teste
Projeto de Teste
Roteiro/Procedimento de Teste
Caso de Teste
•
•
•
•
Relatório
Relatório
Relatório
Relatório
de Anomalias (Incidentes / Defeitos)
de Estado
de Encerramento / Sumário
Master
86
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
29119-3
Política Organizacional de Teste
Estratégia Organizacional de
Teste
Plano de Teste
Relatório de Estado do Teste
Relatório de Término do Teste
Relatório de incidente
Lista de itens de ação
Relatório de teste estático
Especificação de teste
– Especificação de desenho de
teste
– Especificação de caso de
teste
– Especificação de
procedimento de teste
Requisitos de dados de teste
Requisitos de ambiente de teste
Relatório de situação de
ambiente de teste
Conseqüências (gerados por CT)
do teste
Resultados (se o CT passou ou
não) do teste
Log de execução do teste
Relatório de incidência
IEEE 829-2008
•Plano Máster de Teste
•Plano de Teste
•Desenho (Projeto) de Teste
•Casos de Teste
•Procedimentos de Teste
•Relatórios de Execução dos
Testes
Relatório de Estado de
Teste
Relatório de Teste
(sumário)
Relatório de Log de Teste
Relatório de Anomalias
(ex-Relatório de Incidentes)
•Relatório Máster de Teste
87
29119-3
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Teste
Plano de Teste
Relatório de incidente (ver teste
dinâmico)
teste
teste
ambiente de teste
do teste
não) do teste
IEEE 829-2008
•Plano de Teste
•Desenho (Projeto) de Teste de
Aceitação, Sistema, Integração
e Unitário
•Casos de Teste de Aceitação,
Sistema, Integração e Unitário
•Procedimentos de Teste de
e Unitário
Testes
Teste
(sumário)
88
Exemplo de um caso real
Macro-atividade: Planejar Testes
O objetivo desta macro-atividade é definir o planejamento de um projeto
de teste de software, correspondente a um projeto de desenvolvimento.
O planejamento dos testes deve seguir as regras básicas de gerência
de projetos e os critérios específicos definidos nos templates
correspondentes usados nesta etapa (Ex. Plano de Teste).
Atividade:
Realizar estudo de viabilidade do projeto de teste
Atividade:
Iniciar a elaboração do Plano de Teste
Atividade:
Definir o Ambiente de Teste
Atividade:
Configurar Ambiente de Testes para o Projeto
Atividade:
Verificar a testabilidade dos Casos de Uso ou dos
Requisitos
Atividade:
Detalhar Planejamento das Atividades de Teste
89
Plano de Teste
•
•
Introdução
– Identificador do Plano de Teste;
– Escopo;
– Referências
– Nível na seqüencia de teste
– Classe de teste e visão das condições de teste
Detalhes para este nível do plano de teste
– Itens de teste e seus identificadores;
– Matriz de rastreabilidade do teste;
– Funcionalidades a serem testadas;
– Funcionalidades que não serão testadas;
– Abordagem do teste (Estratégia de Teste na ISO 29119);
– Critérios de liberação/falha dos itens;
– Requisitos de suspensão e retomada;
– Entregas do teste;
(continua)
90
Plano de Teste
•
•
Gerência de Teste
– Tarefas do teste;
– Necessidades de ambientes;
– Responsabilidades;
– Integração entre as partes envolvidas;
– Recursos e sua alocação;
– Treinamento;
– Cronograma, estimativas e custos;
– Riscos e contingências;
Geral
– Procedimentos de garantia de qualidade;
– Métricas;
– Cobertura do teste;
– Glossário;
– Procedimentos de alteração do documento e histórico.
91
Planejar Testes - Artefatos
Planejar
Testes
92
Artefatos Gerados
Checklist
ANÁLISE
Testabilidade
Caso de Uso
93
Como seria uma estratégia de teste
baseada nos riscos do produto ou
negócio?
94
O teste da caneta esferográfica
Plano de Teste
95
Plano de Teste
•
•
•
Detalhes para este nível do plano de teste
– Itens de teste e seus identificadores;
– Matriz de rastreabilidade do teste;
– Funcionalidades a serem testadas;
– Funcionalidades que não serão testadas;
– Abordagem do teste (Estratégia de Teste na ISO 29119);
– Critérios de liberação/falha dos itens;
– Requisitos de suspensão e retomada;
– Entregas do teste;
Gerência de Teste
– Tarefas do teste;
– Necessidades de ambientes;
– Responsabilidades;
– Integração entre as partes envolvidas;
– Recursos e sua alocação;
– Treinamento;
– Cronograma, estimativas e custos;
– Riscos e contingências;
Geral
– Procedimentos de garantia de qualidade;
– Métricas;
– Cobertura do teste;
– Glossário;
– Procedimentos de alteração do documento e histórico.
Plano de
Teste
Resumido
96
E neste Site?
Qual seria a estratégia?
97
E neste Site?
Qual seria a estratégia?
98
Desta forma eu destaquei
alguns tópicos básicos para
qualquer gerente poder
entendê-lo, qualquer que seja o
seu nível intelectual.
Gerentes não gostam de
ler mais de uma página.
O meu Plano de Teste
tem tantos campos que
nenhum gerente vai ter
a paciência de lê-lo.
99
Projetos de Teste
(IEEE 829:2008)
•
•
•
•
•
Plano de Teste
Projeto de Teste
Caso de Teste
•
•
•
•
Relatório
Relatório
Relatório
Relatório
de Estado
Master
100
Processo de Teste
Planejar
Planejar
Testes
Testes
Projetar
Testes
Executar
Testes
Analisar
Resultados
Gerenciar
Defeitos
101
Macro-atividade: Projetar Teste
O projeto dos testes contempla a criação dos casos de teste (conforme
template) e demais artefatos necessários às atividades de execução dos
testes. Na ocorrência de alterações de requisitos, de design ou do
código do sistema, durante ou posteriormente a esta atividade, a
alteração é feita através de uma solicitação formal de mudança, onde
são avaliadas as mudanças necessárias nos artefatos envolvidos.
Atividade:
Atividade:
Atividade:
Atividade:
Definir os cenários de teste
Elaborar Casos de Teste
Estruturar Scripts de Teste
Elaborar Procedimento de Teste
102
Projetar Teste - Documentos
Planejar
Projetar
Testes
Testes
• Roteiro de Teste ou Procedimentos de Teste
• Casos de Teste
• Scripts de teste
103
Caso de Teste
• Um caso de teste é uma descrição
do teste a ser executado. Existe
uma correspondência entre o casos
de teste e o casos de uso, embora,
na maioria das vezes, vários casos
de teste correspondam a um caso
de uso.
104
Caso de Teste – IEEE829
• Identificação do caso de teste
• Itens de teste – componentes, módulos, casos de teste,
etc.
• Especificação das entradas – listar todas as entradas
usadas para a execução do caso de teste
• Especificação das saídas – listar todas as saídas geradas
pelo caso deteste
• Ambiente necessário
• Requisitos especiais
• Inter-dependência entre os casos de teste
105
Exemplo de CT
Em um Caso de Uso de Transferência Bancária, um dos cenários é a Transferência “DOC
para conta de terceiros”.
•
•
•
•
•
•
Para se testar este cenário de especificação, devemos criar um cenário de teste para
validar esta funcionalidade. Este cenário de teste, deve seguir os seguintes passos:
Consultar o saldo da conta de origem;
Consultar dados da conta destino;
Transferir um valor da conta origem para conta destino;
Consultar novamente o saldo da conta origem, verificando que o saldo inicial menos
o valor transferido é igual ao saldo atual;
Etc.
Dentro
–
–
–
–
deste cenário de teste podemos destacar diversos casos de testes:
CT01 Preenchimento dos campos obrigatório na tela de transferência;
CT02 Validação de CPF;
CT03 Conta Destino inválida (se for possível);
CT04 Transferência de valores negativos e muitos outros.
106
Caso prático
Um Sistema web com os seguintes requisitos não-funcionais:
•Deve operar em diferentes Browsers - Internet Explorer 5.0,
5.5, e 6.0, Netscape 6.0 e 7.0, Mozilla 1.1, firefox e Opera 7;
•Deve poder usar diferentes plugins - RealPlayer,
MediaPlayer, não usar nenhum;
•Rodar em diferentes sistemas operacionais nas máquinas
clientes - Windows 95, 98, ME, NT, 2000, e XP;
•Deve receber páginas por diferentes servidores – IIS,
WebLogic e Apache.
•Deve rodar em diferentes servidores – Windows 2000, NT e
Linux.
107
Caso de teste
•
•
•
Introdução (uma por documento)
•
– Identificador do documento
– Escopo
– Referências (itens de teste)
– Contexto
– Notas para descrição
Detalhes (um por caso de teste)
– Identificador do caso de teste
– Objetivos
– Especificações de entrada
– Especificações de saída
– Necessidades de ambiente
– Requisitos ou procedimentos especiais
– Dependências entre casos de teste
Global
– Glossário
– Procedimentos de alterações do
documento e histórico de alterações
Referências (Itens de teste)
– Requisitos
– Projeto de teste e features
– Guia do usuário
– Guia operacional
– Guia de instalação
– Etc.
108
Casos de Teste
109
Exemplo de Casos de Teste
110
Exemplo de Casos de Teste
Cenários de Teste
Caso de Teste - CT01 01Teste Campo Obrigatório
Pré-condições:
Não se Aplica
Pós-condições:
Mensagem de Erro do Sistema
Detalhamento:
*PA: O Ator não informa o login e a senha. E1
PA:
O ator seleciona a opção OK.
**PS::
O Sistema verifica se os campos obrigatórios foram informados
PS: O sistema apresenta a mensagem “O(s) Campo(s) << campo>> deve(m) ser informado(s).” e retorna ao
passo anterior
Massa de entrada e de
Saída:
Não se Aplica
Critérios especiais:
Não se Aplica
Ambiente:
Sistema Operacional Cliente Windows 2000, Browser Internet Explorer 6.0, Servidor de Aplicação IIS e SO
Windows 2000.
Implementação:
Manual
Iteração:
1ª Iteração
Interdependências:
Não se Aplica
* PA - Passo do Ator
** PS - Passo do Sistema
111
Exemplo de Elaboração de Casos de teste
Especificação do Sistema:
O sistema apresenta os seguintes campos: Login e Senha RN01
O sistema apresenta as seguintes opções: OK e Limpar
Caso o ator selecione a opção Limpar
O sistema limpa os campos Login e Senha
Caso o ator selecione a opção OK
O sistema valida o preenchimento dos campos obrigatórios Login e Senha E1, RN02
O sistema valida o conteúdo dos campos Login e Senha E2, E3
Fluxos de exceções
E1 – Campos Obrigatórios
Caso um dos dois ou os dois campos Login e Senha não tenham sido preenchidos
O sistema apresenta a mensagem “O(s) Campo(s) << campo>> deve(m) ser informado(s).” e retorna ao passo anterior.
E2 – Validação Usuário e Senha
O sistema apresenta a mensagem "O login ou senha informados não são válidos " e retorna ao passo anterior
E3. Usuário Bloqueado.
O sistema verifica que o usuário está bloqueado, e exibe uma mensagem com o texto descrito acima e retorna ao passo
anterior.
Regra de Negócio
RN01 – Regra de Tamanho
O Campo Login deve conter no máximo 10 Caracteres alfanuméricos, não podendo aceitar caracteres especiais
tais como: !; @; #; $; %; ” ;‘ ;& ; *; ( ; ) ; +; =
O Campo Senha deve estar protegido para identificação na digitação com o # como mascar e deve conter no
máximo 8 Caracteres alfanuméricos não podendo aceitar caracteres especiais tais como: !; @; #; $; %; ” ;‘ ;& ; *; ( ;
) ; +; =
RN02 – Regra de Bloqueio
Após a terceira tentativa de acesso de um login onde a senha estiver incorreta o sistema bloqueia o acesso deste
login ao sistema.
Regra de Usabilidade:
US01 – Formatação dos Campos
O sistema não deve diferenciar caracteres minúsculos de maiúsculos para o campo Login (case insensitive), mais
112
para o campo senha deve ser diferenciado (case sensitive).
Quantos casos de teste seriam
necessários para testar esta
funcionalidade ou requisito?
Quanto tempo você estima que precisaria para testar este
requisito?
113
Resposta dada por um
especialista
• Quantos casos de teste seriam
necessários?
– Entre 20 e 30 casos de teste
• Quanto tempo seriam gasto na
elaboração e na execução de cada
caso de teste?
– Elaboração – 3 minutos (45%)
– Execução – 4 minutos (55%)
114
Processo de Teste
Planejar
Planejar
Testes
Testes
Projetar
Testes
Executar
Testes
Analisar
Resultados
Gerenciar
Defeitos
115
Projetos de Teste
(IEEE 829:2008)
•
•
•
•
•
Plano de Teste
Projeto de Teste
Caso de Teste
•
•
•
•
Relatório
Relatório
Relatório
Relatório
de Estado
Master
116
Vamos pensar um
pouco. O que eu
preciso para
começar a executar
os testes? Lembrese do Plano de
Teste
117
Caso real - exemplo
Macro-atividade: Executar Testes
Executar casos de teste e/ou scripts automáticos, que foram definidos para cada
iteração, bem como executar testes específicos, como teste de desempenho e outros.
Na ocorrência de alterações das especificações ou do código, durante ou
posteriormente a esta atividade, é verificado se estas alterações afetam também os
casos de teste/scripts. Caso isto tenha ocorrido e a execução já tenha sido iniciada,
será planejado um novo ciclo de teste ou teste de regressão.
Antes de executar os casos de teste devem ser definidos os responsáveis pela sua
execução.
•
•
•
•
•
Atividade:
Atividade:
Atividade :
Atividade:
Atividade:
Executar Casos de Teste
Executar Scripts de Teste
Gerar Resultados (logs) de Teste
Acompanhar Defeitos
Executar Testes Especiais
118
Automação do Teste
•Custo / Esforço
• Cem Kaner estima que leva entre 3 a 10 vezes mais para
criar , verificar e documentar teste automático do que criar
e executar o mesmo teste manualmente. (Kaner, Improving
the Maintainability of Automated Test Suites, p. 2.)
• A Especialista em teste automatico Linda Hayes estima
que gasta 5 a 10 vezes do tempo com teste automático em
relação ao teste manual. (Hayes, Does Test Automation
Save Time and Money? StickyMinds.com, August 8, 2001.)
119
Processo de Teste
Planejar
Planejar
Testes
Testes
Projetar
Testes
Executar
Testes
Analisar
Resultados
Gerenciar
Defeitos
120
Macro-Atividade: Gerenciar Defeitos
Registrar e acompanhar a correção dos defeitos, decorrentes da
execução dos testes. Se for identificado que o defeito persiste, após o
re-teste, a correção é rejeitada, caso contrário ela é aprovada.
Defeitos podem ser identificados durante ciclo de desenvolvimento,
durante a execução do teste de aceite, no ambiente de homologação ou
após a entrega do sistema (ambiente de produção). Em todos os casos,
é utilizado um workflow para acompanhar todo o ciclo de vida do defeito.
Atividade:
Atividade:
Atividade:
Atividade:
Cadastrar Defeitos
Executar Re-Teste
Rejeitar Correções
Aprovar Correções
121
Projetos de Teste
(IEEE 829:2008)
•
•
•
•
•
Plano de Teste
Projeto de Teste
Caso de Teste
•
•
•
•
Relatório
Relatório
Relatório
Relatório
de Estado
Master
122
Gerenciar Defeito
Gerenciar
Defeitos
123
Gerenciar Defeito – Ferramenta de Workflow
Workflow
do Defeito
DevTrack
ClearQuest
124
Relatório de Incidentes
O Relatório de Incidentes (defeitos) é o documento
básico onde a equipe de testes relata os defeitos
encontrados (programa e documentação) e
normalmente deve ser encaminhado à equipe de
desenvolvimento para as providências pertinentes.
125
Você está testando o site da Amazon. A funcionalidade testada
é a compra através de cartões de crédito. Ao clicar na etapa de
definir a forma de pagamento e indicar a bandeira do cartão o
site trava e congela. A sequencia de teste logicamente foi
interrompida pois você não pode mais continuar testando a
compra. Como você relataria este incidente.
126
Relatório de Incidentes – IEEE 829
Introdução
Identificador
Escopo
Referências
Detalhes
Sumário
Data da anomalia
Contexto
Descrição da anomalia
Descrição da execução (identificar o
que foi executado)
Resultados (mensagens, requisições
operacionais, etc)
Informações sobre o ambiente
Eventos anormais (conexão com o
Relatório de Anomalias)
Qualquer situação que causou a
interrupção do teste.
Impacto
Estimativa de urgência
Descrição das ações corretivas
Estado da anomalia
Conclusões e recomendações
Geral
Procedimentos de alterações do
documento e histórico de alterações
127
Exemplo da Ferramenta DevTrack
128
Processo de Teste
Planejar
Planejar
Testes
Testes
Projetar
Testes
Executar
Testes
Analisar
Resultados
Gerenciar
Defeitos
129
Projetos de Teste
(IEEE 829:2008)
•
•
•
•
•
Plano de Teste
Projeto de Teste
Caso de Teste
•
•
•
•
Relatório
Relatório
Relatório
Relatório
de Estado
Master
130
Macro-Atividade: Analisar Resultados
Ao encerramento do projeto de teste conforme as regras definidas no
Plano de Teste devem ser elaborados os artefatos de conclusão.
Atividade: Gerar Resultados dos Testes
Descrição:
Ao final do projeto deve ser elaborado um Relatório de
Sumário contemplando todas as informações relevantes coletadas
durante o seu decorrer, assim como problemas ocorridos e não
conformidades encontradas. Os indicadores fornecidos pelo projeto
devem ser catalogados como histórico para uso em processos de
planejamento e de estimativas.
Responsáveis: LP
Participantes:
AT, TE
Artefatos:
Plano de Teste, Relatório de Sumário de Teste
Ferramentas:
Testlink
131
Analisar Resultado - ATIVIDADES
Planejar
Analisar
Testes
Resultados
• Analisar Resultados (logs)
• Gerar resultados dos testes
132
Analisar Resultado - Medição
Planejar
Analisar
Testes
Resultados
Objetivo
• Indicar a qualidade do produto
• Avaliar a produtividade do processo
• Realimentar dados para estimativa
• Realimentar dados para a estratégia organizacional
Se você não sabe onde você está,
um mapa não vai ajudar!”
Roger Pressman
133
Relatório de Sumário
•
•
•
Introdução
– Identificador
– Escopo
– Referências
Detalhes
– Visão geral dos resultados do teste
– Resultados detalhados do teste
– Racional das decisões
– Conclusões e recomendações
Geral
– Glossário
– Procedimentos de alterações do documento e
histórico de alterações
134
A Visão da norma ISO/IEC - 29119
135
Responsáveis pela execução do processo
Gerente de Projeto
Líder de Projeto de Teste
Analista de Teste
Analista de Requisitos
Testador
Arquiteto de Teste
GP
LP
AT
AS
TE
AR
136
Processos multicamadas de teste
Estratégica
Gerencial
Operacional
Processo organizacional de teste
Processos de gerência de teste
Processos de teste dinâmico
137
Processos multicamadas de teste
com todos os processos
Processo organizacional de teste
Planejamento
de teste
Monitoramento
e controle de
teste
Término de
teste
Desenho e
implementação do teste
Configuração
do ambiente
de teste
Registro de
incidente de
teste
Execução do
teste
138
29119-3
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Teste
Plano de Teste
dinâmico)
teste
teste
ambiente de teste
do teste
não) do teste
IEEE 829-2008
•Plano de Teste
e Unitário
e Unitário
Testes
Teste
(sumário)
139
29119-3
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Teste
Plano de Teste
dinâmico)
teste
teste
ambiente de teste
do teste
não) do teste
IEEE 829-2008
•Plano de Teste
e Unitário
e Unitário
Testes
Teste
(sumário)
140
Processo convencional em relação aos
processos da norma
Processos de
teste dinâmico
Planejar
Testes
Projetar
Testes
Executar
Testes
Gerenciar
Defeitos
Analisar
Resultados
O que faltou?
Processo de teste
organizacional
Processo de gerência de
teste
•Monitoramento e
Controle de Teste
•Configuração do
ambiente de teste
141
Relatório de Estado
• Relatório emitido durante o andamento do projeto,
conforme definido no Plano de Teste (Plano de
Comunicação), que demonstra o andamento do projeto,
especificamente se ele está seguindo o que foi planejado
ou se precisa de alguma correção.
• Por exemplo, pode conter uma lista de casos de teste já
executados, estatísticas de defeitos encontrados por
casos de teste ou tipos de defeitos, comparação entre o
previsto e o realizado, etc.
142
Atividades Executadas no Teste
•
•
•
•
•
•
•
•
•
•
•
Participação na revisão da documentação de desenvolvimento;
Elaboração da lista de requisitos de teste usando os requisitos do
sistema;
Elaboração do Planejamento dos Testes (Plano de Testes com a Estratégia
de Testes);
Preparação do ambiente de testes
Elaboração dos Casos de Teste;
Preparação da massa de teste;
Execução dos testes (programas e scripts);
Registro dos defeitos encontrados;
Documentação dos resultados do teste;
Revisão dos resultados do teste;
Manutenção da documentação de testes (bibliotecas de casos de testes,
etc.)
Fonte: Fátima Mattos, Eficácia no Teste de Sistemas
143
O que mais podemos fazer
para melhorar os nossos
testes?
144
Em que precisamos pensar para iniciar corretamente
o teste da caneta?
E o site na internet do RicoSurf?
145
Como melhorar os testes?
 Escolher um (ou mais) processos de testes adequada e
integrada ao processo de desenvolvimento (já vimos)
 Estruturar uma área orientada para testes e com pessoal
capacitado ( veja Ambiente de Teste)
 Utilizar um ambiente de testes adequado
 Utilizar ferramentas de automação dos testes (se for o caso)
 Utilizar regras de medição do projeto de testes
 Utilizar mecanismos de aferição do nível de maturidade do
processo de testes visando conseguir melhorias contínuas
 Usar técnicas de gerência de projetos (PMI)
146
Recursos Humanos
Líder do Projeto de Testes
LT
Técnico responsável pela liderança
de um projeto de teste
Arquiteto de Teste
AT
É o técnico responsável pela
montagem da infra-estrutura de
teste
Analista de Teste
AN
É o técnico responsável pela
modelagem e elaboração dos casos
de teste e pelos “scripts” de teste
Testador
TE
Técnico responsável pela execução
dos casos de teste e “scripts” de
teste
Atenção: As terminologias usadas para identificar os técnicos da área
de testes podem variar entre organizações. Além disso em algumas
empresas um único técnico pode representar 147
diversos papéis.
Preparação do Ambiente
Atributos
Unitário
Integração
Sistema
Aceitação
Escopo
Unidade
Individual
Unidades
agrupadas
Sistema Inteiro
Simulação da
Produção
Equipe
Desenvolvedores
Desenvolvedores
e Testadores
Testadores
Testadores e
Usuários
Volume de dados
Pequeno
Pequeno
Grande
Grande
Criação Manual
Criação Manual
Criação por
processos
Dados Reais
Interfaces
Não existem
Não existem
Simuladas
Reais/Simuladas
Ambiente
Desenvolvimento
Desenvolvimento
Teste
Produção
Origem dos dados
148
NÍVEL
Práticas do Processo de teste
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Metodologia de teste
Ciclo de vida
Nível de envolvimento
Estimativas e planejamento
Técnicas de especificação de teste
Técnicas de teste estático
Métricas
Ferramentas de teste
Ambiente de teste
Ambiente de escritório
Motivação e comprometimento
Funções e treinamento da equipe
Metodologia
Comunicação
Relatórios
Gerência de defeitos
Gerência de testware
Gerência do processo de teste
Avaliação
Teste estruturais, tais como teste de segurança, teste de carga, etc.
149
Estrutura Organizacional
Gerência de TI
Gerência de
Teste
Gerência de
Projeto A
Gerência de
Projeto n
Estruturas organizacionais dependem muito da forma de atuar da
empresa, logo podem variar entre uma e outra instituição. O
importante é preservar a filosofia de atuação da equipe de testes.
150
Momento da Preparação
• O ambiente de teste pode ser preparado em 2
momentos:
– Estratégia de teste
– Plano de teste
151
Revisão
O que compõe o ambiente de teste?
152
Ambiente de Teste
153
Como melhorar os testes?
 Escolher uma metodologia de testes adequada e
integrada ao processo de desenvolvimento
 Estruturar uma área orientada para testes e com pessoal
capacitado
 Utilizar um ambiente de testes adequado
 Utilizar ferramentas de automação dos testes
 Utilizar regras de medição do projeto de testes
 Utilizar mecanismos de aferição do nível de maturidade
do processo de testes visando conseguir melhorias
contínuas
 Usar técnicas de gerência de projetos (PMI)
154
Ciclo
de
Teste
Esforço despendido (horas) para testar Casos de Uso
Simples
Manual
Intermediário
Automat
Manual
Automat
Complexo
Manual
Automat
1
6,0
10,07
12,0
23,01
16,0
29,64
2
12,0
10,37
24,0
23,41
32,0
30,32
3
18,0
10,67
36,0
23,81
48,0
31,00
4
24,0
10,97
48,0
24,21
64,0
31,68
5
30,0
11,27
60,0
24,61
80,0
32,36
Fonte: Instituto Atlântico – Fortaleza – CE - 2006
155
Considerações sobre automação para testar casos
de uso (ver adiante):
Casos de uso simples – poucas transações de interações com os
usuários e/ou regras de negócio simplórias
Casos de uso intermediários – poucas regras de negócio e uma forte
interação do usuário com a aplicação, por meio de operações do tipo
CRUD (Create, Read, Update e Delete)
Casos de uso complexos – incorporam regras de negócio específicas
do domínio da aplicação
[Liane R. P. Bandeira – Qualidade do Produto a partir de Automação
de Casos de Teste – Universidade Estadual do Ceará – 2005]
156
Quando se deve pensar em
automatizar testes?
Quando:
 Existirem fortes pressões para melhorar a qualidade;
 O projeto tiver situações que não possam ser testadas
adequadamente pelos métodos tradicionais;
 O perfil dos softwares desenvolvidos forem complexos e
com impacto no negócio;
 Estudos de custo/benefício justificarem o investimento;
 O tamanho do projeto ou do ambiente de teste
justificarem.
Obs.: Avaliar a possibilidade do uso de ferramentas
abertas e livres
157
Considerações para automação de testes
Ferramentas de mercado;
•
•
•
•
•
•
•
•
HP
Rational
Segue
Empirix
Mercury
Test Complete
Test Link
Mantis ........
Software Livre
• Lembre-se que existem ferramentas disponíveis no mercado que
podem ser utilizadas e que estão disponíveis em sites da internet
para serem baixadas.
• Pequenos desenvolvedores não possuem recursos para comprar
ferramentas caras.
158
159
160
Ferramenta
livres para
teste de
carga em
ambiente
Web
161
Teste de Carga com a ferramenta DieselTest no site
da ALATS
Máximo de 25 usuários
Tempo de
carga
Script
criado
para o teste
Tempo de
carga de
cada página
Usuários
“logados”
162
Teste de Carga com a ferramenta DieselTest no site da
ALATS
Máximo de 50 usuários
Tempo de
carga
Usuários
“logados”
163
Estimativas
Conceitos básicos
O que se quer estimar?
» Tamanho
» Esforço
» Custo
» Prazo
164
Conceitos básicos
TAMANHO
ESFORÇO
CUSTO
PRAZO
165
Estimativa e gerência de projeto
Recursos
desviados
Falta equipe
quando planejado
Funcionalidades
removidas
Requisitos retirados
estimativa
PROJETO
Requisitos
acrescentados
Equipe menos
experiente
Equipe
atendendo
outro projeto
Novos recursos
acrescentados
166
Se você não consegue medir só existe uma razão
para você acreditar que ainda tem o projeto sob o
seu controle: otimismo histérico. Tom de Marco.
Não se pode gerenciar o que não se pode medir.
167
Métricas usadas em projetos de teste de
software
• Análise
de Ponto de Teste
• Ponto de Caso de Teste
• Complexidade de Requisitos
• Complexidade de Casos de Uso
168
Distribuição entre as etapas de teste
Preparação
Especificação
Execução
Transição
10%
40%
45%
5%
Cada ambiente tem
os seus próprios
números
Para aqueles que querem um número mágico para estimativas rápidas
sugerimos um valor entre 1 e 2 horas de teste por ponto de função. No
entanto cabe lembrar que são valores médios de mercado e nem sempre
correspondem a um projeto de teste específico.
169
Estimativas de Capers Jones – livro Estimating
Software Costs
 Cada estágio de testes poderá remover 30% dos
defeitos existentes.
 Um sistema com 100PF teria potencialmente 316
defeitos.
 Neste caso, por exemplo, depois de 3 estágios de
testes (TSU, TI e TS) ainda restaram 108 defeitos que
iriam para os testes de aceitação com o usuário.
170
Boas métricas devem permitir que o gerente possa responder
as seguintes perguntas:
 Por que os testes estão demorando tanto?
 Por que os testes ainda não terminaram?
 Quantos defeitos ainda podem ocorrer em produção?
 Quantos testes ainda serão necessários?
 Quando os testes terminarão?
 Quando os testes começarão a ser feitos pela equipe de testes/
 Qual a qualidade do sistema testado?
 Quando o sistema poderá entrar em produção?
 Quantos defeitos foram encontrados e qual a sua classifação?
171
Outras métricas
 Número de defeitos / tamanho do software
 Número de defeitos / casos de teste
 Número de defeitos classificados por tipo, severidade,
etc.
 Número de horas de teste (defeitos, casos de teste) por
ponto de função
 Custo por defeito
 Etc.
172
Revisão
Quando eu termino um projeto de teste de
software?
No caso do teste da caneta qual seria esse
momento?
Quando eu suspendo um projeto de teste de
software?
173
MPT.Br
Melhoria do Processo de Teste
Brasileiro
174
O que é o modelo?
•
•
O MPT.Br é um modelo que trata a melhoria do
processo de teste através de melhores práticas.
Objetivos:
– Tornar-se um modelo de referência para
definição, implantação e melhoria dos processos de
teste;
– Abordar a melhoria contínua nos processos de
teste conforme os objetivos organizacionais e nível
de maturidade almejado;
– Fornecer uma base para avaliação e consequente
identificação do grau de maturidade presente
nas organizacionais; e
– Reunir as melhores práticas e estruturá-las
segundo o grau de complexidade versus o nível de
maturidade que a mesma estará relacionada.
175
Modelo de Gestão
•
•
SOFTEXRECIFE - Centro de Tecnologia de Software
para Exportação do Recife, sociedadecivil sem fins l
ucrativos, agente da Sociedade SOFTEX, que no Brasil
possui mais de 1.000 empresas associadas. Sua missão
é articular, fomentar e apoiar ações direcionadas à
excelência do setor de software em Pernambuco.
RIOSOFT - fundada em 1993 a partir do Programa
SOFTEX 2000, com a combinação de ideais da classe
empresarial atuante em Tecnologia da Informação e a
vontade política da Prefeitura da Cidade do Rio de
Janeiro, contando também com o apoio do SEBRAE-RJ,
da ASSESPRO-RJ e do SEPRORJ.
176
Referências do Modelo
•
TMMi – Test Maturity Model Integration (versão 3.1):
– desenvolvido para complementar o framework
do CMMi;
– organizado em 5 níveis de maturidade;
– As 5 áreas de processo de qualidade
abordam, dentre outros aspectos, o
processo de testes e seu ciclo de
vida, avaliação e controle da
qualidade do produto;
• ISO 29119
– Já vimos anteriormente
177
Estrutura do Modelo
Base de Conhecimento
ISTQB/CSTE/CBTS
MPS.BR
CMMI
Referencial Teórico
TMMI (versão 3.1)
ISO 29119
•Conselho Consultivo
•Conselho Técnico
•Unidade Executora
•Instituição Avaliadora
•Instituição Implementadora
•Implementador MPT.Br
•Avaliador MPT.Br
Modelo
Gestão
Modelo de
Referência
Modelo de
Avaliação
•SCAMPI
•Modelo de Avaliação MPS.BR
178
Níveis de Maturidade
Controle Estatístico do
Processo
Otimização do Processo de
Teste
Automação de Teste
Gestão de Ferramentas Case
Gestão de Defeitos
Teste Não Funcional
Avaliação da Qualidade do Software
Organização do Teste (evolução)
Automação e
Otimização
Prevenção
de Defeitos
Definido
Gerenciado
Parcialmente
Gerenciado
Organização do Teste
Medição e Análise
Teste estático
Treinamento
Garantia da Qualidade
Teste de Aceitação
Fechamento de Teste
Gerência de Projeto de Teste (Evolução)
Projeto e Execução do Teste (Evolução)
Gerência de Requisitos de Teste
Gerência de Projeto de Teste (Evolução)
Projeto e Execução do Teste (Evolução)
Gerência de Projeto de Teste
Projeto e Execução do Teste
179
Site do MPT.BR
180
www.mpt.org.br
Empresas que
implementaram
Empresas Avaliadas Data da Avaliação
BisaWeb
Brisa
Brisa
Brisa
Brisa
Cartello
DATASUS
FTS LTDA
GCF Sistemas LTDA
In Forma Software LTDA
Informata
iTeste
Partec
Procenge LTDA
WPD Informática LTDA
20/12/11
13/03/12
13/03/12
26/07/12
15/05/12
14/02/12
17/03/10
04 e 05/04/11
15/05/12
12/11/10
10/05/12
22/11/11
29/11/10
30/11/10
12/11/10
Nível
Estado
Nível 1
Nível
Nível
Nível
Nível
Nível
Nível
Nível
SE
Nível
Nível
Nível
Nível
Nível
Nível
Nível
1
2
1
1
2
1
1
PE
BA
RJ
DF
SP
PE
RJ
1
1
1
2
1
1
1
PE
PE
PE
RJ
PE
PE
PE
181
Evolução / Planejamento do MPT.Br
182
Ano
Nível Nível Nível Nível Nível Total
1
2
3
4
5
2010
5
-
-
-
-
5
2011
2
1
-
-
-
3
2012 (*)
5
3
1
Total previsto
2013
(estimativa)
9
17
36
3
3
42
(*) Até o final de 2012 uma empresa será avaliada no nível 1, uma no nível
2 e uma no nível 3
Um empresa do nivel 1 deverá passar para o nivel 2.
• Estrutura Organizacional
– Comitê Gestor
• Softex Recife
• Riosoft (Agente Softex RJ)
– Conselho Consultivo
– Conselho Técnico
– Unidade executora
– Instituição Avaliadora
– Instituição Implementadora
– Implementador MPT
Quanto maior o nível de
maturidade tanto mais
estável será o caminho dos
projetos de teste de
software
Estimativa “boa”
Boeing Company
150
Erro na estimativa %
• Empresas com
níveis altos de
maturidade
tendem a
acertar mais
nas estimativas
50
-50
-150
1
2
3
4
5
CMMI Level
185
Algumas atividades num
projeto de teste de software
•
•
•
•
Participação na revisão da documentação de
desenvolvimento;
Elaboração da lista de requisitos de teste usando os
requisitos do sistema;
Elaboração do Planejamento dos Testes (Plano de
Testes e Estratégia de Testes);
Preparação do ambiente de testes
Elaboração dos Casos de Teste;
Preparação da massa de teste;
Execução dos testes (programas e scripts);
•
•
•
•
Registro / acompanhamento dos defeitos encontrados;
Documentação dos resultados do teste;
Revisão dos resultados do teste (indicadores);
Manutenção da documentação de testes (bibliotecas de casos de testes, etc.)
•
•
•
186
Algumas atividades num projeto de teste de
software
Participação na revisão da documentação de
Planejar desenvolvimento;
• Elaboração da lista de requisitos de teste usando os
requisitos do sistema;
• Elaboração do Planejamento dos Testes (Plano de
Testes e Estratégia de Testes);
Especific
• Preparação do ambiente de testes
ar
• Elaboração dos Casos de Teste;
Gerenci
Executa• Preparação da massa de teste;
ar
r
• Execução dos testes (programas e scripts); defeitos
• Registro / acompanhamento dos defeitos encontrados;
• Documentação dos resultados do teste;
Encerrar• Revisão dos resultados do teste (indicadores);
187
• Manutenção da documentação de testes (bibliotecas de
•
Revisão Geral
188
Quais são os níveis de teste?
•
•
•
•
Teste
Teste
Teste
Teste
Unitário ou Teste de Componente
de Integração
de Sistemas
de Aceitação
Defina Teste Caixa Branca e Teste
Caixa Preta?
189
Revisão
Quando os testes devem ser iniciados?
• R.: O quanto antes (na fase de planejamento)
Quais os documentos que devem ser usados num
processo básico de teste de software?
• R.: Estratégia de Teste, Plano de Teste, Casos de
Teste, Relatório de Defeitos.
Para que serve a Estratégia de Teste?
• R.: Riscos x testes. Características de qualidade x
testes. Módulos x testes. Definir as dimensões de
teste que serão usada. Etc.
190
Revisão
O que compõe o ambiente de teste?
•
•
•
•
•
•
Hardware
Software
Ferramentas de automação
Pessoal
Local de trabalho
Etc.
191
Considerações finais
192
Quadrilátero endemoniado
Tempo
Qualidade
Funcionalidade
Quando aumentam as
pressões sobre o tempo
e o dinheiro a tendência
é reduzir os testes de
funcionalidades e a
qualidade dos testes
Dinheiro
Obs.: Demonic Quadrangle – M.Pol, E. Veenendaal, R. Teunissen
193
Balança Perigosa
Orçamento
Cobertura
dos riscos
Se não fosse o orçamento ( e o tempo) os testes
poderiam eliminar todos os riscos
194
Bibliografia
•
Teste de Software, Editora Altabooks, 2a. Edição - Emerson Rios e Trayahu Moreira
•
Análise de Riscos em Projetos de Teste de Software, Editora Altabooks, Emerson Rios
•
Software Testing, Addison Wesley, Martin Pol, Erik Van Veenendaal e outros.
•
Managing the Testing Process, Microsoft Press, Rex Black
•
Test Process Improvement, Addison Wesley, Martim Pol e Tim Koomen
•
Qualidade de Software, Editora Prentice Hall, Ana Regina Cavalcanti da Rocha e
outros.
•
Base de Conhecimento em Teste de Software, Editora Martins Fontes, Aderson
Bastos, Emerson Rios, Ricardo Cristalli, Trayahu Moreira.
•
Garantia de Qualidade de Software, Editora Camus, Alexandre Bartiê.
•
Documentação de Teste de Software – Ed Imagem Art Studio – 2a edição – Emerson
Rios
•
Gerenciando Projetos de Teste de Software – Ed Imagem Art Studio – Emerson Rios,
Ricardo Cristalli, Trayahu Moreira.
195
FIM
Um bom testador deve estar sempre
aprendendo.
Emerson Rios
[email protected]
196

Clinica sobre conceitos básicos de teste de software

Transcrição

Documentos relacionados

Declaração de garantia do nível de bolha

Baixar Especificações

Sistema de Injeção Eletrônica do JETTA 2.5

Cyclâmen - FV - Veiling Holambra

O CÓDIGO CIVIL NA DEFESA DO CONSUMIDOR Samuel Cohen1

chuchu - Ceagesp

Whistle: Um Detector de Defeitos para Sistema

CERTIFICADO DE APROVAÇÃO - CA Nº 4.677 VÁLIDO

PISOS - pisotech

pisos - pisotech

UTE Cocal 138 kV

ferramenta: POKA YOKE PARA PEQUENAS E MÉDIAS EMPRESAS