Overview de QA

1.517 visualizações

Publicada em

Overview de Níveis, Técnicas e Abordagens de Teste de Software

Publicada em: Tecnologia
0 comentários
4 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.517
No SlideShare
0
A partir de incorporações
0
Número de incorporações
816
Ações
Compartilhamentos
0
Downloads
4
Comentários
0
Gostaram
4
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Overview de QA

  1. 1. OverviewdeQA Resultados Digitais Bárbara Cabral da Conceição - ISTQB CTFL Analista de Testes e Qualidade barbaracabral@gmail.com
  2. 2. Dicas ● O objetivo é alinhar o conhecimento acerca de Testes ● Provavelmente você já conhece e até aplica algumas das técnicas ● Saber realizar pesquisas utilizando os termos abordados ● Não são todas as técnicas que conheço/apliquei ● Não são todas as técnicas que você precisa conhecer/ aplicar (apenas aquelas que achar necessária) ● Se for necessário aprofundar em alguma, vemos isto num próximo seminário, num post ou em pesquisas e conversas informais ● Você não deve se preocupar em aprender tudo hoje
  3. 3. ● São ações de Deteção de erros e defeitos em produtos evitando problemas nas entregas das soluções aos clientes ● Testing is context dependent ○ Técnicas & Abordagens de Testes são aplicadas de forma diferente em cada contexto. Ex: um software de diagnóstico médico é testado diferente de um e-commerce. QualityAssurance ● São ações de Prevenção de erros e defeitos em produtos evitando problemas nas entregas das soluções aos clientes QualityControl
  4. 4. MatrizdeTestesÁgeis
  5. 5. FluxodeTestesemumaRelease
  6. 6. EcomoficaissodentrodeumaSprint?
  7. 7. NíveisdeTestenaMatrizÁgil ● Testes Unitários (Q1) ● Testes de Componente (Q1) ● Testes de Integração (Q1) ● Testes de Sistema (Q1 e Q2) ○ Funcionais ○ Não-funcionais ● Testes de Aceitação (Q3) ○ Comportamento (BDD)
  8. 8. TiposdeTeste ● Smoke Tests ● Testes de Regressão ● Testes de Usabilidade ● Testes de Segurança ● Testes de Stress ● Testes de Carga/Volume ● Testes de Performance ● Testes de Integridade ● Testes Exploratórios ● ...
  9. 9. SmokeTests ● Objetivo: ○ Garantir que as funções mais importantes do sistema estão funcionando ● Também conhecidos como “Build Verification Testing” ● Conjunto mínimo de testes para determinar uma versão “estável do sistema” ● Se estes testes falharem, o build requer fix imediato ● Níves de teste: Sistema, Integração e Aceitação ● Geralmente é um sub-conjunto de uma suite de testes de regressão automatizados
  10. 10. TestesdeRegressão ● Objetivo: ○ Garantir que tudo o que estava funcionando ANTES das alterações continuam funcionando ● É executado a cada vez que um deploy do sistema é realizado, sendo assim geralmente é automatizado ● Retorna um relatório do impacto da mudança no restante do sistema ● Pode exigir que a cobertura de teste de outra área aumente caso o risco de quebra também seja maior ● É apropriado ter uma suite de testes de regressão para cada nível de teste: de componente, de integração e de sistema ● Se a suite é muito grande, geralmente se utiliza um subconjunto dela, os Smoke Tests
  11. 11. TestesdeUsabilidade ● Objetivo: ○ Identificar se a experiência do usuário no sistema está sendo eficiente, efetiva e satisfatória ● Efetividade: o usuário consegue alcançar seus objetivos dentro do software? ● Eficiência: o usuario consegue alcançar seus objetivos em um tempo que ele considera razoável? ● Satisfação: o usuário sente que o software ajudou ele a concluir suas tarefas? ● Geralmente realizados por UX Designers diretamente com o usuário
  12. 12. TestesdeSegurança ● Objetivo: ○ Prevenir acesso não autorizado ao programa ou seus dados, independente se foi causado acidentalmente ou de propósito ● Exemplos: bloqueio de acesso a APIs, manipulação das configurações da infra, arquivos corrompidos, edição de dados que usuários não poderiam realizar através da interface, forçar a sobrecarga de recursos do sistema (CPU, memória), inputs muito longos nos campos podem “quebrar” o sistema, alteração de privilégios de segurança no BD, forçar a quebra com caracteres especiais, scripts, comandos da linguagem ou do banco de dados.
  13. 13. TestesdePerformance ● Objetivo: ○ Medir desempenho do sistema, ou seja, o tempo de resposta dos inputs do usuário no sistema e outros tipos de entrada. ● Algumas medidas de eficiência: ○ Tempo de resposta por operação em segundos ○ Número de transações por segundo ○ Saída de dados por segundo ○ Ciclos de CPU ○ Uso de memória
  14. 14. TestesdeCarga/Volume ● Objetivo: ○ Como o sistema se comporta ao se aumentar o nível de carga e quanta carga o sistema pode manipular até seu “pico” ● Fontes de carga: número de usuários que acessam o sistema; outros sistemas que façam interface com nosso sistema ● O que nos responde: a habilidade que o sistema tem de manipular um número de usuários em paralelo ou, de manter a sessão e garantir a integridade, quantos registros são processados por hora, volume de dados trocados através da rede ou de integrações com outros sistemas, etc. ● Algumas medidas: número máximo de usuários simultâneos, número máximo de transações simultâneas
  15. 15. TestesdeStress ● Objetivo: ○ Determinar a capacidade de recuperação e estabilidade do sistema ● Define picos de instabilidade: aumento e diminuição de carga em uma determinada funcionalidade para testar a elasticidade do sistema ● Avalia como o sistema lida com o stress: se ele falha ou se ele se recupera rapidamente ● Spike tests: Basicamente, é executada uma quantidade massiva de uma determinada funcionalidade, para determinar como a aplicação se comporta. Por exemplo, quando há uma troca de turno em um sistema de call center e todos os novos usuários têm que fazer login ao mesmo tempo enquanto outros realizam logout.
  16. 16. TestesdeIntegridade ● Objetivo: ○ Verificar o sistema se recupera quanto à perdas de dados quando interrompida uma determinada transação ● Failover: ○ Simular falhas no sistema para avaliar em quanto tempo o sistema se recupera e coloca tudo funcionando novamente ● Backup: ○ Verificar que os diferentes tipos de backup estão funcionando para o caso de ocorrer uma falha ● Restore: ○ Verificar o tempo de o sistema avaliar se houve perda de dados ou se
  17. 17. TestesExploratórios ● Objetivo: ○ Descobrir falhas através do aprendizado/experiência no sistema ● Planejados e guiados por um test charter que provê uma descrição geral dos objetivos de teste ● O processo é interativo e criativo ● O resultado varia conforme a experiência do testador no sistema & em outros sistemas
  18. 18. TécnicasdeTeste
  19. 19. Specification-basedTechniques ● Equivalence Partitioning ● Boundary Value Analysis ● Decision Tables ● State Transition ● Use Case Testing
  20. 20. EquivalencePartitioning ● Grupo de condições de teste divididos em partições que serão manipuladas da mesma forma ○ 1º - Identificar um conjunto de dados como as condições de entrada que possuem um mesmo resultado ○ 2º - Agrupar os dados de entrada em partições ○ 3º - Você sempre tem pelo menos 2 tipos de partições: válidas e inválidas ● Provê redução no número de dados para teste
  21. 21. BoundaryValueAnalysis ● Equivalence class não garante erros nos valores limites ● Identificar erros nos limites das partições ○ 1º - Identificar os valores mínimos e máximos de cada partição ○ 2º - Prover caso de teste para cada valor-limite -1, 0, 1 5, 6, 7 17, 18, 19 63, 64, 65
  22. 22. DecisionTable ● Amplamente utilizada para testar regras de negócio ● Geralmente você tem uma grupo de condições de entrada e um conjunto de condições de saída
  23. 23. StateTransition ● Utilizado para testar transições de estado ● Podem ser utilizados grafos de transição de estado ou tabelas: TC1 TC2 TC3 Start event Null Null Confirmed Event Request room Request room Customer cancels Effect Room Available Room Not Available Decrement the room count End State Confirmed On waiting list Canceled
  24. 24. Structure-basedtechniques ● Statement ● Decision ● Condition ● Multiple Condition
  25. 25. Statementcoverage ● Cada “estado” é executado pelo menos 1 vez ● O número de estados executados nos dão o retorno da cobertura ● Quantos casos de teste são necessários para alcançar todos os estados?
  26. 26. Decisioncoverage ● Cada “ponto de decisão” é executado pelo menos 1 vez ● O número de decisões executadas nos dão o retorno da cobertura ● Quantos casos de teste são necessários para alcançar todos os pontos de decisão?
  27. 27. Branch/Conditioncoverage ● O resultado de cada ponto de decisão é executado pelo menos 1 vez ● A cobertura é através do resultado de cada ponto de decisão ● Quantos casos de teste são necessários para alcançar todas os branches dos pontos de decisão?
  28. 28. Multiplecondition(MC/DC) ● O resultado de cada condição deve ser testado individualmente ● A cobertura é através do resultado de cada pequena condição: ● Quantos casos de teste são necessários para alcançar todas as combinações possíveis?
  29. 29. StructuredCoverage byNASA
  30. 30. Outros...
  31. 31. AbordagensdeTeste ● Data driven testing ● Control-flow based testing ● Behavior driven testing ● Business driven testing ● Keyword driven testing ● Model-based testing ● Risk-based testing ● Context-driven testing
  32. 32. ● Geralmente se usa uma tabela de condições gerando um conjunto de Dados de Entrada para um determinado componente e os dados de saída correspondentes ● Os dados de entrada podem ser armazenados/carregados de um arquivo ● Os dados de saída podem ser verificados diretamente em banco de dados ● Permite testar o mesmo cenário de teste com a variação dos dados incluídos Data-driventesting
  33. 33. Control-FlowBasedTesting ● Do código-fonte, criar um gráfico que represente o fluxo de controle do sistema ● Geralmente se criam os testes baseados em uma das seguinte coberturas: ○ Nodes, Edges, Paths e Branches
  34. 34. Behavior-DrivenTesting ● Descreve o sistema em termos de comportamento ● Mapeia com melhor cobertura as regras de negócio e de interface ● Alinha comunicação entre business & code ● Para automação, utiliza a linguagem Gherkin ○ GIVE / WHEN / THEN ● É possível usar o conceito de data- driven junto através das tabelas de dados Feature: Add and remove tags In order to organize my leads As a simple user I want add and remove tags Scenario: action Add a tag Given the page "https://www.rdstation.com.br/leads When I select a filter Todos os contatos da base de leads And I click on group "Ações" And I select "Adicionar Tag" And I fill in Tag with "urgente" And I click on "Adicionar" Then I should see all the leads with the tag "urgente" Scenario: action Remove a tag Given The page "https://www.rdstation.com.br/leads When I select a filter Todos os contatos da base de leads And I click on group "Ações" And I click on "Remover Tag" And I fill with "urgente" And I click on "Remover" Then I should see the leads without the tag "urgente"
  35. 35. Business-DrivenTesting ● Exercita os objetivos de negócio do usuário dentro do sistema ● Mapeia os fluxos de tela e a execução das tarefas
  36. 36. RiskBasedTesting ● Baseado na priorização dos testes em termos de risco de falha ● Baseado na importância da feature dentro do sistema ● Baseado no possível impacto do defeito
  37. 37. ContextDrivenTesting ● Princípios: ○ Os grupos de teste existem para prover serviços relacionados aos testes. Eles servem o projeto. ○ Os grupos de teste têm missões diferentes a cada etapa do projeto: dependendo do contexto atual do projeto e dos problemas atacados ○ O valor essencial de um test case é prover informação e reduzir incerteza ○ Testes automatizadoes não são testes manuais de forma automática ○ Diferentes tipos de defeitos podem ser revelados por diferentes tipos de teste ○ Os testes são sob medida quando satisfazem aos requisitos dos stakeholders do projeto
  38. 38. Mitos ● O objetivo dos Testes é garantir 100% de um produto livre de bugs ○ FATO O objetivo dos testes é descobrir tantos defeitos quanto possível enquanto garante que o software cumpre os seus requisitos. Identificar e “se llivrar” de todos os defeitos é impossível. ● Testar é fácil! =D ○ FATO Testar pode ser difícil e um grande desafio (às vezes até maior do que codificar) ● Testes Automatizados eliminam a necessidade de testes manuais ○ FATO 100% de automação de testes não pode ser alcançado. Testes manuais são, em algum nível, necessários.
  39. 39. Mitos ● Quando detectado um incidente a falha é do QA ○ FATO: Qualidade é a responsabilidade de todos os membros/stakeholders do projeto ● QA não precisa saber as regras de negócio ○ FATO: quanto mais cedo QA souber o comportamento esperado do sistema, mais cedo poderá encontrar falhas ● QA dá resultado a curto prazo ○ FATO: o processo de onboarding de um QA pode demorar mais pelo fato de precisar definir um processo e uma estratégia antes & precisar entender claramente as regras de negócio e comportamento do sistema
  40. 40. Fontes ● Foundations of Software Testing ● Advanced Software Testing - Volume 1 ● The Software Test Engineer’s Handbook ● White-box techniques http://www.chaudhary.org/WhiteBox.pdf ● NASA: /shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001-tm210876-MCDC.pdf ● http://www.inf.ed.ac.uk/teaching/courses/st/2011-12/Resource- folder/06_structural.pdf ● http://www.testdesigners.com/testingstyles/ControlFlowTesting.html
  41. 41. Contato ● Skype: babipcabral ● Twitter: @barbarapcabral ● LinkedIn: /in/barbaracabral ● E-mail: barbara. cabral@resultadosdigitais.com.br

×