ctai teste de software aula 2

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


Unitários

Integração


Análise de Valor Limite

Unitários

Integração


Testes de Caminho


Aceitação

Unitários

Integração


Testes de Caminho


Unitários

Unitários

JUnit

TDD

Escreva um teste que falhe

TDD


Faça o teste passar

TDD


Faça o teste passar

Refatore

Bom dia!

Testes de Aceitação

Testes de aceitação

Por quê?


Por quê?Direcionar o desenvolvimento

do produto


Pra quê?Verificar a completude de um

requisito


Como?


• Idealmente escritos antes do desenvolvimento• Idealmente Automatizados• Garantem que o código faz exatamente o que se propõe a fazer

Como?

Tempo

1

Tempo

1 2

Tempo

1 2 3

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

Testes de aceitação garantes conformidade com os requisitos

Mãos à obra!

Selenium

http://seleniumhq.org/

Selenium IDE\\172.16.4.19

http://seleniumhq.org

http://seleniumhq.org

<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?


Custo


Custo

Prazo


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


Evitar que problemas ocorram

Test Cases

Comunicação


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!


Um único objetivo por vez!



Está tudo claro? Pergunte!



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


Rápido de encontrar o resultado esperado- Interpretação em poucos segundos

Test Cases



Autoexplicativos- Não necessitam da especificação completa do sistma

Test Cases



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


Descrevem o atual requisito

Linhas Gerais



Siga um padrão, facilite a comunicação

Linhas Gerais




Priorize seus testes por valor de negócio

Linhas Gerais





Agrupe testes por domínio

Linhas Gerais





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!


Comunique-se!


Comunique-se!

Comunique-se!


Comunique-se!

Comunique-se!

Se puder, automatize!


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


• 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


Modelo Kano





Linear Quanto mais, melhor!

Modelo Kano





Linear Quanto mais, melhor!

Exciters Necessidades não conhecidas

Modelo Kano



Modelo Kano

http://www.acarlos.com.br/blog/

2 Perguntas:



Modelo Kano


2 Perguntas:

FuncionalO que você acha de ter uma

cerveja de graça no quarto de hotel todos os dias?



Modelo Kano


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

Pré-requisito: Estimativas criadas




Benefício Relativo


Benefits Penalties Sum(BV) Estimation BV/Est

Feature 1 1 9 10 2 5

Feature 2

Feature 3

Feature 4

Feature 5




Benefício Relativo



Feature 1 1 9 10 2 5

Feature 2 2 3 5 5 1

Feature 3

Feature 4

Feature 5




Benefício Relativo

Feature 5

Feature 1

Feature 3

Feature 4

Feature 2

Benefício Relativo



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




ctai teste de software aula 2

Technology