TestesExploratórios

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

agenda

Glossário

Glo

ssár

io

Glo

ssár

io

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 saldoinicial menos o valor transferido é igual ao saldo atual;5. Consultar o saldo da conta destino, verificando que o saldo inicialacrescido do valor transferido é igual ao saldo atual;

Glossário

Glo

ssár

io

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;

Definição

Defi

niçã

o

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 é?

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 detestes com script nessa área;

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;

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 dependedo 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 utilizarinformaçõ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 testadorproduziu resultados que atendam os requisitos especificados.

Requisitos

Requisitos do Testador

Criatividade

testador

Observação cuidadosa

Metódico

Pensamento crítico

Aprendizado rápido

Intuição

Improviso

Autogerenciamento

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.

Abordagens

Abor

dage

ns

Heurísticas

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)

(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á alinhadacom 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 aexpectativa 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

(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

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

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

1. Visibilidade de Status do SistemaIsso 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 realOu 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árioFacilite 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ênciaFale 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 QualidadeAs 10 Heurísticas de Usabilidade de Nielsen

5. Prevenção de errosNa 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çaEvite 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 usoO 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

8. Estética e design minimalistaEvite 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 errosAs 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

Teste Oracle

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

- 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

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 EditionMassa: 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 EditionMassa: 1000 arquivos TXT de 1 kb Tempo de Processamento: 100 segundos

Exemplo

Planejamentos

Plan

ejam

ento

s

Testes Baseados em Seção (SBTM)

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

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

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

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 denovas 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

Formato da MissãoElisabeth Hendrickson recomenda...

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.

Pontos de Testes (sbtm)

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

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 redefinidodurante os testes;

- Cada test point possui uma escala de risco. Esta avaliação também é feitacomo 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);

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.

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

Exemplos – Missão Teste Exploratório

Obs.: Os tests points devem ser testados conforme o risco, sendo os de maior

risco primeiro, pois normalmente requer mais tempo, além de ser mais

importante para o negócio.

Exemplos – Relatório da Seção

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.

Reunião de Alinhamento

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

Fluxo de Testes Exploratórios

Testes Free Style (AD-HOC)

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.

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;

Exemplo Testes AD-HOC

Veja para mim rapidinho se os relatórios estão funcionando!

Dê uma geral e veja se está tudo OK!

Teste como um todo!

Teste o que der e vamos liberar assim mesmo!

Ferramentas

Ferr

amen

tas

Ferramentas

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.

Lab

Labo

rató

rio