• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ALM - Testes Exploratórios
 

ALM - Testes Exploratórios

on

  • 566 views

Uma abordagem de Testes Exploratórios.

Uma abordagem de Testes Exploratórios.

Statistics

Views

Total Views
566
Views on SlideShare
566
Embed Views
0

Actions

Likes
0
Downloads
15
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    ALM - Testes Exploratórios ALM - Testes Exploratórios Presentation Transcript

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