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

Transcrição

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

2 APRESENTAÇÃO MARCIA SILVA 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 Teste de Software 2

3 Nome e expectativas; Atividades atuais; Experiências profissionais; Motivações; 3

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 ) 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 4

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. 5

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. 6

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; para tentar assegurar a qualidade do software; 7

8 O que é Qualidade? 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. 9

10 PRINCÍPIO BASE DOS MODELOS DE QUALIDADE Melhores processos Melhores processos OBJETIVO Melhores produtos Melhorar os processos para melhorar os produtos (bens e serviços) 10

11 Foco na evolução da área de teste para níveis mais altos de maturidade e de qualidade. 11

12 O propósito da Norma ISO/IEC 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 Software Testing é dividida em quarto partes: Part 1: Definitions & Vocabulary Part 2: Test Process Part 3: Test Documentation Part 4: Test Techniques 12

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

14 Lembre-se do ditado: Se você não sabe dizer o que quer, ninguém vai saber fazer o que você quer. Fonte: Livro Software Testing, Ron Patton 14

15 15

16 Atual 16

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 RUP- Rational Unified Process 17

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 18

19 Sim, teste deve ser um projeto independente do processo de desenvolvimento, porém integrado. Teste é um Projeto? 19

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

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

22

23

24 O Processo de Teste de Software está organizado em atividades que baseadas em artefatos de entrada, controles e recursos, geram artefatos de saída. Planejar Planejar Testes Testes Projetar Testes Executar Testes Analisar Resultados Requisitos Plano de Teste Gerenciar Defeitos 24

25 Especificações Suplementares Descrição do Problema (Doc Visão) Glossário Modelo de caso de uso Atores Casos de Uso Planejar Testes Requisitos de Teste... Especificações de Caso de Uso

26 Estratégia de Teste Para planejar os testes, devemos saber: O que pretendemos testar; Quando iremos testar; Como iremos testar Logo, precisamos ter definido a nossa Estratégia de teste. 26

27 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) Detalhar o Planejamento das Atividades de Teste (Cronograma)

28 No inicio do projeto de teste devem ser feitos acordos que permitam estabelecer quando os testes deverão ser interrompidos. Defeitos Encontrados Momento da Entrega? Custo do Teste Tempo 28

29 29

30 Na sua máquina nunca funciona, na minha funciona. O que é que ele fez????? 30

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. 31

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. 32

33

34 Planejar Planejar Testes Testes Projetar Testes Executar Testes Analisar Resultados Cenários de Teste Casos de Teste Procedimentos de Teste Gerenciar Defeitos 34

35 Etapas de Suporte Produtos Etapas de Realização Preparação Planejamento Requisitos Estratégia de Testes Planos de Teste Roteiros de Teste Casos de Teste Scripts ou procedimentos de teste Planejamento Especificação Especificação Execução 35

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: Definir os cenários de teste Atividade: Elaborar Casos de Teste Atividade: Implementar Casos de Testes (automáticos ou manuais) Atividade: Elaborar Procedimento de Teste 36

37 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: Analista de Teste Participantes: Analista de Sistemas, Testador Artefatos: Plano de Teste, Requisitos, Casos de Uso (testáveis) Ferramentas: Precisam ser definidas

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 Casos de Teste Requisitos Cenário de Teste Casos de Uso 38

39 Atividade: Elaborar Casos de Teste 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: Analista de Sistemas, Testador Artefatos: Plano de Teste, Requisitos, Casos de Uso, etc... Ferramentas: Precisam ser definidas 39

40 Atividade: Elaborar Procedimentos de Teste (ou Roteiro de Teste) 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: Analista de Sistemas,Testador Artefatos: Casos de Teste, Procedimentos de Teste Ferramentas: Precisam ser definidas

41 A tarefa de elaboração do teste é coberta por 3 documentos: Especificação de Projeto/cenários de Teste Trata-se de um 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 de Caso de Teste 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 do Procedimento de Teste 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. A Norma IEEE Std (IEEE Standard for Software Test Documentation) descreve um conjunto de documentos para as atividades de teste de um projeto de software. 41

42

43 Planejar Planejar Testes Testes Projetar Testes Executar Testes Analisar Resultados Gerenciar Defeitos 43

44 Macro - Atividade: Executar 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 Planejar Testes Testes Projetar Testes Executar Testes Analisar Resultados Requisitos Gerenciar Defeitos 46

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 Incidentes Atividade: Monitorar Defeitos 47

48 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. 48

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

50 50

51 51

52

53 Elaboração dos Casos de Teste para a revisão da especificação Checklist Recomenda-se o uso de templates para a revisão 53

54 Assegura Qualidade, Testabilidade, Completude, Mensurabilidade das demandas, Entendimento dos Requisitos e principalmente ANTECIPA PROBLEMAS 54

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? 8. Todos os campos das telas estão definidos quanto ao seu tamanho? 55

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

57 Cliente Projeto Caso de Uso Analisado Responsável pela Análise Nº Texto O objetivo e especificação está de facil 1 entendimento? 2 Os atores estão definidos? Existem regras de nvaegabilidade em documentação Suplementar ou na própria 3especificação? Todas as exceções descritas estão sendo citadas 4no corpo da especificação? Todas as telas (protótipos), possuem 5detalhamento de atributos? Todos os campos do tipo "combo", "lista" e "caixa de seleção" estão definidos quanto a sua 6ordenação? Todos os campos das telas estão definidos 7quanto a sua obrigatoriedade de preenchimento? Todos os campos das telas estão definidos 8quanto ao seu tamanho? Todos os campos das telas estão definidos 9quanto ao seu tipo? Análise de Testabilidade Todos os campos que recuperam dados estão 10definidos quanto ao seu valor padrão? Relatório de Testabilidade Test center Projeto em Resposta ao teste Sim Não N/A Consideraçõe s Sim Não Considerações Checklist Testabilidade Caso de Uso

58

59 O que motivou o meu teste? Onde devo testar? Requisitos Configurações Caso de Teste Iteração Implementação Quando devo testar? Como devo testar? 59

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, 5. Imprimir comprovante de transferência 61

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 62

63 Preencher o campo número de confirmação com um número inválido O Sistema apresenta uma mensagem 63

64 Considere 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 teste Testar o requisito funcional Manter Usuário O sistema deve: - incluir usuário - alterar usuário - excluir usuário

65 Funcionalidade Uma das funcionalidades Incluir usuário. - um dos Testes: Passo: Preencher a tela de usuário com seus campos obrigatórios e selecionar a opção incluir. Resultado esperado: Mensagem de Incluído com sucesso. Ambiente 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 Devido ao elevado número de possibilidades, temos então que encontrar um modo de escolher algum subconjunto suficientemente representativo para a nossa elaboração dos testes. A lista abaixo representa algumas dicas, iniciando das mais erradas a serem tomadas até as possíveis. 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 67

68 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.