Post on 12-Jan-2015
description
Victor Hugo GermanoTeste de Software
CTAI SENAISC
Aula - 02
Victor Hugo Germano
http://malditacomedia.blogspot.com
Retrospectiva
Por que testar?
Unitários
Unitários
Transição de Estado
Unitários
Integração
Transição de Estado
Unitários
Integração
Transição de Estado
Análise de Valor Limite
Unitários
Integração
Transição de Estado
Testes de Caminho
Análise de Valor Limite
Aceitação
Unitários
Integração
Transição de Estado
Testes de Caminho
Análise de Valor Limite
Unitários
Unitários
JUnit
TDD
TDD
Escreva um teste que falhe
TDD
Escreva um teste que falhe
Faça o teste passar
TDD
Escreva um teste que falhe
Faça o teste passar
Refatore
Bom dia!
Testes de Aceitação
Testes de aceitação
Por quê?
Testes de aceitação
Por quê?Direcionar o desenvolvimento
do produto
Testes de aceitação
Pra quê?Verificar a completude de um
requisito
Testes de aceitação
Como?
Testes de aceitação
• Idealmente escritos antes do desenvolvimento• Idealmente Automatizados• Garantem que o código faz exatamente o que se propõe a fazer
Como?
Tempo
Tempo
1
Tempo
1 2
Tempo
1 2 3
Tempo
1 2 3 4
Tempo
1 2 3 4
Tempo
1 2 3 4
Explorar RequisitosDefinir Testes de Aceitação para Use Cases
Tempo
1 2 3 4
Explorar RequisitosDefinir Testes de Aceitação para Use Cases
Tempo
1 2 3 4
Explorar RequisitosDefinir Testes de Aceitação para Use Cases
Testes de aceitação garantes conformidade com os requisitos
Tempo
1 2 3 4
Explorar RequisitosDefinir Testes de Aceitação para Use Cases
Testes de aceitação garantes conformidade com os requisitos
Tempo
1 2 3 4
Explorar RequisitosDefinir Testes de Aceitação para Use Cases
Testes de aceitação garantes conformidade com os requisitos
Tempo
1 2 3 4
Explorar RequisitosDefinir Testes de Aceitação para Use Cases
Testes de aceitação garantes conformidade com os requisitos
Tempo
1 2 3 4
Explorar RequisitosDefinir Testes de Aceitação para Use Cases
Testes de aceitação garantes conformidade com os requisitos
Tempo
1 2 3 4
Explorar RequisitosDefinir Testes de Aceitação para Use Cases
Testes de aceitação garantes conformidade com os requisitos
Tempo
1 2 3 4
Explorar RequisitosDefinir Testes de Aceitação para Use Cases
Testes de aceitação garantes conformidade com os requisitos
Mãos à obra!
Selenium
http://seleniumhq.org/
Selenium IDE\\172.16.4.19
<html> <head> <title>My Application Test Suite</title> </head> <body> <table> <tr><td><b>Suite Of Tests</b></td></tr> <tr><td><a href="./TestLogin.html">Test Login</a></td></tr> <tr><td><a href="./TestFormEntry.html">Test Form Entry</a></td></tr> <tr><td><a href="./TestFormSave.html">Test Form Save</a></td></tr> </table> </body> </html>
Test Suite
Exercício V
Integrar Testes numa suite de testes de aceitação
Exercício VConstruir testes de aceitação
Na página principal, devem haver links para outros serviços do google: orkut, email, Imagens e Mapas
Na pagina de Busca avançada, selecionar o idioma Ingles e buscar por “linux” deve retornar a pagina da wikipedia em
inglês como primeiro item da busca
Uma consulta que não apresenta resultados deve apresentar uma mensagem de indicação
Quando Parar de testar?
Quando Parar de testar?
Custo
Quando Parar de testar?
Custo
Prazo
Quando Parar de testar?
Custo
Prazo
Cliente
Criando Test Cases
Test Cases
Comunicação
Test Cases
Comunicação
Encontrar problemas antes que o cliente o faça
Test Cases
Comunicação
Encontrar problemas antes que o cliente o faça
Evitar que problemas ocorram
Test Cases
Comunicação
Encontrar problemas antes que o cliente o faça
Evitar que problemas ocorram
Auxiliar na tomada de decisão
Aderência aos requisitos de negócio,não de sistema
Test Cases
Test Cases
Redução de Riscos
Medir a Qualidade
Encontre as prioridades do projeto!
Encontre as prioridades do projeto!
Um único objetivo por vez!
Encontre as prioridades do projeto!
Um único objetivo por vez!
Está tudo claro? Pergunte!
Encontre as prioridades do projeto!
Um único objetivo por vez!
Pare e pense!
Está tudo claro? Pergunte!
Test Cases
Qualidades
Test Cases
QualidadesFácil de ler- Não há lugar para enrolação!
Test Cases
QualidadesFácil de ler- Não há lugar para enrolação!
Rápido de encontrar o resultado esperado- Interpretação em poucos segundos
Test Cases
QualidadesFácil de ler- Não há lugar para enrolação!
Rápido de encontrar o resultado esperado- Interpretação em poucos segundos
Autoexplicativos- Não necessitam da especificação completa do sistma
Test Cases
QualidadesFácil de ler- Não há lugar para enrolação!
Rápido de encontrar o resultado esperado- Interpretação em poucos segundos
Autoexplicativos- Não necessitam da especificação completa do sistma
Curtos- Elimine todos os desperdícios!
- Seja imperativo
"clique no botão", "vá ao item 1"
- Seja direto e simples, porém não simplório
- Use nomes exatos e consistentes para campos,
não seja genérico
- Entre 10 e 15 passos
- Siga convenções de nomes
- Se não existem convenções, CRIE-AS!!!
Easy to Test Language
• Identificador• Descricao• Prioridade• Pre-condição• Dependências • Entradas• Instruções de utilização• Resultados esperados• Resultado Atual• Pós-condições• Resultado (passou/falhou)• Número da versao
Atributos Comuns
Linhas Gerais
Linhas Gerais
Escrever testes juntamente com os requisitos
Linhas Gerais
Escrever testes juntamente com os requisitos
Descrevem o atual requisito
Linhas Gerais
Escrever testes juntamente com os requisitos
Descrevem o atual requisito
Siga um padrão, facilite a comunicação
Linhas Gerais
Escrever testes juntamente com os requisitos
Descrevem o atual requisito
Siga um padrão, facilite a comunicação
Priorize seus testes por valor de negócio
Linhas Gerais
Escrever testes juntamente com os requisitos
Descrevem o atual requisito
Siga um padrão, facilite a comunicação
Priorize seus testes por valor de negócio
Agrupe testes por domínio
Linhas Gerais
Escrever testes juntamente com os requisitos
Descrevem o atual requisito
Siga um padrão, facilite a comunicação
Priorize seus testes por valor de negócio
Agrupe testes por domínio
Foque no valor! Foque no resultado!
Pratique!!A prática leva à perfeição
Pratique!!Priorize! Remova desperdícios!
A prática leva à perfeição
Pratique!!Priorize! Remova desperdícios!
A prática leva à perfeição
Se possível, automatize!Seja preguiçoso!
http://www.consiste.dimap.ufrn.br/~andre/casouso/
Exercício VI
Sistema de Vendas
Construir testes de aceitação para módulo Fazer Pedido
Fazer Pedido - versão 4
Atores
Cliente
Pré-condição:
O usuário deve ter feito "log-in" e obtido autorização do sistema
Pós-condição:
O pedido deve ter sido gravado no sistema e marcado como confirmado.
Exercício VI
Applying Use Cases: A Pratical Guide", Geri Schneider & Jason Winters, Addison-Wesley, 1998.
Applying Use Cases: A Pratical Guide", Geri Schneider & Jason Winters, Addison-Wesley, 1998.
Fazer Pedido - versão 4
Fluxo de eventos primário:
1. O caso de uso começa quando po cliente seleciona "fazer pedido". 2. O cliente fornece seu nome e endereço. 3. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e o
estado. 4. Enquanto o cliente quiser pedir itens faça 1. O cliente fornece código do produto 2. O sistema fornece as descrição e preço do produto 3. O sistema atualiza o valor total 5. O cliente fornece as informações sobre cartão de crédito. 6. O cliente submete os dados ao sistema. 7. O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as
informações de pagamento para o sistema de contabilidade e pagamento. 8. Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número
de pedido (NP) é dado ao cliente.Fluxo de eventos secundário:
A qualquer momento antes de submeter, o cliente pode selecionar cancelar. O pedido não é gravado e o caso de uso termina.
No passo 7, se alguma informação estiver correta, o sistema pede ao cliente para corrigir a informação.
Planejamento de Testes
Por que Planejar?
Por que planejar?
Finalidade:• Localizar e documentar defeitos na qualidade do software.• Avisar de forma geral sobre a qualidade observada no software.• Validar as suposições feitas nas especificações de design e requisito através de demonstração concreta.• Validar as funções do software conforme projetadas.• Verificar se os requisitos foram implementados de forma adequada.
Com Planejar?
Teste antes, teste sempre!
Teste antes, teste sempre!
Comunique-se!
Teste antes, teste sempre!
Comunique-se!
Comunique-se!
Teste antes, teste sempre!
Comunique-se!
Comunique-se!
Se puder, automatize!
Teste antes, teste sempre!
Comunique-se!
Comunique-se!
Se puder, automatize!
Entenda o domínio do negócio
Templates
Introdução
Introdução
Visão Geral:- Escopo, métodos, Padroes
Introdução
Visão Geral:- Escopo, métodos, Padroes
Requisitos:- Hardware, software, Pessoal
Templates
Template
Interação Homem-Computador
• descrição, • objetivos,• métodos, • objetos a serem testados, • eventos a serem testados, • verificação dos testes, • ferramentas de teste.
Template
Testes Funcionais
• objetivos, • métodos, • funções a serem testadas,• projeto de dados para testes, • construção dos dados de teste, • verficação do teste, • ferramentas de teste
Template
Testes de regressão
•Objetivos • O que não funciona mais e o que
continua funcionando na nova versão • Dados para teste • quais casos serão reutilizados
• Execução dos testes • Ferramentas de teste
Template
Testes de desempenho
• Objetivos
• Métodos de teste • Monousuário • Multiusuário
• Criação dos dados de teste • Verficação do teste • Ferramentas de teste
Template
Testes de aceitação
• Objetivos•Cenários de negócio a serem
testados• Projeto dos casos de teste • Métodos de teste• Verficação do teste • Ferramentas de teste
Template
Testes de Sistema
• Objetivos • cenários de negócio a serem testados
• Projeto dos casos de teste • Métodos de teste • Verficação do teste • Ferramentas de teste
Como documentar um Bug
Documentar um Bug
• Seja preciso • Seja claro - explique de forma que outros
possam reproduzir o erro • Um bug por relatório • Nenhum bug é simples o suficiente para não
ser registrado • Separe claramente fatos de especulações • Um printscreen vale mais que mil parágrafos
Documentar um Bug
“Eu estava usando o sistema e então ele deu pau”
Documentar um Bug
“Eu estava usando o sistema e então ele deu pau”
-> Abra o sistema e vá ao item "Arquivo > Novo"
-> Desenhe uma Reta
-> Vá até a função "Salvar Como..." e salve o arquivo
-> Tente abrir o arquivo novo
-> Verifique a mensagem de erro
O que testar?
Análise de Risco & Prioridades
Analise de Risco
Use Case Cenário Risco Frequência Criticidade
UserCase 1 Cenário A Alto Alta Baixa
UserCase 2 Cenario B Médio Baixa Alta
Analise de Risco
Priorização
PriorizaçãoModelo Kano
PriorizaçãoModelo Kano
Priorização Pelo Valor Percebido
http://en.wikipedia.org/wiki/Kano_model
Modelo Kano
Must-have Obrigatórios
http://en.wikipedia.org/wiki/Kano_model
Modelo Kano
Must-have Obrigatórios
http://en.wikipedia.org/wiki/Kano_model
Linear Quanto mais, melhor!
Modelo Kano
Must-have Obrigatórios
http://en.wikipedia.org/wiki/Kano_model
Linear Quanto mais, melhor!
Exciters Necessidades não conhecidas
Modelo Kano
Modelo Kano
http://www.acarlos.com.br/blog/
2 Perguntas:
Modelo Kano
http://www.acarlos.com.br/blog/
2 Perguntas:
FuncionalO que você acha de ter uma
cerveja de graça no quarto de hotel todos os dias?
Modelo Kano
http://www.acarlos.com.br/blog/
2 Perguntas:
FuncionalO que você acha de ter uma
cerveja de graça no quarto de hotel todos os dias?
DysFunctionalChegar em um hotel que não tem cerveja grátis, o que você
acha?
Modelo Kano
DysFunction Question
Like Q E E E L
Expect R I I I M
Neutral R I I I M
Live with R I I I M
Dislike R R R R Q
Like
Expe
ct
Neu
tral
Live
with
Dis
like
Func
tiona
l Que
stio
n
M - MandatoryL - LinearE - ExciterQ - QuestionableR - ReverseI - Indifferent
Benefício Relativo
Benefício Relativo
http://www.acarlos.com.br/blog/
Benefício Relativo
Pré-requisito: Estimativas criadas
http://www.acarlos.com.br/blog/
Benefício Relativo
Pré-requisito: Estimativas criadas
Benefits Penalties Sum(BV) Estimation BV/Est
Feature 1 1 9 10 2 5
Feature 2
Feature 3
Feature 4
Feature 5
http://www.acarlos.com.br/blog/
Benefício Relativo
Pré-requisito: Estimativas criadas
Benefits Penalties Sum(BV) Estimation BV/Est
Feature 1 1 9 10 2 5
Feature 2 2 3 5 5 1
Feature 3
Feature 4
Feature 5
http://www.acarlos.com.br/blog/
Benefício Relativo
Feature 5
Feature 1
Feature 3
Feature 4
Feature 2
Benefício Relativo
Pré-requisito: Estimativas criadas
Benefits Penalties Sum(BV) Estimation BV/Est
Feature 1 1 9 10 2 5
Feature 2 2 3 5 5 1
Feature 3 5 1.6 13 8 8
Feature 4 6 7 13 13 1
Feature 5 5 5 10 2 5
http://www.acarlos.com.br/blog/