O documento discute técnicas de teste exploratório, incluindo: 1) O que é teste exploratório e quando deve ser usado; 2) Elementos do teste exploratório como exploração do produto e projeto de teste; 3) Requisitos do testador e do software para teste exploratório.

2. - glossário
- definição
- abordagens
- planejamentos
- laboratório
agenda

3. Glossário
Glossário

4. Glossário
Suíte de Testes: Conjunto de Casos de Testes.
Ex.: Suíte de Testes Exploratórios, Suíte de Testes de Desempenho, Suíte de
Testes de Relatórios. Ficando a critério do Analista de Testes quais Casos fazem
parte da Suíte em questão.
Cenário de Testes: É a situação a ser testada.
Ex.: DOC para Conta Corrente
Pode se ter Passos do Cenário para se criar os Casos de Testes:
1. Consultar o saldo da conta de origem;
2. Consultar o saldo da conta destino;
3. Transferir um valor da conta origem para conta destino;
4. Consultar novamente o saldo da conta origem, verificando que o saldo
inicial menos o valor transferido é igual ao saldo atual;
5. Consultar o saldo da conta destino, verificando que o saldo inicial
acrescido do valor transferido é igual ao saldo atual;
Glossário

5. Glossário
Casos de Testes: É um conjunto de condições usadas para o teste de software
Ex.: CT01 - Validação de CPF
Script de Testes/Passos do Caso de Testes: É o descritivo de como deve ser feito
o Caso de teste descrito. O mais formal deve conter entrada, saída e resultado
esperado.
Ex: CT01 – Validação de CPF
Abra seu navegador;
Digite o endereço http://internetbanking.com;
No campo conta corrente, digite a conta 01212;
No campo senha, digite a senha abcdef;
Clique em OK;
Logo que abrir o Menu, vá na opção Transferência  DOC;
No campo CPF, digite o numero 000.000.000-00;
Clique em “Verificar CPF”;
Resultado: Deverá aparecer a mensagem “CPF Inválido, favor confirmar”.
Clique em OK;
Clique em Log OFF;
Feche seu navegador;

6. Definição
Definição

7. O termo Teste Exploratório, preconizado por Cem Kaner no livro
Testing Computer Software, refere-se a uma abordagem de teste muito diferente
do teste orientado, ou teste com roteiro.
Ao invés de realizar uma análise sequencial de necessidades, seguida pela
concepção, documentação e execução de casos de teste, o teste exploratório
foi definido, por James Bach (2009), como um processo em que o testador
aprende, elabora o design do teste e executa simultaneamente enquanto explora
o produto.
O que é?

8. Quando usar?
Para Bach (2009) o teste exploratório deve ser utilizado nas seguintes situações:
· Necessidade em fornecer feedback rápido sobre um novo produto ou serviço;
· Necessidade de aprender o produto rapidamente;
· Diversificar os testes e melhorá-los;
· Encontrar o erro mais importante no menor espaço de tempo;
· Investigar e isolar um defeito específico;
· Investigar a situação de risco em especial, a fim de avaliar a necessidade de
testes com script nessa área;

9. Quando usar?
- Realização de testes quando não existem requisitos;
- Realização de testes quando existe pouco tempo disponível;
- Realização de testes quando não se conhece o aplicativo a ser testado;
- Realização de testes em ambientes pouco testados pelos testes convencionais;
- Identificação dos passos para tentar reproduzir um defeito aleatório;
- Diagnóstico de comportamentos inesperados;
- Investigação de efeitos colaterais;
- Investigação de defeitos semelhantes;
- Medição de riscos;

10. Elementos do Teste Exploratório
- Exploração do produto: descobrir e registrar o objetivo e as funções do produto,
tipos de dados processados e áreas de potencial instabilidade. Esta fase depende
do entendimento da tecnologia utilizada, informações sobre o produto e usuários,
e a quantidade de tempo disponível para fazer o trabalho;
- Projeto de teste: determinar as estratégias de operação, observação e avaliação
do produto;
- Execução do teste: operar o produto, observar o comportamento e utilizar
informações para formar hipóteses de como o produto funciona;
- Heurísticas: são guias ou regras que ajudam o testador a decidir o que fazer, o
que deverá ser testado e como testá-lo;
- Resultados: é o resultado do teste. Este é finalizado uma vez que o testador
produziu resultados que atendam os requisitos especificados.

11. Requisitos

12. Requisitos do Testador
Criatividade
testador
Observação cuidadosa
Metódico
Pensamento crítico
Aprendizado rápido
Intuição
Improviso
Autogerenciamento

13. Requisitos do Software
Para que o teste exploratório ocorra, é necessário que o
software ou parte dele já tenha sido desenvolvido.
(funcionalidade, tela, etc.).
software
Como normalmente não há documentação nesse
caso, a única fonte de informação é o próprio
software.

14. Abordagens
Abordagens

15. Heurísticas

16. Exemplos de Estratégias:
- Heurística HICCUPPS (Michael Bolton);
- Heurística IOSC;
- Heurística de consistência;
- Atributos da Qualidade (Ex: Heurística de Usabilidade de Nielsen);
- Outras...
Heurísticas (Estratégias)

17. (H)istory: As funcionalidades do software devem se comportar de forma
consistente ao longo do tempo;
(I)mage: O comportamento e aparência do software está alinhada
com a imagem que o fabricante deseja expor ao usuário;
(C)omparable products: O software é compatível com software similares;
(C)laims: O software se comporta de acordo com os requisitos;
(U)ser expectation: As funcionalidades se comportam conforme a
expectativa do usuário;
(P)roduct itself: As funcionalidades são consistentes entre si;
(P)urpose: As funcionalidades atendem o seu propósito;
(S)tatuses: O produto está em conformidade, com leis, regulamentos,
diretrizes, etc.
Heurística HICUPPS

18. (I)nput: Exploração do comportamento do software sob a perspectiva das
entradas de dados;
(O)utput: Exploração do comportamento do software sob a perspectiva das
saídas de dados;
(S)torage: Exploração do comportamento do software sob a perspectiva dos
dados armazenados;
(C)omputation: Exploração do comportamento do software sob a perspectiva
da computação/processamento dos dados.
Heurística IOSC

19. Consistência é uma das Heurísticas de Nielsen e significa que o mesmo
comando ou ação deve ter sempre o mesmo efeito e se localizar sempre no
mesmo lugar. A consistência melhora o reconhecimento, o aprendizado, a
memorização e transmite até mais credibilidade ao usuário do sistema.
Existem quatro espécies de consistências:
- Consistência Estética: O estilo e a aparência aumentam o reconhecimento e
comunicam de uma forma bem mais efetiva a mensagem. Um exemplo de
consistência estética seria a mesma escala de cores usadas por empresas do
mesmo ramo, facilitando o reconhecimento por parte do usuário/cliente;
- Consistência Funcional: Mesmas ações com significados iguais melhoram a
usabilidade e a funcionalidade para que os usuários aproveitem ao máximo a
interface. Controles remotos e aparelhos tocadores de mp3 possuem a mesma
linguagem, havendo consistência de informação;
Heurística de Consistência

20. Consistência Interna: Unidade visual interna no ambiente a ser projetado. Um
site, por exemplo, deve ter a localização dos seus elementos internos e o uso
das cores de forma padronizada;
Consistência Externa: Um ambiente quando for projetado fora do seu lugar
comum deve ter a mesma consistência para haver o reconhecimento por parte
do usuário. Por exemplo, um banner referente a um site, ele deve ter a mesma
representação em todos os sites externos nos quais ele se apresentar, para o
usuário reconhecê-lo e poder acessá-lo.
Heurística de Consistência

21. 1. Visibilidade de Status do Sistema
Isso significa que você precisa se certificar de que a interface sempre informe
ao usuário o que está acontecendo, ou seja, todas as ações precisam de
feedback instantâneo para orientá-lo.
2.Relacionamento entre a interface do sistema e o mundo real
Ou não usar palavras de sistema, que não fazem sentido pro usuário. Toda a
comunicação do sistema precisa ser contextualizada ao usuário, e ser coerente
com o chamado modelo mental do usuário.
3. Liberdade e controle do usuário
Facilite as “saídas de emergência” para o usuário, permitindo desfazer ou
refazer a ação no sistema e retornar ao ponto anterior, quando estiver perdido
ou em situações inesperadas.
4. Consistência
Fale a mesma língua o tempo todo, e nunca identifique uma mesma ação com
ícones ou palavras diferentes. Trate coisas similares, da mesma maneira,
facilitando a identificação do usuário.
Heurística Atributos da Qualidade
As 10 Heurísticas de Usabilidade de Nielsen

22. 5. Prevenção de erros
Na tradução livre das palavras do próprio Nielsen “Ainda melhor que uma boa
mensagem de erro é um design cuidadoso que possa prevenir esses erros”. Por
exemplo, ações definitivas, como deleções ou solicitações podem vir
acompanhadas de um checkbox ou uma mensagem de confirmação.
6. Reconhecimento ao invés de lembrança
Evite acionar a memória do usuário o tempo inteiro, fazendo com que cada
ação precise ser revista mentalmente antes de ser executada. Permita que a
interface ofereça ajuda contextual, e informações capazes de orientar as ações
do usuário – ou seja – que o sistema dialogue com o usuário.
7. Flexibilidade e eficiência de uso
O sistema precisa ser fácil para usuários leigos, mas flexível o bastante para se
tornar ágil à usuários avançados. Essa flexibilidade pode ser conseguida com a
permissão de teclas de atalhos, por exemplo. No caso de websites, uso de
máscaras e navegação com tab em formulários são outros exemplos.
Heurística Atributos da Qualidade

23. 8. Estética e design minimalista
Evite que os textos e o design fale mais do que o usuário necessita saber. Os
“diálogos” do sistema precisam ser simples, diretos e naturais, presentes nos
momentos em que são necessários.
9. Ajude os usuários a reconhecer, diagnosticar e sanar erros
As mensagens de erro do sistema devem possuir uma redação simples e clara
que ao invés de intimidar o usuário com o erro, indique uma saída construtiva
ou possível solução.
10. Ajuda e documentação
Um bom design deveria evitar ao máximo à necessidade de ajuda na utilização
do sistema. Ainda assim, um bom conjunto de documentação e ajuda deve ser
utilizado para orientar o usuário em caso de dúvida. Deve ser visível,
facilmente acessada, e com oferecer uma ferramenta de busca na ajuda.
Heurística Atributos da Qualidade

24. Teste Oracle

25. Teste Oracle é uma técnica comumente empregada para auxiliar o testador a
predizer o funcionamento supostamente correto do aplicativo ou de
determinada função do aplicativo.
A idéia fundamental dos Test Oracles é garantir consistência por meio da
observação e comparação. Digamos, por exemplo, que um novo portal de
vendas online está sendo construído para substituir um outro mais antigo.
Durante a realização dos testes do novo portal, o portal antigo sempre será
usado como referência. Ele será um Test Oracle para garantir que o
comportamento do novo portal seja consistente.
Por outro lado, vamos supor que um aplicativo de contabilidade sempre exibe
um preview dos relatórios antes iniciar a impressão. O Test Oracle nesse caso é
a consistência desse comportamento em todo o aplicativo, ou seja,
poderíamos considerar um defeito caso algum relatório não exibisse o preview
antes de iniciar a impressão.
Teste Oracle

26. - Consistência com a proposta: o comportamento deve ser consistente com a
sua proposta;
- Consistência com o resto do aplicativo: o comportamento deve ser
consistente com o comportamento de outras áreas do aplicativo;
- Consistência histórica: o comportamento deve ser consistente ao longo do
tempo;
- Consistência com aplicativos semelhantes: o comportamento deve ser
consistente com o comportamento de aplicativos similares, concorrentes, etc.
Teste Oracle

27. Testes Não Funcional – Função Processamento de Arquivos TXT
Histórico: Versão 1.0
Requisito/Especificação: Não há
Ambiente: Processador Xeon 1,5 GHZ – HD 1 TB 7200 RPM, 04 GB de RAM,
Windows 2003 x64 Enterprise Edition – SQL Server 2008 R2 x64 Standard
Edition
Massa: 1000 arquivos TXT de 1 kb
Tempo de Processamento: 10 segundos
Current: Versão 2.0
Requisito/Especificação: Não há
Ambiente: Processador Xeon 1,5 GHZ – HD 1 TB 7200 RPM, 04 GB de RAM,
Windows 2003 x64 Enterprise Edition – SQL Server 2008 R2 x64 Standard
Edition
Massa: 1000 arquivos TXT de 1 kb
Tempo de Processamento: 100 segundos
Exemplo

28. Planejamentos
Planejamentos

29. Testes Baseados em Seção (SBTM)

30. Durante a jornada de estudos sobre o teste exploratório, Bach (2009) percebeu
que testadores faziam muitas coisas durante o dia além de testar. Para monitorar
os testes, seria preciso encontrar uma forma de distinguir o teste de qualquer
outra coisa. Foi quando surgiu a idéia das seções.
Uma seção não é um caso de teste ou registro de um bug, mas uma unidade
básica de teste. Um bloco ininterrupto, revisável e objetivo de um esforço de
teste.
As seções de teste são divididas em três tipos de tarefas (Bach 2009) (Crispin
2009): Design e Execução, Investigação e Report de bugs e Setup da sessão, que
são chamadas de TBS (Task Breakdown Structure). Após, é necessário que os
testadores estimem o tempo gasto para cada tipo de tarefa. Isso inclui, também,
os tempos gastos em missões associadas às seções e o tempo de teste gasto em
oportunidades, ou seja, o tempo despendido a qualquer teste que não esteja
descrito na missão da sessão.
Session-Based Test Management (SBTM)
sbtm

31. Setup da seção, Design (Modelagem) e Execução, Investigação e Report de bugs,
que são chamadas de TBS (Task Breakdown Structure).
Session-Based Test Management (SBTM)
sbtm

32. Missão: Objetivo do Teste. Ex.: analisar uma função, ou procurar um problema
particular, ou verificar um conjunto de bugs consertados.
Tempo da Seção: Média de 45 à 120 minutos. Sendo que 45 minutos é
classificado como seção curta e mais de 02 horas classificado como seção
longa.
Passos: Não há.
Registros: Para saber quais tarefas foram realizadas durante o teste, é
necessário que os testadores as reportem de forma genérica. O testador
precisa registrar a atividade executada, reações do sistema, dados utilizados,
condições, diagnósticos ou idéias.
Características SBTM

33. Não deve ser muito específica nem muito genérica;
A missão determina o que deve ser testado (não como o teste deve ser
realizado);
Ao final da seção de teste exploratório, novas idéias, oportunidades ou
problemas encontrados pelo testador podem ser usados para a criação de
novas missões;
Importante que sempre tenha uma reunião de alinhamento após a conclusão
das missões para discutirem os vídeos gravados, anotações feitas, possíveis
erros identificados.
Missão

34. Formato da Missão
Elisabeth Hendrickson recomenda...

35. Seção - Etapas
Preparação (Setup): Preparação do ambiente de testes, configuração de
massa de dados, leitura de manuais, requisitos, diagramas, etc.
Especificação (Design): Definição (modelo mental) dos casos de testes
(hipóteses) baseados em heurísticas, idéias, checklists, etc.
Execução (Execution): Execução propriamente dita do teste exploratório para
demonstrar se as hipóteses/expectativas foram atendidas (ou não).
Oportunidades (Opportunities): Tempo gasto em atividades, explorações,
investigações que não estão no escopo ou foco da missão.
Relato de defeitos (Bug investigation/Report): Investigação e registro de
defeitos.

36. Pontos de Testes (sbtm)

37. Pontos de Testes
Lyndsay (2009) introduz um conceito importante que contribuiu ao método
de Bach (2009), que são os pontos de teste (test points) com o objetivo de
controlar o escopo do teste.
No projeto no qual Lyndsay (2009) participou não existia uma lista de teste
nem tampouco requisitos do software e histórico de testes realizados. Para
que ele pudesse controlar o que estava sendo testado, foi necessário levantar
os aspectos que deveriam ser explorados e identificar as fontes de apoio
(oracles/sources).
test points

38. Pontos de Testes
Com base nessas informações, partiu-se para elaboração dos test points que
teriam como características:
- Um test point levaria entre 20 minutos à 4 horas. Esta estimativa de tempo é
feita no momento em que o ponto de teste é definido. Pode ser redefinido
durante os testes;
- Cada test point possui uma escala de risco. Esta avaliação também é feita
como parte do processo de definição do ponto de teste;
- Cada trabalho de teste está relacionado a test point. Pode conter um ou
vários pontos que deverão ser investigados durante o tempo da seção.
O que difere um ponto de teste de uma seção é que o primeiro está
relacionado com a unidade de trabalho, enquanto que o segundo com a
unidade de tempo (Lyndsay 2009);

39. Pontos de Testes
- Um ponto de teste pode ser repetido e uma seção de testes está prevista,
acontece e é registrada;
- A lista de test points é dinâmica, ou seja, novos pontos são adicionados com
base em erros encontrados e correções. Além disso, uma nova compreensão
da funcionalidade do software pelo testador é adquirida durante a
exploração.

40. Resultados
Durante o teste exploratório o testador registra os resultados no Relatório da
Seção.
O relatório inclui notas sobre o que foi testado, o ambiente de testes, arquivos
de dados, defeitos encontrados, algumas métricas básicas, etc.
reports

41. Exemplos – Missão Teste Exploratório

42. Exemplos – Relatório da Seção

43. Reunião de Alinhamento
Após a conclusão da missão ou missões, deve-se realizar uma reunião de
alinhamento com o Analista de Testes e/ou Gerência de Testes afim de
discutir os resultados para:
- Registrar possíveis falhas;
- Criar possíveis casos de testes formais;
- Criar novas missões;
- Registrar possíveis requisitos;
- Registrar novos tests points.

44. Reunião de Alinhamento
Para auxiliar, pode-se realizar a reunião de alinhamento, usando o método
PROOF.

45. Fluxo de Testes Exploratórios

46. Testes Free Style (AD-HOC)

47. Estilo Livre (Free Style)
O teste exploratório estilo livre (Free Style) é o oposto do teste exploratório
baseado em sessões.
Nesta modalidade, não existe nenhuma definição formal de quanto tempo ou
o que será testado. Esta abordagem é normalmente utilizada por testadores
realmente experientes para identificar defeitos críticos quando não existe
muito tempo para a criação de estratégias formais.

48. Características
- Não possui script de execução;
- Não tem tempo de execução;
- Deve ser executado por pessoas que possuem experiência e conhecimento;
- Deve ser de preferência gravado ou descrito após a execução para relatar o
bug que foi detectado;
- Deve-se repetir os passos mais de uma vez para avaliar se o bug identificado
ocorre novamente;

49. Exemplo Testes AD-HOC
Veja para mim rapidinho se os relatórios estão
funcionando!

50. Ferramentas
Ferramentas

51. Ferramentas

52. Ferramentas
Gravador de passos do Windows – para gravar as atividades passo a passo e
gerar um relatório para enviar ao desenvolvedor
Session Tester – Ajuda a controlar as sessões e gera relatórios HTML
Rapid Reporter – Ferramenta para ajudar a gerar relatórios
Testpad – Ferramenta para ajudar a estruturar o planejamento de teste.
Kanbanflow – Painel online de KANBAN para ajudar a organizar atividades.

53. Lab
Laboratório