SlideShare uma empresa Scribd logo
1 de 53
- glossário
- definição
- abordagens
- planejamentos
- laboratório
agenda
Glossário
Glossário
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
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;
Definição
Definiçã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 de
testes 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 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.
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
Abordagens
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á 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
(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 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
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
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
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
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
Planejamentos
Planejamentos
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 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
Formato da Missão
Elisabeth 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 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);
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
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!
Ferramentas
Ferramentas
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
Laboratório

Mais conteúdo relacionado

Mais procurados

[ATC2021] Distribuição de Testes em Diferentes Camadas
[ATC2021] Distribuição de Testes em Diferentes Camadas[ATC2021] Distribuição de Testes em Diferentes Camadas
[ATC2021] Distribuição de Testes em Diferentes CamadasJúlio de Lima
 
An Introduction to Unit Testing
An Introduction to Unit TestingAn Introduction to Unit Testing
An Introduction to Unit TestingJoe Tremblay
 
Planejamento de testes em um mundo ágil
Planejamento de testes em um mundo ágilPlanejamento de testes em um mundo ágil
Planejamento de testes em um mundo ágilAriane Izac
 
Automation - web testing with selenium
Automation - web testing with seleniumAutomation - web testing with selenium
Automation - web testing with seleniumTzirla Rozental
 
Testes E2E em Cypress com JS
Testes E2E em Cypress com JSTestes E2E em Cypress com JS
Testes E2E em Cypress com JSNàtali Cabral
 
Chapter 4 - Test Design Techniques
Chapter 4 - Test Design TechniquesChapter 4 - Test Design Techniques
Chapter 4 - Test Design TechniquesNeeraj Kumar Singh
 
Testing strategy for agile projects updated
Testing strategy for agile projects updatedTesting strategy for agile projects updated
Testing strategy for agile projects updatedTharinda Liyanage
 
Automação de Teste em Front End - Caipira Ágil
Automação de Teste em Front End - Caipira ÁgilAutomação de Teste em Front End - Caipira Ágil
Automação de Teste em Front End - Caipira ÁgilElias Nogueira
 
Palestra ALATS SP - FIAP Teste de Software
Palestra ALATS SP - FIAP  Teste de SoftwarePalestra ALATS SP - FIAP  Teste de Software
Palestra ALATS SP - FIAP Teste de SoftwareElias Nogueira
 
Apresentacao Testes de Unidade
Apresentacao Testes de UnidadeApresentacao Testes de Unidade
Apresentacao Testes de UnidadeAline Ferreira
 
Mini curso de testes ágeis
Mini curso de testes ágeisMini curso de testes ágeis
Mini curso de testes ágeisQualister
 
Introdução à Qualidade e Testes Ágeis de Software
Introdução à Qualidade e Testes Ágeis de SoftwareIntrodução à Qualidade e Testes Ágeis de Software
Introdução à Qualidade e Testes Ágeis de SoftwareClaudia Melo
 

Mais procurados (20)

Test Automation - Keytorc Approach
Test Automation - Keytorc Approach Test Automation - Keytorc Approach
Test Automation - Keytorc Approach
 
Testing Tools
Testing ToolsTesting Tools
Testing Tools
 
[ATC2021] Distribuição de Testes em Diferentes Camadas
[ATC2021] Distribuição de Testes em Diferentes Camadas[ATC2021] Distribuição de Testes em Diferentes Camadas
[ATC2021] Distribuição de Testes em Diferentes Camadas
 
Exploratory testing workshop
Exploratory testing workshopExploratory testing workshop
Exploratory testing workshop
 
Carreira de QA
Carreira de QA Carreira de QA
Carreira de QA
 
An Introduction to Unit Testing
An Introduction to Unit TestingAn Introduction to Unit Testing
An Introduction to Unit Testing
 
Planejamento de testes em um mundo ágil
Planejamento de testes em um mundo ágilPlanejamento de testes em um mundo ágil
Planejamento de testes em um mundo ágil
 
Automation - web testing with selenium
Automation - web testing with seleniumAutomation - web testing with selenium
Automation - web testing with selenium
 
Testes E2E em Cypress com JS
Testes E2E em Cypress com JSTestes E2E em Cypress com JS
Testes E2E em Cypress com JS
 
Chapter 4 - Test Design Techniques
Chapter 4 - Test Design TechniquesChapter 4 - Test Design Techniques
Chapter 4 - Test Design Techniques
 
Testing strategy for agile projects updated
Testing strategy for agile projects updatedTesting strategy for agile projects updated
Testing strategy for agile projects updated
 
Automação de Teste em Front End - Caipira Ágil
Automação de Teste em Front End - Caipira ÁgilAutomação de Teste em Front End - Caipira Ágil
Automação de Teste em Front End - Caipira Ágil
 
Unit Testing in Java
Unit Testing in JavaUnit Testing in Java
Unit Testing in Java
 
testng
testngtestng
testng
 
Palestra ALATS SP - FIAP Teste de Software
Palestra ALATS SP - FIAP  Teste de SoftwarePalestra ALATS SP - FIAP  Teste de Software
Palestra ALATS SP - FIAP Teste de Software
 
Introduction & Manual Testing
Introduction & Manual TestingIntroduction & Manual Testing
Introduction & Manual Testing
 
Apresentacao Testes de Unidade
Apresentacao Testes de UnidadeApresentacao Testes de Unidade
Apresentacao Testes de Unidade
 
Mini curso de testes ágeis
Mini curso de testes ágeisMini curso de testes ágeis
Mini curso de testes ágeis
 
Introdução à Qualidade e Testes Ágeis de Software
Introdução à Qualidade e Testes Ágeis de SoftwareIntrodução à Qualidade e Testes Ágeis de Software
Introdução à Qualidade e Testes Ágeis de Software
 
Automation Testing
Automation TestingAutomation Testing
Automation Testing
 

Semelhante a ALM - Testes Exploratórios

Palestra - Testes de Usabilidade
Palestra - Testes de UsabilidadePalestra - Testes de Usabilidade
Palestra - Testes de UsabilidadeLuiz Agner
 
Automação de testes para equipes agile
Automação de testes para equipes agileAutomação de testes para equipes agile
Automação de testes para equipes agileAlini Rebonatto
 
IHM - INTERFACE HOMEM MÁQUINA TESTE DE USABILIDADE
IHM - INTERFACE HOMEM MÁQUINA TESTE DE USABILIDADEIHM - INTERFACE HOMEM MÁQUINA TESTE DE USABILIDADE
IHM - INTERFACE HOMEM MÁQUINA TESTE DE USABILIDADEFernandaRodriguesMac4
 
Mta1 aula-05 Avaliação Heurística
Mta1 aula-05 Avaliação HeurísticaMta1 aula-05 Avaliação Heurística
Mta1 aula-05 Avaliação HeurísticaAlan Vasconcelos
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de SoftwareRalph Rassweiler
 
Slides exemplodeprocessoscrum
Slides exemplodeprocessoscrumSlides exemplodeprocessoscrum
Slides exemplodeprocessoscrumSilas Dias
 
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...Isaac de Souza
 
Introdução aos fundamentos de teste de software 3
Introdução aos fundamentos de teste de software 3Introdução aos fundamentos de teste de software 3
Introdução aos fundamentos de teste de software 3Alain Ageev, SFPC
 
Aula 5 -Avaliação de interfaces de usuário - testes com usuários
Aula 5 -Avaliação de interfaces de usuário - testes com usuáriosAula 5 -Avaliação de interfaces de usuário - testes com usuários
Aula 5 -Avaliação de interfaces de usuário - testes com usuáriosAndré Constantino da Silva
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trataRoni Reis
 
Principais conceitos em testes de software
Principais conceitos em testes de softwarePrincipais conceitos em testes de software
Principais conceitos em testes de softwareJoyce Bastos
 
Teste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATSTeste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATSFabrício Campos
 

Semelhante a ALM - Testes Exploratórios (20)

Palestra - Testes de Usabilidade
Palestra - Testes de UsabilidadePalestra - Testes de Usabilidade
Palestra - Testes de Usabilidade
 
Automação de testes para equipes agile
Automação de testes para equipes agileAutomação de testes para equipes agile
Automação de testes para equipes agile
 
Conceitos de Usabilidade
Conceitos de UsabilidadeConceitos de Usabilidade
Conceitos de Usabilidade
 
IHM - INTERFACE HOMEM MÁQUINA TESTE DE USABILIDADE
IHM - INTERFACE HOMEM MÁQUINA TESTE DE USABILIDADEIHM - INTERFACE HOMEM MÁQUINA TESTE DE USABILIDADE
IHM - INTERFACE HOMEM MÁQUINA TESTE DE USABILIDADE
 
Testes de Usabilidade
Testes de UsabilidadeTestes de Usabilidade
Testes de Usabilidade
 
Usabilidade1
Usabilidade1Usabilidade1
Usabilidade1
 
Mta1 aula-05 Avaliação Heurística
Mta1 aula-05 Avaliação HeurísticaMta1 aula-05 Avaliação Heurística
Mta1 aula-05 Avaliação Heurística
 
Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
 
Slides exemplodeprocessoscrum
Slides exemplodeprocessoscrumSlides exemplodeprocessoscrum
Slides exemplodeprocessoscrum
 
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
 
DevQA: UI Testing , como fazer?
DevQA: UI Testing , como fazer?DevQA: UI Testing , como fazer?
DevQA: UI Testing , como fazer?
 
Aula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptxAula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptx
 
Framework
FrameworkFramework
Framework
 
Introdução aos fundamentos de teste de software 3
Introdução aos fundamentos de teste de software 3Introdução aos fundamentos de teste de software 3
Introdução aos fundamentos de teste de software 3
 
Interface Humano Computador - Aula03 - design de experiência de usuário e aná...
Interface Humano Computador - Aula03 - design de experiência de usuário e aná...Interface Humano Computador - Aula03 - design de experiência de usuário e aná...
Interface Humano Computador - Aula03 - design de experiência de usuário e aná...
 
Aula 5 -Avaliação de interfaces de usuário - testes com usuários
Aula 5 -Avaliação de interfaces de usuário - testes com usuáriosAula 5 -Avaliação de interfaces de usuário - testes com usuários
Aula 5 -Avaliação de interfaces de usuário - testes com usuários
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Principais conceitos em testes de software
Principais conceitos em testes de softwarePrincipais conceitos em testes de software
Principais conceitos em testes de software
 
Teste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATSTeste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATS
 

Mais de Alan Carlos

Jovens Empreendedores - StartUps
Jovens Empreendedores - StartUpsJovens Empreendedores - StartUps
Jovens Empreendedores - StartUpsAlan Carlos
 
Cloud Computing - Pratices & Patterns
Cloud Computing - Pratices & PatternsCloud Computing - Pratices & Patterns
Cloud Computing - Pratices & PatternsAlan Carlos
 
Alfabetização Digital
Alfabetização DigitalAlfabetização Digital
Alfabetização DigitalAlan Carlos
 
TechNet Wiki Summit 2015 - DevOps
TechNet Wiki Summit 2015 - DevOpsTechNet Wiki Summit 2015 - DevOps
TechNet Wiki Summit 2015 - DevOpsAlan Carlos
 
TechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerTechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerAlan Carlos
 
Workshop - Plano de Testes End to End com o Microsoft Test Manager
Workshop   - Plano de Testes End to End com o Microsoft Test ManagerWorkshop   - Plano de Testes End to End com o Microsoft Test Manager
Workshop - Plano de Testes End to End com o Microsoft Test ManagerAlan Carlos
 
Workshop - Testes de Segurança
Workshop - Testes de SegurançaWorkshop - Testes de Segurança
Workshop - Testes de SegurançaAlan Carlos
 
ALM e Operações - Workshop - Como Diagnosticar um Incidente
ALM e Operações - Workshop - Como Diagnosticar um IncidenteALM e Operações - Workshop - Como Diagnosticar um Incidente
ALM e Operações - Workshop - Como Diagnosticar um IncidenteAlan Carlos
 
Operações - Base de Conhecimento - Parte 02
Operações - Base de Conhecimento - Parte 02Operações - Base de Conhecimento - Parte 02
Operações - Base de Conhecimento - Parte 02Alan Carlos
 
Operações - Base de Conhecimento - Parte 01
Operações - Base de Conhecimento - Parte 01Operações - Base de Conhecimento - Parte 01
Operações - Base de Conhecimento - Parte 01Alan Carlos
 
ALM Summit - DevOps - VSALM e System Center Um Casamento de Sucesso
ALM Summit - DevOps - VSALM e System Center Um Casamento de SucessoALM Summit - DevOps - VSALM e System Center Um Casamento de Sucesso
ALM Summit - DevOps - VSALM e System Center Um Casamento de SucessoAlan Carlos
 
Geração Tec - Help Desk - Tenha um Helpdesk de Qualidade
Geração Tec - Help Desk - Tenha um Helpdesk de QualidadeGeração Tec - Help Desk - Tenha um Helpdesk de Qualidade
Geração Tec - Help Desk - Tenha um Helpdesk de QualidadeAlan Carlos
 
Geração TEC - Help Desk - Fundamentos do ITIL - IR, CR e Problemas, Medição ...
Geração TEC -  Help Desk - Fundamentos do ITIL - IR, CR e Problemas, Medição ...Geração TEC -  Help Desk - Fundamentos do ITIL - IR, CR e Problemas, Medição ...
Geração TEC - Help Desk - Fundamentos do ITIL - IR, CR e Problemas, Medição ...Alan Carlos
 
Geração Tec - Help Desk - Principais Ferramentas Técnicas e Erros Comuns
Geração Tec  - Help Desk - Principais Ferramentas Técnicas e Erros ComunsGeração Tec  - Help Desk - Principais Ferramentas Técnicas e Erros Comuns
Geração Tec - Help Desk - Principais Ferramentas Técnicas e Erros ComunsAlan Carlos
 
Geração Tec Help Desk - Base de Conhecimento, Scripts e Estratégias de Aten...
Geração Tec   Help Desk - Base de Conhecimento, Scripts e Estratégias de Aten...Geração Tec   Help Desk - Base de Conhecimento, Scripts e Estratégias de Aten...
Geração Tec Help Desk - Base de Conhecimento, Scripts e Estratégias de Aten...Alan Carlos
 
Geração TEC - Help Desk - Hardwares e Sistemas Operacionais
Geração TEC - Help Desk - Hardwares e Sistemas OperacionaisGeração TEC - Help Desk - Hardwares e Sistemas Operacionais
Geração TEC - Help Desk - Hardwares e Sistemas OperacionaisAlan Carlos
 
Geração TEC Help Desk - Hardwares e Sistemas Operacionais
Geração TEC Help Desk - Hardwares e Sistemas OperacionaisGeração TEC Help Desk - Hardwares e Sistemas Operacionais
Geração TEC Help Desk - Hardwares e Sistemas OperacionaisAlan Carlos
 
Geração TEC - Help Desk - Ambientes e Sistemas
Geração TEC - Help Desk - Ambientes e SistemasGeração TEC - Help Desk - Ambientes e Sistemas
Geração TEC - Help Desk - Ambientes e SistemasAlan Carlos
 
ALM - Visual Studio - Indicadores - Como Usar
ALM - Visual Studio - Indicadores - Como UsarALM - Visual Studio - Indicadores - Como Usar
ALM - Visual Studio - Indicadores - Como UsarAlan Carlos
 
Apresentação - IT Specialist
Apresentação - IT SpecialistApresentação - IT Specialist
Apresentação - IT SpecialistAlan Carlos
 

Mais de Alan Carlos (20)

Jovens Empreendedores - StartUps
Jovens Empreendedores - StartUpsJovens Empreendedores - StartUps
Jovens Empreendedores - StartUps
 
Cloud Computing - Pratices & Patterns
Cloud Computing - Pratices & PatternsCloud Computing - Pratices & Patterns
Cloud Computing - Pratices & Patterns
 
Alfabetização Digital
Alfabetização DigitalAlfabetização Digital
Alfabetização Digital
 
TechNet Wiki Summit 2015 - DevOps
TechNet Wiki Summit 2015 - DevOpsTechNet Wiki Summit 2015 - DevOps
TechNet Wiki Summit 2015 - DevOps
 
TechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerTechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test Manager
 
Workshop - Plano de Testes End to End com o Microsoft Test Manager
Workshop   - Plano de Testes End to End com o Microsoft Test ManagerWorkshop   - Plano de Testes End to End com o Microsoft Test Manager
Workshop - Plano de Testes End to End com o Microsoft Test Manager
 
Workshop - Testes de Segurança
Workshop - Testes de SegurançaWorkshop - Testes de Segurança
Workshop - Testes de Segurança
 
ALM e Operações - Workshop - Como Diagnosticar um Incidente
ALM e Operações - Workshop - Como Diagnosticar um IncidenteALM e Operações - Workshop - Como Diagnosticar um Incidente
ALM e Operações - Workshop - Como Diagnosticar um Incidente
 
Operações - Base de Conhecimento - Parte 02
Operações - Base de Conhecimento - Parte 02Operações - Base de Conhecimento - Parte 02
Operações - Base de Conhecimento - Parte 02
 
Operações - Base de Conhecimento - Parte 01
Operações - Base de Conhecimento - Parte 01Operações - Base de Conhecimento - Parte 01
Operações - Base de Conhecimento - Parte 01
 
ALM Summit - DevOps - VSALM e System Center Um Casamento de Sucesso
ALM Summit - DevOps - VSALM e System Center Um Casamento de SucessoALM Summit - DevOps - VSALM e System Center Um Casamento de Sucesso
ALM Summit - DevOps - VSALM e System Center Um Casamento de Sucesso
 
Geração Tec - Help Desk - Tenha um Helpdesk de Qualidade
Geração Tec - Help Desk - Tenha um Helpdesk de QualidadeGeração Tec - Help Desk - Tenha um Helpdesk de Qualidade
Geração Tec - Help Desk - Tenha um Helpdesk de Qualidade
 
Geração TEC - Help Desk - Fundamentos do ITIL - IR, CR e Problemas, Medição ...
Geração TEC -  Help Desk - Fundamentos do ITIL - IR, CR e Problemas, Medição ...Geração TEC -  Help Desk - Fundamentos do ITIL - IR, CR e Problemas, Medição ...
Geração TEC - Help Desk - Fundamentos do ITIL - IR, CR e Problemas, Medição ...
 
Geração Tec - Help Desk - Principais Ferramentas Técnicas e Erros Comuns
Geração Tec  - Help Desk - Principais Ferramentas Técnicas e Erros ComunsGeração Tec  - Help Desk - Principais Ferramentas Técnicas e Erros Comuns
Geração Tec - Help Desk - Principais Ferramentas Técnicas e Erros Comuns
 
Geração Tec Help Desk - Base de Conhecimento, Scripts e Estratégias de Aten...
Geração Tec   Help Desk - Base de Conhecimento, Scripts e Estratégias de Aten...Geração Tec   Help Desk - Base de Conhecimento, Scripts e Estratégias de Aten...
Geração Tec Help Desk - Base de Conhecimento, Scripts e Estratégias de Aten...
 
Geração TEC - Help Desk - Hardwares e Sistemas Operacionais
Geração TEC - Help Desk - Hardwares e Sistemas OperacionaisGeração TEC - Help Desk - Hardwares e Sistemas Operacionais
Geração TEC - Help Desk - Hardwares e Sistemas Operacionais
 
Geração TEC Help Desk - Hardwares e Sistemas Operacionais
Geração TEC Help Desk - Hardwares e Sistemas OperacionaisGeração TEC Help Desk - Hardwares e Sistemas Operacionais
Geração TEC Help Desk - Hardwares e Sistemas Operacionais
 
Geração TEC - Help Desk - Ambientes e Sistemas
Geração TEC - Help Desk - Ambientes e SistemasGeração TEC - Help Desk - Ambientes e Sistemas
Geração TEC - Help Desk - Ambientes e Sistemas
 
ALM - Visual Studio - Indicadores - Como Usar
ALM - Visual Studio - Indicadores - Como UsarALM - Visual Studio - Indicadores - Como Usar
ALM - Visual Studio - Indicadores - Como Usar
 
Apresentação - IT Specialist
Apresentação - IT SpecialistApresentação - IT Specialist
Apresentação - IT Specialist
 

ALM - Testes Exploratórios

  • 1.
  • 2. - glossário - definição - abordagens - planejamentos - laboratório agenda
  • 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;
  • 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.
  • 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.
  • 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
  • 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
  • 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.
  • 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
  • 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!
  • 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.