09 02 Teste Manual PDF

Organização Origem dos Defeitos de Software Prevenção e Detecção de Defeitos Teste Manual Conclusão Questões Leit
Teste Exploratório de Software

Teste Manual
Auri Marcelo Rizzo Vincenzi1 , Márcio Eduardo Delamaro2 e
José Carlos Maldonado2
1 Instituto
de Informática
Universidade Federal de Goiás
2 Instituto
de Ciências Matemáticas e de Computação
Universidade de São Paulo
Vincenzi, Delamaro & Maldonado

Teste Exploratório: Teste Manual 1/32
Este material pode ser utilizado livremente respeitando-se a licença

Creative Commons: Atribuição – Uso Não Comercial –
Compartilhamento pela mesma Licença (by-nc-sa).
Ver o Resumo da Licença | Ver o Texto Legal

Organização
Origem dos Defeitos de Software
Prevenção e Detecção de Defeitos

Prevenção de Defeitos
Detecção de Defeitos
Teste Manual
Scripts para Teste Manual
Teste Exploratório
Teste Exploratório de Escopo Reduzido
Teste Exploratório de Escopo Abrangente
Conclusão
Questões
Leitura Recomendada


Teste Manual
Conclusão
Questões
Leitura Recomendada

Origem dos Defeitos (1)
◮ Desde o inı́cio do processo de desenvolvimento do software

defeitos são introduzidos
◮ É claro que não se inicia o desenvolvimento com um software
perfeito e, posteriormente, os defeitos são introduzidos
◮ Segundo Harlan Mills, citado por Whittaker (2009) “a única
maneira de defeitos ocorrem em um programa é eles serem
introduzidos pelo seu autor”
◮ O primeiro software tinha defeitos, o último também tem, e,
dificilmente, existirá software livre de defeitos


Teste Manual
Conclusão
Questões
Leitura Recomendada

◮ É praticamente inevitável o desenvolvimento de software livre

de defeitos
◮ Como manter os defeitos fora do ecossistema de
desenvolvimento, minimizando as falhas e produzindo o
melhor software possı́vel?
◮ Duas categorias principais: prevenção de defeitos e
detecção de defeitos

◮ Geralmente orientada para o desenvolvedor

◮ Em geral, consiste de:
◮ escrever melhores especificações
◮ realizar revisão de código
◮ executar ferramentas de análise estática
◮ desenvolver e executar testes unitários (frequentemente de
forma automática)
◮ Todas elas sofrem de problemas fundamentais, apresentados
em seguida

Problemas para a Prevenção de Defeitos (1)

◮ Problema do desenvolvedor que desenvolve e executa os piores
testes
◮ Desenvolvedor detectar defeitos em seu próprio código é
suspeito
◮ Se ele é bom em detectar defeitos, ele não deveria ser bom em
não cometer enganos e introduzir defeitos?
◮ Trabalham na perpectiva de construir o sistema
◮ Nada melhor do que uma perspectiva diferente diferente para
detectar defeitos
◮ Perspectiva do testador é “como posso ‘quebrar’ o software”
ao invés da perspectiva do desenvolvedor que é “como posso
construir o software”
◮ Uso de Desenvolvimento Orientado a Teste (Test-Driven
Development – TDD e testes unitários podem ser feitos pelo
desenvolvedor
◮ Problema do software em repouso

◮ Revisão e análise estática avaliam o software em repouso
◮ Defeitos de operação (aspecto comportamental do programa)
não podem ser detectados com o software em “repouso”
◮ Vários defeitos são detectados quando o software é posto em
execução em seu ambiente operacional real

◮ Problema da falta de dados

◮ Software necessita de dados entrada para executar os vários
caminhos no código
◮ Quais partes do código são executadas dependem da entrada
fornecida, do estado interno do software, e influências externas
como banco de dados e arquivos de dados
◮ Em geral, o acúmulo de dados ao longo do tempo é que faz o
software falhar
◮ Como conseguir isso se o tempo para teste, em geral, é
bastante reduzido?
◮ Executar o software em um ambiente semelhante ao do usuário
e com dados tão rico como aqueles utilizados pelo mesmo
potencializa a detecção do defeito

Detecção de Defeitos (1)
◮ Duas formas de análise dinâmica

◮ Teste automatizado: escrever código de teste para testar um
software
◮ Teste manual: executa o software via interface gráfica e as
entradas são fornecidas manualmente

Teste Automatizado
◮ Estigma
◮ Teste é codificado: escrever teste significa que o testador é
também um desenvolvedor
◮ Desenvolvedores são bons testadores?
◮ Qual o tempo gasto para escrever os testes?
◮ Estima-se que para cada linha de código exista uma linha de
teste automatizado
◮ Respeito
◮ Automatização é interessante
◮ Uma vez desenvolvido o conjunto de teste, sua execução pode
ser repetida quantas vezes forem necessárias
◮ Produtividade com base no número de teste executado
versus na qualidade dos teste
◮ Problema do oráculo


Teste Manual
Conclusão
Questões
Leitura Recomendada

Teste Manual (1)
◮ Teste manual é aquele realizado na presença de um testador

◮ Testador utiliza seu cérebro, dedos e inteligência para criar
cenários que ou fazem o software falhar ou desempenhar sua
missão com sucesso
◮ Permite criar cenários realistas
◮ Usar dados reais em um ambiente real
◮ Reconhecer falhas óbvias e misteriosas
◮ Melhor escolha para encontrar defeitos relacionados com as
regras de negócio da aplicação

Teste Manual (2)
◮ Apesar de ser sensato, historicamente, o emprego de teste

manual não foi promissor
◮ Ele é muito lento, ad-hoc, não repetı́vel, não transferı́vel, e
não existem bons conselhos para se obter melhores resultados
◮ Teste Exploratório visa a superar tais limitações
◮ Objetiva sistematizar a forma como o teste manual é
conduzido

Script para Teste Manual (1)
◮ Grande parte do teste manual é executado por scripts

◮ São escritos antecipadamente
◮ Indicam como as saı́das obtidas podem ser verificadas em
relação a especificação
◮ Em geral, são documentados em planilhas e sofrem
manutenção em função de novas caracterı́sticas ou correção de
defeitos
◮ Scripts de teste podem ser demasiadamente rı́gidos para
grande parte das aplicações
◮ Scripts passam a ser escritos como um cenário geral,
oferecendo mais flexibilidade ao testados durante a execução

Teste Exploratório (1)
◮ Quando scritps são removidos completamente ou tornam-se

menos rı́gidos, o processo passa a ser chamado Teste
Exploratório
◮ Testadores podem interagir com a aplicação da forma como
quiserem e usar as informações obtidas para:
◮ Reagir
◮ Alterar o curso
◮ Explorar funcionalidades da aplicação sem repressão
◮ Pode parecer uma técnica ad-hoc mas uma vez dominada é
bastante poderosa em detectar defeitos

◮ Resultados de teste, casos de teste e documentação de teste

são geradas a medida que os testes são realizados
◮ Ferramentas de captura e reprodução (Capture & Playback),
captura de tela e registro de teclas são ideais para armazenar
os resultados do teste exploratório
◮ Ideais para o teste de aplicações web modernas, desenvolvida
seguindo metodologias ágeis
◮ Desenvolvimento em ciclos curtos implica em pouco tempo
para a escrita de scripts e manutenção dos mesmos

◮ Principal desvantagem é o risco do testador desperdiçar muito

tempo procurando por “coisas” para testar e tentar consertar
os defeitos
◮ Falta de preparação, estrutura e diretrizes podem levar a
improdutividade e reteste da mesma funcionalidade várias
vezes
◮ Sem documentação, como os testadores garantem que estão
atingindo uma boa cobertura das funcionalidades?
◮ Teste exploratório sem orientação é semelhante a um turista
em uma cidade desconhecida procurando por atrações
interessantes

◮ Duas diretrizes principais:

◮ Teste exploratório de escopo reduzido (exploratory testing in
the small)
◮ Teste exploratório de escopo abrangente (exploratory testing
in the large)

Teste Exploratório de Escopo Reduzido (1)
◮ Muitas das atividades do teste manual consiste em escolhas:

◮ Quais entradas utilizar?
◮ Que item do menu selecionar?
◮ Que página visitar?
◮ Quais valores serão utilizados em cada campo de um
formulário?
◮ Existem centenas dessas decisões que são tomadas durante a
execução de cada teste

Teste Exploratório de Escopo Reduzido (2)

◮ Quando se usa teste exploratório para responder a tais
questões, o mesmo é denominado Teste Exploratório de
Escopo Reduzido
◮ O escopo da decisão a ser tomada é bem restrito
◮ O problema é que muitos testadores não sabem tomar decisões
frente a uma variedade de situações que são encontradas
◮ Qual valor deve ser fornecido em um campo que aceita um
inteiro?
◮ 4 é melhor que 400?
◮ 0 ou um número negativo são valores especiais?
◮ Quais valores ilegais deveria ser utilizados?
◮ O conhecimento da aplicação influencia a decisão?
◮ Teste Exploratório de Escopo Reduzido visa a auxiliar em
responder tais questões
Teste Exploratório de Escopo Abrangente (1)
◮ Testar é mais do que tomar pequenas decisões

◮ Mesmo após resolver todas as questões de escopo reduzido, o
conjunto de teste resultante pode não ser suficiente para
confirmar que o produto está pronto para ser liberado
◮ Casos de teste estão inter-relacionados e um caso de teste
deveria ser combinado com outro de modo a obter um
conjunto de teste melhor
◮ Faz-se necessária um estratégia para guiar o testador no
projeto de casos de teste e exploração do produto em teste

Teste Exploratório de Escopo Abrangente (2)
◮ Problemas de interesse:
◮ Quais caracterı́sticas deveriam ser visitadas por um único caso
de teste?
◮ Existem funções ou caracterı́sticas que deveriam ser testadas
em conjunto?
◮ Quais caracterı́sticas deveriam ser usadas primeiro e quais
subsequentemente?
◮ Se existem vários testadores no projeto, como eles podem
atuar de maneira complementar, maximizando o esforço de
teste e minimizando a repetição dos testes?
◮ Denominado de escopo abrangente pois as decisões perpassam
o software como um todo ao invés de se concentrar em um
escopo restrito


Teste Manual
Conclusão
Questões
Leitura Recomendada

Conclusão
◮ Se realizado adequadamente, o teste exploratório combina as

vantagens do teste manual e a descoberta de defeitos ocultos,
questões de usabilidade, segurança, dentre outros
◮ Em geral essa exploração é realizada de forma ad-hoc ou
delegada a especialistas com décadas de experiência
◮ As diretrizes apresentadas sintetizam a experiência e sabedoria
acumulada facilitando novos especialistas produzirem
resultados de alta qualidade


Teste Manual
Conclusão
Questões
Leitura Recomendada

Questões
1. Por que simplesmente não se constrói um software para testar

automaticamente outro software? Por que a resposta para o
problema do teste de software não está na automação?
2. Que tipo de código é bom para ser testado com ferramentas
de automação de teste? Que tipo de código exige testes
manuais? Tente formular uma teoria que explique isso.
3. Que tipos de defeitos são detectados com os testes conduzidos
por ferramentas de automação de teste? Que tipos de defeitos
tais ferramentas são ruins em detectar? Exemplifique.


Teste Manual
Conclusão
Questões
Leitura Recomendada

Leitura Recomendada
Mais informações podem ser obtidas no Capı́tulo 2 de:
Exploratory Software Testing: Tips, Tricks,

Tours, and Techniques to Guide Test Design
James A. Whittaker
Addison-Wesley, Boston, MA, 2009.

Referências I
Whittaker, J. A. Exploratory software testing: Tips, tricks, tours, and techniques to guide test design.
Addison-Wesley Professional, 2009.


09 02 Teste Manual PDF

Enviado por

Dados do documento

Descrição original:

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

09 02 Teste Manual PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Organização Origem dos Defeitos de Software Prevenção e Detecção de Defeitos Teste Manual Conclusão Questões Leit

Teste Exploratório de Software

Vincenzi, Delamaro & Maldonado

Este material pode ser utilizado livremente respeitando-se a licença

Ver o Resumo da Licença | Ver o Texto Legal

Vincenzi, Delamaro & Maldonado

Origem dos Defeitos de Software

Prevenção e Detecção de Defeitos

Vincenzi, Delamaro & Maldonado

Origem dos Defeitos de Software

Prevenção e Detecção de Defeitos

Vincenzi, Delamaro & Maldonado

Origem dos Defeitos (1)

◮ Desde o inı́cio do processo de desenvolvimento do software

Vincenzi, Delamaro & Maldonado

Origem dos Defeitos de Software

Prevenção e Detecção de Defeitos

Vincenzi, Delamaro & Maldonado

Prevenção e Detecção de Defeitos

◮ É praticamente inevitável o desenvolvimento de software livre

Vincenzi, Delamaro & Maldonado

◮ Geralmente orientada para o desenvolvedor

Vincenzi, Delamaro & Maldonado

Problemas para a Prevenção de Defeitos (1)

Problemas para a Prevenção de Defeitos (2)

◮ Problema do software em repouso

Vincenzi, Delamaro & Maldonado

Problemas para a Prevenção de Defeitos (3)

◮ Problema da falta de dados

Vincenzi, Delamaro & Maldonado

Detecção de Defeitos (1)

◮ Duas formas de análise dinâmica

Vincenzi, Delamaro & Maldonado

Vincenzi, Delamaro & Maldonado

Origem dos Defeitos de Software

Prevenção e Detecção de Defeitos

Vincenzi, Delamaro & Maldonado

Teste Manual (1)

◮ Teste manual é aquele realizado na presença de um testador

Vincenzi, Delamaro & Maldonado

Teste Manual (2)

◮ Apesar de ser sensato, historicamente, o emprego de teste

Vincenzi, Delamaro & Maldonado

Scripts para Teste Manual

Script para Teste Manual (1)

◮ Grande parte do teste manual é executado por scripts

Vincenzi, Delamaro & Maldonado

Teste Exploratório (1)

◮ Quando scritps são removidos completamente ou tornam-se

Vincenzi, Delamaro & Maldonado

Teste Exploratório (2)

◮ Resultados de teste, casos de teste e documentação de teste

Vincenzi, Delamaro & Maldonado

Teste Exploratório (3)

◮ Principal desvantagem é o risco do testador desperdiçar muito

Vincenzi, Delamaro & Maldonado

Teste Exploratório (4)

◮ Duas diretrizes principais:

Vincenzi, Delamaro & Maldonado

Teste Exploratório de Escopo Reduzido

Teste Exploratório de Escopo Reduzido (1)

◮ Muitas das atividades do teste manual consiste em escolhas: