Testes de software

Design clássico e Ágil

KLEITOR

Lean SS Black Belt certified

Kanban Coach certified
Scrum Coach certified
Lean expert and QA specialist

Uma introdução.
Conheça: clipzen.blog

1 1
emphasize

Esta apresentação fornece visão

geral sobre testes, e enfatiza testes
funcionais no universo de times
ágeis.

2 2
Padronizando o vocabulário

Design clássico

Design Ágil

3 3
Padronizando o
vocabulário

4 4
 Qualidade

Qualidade como o "grau em que um conjunto de

características inerentes a um objeto atende aos requisitos".

Simplificando, a qualidade é atender aos requisitos do cliente

ISO 9000:2015: Quality management systems—Fundamentals and vocabulary

5 5
Garantia da qualidade
x
Controle da qualidade

6 6
Garantia da qualidade
Atividade proativa

-Prevenção do que perturba a qualidade

-Foco no processo e melhoria continua
-Como o processo e o produto é feito

7 7
Controle da qualidade

Mede, inspeciona,
examina

Ferramenta que a Garantia da Qualidade usa

para garantir o atendimento aos requisitos dos
Produtos ou Serviços.
http://academiaplatonica.com.br/2012/gestao/nbr-iso-90002005-3-2-11-garantia-da-
qualidade-sistema-de-gestao-da-qualidade-fundamentos-e-vocabulario/

8 8
A psicologia de testes

O que acreditamos que seja teste?

9 9
 O que é teste, para você?
O objetivo dos testes é agregar valor
o mais cedo possível ao produto

- Teste como atividade

- Começa na primeira captura de requisitos
- Não é sobre bug-zero
- É sobre obter um wow do cliente

10 10
O que é teste, para você?

- É sobre falhar o mais rápido possível

- Sua essência é enriquecer requisitos.
- Checar é o básico, validar é tudo

É sobre perceber o que

é importante pro
cliente.

11 11
Benefícios de testes

Teste fornece informação

-Que tipo de informação é necessária entregar e

aumentar a qualidade e reduzir riscos?
-Como evidenciar o benefício?
-Qual o tempo para evidenciar e fornecer
feedback?

12 12
Falha, erro, defeito e bug
Uma falha significa que um dado requisito não é
cumprido. Uma falha está presente se uma expectativa
não é conhecida.
Uma falha é causada por um defeito
ou erro interno no software,
cujo jargão é bug.

IEEE Standard 610.12,

Software Testing Foundations, 4ª edição

13 13
Níveis de teste

Componentes (unitarios),
integração, teste de sistema, teste
de aceitação, etc...

Os níveis são sequenciais ou

paralelos?

14 14
Níveis de teste

Componentes (unitários)

15 15
Níveis de teste

Integração: nível unitário, nível de

interface, End-to-end System
testing.

16 16
Tipos de teste

Funcional (caixa preta), inclui todos os tipos de

testes que verificam o comportamenteo de um
sistema. ISO 9126

17 17
Estruturais

Técnicas estruturais (testes baseados em

estrutura, teste de caixa branca).
Informações sobre a estrutura ou arquitetura de
código interno do objeto de teste.

18 18
Tipos de teste

Não funcional (performance, segurança,

usabilidade, etc). Não descrevem as funções, mas
atributos do comportamento funcional ou do
sistema. ISO / IEC 25010: 2011

19 19
Orientados a mudança

O objetivo é aferir se as mudanças não

causaram efeito indesejado.

Teste de confirmação( falhou da primeira vez),

Teste de regressão ( passou da primeira vez).

Se gerou comportamento indesejado ou

inesperado.

20 20
Perspectivas e
expectativas

21 21
PERSPECTIVAS

V&V – Validação e verificação de software

A validação verifica a conformidade com as expectativas de

qualidade do cliente.

A verificação verifica a conformidade da implementação do

produto de software contra a sua especificação para ver se foi
implementado corretamente.

V&V – Software verification and validation IEEE 1012

https://en.wikipedia.org/wiki/Software_verification_and_validation
https://en.wikipedia.org/wiki/Verification_and_validation

22 22
PERSPECTIVAS DE VALIDAÇÃO E VERIFICAÇÃO

-Validação: caixa-preta

-Verificação: caixa branca ( estrutural)

23 23
DESIGN
DE
TESTE

24 24
Desenho de teste

Técnicas estáticas: revisões, inspeções, auditoria de

código

Técnicas Dinâmicas: caixa-preta, Caixa-branca,etc.

Exemplos de técnicas de caixa-preta: partição por equivalência,

análise do valor do limite; tabelas de decisão, etc.

https://en.wikiversity.org/wiki/Software_testing/Design_technique

25 25
 Por que
desenhar
testes?

Não se pode cobrir tudo.

Cobrir estrategicamente
Amostras de valor

26 26
TÉCNICAS DE TESTE

É impossível um conjunto completo de testes para provar que

não há erros, a solução é mudar a abordagem de prova
absoluta para demonstração convincente, buscando mostrar
que a probabilidade de falhas mais críticas que hibernam
foram cobertas pelos casos de teste.

IDENTIFICAR BUGS, CENÁRIOS DE RISCOS

E NECESSIDADES DO CLIENTE

27 27
TÉCNICAS DE TESTE

Análise de valor limite

Técnica que busca limítrofes, ou seja, erros que ocorrem nas

fronteiras do domínio de entrada em vez de no centro.

28 28
TÉCNICAS DE TESTE

Análise de valor limite

Outros exemplos:

• Validar limites de expressões numéricas e datas:

>,>=,<,<=;
• Validar datas retroativas
• Validar arquivos cheios e vazios;
• Validar limite mínimo e máximo de parâmetros.
• Validar se cabeçalhos e rodapés estão aparecendo nos
limites superior e inferior;

29 29
 Exercício: Análise de valor limite

Uma escola quer cadastrar turmas e professores.

Uma turma pode ter aulas em salas teóricas e laboratórios
Cada professor tem no máximo 3 turmas, mas pode não estar alocado.
Turmas têm no máximo 30 alunos
A lista de presença deve ser preenchida até 10 minutos após o início da
aula

Identifique cenários

30 30
TÉCNICAS DE TESTE

Partição por equivalência

Divide o domínio de entrada em classes ( partes ) de tipos

específicos. Testar um da equivalência é considerado
suficiente.

Software Testing Foundations, 4ª edição

Quais as classes inválidas?

31 31
 Exercício: Partição por equivalência

Uma escola quer cadastrar turmas e professores.

Uma turma pode ter aulas em salas teóricas e laboratórios
Cada professor tem no máximo 3 turmas, mas pode não estar alocado.
Turmas têm no máximo 30 alunos
A lista de presença deve ser preenchida até 10 minutos após o início da
aula

Identifique cenários

32 32
 TÉCNICAS DE TESTE

Tabelas de decisão

Testes baseados em partições de equivalência ou análise de valores-

limite consideram cada valor de entrada isoladamente.
E se existirem combinações de valores que constituam situações
interessantes a serem testadas?
A resposta é utilizar Tabelas de decisão para análise de “causa-efeito”.
Elas também permitem que se represente várias técnicas de teste em
conjunto.

33 33
TÉCNICAS DE TESTE

Tabelas de decisão

Exemplo para testar “Anexar arquivo”

Resultado Esperado
Cenário Condição Funcional Pentest
Validar Extensão V V N/A
F F F
Validar conteúdo V V N/A
F F F
Validar Tamanho V V N/A
F F F

34 34
TÉCNICAS DE TESTE

Tabela de decisão para “Sacar dinheiro”.

Cenário Senha Numero da Valor Valor na Valor no Resultado

( causas) conta digitado conta caixa esperado.
eletrônico ( efeitos )
CN1- Retirada em V V V V V Retirada em
Dinheiro Bem- dinheiro bem-
sucedida sucedida.
CN2 - Caixa V V V V F Opção Retirada
Eletrônico sem em Dinheiro
Dinheiro indisponível.

http://www.wthreex.com/rup/process/modguide/md_tstcs.htm

35 35
Cenários de teste
Uma instância de um contexto. Sequência específica de ações que
ilustra comportamentos. Um cenário pode ser usado para ilustrar
uma interação ou a execução da instância de um contexto.

Cenário Senha Numero da Valor Valor na Valor no Resultado

( causas) conta digitado conta caixa esperado.
eletrônico ( efeitos )

CN1- Retirada em V V V V V Retirada em

Dinheiro Bem- dinheiro bem-
sucedida sucedida.

36 36
 Exercício: Tabela de decisão

Uma escola quer cadastrar turmas e professores.

Uma turma pode ter aulas em salas teóricas e laboratórios
Cada professor tem no máximo 3 turmas, mas pode não estar alocado.
Turmas têm no máximo 30 alunos
A lista de presença deve ser preenchida até 10 minutos após o início da
aula

Identifique cenários

37 37
 Caso de teste (script)
Conceito:
Conjunto de instruções passo a passo que contêm
-Entradas( dados de teste)
-Saídas ( resultados )
-Validações (Condições de execução: RN, exceções, msg, fluxos, etc)

38 38
 Massa e dados de teste

 Dados Válidos: participam de um cenário de casos de teste

positivo.
Ex: nome ”joao”, telefone:3232-0000.

 Dados inválidos: possibilitam a implementação do teste

negativo a um determinado cenário.
Ex: nome ”\??@*!”, telefone:”abcd;,~!!”.

Precisa de massa de teste?

39 39
Testes com script. Um exemplo:

40 40
 Exercício: Crie um teste funcional com script

Uma escola quer cadastrar turmas e professores.

Uma turma pode ter aulas em salas teóricas e laboratórios
Cada professor tem no máximo 3 turmas, mas pode não estar alocado.
Turmas têm no máximo 30 alunos
A lista de presença deve ser preenchida até 10 minutos após o início da
aula

41 41
O paradoxo dos pesticidas.
Insetos e bactérias tornam-se resistentes aos pesticidas. Da mesma
forma, se os mesmos testes são repetidos uma e outra vez, tendem
a perder sua eficácia, não descobrindo novos defeitos.
Para manter a eficácia de testes e lutar contra este "paradoxo de
pesticidas", casos de teste novos e modificados devem ser
desenvolvidos.

Com base em Software Testing Foundations, 4ª edição

Como reduzir o paradoxo dos pesticidas?

42 42
TÉCNICAS ÁGEIS DE TESTE

-Teste Exploratório no mundo ágil

-Histórias do usuário

43 43
 Manifesto de teste

Valorizamos

-Teste no todo é melhor que no final

-Prevenir bugs é melhor que procurá-los
-Compreender o teste é melhor que checar
funcionalidades
-Construir o melhor sistema é melhor que quebra-lo
-Responsabilidade do time com a qualidade é
melhor que a responsabilidade do tester

44 44
 Teste
exploratório

45 45
 O que é pra
você, teste
exploratório?

Um vídeo sobre
exploratório

46 46
Teste Exploratório:
Características Essa é fácil!!! Design,
Deixa comigo!!! Seus execução e
Seu ponto de partida aprendizagem ao
são ideias, propósitos elementos são três..
mesmo tempo
e missão definidas

Gente, desculpa,
ainda não entendi o
que é teste
É estruturado. Não é
exploratório
“Testa eah!”

identificar riscos
críticos, necessidades
e fatores de qualidade
Porque o objetivo é
agregar valor ao Por quê?
produto

James Bach’s 2003 paper, “Exploratory Testing Explained.”

47 47
Por que usar Exploratorios?
Software perfeito e outras ilusões

...e nem todas

condições são úteis de ...e é muita coisa que leva tempo!
serem cobertas configurações, interações,
execução, sumarização... rsrs

Não consigo cobrir ...e o conhecimento?!

com antecedência dados, cenários,
todas as condições configurações... nem se
fala!

48 48
Por que usar Exploratorios?
Repensando estratégias

Que tal uma estratégia que

responda a questões criticas?
Amei a ideia..rsrs Que tal um um brainstorm
sobre comportamento e risco?

Não é necessário um
conjunto “perfeito” de
testes

49 49
Quem precisa de
Exploratórios?

50 50
Quem precisa de
Exploratórios?

51 51
TESTE COM SCRIPT e EXPLORATÓRIO

52 52
 SCRIPT CHECA

EXPLORATÓRIO
TESTA

53 53
Técnicas Exploratórias- Como explorar Não são
sequenciais
Jogos de Técnica Session Based e
catástrofes de turismo de Reconhecimento

Persona
Modelos de estado,
Técnica de relações,
CRUD, QQC,
Comportamento
padrão
54 54
Cartas exploratórias

Frente da carta Costas da carta

Critérios e condições de teste

55 55
 Abordagem
Exploratória

O valor das
Cartas de Teste

Card: para lembrar do teste, conversa

Conversation: detalhes
Confirmation: teste de aceitação

56 56
 Sessões de reconhecimento
Sessões de reconhecimento são sobre mapear o território do sistema existente.
Ao final da sessão, saber mais sobre:
-O escopo exploratório
-As técnicas necessárias na exploração tendo uma ideia inicial
sobre a qualidade e características do sistema

James and Jon Bach recon session

https://www.youtube.com/watch?v=Vy0I2SB5OLo

57 57
Técnicas Exploratórias

58 58 58
Identificando cenários
orientados a risco

Técnica de Jogos de catástrofes

• E se... O que de pior pode ocorrer? O que pode

comprometer?
• E se a primeira camada de segurança quebrar?
• E se eu mudar um parâmetro da requisição e o captha
não impedir um DOS?
• E se eu testar este trecho de funcionalidade, o que
ocorre?

• O que acontece se eu...

59 59
Onde ( o que ) : Riscos
Atividade 2-Jogos de catástrofes

60 60
 Mind Maps
-Começe com um alvo base
-Estratégias: top down e bottom up
-Deixe as ideias explodirem
-Planeje: KISS at all
-Recall da conversation

61 61
Desenhando cenários com mindmaps

"Acceptance Criteria", Kent McDonald 62 62

Crie um Atividade 6

que

com critérios mínimos de aceitação

Utilize técnicas de desenho de teste
Sessões de 5 minutos: Reconhecimento, exploração 63 63
Técnica CRUD

Create.
Crie um caminho diferente para explorar a entidade
Crie entidades com atributos diferentes ( formulários com campos
personalizados)

Delete
Delete atributos da entidade e execute percurso padrão e diferente

Read
Veja a entidade imagem em browsers diferentes e dimensões
diferentes

Update:
Atualize a sessão do browser ( F5) durante o upload da entidade
arquivo
64 64
Onde ( o que ) : Entidades, funcionalidades, UI, código...

Como: Técnica 3QC (Quando, Quem, Quantos, Como ) +

CRUD

Exemplo:

oQuem insere na funcionalidade criar escala?

oQuem pode enviar msgs fora do sistema?
oQuando pode enviar msgs?
oPode enviar msgs ao mesmo tempo? (quando)
oQuantos podem concorrentemente se matricular?
oHá outra forma de enviar msg usando tecla de atalho
( como )
oQuando pode apagar a msg de quem?
oComo ( Regras de negócio) insere?

65 65
 Explore com Técnica 3QC (Quando, Quem, Quantos,
Como ) + CRUD

Uma escola quer cadastrar turmas e professores.

Uma turma pode ter aulas em salas teóricas e laboratórios
Cada professor tem no máximo 3 turmas, mas pode não estar alocado.
Turmas têm no máximo 30 alunos
A lista de presença deve ser preenchida até 10 minutos após o início da
aula

66 66
Vantagens de explorar o requisito

-Time uniformiza a visão sobre o requisito

-Time aprende e valida se o que modelou representa
necessidade do cliente

-Aproxima o time e requisitos são enriquecidos

67 67
Vantagens de explorar o requisito

-Testes mais simples e rápidos são produzidos

-Horas de retrabalho de todo o time são economizadas

-Times sadiamente mais produtivos

68 68
USANDO

Heurísticas

69 69
Heurísticas
Recurso valioso ou limitador?

70 70
Definindo as heurísticas
não estou limitando como explorar?

-O cuidado entre direcionar x restringir a

exploração
-Por que o tempo pode ser muito curto e
heurísticas prioritárias
Necessitam ser definidas

-Por que o explorador pode ser inexperiente ou pouco criativo

71 71
Heurísticas

Não demore a entregar um

teste for falta delas.

72 72
 Um arquivo de heurísticas

Test Heuristics Cheat Sheet Data Type Attacks & Web ... - Test Obsessed

http://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf

73 73
Atividade -Sugerir - passar à frente

Não consigo enxergar

oportunidade exploratórias

74 74
Fontes de quando
explorar.

75 75 75
Fonte de inspiração para Cartas
Quando explorar
Vc faz parte! Quem sabe fará parte
Discussões de requisitos Apresentação de um produto

Vc ficou de fora!
Explorar artefatos
Explorar com o cliente
Explorar com o time

76 76
Algumas (outras) fontes
para Teste Exploratório

77 77
Quando é preciso explorar mais?

Atenção às
respostas verbais!

78 78
Prática – identificando oportunidades
Quando é preciso explorar mais?

Cada time faz duas perguntas sobre o cenário abaixo

e se há possibilidade de explora-la mais.
Simples, imprecisas, incompletas, dependência, ambiguas

79 79 79
Atenção às emoções

Surgimento:
Não interpreto a observação como um
problema até que o sentimento ( intensidade)
chega

80 80
EXPLORANDO REQUISITOS

o Escute a conversa
o Pergunte e explore
o Time precisa de mentalidade
exploratória para trazer ideias à
mesa.

o Gaste alguns minutos em torno das bordas

de uma ideia a explorar
o Questione pressupostos e novos conceitos, isso pode
poupar semanas de retrabalho.

Revisão de teste é uma revisão de requisitos para análise,

teste e desenvolvimento: documentação viva

81 81
 ATDD (Acceptance Test Driven Development)

Teste de Eu sei o que eu

Aceitação
disse, mas já faz
seis meses

O núcleo de todas as práticas

82 82
 ATDD: teste.. Design orientado

Alguns pontos de vista

-Aceitação do cliente como base;

-Só como pré-entrega do produto é subutilizar a
inteligência produtiva da empresa: muito gasto pouco ROI
-No Ágil é executado em todo o ciclo de vida do produto

83 83
 ATDD: teste..
Design orientado

Alguns pontos de vista

-Aproxima o produto da necessidade do cliente. Reduz

incertezas
-Agrega muito valor ao produto

84 84
 Testando com Histórias

Usando 3C

-Card
-Conversation
-Confirmation

"User Stories… Unleashed"; Mike Turner, Sean Hurst, Ray Jordan

85 85
O que é uma história?

-Descrição escrita usada para descrever cenários de

negócios
-Testes que transmitem e documentam os detalhes de
um projeto (confirmação).
-Utilizada para modelar o sistema

"User Stories… Unleashed"; Mike Turner, Sean Hurst, Ray Jordan 86 86

 User stories
-Enfatizam comunicação verbal ao invés de escrita.
-São compreensíveis pela equipe e cliente
-São ferramentas de desenvolvimento iterativo.
-Encorajam detalhes até que se tenha entendimento
do que realmente precisa.

87 87 87
 Não fique obcecado pelo formato

O MVP é o mais importante

http://blog.crisp.se/2014/09/25/david-evans/as-a-i-want-so-that-considered-harmful 88 88
 Critérios de aceitação nas costas
da nota adesiva

O MVP é o mais importante

http://blog.crisp.se/2014/09/25/david-evans/as-a-i-want-so-that-considered-harmful 89 89
Crie uma ou mais histórias para o cenário seguinte

Uma floricultura deseja informatizar suas operações.

Deseja manter um cadastro de seus clientes e de seus produtos.
Há descontos em certos dias do mês e por limite mínimo

Escreva critérios de aceitação

Use 3C

90 90 90
O valor das
Histórias testáveis

A história para mover o projeto

pra frente
Estreita colaboração com seus stakeholders:
• Para gerar Informações de valor
• Para identificar e enquadrar requisitos que respondam as
perguntas mais importantes sobre o software ou serviço

91 91 91
 Teste de aceitação: ATDD Todo o
time
explora e
Time modela
explora e
remodela
testes de
aceitação

Time apoia
e modela
testes de
aceitação

Testers, Dev,
Analistas
modelam
testes de
aceitação

Driving Development with Tests:ATDD and TDD, Elisabeth Hendrickson

92 92
Padrões de teste de software
Algumas referências
http://www.gcreddy.com/2012/12/software-testing-standards.html

http://extremesoftwaretesting.com/Info/standards.html

93 93 93
Imagens

http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3127/10-Tips-for-Writing-Good-
User-Stories.aspx
http://blog.commlabindia.com/elearning-design/effective-scenarios-for-elearning
https://www.callcentrehelper.com/tag/quality
https://www.sadlerco.com/quality-control/
http://ecomputernotes.com/software-engineering/levels-of-software-testing
http://www.guru99.com/black-box-testing.html

94 94
Parabéns!!!!!

Seu time conseguiu

95 95