CLÍNICA TECNOLÓGICA COMO ESCREVER CASOS DE TESTE. Palestrante: Marcia Silva

(1)

CLÍNICA TECNOLÓGICA

COMO ESCREVER CASOS DE TESTE

Palestrante: Marcia Silva

MARCIA.SILVA@DATASUS.GOV.BR www.emersonrios.eti.br

(2)

MARCIA SILVA

marcia.silva@datasus.gov.br

Pós-graduada em Melhoria de Qualidade de Software pela UFRJ e em Análise, Projetos e Gerência de Sistemas pela Consultoria GFI (UNB); Graduada em Processamento de Dados pela Faculdade Alvorada (DF); Certificada CBTS (Certificação Brasileira em Teste de Software) ;

Desempenha a função de Gerente, Gestora e Projetista de Teste no Departamento de Informática do Sistema Único de Saúde DATASUS; Habilitada para implementar e avaliar o Modelo de Melhoria de

Qualidade de Software Brasileiro MPT.BR (Nível 1 e 2);

Faço parte do Grupo de Trabalho da ISO 29.119 Teste de Software

2

(3)

Nome e expectativas;

Atividades atuais;

Experiências profissionais;

Motivações;

(4)

O que é Teste de Software? Por que testamos?

Quero testar mas não sei por onde começar… Processo básico de Teste de Software

Fases de um Projeto de Teste Como planejar os Testes?

Casos de Testes (Padrão IEEE 829 x ISO 29.119) Tipos e técnicas de Teste de Software

Como identificar os cenários de Teste? Como elaborar os casos de Teste?

Como encontrar defeitos? Exercícios

(5)

Ao final do curso, os participantes deverão:

Ter uma visão

dos conceitos Básicos de Teste de Software

das principais atividades do processo de teste: planejamento, projeto,

execução, acompanhamento e encerramento;

os documentos que podem ser gerados para acompanhar e executar as

atividades de teste;

Projetos x Processos

Conhecer:

as principais técnicas para escrever Casos de Teste. Diferenciar Cenário Teste X Caso de Teste (CT)

Elaborar CT para os diferentes estágios de teste. Elaborar CT para diferentes tipos de teste.

(6)

O que é Teste de Software?

Teste é o processo de executar um programa com o

objetivo de verificar sua conformidade em relação aos

requisitos especificados.

(7)

Porque Testamos?

para

verificar

se o software está fazendo o que foi

pedido que ele fizesse num requisito;

para

tentar

evitar que o negócio corra riscos

provocados por defeitos em produção;

(8)

Ausência de Bugs?

Conformidade com os Requisitos? Satisfação do Cliente?

Bem, qualidade pode ser considerado tudo isso, ou simplesmente

como “fazer as coisas certas ao fazer as coisas certas”.

Isso significa que não adianta não ter bugs se o produto não atende

as expectativas dos usuários.

Com qualidade não queremos bugs, mas também não queremos um

produto cujas features não sejam o que o usuário esperava.

8

(9)

Definição:

Qualidade

do

Software

é

um

conjunto

de

características

que

devem

ser

alcançadas

em

determinado grau

para que o produto atenda as

necessidades do seu usuário. [Ana R. C. Rocha 2001]

No desenvolvimento de software, a qualidade do

produto está diretamente relacionada à qualidade do

processo de desenvolvimento, desta forma, é comum

que a busca por um software de maior qualidade passe

necessariamente por uma melhoria no processo de

desenvolvimento.

(10)

Melhores processos

10

OBJETIVO

Melhorar

Melhorar os processos para melhorar os produtos

os processos para melhorar os produtos

(bens e serviços)

Melhores produtos

PRINCÍPIO BASE DOS MODELOS DE QUALIDADE

(11)

Foco na evolução da área de teste para

níveis mais altos de maturidade e de

qualidade.

(12)

O propósito da Norma ISO/IEC 29119 Software Testing é

oferecer um padrão definitivo para o ciclo de vida

completo de teste de software.

Esta norma apoiará testes de qualquer projeto de

teste para software em desenvolvimento ou em

manutenção.

A Norma ISO/IEC 29119 Software Testing é dividida

em quarto partes:

Part 1: Definitions & Vocabulary

Part 2: Test Process

Part 3: Test Documentation

Part 4: Test Techniques

(13)

O que é Defeito?

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.

Fonte ISO 29.119

(14)

14

Fonte: Livro Software Testing, Ron Patton

Lembre-se do ditado: Se você não sabe dizerdizerdizerdizer o que quer, ninguém vai saber fazer fazer fazer o que fazer você quer.

(15)

(16)

1 6

A

tu

a

l

A

tu

a

l

A

tu

a

l

A

tu

a

l

(17)

O RUP é um framework de

processo iterativo e

incremental que provê uma abordagem disciplinada para o desenvolvimento de software

Possui duas dimensões:

O eixo horizontal representa o

aspecto dinâmico do processo e mostra as fases do ciclo de vida à medida que este se

desenvolve

O eixo vertical representa o

aspecto estático do processo, como ele é descrito em termos de disciplinas

As disciplinas fundamentais

do processo de

desenvolvimento de software também estão presentes na estrutura do RUP

O RUP é um framework de

processo iterativo e

incremental que provê uma abordagem disciplinada para o desenvolvimento de software

Possui duas dimensões:

O eixo horizontal representa o

aspecto dinâmico do processo e mostra as fases do ciclo de vida à medida que este se

desenvolve

O eixo vertical representa o

aspecto estático do processo, como ele é descrito em termos de disciplinas

As disciplinas fundamentais

do processo de

desenvolvimento de software também estão presentes na estrutura do RUP

RUP RUP RUP

(18)

Qual a diferença entre Projeto e Processo?

Projeto é um empreendimento temporário conduzido para criar um

produto ou serviço único. Fonte: Gerenciando Projetos de Teste de Software – Editora ArtImagem (baseado no PMI – Project Management Institute – PMBok 2008)

Processo – Na engenharia de software, o processo é uma sequencia de

atividades interligadas que 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. Fonte: Wikipédia

(19)

Teste é um

Projeto

?

Sim, teste deve ser um projeto independente do processo de

desenvolvimento, porém integrado.

(20)

Projeto x Processo

O teste também deve ser considerado um projeto; É importante termos um processo de teste;

(21)

Gerência de Requisitos

P l a n e j a m e n t o Desenho Lógico e Físico P l a n e j a m e n t o Especificação Validação Construção Elaboração CT e Execução Unitária Teste Unitário Implantação Execução Teste de Integração e de Sistema Entrega Entrega Teste de Aceitação Desenvolvimento _Teste

(22)

(23)

(24)

24

Planejar

Testes

Projetar

Testes

Executar

Testes

Analisar

Resultados

Gerenciar

Defeitos

Planejar

Testes

O Processo de Teste de Software está organizado em atividades que

baseadas em artefatos de entrada, controles e recursos, geram artefatos de saída.

(25)

...

Especificações de Caso de Uso

Modelo de caso de uso

Casos de Uso

Atores

Descrição do Problema (Doc Visão) Especificações Suplementares Glossário

Planejar

Testes

Requisitos de Teste

(26)

Para planejar os testes, devemos saber:

• O que

O que

pretendemos testar;

• Quando

Quando

iremos testar;

• Como

Como

iremos testar

Logo, precisamos ter definido a nossa

de teste.

Estrat

é

gia

Estrat

é

gia

26

Estratégia

(27)

Atividades Atividades Atividades Atividades: : : :

Verificar a testabilidade dos Casos de Uso ou dos Requisitos (qualidade

da documentação)

Fazer analise de risco do produto (estratégia do teste)

Definir o escopo do projeto e cenários de teste (o que testar)

Definir o critério de execução do teste (manual ou automatizada,

prioridades de execução e dependências)

Estimar o tamanho e o esforço (custo e tempo)

Definir os riscos do projeto de teste e os critérios de suspensão,

retomada e encerramento (quando parar de testar)

Configurar o ambiente de teste o local de armazenamento dos artefatos

do projeto (Pré condição do teste)

Planejar os recursos humanos do projeto (Recursos)

(28)

Defeitos Encontrados

Custo do Teste

Momento da Entrega?

Tempo

No inicio do projeto de teste devem ser feitos

acordos que permitam estabelecer quando os

testes deverão ser interrompidos.

(29)

(30)

“

Na sua máquina nunca funciona, na minha

funciona.”

“O que é que ele fez?????”

(31)

Eu quero Testar mas não sei por onde

começar...

Um bom começo seria

elaborar os casos de teste, com base nos requisitos e cenários de teste descrito no planejamento do projeto de teste.

(32)

32

Casos de Testes é um

conjunto

de condições usadas para:

• Encontrar defeitos na estrutura interna do software

• Garantir que os requisitos do software que foram construídos sejam plenamente atendidos.

(33)

(34)

34

Planejar

Testes

Projetar

_Testes

Testes

Executar

Testes

Analisar

Resultados

Gerenciar

Defeitos

Planejar

Testes

Cenários de Teste Cenários de Teste Cenários de Teste Cenários de Teste Casos de Teste Casos de Teste Casos de Teste Casos de Teste Procedimentos de Procedimentos de Procedimentos de Procedimentos de Teste TesteTeste Teste

(35)

Requisitos

Estratégia de Testes

Planos de Teste

Roteiros de Teste

Casos de Teste

Scripts ou procedimentos

de teste

Planejamento PlanejamentoPlanejamento

Planejamento EspecificaçãoEspecificaçãoEspecificaçãoEspecificação

Execução Execução Execução Execução Preparação Preparação Preparação Preparação Planejamento PlanejamentoPlanejamento Planejamento Especificação EspecificaçãoEspecificação Especificação

Etapas de

Suporte

Produtos

Etapas de

Realização

(36)

O projeto dos testes contempla a criação dos casos de teste 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. O grande foco desta atividade realmente é a

especificação dos casos e procedimentos de teste. Atividade:

Atividade: Atividade:

Atividade: Definir os cenários de teste Atividade:

Atividade: Elaborar Casos de Teste Atividade:

Atividade: Implementar Casos de Testes (automáticos ou manuais)

Atividade: Atividade: Atividade:

Atividade: Elaborar Procedimento de Teste

(37)

Descrição

Descrição:

:

O Analista de Teste com base nos requisitos de teste ou nos casos de uso, e usando o Plano de Teste como referência,

deve definir os Cenários de Teste e que servirão posteriormente para a elaboração dos Procedimentos (ou Roteiro) de Teste.

Responsáveis: Responsáveis: Responsáveis:

Responsáveis: Analista de Teste Participantes:

Participantes: Participantes:

Participantes: Analista de Sistemas, Testador Artefatos:

Artefatos: Artefatos:

Artefatos: Plano de Teste, Requisitos, Casos de Uso (testáveis) Ferramentas:

Ferramentas: Ferramentas:

(38)

Os casos de testes são derivados de uma

especificação formal que define os requisitos

◦

Requisitos de negócio, Casos de Uso, etc

Requisitos Casos de Uso Cenário de Teste Casos de Casos de Casos de Casos de Teste Teste Teste Teste 38

(39)

Atividade: Elaborar Casos de TesteElaborar Casos de TesteElaborar Casos de TesteElaborar Casos de Teste Descrição:

Descrição: Descrição:

Descrição: O Analista de Teste define e elabora os casos de teste baseados nas especificações dos casos de uso ou requisitos e em especificação suplementar (caso exista), tomando como base o Plano de Teste. . . .

Os testes não funcionais, caso existam, também devem estar definidos, nos casos de teste. Exemplo, teste de desempenho,.

Responsáveis: Analista de Teste Participantes:

Participantes: Analista de Sistemas, Testador Artefatos:

Artefatos: Plano de Teste, Requisitos, Casos de Uso, etc ... Ferramentas:

Ferramentas: Ferramentas:

(40)

Atividade: Elaborar Procedimentos de Teste (ou Roteiro de Teste) Atividade: Elaborar Procedimentos de Teste (ou Roteiro de Teste) Atividade: Elaborar Procedimentos de Teste (ou Roteiro de Teste) Atividade: Elaborar Procedimentos de Teste (ou Roteiro de Teste)

Descrição Descrição Descrição

Descrição: : : Os procedimentos de teste devem ser elaborados com o : intuito de manter a sequencia necessária para a execução dos casos de teste que se enquadrem nesta situação.

Responsáveis: Analista de Testes Participantes:

Participantes: Analista de Sistemas ,Testador Artefatos:

Artefatos: Casos de Teste, Procedimentos de Teste

Ferramentas: Ferramentas: Ferramentas:

(41)

A tarefa de elaboração do teste é coberta por 3 documentos:

Especificação Especificação Especificação

Especificação dededede Projeto/cenáriosProjeto/cenáriosProjeto/cenários deProjeto/cenários dedede TesteTesteTeste – Trata-se de umTeste detalhamento da abordagem apresentada no Plano de Teste e identifica as funcionalidades e características a serem testadas pelo projeto. Este documento também identifica os casos e os procedimentos de teste, se existirem, e apresenta os critérios de aprovação.

Especificação dedede Casode CasoCaso deCaso dedede TesteTesteTesteTeste – Define os casos de teste, incluindo dados de entrada, resultados esperados, ações e condições gerais para a execução do teste. Utilizaremos a nomenclatura de Plano de Caso de Teste para este documento gerado.

Especificação dododo Procedimentodo ProcedimentoProcedimentoProcedimento dededede TesteTesteTesteTeste – Identifica todos os passos necessários para operar o sistema e exercitar os Casos de Testes especificados, de maneira a cobrir o Projeto de Teste planejado. Os procedimentos de testes formam um documento separado com a intenção de que seja seguido passo a passo, sem ocorrências não previstas.

(42)

(43)

Planejar

Testes

Projetar

Testes

Executar

Testes

Analisar

Resultados

Gerenciar

Defeitos

Planejar

Testes

(44)

Macro Macro Macro

Macro ---- AtividadeAtividadeAtividade: Atividade: : Executar Testes: Executar TestesExecutar TestesExecutar Testes

Nesta macro-atividade serão executados os 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.

Após a conclusão da elaboração dos casos de teste e da liberação da baseline da versão do sistema para testes, inicia-se a execução dos testes.

O Testador executa os casos de teste, de acordo com o planejamento para cada iteração.

(45)

(46)

Planejar

Testes

Projetar

Testes

Executar

Testes

Analisar

Resultados

Gerenciar

Defeitos

Planejar

Testes

46 Requisitos

(47)

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.

Os defeitos devem ser classificados conforme as regras estabelecidas.

Atividade: Cadastrar Defeitos ou IncidentesCadastrar Defeitos ou IncidentesCadastrar Defeitos ou IncidentesCadastrar Defeitos ou Incidentes Atividade:

(48)

48

TestLink TestLinkTestLink

TestLink é um software web desenvolvido para teste de software que visa facilitar testes e assegurar a qualidade de software. Foi desenvolvido e mantido por varias equipes ao longo de sua existências. A plataforma oferece suporte para caso de teste, plano de teste, teste de unidade entre outros, também conta com suporte para relatórios e estatísticos. Possui como grande atrativo, ser acessado pela web, o que facilita a execução de testes por diversas equipes que estão separadas fisicamente.

TestLink possui suporte nativo para os bancos de dados My SQL e PostgreSQL. Contudo, seu funcionamento depende de arquitetura baseado na web.

(49)

Projetar

Testes

Mudança de um Requisito Requisito RequisitoRequisito Requisito Atualiza/Versiona os Casos de Testes Associados Teste Teste Teste Teste

(50)

(51)

(52)

(53)

Elaboração dos Casos de Teste para a revisão

da especificação

Checklist

“Recomenda

“Recomenda-

-

-se o uso de

-

se o uso de

templates

(54)

Assegura Qualidade, Testabilidade,

Completude,

Mensurabilidade das demandas, Entendimento dos Requisitos e

principalmente ANTECIPA PROBLEMAS

(55)

1. O Objetivo da especificação está de fácil entendimento?

2. Os Atores estão definidos?

3. Existem regras de navegabilidade em documentação Suplementar ou na

própria especificação?

4. Todas as exceções descritas estão sendo citadas no corpo da

especificação?

5. Todas as telas (protótipos), possuem detalhamento de atributos?

6. Todos os campos do tipo "combo","lista" e "caixa de seleção" estão definidos quanto a sua ordenação?

7. Todos os campos das telas estão definidos quanto a sua

obrigatoriedade de preenchimento?

(56)

9. Todos os campos das telas estão definidos quanto ao seu tipo?

10. Todos os campos que recuperam dados estão definidos quanto ao seu

valor padrão?

11. A seqüência lógica da especificação está bem descrita?

12. Todas as Regras de Negócio estão citadas ?

13. Todos os cenários possíveis estão descritos?

14. Todas as opções (Botões) da tela principal estão descritas como

fluxos?

15. A indentação está refletindo a correta funcionalidade ?

16. Todas os campos do tipo “data” estão sendo validados quanto ao

conteúdo, formato inválido e data inválida?

17. Todas as mensagens estão inteligíveis e corretamente descritas nas suas respectivas ações do sistema?

(57)

Relatório de Testabilidade Cliente

Projeto

Caso de Uso Analisado Responsável pela Análise

Nº Texto

Test center Projeto em Resposta ao teste

Sim Não N/A

Consideraçõe

s Sim Não Considerações

1

O objetivo e especificação está de facil entendimento?

2 Os atores estão definidos?

3

Existem regras de nvaegabilidade em documentação Suplementar ou na própria especificação?

4

Todas as exceções descritas estão sendo citadas no corpo da especificação?

5

Todas as telas (protótipos), possuem detalhamento de atributos?

6

Todos os campos do tipo "combo", "lista" e "caixa de seleção" estão definidos quanto a sua ordenação?

7

Todos os campos das telas estão definidos quanto a sua obrigatoriedade de preenchimento?

8

Todos os campos das telas estão definidos quanto ao seu tamanho?

9

Todos os campos das telas estão definidos quanto ao seu tipo?

Checklist ChecklistChecklist Checklist

(58)

(59)

Requisitos Requisitos Requisitos Requisitos Iteração Iteração Iteração

Iteração ImplementaçãoImplementaçãoImplementaçãoImplementação Configurações ConfiguraçõesConfigurações Configurações

Caso de Teste

O que O que O que

O que motivou o meu teste ?motivou o meu teste ?motivou o meu teste ?motivou o meu teste ?

Quando QuandoQuando

Quando devo testar ?devo testar ?devo testar ?devo testar ? Como Como Como Como devo testar ?devo testar ?devo testar ?devo testar ?

Onde Onde Onde

(60)

Em um Caso de Uso de Transferência Bancária, um dos

cenários é a Transferência

“DOC para conta de

terceiros”.

(61)

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:

Pré Condição

Estar logado internet bank e existir Banco e Conta Corrente de origem

Passos

1. Selecionar opção de “Transferência”

2. Preencher Dados Destinatário

• Código do Banco

• Agência

• Conta Corrente

• CPF do Destinatário

• Valor

3. Verificar o saldo da conta de origem,

4. Transferir o valor da conta origem para conta destino,

4. Consultar novamente o saldo da conta origem, verificando que o saldo

inicial menos o valor transferido é igual ao saldo atual,

(62)

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

· CT04 Transferência de valores negativos

e muitos outros

(63)

O Sistema apresenta

Preencher o campo número de confirmação com um número inválido

(64)

Considere as seguintes situaçõesConsidere as seguintes situaçõesConsidere as seguintes situaçõesConsidere as seguintes situações::::

1 – Um Sistema web com os seguintes requisitos não-funcionais: • Deve operar em diferentes Browsers

• Deve poder usar diferentes plug-ins

• Rodar em diferentes sistemas operacionais nas máquinas clientes • Deve receber páginas por diferentes servidores

• Deve rodar em diferentes servidores

Exemplo de Caso de Exemplo de Caso de Exemplo de Caso de Exemplo de Caso de testetestetesteteste

• Testar o requisito funcional – Manter Usuário

O sistema deveO sistema deveO sistema deveO sistema deve::::

- incluir usuário - alterar usuário - excluir usuário

(65)

Funcionalidade – Uma das funcionalidades

Incluir usuário

.

- um dos Testes:

PassoPassoPassoPasso: Preencher a tela de usuário com seus campos obrigatórios e

selecionar a opção incluir.

Resultado esperadoResultado esperadoResultado esperadoResultado esperado: Mensagem de Incluído com sucesso. Ambiente de testeAmbiente de testeAmbiente de testeAmbiente de teste:

Máquina cliente com sistema operacional windows 2000, utilizando o Internet explorer 6.0 como Browser, recebendo

páginas de um servidor com IIS e ter um servidor de Websphere em Linux.

(66)

(67)

• Não testar tudo, simplesmente desistir por causa do número elevado de combinações;

• Testar todas as combinações possíveis (elevado custo e tempo);

• Escolher uma ou duas combinações e torcer para ter sido uma boa escolha;

• Escolher o teste mais fácil, ignorando os mais usados e que agreguem mais valores; • Fazer uma lista de todas as combinações possíveis e escolher as mais importantes; • Fazer uma lista de todas as combinações possíveis e escolher subconjuntos

randomicamente;

• Escolher um subconjunto que possa ser o mais provável de se encontrar mais defeitos