1
Testes de Software & Testes de Software & Garantia da QualidadeGarantia da Qualidade
(Conceitos & Fundamentos(Conceitos & Fundamentos))Professor: Rodrigo Zauza PassosProfessor: Rodrigo Zauza Passos
2
Slide: 2
Capacitar o aluno a testar uma solução tecnológica fundamentando-
se nas melhores práticas de
Testes e de Garantia da Qualidade.
:.: :.: ObjetivoObjetivo
3
Slide: 3
Achar falhas
Previnir falhas
Evitar falhas
:.: :.: A Oratec trabalha com as práticas:A Oratec trabalha com as práticas:
4
Slide: 4
Ferr
am
en
tas
Ferr
am
en
tas
Pro
cess
os
Pro
cess
os
Pess
oas
Pess
oas
• Qualquer ciclo de produção em TI é sustentado por 3 pilares:– Processos: o melhor
método é simples de usar e cabe no bolso de quem o usa.
– Pessoas: devem atuar em suas competências nivelada ao seu perfil pessoal;
– Ferramentas: são componentes facilitadores e não complicadores.
• … e ele é amparado pelaquadra “Escopo, Prazo, Custo & Qualidade” , mandamento de qualquer bom gerente de área.
:.: :.: Variáveis de ContextoVariáveis de Contexto
5
Aurélio– Requisito
• Condição que se deve satisfazer para que uma coisa fique legal e regular;• Exigência imprescindível para a consecução de certo fim;• Qualidade, dotes, predicados exigidos para um produto;
– Requerimento• Ato ou efeito de requerer (pedir /solicitar).
Para um Analista• “Um requisito é algo que o produto deve fazer ou alguma qualidade que deve
apresentar.”
Para um Testador:• “Um requisito é algo (verificável) que o produto deve fazer ou alguma qualidade
(mensurável) que deve apresentar e que (pelo seu risco de comprometer o sucesso do projeto, compen$a) deve ser testado”.
:.: :.: Nivelamento de Conceitos (I)Nivelamento de Conceitos (I)Conce
ito
6
Usuário Implementador Testador Organização
Facilidade de uso,
desempenho, confiabilidade
dos resultados, etc.
Facilidade de manutenção e
conformidade em relação aos
requisitos de usuários, etc.
Software com boa qualidade é
aquele que cumpre com os
requisitos negociais com o mínimo de falhas
possível.
Cumprimento de prazo, boa previsão de custo, boa
produtividade e
rentabilidade.
Visões sobre a qualidade de um Software:
:.: :.: Nivelamento de Conceitos (II)Nivelamento de Conceitos (II)Conce
ito
7
Existe defeito quando um software ou parte dele:
– Não funciona, mas os requisitos ou os artefatos indicam que funciona;
– Faz algo na aplicação em que os requisitos ou os artefatos indicam que não deveria fazer;
– Faz algo que os requisitos ou os artefatos não indicam;– Faz algo que os requisitos ou os artefatos não indicam, porém
deveriam indicar;– Não funciona adequadamente aos olhos do testador, pois é
difícil de entender, de usar ou é lento.
:.: :.: Nivelamento de Conceitos (III)Nivelamento de Conceitos (III)
Defeito=Falha=Anomalia=Bug=Ocorrência
Conce
ito
8
Caso 1 - Disney´s Lion King ( 1994-1995) -A Disney , em 1994 lançou seu primeiro jogo de multimedia para crianças “ Lion King Animated stories”. Era a primeira da Disney , e renomada , fez um enorme campanha de marketing por todo os EUA . Vendas foram absurdamente fantásticas (vendas de natal).Porém , no dia seguinte , 26 de dezembro de 1994 o departamento de atendimento ao cliente da Disney recebeu uma enxurrada de ligações de clientes indignados e nervosos. O CD não funcionava em muitas das plataformas de PC existentes no mercado. Razão : O software foi desenvolvido em uma única plataforma ( que não refletia as mais comuns do mercado!).
Faltou um simples teste de multiplataforma....
:.: :.: Bug Arrasadores (1/4)Bug Arrasadores (1/4)
9
Caso 2 – Patriot Missile Defense System , 1991 Um programa de defesa americano chamado de “ star wars” incluía o chamado “U.S. Patriot missile”. O primeiro uso foi na guerra do golfo em 1991 para defender dos misseis Scuds do Iraque. Porem , este sistema falhou inúmeras vezes contra vários misseis , incluindo um míssil iraquiano que matou 28 soldados americanos em Dhahran , na Arábia Saudita. Numa analise , encontraram a causa : um bug no sistema de contagem ( pequeno timing error ) culminando num erro de 14 horas de diferença entre os relógios, deixando o sistema de contagem defasado.
Custo : No mínimo, 28 vidas.
:.: :.: Bug Arrasadores (2/4)Bug Arrasadores (2/4)
10
Caso 3 – Limite de endereços de computador na WWWQuando o TCP/IP (protocolo de transmissão de pacotes da Internet) foi criado pelos sr. Vint Cerf e Bob Kahn, eles acharam que 4.3 bilhões de endereços eram suficientes. Parece muito, mas com o crescimento exponencial de transações nessa plataforma, pode-se atingir o limite antes do previsto. Um consórcio de organizações governamentais estão se preparando para ampliar este número para mais de 200 trilhões de endereços possíveis. A singela mudança implica mexer com muita gente e muitos computadores espalhados pelo planeta. Será um problema complexo de logística e sincronização dos sistemas.
:.: :.: Bug Arrasadores (3/4)Bug Arrasadores (3/4)
11
Caso 4 – Novo Sistema DDD no Brasil Em julho de 1999, o Brasil experimentou um caos no sistema de telefonia por mais de uma semana, devido a instalação do novo sistema de codificação de DDD. As razões do problema foram:• A anatel não checou o resultado dos testes feitos pelas operadoras dentro dos
estados. Entre estados nenhum teste foi feito;• A troca do Sistema não passou por um teste simulado em nível nacional;• As operadoras apenas simularam conexão dos equipamentos em área limitadas;
• Nem todas as operadoras fizeram investimentos suficientes para suportar a mudança;
• A campanha publicitária da Anatel enfatizava somente o direito de escolha das operadoras, mas não explicava com clareza as mudanças;• Seis centrais da Embratel tiveram erros na programação, fazendo com que as chamadas fossem parar em locais diferentes.
:.: :.: Bug Arrasadores (4/4)Bug Arrasadores (4/4)
12
– São disciplinas distintas, mas convergentes: meta é a qualidade;
– Testar significa verificar e validar um ou mais artefatos;– Garantir a qualidade significa disciplinar a verificação e
validação deles nos ciclos de produção e testes de software;– Missão do time de teste: achar anomalias;– Missão do time de QA: não deixar que elas se repitam;– Nas tratativas legais, o Analista de QA é quem responde pela
qualidade do software, baseando-se nas métricas do time de testadores.
:.: :.: Nivelamento de Conceitos (IV)Nivelamento de Conceitos (IV)
Testes de Software ≠ Garantia da Qualidade
Vivên
cia
13
Slide: 13
ProcessosProcessos
14
Slide: 14
Processo de Software
Gerência eficaz e controle das atividades
Processo de Software
muito bem definido
pessoas
procedimentos
ferramentas Req usuários
Req. desenvolvedor
Req. organização
:.: :.: Processo de SoftwareProcesso de Software
15
Slide: 15
RADRADRADRAD
XM
XM
XM
XM
OM
TO
MT
OM
TO
MT
Booc
Booc
hhB
ooc
Booc
hh
PM
BO
KP
MB
OK
PM
BO
KP
MB
OK
Cata
lysi
Cata
lysi
ssC
ata
lysi
Cata
lysi
ss
Wate
Wate
rfall
rfall
Wate
Wate
rfall
rfall
USDP
USDP
SSADSSADMM
W-M
odelV-Model
Na Engenharia de Software, existem várias metodologias de produção ...
Focaliza o quêFocaliza o quê
Análise do sistemaAnálise do sistema
Fase planejamentoFase planejamento
Análise de requisitosAnálise de requisitos
Focaliza o comoFocaliza o como
Projeto da ArquiteturaProjeto da Arquitetura
CodificaçãoCodificação
TestesTestes
Focaliza as mudançasFocaliza as mudanças
Manutenções A.C.E.Manutenções A.C.E.
DefiniçãoDefinição
DesenvolvimentoDesenvolvimento
ManutençãoManutenção
Informações processadasFunção e desempenho desejados
Riscos mapeadosInterfaces estabelecidas
Arquitetura da soluçãoEstrutura de dados
Padrões de codificaçãoPlanejamento dos Testes
Contramedidas para a gerência da produção
XP
XP
XP
XP
FD
DFD
DFD
DFD
D
RUPRUPRUPRUP
DS
DM
DS
DM
DS
DM
DS
DM
SC
RU
MS
CR
UM
SC
RU
MS
CR
UM
Icon
ixIc
on
ixIc
on
ixIc
on
ix
Cris
taC
rista
llC
rista
Cris
tall
EU
P
:.: :.: Métodos de ProduçãoMétodos de Produção
16
Slide: 16
Existem vários modelos e padrões de qualidade:Existem vários modelos e padrões de qualidade:
:.: :.: Padrões de QualidadePadrões de Qualidade
17
Slide: 17
Existem vários modelos e padrões de qualidade:Existem vários modelos e padrões de qualidade:
Efici
ênci
a
Inte
grid
ade
Usa
bilid
ade
Corr
etitu
de
Confi
abili
dad
e
Manutenibilidad
e
Flexibilidade
Testabilidade
PortabilidadeReusabilidade
Interoperabilidade
A maioria deles avaliam a qualidade do software a partir de 3 aspectos: (1) Operação do Produto; (2) Revisão do Produto; (3) Transição do Produto.
A maioria deles avaliam a qualidade do software a partir de 3 aspectos: (1) Operação do Produto; (2) Revisão do Produto; (3) Transição do Produto.
Modelo de MCall (1977)
:.: :.: Padrões de QualidadePadrões de Qualidade
18
Slide: 18
Testability Maturity Model (TMM) Test Organization Maturity (TOM) Testing Assessment Program (TAP) Evaluation&Test SW-CMM Key Process Area
(CMM-I KPA) Metrics-based Testing Maturity Model (MB-
TMM)– Em desenvolvimento
:.: :.: Padrões de Qualidade para testesPadrões de Qualidade para testes
19
Slide: 19
ProcessoProcesso ProdutoProduto
RequerimentosRequerimentos
AnáliseAnálise
DesenhoDesenho
CodificaçãoCodificação Testes de Unidade
Testes de Unidade
Testes de Sistema
Testes de Sistema
Testes de Aceitação
Testes de Aceitação
Testes de Integração
Testes de Integração
testeteste
testeteste
testeteste
testeteste
docdoc
docdoc
docdoc
docdoc
:.: :.: Um bom modelo de produçãoUm bom modelo de produção
20
Slide: 20
A implantação de um processo de formal de
Testes no ciclo produtivo otimiza as relações
setoriais e garante a cadência do trabalho
coorporativo
:.: :.: Visão Geral sobre os TestesVisão Geral sobre os Testes
:.: O Processo de Testes de Software:.: O Processo de Testes de Software
Existem basicamente 2 visões sobre os testes:
Vivên
cia
Visão Restrita Visão Abrangente Um bom testador é um
bom programador;
Testar significa mais gastos de recursos e tempo do projeto;
O testador só deve achar erros.
Um bom testador é aquele que domina as regras negociais do SUT (System Under Testing);
Testar significa investir para gastar menos;
Além de achá-los, o testador deve indicar como evitá-los e prevení-los. (QA/QD/QC)
21
Registrar/monitorar erros
Analisar todos os requisitos
Produzir métricas
Formular indicadoresde qualidade
:.: O Processo de Testes de Software:.: O Processo de Testes de Software
São premissas dos testes de software:
22
23
Com
plex
idad
e
Ciclo de Vida
ConcepçãoDiagnosticarsituação atual
AssimilarConhecimento
DefinirEstratégias
InstrumentalizaçãoInstrumentalizar as estratégias definidas
Criar, compartilhar e realimentar Expertise
EvangelizaçãoMonitorar e criar cultura, Divulgar, Negociar, Compartilhar, Justificar, Celebrar, Aperfeiçoar...
Analistas /Arquiteto de Testes
Analista/Executores de Testes
t+1
Analistas e Executores
:.: O Processo de Testes de Software:.: O Processo de Testes de Software
Atividades Macro X Responsáveis:
t
• Todos os testes devem ser rastreáveis até a sua origem, que são os requisitos negociais;
• Planeje sempre. Mas seja comedido !• Cerca de 60% das falhas ocorrem na concepção do produto;• Crie casos de testes genéricos;• Testes não têm fim. Eles apenas provocam um “ponto de
corte” !• Processos inteligentes (e eficientes) são independentes de
ferramentas;• Antes de executar um esforço de testes defina bem os
papéis e responsabilidades;
:.: O Processo de Testes de Software:.: O Processo de Testes de Software
Dicas úteis:
Vivên
cia
24
25
:.: :.: Nivelamento de Conceitos (V)Nivelamento de Conceitos (V)Conce
ito
Artefatos documentais do processo de testes de software: • Requisitos: lista contendo todas as
necessidades negociais do SUT (funcionais/não funcionais);
• Plano ou estratégia: documento com o conjunto das atividades do esforço de teste. Aqui se definem os tipos de testes, cronograma, papéis, responsabilidades e infra necessária;
• Cenário ou roteiro: conjunto de casos de testes que serão executados para cobrir um ou mais processos negociais;
• Casos de teste: é um conjunto de procedimentos que valida/verifica um ou mais requisitos negociais;
• Etapas: ações de validação/verificação de um caso de teste.
26
Construa um simples caso de teste cuja meta é:
Verificar se um palito de fósforo acende.Tempo estimado: 30 minutos (20/10)
:.: Desafio #1:.: Desafio #1
27
:.: O Processo de Testes de Software:.: O Processo de Testes de Software
Estratégia de testes
Testes caixa branca
Testes exploratórios
Testes caixa preta
Testes de vulnerabilidades
Testes de Carga e Stress
Testes Funcionais
Testes baseados em cenários Testes negativos
Inspeção de Artefatos Doc.
Verificação de Diagramas UML
Validação de modelos ER
Validação/Verificação de requisitos
Régua de Avaliação Fornecedores
Testes unitários
A estratégia de testes faz parte da Metodologia dos testes !!!
Testes de regressão
Testes automatizados
:.: O Processo de Testes de Software:.: O Processo de Testes de Software
Tipos de testes mais comuns:• Funcionais: verificam se o SUT está agindo conforme os requisitos negociais
projetados inicialmente;• Baseados em cenários: é uma boa estratégia para abranger a maior parte dos
requisitos negociais do SUT;• Testes negativos: são atividades que tentam contradizer a natureza para qual
aquela funcionalidade foi projetada;• Testes de caixa-preta: valida somente a entrada e a saída de um processo, não
importando o que acontece dentro dele;• Performance: são atividades que avaliam o desempenho do SUT ou de um
componente de acordo com parâmetros balisadores de aceitabilidade (requisitos não funcionais);
• Load/Stress: é a estratégia utilizada para averiguar a suportabilidade da infraestrutura do SUT (rede, middleware, RDBMS, etc.). O teste de stress nada mais é do que o ponto limite da carga utilizada no esforço do teste e suportada pela infraestrutura;
• Teste exploratório: sua finalidade é reconhecer as características do protótipo e tentar provocar a ocorrência de anomalias;
• Teste de vulnerabilidade: com o advento da Internet tornou-se atividade estratégica, pois verifica os limites do SUT com relação às atividades de XSS, Cross-Scripting, sobrecarga de níveis de serviço;
• Testes automatizados: são viáveis quando os requisitos do SUT são maduros e estáveis;
• Testes de regressão: aplicável quando um coponente do SUT sofre alteração. Portanto é necessário retestar todas as integrações periféricas daquele componente.
28
Slide: 29
Levantamento de
Necessidades
Análise dos Requisitos e
ArtefatosEspecificação
/Desenho
Inspeção e Validação
Corrigir e solucionar dúvidas
Esclarecimento
Reescrever
Revalidar
Enviar Defeito
Fornecedor
Abrir Defeito
Retestar Defeito
Cancelar Defeito
Encerrar Defeito
É Defeito ?
BUGFix ?
Ciclo de Reparo de Defeitos
Gerenciamento de Testes e Defeitos
:.: O ciclos de produção e:.: O ciclos de produção ede testes de softwarede testes de software
Gerenciamento do ciclo de produção do
software
30
• Não se pode testar aquilo que não se sabe;• Clientes sempre mudam os requisitos;• Uso de protótipos não pode ser desculpa para não
documentar requisitos;• Interfaces gráficas abrangem unicamente requisitos
funcionais de alto nível, sem detalhes, sem regras de negócios;
• Usuários não sabem o que querem até terem algo paupável.
:.: Melhores práticas de testes (1/9):.: Melhores práticas de testes (1/9)
#1) Requisito é a base do teste
31
• É fácil de configurar: customizar uma funcionalidade conforme as necessidades do usuário deve ser uma tarefa fácil para ele;
• Está em conformidade com os requisitos que o cliente pediu.• É eficiente: recursos de infraestrutura atendem a performance da
funcionalidade (processador, memória, discos e linhas de comunicação);
• Seja expandível: recursos que permitam a utilização de objetos e componentes de estrutura funcional para compor os novos requisitos de sistema (isso é ideal para a perfeita manutenção do software);
• Tenha flexibilidade: procedimento que permite a mudança do software em ambientes diferentes. Ex.: mudança de Banco de Dados;
• Tenha integridade: que é a habilidade do software proteger a ele mesmo via permissionamento de níveis de acesso.
#2) Um bom software é aquele que …
:.: Melhores práticas de testes (2/9):.: Melhores práticas de testes (2/9)
32
• Tenha interoperabilidade: que é a capacidade de trocar dados com outros softwares;
• Seja de fácil manutenção: reutilização de componentes, parametrização, orientação a objetos e todas as demais técnicas que organizam e facilitem a vida do programador;
• Seja gerenciável: que é a habilidade de gerenciar os recursos de alocação, gestão de conteúdo e configuração;
• Seja seguro: que é a capacidade do software executar uma funcionalidade sem causar condições inseguras;
• Seja fácil de usar: é a facilidade que o software pode ser aprendido e operado;
• Seja verificável: é a capacidade de verificar que o software está trabalhando corretamente.
#2) Um bom software é aquele que …
:.: Melhores práticas de testes (2/9):.: Melhores práticas de testes (2/9)
33
• A linguagem escrita não é um meio confiável de especificar requisitos. Podem aparecer requisitos:• Vagos• Ambíguos• Incompletos• De difícil compreensão e entendimento• Não tão fáceis de se testar
• DICA: Use alguns desses modelos para incrementar a linguagem escrita:• Modelo de dados• Modelo de processos • Modelo de objetos• Tabelas de decisão• Casos de uso
#3) Adote um modelo baseado em requisitos
:.: Melhores práticas de testes (3/9):.: Melhores práticas de testes (3/9)
34
• Para cada requisito, identifique os possíveis cenários;
• Use técnicas como:• Classes de equivalência;• Gráficos de causa e efeitos;• Tabelas de decisão;• Árvores de decisão;• Análise da integridade relacional;• Casos de uso.
#4) Defina formalmente os casos de testes
:.: Melhores práticas de testes (4/9):.: Melhores práticas de testes (4/9)
35
• Testes positivos: é qualquer atividade que aponta a validação de um requisito. Supõe-se que o dado entrado é válido e ele será processado através dos caminhos normais;
• Testes negativos: é o processo de execução de um programa com a intenção de encontrar erros. Supõe-se que o dado entrado é inválido e ele será processado através da manipulação errada dos caminhos funcionais;
#5) Execute casos de testes positivos e negativos
:.: Melhores práticas de testes (5/9):.: Melhores práticas de testes (5/9)
36
Requisito #1 Requisito #2 Requisito #... Requisito #n
Caso de Teste #1
Passou Passou Não executado
Caso de Teste #2
Passou Passou
Caso de Teste #3
Falhou Passou Passou
Caso de Teste #...
Caso de Teste #n
#6) Crie matriz de rastreabilidade de componentes
:.: Melhores práticas de testes (6/9):.: Melhores práticas de testes (6/9)
37
• Baseie os cenários de teste de regressão em: Análise de impacto
Quando um requisito é modificado, quais são os componentes afetados com a mudança ?
Quando um componente é modificado, quais os requisitos que devem ser retestados novamente ?
Este tipo de análise começa no desenvolvimento com os programadores e continua durante a fase dos testes
Análise de risco
• Ferramentas de Capture/Playback podem ser muito útil (inclusive para automatizar os testes de regressão).
#7) Execute testes de regressões mais abrangentes
:.: Melhores práticas de testes (7/9):.: Melhores práticas de testes (7/9)
38
• Ferramenta de planejamento de testes• Gerenciamento de testes• Ferramentas de Case Design• Ferramentas para testes de cobertura• Ferramentas para execução de testes e de
capture/replay• Ferramentas para análise estática• BugTrackers
#8) Selecione ferramentas para suportar os testes
:.: Melhores práticas de testes (8/9):.: Melhores práticas de testes (8/9)
39
• Testes de software é uma disciplina contextual;• A prática é a melhor maneira de aprimorar seus
conhecimentos;• Procure se certificar profissionalmente:
• CSTE (QAI/USA)• CSQA (QAI/USA)• CBTS (ALATS/BRZ)
#9) Aprimore continuamente sua capacitação
:.: Melhores práticas de testes (9/9):.: Melhores práticas de testes (9/9)
40
Em desenvolvimentoEm teste
Em teste
Em homologação
Em homologaçãoEm produção
:.: Ambientes de produção:.: Ambientes de produção
41
:.: Ambientes de produção:.: Ambientes de produção
42
• Toda a estrutura é destinada aos analistas de sistema e programadores;
• É segmentado em produção e testes • É facultativo o uso das equipes
• Toda a estrutura é destinada aos analistas de sistema e programadores;
• É segmentado em produção e testes • É facultativo o uso das equipes
:.: Ambientes de produção:.: Ambientes de produção
43
• Toda a estrutura é destinada à equipe de testadores
• Testa os requisitos de software• Estrutura semelhante ao da produção
• Toda a estrutura é destinada à equipe de testadores
• Testa os requisitos de software• Estrutura semelhante ao da produção
:.: Ambientes de produção:.: Ambientes de produção
44
• Pelos erros ocorridos e métricas coletadas, novos casos serão confeccionados para garantir a qualidade de software
• Beta testes somente para um grupo de usuários
• Pelos erros ocorridos e métricas coletadas, novos casos serão confeccionados para garantir a qualidade de software
• Beta testes somente para um grupo de usuários
:.: Ambientes de produção:.: Ambientes de produção
45
Slide: 45
• Escolha mais de três maneiras para medir a estabilidade do produto será liberado em produção:1. Padrões de Codificação2. Fluxo de Falhas/Condição3. Estabilidade Performática4. Qualidade dos Testes5. MNC (Métricas Não Cartesianas)
:.: Métricas clássicas :.: Métricas clássicas em testesem testes
46
Slide: 46
Em cada ciclo de testes, consegue-se coletar:• As falhas por módulos(local aonde a falha foi detectada);
• O progresso dos testes;• A quantidade de falhas por status, severidade, testador, etc;
• O bugfix time;
• A quantidade de falhas em ambientes de pré e pós produção;
• A densidade de falhas ( #falhas/KLOC )• A distribuição de esforço por fases de produção;• A evolução da qualidade dos testes;• A evolução do tamanho de cada versão;
:.: Métricas clássicas :.: Métricas clássicas em testesem testes
47
Slide: 47
São métricas que dependem do contexto da análise.
• Fatores que atrapalham a qualidade dos testes (falta de metodologia, tempo curto para execução dos testes, documentação rudimentar, infraestrutura, etc.);
• Percentual de acertos do bugfix;• Índice de satisfação do cliente;• Evolução dos requisitos por versão;
:.: Métricas não :.: Métricas não cartesianascartesianas
48
Slide: 48Viv
ência
Acredite:
– Uma métrica é a fotografia de uma situação em um dado momento;
– Em um processo, existem ferramentas, métodos e pessoas. E para “medir” as pessoas, o conjunto de métricas, com certeza, não serão cartesianas;
– Por mais caótico que seja a produção de software na corporação, sempre haverá uma maneira de medir a sua eficiência;
– “Se me fosse dado seis horas para derrubar uma árvore, as quatro primeiras passaria afiando o machado. (Abraam Lincoln)”
– Planeje sempre a sua medição.
49
:.: Métricas recursos de infra:.: Métricas recursos de infra
50
448.5 MB/hr324.9 MB/hr214.0 MB/hr170.1 MB/hr123.2 MB/hr115.7 MB/hr73.9 MB/hr31.4 MB/hr31.0 MB/hr26.0 MB/hr18.0 MB/hr
SMBCC:Mail
IPNFSRPC
NetBIOS Session SrvcTCPISO
SQL ServerWWW (Web)
FTP
10.2 ms1.5 ms --
35.5 ms123.3 ms90.0 ms -- ms -- ms4.2 s
189.0 ms673.4 ms
Application List
Bytes Application Average Response Time
113 Applications
Lock Filter
WAN Top ApplicationsSMB32%
All Others10%
NetBIOSSession Srvc
6%TCP7%
Pipe files8%
IP Port 11779%
CC:Mail28%
Passo Nove
:.: Métricas recursos de infra:.: Métricas recursos de infra
51
Slide: 51
1. Preparação dos testes
Objetivo: preparar todas as informações e artefatos necessários para um efetivo e eficiente processo de testes. Isto inclui levantar as especificações de uso, estabelecer as classe e desenhar um modelo flexível para o processo de testes.
:.: O ciclo de testes:.: O ciclo de testes
52
Slide: 52
2. Planejando os testes
Objetivo: identificar a estratégia e procedimentos que melhor se adaptem à metodologia de desenvolvimento garnatindo a eficiência e eficácia dos testes.
Esta etapa está em paralelo ao desenho do sistema e inclui: recursos, responsabilidades e objetivo dos testes; identificação de riscos e prioridades e identificação de entidades que serão ou não testadas.
:.: O ciclo de testes:.: O ciclo de testes
53
Slide: 53
3. Desenhando os testes
Objetivo: definir os casos de teste, dados e procedimentos que estarão em conformidade com os requisitos iniciais. Esta etapa envolve planejamento estratégico próativo que detecte possíveis falhas. A definição dos testes deve primar pela simplicidade e baixo custo de execução.
:.: O ciclo de testes:.: O ciclo de testes
54
Slide: 54
3. Executando os testes
Objetivo: Baseado nos casos de teste definidos na etapa anterior a execução será dinamizada de maneira que se descubra um número maior de falhas.
:.: O ciclo de testes:.: O ciclo de testes
55
Slide: 55
4. Análise do resultado dos testes
Objetivo: Pra aprimorar o processo produtivo, nesta etapa são coletadas analisadas as evidências geradas pela etapa anterior.
:.: O ciclo de testes:.: O ciclo de testes
56
1. Criar os artefatos documentais para os seguintes softwares: Controle de Estoque; Locadora de DVD; Automoção Comercial
(lanchonete);
2. Considerações: Dividam-se em 3 grupos e
escolham o System Under Testing (SUT);
Se tiver dúvida, pergunte ao Professor sobre os requisitos negociais de cada software;
Garanta a rastreabilidade dos artefatos;
3. Tempo estimado: 1h30min
:.: Desafio #2:.: Desafio #2
57
• Interpretação (do usuário e do analista);• Ambiguidade;• Inconsistência;• Não relevância;• Informalidade;• Não testabilidade;• Gramatical e morfológica;• Sub especificação.
:.: Anomalias dos Artefatos documentais :.: Anomalias dos Artefatos documentais
58
Que exista um
DOCUMENTO ESCRITO (±Formal)
com aquilo que deve ser feito e que neste documento exista uma
lista identificada de REQUISITOS.
(pode ser um anexo)
CMM nível 2 é essencialmente sobre Requisitos
CMM nivel 3 introduz formalmente Testes de Requisitos (peer-reviews)
:.: Premissas para se executarem testes:.: Premissas para se executarem testesVivên
cia
59
:.: Apresentação da metodologia A360’:.: Apresentação da metodologia A360’Vivên
cia
• Criada por Rodrigo Z. Passos em 2006 para ajudar a área de Gestão de Projetos de uma grande siderúrgica. A missão era envolver todos os colaboradores na homologação de artefatos de fornecedores externos, atestando ou não a entrega do produto.
• A metodologia baseia-se em 3 premissas:1. No perfil de colaborador envolvido (permite até 4 perfis);2. No Questionário com n perguntas baseadas na ISO 9126 e
configuradas de acordo com o artefato a ser inspecionado (documentos, diagramas, etc.);
3. No parecer técnico final.
Objetivo lúdico: testar o software antes dele existir !
60
:.: Apresentação da metodologia A360’:.: Apresentação da metodologia A360’Vivên
cia
• O conceito de qualidade é variável em relação ao perfil do analisador;
• Uma equipe de testes é mais qualificada para inspecionar a qualidade do que qualquer outro time; mas a etapa de homologação legalmente envolve terceiros;
• O desafio foi desenvolver uma metodologia que transforma a subjetividade da análise contextual do documento, em métricas objetivas que demonstrem matematicamente a qualidade do artefato inspecionado;
• Criou-se um questionário-base para todos os colaboradores envolvidos responderem uma escala gradativa de 1 a 7. Cada uma das respostas gera uma média ponderada para a categoria de análise realizada (via ISO9126);
• Nenhum dos colaboradores pode ter acesso ao questionário de seu colega;
• O confronto das médias encontradas pelos testadores e demais colaboradores fornece várias perspectivas de análise sobre a qualidade do artefato.
Fatores motivadores para criação da metodologia
61
:.: Apresentação da metodologia A360’:.: Apresentação da metodologia A360’Vivên
cia
Insumo básico - ISO 9126: Portais da Qualidade
Portais da Qualidade
Significado Pergunta Chave
Funcionabilidade Evidencia o conjunto de funções que atendem às necessidades implícitas e explícitas para a finalidade a que se destina o produto
Satisfaz às necessidades ?
Confiabilidade Evidencia a capacidade do produto de manter seu desempenho ao longo do tempo e em condições estabelecidas.
É imune a falhas ?
Usabilidade Evidencia a facilidade para a utilização do produto
E fácil de usar ?
Eficiência Evidencia o relacionamento entre o nível de desempenho do produto e a quantidade de recursos utlizados, sob condições estabelecidadas..
É rápido e “enxuto” ?
Manutenibilidade Evidencia o esforço necessário para realizar modificações no produto.
É fácil de modificar ?
62
:.: Apresentação da metodologia A360’:.: Apresentação da metodologia A360’Vivên
cia
• Engenharia Conceitual:• normalmente é o escopo do projeto acordado entre a área de
usuários e demais técnicos;• Requistos de Negócio/Funcionais:
• lista contendo todas as necessidades do software/solução em TI;
• Especificações Funcionais ou de Caso de Uso• Diagramas UML:
• estado, transição, casos de uso, etc;• Diagramas Fluxo de Dados • Diagramas de Entidade e Relacionamento
Tipos de artefatos que podem ser inspecionados:
63
1. Inspecionar os artefatos documentais criados anteriormente para: Controle de Estoque; Locadora de DVD; Automoção Comercial
(lanchonete);
2. Considerações: Dividam-se novamente em 3
grupos, com composição respectiva diferente da anterior;
Use a metodologia A360’; Registre as anomalias
encontradas;
3. Tempo estimado: 2h
:.: Desafio #3:.: Desafio #3
64
Slide: 64
PessoasPessoas
65
Slide: 65
• Fique preparado: tudo vai bem até o seu relatório apontar o primeiro problema;
• Você é apenas um inspetor ! A garantia da qualidade não é a sua responsabilidade.
• Bugs são altamente relevantes ao ciclo de produção;• Mantenha seu senso de humor e aceitação. Não se irrite por estar
testando “uma bosta” … Faça seu trabalho e tenha vida normal após o expediente de trabalho.
• Você só pode testar aquilo que se pode observar;• Alguém aqui já testou um sistema de bilhetagem ????
• Use a disciplina a seu favor: torne-se amiguinho de padrões e processos;
• Fique esperto: nunca se terá tempo suficiente para se testar um SUT;
• Não se iluda: não existe Software “Zero-Defect” ! • Desenvolvedores não são inimigos !!!• Sobre o SUT: simplicidade não é sinônimo de facilidade.
:.: Frases a serem ditas a um testador::.: Frases a serem ditas a um testador:Vivên
cia
66
Slide: 66
• Já existe carreira profissional de teste• Pode ser um Analista de Qualidade/Teste ou
Tester;• Já existem algumas publicações e obras em
português;• Os salários dos testadores são geralmente iguais
aos de desenvolvedores;• Já existe um mercado de “usados e experientes”.
• Em muitas corporações, ainda é novidade• O RH ainda não sabe recrutar profissionais em
testes.• Falta mão de obra especializada
• Os bons profissionais estão alocados.
:.: Situação Atual no mercado:.: Situação Atual no mercado
67
Slide: 67
• Tem um forte auto-marketing;• Sabe automotivar-se;• Entende e defende o usuário/cliente;• Seleciona talentos na equipe que farão a
diferença na hora da entrega do produto de software com qualidade;
• Estuda o processo negocial, aplica o conhecimento técnico e acredita no seu taco ( pró-atividade)
:.: Um bom profissional de testes::.: Um bom profissional de testes:Vivên
cia
68
Slide: 68
• O programa de certificação do Quality Assurance Institute (QAI) é um dos mais aceitos internacionalmente.
• Existem dois tipos de certificação:1. CSTE (“produto”): preparação do ambiente de
testes; planejamento de testes; test design; execução de testes; automação; ferramentas; elaboração de relatórios; etc.
2. CSQA (“processo”): estrutura de modelos de qualidade; definição de padrões de prática e controle de qualidade; construção, implementação e melhoria dos processos de qualidade; métricas.
• Outras instituições outorgantes: International Software Testing Institute e American Society for Quality
:.: Certificação Profissional:.: Certificação Profissional
69
Slide: 69
:.: Papéis & Responsabilidades:.: Papéis & ResponsabilidadesPapel Responsabilidades
Gerente, Coordenador ou Líder de testes
Viabiliza os recursos necessários para um esforço de testes; conduz as atividades e as monitora em conformidade com o planejamento; Realoca recursos ao longo do ciclo.
Analistas de Testes Planeja a estratégia e elabora casos de testes, baseando-se nos requisitos de negócio do SUT.
Arquiteto de Testes Prepara toda infra estrutura necessária para se executar a estratégia de testes. Instala ferramenta, gera massa de dados, mede performance, etc.
Executor de Testes Executa tudo o que está planejado. Figura-chave do ciclo de testes pois as ocorrências encontradas por ele são os indicadores da qualidade do produto inspecionado.
70
Slide: 70
FerramentasFerramentas
71
FerramentasFerramentasFerramentasFerramentas
Gerenciamento de Dados e Arquivos
Depuração e Análise Interativa
Gerenciamento de Falhas e Performance
Automação dos Testes
:.: Visão geral de ferramentas em testes:.: Visão geral de ferramentas em testes
72
Slide: 72Viv
ência
A Tecnologia deve conter:
•GUI: Interface com capacidades de capture / playback, planejamento, script, gerenciar e analisar resultados, relatórios e gráficos;
•Repositório: Armazena o projeto; •Carga: Simulação de usuários, volume,
performance e stress;•Analisador: Monitorar teste;•Detector: Detecta e relata erros/problemas;•Tracker: Captura defeitos e armazena;
:.: Dicas sobre ferramentas:.: Dicas sobre ferramentas
73
Slide: 73Viv
ência
Dicas importantes para gerentes que irão adquirir ferramentas de mercado:
• Definir requisitos iniciais:– Quais são os principais problemas que as ferramentas deverá a ajudá-lo resolver ?– Quais são as capacidades que a ferramenta deverá ter para ser eficiente no ambiente de trabalho ?– Qual é o impacto da absorção cultural das novas tecnologias defendidas pela ferramenta ?– Se as diretrizes estratégicas existem investimentos em testes de automação, qual é o ROI da ferramenta
?• Pesquisar muito antes de comprar:
– Interaja com a comunidade: participe de feiras, congressos, etc;– Leia tudo o que puder: web, livros, revistas, jornais, blog;– Analise a relação contextual: mudança cultural corporativa X nova ferramenta;
• Refinar os requisitos:– Durante a pesquisa, você irá descobrir novas necessidades em termos ferramentais;– Ache uma maneira de convencer o setor de que aquela ferramenta não irá acabar com o emprego dos
colaboradores. Apresente contigência, caso isso seja inevitável;• Fazer prova de aderência:
– É a chance que se têm de verificar o quão eficiente a ferramenta será para o ciclo produtivo da corporação
• Cuidado: Os grandes players são predadores– Eles sempre irão dizer que ferramentas “salvarão a lavoura”. – Não se enganem: estes só vendem “caixinhas”.– Delimite o seu terreno.
:.: 5 etapas de avaliação de ferramentas::.: 5 etapas de avaliação de ferramentas:
74
ExperimentosExperimentos
75
Slide: 75
:.: Inspeção de Artefatos em TI (1/5):.: Inspeção de Artefatos em TI (1/5)Por Ciclo de Entregas
Qualid
ade
Ciclo de Vida
Qualidade suficientemente boa
Não dá pra testar a Qualidade
O artefato foi liberado. O Ciclo de testes começa aqui !
Build / Versão / Release
Fim do Ciclo
Testes NOK: problemas à vista
Testes OK: comportamento esperado
Testes não executados:Várias causas.
Vivên
cia
76
Slide: 76
:.: Inspeção de Artefatos em TI (2/5):.: Inspeção de Artefatos em TI (2/5)Ritmo mais demorados de testes
Qualid
ade
Ciclo de Vida
Qualidade suficientemente boa
Não dá pra testar a Qualidade
O artefato foi liberado. O Ciclo de testes começa aqui !
Build / Versão / Release
Fim do Ciclo
Testes NOK: problemas à vista
Testes OK: comportamento esperado
Testes não executados:Várias causas.
Vivên
cia
77
Slide: 77
:.: Inspeção de Artefatos em TI (3/5):.: Inspeção de Artefatos em TI (3/5)Ritmo de testes estilo “Pizzaria”
Qualid
ade
Ciclo de Vida
Qualidade suficientemente boa
Não dá pra testar a Qualidade
O artefato foi liberado. O Ciclo de testes começa aqui !
Build / Versão / Release
Vivên
cia
Testes NOK: problemas à vista
Testes OK: comportamento esperado
Testes não executados:Várias causas.
78
Slide: 78
:.: Inspeção de Artefatos em TI (4/5):.: Inspeção de Artefatos em TI (4/5)Sob pressão forçam a homologação.
Qualid
ade
Ciclo de Vida
Qualidade suficientemente boa
Não dá pra testar a Qualidade
O artefato foi liberado. O Ciclo de testes começa aqui !
Fim do Ciclo
Testes NOK: problemas à vista
Testes OK: comportamento esperado
Testes não executados:Várias causas.
Vivên
cia
Build / Versão / Release
79
Slide: 79
:.: Inspeção de Artefatos em TI (5/5):.: Inspeção de Artefatos em TI (5/5)Está acontecendo algo com quem produz o SUT …
Qualid
ade
Ciclo de Vida
Qualidade suficientemente boa
Não dá pra testar a Qualidade
O artefato foi liberado. O Ciclo de testes começa aqui !
Fim do Ciclo
Testes NOK: problemas à vista
Testes OK: comportamento esperado
Testes não executados:Várias causas.
Vivên
cia
Build / Versão / Release
80
Slide: 80
:.: Finalizando (1/2):.: Finalizando (1/2)
Resultados obtidos com os desafios deste curso:• Desafio#1 : descoberta da real
importância sobre como se deve escrever um artefato documental em TI;
• Desafio#2: a partir do conhecimento de domínio público, foram construídos os artefatos documentais para o ciclo de testes de 3 SUTs;
• Desafio#3: aplicando a teoria à prática - pelo uso da ferrementa Camaleão®, o aluno populou os ciclos de controle de produção e testou efetivamente os protótipos dos SUTs.
81
Slide: 81
• São premissas de uma boa prática de testes de software:
O valor de qualquer prática, depende de seu contexto;
Existem boas práticas em um contexto, mas não existem melhores práticas;
Projetos evoluem ao longo do tempo de maneira raramente antecipada;
Pessoas trabalhando em espírito de equipe são o contexto mais importante de qualquer projeto;
:.: Finalizando (2/2):.: Finalizando (2/2)