Testes de Software &

Garantia da Qualidade
(Conceitos & Fundamentos)
Professor: Rodrigo Zauza Passos

1
 Slide: 2

:.: Objetivo

Capacitar o aluno a testar uma

solução tecnológica fundamentando-
se
nas melhores práticas de
Testes e de Garantia da Qualidade.

2
 Slide: 3

:.: A Oratec trabalha com as práticas:

Achar falhas

Evitar falhas

Previnir
falhas

3
 Slide: 4

:.: Variáveis de Contexto

• 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

Ferramentas
em suas competências

Processos

Pessoas
nivelada ao seu perfil
pessoal;
– Ferramentas: são
componentes
facilitadores e não
complicadores.

• … e ele é amparado pela

quadra “Escopo, Prazo,
Custo & Qualidade” ,
mandamento de qualquer
bom gerente de área.
4
 to
ei
:.: Nivelamento de Conceitos (I)
nc
Co

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”.
5
 to
ei
:.: Nivelamento de Conceitos (II)
nc
Co

Visões sobre a qualidade de um Software:

Usuário Implementador Testador Organização

Facilidade de Facilidade de Software com boa Cumprimento
uso, manutenção e qualidade é aquele de prazo, boa
desempenho, conformidade em que cumpre com previsão de
confiabilidade relação aos os requisitos custo, boa
dos resultados, requisitos de negociais com o produtividade
etc. usuários, etc. mínimo de falhas e rentabilidade.
possível.

6
 to
ei
:.: Nivelamento de Conceitos (III)
nc
Co

Defeito=Falha=Anomalia=Bug=Ocorrência

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.

7
:.: Bug Arrasadores (1/4)

Caso 1 - Disney´s Li
on King ( 1994-1995)
-A Disney , em 1994
lançou seu primeiro jo
crianças “ Lion King go de multimedia para
Animated stories”. Er
e renomada , fez um a a primeira da Disne
enorme campanha de y,
EUA . Vendas foram marketing por todo os
absurdamente fantástic
as (vendas de natal).
Porém , no dia seguin
te , 26 de dezembro de
atendimento ao client 1994 o departamento
e da Disney recebeu de
ligações de clientes in uma enxurrada de
dignados e nervosos.
muitas das plataform O CD não funcionava
as de PC existentes no em
software foi desenvol mercado. Razão : O
vido em uma única pl
as mais comuns do m ataforma ( que não re
ercado!). fletia
Faltou um simples te
ste de multiplataform
a....

8
:.: Bug Arrasadores (2/4)

Caso 2 – Patriot Miss

ile Defense System ,
1991
Um programa de defe
sa americano chamad
chamado “U.S. Patriot o de “ star wars” incl
missile”. O primeiro uía o
golfo em 1991 para de uso foi na guerra do
fender dos misseis Sc
este sistema falhou in uds do Iraque. Porem
úmeras vezes contra ,
um míssil iraquiano qu vários misseis , inclui
e matou 28 soldados ndo
na Arábia Saudita. americanos em Dhahr
Numa analise , encont an ,
sistema de contagem raram a causa : um bu
( pequeno timing erro g no
de 14 horas de difere r ) culminando num
nça entre os relógios, erro
contagem defasado. deixando o sistema de
Custo : No mínimo,
28 vidas.

9
:.: Bug Arrasadores (3/4)

Caso 3 – Limite de en
dereços de computa
dor na WWW
Quando o TCP/IP (pro
tocolo de transmissão
foi criado pelos sr. V de pacotes da Internet
int Cerf e Bob Kahn, )
bilhões de endereços eles acharam que 4.3
eram suficientes. Pare
crescimento exponenc ce muito, mas com o
ial de transações ness
atingir o limite antes a plataforma, pode-se
do previsto. Um cons
governamentais estão órcio de organizações
se preparando para am
mais de 200 trilhões de pliar este número para
endereços possíveis.
A singela mudança im
plica mexer com mui
computadores espalh ta gente e muitos
ados pelo planeta. Se
de logística e sincron rá um problema compl
ização dos sistemas. exo

10
:.: Bug Arrasadores (4/4)

Caso 4 – Novo Sistem

a DDD no Brasil
Em julho de 1999, o Br
asil experimentou um
por mais de uma sem caos no sistema de tel
ana, devido a instalaç efonia
codificação de DDD. ão do novo sistema de
As razões do problem
a foram:
• A anatel não ch
ecou o resultado dos
estados. Entre estados testes feitos pelas oper
nenhum teste foi feito adoras dentro dos
;
• A troca do Siste
ma não passou por um
teste simulado em níve
• As operadoras ap l nacional;
enas simularam conexã
limitadas; o dos equipamentos em
área
• Nem todas as op
eradoras fizeram inves
mudança; timentos suficientes pa
ra suportar a
• A campanha pu
blicitária da Anatel en
operadoras, mas não ex fatizava somente o di
plicava com clareza as reito de escolha das
mudanças;
• Seis centrais da
Embratel tiveram erros
chamadas fossem parar na programação, fazen
em locais diferentes. do com que as

11
 ia
nc
:.: Nivelamento de Conceitos (IV)
vê
Vi

Testes de Software ≠ Garantia da Qualidade

– 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.

12
 Slide: 13

Pr ocesso
s

13
 Slide: 14

:.: Processo de Software

ferramen Req usuários

tas Processo de Software
procedime Req.
ntos desenvolvedor
pessoa Req.
s organização

Gerência eficaz e controle Processo de Software

das atividades
muito bem definido
14
 Slide: 15

:.: Métodos de Produção

P
PM
Wat

MB
Boo

Wate
el

Boocc

Cata
rfall

Catalysi
rfall
O
OM
X
d

BO
XM

hh
o

MT
US

OK
M
M

ss
V-

e
T

K
DP

lysi
d el
o
-M
W

DSD
DSDM
FDD

C
FDD

SCR

Cristta

Ic
SCRUM
Na Engenharia de Software,

Ico
r
R
RA

P
AD SSAD

is
D

on
ll
X
XP
RR

EU
M

nix
UU existem várias metodologias de produção ...
P

UM
M

ix
PP

Informações processadas Focaliza o quê

Função e desempenho desejados Análise do sistema
Definição Interfaces estabelecidas Fase planejamento
Riscos mapeados Análise de requisitos

Arquitetura da solução Focaliza o como

Estrutura de dados Projeto da Arquitetura
Desenvolvimento Planejamento dos Testes Codificação
Padrões de codificação Testes
Contramedidas
Focaliza as mudanças
Manutenção para a gerência
da produção
Manutenções A.C.E.

15
 Slide: 16

:.: Padrões de Qualidade

Existem vários modelos e padrões de qualidade:

16
 Slide: 17

:.: Padrões de Qualidade

Existem vários modelos e padrões de qualidade:

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.

M
an
Co or abil ridacia
nf ret ida de
e

ut e ilida ad
Fl esta
T
ia itu d
n

e il id d e

ex b
ad

en
U s t e g iê
In Efic

ib ilid

ib
ilid
b

ad
de e
C

Portabilidade
Reusabilidade
Interoperabilida
de
17
Modelo de MCall (1977)
 Slide: 18

:.: Padrões de Qualidade para testes

 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

18
 Slide: 19

:.: Um bom modelo de produção

teste
teste Testes
Testes
Requerimentos
Requerimentos de Aceitação
de Aceitação
doc
doc

teste
teste
Testes
Testes
Análise
Análise de
deSistema
Sistema
doc
doc

teste
teste Testes
Desenho Testes
Desenho de
doc
doc deIntegração
Integração

teste
teste
Testes
Testes
Codificação
Codificação de
deUnidade
Unidade
doc
doc

Processo Produto
19
 Slide: 20

:.: Visão Geral sobre os Testes

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

20
 ia
nc
:.: O Processo de Testes de Software
vê
Vi

Existem basicamente 2 visões sobre os testes:

Visão Restrita Visão Abrangente

− Um bom testador é um bom
programador;
− Testar significa mais gastos
de recursos e tempo do
projeto;
− Um bom testador é aquele
que domina as regras
negociais do SUT (System
Under Testing);
− Testar significa investir para
gastar menos;

− O testador só deve achar − Além de achá-los, o testador

erros. deve indicar como evitá-los e
prevení-los. (QA/QD/QC)

21
:.: O Processo de Testes de Software
São premissas dos testes de software:

Registrar/monitorar erros

Analisar todos os requisitos

Produzir métricas

Formular indicadores
de qualidade

22
:.: O Processo de Testes de Software
Atividades Macro X Responsáveis:

Analistas /Arquiteto
de Testes

Analista/Executores de
Testes
Concepção
Diagnosticar
situação
atual Instrumentalização
Instrumentalizar as estratégias definidas
Complexidade

Assimilar
Conhecimento
Criar, compartilhar e realimentar Expertise
Definir
Estratégias

Evangelização Analistas e
Executores
Monitorar e criar cultura, Divulgar, Negociar,
Compartilhar, Justificar, Celebrar, Aperfeiçoar...

t t+1
Ciclo de Vida
23
 ia
nc
:.: O Processo de Testes de Software
vê
Vi

Dicas úteis:
• 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;

24
 to
ei
:.: Nivelamento de Conceitos (V)
nc
Co

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.
25
:.: Desafio #1
Construa um simples caso de teste cuja
meta é:

Verificar se um palito de fósforo acende.

Tempo estimado: 30 minutos (20/10)
26
:.: O Processo de Testes de Software
A estratégia de testes faz parte da Metodologia dos
testes !!!
Verificação de
Diagramas UML Testes de regressão

Validação de modelos ER
Testes de Carga e Stress

Validação/Verificação de Inspeção de
requisitos Artefatos Doc. Testes caixa preta

Régua de Avaliação
Fornecedores Testes de vulnerabilidades

Estratégia de testes
Testes exploratórios

Testes caixa branca

Testes Funcionais Testes unitários

Testes automatizados
Testes baseados em cenários Testes negativos

27
:.: 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;
28
• Testes de regressão: aplicável quando um coponente do SUT sofre alteração.
:.: O ciclos de produção e
de testes de software

Esclarecimento Revalidar

Levantament Análise dos

o de Inspeção e
Requisitos e Especificação
Necessidades Validação
Artefatos /Desenho

Reescreve
r
Corrigir e solucionar
dúvidas

Ciclo de Reparo de
Gerenciamento do ciclo
Defeitos de produção do
software
Gerenciamento de
Enviar Testes e Defeitos
Abrir Retestar
É Defeito ? Defeito
Defeito Defeito
Fornecedor

Cancelar Encerrar
BUGFix ?
Defeito Defeito

Slide: 29
:.: Melhores práticas de testes (1/9)

#1) Requisito é a base do teste

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

30
 :.: Melhores práticas de testes (2/9)

#2) Um bom software é aquele que …

• É 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.
31
:.: Melhores práticas de testes (2/9)

#2) Um bom software é aquele que …

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

32
:.: Melhores práticas de testes (3/9)

#3) Adote um modelo baseado em requisitos

• 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
33
:.: Melhores práticas de testes (4/9)

#4) Defina formalmente os casos de testes

• 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.
34
:.: Melhores práticas de testes (5/9)

#5) Execute casos de testes positivos e

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

35
:.: Melhores práticas de testes (6/9)

#6) Crie matriz de rastreabilidade de

componentes
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

36
 :.: Melhores práticas de testes (7/9)

#7) Execute testes de regressões mais

abrangentes
• 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).

37
:.: Melhores práticas de testes (8/9)

#8) Selecione ferramentas para suportar os

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

38
:.: Melhores práticas de testes (9/9)

#9) Aprimore continuamente sua capacitação

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

39
 :.: Ambientes de produção

Em homologação
Em produção

Em homologação

Em teste

Em teste Em desenvolvimento

40
:.: Ambientes de produção

41
:.: Ambientes de produção

• Toda a estrutura é destinada aos

analistas de sistema e programadores;
• É segmentado em produção e testes
• É facultativo o uso das equipes

42
 :.: Ambientes de produção

• Toda a estrutura é destinada à equipe de

testadores
• Testa os requisitos de software
• Estrutura semelhante ao da produção

43
:.: Ambientes de produção

• 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

44
 Slide: 45

:.: Métricas clássicas

em testes

• Escolha mais de tr
ês maneiras para
medir a estabilida
de do produto será
liberado em produ
ção:
1. Padrões de Cod
ificação
2. Fluxo de Falhas
/Condição
3. Estabilidade Perf
ormática
4. Qualidade dos T
estes
5. MNC (Métricas N
ão Cartesianas)

45
 Slide: 46

:.: Métricas clássicas

em testes

Em cada ciclo de testes, co

nsegue-se coletar:
• As falhas por módulos
(local aonde a falha foi
detectada);
• O progresso dos testes
;
• A quantidade de falha
s 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 qualida
de dos testes;
• A evolução do tamanho
de cada versão;

46
 Slide: 47

:.: Métricas não

cartesianas

São métricas que dependem

do
contexto da análise.
• Fatores que atrapalham
a qualidade
dos testes (falta de metodol
ogia,
tempo curto para execução
dos
testes, documentação rudim
entar,
infraestrutura, etc.);
• Percentual de acertos do
bugfix;
• Índice de satisfação do
cliente;
• Evolução dos requisitos
por versão;

47
 Slide: 48

ia
nc Acredite:
vê
Vi

– 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.

48
:.: Métricas recursos de infra

49
 :.: Métricas recursos de infra
Passo Nove

WAN Top Applications

SMB
32%

CC:Mail
28%

All Others Application List

10%
113 Applications
Bytes Application Average Response Time
448.5 MB/hr SMB 10.2 ms
NetBIOS 324.9 MB/hr CC:Mail 1.5 ms
Session Srvc IP Port 1177 214.0 MB/hr IP --
6% 9% 170.1 MB/hr NFS 35.5 ms
123.2 MB/hr RPC 123.3 ms
TCP Pipe files 115.7 MB/hr NetBIOS Session Srvc 90.0 ms
7% 8% 73.9 MB/hr TCP -- ms
31.4 MB/hr ISO -- ms
31.0 MB/hr SQL Server 4.2 s
26.0 MB/hr WWW (Web) 189.0 ms
18.0 MB/hr FTP 673.4 ms

Lock Filter
50
 Slide: 51

:.: O ciclo de testes

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.

51
 Slide: 52

:.: O ciclo de testes

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.

52
 Slide: 53

:.: O ciclo de testes

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.

53
 Slide: 54

:.: O ciclo de testes

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.

54
 Slide: 55

:.: O ciclo de testes

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.

55
:.: Desafio #2
1. Criar os artefatos
documentais para os
seguintes softwares:
 Controle de Estoque;
 Locadora de DVD;
 Automoção Comercial
(lanchonete);
1. 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;
1. Tempo estimado: 1h30min
56
:.: Anomalias dos Artefatos documentais

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

57
 ia
nc
:.: Premissas para se executarem testes
vê
Vi

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)

58
 ia
nc
:.: Apresentação da metodologia A360’
vê
Vi

Objetivo lúdico: testar o software antes dele

existir !
• 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.

59
 ia
nc
:.: Apresentação da metodologia A360’
vê
Vi

Fatores motivadores para criação da metodologia

• 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
60
colaboradores fornece várias perspectivas de análise sobre a
 ia
nc
:.: Apresentação da metodologia A360’
vê
Vi

Insumo básico - ISO 9126: Portais da Qualidade

Portais da Significado Pergunta Chave
Qualidade
Funcionabilidade Evidencia o conjunto deSatisfaz às
funções que atendem àsnecessidades ?
necessidades implícitas e
explícitas para a finalidade
a que se destina o produto
Confiabilidade Evidencia a capacidade doÉ imune a falhas ?
produto de manter seu
desempenho ao longo do
tempo e em condições
estabelecidas.
Usabilidade Evidencia a facilidade paraE fácil de usar ?
a utilização do produto
Eficiência Evidencia o relacionamentoÉ rápido e “enxuto” ?
entre o nível de
desempenho do produto e
a quantidade de recursos
utlizados, sob condições
estabelecidadas..

Manutenibilidade Evidencia o esforçoÉ fácil de modificar ?

necessário para realizar
modificações no produto.

61
 ia
nc
:.: Apresentação da metodologia A360’
vê
Vi

Tipos de artefatos que podem ser

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

62
:.: Desafio #3
1. Inspecionar os artefatos
documentais criados
anteriormente para:
 Controle de Estoque;
 Locadora de DVD;
 Automoção Comercial
(lanchonete);
1. Considerações:
 Dividam-se novamente em 3
grupos, com composição
respectiva diferente da anterior;
 Use a metodologia A360’;
 Registre as anomalias
encontradas;
1. Tempo estimado: 2h

63
 Slide: 64

Pessoas

64
 Slide: 65

a
ci
ên
:.: Frases a serem ditas a um testador:
v
Vi

• 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. 65
 Slide: 66

:.: Situação Atual no mercado

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

66
 Slide: 67

a
ci
ên
:.: Um bom profissional de testes:
v
Vi

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

67
 Slide: 68

:.: Certificação Profissional

• 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 68
 Slide: 69

:.: Papéis & Responsabilidades

Papel Responsabilidades
Gerente, Coordenador ou Viabiliza os recursos necessários para
Líder de testes 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.

69
 Slide: 70

Ferramenta
s

70
:.: Visão geral de ferramentas em testes

Gerenciamento de Automação dos

Dados e Arquivos Testes

Ferramentas

Depuração e Gerenciamento de
Análise Interativa Falhas e Performance

71
 Slide: 72

ia
nc
:.: Dicas sobre ferramentas
vê
Vi

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;

72
 Slide: 73

ia
nc
:.: 5 etapas de avaliação de ferramentas:
vê
Vi

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.

73
Experiment
os

74
 Slide: 75

ia
nc
:.: Inspeção de Artefatos em TI (1/5)
vê
Vi

Por Ciclo de Entregas

Qualidade suficientemente boa

Testes NOK:
problemas à vista

O artefato foi liberado.

O Ciclo de testes começa Fim do Ciclo
Qualidade

aqui !
Testes não
executados:
Várias
Build / Versão / Release causas.

Testes OK:
comportamento
esperado
Não dá pra testar
a Qualidade

Ciclo de Vida
75
 Slide: 76

ia
nc
:.: Inspeção de Artefatos em TI (2/5)
vê
Vi

Ritmo mais demorados de testes

Qualidade suficientemente boa

Testes NOK:
problemas à vista

O artefato foi liberado.

O Ciclo de testes começa Fim do Ciclo
Qualidade

aqui !
Testes não
executados:
Várias
Build / Versão / Release causas.

Testes OK:
comportamento
Não dá pra testar esperado
a Qualidade

Ciclo de Vida
76
 Slide: 77

ia
nc
:.: Inspeção de Artefatos em TI (3/5)
vê
Vi

Ritmo de testes estilo “Pizzaria”

Qualidade suficientemente boa

Testes NOK:
problemas à vista

O artefato foi liberado.

O Ciclo de testes começa
Qualidade

aqui !
Testes não
executados:
Várias
Build / Versão / Release causas.

Testes OK:
comportamento
Não dá pra testar esperado
a Qualidade

Ciclo de Vida
77
 Slide: 78

ia
nc
:.: Inspeção de Artefatos em TI (4/5)
vê
Vi

Sob pressão forçam a homologação.

Qualidade suficientemente boa

Testes NOK:
problemas à vista

Testes não
executados:
O artefato foi liberado. Várias
O Ciclo de testes começa causas.
Qualidade

aqui !

Build / Versão / Release

Fim do Ciclo

Testes OK:
comportamento
esperado
Não dá pra testar
a Qualidade

Ciclo de Vida
78
 Slide: 79

ia
nc
:.: Inspeção de Artefatos em TI (5/5)
vê
Vi

Está acontecendo algo com quem produz o SUT …

Qualidade suficientemente boa

Testes NOK:
problemas à vista
O artefato foi liberado.
O Ciclo de testes começa
Qualidade

Fim do Ciclo
aqui !

Build / Versão / Release

Testes não
executados:
Várias
causas.
Não dá pra testar Testes OK:
a Qualidade comportamento
esperado

Ciclo de Vida
79
 Slide: 80

:.: 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. 80
 Slide: 81

:.: Finalizando (2/2)

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

81
 Slide: 82

Dúvidas & Sugestões:

rodrigo@oratec.com.br
http://www.oratec.com.b
r

82