Workshop de Testes Conceitos Básicos

Apresentação em tema: "Workshop de Testes Conceitos Básicos"— Transcrição da apresentação:

1 Workshop de Testes Conceitos Básicos
PROSOFT Workshop de Testes Conceitos Básicos Daniel Leitão Juliana Xavier Setembro/ 2010

2 Agenda Histórico Definições Dimensões do Teste Casos de Teste
Estágios Técnicas Tipos Casos de Teste Testes Exploratórios 2

3 Histórico Visão Histórica da Execução dos Testes
Demonstração – Década de 70 Garantir que o produto funciona; Testes feitos pelos desenvolvedores. Detecção – Década de 80/90 Garantir que o produto atende aos requisitos; Testes feitos pelos desenvolvedores e usuários. Prevenção – Década de 90/00 Garantir que o produto funciona, atende aos requisitos e não tem defeitos; Testes feitos pelos desenvolvedores, usuários e testadores.

4 Definições “É um processo de exercitar um software ou componente sob condições específicas, observando ou gravando os resultados, e realizando uma avaliação sobre algum aspecto”. (IEEE) “Processo de executar um programa ou sistema com a intenção de encontrar defeitos”. (Glen Myers, 1979) “Qualquer atividade que a partir da avaliação de um atributo ou capacidade de um programa ou sistema seja possível determinar se ele alcança os resultados desejados” (Bill Hetzel, 1988) A primeira definição se refere ao teste negativo

5 Importância dos Testes
PMBOK, 2008

6 Regra 10 de Myers Regra 10 de Myers Custo em U$ do defeito
12000 10000 8000 6000 4000 2000 The Art of Software Testing – Glenford Myers

7 Regra 10 de Myers The Art of Software Testing – Glenford Myers
O custo aumenta aproximadamente em 10x de uma fase para outra. The Art of Software Testing – Glenford Myers

8 Importância dos Testes
Para quem ainda duvida veja o que Myers afirmou Os testes unitários podem remover entre 30% e 50% dos defeitos dos programas Os testes de sistemas podem remover entre 30% e 50% dos defeitos remanescentes Dessa forma, os sistemas podem ir para produção ainda com aproximadamente 49% de defeitos Por último, ele afirma que revisões de código podem ainda reduzir entre 20% e 30% desses defeitos

9 Importância dos Testes
Por que os testes executados pelos desenvolvedores não atendem? Desenvolvedores não são técnicos de teste, ou seja, não são testadores Desenvolvedores são mais sujeitos a pressões de prazo e custo do que uma equipe apartada Em geral, não possuem ferramentas, metodologia etc.

10 Importância dos Testes
Quanto mais crítico for o software Mais testes serão gastos para o controle da qualidade do produto Logo, quem define a quantidade de testes é a criticidade do negócio 10

11 Papel do Testador É tudo na limpeza!

12 Garantia de Qualidade x Controle de Qualidade
Garantia da Qualidade de Software Foco no processo Prevenção Controle de Qualidade de Software Foco no produto Detecção CMMI

13 Controle de Qualidade Está relacionado a um produto ou serviço específico Verifica se um produto ou serviço específico tem um atributo específico Identifica defeitos com o propósito principal de corrigi-los A disciplina de testes está nesse âmbito

14 Garantia de Qualidade Ajuda a estabelecer e avaliar processos
Identifica fraquezas em processos e os aperfeiçoa Avalia se o controle de qualidade está funcionando SEPG e Equipe de Qualidade estão nesse âmbito

15 Dimensões do Teste (IEEE)
Técnica de Teste (como testar) Tipos de Teste (o que testar) Estágios ou Níveis de Teste (quando testar)

16 Estágios de Teste Unidade Integração Sistema Aceitação

17 Teste Unitário Estágio mais baixo da escala de testes
Verifica o funcionamento de um pedaço do software que possa ser testado isoladamente Falar da ferramenta Junit, PHPUnit.

18 Teste Unitário Sempre que possível, deve ser automatizado
Normalmente feito pelo programador na etapa de implementação Falar da ferramenta Junit, PHPUnit.

19 Teste de Integração Verifica se os componentes funcionam corretamente juntos, conforme as especificações É alimentado pelos módulos previamente testados individualmente pelo teste de unidade

20 Teste de Integração Em geral, é feito ao término de cada iteração, dentro de um ambiente operacional controlado Normalmente feito pelo Analista de Sistemas para um módulo ou conjunto de programas

21 Teste de Sistema Visa a execução do sistema como um todo ou um subsistema (parte do sistema), dentro de um ambiente operacional controlado

22 Teste de Sistema Valida a exatidão e perfeição na execução das funções
São realizados pela Equipe de Testes

23 Teste de Aceitação Verifica se a solução atende aos objetivos do negócio e a seus requisitos, no que diz respeito à funcionalidade e usabilidade, antes da utilização no ambiente de produção

24 Teste de Aceitação São os testes finais da execução do sistema, realizados pelos usuários Executado no ambiente de homologação Falar que o objetivo é achar erros de requisitos

25 Modelo em V CRAIG e JASKIEL, 2002
Figura 3. Modelo V descrevendo o paralelismo entre as atividades de desenvolvimento e teste de software (CRAIG e JASKIEL, 2002) Modelo em V CRAIG e JASKIEL, 2002

26 Técnicas de Teste

27 Testes Caixa Preta Visam verificar a funcionalidade e a aderência aos requisitos em uma ótica externa ou do usuário Não se baseiam em qualquer conhecimento do código ou da lógica interna do componente testado 27 27

28 Testes Caixa Branca Visam avaliar as cláusulas de código, a lógica interna do componente codificado, as configurações e outros elementos técnicos Também conhecidos como Testes de Caixa de Vidro 28 28

29 Tipos de Teste RUP 29

30 Funcionalidade Teste Funcional Teste de Regressão Teste de Volume
Teste de Segurança

31 Funcionalidade Teste Funcional
Teste destinado a validar as funções do sistema conforme o esperado Fornece as entradas e compara as saídas da execução do teste com o resultado esperado Pode ser implementado e executado em diferentes estágios de teste, como unidade, integração e sistema

32 Funcionalidade Teste de Regressão
Visam garantir que mudanças realizadas não geraram impactos negativos no sistema Existem vários níveis de regressão Regressão Total Regressão Básica Regressão Seletiva Em geral, sempre que possível devem ser automatizados

33 Funcionalidade Teste de Volume
Tem como objetivo verificar a capacidade do sistema de lidar com um grande volume de dados Abrange estratégias de teste, como a entrada de dados no volume máximo de cada campo ou a criação de consultas que retornem um grande volume de dados Exemplos: Relatórios com o período máximo permitido (1 ano, 2 anos etc) Inserção de arquivos no BD com o tamanho máximo permitido (500 MB, 1 GB etc) Exemplos de inclusão de imagens com tamanho máximo nos arquivos do BD.

34 Funcionalidade Teste de Segurança
Testes destinados a garantir que as funcionalidades e os dados possam ser acessados apenas por determinados atores Devem validar os requisitos de segurança definidos para o sistema Objetivos Detectar vulnerabilidades Verificar robustez do sistema frente a determinados tipos de ataques CID Tipos de Ataque = SQL Injection

35 Usabilidade Testes de Usabilidade
Enfatizam: Interface com o usuário Acessibilidade Estética Ajuda on-line e contextual Adequação a padrões Não esquecer de utilizar o padrão de interface visual do TJPE !!!

36 Confiabilidade Teste de Integridade Teste de Estrutura
Teste de Estresse Teste de Fumaça (Smoke Test)

37 Confiabilidade Teste de Integridade Teste de Estrutura
Testes destinados a avaliar a robustez do sistema (resistência a falhas) Pode ser implementado e executado em vários níveis (unidade, integração, sistema) Teste de Estrutura Em geral, é executado em aplicativos Web Verifica se todos os links estão conectados, que o conteúdo esperado é exibido e que não há link órfão

38 Confiabilidade Teste de Estresse Teste de Fumaça (Smoke Test)
Destinado a avaliar como o sistema responde em condições anormais de uso O estresse no sistema pode abranger carga de trabalho extrema, memória insuficiente, hardware e serviços indisponíveis ou recursos compartilhados limitados Teste de Fumaça (Smoke Test) Executam testes básicos para verificar a estabilidade da versão Podem ser executados pela equipe de testes ou por outra equipe

39 Desempenho Teste de Carga
Tipo de teste de desempenho usado para validar a aceitabilidade dos limites operacionais de um sistema de acordo com cargas de trabalho variáveis, enquanto a configuração permanece constante Durante os testes de carga, vários atributos do sistema são medidos Tempo de resposta de cada requisição, uso da CPU, uso da memória, tráfego de rede, etc Mostrar o relatório do SICASE

40 Suportabilidade Teste de Configuração Teste de Instalação
Teste destinado a garantir que o sistema funcione conforme o esperado em diferentes configurações de hardware e/ou software Exemplos: Navegadores, Servidores de Aplicação, Banco de Dados, etc Teste de Instalação Teste destinado a garantir que o sistema seja instalado conforme o esperado em diferentes configurações de hardware e/ou software Configuração, o sistema já está funcionando. E instalação, é testar o processo de instalação.

41 Casos de Teste É um conjunto de entradas de teste, condições de execução e resultados esperados desenvolvidos para um objetivo específico Os casos de testes funcionais devem conter: Identificação Única (Ex: CT001) Objetivo Pré-condições Passos (Ação e Resultado Esperado) Pós-condições

42 Casos de Teste Em geral, estão associados a um requisito Podem ser:
Positivos: têm como objetivo demonstrar que o requisito foi atendido Negativos: refletem uma condição ou dados inaceitáveis, anormais ou inesperados para demonstrar que o sistema responde da forma esperada NEGATIVOS: Entradas fora do domínio, excluir usuário inexistente, etc

43 Derivação de Casos de Teste
Os casos de teste funcionais são derivados a partir dos cenários dos casos de uso

44 Derivação de Casos de Teste
Passos para derivação dos casos de teste (Heumann) : Para cada caso de uso, gerar uma lista de cenários Para cada cenário, identificar, ao menos, um caso de teste e a condição que o farão ser executado Para cada caso de teste, identificar os dados que serão utilizados

45 Casos de Teste Exemplo:

46 Testes Exploratórios O que são testes exploratórios?
“Testes em que o testador controla ativamente o design dos testes durante a execução e utiliza informações adquiridas para projetar novos e melhores testes” James Bach, “Exploratory Testing Explained”

47 Testes Exploratórios Simultaneamente Aprender sobre o produto
Aprender caminhos em que o produto falha Aprender os pontos fracos do produto Aprender como testar o produto Testar o produto Reportar problemas Desenvolver novos testes com o que foi aprendido até o momento

48 Testes Exploratórios Todo testador pratica exploração em algum nível
Desde os testes com roteiro aos testes ad-hoc Em que nível o seu teste é exploratório?

49 Testes Exploratórios Como funciona
Durante um período de tempo (sessão), o testador interage com o produto para executar uma “missão de teste” e reportar os resultados Sessão Tempo Testador Produto Missão Relatório

50 Testes Exploratórios Sessão
O testador recebe uma cartilha (fornecida pelo líder de testes) que contém a missão e, possivelmente, táticas a serem usadas Em algumas organizações, casos de testes e procedimentos podem ser usados como cartilhas Não deve ser muito longa Depende do objetivo da sessão, mas uma sessão típica dura em torno de 90 minutos

51 Testes Exploratórios Sessão É uma unidade básica de teste
Deve ser ininterrupta s, telefonemas, conversas devem ser evitados Revisável Para isso, o relatório deve estar em um formato possível de ser entendido por terceiros (o gerente do projeto, por exemplo)

52 Testes Exploratórios Exemplo de cartilha
Teste todos os campos de entrada da tela “Inserir Produto”. Lembre-se de testar limites e dados inválidos. A primeira frase estabelece a missão A segunda, táticas a serem usadas

53 Testes Exploratórios Possível formato para relatório de sessão
Cartilha Testador Data/Hora Observações Bugs Questionamentos

54 Testes Exploratórios Habilidades Projetista de testes Observador
Todo testador exploratório é, em primeira instância, um projetista / arquiteto de testes Observador Testadores experientes diferem de novatos por perceberem mais facilmente comportamentos “não usuais” Crítico Um bom testador deve ser capaz de revisar e explicar sua lógica de achar um bug

55 Testes Exploratórios Habilidades Crítico Explorador de recursos
Testadores experientes tendem a usar mais heurísticas para produzir novas e melhores idéias Explorador de recursos Um bom testador deve estar munido de ferramentas, informações e ter contato com pessoas que possam ajudar

56 Testes Exploratórios X Testes com Roteiro
Conhecimento do domínio Com roteiros Falta de conhecimento pode ser minimizado durante a fase de projeto de testes Com exploração Não é possível prosseguir quando o conhecimento do domínio é insuficiente Treinamentos podem ser utilizados, mas introduzem overhead

57 Testes Exploratórios X Testes com Roteiro
Complexidade do Sistema Com roteiros Possibilita um projeto de testes cuidadoso que se preocupa com as dependências entre os testes Com exploração Reside na experiência do testador para gerenciar as dependências entre os testes

58 Testes Exploratórios X Testes com Roteiro
Nível de documentação Com roteiros Requer vasta e boa documentação Com exploração Não requer documentação (assumindo grande conhecimento do domínio)

59 Testes Exploratórios X Testes com Roteiro
Prazos Com roteiros Requer tempo para preparação Com exploração Não requer grande tempo inicial para preparação

60 Testes Exploratórios X Testes com Roteiro
Recursos Disponíveis Com roteiros Requer maior consumo de recursos (mais pessoas) Com exploração Ideal quando há limitação grande de recursos

61 Testes Exploratórios X Testes com Roteiro
Habilidades Necessárias Com roteiros Requer grande habilidade dos envolvidos na análise e projeto dos testes; na execução, pode usar testadores com poucas habilidades Com exploração Requer testadores habilidosos na arte da exploração

62 Testes Exploratórios X Testes com Roteiro
Cobertura Com roteiros Há rastreabilidade entre os testes e os requisitos / especificações que os originaram. Dessa maneira, pode-se calcular a cobertura Com exploração Não há como calcular a cobertura de maneira precisa

63 Testes Exploratórios X Testes com Roteiro
Verificação Com roteiros Verifica formalmente se o sistema está de acordo com a sua especificação Com exploração O sistema é comparado apenas com as expectativas e o entendimento do testador sobre o que a aplicação deveria fazer

64 Testes Exploratórios X Testes com Roteiro
Facilidade de reprodução Com roteiros Pode ser facilmente reproduzido Com exploração Apenas defeitos podem ser reproduzidos, os testes não.

65 Dúvidas | Sugestões SEPG: dinfo.sepg@tjpe.jus.br
Mantis: “Processo de Software” UTS: Telefone: 65

66 Workshop de Testes Conceitos Básicos
PROSOFT Workshop de Testes Conceitos Básicos Daniel Leitão Juliana Xavier Setembro/ 2010