OverviewdeQA
Resultados Digitais
Bárbara Cabral da Conceição - ISTQB CTFL
Analista de Testes e Qualidade
barbaracabral@gmail.com

Dicas
● O objetivo é alinhar o conhecimento acerca de Testes
● Provavelmente você já conhece e até aplica algumas das técnicas
● Saber realizar pesquisas utilizando os termos abordados
● Não são todas as técnicas que conheço/apliquei
● Não são todas as técnicas que você precisa conhecer/ aplicar
(apenas aquelas que achar necessária)
● Se for necessário aprofundar em alguma, vemos isto num próximo
seminário, num post ou em pesquisas e conversas informais
● Você não deve se preocupar em aprender tudo hoje

● São ações de Deteção de erros e defeitos em produtos evitando
problemas nas entregas das soluções aos clientes
● Testing is context dependent
○ Técnicas & Abordagens de Testes são aplicadas de forma diferente em
cada contexto. Ex: um software de diagnóstico médico é testado
diferente de um e-commerce.
QualityAssurance
● São ações de Prevenção de erros e defeitos em produtos evitando
problemas nas entregas das soluções aos clientes
QualityControl

MatrizdeTestesÁgeis

FluxodeTestesemumaRelease

EcomoficaissodentrodeumaSprint?

NíveisdeTestenaMatrizÁgil
● Testes Unitários (Q1)
● Testes de Componente (Q1)
● Testes de Integração (Q1)
● Testes de Sistema (Q1 e Q2)
○ Funcionais
○ Não-funcionais
● Testes de Aceitação (Q3)
○ Comportamento (BDD)

TiposdeTeste
● Smoke Tests
● Testes de Regressão
● Testes de Usabilidade
● Testes de Segurança
● Testes de Stress
● Testes de Carga/Volume
● Testes de Performance
● Testes de Integridade
● Testes Exploratórios
● ...

SmokeTests
● Objetivo:
○ Garantir que as funções mais importantes do sistema estão funcionando
● Também conhecidos como “Build Verification Testing”
● Conjunto mínimo de testes para determinar uma versão “estável do sistema”
● Se estes testes falharem, o build requer fix imediato
● Níves de teste: Sistema, Integração e Aceitação
● Geralmente é um sub-conjunto de uma suite de testes de regressão
automatizados

TestesdeRegressão
● Objetivo:
○ Garantir que tudo o que estava funcionando ANTES das alterações
continuam funcionando
● É executado a cada vez que um deploy do sistema é realizado, sendo assim
geralmente é automatizado
● Retorna um relatório do impacto da mudança no restante do sistema
● Pode exigir que a cobertura de teste de outra área aumente caso o risco de
quebra também seja maior
● É apropriado ter uma suite de testes de regressão para cada nível de
teste: de componente, de integração e de sistema
● Se a suite é muito grande, geralmente se utiliza um subconjunto dela, os
Smoke Tests

TestesdeUsabilidade
● Objetivo:
○ Identificar se a experiência do usuário no sistema está sendo
eficiente, efetiva e satisfatória
● Efetividade: o usuário consegue alcançar seus objetivos dentro do
software?
● Eficiência: o usuario consegue alcançar seus objetivos em um tempo que ele
considera razoável?
● Satisfação: o usuário sente que o software ajudou ele a concluir suas
tarefas?
● Geralmente realizados por UX Designers diretamente com o usuário

TestesdeSegurança
● Objetivo:
○ Prevenir acesso não autorizado ao programa ou seus dados,
independente se foi causado acidentalmente ou de propósito
● Exemplos: bloqueio de acesso a APIs, manipulação das configurações da
infra, arquivos corrompidos, edição de dados que usuários não poderiam
realizar através da interface, forçar a sobrecarga de recursos do sistema
(CPU, memória), inputs muito longos nos campos podem “quebrar” o sistema,
alteração de privilégios de segurança no BD, forçar a quebra com
caracteres especiais, scripts, comandos da linguagem ou do banco de dados.

TestesdePerformance
● Objetivo:
○ Medir desempenho do sistema, ou seja, o tempo de resposta dos inputs
do usuário no sistema e outros tipos de entrada.
● Algumas medidas de eficiência:
○ Tempo de resposta por operação em segundos
○ Número de transações por segundo
○ Saída de dados por segundo
○ Ciclos de CPU
○ Uso de memória

TestesdeCarga/Volume
● Objetivo:
○ Como o sistema se comporta ao se aumentar o nível de carga e quanta
carga o sistema pode manipular até seu “pico”
● Fontes de carga: número de usuários que acessam o sistema; outros sistemas
que façam interface com nosso sistema
● O que nos responde: a habilidade que o sistema tem de manipular um número
de usuários em paralelo ou, de manter a sessão e garantir a integridade,
quantos registros são processados por hora, volume de dados trocados
através da rede ou de integrações com outros sistemas, etc.
● Algumas medidas: número máximo de usuários simultâneos, número máximo de
transações simultâneas

TestesdeStress
● Objetivo:
○ Determinar a capacidade de recuperação e estabilidade do sistema
● Define picos de instabilidade: aumento e diminuição de carga em uma
determinada funcionalidade para testar a elasticidade do sistema
● Avalia como o sistema lida com o stress: se ele falha ou se ele se
recupera rapidamente
● Spike tests: Basicamente, é executada uma quantidade massiva de uma
determinada funcionalidade, para determinar como a aplicação se comporta.
Por exemplo, quando há uma troca de turno em um sistema de call center e
todos os novos usuários têm que fazer login ao mesmo tempo enquanto outros
realizam logout.

TestesdeIntegridade
● Objetivo:
○ Verificar o sistema se recupera quanto à perdas de dados quando
interrompida uma determinada transação
● Failover:
○ Simular falhas no sistema para avaliar em quanto tempo o sistema se
recupera e coloca tudo funcionando novamente
● Backup:
○ Verificar que os diferentes tipos de backup estão funcionando para o
caso de ocorrer uma falha
● Restore:
○ Verificar o tempo de o sistema avaliar se houve perda de dados ou se

TestesExploratórios
● Objetivo:
○ Descobrir falhas através do aprendizado/experiência no sistema
● Planejados e guiados por um test charter que provê uma
descrição geral dos objetivos de teste
● O processo é interativo e criativo
● O resultado varia conforme a experiência do testador no
sistema & em outros sistemas

TécnicasdeTeste

Specification-basedTechniques
● Equivalence Partitioning
● Boundary Value Analysis
● Decision Tables
● State Transition
● Use Case Testing

EquivalencePartitioning
● Grupo de condições de teste divididos em partições que
serão manipuladas da mesma forma
○ 1º - Identificar um conjunto de dados como as condições de entrada
que possuem um mesmo resultado
○ 2º - Agrupar os dados de entrada em partições
○ 3º - Você sempre tem pelo menos 2 tipos de partições: válidas e
inválidas
● Provê redução no número de dados para teste

BoundaryValueAnalysis
● Equivalence class não garante erros nos valores limites
● Identificar erros nos limites das partições
○ 1º - Identificar os valores mínimos e máximos de cada partição
○ 2º - Prover caso de teste para cada valor-limite
-1, 0, 1 5, 6, 7 17, 18, 19 63, 64, 65

DecisionTable
● Amplamente utilizada para testar regras de negócio
● Geralmente você tem uma grupo de condições de entrada e
um conjunto de condições de saída

StateTransition
● Utilizado para testar transições de
estado
● Podem ser utilizados grafos de
transição de estado ou tabelas:
TC1 TC2 TC3
Start
event
Null Null Confirmed
Event Request room Request
room
Customer
cancels
Effect Room Available Room Not
Available
Decrement the
room count
End
State
Confirmed On waiting
list
Canceled

Structure-basedtechniques
● Statement
● Decision
● Condition
● Multiple Condition

Statementcoverage
● Cada “estado” é executado pelo
menos 1 vez
● O número de estados executados
nos dão o retorno da cobertura
● Quantos casos de teste são
necessários para alcançar todos
os estados?

Decisioncoverage
● Cada “ponto de decisão” é
executado pelo menos 1 vez
● O número de decisões executadas
nos dão o retorno da cobertura
● Quantos casos de teste são
necessários para alcançar todos
os pontos de decisão?

Branch/Conditioncoverage
● O resultado de cada ponto de decisão
é executado pelo menos 1 vez
● A cobertura é através do resultado
de cada ponto de decisão
● Quantos casos de teste são
necessários para alcançar todas os
branches dos pontos de decisão?

Multiplecondition(MC/DC)
● O resultado de cada condição deve
ser testado individualmente
● A cobertura é através do resultado
de cada pequena condição:
● Quantos casos de teste são
necessários para alcançar todas as
combinações possíveis?

StructuredCoverage byNASA

Outros...

AbordagensdeTeste
● Data driven testing
● Control-flow based testing
● Behavior driven testing
● Business driven testing
● Keyword driven testing
● Model-based testing
● Risk-based testing
● Context-driven testing

● Geralmente se usa uma tabela de condições gerando um
conjunto de Dados de Entrada para um determinado
componente e os dados de saída correspondentes
● Os dados de entrada podem ser armazenados/carregados de
um arquivo
● Os dados de saída podem ser verificados diretamente em
banco de dados
● Permite testar o mesmo cenário de teste com a variação
dos dados incluídos
Data-driventesting

Control-FlowBasedTesting
● Do código-fonte, criar um
gráfico que represente o
fluxo de controle do sistema
● Geralmente se criam os
testes baseados em uma das
seguinte coberturas:
○ Nodes, Edges, Paths e Branches

Behavior-DrivenTesting
● Descreve o sistema em termos de
comportamento
● Mapeia com melhor cobertura as regras
de negócio e de interface
● Alinha comunicação entre business &
code
● Para automação, utiliza a linguagem
Gherkin
○ GIVE / WHEN / THEN
● É possível usar o conceito de data-
driven junto através das tabelas de
dados
Feature: Add and remove tags
In order to organize my leads
As a simple user
I want add and remove tags
Scenario: action Add a tag
Given the page "https://www.rdstation.com.br/leads
When I select a filter Todos os contatos da base de
leads
And I click on group "Ações"
And I select "Adicionar Tag"
And I fill in Tag with "urgente"
And I click on "Adicionar"
Then I should see all the leads with the tag "urgente"
Scenario: action Remove a tag
Given The page "https://www.rdstation.com.br/leads
When I select a filter Todos os contatos da base de
leads
And I click on group "Ações"
And I click on "Remover Tag"
And I fill with "urgente"
And I click on "Remover"
Then I should see the leads without the tag "urgente"

Business-DrivenTesting
● Exercita os objetivos de
negócio do usuário dentro
do sistema
● Mapeia os fluxos de tela e
a execução das tarefas

RiskBasedTesting
● Baseado na priorização dos testes em termos de risco de
falha
● Baseado na importância da feature dentro do sistema
● Baseado no possível impacto do defeito

ContextDrivenTesting
● Princípios:
○ Os grupos de teste existem para prover serviços relacionados aos
testes. Eles servem o projeto.
○ Os grupos de teste têm missões diferentes a cada etapa do projeto:
dependendo do contexto atual do projeto e dos problemas atacados
○ O valor essencial de um test case é prover informação e reduzir
incerteza
○ Testes automatizadoes não são testes manuais de forma automática
○ Diferentes tipos de defeitos podem ser revelados por diferentes tipos
de teste
○ Os testes são sob medida quando satisfazem aos requisitos dos
stakeholders do projeto

Mitos
● O objetivo dos Testes é garantir 100% de um produto livre de bugs
○ FATO O objetivo dos testes é descobrir tantos defeitos quanto possível
enquanto garante que o software cumpre os seus requisitos. Identificar e
“se llivrar” de todos os defeitos é impossível.
● Testar é fácil! =D
○ FATO Testar pode ser difícil e um grande desafio (às vezes até maior do
que codificar)
● Testes Automatizados eliminam a necessidade de testes manuais
○ FATO 100% de automação de testes não pode ser alcançado. Testes
manuais são, em algum nível, necessários.

Mitos
● Quando detectado um incidente a falha é do QA
○ FATO: Qualidade é a responsabilidade de todos os membros/stakeholders
do projeto
● QA não precisa saber as regras de negócio
○ FATO: quanto mais cedo QA souber o comportamento esperado do
sistema, mais cedo poderá encontrar falhas
● QA dá resultado a curto prazo
○ FATO: o processo de onboarding de um QA pode demorar mais pelo fato
de precisar definir um processo e uma estratégia antes & precisar entender
claramente as regras de negócio e comportamento do sistema

Fontes
● Foundations of Software Testing
● Advanced Software Testing - Volume 1
● The Software Test Engineer’s Handbook
● White-box techniques http://www.chaudhary.org/WhiteBox.pdf
● NASA: /shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001-tm210876-MCDC.pdf
● http://www.inf.ed.ac.uk/teaching/courses/st/2011-12/Resource-
folder/06_structural.pdf
● http://www.testdesigners.com/testingstyles/ControlFlowTesting.html

Contato
● Skype: babipcabral
● Twitter: @barbarapcabral
● LinkedIn: /in/barbaracabral
● E-mail: barbara.
cabral@resultadosdigitais.com.br