overview de qa
TRANSCRIPT
Overview de QAResultados Digitais
Bárbara Cabral da Conceição - ISTQB CTFLAnalista de Testes e Qualidade
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
● 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.
Quality Assurance● São ações de Prevenção de erros e defeitos em produtos evitando
problemas nas entregas das soluções aos clientes
Quality Control
Matriz de Testes Ágeis
Fluxo de Testes em uma Release
E como fica isso dentro de uma Sprint?
Níveis de Teste na Matriz Á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)
Tipos de Teste● 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● ...
Smoke Tests● 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
Testes de Regressã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
Testes de Usabilidade● 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
Testes de Seguranç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.
Testes de Performance● 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
Testes de Carga/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
Testes de Stress● 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.
Testes de Integridade● 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 dados foram corrompidos quando ocorreu a falha
Testes Explorató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
Técnicas de Teste
Specification-based Techniques● Equivalence Partitioning● Boundary Value Analysis● Decision Tables● State Transition● Use Case Testing
Equivalence Partitioning● 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
Boundary Value Analysis● 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
Decision Table● 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
State Transition● 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
Structure-based techniques● Statement● Decision● Condition● Multiple Condition
Statement coverage● 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?
Decision coverage● 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?
Branch/Condition coverage● 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?
Multiple condition (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?
Structured Coverage by NASA
Outros...
Abordagens de Teste
● 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
● 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-driven testing
Control-Flow Based Testing● 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
Behavior-Driven Testing ● 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"
Business-Driven Testing● Exercita os objetivos de
negócio do usuário dentro do sistema
● Mapeia os fluxos de tela e a execução das tarefas
Risk Based Testing● 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
Context Driven Testing● 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
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.
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
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
Contato
● Skype: babipcabral● Twitter: @barbarapcabral● LinkedIn: /in/barbaracabral● E-mail: barbara.