137
Validação e Testes de Software Rondinelli Mesquita

Validação e Testes de software

Embed Size (px)

Citation preview

Validação e Testes de Software

Rondinelli Mesquita

About me

Rondinelli  Mesquita Developer | Tester | Coffee | Rock

•  Sistemas de Informação•  Esp. Desenv. Aplicativos Móveis•  Instituto Atlântico - Fortaleza

@[email protected]

rondymesquita.com.br

Skills

•  Java•  Android•  Javascript•  Automated Tests

IntroduçãoProcesso de Teste

Nível e Abordagem

de Teste

Papeis, Ambiente

1 2 3 4

PlanejamentoCasos de

Teste Técnicas Ferramentas

5 6 7 8

Bibliografia

Livro Base

https://stocksnap.io/photo/IA7B7S9TSW

O que NÃO é testar

“Testar é o processo de demonstrar que os erros não

estão presentes”

O que é realmente testar

“Testar é o processo de executar o programa com a intenção de

encontrar erros”(MYERS, BADGET e SANDLER, 2012)

Perfil de um Tester

Demonstrar que existem erros no software e auxiliar equipe na

resolução desse erro.

POR QUE TESTAR ?

Regra 10 de Myers

Custo da correção de defeitos: Extraído de Bastos; Rios; Cristalli; Moreira (2007)

Redução de defeitos •  Testes unitários podem remover entre 30%

e 50%•  Testes sistêmicos podem remover 30% e

50%•  Revisões de códigos podem reduzir entre

20% e 30%•  Mesmo assim, os sistemas podem ir para a

produção ainda com aprox. 49% de defeitos

Extraído de Bastos; Rios; Cristalli; Moreira (2007)

Ciclo de Vida do Software Um software pode ainda estar rodando mesmo depois de ter sido construído (10 anos…)

Riscos?

•  Falta de profissional especialista na tecnologia

•  Custo de parar o sistema que está rodando para corrigir um erro

Dev

Test

Dev Test

“Quanto menos defeitos deixarmos no software,

mais barata será sua manutenção” $  

Custo com Qualidade

Estimativas de custos de teste. Fonte: Extraído de Bastos; et al(2007)

O teste é iniciado junto com o

desenvolvimento!

Scrum

Processo Scrum. Fonte: Adaptado de Keith (2010)

!

Integração entre processos

Integração entre processos. Fonte: Extraído de Bastos; et al

(2007)

Mitos

“O Tester é inimigo do Desenvolvedor"

Mitos

“A equipe de testes pode ser montada com os

desenvolvedores menos qualificados, pois qualquer um pode testar sistemas”

Mitos

“Quando estiver tudo pronto, o software seguirá

para o pessoal fazer o teste.”

Como priorizar? Quais testes são importantes? •  Analisar os riscos e impactos– Requisito: tempo de resposta -> Teste de

performance

“É necessário ter uma metodologia estruturada de teste”

Verificação x Validação •  Verificação: realizar inspeções sobre os

artefatos gerados nas etapas do processo

•  Validação: Avaliar se o sistema atende aos requisitos

Definições de verificação e validação. Fonte: Extraído de Bastos, et al (2007)

Inspeção de código (verificação) O time inspeciona os artefatos produzidos à procura de possíveis erros. Importante existir um checklist.

Conduzindo por um desenvolvedor que não seja o autor do código

Ferramentas: PMD e FindBugs

(MYERS, BADGET e SANDLER, 2012)

Passo a passo (walkthrough) Geralmente informal, o autor do código apresenta o código para o time e o time faz sugestões.

(MYERS, BADGET e SANDLER, 2012)

Processo de Teste

https://stocksnap.io/photo/PBTF1NEBCG

Conceito “V” de teste

Conceito “V” de teste de software. Fonte: Extraído de Bastos, et al (2007)

Passos do Processo de Teste 1.  Acesso ao Plano de Desenvolvimento2.  Plano de Testes3.  Avaliação dos Requisitos do Software4.  Avaliação do Desenho5.  Inspeção da Construção do Software6.  Execução dos Testes

1.  Abordagem2.  Ferramentas3.  Tipos de Teste

Passos do Processo de Teste 7.  Teste de Aceitação

8.  Informação dos Resultados1.  Bugs

2.  Melhorias

9.  Teste de Instalação

10.  Teste das Mudanças

11.  Avaliação da Eficácia

Ciclo de vida de testes

1.  Planejamento2.  Preparação3.  Procedimentos Iniciais4.  Especificação5.  Execução6.  Entrega

Ciclo de vida de testes: Adaptado de Bastos, et al (2007)

Modelo 3P x 3E do Ciclo de Vida

Modelo 3P x 3E. Fonte: Extraído de Bastos, et al (2007)

https://stocksnap.io/photo/QNFDIZPFN6

Nível de Teste

Nível de Teste de Software •  Representa a que fase do desenvolvimento

se aplica um determinado teste.

– Teste de Unidade

– Teste de Integração

– Teste de Sistema (ou sistêmico)

– Teste de Aceitação

Teste de Unidade Estágio mais baixo da escala de teste

Feito pelos desenvolvedores

Testa as classes, métodos, funções, componentes isolando/simulando suas dependências

Teste de Unidade //JUnit Example

Discipline discipline = new Discipline();discipline.setName("Prog 1");discipline.setWorkload(120);

Assert.assertEquals("Prog 1", discipline.getName());

Teste de Unidade //JUnit Example

Calculator  calculator  =  new  Calculator();calculator.add(1,  2);  Assert.assertEquals(3,  calculator.getResult());

Teste de Integração Teste do sistema ao término de cada iteração.

Teste da integração entre os componentes.

Teste de Integração //JUnit Example

Discipline discipline = new Discipline();discipline.setName("Prog 1");discipline.setWorkload(120);

Assert.assertTrue(disciplineApplication.save(discipline));

Teste de Sistema Teste do sistema como um todo depois da integração dos componentes.

Utiliza um ambiente parecido ou igual ao ambiente real

Teste de Aceitação Verificar se o software está pronto para ser usado.

Verificar o comportamento do software

Feito no ambiente de homologação

Abordagem de Teste

https://stocksnap.io/photo/16VYGB9PG5

White box Se concentra do comportamento do software sem se deter a sua estrutura interna.

Verifica se o programa se comporta de acordo com suas especificações.

•  Teste Sistêmico•  Teste de Aceitação

(MYERS, BADGET e SANDLER, 2012)

Black Box Testa a estrutura interna, a lógica do software.O critério de busca é o Teste do Caminho, testando os possiveis caminhos que o software pode tomar.

•  Teste unitário•  Teste de Integração

(MYERS, BADGET e SANDLER, 2012)

https://stocksnap.io/photo/VQXYE2ZEHC

Papeis

Papeis do Processo de Teste Papel Responsabilidade

Gerente de Teste Responsável pela área de teste na empresa

Líder do Projeto de Teste Líder do time de testes

Arquiteto de Teste Montagem de Infra-estrutura e ambiente, ferramentas, preparação do time

Profissionais do processo de teste. Fonte: Adaptado de Bastos, et al (2007)

Papeis do Processo de Teste Papel Responsabilidade

Analista de Teste Elaboração dos casos e scripts de teste

Testador Execução dos casos de teste e scripts de teste

Profissionais do processo de teste. Fonte: Adaptado de Bastos, et al (2007)

https://stocksnap.io/photo/DUGHLO7780

Ambiente

Ambiente •  Toda a estrutura onde os testes serão

executados– Ambiente físico

– Pessoal

– Hardware

– Software

– Suprimentos

– Rede

– Documentação

Ambiente Ao definirmos o ambiente de teste devemos considerar:•  OS•  Arquitetura do sistema•  Identificação dos componentes•  Meio de acesso ao sistema•  Linguagem de programação•  Conectividade entre ambientes

(RIOS e MOREIRA, 2003, apud BASTOS el al., 2007)

https://stocksnap.io/photo/QKNVDENHQP

Planejamento e Documentação

Documentação •  Plano de Testes– Planejamento para a execução dos testes,

abrangência, abordagem, níveis, ambientes, recursos e técnicas.

•  Especificação de Caso de Teste– Define os cenários com entradas, saídas,

resultados esperados e condições para a execução.

Plano de Testes •  Descreve quais testes serão executados e

como será feita a execução

– Escopo

– Ambiente

– Abordagem

– Nível

– Técnicas

Plano de Testes – Artefatos liberados

– Responsabilidade

– Cronograma

– Critérios de completude

Requisitos do Projeto à Plano de Testes

Brainstorm

https://stocksnap.io/photo/84GOP2OAKR

Procedimentos de Teste

https://stocksnap.io/photo/84GOP2OAKR

Procedimentos de Teste “…os testes devem ser executados em todas as etapas do ciclo de vida do processo de desenvolvimento de software, desde os requisitos até o teste de aceitação, na fase de homologar e liberar o software para a produção.”

(BASTOS el al., 2007)

Procedimentos de Teste •  Plano de teste sempre atualizado.•  Responsabilidades

Teste UnitáriosFeito pelos desenvolvedores

Teste de IntegraçãoFeito quando os componentes a ser integrados já tiverem seus testes unitários feitos.

Procedimentos de Teste Teste de Sistema–  Ambiente deve se aproximar do ambiente de

produção

–  Definir quais casos de teste serão empregados nessa fase

–  Avaliar os resultados dos testes e identificar problemas encontrados

–  Registro de defeitos

–  Garantir que usuários finais não encontrem erros grosseiros

Procedimentos de Teste Teste de Aceitação–  Realizado pelos usuários do software para

garantir que tudo que foi definido tenha sido de fato implementado.

Procedimentos de Teste Quando parar de testar?

•  Métricas– Tempo médio entre defeitos encontrados

– Porcentagem de cobertura alcançada

– Número de defeitos encontrados que não foram corrigidos dependendo do seu grau de severidade

Procedimentos de Teste Construir casos de

teste

Executar os testes

Registrar os resultados dos testes

Identificar a natureza dos problemas e

retrabalhar o teste

Foram encontra

dos defeitos

Os testes foram

executados corretame

nte?

Construir casos de

teste

Ambiente

Plano de Teste

Softwares de Teste

Documentação

Relatórios

Fluxo de execução dos testes. Fonte: Adaptado de Bastos, et al (2007)

Casos de Teste User Stories e BDD

https://stocksnap.io/photo/84GOP2OAKR

Casos de Teste Detalhamento das interações com a aplicação. Estabelece quais as informações empregadas e os resultados.

– Cenários

– Pré-condição

– Pós-condição

– Critério de aceitação

Casos de Teste – Configuração de ambiente– Manual/Automatizada– Dependências

Características– Efetivo– Econômico– Reutilizável– Rastreável– Auto-explicativo

Casos de Teste

Fluxo de caso de uso. Fonte: Extraído de Bastos, et al (2007)

User Story •  Representa uma funcionalidade/

caracteristica do produto narrada pelo cliente.

•  São as necessidades do cliente, mostrando qual problema ele deseja resolver.

(COHN, 2004)

User Story Eu, como… (Papel)

Eu quero… (Necessidade)

Para… (Valor de negócio)

User Story - Exemplo [US_03] Realizar reserva

Como um usuário do sistema

Eu quero poder realizar a reserva de salas da minha instituição

Para facilitar o controle de reservas e evitar atrasos

!

BDD Behavior-driven development ou Desenvolvimento Orientado ao Comportamento.

Combina ideias do TDD e DDD e Projeto Orientado a Objeto que fornece ao time um processo compartilhado para o desenvolvimento do software

(YE, 2013)

BDD •  Linguagem ubiqua– Linguagem natural– Linguagem compartilhada

•  Foco no Minimum Markatable Feature•  Valor verificável para o negócio•  Requisitos aliado aos testes•  Baseado naquilo que se espera da

aplicação•  Documentação viva

BDD Dado que… (pré-condição)

Quando… (ação)

Então… (pós-condição)

BDD Dado que… (pré-condição)

E… (mais uma pré-condição)

Quando… (ação)

E… (mais uma ação)

Então… (pós-condição)

E… (mais uma pós-condição)

Cenário BDD - Exemplo [US_3] Realizar reserva

Como um usuário do sistema

Eu quero poder realizar a reserva de salas da minha instituição

Para facilitar o controle de reservas e evitar atrasos

!

Cenário BDD - Exemplo [TC_3.1] Realizar uma reserva com sucesso

Dado que eu estou na tela principalE seleciono a opção “Resevas”E preencho o campo “Responsável”E preencho o campo “Sala”E seleciono a dataE seleciono a horaQuando eu clico em “Finalizar”Então devo ver a mensagem “Reserva realizada com sucesso”

Brainstorm A saga continua

https://stocksnap.io/photo/84GOP2OAKR

Técnicas de Teste

https://stocksnap.io/photo/OXTQKWK4EJ

Técnicas de Teste •  Estrutural– Garantir que o software é sólido. Relacionados

as características do software.

•  Funcional– Garantir que o software atende aos requisitos.

https://unsplash.com/levisaunders

Estrutural

https://stocksnap.io/photo/08770132A3

Estresse

Estrutural – Teste de Estresse Avalia o software sob condições críticas.

•  Restrição de Memória

•  Processamento

•  Armazenamento

•  Volume de Dados

•  Tempo de Transação

Estrutural – Teste de Estresse Objetivos

•  Determinar que a aplicacao suporta volume de transação normal ou acima do normal num periodo de tempo esperado

•  Determinar que a aplicação suporta volume normal e continua a funcionar corretamente

Comuns em aplicações web

https://stocksnap.io/photo/LNYEQYRA6G

Execução

Estrutural – Teste de Execução Avalia o tempo de resposta, de processamento e desempenho.

•  Tempo de resposta das transações

Estrutural – Teste de Execução Objetivos

•  Determinar o tempo de resposta das transações

•  Determinar se hardware e software fornecem capacidade adequada

•  Código é executado com eficácia

https://stocksnap.io/photo/A129A7D04F

Recuperação

Estrutural – Teste de Recuperação •  Capacidade de reiniciar operacoes após a

perda de integridade.

•  Garantir a continuidade das operações após um erro.– Fatores

•  Volume de dados processados no momento do erro

Estrutural – Teste de Recuperação Objetivos– Verifica a eficácia e eficiência o processo de

recuperação

– Backup

– Documentar procedimentos de recuperação

https://stocksnap.io/photo/4B29F3D6ED

Operação

Estrutural – Teste de Operação Objetivos– Estabelecer se o sistema é executável durante a

operação normal

– Se os utilizadores do sistema conseguem utilizar-lo, utilizando a documentação preparada.

– Os utilizadores devem testar sem ajuda nenhuma

https://stocksnap.io/photo/D5E363D0E7

Conformidade

Estrutural – Teste de Conformidade •  Verifica se a aplicação foi desenvolvida de

acordo com os padrões de TI– Aumentar as chances de sucesso

– Transferência de conhecimento e curva de aprendizado

– Manutenibilidade

Estrutural – Teste de Conformidade Objetivos– Padrões de TI estão sendo seguidos e de forma

adequada

– Avalidar documentação

– Falta de conformidade foi falta de comunicação? Problema no processo? Padrões mal entendidos?

https://stocksnap.io/photo/AD76394B17

Segurança

Estrutural – Teste de Segurança •  Verificar a confidencialidade das

informações e proteção dos dados contra acesso indevido.– Segurança da Informação

– Defeitos difíceis de indentificar

Estrutural – Teste de Segurança Objetivos– Riscos?

•  Determinar as regras de acesso e se foram implementadas de acordo com as definições•  Verificar se as medidas de segurança foram

corretamente implementadas

– Riscos baixos, tecnicas de invasão usual: •  Pode-se realizar os testes

– Riscos altos, técnicas de invasão sofisticadas:•  Testes conduzidos por pessoal especializado

https://stocksnap.io/photo/E2C541A7DC

Funcional

https://stocksnap.io/photo/AD76394B17

Requisitos

Funcional – Teste de Requisitos Objetivos– Verificar se o sistema faz o que está

especificado nos requisitos.

– Verificação do comportamento do sistema

– Checklist de funcionalidades

– Normalmente os testes são preparados na fase de requisitos

http://pixabay.com/en/road-sign-roadsign-traffic-turning-145153/

Regressão

Funcional – Teste de Regressão •  Voltar a testar componentes já testados

após implementação de uma mudança em outra parte do software

Objetivos

– Determinar se a funções previamente testadas continuam funcionando após a introdução de mudanças no sistema

Funcional – Teste de Regressão Riscos–  Tempo e custo

•  Automação de Testes

Quando usar?

Quando os riscos de mudança do software são altos

http://pixabay.com/en/stop-shield-traffic-sign-road-sign-634941/

Tratamento de Erros

Funcional – Teste de Tratamento de Erros •  Verificar a capadicade do sistema de tratar

transações incorretas

Objetivos– Determinar as condições de erro e tratá-los

– Testar o erro e o acerto

https://stocksnap.io/photo/56A1C1BE07

Interconexão

Funcional – Teste de Interconexão •  Verificar a conectividade do software com

outros softwares– Sejam dados recebidos ou fornecidos

Objetivos– Verificar se os dados são recebidos e/ou

enviados corretamente

– Executar quando as entradas e saídas dos softwares relacionados mudarem

https://stocksnap.io/photo/WBDINSMDFO

Paralelos

Funcional – Teste Paralelo •  Teste de compatibilidade. Demonstrar

consistência e cincosistências entre versões do mesmo software

•  Mesmos dados de entrada funcionem em software de diferentes versões

Gestão de Defeitos

https://stocksnap.io/photo/AC169E486A

Gestão de defeitos •  Prevenção de defeitos•  Baselines•  Identificação•  Registro•  Solução do defeitos•  Melhoria do processo•  Relatório de gestão

(BASTOS et al., 2007)

Gestão de defeitos Jira

Gestão de defeitos

Ferramentas

https://stocksnap.io/photo/5304C4F098

Teste de Unidade

@Testpublic void sumTwoNumbers() {

Calculator calculator = new Calculator();calculator.add(1, 2);Assert.assertEquals(calculator.getResult(), 3);

}

http://junit.org

Teste de Unidade •  Ruby– Rspec: http://rspec.info

•  .Net– Nunit: http://www.nunit.org

Teste Funcional

Selenium

Testes Automatizados de aplicações web.

Teste Funcional •  Selenium: http://www.seleniumhq.org– Java

– C#

– Ruby

– Python

– JS(Node)

•  Ruby– Capybara: http://jnicklas.github.io/capybara/

Teste Funcional @Testpublic void doBingSearch() {

WebDriver driver = new FirefoxDriver();

driver.get("http://www.bing.com");

WebElement searchField = driver.findElement(By.id("sb_form_q"));

searchField.sendKeys("Transformers");

driver.findElement(By.id("sb_form_go")).click();

driver.getPageSource().contains("Imagens de transformers");}

Teste Funcional •  Calabash: http://calaba.sh – Android

–  IOS

•  Selendroid: http://selendroid.io – Android

Teste de Desempenho

•  Realiza testes de desempenho em aplicações web, webservices e páginas dinâmicas

122  

Meu softwareestá

rodando…

Mas o meu tem

testes!

Certificação de Testes

https://stocksnap.io/photo/DB7F22291B

CBTS Certificação Brasileira de Teste de Software

Criada pela ALATS (Associação Latino Americana de Teste de Software), procura estabelecer um padrão de conformidade para avaliação da qualificação dos profissionais da área da qualidade do software.

CBTS Certificação Brasileira de Teste de Software

Criada pela ALATS (Associação Latino Americana de Teste de Software), procura estabelecer um padrão de conformidade para avaliação da qualificação dos profissionais da área da qualidade do software.

E...

https://stocksnap.io/photo/2E7892A6E4

Livros recomendados sd

Livros recomendados sd

Livros recomendados sd

Livros recomendados sd

Links •  http://behaviourdriven.org

•  http://dannorth.net/introducing-bdd/

•  http://tableless.com.br/introducao-ao-behavior-driven-development/

•  http://junit.org

•  http://www.seleniumhq.org

•  https://www.atlassian.com/software/jira

•  http://www.alats.org.br/portal/home.html

Links •  http://aprendendotestar.webs.com

•  http://qualidade-de-software.blogspot.com.br

•  http://www.bstqb.org.br

•  http://guts-rs.blogspot.com.br

•  http://www.qualister.com.br

•  https://www.youtube.com/user/guru99com

•  https://github.com/rondymesquita

•  http://rondymesquita.com.br

About me

Rondinelli  Mesquita

@[email protected]

rondymesquita.com.br

Bibliografia •  BASTOS, Aderson, at al. Base de conhecimento em

teste de software. 2. ed. rev. São Paulo: Martins, 2007.

•  MYERS, Glenford J.; BADGET, Tom; SANDLER, Corey. The art of software testing. 3. ed. Wiley, 2012.

•  WATKINS, John. Agile testing: how to succeed an extreme testing environment. Cambridge, 2009.

•  YE, Wayne. Cucumber BDD how-to: A short guide to mastering behavior-driven software development with cucumber. Packt Publishing, 2013.

Bibliografia •  KEITH, Clinton. Agile game development with

scrum. Addison-Wesley, 2010.

•  COHN, Mike. User stories applied: for agile software development. Addison-Wesley, 2004.

Imagens Imagens extraídas de stocksnap.io.

Capa: https://stocksnap.io/photo/F164KBFZ95

Obrigado! :D