GOTEST Aula1 Introdução

Introdução a Testes
de Software
Cidinha Gouveia
cidinha@gotest.biz
http://www.applabs.com/uploads/tool.jpg
2009
SUMÁRIO
• Por que teste é necessário?

• Objetivos do teste
• O que é teste?
• Princípios gerais
• Teste X Qualidade
• O papel do testador
• Abordagens de teste
• Fases de teste
• Tipos de teste
• Técnicas de teste
SUMÁRIO

• O que é teste?
• Fases de teste
• Tipos de teste
Sistemas de software estão cada vez
mais presentes nas nossas vidas!
Sistemas cada vez mais complexos!
02/10/2006 - 00h30
Tragédia da Gol matou os 155 ocupantes
O avião, com 149 passageiros e seis tripulantes a bordo, perdeu

contato com os radares na sexta-feira por volta das 17h,
quando cobria uma rota entre Manaus e o Rio de Janeiro, com
escala em Brasília.
http://noticias.uol.com.br/ultnot/efe/2006/10/02/ult1807u31263.jhtm
CONSEQUÊNCIAS:
- Caos nos aeroportos do Brasil
- greve dos controladores de vôo
- novas leis para companhias aéreas
2005 -> 58 acidentes

Centro de Investigação e Prevenção de
Acidentes Aeronáuticos (Cenipa)
Show de Madonna: fãs que tiveram
cartão debitado terão ingresso
O anúncio afirma que o motivo da pane
no sistema no site ticketsforfun.com.br
no início das vendas dos ingressos (dia
1º/9 no Rio e 3/9 em São Paulo) foi
devido ao "número de hits simultâneos no
site de vendas [que] provocou
morosidade no sistema. Como efeito
colateral, houve aumento do tempo de
transação entre os diversos módulos do
software de vendas causando atraso nas
respostas e gerando informações
múltiplas que o sistema não conseguiu
interpretar".
http://g1.globo.com/Noticias/Musica/0,,MUL749176-7085,00.html
Hospital Sírio-Libanês apresentou
robô cirúrgico na feira HOSPITALAR 2008
http://www.hospitalar.com/imprensa/not2273.html
Sistemas de software estão cada vez mais presente
em nossas vidas.
Realidade: sistemas que não trabalham como

esperado;
Fato: Software que não trabalha corretamente pode

acarretar uma série de problemas: perda de TEMPO,
DINHEIRO e REPUTAÇÃO nos negócios ou até mesmo
FERIMENTOS e MORTES.
Como evitar esses problemas?
O que pode ser melhorado no
desenvolvimento dos sistemas de
software?
Realidade Cronograma
• Cerca de 30-40% dos Projetos de
Software excedem seu cronograma
originalmente estimado.
• Os Projetos excedem em mais de

200% do seu cronograma inicial.
• Mais de 70% dos projetos falham

nas funcionalidades requisitadas.
Fonte: [Pesquisa realizada pelo Standish Group [11]]

Custos
• Mais de 50% dos Projetos de
Software excedem os custos
planejados
• Os custos são excedidos em

mais de 180% do estimado
• Mais de 30% dos Projetos de

Software são cancelados antes
de terminar.
Fonte: [Pesquisa realizada pelo Standish Group [11]]
Taxa de Sucesso dos Projetos de TI
Cancelados
Concluídos em mais Pequeno

tempo, maior custo e Médio
menos funcionalidades Grande
Sucesso
Fonte: CHAOS Survey by Standish Group

DESAFIO
Por que teste é necessário?
D E S A F I O:
• Produto com maior qualidade;
• Baixo custo;
• Menor tempo possível
Cliente feliz
Custos
Custo para consertar um bug
Especificação Projeto Código Execução de Teste Entrega
Tempo – quando o bug é encontrado
CUSTO pode ser ELEVADO se a falha for encontrada

muito TARDE
Quanto mais cedo um bug for detectado mais barata é
sua correção.
Fonte: [Elfried Dustin – Effective Software Testing]

Fonte: [Elfried Dustin – Effective Software Testing]
Exemplos de falhas encontradas muito tarde
Custos elevados
• Blackout no
nordeste dos EUA
em 2003
• Afetou mais de 50
milhões de
consumidores
• Perda estimada em Um bug foi encontrado no sistema

de gerenciamento de energia
$ 6 bilhões. elétrica dos EUA.
Custos elevados
• Milhões de contas
bancárias foram
afetadas
• 2 semanas para
reparar o erro
Erros nos sistemas de transações

• Perda de $ 100 bancárias em um dos maiores
milhões. bancos americano.
Custos elevados
• Em 1999, a NASA
perdeu um de seus
satélites
• Ele não foi

localizado
• Perda estimada em
Um simples erro de conversão de
$ 125 milhões dados.
Custos elevados
• Em 1999, uma
pequena cidade em
Ilinois-U.S., comprou
um sistema para
gerenciar a
distribuição de
energia elétrica.
700 vezes maior que a conta
• A cidade recebeu
normal da cidade.
uma conta de $ 7
milhões
Cronograma
O que acontece?
Planejado: Spec. Design Coding Test
Spec. Design Coding Test
Spec. Design Coding Test
Realizado:
Spec. Design Coding Test?
Spec. Design Coding Test?
Spec. Design Coding Test......

Como aumentar a qualidade?
MENOS bugs  MAIOR qualidade

Qualidade
Consumidores estão mais exigentes

Equação
Menores custos
+
Pouco tempo
+
Alta qualidade
=
Satisfação do cliente
Solução da equação
Realizar testes de forma BEM PLANEJADA

pode ajudar a resolver essa equação!
E O MERCADO
A Índia movimenta US$ 16 bilhões por
ano e já emprega cerca de 500 mil
pessoas.
[terra ]
Fábricas de teste
• Brasil:
– Qualiti (PE),
– CPM Braxis (PR)
– RSI (SP, BSB, RJ)
– Zero-defect (RS)
• Exterior:
– Sogeti (Espanha)
– Critical Software (Portugal)
– International Institute of
Software Testing (EUA)
• [testexpert]
Notícias de mercado
1. Software de alta qualidade  Custos

elevados
2. Testes bem planejados  redução

nos custos envolvidos no projeto.
3. Quanto mais cedo um erro for

encontrado, menor serão os custos
relacionados com a correção do mesmo.
• Por que existem bugs (defeitos) no software?
Defeitos no software podem ocorrer por diversas

razões, tais como:
Erro humano  produz defeitos  causando falhas
• Falta de documentos de requisitos;
• Requisitos incompletos;
• Complexidade do software;
• Erros de programação;
• Mudança de requisitos;
– Complexidade em coordenar mudanças pode
resultar em erros;
– O entusiasmo dos engenheiros de teste pode ser
afetado;
– O gerente deve entender bem os riscos e os
engenheiros de qualidade devem adaptar os planos
para que os bugs inevitáveis não saiam do controle;
• Pressão de tempo
• Mudança da tecnologia.
• Ego
– As pessoas preferem dizer: “sem problemas”, “muito
fácil”, à: “isto é muito complexo, pode gerar erros no
final” ou “preciso investigar melhor para dizer quanto
tempo vai levar”.
• Pobre documentação de código;
• Ferramentas de desenvolvimento de software
pode ajudar a adicionar mais bugs devido a pobre
documentação da ferramenta;
– Falhas também podem ocorrer devido a
condições ambientais, tais como:
• Radiação;
• Magnetismo;
• Campos eletrônicos;
• Poluição, etc.
Onde estão localizadas as falhas?
Software
Problemas!!! Qualidade Testes
com defeitos
Cliente Perda de:

insatisfeito • tempo Testes bem
Alto custo!
• dinheiro planejados!
• reputação
Sumário

• O que é teste?
• Pscicologia do teste
• Fases de teste
• Tipos de teste
Objetivos do teste
• Objetivos gerais:
 Encontrar defeitos o quanto antes;
 contribuir com a qualidade do software;
 garantir que o software está de acordo com os
seus requisitos ou padrões específicos.
• Diferentes pontos de vista de teste podem ter

diferentes objetivos:
Objetivos do teste
Testes Objetivos
Durante o desenvolvimento Causar o máximo de falhas
(componente, integração, sistema) possíveis para que os defeitos
possam ser encontrados e
corrigidos.
Teste de aceitação Confirmar que o sistema trabalha
como esperado para garantir que o
software funciona de acordo com os
requisitos.
Testes de manutenção Certificar que nenhum erro novo foi
introduzido após as mudanças
realizadas no software.
Teste operacional Acessar as caracteristicas do
sistemas tais como: confiabilidade e
disponibilidade.
Sumário

• O que é teste?
• Fases de teste
• Tipos de teste
O que é teste?
O que é teste?
Testar é questionar um produto para avaliá-lo.
• As “questões” consistem de várias maneiras de configurar e operar

o produto.
• O produto “responde” exibindo comportamentos, os quais os
testadores observam e avaliam.
• Um bom resultado de teste vem de uma boa observação do
produto.
• Avliar um produto é observar como ele se comporta e identificar
problemas importantes no mesmo..
O que é teste?
O que é teste?
O que é teste?
O que é teste?
O que é teste?
Processo onde:
• Um sistema ou componente é executado sob
condições específicas,
• Os resultados são observados e registrados,
• Uma avaliação é realizada sobre os resultados
O que é teste?
Debug teste
Desenvolvedores Testadores
Encontrar a causa de Mostrar as

um defeito, reparar o falhas que
código e checar se o podem ser
defeito foi realmente causadas por
corrigido. defeitos.
Sumário

• O que é teste?
• Fases de teste
• Tipos de teste
Princípios Gerais de Teste
Os testes devem ser rastreáveis aos requisitos do cliente
A matriz de rastreabilidade deve ser atualizada com os testes
Testes devem ser planejados antes da execução
Testes têm mais chances de serem efetivos quando planejados
Testes devem iniciar em partes pequenas até atender o todo
Não deixar para testar apenas quando estiver tudo “pronto”

Teste não é uma atividade exaustiva
Deve-se procurar identificar os melhores casos de teste, aqueles

que “mostram” mais falhas
Princípios Gerais de Teste
Devem ser identificados casos de teste para condições inválidas e
inesperadas e para válidas e esperadas
Não basta testar apenas o que vai dar certo ou apenas o que não vai
dar certo
Teste é uma atividade destrutiva e não construtiva
Quem vai participar do teste deve pensar em como quebrar o
sistema
Teste não garante a ausência de defeitos
O teste reduz a probabilidade da existência de defeitos no software
mas não serve como prova de corretude.
A atividade de teste deve ser iniciada o mais cedo possível.
Quanto antes os defeitos forem encontrados, menores são os custos
do projeto.
Sumário

• O que é teste?
• Fases de teste
• Tipos de teste
Teste x Qualidade
Qualidade é o valor agregado à alguém.
Um BUG é qualquer coisa que implique no valor

do produto.
Michael Bolton
O que é um bug?
• Basketball Movie
Teste x Qualidade
Teste x Qualidade
• Teste e Qualidade
– Os testes podem AJUDAR a medir a qualidade do
software em termos de defeitos encontrados;
– O teste pode aumentar a confiabilidade do

software se poucos ou nenhum defeito for
encontrado;
– Testar bem reduz o risco de ter um sistema com

má qualidade!
Teste x Qualidade
– A qualidade do sistema pode aumentar

quando os defeitos são consertados;
– Lições podem ser aprendidas: defeitos já

conhecidos podem ser prevenidos.
– Teste pode ser considerado como uma

das atividades de garantia da qualidade.
Sumário

• O que é teste?
• Fases de teste
• Tipos de teste
Testadores não são Feras Selvagens…
… apesar de, às vezes, parecer um pouco

“negativo” para os desenvolvedores e vendedores.
Testadores iluminam o caminho.
Esse é o nosso lema!

Nós vemos as coisas como elas são.
Provemos informações que ajudam a decidir sobre
a possível qualidade de um produto.
O papel do testador
• O testador está diretamente associado a definição de teste de

software
O testador
– Encontra o bug
– Busca encontrá-lo o mais cedo possível
– Garante que o bug está corrigido
• Um bug corrigido não necessariamente implementa em mudança no
código
– Correção de um manual
– Correção de treinamento
– Etc.
• O testador deve ser responsável por verificar realmente se o bug foi
corrigido
O papel do testador
• Por que o testador é necessário?

– Os testes feitos por desenvolvedores
• Tendem a verificar apenas o “caminho feliz”
• Normalmente são otimistas
• Não são sofisticados
– Organizações iniciais tem usualmente 5 testes de
“caminho feliz” para cada teste de “caminho
alternativo”
• Organizações maduras usualmente tem o oposto - 5 de
caminho alternativo para cada um de caminho feliz
– Desenvolvedores normalmente só conseguem
enxergar 50-60% dos casos de teste do seu código
O papel do testador
Testadores não encontram falhas

apenas, eles oferecem evidência.
Testadores não gostam de quebrar

sistemas, eles gostam de quebrar a ilusão
de que eles funcionam corretamente.
Testadores não gostam de dar más

notícias, eles gostam de poupar
seus clientes de uma falsa verdade.
82
O papel do testador
• Desenvolvedor x testador  a
separação de responsabilidades é feita
para ajudar a focar os esforços e prover
benefícios;
• Quanto maior for o grau de

independência do teste, mais efetivo ele
pode ser em encontrar defeitos e
falhas;
Diferentes graus de independência
podem ser considerados, por exemplo:
• Teste desenvolvido pela pessoa que
escreveu o software;
• Teste desenvolvido por uma outra pessoa
do time de desenvolvimento;
• Teste desenvolvido por pessoas de um
grupo diferente da organização;
• Teste desenvolvido por uma empresa ou
organização diferente;
• Identificar falhas pode ser visto como uma
crítica ao produto ou ao autor do produto;
• Procurar falhas num sistema requer:

• Curiosidade;
• Pessimismo profissional;
• Olho crítico;
• Atenção aos detalhes;
• Boa comunicação;
• Conhecimento diversificado.
• Se erros, defeitos ou falhas forem
comunicados de maneira positiva, as rixas
entre desenvolvedores e testadores podem
ser minimizadas ou evitadas;
• Os testadores e os líderes de teste precisam

ter boas ferramentas para comunicar
informações sobre defeitos, progressos e
riscos de maneira construtiva;
• Para autores do software ou documento, as

informações de defeito podem ajudar a
melhorar suas habilidades;
• Defeitos encontrados e corrigidos durante os
testes podem economizar tempo e dinheiro
no futuro, além de reduzir os riscos;
• Se os testadores forem vistos apenas como

portadores de notícias não desejadas sobre
defeitos, poderá haver problemas;
Como reverter este quadro?

• Mostrar colaboração ao invés de batalhas:
• Lembrar a todos dos objetivos comuns para
melhorar a qualidade do sistema;
• Comunicar os defeitos encontrados de forma

neutra, focando no problema, sem críticas diretas
às pessoas criadoras;
• Tentar entender como essas pessoas se

sentem e porque elas reagem de tal forma;
• Certificar que a outra pessoa entendeu o que

foi comunicado e vice-versa.
Pergunta
Qual o objetivo de um testador. Marque V

para as opções verdadeiras
V F
( ) ( ) Corrigir bugs
( ) ( ) Encontrar bugs
( ) ( ) Garantir a qualidade do software
( ) ( ) Garantir que o software seja perfeito
( ) ( ) Encontrar bugs o mais rápido possível
Sumário

• O que é teste?
• Fases de teste
• Tipos de teste
Abordagens de testes
Abordagem / estratégia de teste
Caixa Branca / Estrutural

Como um sistema opera. Código, fluxo de
execução. Testes realizados em tempo de
desenvolvimento.
93
Abordagem de Teste
• Testes caixa branca são aqueles nos quais o testador

sabe como funciona o “interior” do objeto sendo testado
– Usualmente são executados pelo próprio desenvolvedor
– São fortemente associados aos testes unitários
– Avalia TODOS os caminhos lógicos do código para garantir que
TODOS os fluxos são executados corretamente
– Busca encontrar bugs, mas bugs no código e não bugs na
especificação, por exemplo
Abordagem de Teste
• A grande maioria dos sistemas de software realiza

apenas testes caixa preta
• Quando testes caixa branca são executados, eles não
são formalizados
– Não existe procedimento bem definido
– Não existe resultado de testes documentado
• Caso um procedimento de testes caixa branca seja
escrito, existe grande chance dele ser descartado após
a execução dos testes
Caixa Preta / Funcional

O que um sistema deve fazer. Características
externas, cenários. Melhores resultados quando
executado por um time de teste independente.
Testes caixa preta são aqueles nos quais o testador não vê o
“interior” do objeto que está sendo testado
• Usualmente executados por um testador que é diferente
do desenvolvedor
• Avalia todas as diferentes entradas e suas respectivas
saídas para garantir que o software se comporta como
especificado
• Associado a estágios de teste como sistema ou
componente
96
Sumário

• O que é teste?
• Fases de teste
• Tipos de teste
Fases de Teste
Fases, níveis ou estágios de teste:

• Teste de Unidade
• Teste de Integração
• Teste de Sistema
• Teste de Aceitação
Fases de Teste
1. Teste de Unidade
Consiste na verificação da menor unidade

de projeto de software.
Interface
Estrutura de dados locais
Módulo Condições de limite
Caminhos independentes
Caminho de tratamento de erros
Casos de teste
Fases de Teste
Teste de Integração
Consiste no teste das interfaces entre

unidades e módulos para garantir que eles
possuam considerações consistentes e se
comunicam corretamente.
Fases de Teste
• Estratégias:
– Top-down  abordagem incremental onde os
módulos são integrados de cima pra baixo.
– Bottom-up abordagem incremental onde os
módulos são integrados de baixo pra cima.
Botton-up
Top-Down
Fases de Teste
Top-down
• Vantagens: testar logo as principais funções de controle;
• Desvantagens: necessidade de ter stubs
Bottom-up
• Vantagens: projeto mais fácil de casos de teste e ausência
de stubs.
• Desvantagens: o programa não existe como entidade até
que o último módulo seja adicionado.
Fases de Teste
Teste de Sistema
Busca de defeitos em todo o sistema, totalmente
integrado.
• Foco no ponto de vista do cliente ou usuário final;
• Também usados para estressar aspectos particulares do
sistema: segurança, velocidade, precisão, confiança.
• Normalmente organizações independentes de testes
focam seus esforços em testes de sistema.
Sumário

• O que é teste?
• Fases de teste
• Tipos de teste
Tipos de teste
• Aceitação: testa o comportamento do sistema de

acordo com as necessidades do usuário;
• Envolve dados, ambiente e cenários reais;
• O foco não é voltado para procura por defeitos;
• O comprador normalmente é o mais interessado nos
resultados;
• Às vezes chamados de teste alfa (usuários internos) e beta
(consumidores).
• Considerado por alguns autores como uma fase de teste.
Tipos de Teste
Tipos de teste
Tipos de Teste
Tipos de Teste
Características observadas durante o teste

de usabilidade:
Tipos de Teste
Stress: testa como o sistema trabalha com

grande volumes de dados, transações,
usuários, etc.
Performance: testa se o sistema está de
acordo com os seus requisitos de
performance, tais como: capacidade e
tempo de resposta.
Tipos de Teste
• Sanidade: testa as funcionalidades básicas

do sistema.
• Regressão: re-teste de toda a aplicação
após qualquer alteração para verificar que não
foi causado nenhum efeito inesperado.
• Trade-off: garantia oferecida pelo teste de regressão
sempre que ocorre mudanças no sistema x recursos
necessários.
Tipos de Teste
• Instalação: testa o sistema com os requisitos de

configuração de hardware determinados. Os
procedimentos de instalação também são verificados.
• Configuração: Analisa o software sob diferentes

configurações especificadas.
Sumário

• O que é teste?
• Fases de teste
• Tipos de teste
Técnicas de Teste
• Técnicas estáticas
• Técnicas para design de casos de teste
– Baseada na especificação (caixa-preta)
– Baseada na estrutura (caixa-branca)
– Baseada na experiência
Técnicas de Teste
Técnicas de Teste
•Técnicas Estáticas
Não executam o software que está sendo
testado.
• Pode ser manual (revisões) ou automática
(análise estática).
Técnicas de Teste
Revisões
• Quando?
Podem ser realizadas antes da execução
dinâmica dos testes;
• Por que?
Defeitos podem ser encontrados cedo  mais
baratos de serem removidos;
• Atividade principal
Examinar o produto e fazer comentários sobre o
mesmo;
• O que pode ser revisado?
Especificação dos requisitos; design dos testes;
código, plano de teste, casos de teste, scripts
Técnicas de Teste
Revisões
Benefícios:
• Detecção e correção de defeitos cedo;
• Melhoria na produtividade do desenvolvimento;
• Redução no tempo gasto para desenvolvimento;
• Minimização de tempo e custo total;
• Redução de falhas no software;
• Melhoria na comunicação;
• Podem encontrar omissões nos requisitos.
Técnicas de Teste
Revisões
Típicos defeitos encontrados:
• Desvios de padrões;
• Defeito nos requisitos;
• Manutenibilidade insuficiente;
• Especificações incorretas
Técnicas de Teste
• Processo de Revisão
• As revisões podem ser formais ou informais.
• O modo como a revisão é conduzida depende do seu

objetivo:
• Encontrar defeitos;
• Adquirir um melhor entendimento;
• Gerar discussões e tomar decisões em consenso.
Técnicas de Teste
Fases de uma revisão formal:

• Planejamento
• Kick-off
• Preparação Individual
• Reunião
• Re-trabalho
• Follow-up
Técnicas de Teste
• Planejamento
- Selecionar pessoal; definir regras, critérios e local;
definir que parte do documento será revisada.
• Kick-off
- Distribuir documentos, explicar os objetivos e
processos aos participantes.
• Preparação Individual
- Os participantes devem analisar o documento e
tomar nota dos defeitos encontrados,
questionamentos e comentários.
Técnicas de Teste
• Reunião
- Discussões onde os resultados devem ser documentados.
- Os participantes devem ressaltar os defeitos, fazer
recomendações ou tomar algumas decisões para correção
dos mesmos.
• Re-work
- Conserto dos defeitos encontrados, normalmente pelo autor.
• Follow-up
- Checagem da correção dos defeitos;
- Coleta de métricas;
- Checagem do critério de saída
Técnicas de Teste
Papéis e responsabilidades:
• Líder
• Moderador
• Autor
• Revisor
• Registrador
Técnicas de Teste
Tipos de revisões:
• Revisões Informais
• Walkthrough
• Inspeções
Técnicas de Teste
Fatores de sucesso para revisões:
• Ter um objetivo bem definido;

• Escolher as pessoas corretas;
• Defeitos encontrados devem ser aceitos e
expressos objetivamente;
• Escolher a técnica mais adequada para o
propósito desejado;
Técnicas de Teste
• Usar check-lists ou regras, se apropriado, para
aumentar a efetividade na identificação de
defeitos;
• Fornecer treinamentos, principalmente para
técnicas formais de revisão (e.g.: inspeção);
• O gerencimento deve fornecer suporte para
obtenção de uma boa revisão (e.g.: ajuste de
tempo e cronograma);
Técnicas de Teste
Técnicas de Teste
Baseada na especificação
Casos de teste são derivados a partir de

especificações do software.
Ex:
• Partição por equivalência
• Análise de valores limites
• Tabelas de decisão / Tabela Causa-Efeito
• Testes derivados de casos de uso
Técnicas de Teste
Grafo de Causa-Efeito
- Causas e efeitos são extraídas das
especificações do sistema;
- Um grafo causa-efeito é gerado;
- A partir do grafo é gerada uma tabela de
decisão;
- Cada caso da tabela representa um caso de
teste.
Técnicas de Teste
Grafo Causa-Efeito Tabela de Decisão

1 2 3 4
C1 “ou” Causas 1 1 0 0 0
v E7 2 0 1 0 0
3 0 0 1 1
C2 E8 4 0 0 0 1
5 Causas
C3 v Intermediárias 5 1 1
E9 6 1
6 “e” Efeitos 7 1 1
8 1
C4 9 1
Técnicas de Teste
Baseada na estrutura
Casos de teste são realizados com foco no

código-fonte do sistema.
Ex.:
• Cobertura e Teste baseado em instruções
• Cobertura e Teste baseado em laços de
decisões
Técnicas de Teste
Baseada na experiência
- Testes são derivados da intuição e
experiência dos testadores;
- O grau de efetividade depende do grau de
experiência do testador;
- Algumas abordagens:
- Error guessing
- Testes exploratórios
Técnicas de Teste
Testes exploratórios
- Deve ser usado para encontrar mais bugs
mais rápido;
- Normalmente utilizada quando:
- Há pouca ou inadequada especificação;
- Pressão de tempo;
- É necessário complementar outra técnica formal
Técnicas de Teste
Error guessing
- Enumera-se uma lista de possíveis defeitos;
- Elabora-se testes para atacar esses defeitos
baseando-se em:
- Experiência do testador;
- Defeitos disponíveis e dados de falhas;
- Conhecimento comum sobre porque o
software falha.
Design x Execução
Como você produz

um excelente design?
Como você guia

um testador?
Técnicas Contrastantes
Test design Testes são

desenvolvidos, registrados e
executados depois ou por
um diferente testador.
Testes exploratórios  os
testes são produzidos e
executados ao mesmo
tempo, e não são
necessariamente
registrados.
Test design Discurso

preparado. Guiado por idéias
pré-concebidas.
Testes exploratórios  é como

um diálogo. Auto-guiado.
Test design controlar a

execução.
Testes exploratórios 
melhorar o design dos
testes.
Teste não significa documentação.
Teste é o que você

pensa e faz.
Apenas uma fração do pensamento e

comportamento de um testador experiente
está representado na documentação dos
casos de teste.
Exercício 1
• Pense em 10 situações onde seja

viável a prática de test design.
Respostas
• Quanto se precisa fazer algo muito específico;
• Quando ações específicas são conhecidas antes de realizar os
testes
• Quando o que se precisa testar é muito complexo, necessitando de
treinamentos
• Quando há muito risco em esquecer o que deve ser feito
• Quando a velocidade das execuções não é tão importante
• Quando há muitos recursos para testar
• Quando é necessário compartilhar decisões
• Quando é preciso decidir critérios baseados em quantidades de
testes passando/falhando.
• Quando um bom design de testes NÃO seria muito caro ou NÃO
requereria muito tempo
• Quando documentar for mais produtivo
Exercício 2
• Tente imaginar 10 situações onde

seja viável a prática de testes
exploratórios.
Respostas
• Quanto NÃO se precisa fazer algo muito específico;

• Quando ações específicas NÃO são conhecidas antes de realizar
os testes
• Quando sabe-se o que se fazer sem precisar de treinamentos
• Quando há pouco risco em esquecer o que deve ser feito
• Quando precisa execuções rápidas
• Quando NÃO há muitos recursos para testar
• Quando NÃO é necessário compartilhar decisões
• Quando NÃO é preciso decidir critérios baseados em quantidades
de testes passando/falhando.
• Quando um bom design de testes seria MUITO CARO ou requerer
MUITO TEMPO
• Quando NÃO documentar for mais produtivo
Teste é ciência.
Desenvolva sua mente científica.

Desenvolva sua mente
Especificação
Problema Comunicação
Conhecimento Técnico Produto
Experiência
Problema
Conhecimento de domínio
Reportagem Cobertura
A parte importante de testes não está no seu computador, nem na sua mesa
Desenvolva sua mente científica
Desenvolva sua mente científica
Vamos testar os triângulos?

Referências
• [Dustin, 2006] Elfried Dustin, Effective Software Testing, 5th

Printing, December, 2006
• [Burnstein, 2003] Ilene Burnstein, Practical software testing : a

process-oriented approach, 2003, Springer-Verlag New York
• [Graham, Black, 2007] Dorothy Graham, Erik Van, Isabel Evans,

Rex Black, Foundations of Software Testing, Thomson, 2007
• [Craig, Jaskiel, 2007] Rick Craig, Stefan Jaskiel, Systematic

Software Testing, Artech House Publishers, 2007
• [Myers, Glenford, 2004] Glenford myers, The Art of Software

Testing, John Wiley & Sons, Inc., Hoboken, New Jersey, 2004

GOTEST Aula1 Introdução

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

GOTEST Aula1 Introdução

Enviado por

Direitos autorais:

Formatos disponíveis

Introdução a Testes

• Por que teste é necessário?

• Por que teste é necessário?

O avião, com 149 passageiros e seis tripulantes a bordo, perdeu

2006 -> 66 acidentes

2007 -> 97 acidentes

Realidade: sistemas que não trabalham como

Fato: Software que não trabalha corretamente pode

• Os Projetos excedem em mais de

• Mais de 70% dos projetos falham

Fonte: [Pesquisa realizada pelo Standish Group [11]]

• Os custos são excedidos em

• Mais de 30% dos Projetos de

Concluídos em mais Pequeno

Fonte: CHAOS Survey by Standish Group

Custo para consertar um bug

Especificação Projeto Código Execução de Teste Entrega

Tempo – quando o bug é encontrado

CUSTO pode ser ELEVADO se a falha for encontrada

Fonte: [Elfried Dustin – Effective Software Testing]

• Perda estimada em Um bug foi encontrado no sistema

Erros nos sistemas de transações

• Ele não foi

Spec. Design Coding Test

Spec. Design Coding Test

Spec. Design Coding Test?

Spec. Design Coding Test......

MENOS bugs  MAIOR qualidade

Consumidores estão mais exigentes

Realizar testes de forma BEM PLANEJADA

1. Software de alta qualidade  Custos

2. Testes bem planejados  redução

3. Quanto mais cedo um erro for

Defeitos no software podem ocorrer por diversas

Cliente Perda de:

• Por que teste é necessário?

• Diferentes pontos de vista de teste podem ter

• Por que teste é necessário?

Testar é questionar um produto para avaliá-lo.

• As “questões” consistem de várias maneiras de configurar e operar

Encontrar a causa de Mostrar as

• Por que teste é necessário?

Testes devem iniciar em partes pequenas até atender o todo

Não deixar para testar apenas quando estiver tudo “pronto”

Deve-se procurar identificar os melhores casos de teste, aqueles

• Por que teste é necessário?

Qualidade é o valor agregado à alguém.

Um BUG é qualquer coisa que implique no valor

– O teste pode aumentar a confiabilidade do

– Testar bem reduz o risco de ter um sistema com

– A qualidade do sistema pode aumentar

– Lições podem ser aprendidas: defeitos já

– Teste pode ser considerado como uma

• Por que teste é necessário?

… apesar de, às vezes, parecer um pouco

Esse é o nosso lema!

• O testador está diretamente associado a definição de teste de

• Por que o testador é necessário?

Testadores não encontram falhas

Testadores não gostam de quebrar

Testadores não gostam de dar más

• Quanto maior for o grau de

• Procurar falhas num sistema requer: