10_tecnicas_baseadas_experiencia

Prévia do material em texto

1
Técnicas de teste
BASEADAS NA 
EXPERIÊNCIA
conteúdo
1. Previsão de Erros
2. Teste Exploratório
3. Teste Baseado em Checklist
2
previsão
DE ERROS
TÉNICAS DE TESTE
Particionamento de 
Equivalência (PE)
Análise de Valores Limite 
(AVL)
Teste de Tabela de 
Decisão
Teste de Transição de 
Estado
CAIXA PRETA
Teste de Comandos 
e Cobertura de 
Comandos
Testes de Desvios e 
Cobertura de Desvios
CAIXA BRANCA
Previsão de Erros
Teste Exploratório
BASEADO NA 
EXPERIÊNCIA
Teste Baseado em 
Checklist
TÉCNICAS DE TESTE
3
TÉNICAS DE TESTE | BASEADO NA EXPERIÊNCIA
• Técnicas menos formais em comparação 
às discutidas anteriormente.
• Baseiam-se no conhecimento, habilidades, 
intuição e experiência dos testadores.
• Utilizam a experiência com produtos 
semelhantes ou o mesmo produto.
CAIXA PRETA
CAIXA BRANCA
BASEADO NA 
EXPERIÊNCIA
TÉCNICAS DE TESTE
TÉNICAS DE TESTE | BASEADO NA EXPERIÊNCIA
• Facilitam a identificação de falhas ou defeitos 
difíceis de detectar com técnicas mais 
estruturadas.
• Comumente usadas por testadores.
• A eficácia dessas técnicas depende muito da 
abordagem e experiência individual dos 
testadores.
CAIXA PRETA
CAIXA BRANCA
BASEADO NA 
EXPERIÊNCIA
TÉCNICAS DE TESTE
4
PREVISÃO DE ERROS (ERROR GUESSING)
• Técnica mais simples baseada na 
experiência do testador;
• Sem planejamento prévio ou necessidade 
de gerenciamento específico;
• O testador prediz os possíveis tipos de 
erros, defeitos ou falhas.
BASE DE PREVISÃO
• Funcionamento atual de um componente, 
sistema em teste ou versões anteriores em 
produção;
• Erros típicos conhecidos pelo testador 
cometidos por desenvolvedores, arquitetos, 
analistas, etc.
• Conhecimento de falhas anteriores em 
aplicações similares.
5
ERROS, DEFEITOS E FALHAS ANTERIORES RELACIONADOS A
Entrada
• Entrada válida não aceita;
• Entrada inválida aceita;
• Valor de parâmetro errado;
• Parâmetro de entrada ausente.
ERROS, DEFEITOS E FALHAS ANTERIORES RELACIONADOS A
Saída
• Formato de saída errado;
• Resultado incorreto;
• Saída correta no momento errado;
• Saída incompleta;
• Saída ausente;
• Erros gramaticais ou de pontuação.
6
ERROS, DEFEITOS E FALHAS
Lógica
• Casos ausentes a considerar;
• Casos duplicados;
• Operador lógico inválido;
• Condição ausente;
• Iteração de loop inválida.
ERROS, DEFEITOS E FALHAS
Cálculos
• Algoritmo errado ou ineficaz;
• Cálculo ausente;
• Operando ou operador inválido;
• Erro de arredondamento;
• Precisão insuficiente do resultado;
• Função embutida inválida.
7
ERROS, DEFEITOS E FALHAS
Interface
• Processamento incorreto de eventos da 
interface;
• Falhas relacionadas ao tempo no 
processamento de entrada/saída;
• Chamada de função errada ou inexistente;
• Parâmetro ausente;
• Tipos de parâmetro incompatíveis.
ERROS, DEFEITOS E FALHAS
Dados
• Inicialização, definição ou 
declaração incorreta de variável.
• Acesso incorreto a variável.
• Valor errado de variável.
• Uso de variável inválida.
• Referência incorreta a dados.
8
ERROS, DEFEITOS E FALHAS
Dados
• Dimensão errada dos dados.
• Índice ou tipo de variável incorreto.
• Faixa de variável incorreta.
• Erro de "um a mais" ou "um a menos".
FAULT ATACK (SOFTWARE ATACK)
Variação mais organizada e 
metódica da técnica de previsão de 
erros.
9
CARACTERÍSTICAS | FAULT ATACK (SOFTWARE ATACK)
• Envolve a criação de uma lista de 
potenciais erros, defeitos e falhas;
• O testador analisa a lista ponto a 
ponto;
• E tenta tornar visível cada erro, 
defeito ou falha no objeto em 
teste.
CARACTERÍSTICAS | FAULT ATACK (SOFTWARE ATACK)
• Focado em eventos negativos: 
defeitos ou falhas específicos
• Ao invés de eventos positivos: 
verificar a lógica de negócios ou 
domínio de entrada.
10
FONTE DAS LISTAS DE POTENCIAIS ERROS
• Listas podem ser baseadas na 
experiência do testador, tornando-as 
mais eficazes;
• Listas públicas disponíveis na internet 
também podem ser utilizadas.
EXEMPLO: ATAQUE DE FALHA (FAULT ATACK)
Um testador está testando um 
programa para calcular o IMC 
(Índice de Massa Corporal), 
https://calculatorsworld.com/health/bmi-calculator/
11
EXEMPLO: ATAQUE DE FALHA (FAULT ATACK)
• O testador aplicará a técnica 
ataque de falha;
• Utilizando a seguinte lista de 
defeitos e falhas:
1. A ocorrência de um overflow em 
um campo de formulário.
2. A ocorrência de divisão por zero.
3. Forçar a ocorrência de um valor 
inválido.
RESUMO DOS TESTES DE FALHAS PARA O PROGRAMA IMC
1. Forçar Falha de Overflow
Testador tenta inserir uma sequência muito 
longa de dígitos no campo de entrada de 
"peso".
2147483647.7976931348623157Peso:
12
RESUMO DOS TESTES DE FALHAS PARA O PROGRAMA IMC
2. Forçar Falha de Divisão por Zero
Testador insere altura zero, pois o 
IMC é calculado como o quociente do 
peso pelo quadrado da altura.
0Altura:
RESUMO DOS TESTES DE FALHAS PARA O PROGRAMA IMC
3. Forçar Falha de Valor Inválido
Testador insere um valor de peso 
negativo para forçar um valor de IMC 
negativo (incorreto).
-92.00Peso:
13
OBSERVAÇÃO
• Esses ataques são possíveis;
• Porque a interface permite que 
os valores de peso e altura;
• Sejam inseridos diretamente pelo 
teclado.
RECOMENDAÇÕES DE DESIGN DE INTERFACE
• Projetar interfaces que evitem a 
entrada de valores incorretos;
• Permitir a entrada apenas por meio de 
botões que aumentem ou diminuam 
os valores dentro de um intervalo 
controlado;
• Usar mecanismos como listas 
suspensas ou deslizadores.
14
TESTE
EXPLORATÓRIO
TÉNICAS DE TESTE
Particionamento de 
Equivalência (PE)
Análise de Valores Limite 
(AVL)
Teste de Tabela de 
Decisão
Teste de Transição de 
Estado
CAIXA PRETA
Teste de Comandos 
e Cobertura de 
Comandos
Testes de Desvios e 
Cobertura de Desvios
CAIXA BRANCA
Previsão de Erros
Teste Exploratório
BASEADO NA 
EXPERIÊNCIA
Teste Baseado em 
Checklist
TÉCNICAS DE TESTE
15
TESTE EXPLORATÓRIO
• Abordagem de projetar, executar 
e registrar testes não roteirizados
• Não Roteirizado: não planejados 
previamente;
• E avaliá-los dinamicamente 
durante a execução.
CARACTERÍSTICAS DO TESTE EXPLORATÓRIO
O testador não executa testes 
preparados em uma fase separada de 
design ou análise.
16
CARACTERÍSTICAS DO TESTE EXPLORATÓRIO
Cada próximo passo no cenário de teste atual 
é dinâmico e depende de:
1. Conhecimento e intuição do testador;
2. Experiência com esta ou aplicações 
similares;
3. Comportamento do sistema no passo 
anterior do cenário.
TESTE EXPLORATÓRIO X TESTE ROTEIRIZADO
• A diferença entre o teste exploratório e o 
roteirizado não é totalmente precisa;
• Toda atividade de teste inclui elementos de 
planejamento e de dinâmica/exploração.
17
PLANEJAMENTO EM TESTES EXPLORATÓRIOS
• Mesmo em testes puramente exploratórios;
• É comum planejar a sessão exploratória com 
antecedência;
• Exemplo: alocar um tempo específico para o 
testador executá-la.
• O testador exploratório pode preparar 
vários dados de teste necessários antes da 
sessão começar.
TESTES EXPLORATÓRIOS BASEADOS EM SESSÕES
Abordagem que permite maior 
estruturação e melhor gerenciamento das 
atividades de teste exploratório.
18
1. PLANEJAMENTO DA SESSÃO
• O testador se reúne com o gerente 
para determinar o escopo do teste e 
alocar tempo.
• O gerente entrega ou colabora com o 
testador para escrever a carta de teste 
(Test Charter).
• A carta de teste deve ser criada 
durante a análise de teste.
2. EXECUÇÃO DA SESSÃO
• O testador conduz a sessão de teste 
exploratório
• Fazendo anotações sobre observações 
relevantes
• Exemplo: Problemas, recomendações, 
informações sobre falhas, etc.
19
3. REUNIÃO DE REVISÃO
• Ao final da sessão, o testador e o 
gerente discutem os resultados 
• E decidem os próximos passos.
CARACTERÍSTICAS DA SESSÃO
• Realizada em um período bem definido
• Exemplo: 1 a 4 horas;
• O testador foca na tarefa especificada na 
carta de teste;
• Mas pode desviar-seda tarefa principal 
se observar um defeito sério em outra 
área da aplicação;
• Os resultados da sessão são 
documentados na carta de teste.
20
RECOMENDAÇÕES PARA A SESSÃO
• Realizar o teste de forma colaborativa, 
utilizando pares.
• O testador pode fazer dupla com um 
representante de negócios, usuário final 
ou Product Owner
• Para explorar a aplicação durante o 
teste.
RECOMENDAÇÕES PARA A SESSÃO
• O testador pode também fazer dupla com 
um desenvolvedor para:
• Evitar testar funcionalidades instáveis;
• Resolver questões técnicas;
• Demonstrar comportamentos indesejados 
imediatamente.
• Sem necessidade de fornecer evidências 
extensas no relatório de defeitos.
21
EXEMPLO: TESTE EXPLORATÓRIO
Uma empresa planeja testar a 
funcionalidade básica de um site
CARTA DE TESTE TE 02-001-01Carta de Teste
Testar a funcionalidade de loginObjetivo
• Login como um usuário existente com login e senha corretos
• Login como um usuário existente através de uma conta do Google
• Login como um usuário existente através de uma conta do Facebook
• Login incorreto - usuário inexistente
• Login incorreto - senha errada
• Ações que resultam no bloqueio da conta
• Uso da função de lembrete de senha
• Ataque de injeção SQL e outros ataques de segurança
Áreas
Site acessível através de vários navegadores (Chrome, FF, IE)Ambiente
2019-06-12, 11:00–13:15Tempo
Bob BugbusterTestador
Notas do Testador
Capturas de tela, dados de teste, etc.Arquivos
-Defeitos Encontrados
20% preparação para a sessão
70% condução da sessão
10% análise de problemas
Divisão do Tempo
22
EXEMPLO: TESTE EXPLORATÓRIO
• O gerente de testes, com base nos 
resultados coletados de várias sessões 
de testes exploratórios;
• Deriva as seguintes métricas amostrais 
para análise posterior;
MÉTRICAS AMOSTRAIS DO TESTE EXPLORATÓRIO
• Número de Sessões de Teste Conduzidas: 
Quantidade total de sessões de teste 
exploratório realizadas.
• Tempo Médio por Sessão: Duração média 
de cada sessão de teste exploratório.
• Número de Defeitos Encontrados: 
Quantidade total de defeitos identificados 
durante as sessões de teste.
23
MÉTRICAS AMOSTRAIS DO TESTE EXPLORATÓRIO
• Gravidade dos Defeitos: Classificação dos 
defeitos encontrados por gravidade 
• Exemplo: crítica, alta, média, baixa
• Áreas do Sistema Testadas: Partes do sistema 
que foram exploradas e testadas.
• Recomendações e Observações: Sugestões e 
anotações feitas pelos testadores durante as 
sessões.
QUANDO UTILIZAR TESTES EXPLORATÓRIOS?
• A especificação do produto em teste está 
incompleta, é de baixa qualidade ou está 
ausente.
• Há pressão de tempo; os testadores têm 
pouco tempo para conduzir os testes.
• Os testadores conhecem bem o produto e 
têm experiência em testes exploratórios.
24
TESTES EXPLORATÓRIOS
• Os testes exploratórios estão fortemente 
relacionados à estratégia de teste reativa;
• Podem utilizar outras técnicas baseadas em 
caixa preta, caixa branca e experiência.
TESTES EXPLORATÓRIOS
Ninguém pode ditar ao testador como conduzir 
a sessão.
• Um testador pode achar útil criar um diagrama 
de transição de estado para descrever o 
funcionamento do sistema 
• E, em uma sessão exploratória, projetar e 
executar casos de teste com base nele. 
25
teste BASEADO EM
CHECKLIST
TÉNICAS DE TESTE
Particionamento de 
Equivalência (PE)
Análise de Valores Limite 
(AVL)
Teste de Tabela de 
Decisão
Teste de Transição de 
Estado
CAIXA PRETA
Teste de Comandos 
e Cobertura de 
Comandos
Testes de Desvios e 
Cobertura de Desvios
CAIXA BRANCA
Previsão de Erros
Teste Exploratório
BASEADO NA 
EXPERIÊNCIA
Teste Baseado em 
Checklist
TÉCNICAS DE TESTE
26
TESTE BASEADO EM CHECKLIST
• Utiliza o conhecimento e a experiência 
do testador;
• Sendo a execução do teste baseada 
nos itens contidos em um checklist;
• Que lista as condições a serem 
verificadas.
CARACTERÍSTICAS DO CHECKLIST
• Não deve conter itens que possam ser 
verificados automaticamente;
• Não deve incluir critérios de entrada/saída;
• Não deve conter itens muito gerais;
• Frequentemente, os itens são formulados 
como perguntas.
27
CARACTERÍSTICAS DO CHECKLIST
• Permite verificar cada item 
separadamente e diretamente;
• Pode se referir a requisitos, 
características de qualidade ou outras 
condições de teste;
• Suporta vários tipos de testes, 
incluindo funcionais e não funcionais.
ATAQUE DE FALHA X CHECKLIST
Ataque de Falhas
• Inicia a partir de defeitos e falhas; 
• O testador age para revelar problemas 
específicos.
Teste Baseado em Checklist
• Verifica as funcionalidades positivas do 
software de maneira sistemática; 
• A base do teste é o próprio checklist.
28
MANUTENÇÃO DO CHECKLIST
• Deve ser atualizado regularmente com 
base na análise de defeitos;
• Deve evitar se tornar muito longo;
• Itens podem se tornar menos eficazes 
com o tempo 
MANUTENÇÃO DO CHECKLIST
• À medida que a equipe aprende a evitar 
erros repetidos.
• Novos itens podem ser adicionados para 
refletir defeitos de alta gravidade 
recentemente descobertos.
29
CONSISTÊNCIA E VARIABILIDADE DO CHECKLIST
• Proporciona uma certa consistência na 
ausência de casos de teste detalhados.
• Dois testadores trabalhando com o mesmo 
checklist
• Provavelmente realizarão tarefas de forma 
ligeiramente diferente
• Mas testarão as mesmas condições, 
resultando em testes similares.
CONSISTÊNCIA E VARIABILIDADE DO CHECKLIST
• Checklists de alto nível podem resultar em 
maior variabilidade nos testes reais;
• Potencialmente aumentando a cobertura; 
• Mas reduzindo a repetibilidade dos testes.
30
TIPOS DE CHECKLIST
• Existem muitos tipos diferentes de 
checklists para diferentes aspectos do 
software.
• Podem ter graus variados de generalidade 
e um campo de aplicação mais amplo ou 
mais restrito.
TIPOS DE CHECKLIST
• Existem muitos tipos diferentes de 
checklists para diferentes aspectos do 
software.
• Podem ter graus variados de generalidade 
e um campo de aplicação mais amplo ou 
mais restrito.
31
TIPOS DE CHECKLIST
• Não há uma regra fixa para o nível de 
detalhe dos checklists.
• Testadores devem sempre ajustar o nível 
de detalhe do checklist
• Para atender às suas próprias 
necessidades.
CHECKLIST PARA TESTE DE CÓDIGO
• Usados em testes de componentes.
• Tendem a ser muito detalhados.
• Incluem muitos detalhes técnicos sobre 
aspectos do desenvolvimento de código 
• Em uma linguagem de programação 
específica.
32
APLICAÇÃO DOS CHECKLISTS
• Checklists podem ser usados para 
basicamente qualquer tipo de teste;
• Incluindo testes funcionais e não funcionais.
PROCESSO NO TESTE BASEADO EM CHECKLISTS
• O testador projeta, implementa e 
executa testes;
• Para cobrir as condições de teste 
encontradas no checklist;
• Testadores podem usar checklists 
existentes, modificá-los e adaptá-los às 
suas necessidades.
33
PROCESSO NO TESTE BASEADO EM CHECKLISTS
Testadores também podem criar suas próprias 
listas com base 
• Na experiência com defeitos e falhas;
• No conhecimento das expectativas dos usuários 
• No conhecimento das causas e sintomas de falhas 
de software.
PROCESSO NO TESTE BASEADO EM CHECKLISTS
• Utilizar a própria experiência pode tornar esta 
técnica mais eficaz;
• Pois pessoas na mesma organização, 
trabalhando em produtos similares, tendem a 
cometer erros semelhantes;
• Testadores menos experientes geralmente 
trabalham com checklists já existentes.
34
COBERTURA DOS TESTES
• Não há medidas específicas de cobertura 
definidas para testes baseados em checklist;
• No mínimo, cada item do checklist deve ser 
coberto;
• A extensão da cobertura de cada item pode 
ser difícil de determinar;
• Pois a técnica se baseia no conhecimento, 
experiência e intuição do testador.
VANTAGEM - TESTE BASEADO EM CHECKLIST
• Maior cobertura pode ser alcançada se a 
mesma lista de testes for usada por 2 ou mais 
testadores;
• Cada testadorprovavelmente realizará um 
conjunto de passos ligeiramente diferente para 
cobrir o mesmo item do checklist;
• Resultando em alguma variabilidade nos testes;
• O que traduz em maior cobertura, mas com 
menor repetibilidade.
35
DESVANTAGEM - TESTE BASEADO EM CHECKLIST
• Falta de informações detalhadas sobre 
a cobertura;
• Menor repetibilidade em comparação 
com técnicas formais.
EXEMPLO – CHECKLIST PARA INSPEÇÃO DE CÓDIGO
1. O código está escrito de acordo com os padrões atuais?
2. O código está formatado de maneira consistente?
3. Existem funções que nunca são chamadas?
4. Os algoritmos implementados são eficientes, com 
complexidade computacional apropriada?
5. A memória está sendo utilizada de maneira eficaz?
6. Existem variáveis que são usadas sem serem declaradas 
primeiro?
36
EXEMPLO – CHECKLIST PARA INSPEÇÃO DE CÓDIGO
6. O código está devidamente documentado?
7. A maneira de comentar é consistente?
8. Toda operação de divisão está protegida contra divisão por 
zero?
9. Em declarações IF-THEN, os blocos de instruções executados 
mais frequentemente são verificados primeiro?
10.Cada declaração CASE tem um bloco padrão?
11.Toda memória alocada é liberada quando não está mais em 
uso?
EXEMPLO – HEURÍSTICAS DE NIELSEN
1. Visibilidade do Status do Sistema;
2. Correspondência entre o Sistema e o 
Mundo Real
3. Controle de Usuário e Liberdade
4. Consistência e Padrões
5. Prevenção de Erros
6. Reconhecimento em Vez de 
Recordação
7. Flexibilidade e Eficiência de Uso
8. Design Estético e Minimalista
9. Ajude os Usuários a Reconhecer, 
Diagnosticar e Recuperar de Erros
10. Ajuda e Documentação
37
BIBLIOGRAFIA
STAPP, Lucjan; ROMAN, Adam; PILAETEN, Micha
ël. ISTQB – Certified Tester Foundation Level: A 
Self-Study Guide Syllabus v4.0. Chapter 2. Testing 
in the Context of a Software Development Cycle - Test 
Levels. Springer, 2023.
BIBLIOGRAFIA
MYERS, Glenford J.; BADGETT, Tom; SANDLER, 
Corey. The Art of Software Testing. Wiley, 2011.
38
BIBLIOGRAFIA
SOMMERVILLE, Ian. Engenharia de Software. Cap. 2 
– Processo de Software. pág. 18. Cap. 3 –
Desenvolvimento Ágil de Software. pág. 38. Pearson, 
2019.
BIBLIOGRAFIA
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia 
de Software: Uma Abordagem Profissional. Cap. 
4.1 Modelos de Processos Prescritivos, pág. 41. 
AMGH, 2021.
39
BIBLIOGRAFIA
BOURQUE, Pierre.; FAIRLEY, Richard E. (Dick). 
SWEBOK V3.0. Chapter 8. Software Engineering 
Process, pág. 81. AMGH, 2021.
Diego Augusto Barros é bacharel em Sistemas de
Informação pela Pontifícia Universidade Católica de Minas
Gerais (2012) e mestre em Ciência da Computação pela
Universidade Federal de Minas Gerais (2015).
Sua pesquisa concentra-se nas áreas de Visualização de
Dados e Interação Humano-computador, e investiga
fatores cognitivos e perceptivos envolvidos na análise de
grandes conjuntos de dados, que resultam em novos
sistemas interativos para comunicação e análise visual.
Seus principais interesses nas áreas são: visualização de
informação, Visual Analytics, métodos de avaliação de
interfaces, interação com sistemas, tecnologias web,
sistemas de informação, engenharia de software e
informática na educação.
diegoaugustobarros.com
@diegoaugustobarros
@profdiegoaugusto
PROF. DIEGO AUGUSTO BARROS