1. LARISSA ROSOCHANSKY
TESTES E O CICLO DE DESENVOLVIMENTO DE
SISTEMAS
FASP
SÃO PAULO – 2006

2. LARISSA ROSOCHANSKY
05020430019-3
TESTES E O CICLO DE DESENVOLVIMENTO DE
SISTEMAS
Trabalho de conclusão
de curso como pré-
requisito para obtenção
do grau de Engenheiro
de Sistemas sob
orientação do Prof.
Edison Kalaf.
FASP
SÃO PAULO – 2006

3. Autor:
Larissa Rosochansky
Título:
Testes e o Ciclo de Desenvolvimento de Sistemas
Banca examinadora:
Prof. Edison Kalaf
FASP
SÃO PAULO – 2006

4. Dedico este trabalho ao
meu marido, que sempre
me apoiou em todas as
minhas decisões, e a meu
pai, inspiração intelectual,
sempre.

5. Resumo
Este trabalho apresenta uma visão prática da aplicação da fase de testes dentro
do ciclo de vida de um sistema, desde seu planejamento até o encerramento
desta fase, com uma reunião de lições aprendidas.
Por ser uma abordagem prática do trabalho feito pelo autor nestes últimos dois
anos em uma empresa de renome em "outsourcing" de serviços de teste, pode
muitas vezes divergir das idéias existentes no mercado.
Mesmo assim, a intenção é demonstrar a importância da observância real desta
fase dentro do ciclo de vida, assim como seu impacto na redução de custos
geral.
Assim sendo, mostraremos a abordagem prática com uma visão gerencial,
atingindo a todo o público interessado e atuante no ciclo de vida de sistemas.

6. Índice Sumário
1. Objetivo.............................................................................................................1
2. Introdução.........................................................................................................2
2.1. Princípios de teste...............................................................................................4
2.2. Níveis de Teste em uma organização................................................................4
2.3. Resumo................................................................................................................5
3. Histórico de testes...........................................................................................6
3.1. Início de tudo: um acidente................................................................................6
3.2. Décadas de 70 e 80..............................................................................................6
3.3. A trama se complica: década de 90...................................................................6
3.4. Parem tudo, a Web chegou.................................................................................7
3.5. Anos 2000: caindo na real..................................................................................8
3.6. Resumo................................................................................................................8
4. Testes e o ciclo de desenvolvimento...........................................................10
4.1. Redução de custos............................................................................................10
4.2. A relação custo/benefício de testes.................................................................13
4.3. Resumo..............................................................................................................14
5. Abordagens de testes....................................................................................15
5.1. Testes estáticos.................................................................................................15
5.1.1. Tipos de testes estáticos............................................................................................15
5.2. Testes dinâmicos..............................................................................................16
6. Técnicas de teste............................................................................................17
6.1. Teste de caixa preta..........................................................................................17
6.1.1. Teste de equivalência de classes...............................................................................18
6.1.2. Teste de valores limites..............................................................................................18
6.1.3. Tabela de decisão......................................................................................................19
6.1.4. Teste de matriz ortogonal...........................................................................................19
6.1.5. Diagramas de transição de estado.............................................................................20
6.2. Teste de caixa branca.......................................................................................21
6.2.1. Teste de fluxo de controle..........................................................................................21
6.2.2. Níveis de cobertura....................................................................................................22
6.2.3. Teste do caminho básico............................................................................................23
6.3. Encontro de erros..............................................................................................23
6.4. Resumo..............................................................................................................23
7. Níveis de testes..............................................................................................25
7.1. Teste unitário.....................................................................................................25

7. 7.2. Teste de integração ou modular.......................................................................26
7.3. Teste de sistemas..............................................................................................27
7.4. Teste de integração de sistemas......................................................................27
7.5. Teste de aceite...................................................................................................28
7.6. Testes de operabilidade....................................................................................28
7.7. Resumo..............................................................................................................29
8. Tipos de testes...............................................................................................30
8.1. Teste de requisitos............................................................................................30
8.2. Teste de desenho..............................................................................................30
8.3. Teste de regressão............................................................................................31
8.4. Teste de usabilidade.........................................................................................31
8.5. Teste de backup e recuperação.......................................................................31
8.6. Teste de desempenho.......................................................................................32
8.7. Teste de segurança...........................................................................................32
8.8. Teste de stress / volume...................................................................................32
8.9. Resumo..............................................................................................................33
9. Processo de testes.........................................................................................34
9.1. Planejamento e controle...................................................................................34
9.1.1. Escopo do teste..........................................................................................................35
9.1.2. Análise de risco..........................................................................................................35
9.1.3. Objetivos do teste.......................................................................................................35
9.1.4. Estratégia do teste......................................................................................................36
9.1.5. Gerenciamento de problemas e controle de mudanças.............................................36
9.2. Análise e desenho do teste..............................................................................36
9.2.1. Revisão da base de testes.........................................................................................37
9.2.2. Identificação das condições e requisitos de teste.......................................................37
9.2.3. Criação dos casos de teste........................................................................................37
9.2.4. Automação: quando usar...........................................................................................38
9.2.5. Avaliar a testabilidade dos requisitos e do sistema....................................................39
9.2.6. Desenhar a preparação de ambiente e necessidades de infra-estrutura...................40
9.3. Execução dos testes.........................................................................................40
9.4. Avaliação do critério de saída e relatórios......................................................41
9.5. Atividades de encerramento dos testes..........................................................41
9.6. Resumo..............................................................................................................42
10. Papéis e profissões existentes em testes.................................................43
10.1. Testador...........................................................................................................43
10.2. Analista de testes - negócios.........................................................................43
10.3. Analista de testes - técnico............................................................................44
10.4. Líder de equipe................................................................................................44

8. 10.5. Gerente de testes............................................................................................44
10.6. Gerente de defeitos.........................................................................................44
10.7. Arquiteto de testes..........................................................................................45
10.8. Resumo............................................................................................................45
11. Defeitos e seu gerenciamento....................................................................46
11.1. Objetivos do gerenciamento de defeitos.......................................................46
11.2. Atividades do gerenciamento de defeitos.....................................................46
11.3. Início e fim do gerenciamento de defeitos....................................................47
11.4. Classificação dos defeitos..............................................................................47
11.5. Análise dos defeitos........................................................................................49
11.6. Resumo............................................................................................................49
12. A prática de testes hoje...............................................................................50
12.1. Testes, o “mal necessário”.............................................................................50
12.2. Profissionais de testes qualificados, uma raridade......................................51
12.3. Certificações de testes no Brasil...................................................................51
12.4. Resumo............................................................................................................52
13. Métricas de teste..........................................................................................53
13.1. Onde aplicar as métricas................................................................................53
13.2. Considerações importantes...........................................................................54
13.3. Melhorando as métricas..................................................................................55
..................................................................................................................................55
13.4. Resumo............................................................................................................55
14. Ferramentas disponíveis.............................................................................56
14.1. Gerenciadores de teste...................................................................................56
14.1.1. Ferramentas Mercury...............................................................................................56
14.1.2. Ferramentas Rational...............................................................................................57
14.2. Outras ferramentas de teste...........................................................................58
14.2.1. Gerenciadores de mudanças e configuração...........................................................58
14.2.2. Ferramentas para teste e gerenciamento em sites..................................................58
14.2.3. Ferramentas auxiliares diversas...............................................................................58
14.2.4. Ferramentas abertas para testes..............................................................................58
14.3. Resumo............................................................................................................59
15. Conclusão.....................................................................................................60
16. Bibliografia....................................................................................................62
17. Glossário.......................................................................................................65

9. Índice de Imagens
Figura 1 - Fases do Projeto de Software............................................................2
Figura 2 – Custo da remoção de defeitos nas diferentes fases (por
multiplicador)......................................................................................................10
Figura 3 - Fases do Projeto x Fases de Teste.................................................11
Figura 4 – Modelo V............................................................................................12
Figura 5 - Teste caixa preta...............................................................................17
Figura 6 - Relações de Níveis e Tipos de teste...............................................33
Figura 7 - Curva S - Esforço de Teste..............................................................42
Figura 8 - Quadro Comparativo de Certificações de Testes..........................52

10. 1
1. Objetivo
Esta monografia destina-se a todos os profissionais envolvidos no ciclo de
vida de um projeto de software e, também, à alta gestão de TI, a fim de
esclarecer o que é teste, como a fase de testes se enquadra no ciclo de vida de
desenvolvimento de um sistema e qual sua importância no produto final, assim
como os riscos da má implantação da fase de testes nestes pontos.

11. 2
2. Introdução
A meta principal de todo projeto de software é, sempre, entregar ao cliente
o produto no prazo e custo acordados, com a qualidade esperada. Para tal,
necessitamos de alguns pressupostos: deve haver uma metodologia para o ciclo
de vida, e o software deve ser considerado como um projeto. Em um projeto de
software, normalmente, possuímos as seguintes fases:
Figura 1 - Fases do Projeto de Software
Iremos nos focar, aqui, somente na fase de testes, que normalmente
abrange o projeto como um todo, agindo diretamente na qualidade. E, sem uma
gestão adequada do projeto como um todo, não há que se falar em qualidade,
pois não haverá um produto a ser entregue.
Qualidade, atualmente, é a palavra da moda. E, como qualquer moda,
muitos querem utilizar sem saber exatamente como. Diversas empresas
procuram por fábricas de software com CMMI 5, mas simplesmente não estão
dispostas aos ônus de fornecer informação e arcar com toda a metodologia e
custos associados necessários.
Nesta luta insaciável pela qualidade, a fase de testes de software é um dos
maiores aliados. E, normalmente, a menos observada e mais prejudicada.
Se a fase de construção de um produto de software se atrasa no
cronograma geral do projeto, normalmente a data do “Go Live” não é afetada, e
sim a fase de testes. Muitas vezes, este desprezo pela fase de testes encontra-
se no desconhecimento do que é esta fase, e de como planejá-la
adequadamente.
Mas, afinal, o que é testar um software? Vamos ver algumas definições do
que é Teste:
- “Testar é o processo de executar um programa ou sistema com a
intenção de encontrar erros”. Glenfond Myers, The Art of Software Testing
- “Testar é qualquer atividade direcionada à avaliação de um atributo de
um programa ou sistema. Testar é a métrica da qualidade de software”,
Bill Hetzel, The Complete Guide to Software Testing
- “O processo de avaliar ou exercitar um sistema ou um componente de
sistema por meios manuais ou automatizados para verificar se satisfaz
requisitos específicos ou identificar as diferenças entre os resultados
esperados e resultados reais”, IEEE

12. 3
Se juntarmos todas essas definições, podemos entender perfeitamente o
propósito de testar um software, ao invés de procurar uma definição para esta
atividade. Desta maneira, os testes de softwares existem para:
- Medir os resultados contra os requisitos, ou seja, verificar se os
resultados estejam iguais a aquilo que é esperado pelo requisito;
- Documentar as diferenças entre os resultados reais e resultados
esperados;
- Ajudar a resolver estas diferenças fornecendo os devidos resultados e
achados no debugi
.
Secundariamente, os objetivos do teste são:
- Fornecer confiança ao sistema, através do envolvimento do usuário;
- Garantir que o sistema funcionará tanto do ponto de vista funcional
quanto de desempenho;
- Garantir que as interfaces entre os sistemas funcionem;
- Estabelecer exatamente o que o sistema faz (e não faz) para que o
usuário não receba nenhuma surpresa à época da
- Identificar áreas problemáticas onde os produtos do sistema não atendam
às especificações acordadas
- Melhorar os processos de desenvolvimento que ocasionam erros.
E, dependendo do papel exercido por uma pessoa, podemos dizer que
testar serve:
- Desenvolvedor: validar que um programa ou sistema tenha sido
desenvolvido de acordo com seus requisitos.
- Gerente de projeto: mede se o produto a ser entregue foi feito com
qualidade, se preocupando com a integração das equipes de teste e
desenvolvimento, determinando riscos, problemas e gerenciando por
métricas.
- Analista de testes: Analisar e definir a melhor estratégia para testar os
requisitos, encontrando erros significativos dentro do prazo alocado para
isto, e verificar se a correção para este erro torne o software ou sistema
conforme com os requisitos.
- Empresa ou negócio desenvolvendo o software: melhorar a qualidade
e satisfação do cliente, redução de custos relacionados a reclamações de
usuários e re-escrita do software, assim como aumento da margem de
lucro para o negócio.

13. 4
2.1. Princípios de teste
Testar demonstra a presença de defeitos: o teste pode demonstrar que
há defeitos, mas não pode assegurar que não existam defeitos. Testes reduzem
a probabilidade de que defeitos não descobertos continuem no sistema mas,
mesmo que nenhum defeito tenha sido encontrado, não é uma prova de que o
aplicativo não possui problemas.
Testes exaustivos são impossíveis: testar tudo (todas as combinações
de entradas e pré-condições) não é factível exceto em casos triviais. Ao invés de
testes exaustivos, usam-se riscos e prioridades para focar no esforço de teste.
Testes prévios: as atividades de teste devem começar o quanto antes no
ciclo de desenvolvimento de software, e deve estar focado em objetivos
definidos.
Agrupamento de defeitos: um pequeno número de módulos contém a
maioria dos defeitos descobertos durante o teste pré-produção, ou demonstrar
as maiores falhas operacionais.
Paradoxo de teste: se os mesmos testes são repetidos diversas vezes,
eventualmente este set de casos de teste não encontrará nenhum defeito novo.
Para superar este paradoxo, os casos de teste necessitam ser regularmente
revistos e revisados, e novos e diferentes testes precisam ser escritos para
exercitar diferentes partes do software ou sistema para encontrar potencialmente
mais defeitos.
Teste é contextual: o teste é feito de maneira diversa em contextos
diferentes. Por exemplo, o teste de uma funcionalidade é feito de maneira
totalmente diferente do teste de aceite do usuário.
Ilusão da falta de erros: encontrar e corrigir defeitos não adianta se o
sistema não possui usabilidade e não atende às necessidades e expectativas
dos usuários.
2.2. Níveis de Teste em uma organização
Existem também níveis de maturidade de Teste em uma organização,
criados por Boris Beizer em seu livro intitulado Software Testing Techniques,
divididos em 5 níveis, a exemplo do CMMI. São eles:
- Nível 1 - "Não há diferença entre testar e depurar. Além de servir como
suporte ao debug, testar não possui outro." Pode-se encontrar defeitos
mas não há um esforço formal para encontrá-los.
- Nível 2 - "O propósito do teste é demonstrar que o software funciona."
Esta abordagem, que começa com a premissa de que o software está
correto, pode nos cegar para descobrir defeitos. Glenford Myers escreveu
que aqueles fazendo os testes podem subconscientemente selecionar
casos de teste que não vão falhar. Assim, os casos de testes criados a
fim de encontrar defeitos escondidos, nunca existirão.

14. 5
- Nível 3 - "O propósito do teste é demonstrar que o software não
funciona." Esta abordagem assume que o software não funciona e desafia
o testador a encontrar seus defeitos. Com esta abordagem, serão
selecionados os casos de teste para avaliar minuciosamente o sistema,
seus limites, usando casos de testes extremamente bem construídos para
este fim.
- Nível 4 - "O propósito do teste não é provar nada, apenas reduzir o risco
percebido de não funcionar a um nível aceitável." Não se faz um
julgamento prévio do software, somente há a preocupação de entregá-lo
da melhor maneira possível.
- Nível 5 - "Testar não é um ato, é uma disciplina mental que resulta em um
software de baixo risco sem muito esforço de testes”. Com esta
maturidade, a equipe de testes é colocada logo no início do projeto de
software, ajudando a definir requisitos, sempre em mente a faceta do que
é testável e mensurável.
2.3. Resumo
Os graus de maturidade de uma organização e a análise destes é o que
permite identificar a qualidade para se implantar satisfatoriamente o teste.
Uma fase de testes bem planejada e bem executada garante a qualidade
do produto, assim como de futuros projetos similares. E, no mundo atual,
garantir a qualidade do produto entregue é garantir a permanência da empresa
no mercado.

15. 6
3. Histórico de testes
Infelizmente, não temos um histórico muito preciso sobre a história de
testes no Brasil. Muito do que será dito aqui corresponde à história nos Estados
Unidos.
3.1. Início de tudo: um acidente
Em 1961, um simples erro de software causou a destruição de uma
aeronave. Este simples, mas caro erro levou a Força Aérea a demandar uma
verificação independente em todas as futuras missões críticas. A metodologia de
verificação e validação evoluiu deste requisito.
3.2. Décadas de 70 e 80
Uma década depois, no início da “era dos computadores”, na década de 70
e 80, temos o início dos métodos formais e métricas utilizados até hoje.
Logicamente, o mercado de então se comportava de uma maneira
totalmente diferente. Computadores e softwares associados eram construídos
para durar (pelo menos cinco anos para os softwares e 10 anos para o
hardware). Nesta ótica, os investimentos nesta área derivavam de longas
projeções, e os compromissos feitos eram duradouros.
Normalmente um parceiro de tecnologia desta época venderia hardware,
software, suporte, educação e consultoria. Uma vez escolhida o parceiro, a
empresa estaria presa a ele até a total depreciação do hardware e software, um
processo que poderia levar 10 anos ou mais. Estes consumidores exigiam
confiabilidade e qualidade em seu produto. Testes era uma parte integrante
deste processo. Apenas alguns parceiros existiam, sempre com diplomas de
engenharia, e cada um possuía uma maneira própria de fazer as coisas.
Para a maioria das empresas nesta época, qualquer aplicativo ou sistema
operacional rodava apenas em um ambiente. Eram muito raras as situações
onde um aplicativo ou hardware deveriam interagir, quiçá trocar informações em
tempo real.
3.3. A trama se complica: década de 90
Na década de 90, os Pcs se popularizaram, e com isso surgiram os
softwares baratos para o público em geral. Durante toda a década de 90, os
computadores continuaram a se tornar mais baratos, poderosos e rápidos.
Assim, os desenvolvedores de software foram levados a explorar os

16. 7
computadores de uma maneira mais ampla, rápida e melhor. E os consumidores
foram levados a atualizar-se, apenas para se manter competitivos em seus
negócios. Ou assim se imaginava.
Os criadores de software criaram técnicas de desenvolvimento rápido de
aplicativos (RADii
) para que pudessem estar à altura do hardware e das
demandas dos consumidores nesta nova indústria, onde ser o primeiro no
mercado normalmente era a chave do sucesso. Ferramentas de
desenvolvimento tornavam “escrever programas” cada vez mais fácil. E os
diplomas menos importantes.
Diferentemente dos anos 80, onde uma nova versão de um aplicativo seria
uma versão mais forte do que já existia, nos anos 90, uma nova versão de um
aplicativo normalmente seria uma versão completamente diferente, contendo
"bugs"iii
muito mais sérios do que seu predecessor.
O cronograma agressivo de entrega deixava pouco tempo para testes nas
funcionalidades base, o que dirá testar os diversos ambientes onde o software
era esperado rodar, como computadores feitos por diferentes companhias, e
diferentes versões de sistemas operacionais. Assim, era testado pelos usuários,
com grupos de suporte aos produtos ajustando os problemas. Os custos de
atendimento ao usuário eram altíssimos então.
3.4. Parem tudo, a Web chegou
Em poucos meses, toda empresa grande de software e hardware tinha
garantida sua presença na web. O processo de conserto de bugs se tornou
muito mais eficiente porque não era mais necessário enviar as correções para
todos que haviam comprado o software; o custo de correção caiu a quase zero,
pois os usuários faziam o "download" da solução na Internet. Os sites de
atendimento ao usuário forneciam um lugar único de informação e atualizações
tanto para o usuário quanto para o atendimento a este, e o tempo necessário
para tornar uma correção disponível ao público era irrisório.
O custo de implantação destes sites de atendimento ao usuário era mínimo
e a redução de custos monstruosa. A qualidade dos produtos aumentou, não
porque novas técnicas de teste foram criadas, mas sim porque as correções
eram entregues mais rapidamente. Aliás, a preocupação com a qualidade na
entrega do produto diminuiu consideravelmente. Para que gastar com testes se
era possível consertar os defeitos depois do produto entregue?
Enquanto isso, os consumidores baseavam suas decisões de compra na
disponibilidade e propaganda dos softwares. Eles compravam o primeiro produto
que encontravam que atendesse às suas necessidades em termos de
funcionalidade, sem se preocupar com a confiabilidade dele. Normalmente não

17. 8
há nenhuma informação de confiabilidade de um software, pois não há padrões
estabelecidos.
A decisão de entregar o produto é geralmente baseada pelas datas
estabelecidas pelo mercado, e não pela atual confiabilidade do produto. Tornou-
se prática comum distribuir versões de correções de bugs apenas após poucas
semanas da versão inicial – depois que o mercado já estava conquistado.
Conseqüentemente, métricas de confiabilidade não são consideradas como
cruciais ao sucesso comercial do produto. Esta tendência se espalha no
mercado de software e hardware.
3.5. Anos 2000: caindo na real
Após a falência de muitas empresas "pontocom" e a queda do mercado em
2001 e 2002, investidores exigem lucratividade. Em contrapartida, na década de
90, os consumidores adquiriam os novos softwares, sem saber exatamente se
necessitavam desta nova versão. Mais ainda, quando a utilizavam, não era
completamente, apenas algumas poucas funcionalidades. Desta maneira, estas
aplicações cliente servidor pesadas foram substituídas por aplicações leves,
com muito menos funcionalidades, baseadas em "browser"iv
. Os consumidores
nunca sentiram falta das funcionalidades que se foram, visto que não as
utilizavam.
Desenvolvedores argumentavam, na década de 90, com sucesso, que
investir em melhores ferramentas construiria um software melhor, ao invés de
investir em um melhor processo de testes. Como a maioria das melhoras de
qualidade veio de padronização e melhoria no processo de desenvolvimento,
isto funcionou. Entretanto, as falhas reais nos produtos foram erros nas
funcionalidades, e aplicações que não rodavam bem em grandes sistemas, ou
sistemas que eram simplesmente muito caros para manter. E isto são coisas
que as ferramentas de desenvolvimento não podem identificar, mas testes sim.
3.6. Resumo
No mercado atual, a área financeira da empresa não vai permitir que um
servidor seja jogado fora até que seja totalmente depreciado. Nem aceitarão a
compra de um novo sistema operacional ou outros softwares sem uma
justificativa de custo benefício aceitável.
A partir do momento que os consumidores não querem mais comprar algo
porque é novo, as coisas começam a mudar. Quando consumidores exigem
confiabilidade ao invés de funcionalidades e custos, a balança volta a pesar em
direção à confiabilidade, e na qualidade. O valor de utilizar métodos formais e
métricas se torna a diferença entre empresas que sobrevivem e outras que não.

18. 9
E é assim que estamos hoje. Nos afastamos da “era de ouro” da Internet,
caindo na real, nos preocupando em desenvolver o melhor software possível
dentro do prazo e custo acordados.

19. 10
4. Testes e o ciclo de desenvolvimento
Testes possibilitam a evolução de um software de um estado de hipotética
utilidade a um estado de comprovada utilidade. Para se conseguir isso, devem-
se testar requisitos, desenho, código, documentação e procedimentos
operacionais. Testando-se em todo o ciclo de vide, e não apenas na fase
“designada” a testes, pode ajudar, em um mínimo, a trazer antecipadamente
problemas ã tona com maior facilidade e chance de correção.
4.1. Redução de custos
Envolver a equipe de testes antecipadamente no ciclo de vida do sistema
foca a equipe de testes em prevenir erros, ao invés de encontrá-los, além de
reduzir, e muito, os custos de um projeto. Quanto antes um erro for identificado
no ciclo de vida, menor será o custo do seu reparo.
Fase do desenvolvimento de
Software
Média relativa do custo de
remoção do defeito
Especificação dos requisitos 1
Desenho 2,5
Construção 6,5
Teste integração 16
Documentação 40
Teste integração de sistemas 40
Produção 110
Figura 2 – Custo da remoção de defeitos nas diferentes fases (por multiplicador)
Desta maneira, o teste deve começar na fase onde começa o projeto, ou
seja, onde se estabelece os objetivos do projeto também se devem estabelecer
os objetivos do teste. Depois, fundamentalmente, na fase de Elicitação de
Requisitosv
, ou seja, quando do levantamento dos requisitos junto ao cliente.

20. 11
Figura 3 - Fases do Projeto x Fases de Teste
E o que deve ser testado nesta fase? O requisito perfeito é aquele que seja
claro, correto, completo, consistente, testável, modificável e rastreável. Assim, o
tipo de teste que é feito nesta fase, é o Teste Estático, ou seja, aquele teste que
é conduzido com o exame detalhado das características de um produto, como
uma documentação, para verificar um conjunto de atributos e padrões.
O que testes busca nessas revisões antecipadas, antes da fase de testes
propriamente dita, é assegurar a testabilidade do sistema, potenciais defeitos e
ambigüidades, e um conhecimento antecipado e geral da aplicação, de maneira
a escrever casos de testes mais abrangentes.
A fase de testes começa, e é conhecida, na fase do projeto físico do
sistema, ou seja, na sua construção. Nesta fase temos os testes unitários,
sistema, integração, aceite e usabilidade, do qual falaremos mais adiante. Mas,
baseado em uma metodologia voltada à qualidade, baseada no modelo CMMivi
,
a equipe de testes está sempre envolvida, na revisão de pares, garantia de
qualidade de software, métricas, gestão de mudanças e gestão e
acompanhamento de defeitos.
Baseado em um estudo especial comissionado pelo Departamento de
Defesa e Carpers Jones (Software Product Research, 1994; Jones, 2000) foi

21. 12
estimado a efetividade da remoção do defeito para organizações em diferentes
níveis do CMMvii
:
• Nível 1: 85%
• Nível 2: 89%
• Nível 3: 91%
• Nível 4: 93%
• Nível 5: 95%
Falando em outro modelo amplamente conhecido em qualidade, temos o
“V-Modelviii
”, que é uma representação gráfica do ciclo de vida de
desenvolvimento de software. O V-Model é o modelo utilizado pelo governo
alemão para o desenvolvimento de software, definindo os resultados a serem
alcançados em um projeto e a abordagem para consegui-los. Este modelo
mostra claramente a necessidade de Teste em todas as fases, visto que pontos
de qualidade existem para todas as fases do ciclo.
Figura 4 – Modelo V
Erros encontrados antes nesse processo são, em média, pelo menos 20%
mais baratos para corrigir do que se achados após a implantação (de acordo
com figura 2). Desta maneira, há um benefício financeiro expressivo ao
monitorar e gerenciar testes para encontrar e fazer correções na oportunidade
menos custosa.

22. 13
E, da mesma maneira, apesar do maior esforço de testes ocorrer durante o
que chamamos de fase de execução, teste é uma atividade a ser desenvolvida
em paralelo com desenvolvimento, como se fosse um projeto dentro de outro
projeto.
Por mais que possa parecer uma duplicação de custos, à primeira vista, ter
uma estrutura hierárquica completa para cada fase do projeto, este custo se
paga com a redução dos defeitos, e maior qualidade do produto a ser entregue,
como visto anteriormente.
4.2. A relação custo/benefício de testes
A qualidade nunca é um acidente. Melhorar a qualidade não implica
automaticamente em levar mais tempo para os "deliverables"ix
e aumentar
custos. É possível minimizar riscos enquanto se maximiza a qualidade.
A quantidade de testes que devemos (e estamos dispostos a) fazer
depende diretamente dos riscos envolvidos. Programas ou sistemas de alto risco
requerem mais casos de teste e mais ênfase em testes. Programas com baixo
risco ou impacto limitado de falha não precisam da mesma preocupação.
No mundo atual, de softwares críticos ao negócio, não é objetivo de testes
encontrarem todos os defeitos, o que é praticamente impossível. Ao invés disso,
testes devem garantir que dentre os defeitos encontrados estão todos aqueles
que possam causar uma real interrupção nos ambientes de produção. Em outras
palavras, encontrar os defeitos que fazem a diferença.
Atingir a alta qualidade é possível e não custa muito. Como visto
anteriormente, um defeito encontrado em produção custa 100 vezes mais caro
para ser removido do que aquele encontrado na fase de requisitos.
Há um mito que diz que o ROIx
(Return over investment) não é atingido
pelas melhorias de processo e qualidade do ciclo de desenvolvimento de
software. Definitivamente, não é proibitivo alcançar melhorias significativas de
processo e cada melhoria deste processo reflete uma melhoria direta na redução
dos custos e na satisfação do cliente. A habilidade de uma empresa de competir
efetivamente e implantar mudanças é amplamente aumentada pela melhoria de
qualidade e previsibilidade do software. A satisfação do cliente traz a melhoria
da imagem e percepção da marca para a empresa, resultando em ganhos
mensuráveis e quantificáveis do ROI.

23. 14
4.3. Resumo
Testar não é uma atividade isolada, ou desordenada. Ele existe para
prevenir defeitos, muito mais do que corrigi-los, e deve existir desde o início do
projeto. Nos dias atuais, a importância de testes no ciclo de desenvolvimento de
software e sua inserção antecipada trazem muitos benefícios ao produto
desenvolvido bem como ao custo do software em si.
Nos grandes modelos usados atualmente, como CMMi e V-Model, não se
fala mais de testes como uma atividade relegada ao desprezo, mas sim a
atividade chave para que a Melhoria contínua pregada por estes modelos possa
acontecer.
E, quanto antes for inserida a equipe de testes no projeto, maior é o
benefício do ponto de vista qualitativo e de custos.
A próxima fase pelo qual o mercado passará agora não será a prevenção
de defeitos mas sim a redução deles, baseado em estatísticas de projetos
anteriores, de maneira extremante efetiva e que possibilitará, e muito, a
diminuição de custo de software.
Assim, contratar uma empresa possuidora de nível 5 de CMMi não apenas
garantirá um produto de qualidade bem como um produto mais barato, devido à
metodologia de redução de defeitos.

24. 15
5. Abordagens de testes
Antes de entrarmos nos tipos de testes propriamente dito, vamos nos ater a
uma outra visão, a abordagem de testes. Existem dois tipos de abordagens que
podem ser feitas em testes: testes estáticos e testes dinâmicos.
5.1. Testes estáticos
O teste estático é um exame detalhado das características de um produto
em relação a um esperado conjunto de atributos, experiências e padrões. Como
o produto sendo examinado é estático, e não em movimento (como a execução
de um programa, por exemplo), o seu comportamento a entradas diferentes não
pode ser avaliado.
A descoberta de defeitos ou desvios cedo em um projeto resulta em
mudanças mais baratas e menos sofríveis. E, no ciclo de desenvolvimento, o
único teste disponível durante as fases de pré-construção são os testes
estáticos.
A abordagem de teste estático faz parte dos testes de caixa branca, ou
seja, o teste tem acesso ao código (veremos este tipo de teste mais adiante).
Nesta abordagem usam-se diversos tipos de técnicas como revisão de código,
inspeção e outros.
5.1.1. Tipos de testes estáticos
Protótipo: revisar o modelo de um produto definido sem sua total
funcionalidade do produto final proposto; o protótipo é mostrado, exercitado, e
seu resultado avaliado, levando a uma melhora no design deste. Esta técnica é
usada intensamente para verificar e validar o desenho da interface do usuário e
para confirmar a usabilidade
Auto-revisão: processo do autor de um produto ler seu produto a fim de
encontrar defeitos.
Listas de checagem: série de itens comuns, ou perguntas a fim de
verificar a completeza dos passos de uma tarefa. Estas listas de checagem
também podem ser usadas para o estágio de preparação do processo de
inspeção.
Mapeio: identificação de funções da especificação e demonstração de
como esta função, direta ou indiretamente, mapeia aos requisitos.
Revisão: usadas para fornecer ao projeto controle e segurança, focado em
problemas que impactam o produto, processo de desenvolvimento e o projeto.

25. 16
As revisões lidam com as características do que está sendo construído, como
está sendo construído, e quais os recursos usados para construí-lo. As revisões
não são formais, mas são uma maneira excelente de colher feedbacks de pares
e membros da equipe.
Passo a passo: são mais formais do que revisões mas menos formais do
que inspeções. Geralmente são feitas como reuniões agendadas onde os
participantes são convidados a participar. As minutas das reuniões são
anotadas, assim como os problemas e as ações a serem tomadas resultantes.
Os problemas e ações recebem responsáveis e há acompanhamento dessas
ações. Mesmo não sendo tão formais quanto inspeções, estas reuniões são uma
alternativa viável se há problemas de tempo envolvidos.
Inspeções: são a forma mais organizada de se fazer testes estáticos e,
sendo assim, é a maneira mais efetiva e econômica para detectar defeitos
antecipadamente no ciclo de vida. O processo de inspeção é um procedimento
muito bem definido e compreensivo, incluindo planejamento, preparação,
reunião de inspeção, re-trabalho e acompanhamento. É uma revisão ordenada
com diversas pessoas de várias áreas (negócio, técnico) para fornecer visões
mais compreensivas sobre os produtos de trabalho.
5.2. Testes dinâmicos
Teste dinâmico é o processo de verificação ou validação de um produto
executando-o ou operando-o sob exame e observando seu comportamento com
diferentes entradas e ambientes. Onde um módulo é testado estaticamente
olhando para sua documentação, é executado dinamicamente para testar o
comportamento de sua lógica e sua resposta às entradas.
Alguns exemplos significativos de teste dinâmico podem ser execução de
casos de testes em um sistema funcional, simular cenários de utilização com
usuários finais reais para testar usabilidade e testes paralelos em um ambiente
de produção, entre outros.

26. 17
6. Técnicas de teste
Existem três técnicas de teste mais comuns: caixa preta, caixa branca e
encontro de erros. Técnicas de teste que examinam os interiores de um produto
usam a abordagem de caixa branca. A técnica que observa como uma unidade
sob teste se comporta apenas checando suas entradas e saídas é uma
abordagem caixa preta. A técnica de encontro de erros é onde experiência e
intuição são aplicadas para inesperados mas recorrentes erros.
6.1. Teste de caixa preta
No teste de caixa preta, os testadores possuem uma visão externa do
sistema, não requerendo conhecimento da parte interna, estrutura ou
implantação do software. Preocupam-se com “o que” é feito ao invés de “como”
é feito. Para testar este sistema, todas as combinações de entrada possíveis são
colocadas e as saídas são examinadas. Devem ser usadas tanto entradas
válidas quanto inválidas.
O processo de teste de caixa preta usualmente é feito assim:
- Requisitos ou especificações são analisados;
- Entradas válidas são escolhidas baseadas na documentação para
determinar se o sistema se comporta da maneira como deveria se
comportar;
- Resultados esperados destas entradas são definidas;
- Testes são executados;
- Resultados reais são comparados com resultados esperados;
- Chega-se à conclusão se o sistema está funcionando de acordo ou
não.
Esta técnica pode ser aplicada em todas as fases de teste: unitário,
integração, sistema e aceite. Conforme vamos passando de módulo a um
subsistema a um sistema a caixa fica maior, com entradas e saídas mais
complexas, mas a técnica continua a mesma, conforme figura abaixo.
Figura 5 - Teste caixa preta

27. 18
Da mesma forma, conforme vai aumentando o tamanho da caixa, torna-se
necessário o uso da técnica de caixa preta, já que existem muitos caminhos a
serem testados para a técnica de caixa branca, conforme veremos adiante.
Uma das desvantagens da técnica de caixa preta é o fato do testador
nunca saber quanto do sistema já foi testado. Não importa quão esperto ou
minucioso ele seja, alguns caminhos jamais serão exercitados. E, isso vai de
encontro com um dos princípios de teste, “testes exaustivos são impossíveis”.
Mas, mesmo não sendo possível testar todas as combinações existentes, a
técnica de caixa preta direciona o testador a subconjuntos de testes que são
efetivos e eficientes em encontrar defeitos. E essa é a vantagem desta técnica:
estes subconjuntos vão encontrar mais defeitos do que um mesmo número
equivalente, mas randomicamente criado. Em outras palavras, a técnica de
caixa preta ajuda a maximizar o retorno do investimento de testes.
Neste tipo de testes, são utilizadas as seguintes técnicas:
6.1.1. Teste de equivalência de classes
O teste de equivalência de classes é a técnica utilizada para diminuir o
número de casos de testes a um número gerenciável mantendo uma razoável
cobertura de testes. Assim, ao invés de se testar todas as possíveis entradas,
testa-se somente as classes equivalentes, ou seja, um conjunto de dados que
são tratados pelo sistema da mesma maneira ou espera o mesmo resultado;
apenas um dado deste conjunto já testa esta condição (se este dado encontra
um defeito, todos deste conjunto também, e vice-versa). E, lógico, sempre, deve-
se testar todas as exceções (testes negativos). Este tipo de testes é aplicável
em todas as fases de testes, desde que as entradas e saídas possam ser
divididas baseadas nos requisitos.
6.1.2. Teste de valores limites
O teste de valores limites foca-se nos valores que estão nas “pontas” dos
conjuntos, justamente porque é neste ponto onde se encontram muitos defeitos.
Desta maneira, devem-se antes identificar as classes equivalentes, depois
encontrar os valores limites de cada classe e escrever casos de teste que
testem valores um ponto menor que o limite, o limite, e um ponto maior. Como o
teste de equivalência, também pode ser aplicado em todas as fases de testes,
desde que as entradas e saídas possam ser divididas e encontrado limites
nelas.

28. 19
6.1.3. Tabela de decisão
A tabela de decisão é uma excelente ferramenta para capturar alguns tipos
de requisitos de sistema e para documentar desenho interno do sistema. São
utilizados para guardar regras de negócio complexas que devem ser
implantadas por um sistema e servem como um guia para a criação de casos de
testes.
Infelizmente, é muito complexo explicar esta técnica sem exemplos
concretos. Deve-se seguir um padrão para construir a tabela de decisão,
conforme mostrado:
Regra 1 Regra 2 … Regra p
Condições
Condição 1
Condição 2
…
Condição n
Ações
Ação 1
Ação 2
…
Ação o
Neste padrão, as condições são as condições de entrada, as ações são as
ações que devem ser tomadas pelo sistema dependendo das condições de
entrada e cada regra significa um conjunto de condições e respectivas ações.
Após completar toda a tabela com os valores, cada coluna (regras) significa
um caso de teste. Caso a condição seja um conjunto ou uma faixa de valores,
devem-se escrever casos para cada um dos valores limites (neste caso, usa-se
conjuntamente a técnica de valores limite com a tabela de decisão).
6.1.4. Teste de matriz ortogonal
O teste de matriz ortogonal baseia-se na idéia de que a maioria dos
problemas em software são causados por interações envolvendo uma ou duas
variáveis, e que a maioria dos defeitos seria descoberta se fossem executados
todas as combinações envolvendo uma ou duas variáveis. Este tipo de técnica
define um conjunto mínimo que guia os testadores a todos os defeitos
individuais ou com outra variável. O sucesso desta técnica em diversos projetos,
documentados ou não, é o maior incentivo para seu uso.
Simplificando algo que normalmente soa muito complicado, pegando
qualquer matriz ortogonal com um número x de linhas e um número y de
colunas, escolhendo-se quaisquer duas colunas (um par), cobrem-se todas as

29. 20
mais problemáticas situações, economizando muitos casos de teste, horas e
dinheiro.
Para implantar a abordagem ortogonal é interessante utilizar ferramentas
preparadas para isto, como a rdExpert, da empresa Phadke Associates
(http://www.phadkeassociates.com/). Ou, caso prefiram, Neil J.A. Sloane
mantém um grande catálogo de matrizes ortogonais como referência
(http://www.research.att.com/~njas/oadir/index.html). Em muitos casos, ao
construirmos matrizes não nos apercebemos que existem restrições a opções (e
a matriz testa todos os pares), e seria muito difícil identificá-las manualmente.
Por isso, utilizando ferramentas como a já citada rdExpert ou a AETG pode
ajudar muito nesta tarefa.
O processo para utilizar as matrizes ortogonais é:
- Identificar as variáveis;
- Determinar o número de opções de cada variável;
- Encontrar uma matriz ortogonal que possua uma coluna para cada
variável e valores dentro das colunas que correspondam às escolhas
para cada variável;
- Mapear o problema a ser testado na matriz ortogonal;
- Construir os casos de teste.
A grande promessa do teste ortogonal é que, ao criar e executar de 1 a
20% dos casos de teste, pode-se encontrar de 70 a 85% do total de defeitos. É
sempre fundamental lembrar que esta técnica pode muitas vezes deixar de fora
testes importantes que devem ser feitos. Para isso, recomenda-se sempre usar
o bom senso e a experiência prévia do testador, além das técnicas já explicadas
anteriormente.
Esta técnica também pode ser aplicada a todas as fases de teste,
requerendo apenas uma combinação de entradas, com muitos valores,
resultando em simplesmente uma quantidade absurda de casos para testar.
6.1.5. Diagramas de transição de estado
Os diagramas de transição de estado é outra excelente ferramenta para
capturar alguns tipos de requisitos de sistema e para documentar desenho
interno do sistema. Estes diagramas documentam os eventos que entram e são
processados por um sistema assim como as respostas do sistema. É uma
ferramenta perfeita para ser utilizada quando o sistema necessita lembrar-se de
algo que ocorreu antes ou quando ordens de operação válidas ou inválidas
existem.
Estes diagramas direcionam os esforços de testes identificando os estados,
eventos, ações e transições que deveriam ser testadas. Juntas, definem como

30. 21
um sistema interage com o mundo exterior, os eventos que processa e a ordem
válida e inválida destes eventos.
Este tipo de técnica não é aplicável quando o sistema não possui estados
ou não possui a necessidade de responder em tempo real a eventos de fora do
sistema.
6.2. Teste de caixa branca
No teste de caixa branca, os testadores possuem uma visão interna do
sistema. Preocupam-se com “como” é feito ao invés de “o que” é feito. Este tipo
de teste é orientado pela lógica: os testadores estão preocupados com a
execução de todos os caminhos possíveis do fluxo do programa. A abordagem
caixa branca é essencialmente um método de teste unitário e é quase sempre
feito pelo pessoal técnico.
Cada técnica do teste de Caixa Branca oferece apenas uma faceta para a
solução da complexidade geral ao problema de testar completamente todos os
aspectos do caminho lógico e seu conteúdo. Os testes de caixa branca
dependem da estrutura do programa, e assim possuem como processo:
implantação é analisada, caminhos são identificados, entradas e resultados para
estas entradas são determinadas, testes são executados, resultados
comparados e feito um reporte.
O teste de caixa branca pode ser aplicado em todos os níveis de
desenvolvimento de software: unitário, integração e sistema. Apesar do teste de
caixa branca ser visto como uma atividade de teste unitário, este tipo de visão é
uma visão muito restrita. O teste caixa branca é um teste de “caminhos”, e não
de código. Desta maneira, podemos aplicar as mesmas técnicas de teste de
caminhos entre módulos de um subsistema, subsistemas de um sistema, e ate
entre sistemas inteiros.
As desvantagens do teste de caixa branca é o escopo (a quantidade de
casos de testes a serem testados pode ser tão grande que simplesmente não
vale a pena), estes testes também podem não detectar erros simples de dados.
Além disso, o teste de caixa branca assume que o caminho sendo seguido pela
aplicação é o correto; como os testes são feitos baseados nestes caminhos, não
se pode descobrir caminhos alternativos por teste de caixa branca. A última
desvantagem cai no fato do testador ter de possuir conhecimentos de
programação, para fazer os testes necessários. A vantagem principal desse tipo
de abordagem é que o testador, nesse tipo de teste, pode ter certeza de que
todos os caminhos foram do software foram identificados e testados.
6.2.1. Teste de fluxo de controle

31. 22
Esta abordagem identifica os caminhos de execução através de um modulo
de um software e então cria e executa casos de testes para cobrir esses
caminhos. Um caminho pode ser definido como uma execução de seqüência de
instrução que começa em um ponto determinado e termina em uma saída.
Os gráficos do fluxo de controle são a base para o teste de Fluxo de
Controle. Estes gráficos documentam a estrutura de controle do módulo. Estes
módulos são convertidos em gráficos, os caminhos através dos gráficos são
analisados e os casos de testes são criados a partir desta análise.
O teste de fluxo de controle só será completo quando usado junto com o
teste do caminho básico.
6.2.2. Níveis de cobertura
Cobertura por instruções
Cobertura por instruções é uma técnica de caixa branca utilizada para
verificar que cada instrução no programa seja utilizada pelo menos uma vez. Isto
garante a cobertura lógica completa. Esta cobertura testará apenas se a
instrução foi alcançada, não testando a condição falsa, por exemplo.
Cobertura por decisão
Esta cobertura é uma melhoria em cima da cobertura por instruções onde
todos os ramos, verdadeiros ou falsos são testados. A cobertura por decisão é
alcançada quando todos os ramos foram atingidos e cada ponto de entrada foi
chamado ao menos uma vez. Mas, uma vez que uma condição seja satisfeita
não necessariamente irá testar os outros ramos da mesma instrução.
Cobertura por condição
O objetivo do teste da cobertura por condição é que todas as condições
dentro e uma instrução, e não penas uma decisão específica, sejam testadas
para garantir cobertura total. Assim, a cobertura é atingida quando cada decisão
é verdadeira pelo menos uma vez, e falsa pelo menos uma vez, e cada ponto foi
chamado pelo menos uma vez.
Cobertura por múltiplas condições
O objetivo é garantir que todas as combinações de diferentes condições
sejam testadas, podendo-se usar para isso a tabela de decisão.
Cobertura por caminho
Garantir que todas as possíveis combinações de caminhos de um fluxo
sejam chamadas pelo menos uma vez, baseado em todas as possíveis

32. 23
combinações de resultados de condições em cada decisão de todos os pontos
de entrada ate todos os pontos de saída.
6.2.3. Teste do caminho básico
Este teste utiliza uma analise da topologiaxi
do gráfico de fluxo de controle
para identificar os casos de teste. Para descobrir quantos casos de testes
devem ser criados, utiliza-se a complexidade ciclomática que é exatamente o
número mínimo de caminhos independentes, não circulares (chamados de
caminhos básicos) que podem, em uma combinação linear, gerar todos os
caminhos possíveis através do módulo.
Desta maneira, a Complexidade Ciclomática (C) é definida por pontas-
nódulos+2.
O processo do teste estruturado baseia-se nos seguintes passos: derivar o
gráfico do fluxo de controle baseado no módulo, computar a complexidade
ciclomática do gráfico, selecionar um conjunto de C caminhos básicos, criar um
caso de teste para cada caminho básico e executar estes testes.
O conjunto de casos de teste encontrado garante a cobertura tanto de
instruções quanto de ramos.
6.3. Encontro de erros
Baseando-se em experiências passadas, dados de teste podem ser criados
para antecipar aqueles erros que ocorrem com maior freqüência. Usando a
experiência e o conhecimento da aplicação, são testados dados inválidos que
representam os erros comuns que um usuário pode cometer para verificar como
o sistema lidará com esses erros.
Uma abordagem estruturada para esta técnica é enumerar uma lista de
possíveis erros e criar testes para atacá-los. Estas listas de defeitos e falhas
podem ser construídas baseadas em experiência, defeitos disponíveis e dados
falhos, e do conhecimento comum do por que o software falha.
6.4. Resumo

33. 24
Em todos os softwares a serem testados sempre devemos utilizar a
abordagem de teste caixa branca e a caixa preta, em diferentes momentos do
processo de testes e em diferentes tipos de testes, conforme veremos adiante.
Agora, qual técnica deve ser utilizada entre as diversas apresentadas aqui
dependerá do escopo do projeto, o modelo de desenvolvimento utilizado, os
riscos, além do prazo e orçamento, conforme explicado anteriormente.
Logicamente, conforme a experiência no gerenciamento da fase de testes
aumenta, tomar esta decisão torna-se muito mais fácil.

34. 25
7. Níveis de testes
O teste avança por diversos níveis físicos da mesma maneira que o ciclo de
vida de desenvolvimento de software. Cada nível completo representa um marco
no plano do projeto e cada estágio representa um nível de integração física e
qualidade. Estes estágios de integração são conhecidos como níveis de teste.
Produtos de trabalho de software, tais como cenários de negócio ou casos
de uso, especificações de requisitos, documentos de desenho e código são
muitas vezes utilizados como base do teste em um ou mais níveis de teste. Em
qualquer modelo de ciclo de vida, existem diversas características do bom teste:
- Para cada atividade de desenvolvimento há uma atividade de teste;
- Cada nível de teste possui objetivos específicos a estes níveis;
- A análise e criação dos testes para um determinado nível devem
começar durante a atividade de desenvolvimento correspondente;
- Os testadores devem ser envolvidos na revisão da documentação
assim que os rascunhos estejam disponíveis no ciclo de
desenvolvimento.
É importante salientar que estes níveis de teste não são fixos, podendo ser
combinados ou reorganizados dependendo da natureza do projeto ou da
arquitetura do sistema.
Para cada um dos níveis de teste que veremos a seguir, podem ser
identificados seus objetivos genéricos, a base do teste, o objeto do teste,
defeitos típicos e falhas a serem encontradas, requisitos do aparato de teste e
ferramentas, além de abordagens específicas e responsabilidades.
Os níveis de teste mais utilizados são Teste Unitário, Teste Funcional,
Teste de Integração, Teste de Integração de Sistemas, Teste de Aceite e Teste
de Regressão.
7.1. Teste unitário
O teste unitário é o teste inicial do código novo e modificado de um módulo.
Verifica as especificações do programa contra a lógica interna do programa ou
módulo e valida esta lógica.
Os objetivos deste teste são testar a função de um programa ou unidade de
código, testar a lógica interna, verificar o desenho interno, testar a cobertura de
caminhos e condições, testar condições de exceções e manejo de erros.

35. 26
Este teste ocorre após as fases de construção desta unidade e possui
como produtos de entrada o desenho interno da aplicação, além do Plano
Mestre de Testes e Plano Unitário de Testes e, como produto de saída, o
Relatório do teste Unitário. Quem deve participar deste teste é o desenvolvedor,
usando como método técnicas de caixa branca e técnicas de cobertura de
testes. As ferramentas ideais para este nível de teste são debug, reestruturação,
analisadores de código e ferramentas de cobertura de caminhos/instruções.
Para que este nível de teste possa ser feito seu executor deve ser treinado na
metodologia de testes e no uso efetivo das ferramentas descritas anteriormente.
Os programas e módulos devem ser exercitados o teste de mesa antes de
serem integrados e testados. Esta revisão deve ser feita previamente pelo
programador e depois de uma maneira mais formal através de inspeções.
Os passos para preparação do teste unitário são:
- Determinar a integração do desenvolvimento e abordagem de teste
(cima pra baixo, baixo pra cima ou uma combinação dos dois);
- Determinar as técnicas de teste caixa branca a serem utilizadas e as
sub-técnicas particulares que melhor se aplicam;
- Criar os conjuntos de condições (um ou mais níveis dependendo do
detalhe).
A melhor abordagem no teste unitário é criar os casos de teste ao mesmo
tempo em que o código é desenvolvido. As vantagens desta abordagem são
criar casos de teste mais objetivamente, não sendo influenciado pelo estilo do
código e não deixar de escrever algum caso.
7.2. Teste de integração ou modular
Os testes de integração verificam a execução correta de componentes da
aplicação de não requerem que esta interaja com outras aplicações. A
comunicação dentre os módulos dentro dos subsistemas é testada em um
ambiente controlado e isolado.
Os objetivos deste teste são verificar tecnicamente a correta interação entre
os módulos e subsistemas. O teste de integração deve ser feito a fim de verificar
os requisitos funcionais do sistema.
Este teste ocorre após as fases de teste unitário dos módulos e possui
como produtos de entrada o desenho interno e externo da aplicação, além do
Plano Mestre de Testes e Plano de Testes de Integração e, como produto de
saída, o Relatório do teste de Integração. Quem deve participar deste teste é o
desenvolvedor e o testador, usando como método técnicas de caixa branca e
caixa preta, além de gerenciamento de problemas e configuração. As

36. 27
ferramentas ideais para este nível de teste são debug, reestruturação, e
analisadores de código. Para que este nível de teste possa ser feito seu
executor deve ser treinado na metodologia de testes e no uso efetivo das
ferramentas descritas anteriormente.
7.3. Teste de sistemas
Os testes de sistemas verificam a correta execução de todos os
componentes da aplicação incluindo interfaces com outras aplicações. Tanto os
testes funcionais quanto estruturais são feitos para verificar que o sistema esteja
funcionando.
Os objetivos deste teste são verificar que os componentes do sistema
exerçam funções de controle, executar testes entre os sistemas e demonstrar
que o sistema funcione tanto funcional quanto operacionalmente como
especificado. Durante o teste de sistemas, a estabilidade funcional e estrutural
do sistema será demonstrada assim como os requisitos não funcionais, como
desempenho e confiabilidade.
Este teste ocorre após as fases de teste de integração e possui como
produtos de entrada os requisitos detalhados e o desenho externo da aplicação,
além do Plano Mestre de Testes e Plano de Testes de Sistemas e, como
produto de saída, o Relatório do teste de Sistemas. Quem deve participar deste
teste é o desenvolvedor, o testador e os usuários, usando como método técnicas
de gerenciamento de problemas e configuração.
7.4. Teste de integração de sistemas
Os testes de integração de sistemas verificam a integração de todas as
aplicações, incluindo interfaces internas e externas à organização com seus
componentes físicos, lógicos e de infra-estrutura em um ambiente similar ao de
produção.
Os objetivos deste teste são testar a existência de produtos e aplicações
que são necessárias para funcionarem juntas em um ambiente similar ao de
produção (físico, lógico e de rede), garantir que o sistema funcione junto a todos
os componentes do ambiente como um sistema total e garantir que as versões
do sistema possam ser implantadas no ambiente atual.
Este teste ocorre após as fases de sistema e possui como produtos de
entrada a estratégia de teste, além do Plano Mestre de Testes e Plano de
Testes de Integração de Sistemas e, como produto de saída, o Relatório do
teste de Integração de sistemas. Quem deve participar deste teste é o testador
de sistemas, usando como método técnicas de caixa branca e caixa preta, além

37. 28
de gerenciamento de problemas e configuração. Para que este nível de teste
possa ser feito seu executor deve ser treinado na metodologia de testes.
7.5. Teste de aceite
Os testes de aceite verificam que o sistema esteja de acordo com os
requisitos do usuário conforme foram definidos. Este teste simula o ambiente do
usuário e enfatiza segurança, documentação e testes de regressão e serve para
demonstrar que o sistema funciona como esperado pelo cliente e usuário final
para que estes o aceitem.
Os objetivos deste teste são verificar que o sistema faça exatamente o que
os requisitos pedem para ele fazer, nem mais nem menos.
Este teste ocorre após as fases de sistema e possui como produtos de
entrada as necessidades do negócio e requisitos detalhados, além do Plano
Mestre de Testes e Plano de Testes de Aceite e, como produto de saída, o
Relatório do teste de Aceite. Quem deve participar deste teste são os usuários,
usando como método técnicas de caixa preta, além de gerenciamento de
problemas e configuração. Para que este nível de teste possa ser feito seu
executor deve ser treinado na metodologia de testes, conhecimento do produto e
da estratégia de lançamento do negócio.
7.6. Testes de operabilidade
Os testes de operabilidade verificam que o sistema possa operar em um
sistema de operação. Estes testes são feitos depois ou concorrentemente com
os testes de aceite.
Os objetivos deste teste são garantir que o produto possa operar no
ambiente de produção, garantir que o produto atenda a um nível aceitável de
serviço conforme estabelecido no SLAxii
(Service Level Agreement), garantir que
o produto opere como definido nos padrões operacionais e garantir que o
produto possa ser recuperado ou reiniciado de acordo com os padrões.
Este teste ocorre após as o fim dos testes e possui como produtos de
entrada o Plano de Testes de Aceite, o aceite do usuário, Plano de teste
operacional, além dos padrões operacionais e, como produto de saída, o
Relatório do teste operacional. Quem deve participar deste teste é o pessoal de
operações, usando como método gerenciamento de problemas e configuração.
Para que este nível de teste possa ser feito devem ser usadas ferramentas de
desempenho.

38. 29
7.7. Resumo
É imprescindível sabermos qual o nível de teste que estamos utilizando, já
que o foco muda totalmente. Quando estamos fazendo um teste de integração,
modular, o foco é de que este módulo funcione, não se importando com a
interoperabilidade com os outros módulos. Desta maneira, cada nível de teste
muitas vezes tem que criar casos de testes novos, já que o foco a ser testado
muda totalmente.
Mostramos neste capítulo os níveis básicos de teste, que são Teste
Unitário, Teste de Integração, Teste de Sistemas, Teste de Integração de
Sistemas e Teste de Aceite. Estes níveis não são fixos, podendo ser acoplados
a outros dependendo da complexidade do projeto. Muitas vezes, o teste de
Integração de Sistemas é feito junto com o teste de Sistemas.

39. 30
8. Tipos de testes
Já vimos os níveis de teste, ou seja, qual é o foco dado a cada nível de
teste. Agora, para que esta idéia fique mais fácil de compreender, alguns tipos
de testes que podem ser usados em cada nível de testes.
É sempre fundamental lembrarmos que nada, em teste, é fixo. Sempre os
tipos de teste devem adaptar-se ao produto que se está testando e o tipo de
projeto onde este produto está inserido.
8.1. Teste de requisitos
Teste de requisitos envolve a verificação e validação destes através de
testes estáticos e dinâmicos. A validação dos requisitos é alcançada pelo teste
de aceite do usuário. A princípio, o teste de requisitos faz somente a verificação.
Os objetivos deste teste são verificar que os requisitos encontrados
atendam às necessidades de negócio do usuário final antes que o desenho da
aplicação comece e avaliar os requisitos no tocante à sua testabilidade.
Este teste ocorre logo após a fase de elicitação de requisitos, tendo como
produto de entrada os requisitos detalhados e saída os requisitos verificados.
Quem deve participar deste teste são os usuários e desenvolvedores, usando
como método JADxiii
, técnicas de teste estático, listas de checagem, mapeio, e
revisões de documentos. As ferramentas ideais para este nível de teste são
ferramentas CASE. Para que este nível de teste possa ser feito seu executor
deve ser treinado na aplicação.
8.2. Teste de desenho
O teste de desenho envolve a verificação e validação do desenho do
sistema através de testes estáticos e dinâmicos. A validação do desenho
externo é feito durante o Teste de Aceite do Usuário e a validação do desenho
interno é coberta durante o teste Unitário, Integração e Sistema. A princípio, o
teste de desenho faz somente a verificação do desenho externo e interno.
Os objetivos deste teste são verificar que o desenho do sistema aos
requisitos de negócio e técnicos acordados antes que a construção do sistema
comece e identificar requisitos faltantes.
Este teste ocorre após as fases de desenho interno e externo estarem
completas e possui como produtos de entrada o desenho interno e externo da
aplicação e, como produto de saída, os desenhos internos e externos
verificados. Quem deve participar deste teste são os usuários e

40. 31
desenvolvedores, usando como método JAD, técnicas de teste estático, listas de
checagem, protótipos, mapeio e revisões de documentos. As ferramentas ideais
para este nível de teste são ferramentas CASE e de protótipo. Para que este
nível de teste possa ser feito seu executor deve ser treinado na aplicação e
possuir um treinamento técnico.
8.3. Teste de regressão
O teste de regressão verifica que nenhuma mudança indesejável tenha
sido introduzida ao sistema como resultado de mudanças em outras partes do
sistema. Este teste sempre deve ser feito antes de ser iniciado o teste de uma
nova versão, e como último teste, para garantir que nenhum dos consertos dos
desvios encontrados durantes os testes da versão corrente tenham criado outros
desvios.
Para executar um teste de regressão, o sistema deve ser executado pelo
menos duas vezes no mesmo cenário de teste, ou seja, a primeira na fase
correspondente, e a segunda no teste de regressão, e os resultados são
comparados. Os resultados desta comparação são usados para documentar e
analisar as diferenças.
8.4. Teste de usabilidade
O teste de usabilidade garante que o produto final é usável, de uma
maneira prática, dia-a-dia. Este tipo de teste busca a simplicidade e o fato de ser
amigável ao usuário. Este tipo de teste normalmente é feito como parte do teste
funcional nos níveis de teste de Sistemas e teste de Aceite.
Os objetivos deste teste são garantir que o sistema seja fácil de operar de
um ponto de vista do usuário e do provedor de serviços, e que as
funcionalidades sigam um caminho intuitivo.
8.5. Teste de backup e recuperação
Recuperação é a habilidade de um sistema reinicializar após uma falha;
este processo normalmente envolve voltar a um ponto no ciclo de
processamento onde a integridade do sistema é garantida e refazer as
transações deste ponto em diante. A natureza da aplicação, o volume de
transações, o desenho interno da aplicação para lidar com o processo de
reinício, nível das pessoas envolvidas, ferramentas e documentação, tudo afeta
o processo de recuperação.

41. 32
O teste de backup e recuperação deve ser feito como parte do teste de
Sistemas e verificado durante o teste de Desempenho sempre que a
continuidade do processo seja um requisito crítico para a aplicação. Riscos de
falha e perdas potenciais devido à inabilidade da aplicação de se recuperar
ditarão a extensão do teste requerido.
8.6. Teste de desempenho
Teste de desempenho é feito para verificar que o sistema atenda o nível
desejado de desempenho em um ambiente de produção. O que deve ser
considerado aqui é o tempo de resposta, tempo de saída, problemas técnicos de
desenho, e assim por diante. O teste de desempenho pode ser feito em um
ambiente de produção, em um ambiente simulado ou um protótipo.
Na fase de desenho os critérios de desempenho devem ser
estabelecidos. A mensuração do desempenho deve começar assim que
produtos executáveis (não necessariamente sem defeitos) sejam produzidos.
8.7. Teste de segurança
Segurança de um sistema é necessária para garantir a proteção da
informação confidencial dentro de um sistema e outros sistemas afetados,
protegendo-os de perda, corrupção ou mau uso dos dados. A quantidade de
testes necessários dependerá da avaliação dos riscos de uma falha na
segurança. Os testes devem focar-se e limitar-se àquelas funcionalidades
desenvolvidas como parte do sistema, mas podem incluir funções de segurança
previamente implantadas mas necessárias para testar completamente o sistema.
O teste de segurança pode começar a qualquer tempo dentro do teste de
sistemas, continuar no teste de aceite e ser terminados no teste de
operabilidade.
8.8. Teste de stress / volume
O teste de stress pode ser definido como processar um grande número
de transações no sistema dentro de um determinado período de tempo e é feito
para medir as características de desempenho do sistema sob condições de pico
de uso.
Fatores de stress podem ser aplicados a diferentes aspectos do sistema
como transações de entrada, linhas de relatório, tabelas internas, comunicações,
capacidade de processamento do computador, saídas, espaço em disco, etc.

42. 33
O teste de stress não deve começar até as funções do sistema estarem
totalmente testadas e estáveis. A necessidade é detectada na fase de desenho
e deve começar assim que produtos estáveis sejam entregues.
8.9. Resumo
Comentamos aqui apenas os tipos de testes mais comuns, e não todos
existentes. Existem muitos outros tipos de teste e cada projeto pode precisar de
um tipo de teste diferente. Mas, como se pode perceber, cada tipo de teste se
relaciona com uma fase de testes. Para se ter uma idéia melhor, vamos ilustrar a
relação dos tipos de teste com os níveis de testes em uma tabela, como
veremos a seguir:
Tipos Níveis
Unitário Integração Sistemas Integração
de
Sistemas
Aceite Operabilidade
Função/Requisitos x x x x x
Instalação x
Interface x X x X
Regressão x x x X x
Usabilidade x x
Backup e
Recuperação
x x X X
Desempenho x X X
Segurança x x X X
Stress/Volume x X
Figura 6 - Relações de Níveis e Tipos de teste

43. 34
9. Processo de testes
A parte mais visível do Processo de testes é a execução, mas isto não é
somente o que ocorre no Processo de testes. Para ser mais eficiente e efetivo,
os planos de testes devem conter tempo no planejamento dos testes, desenho
dos casos de testes, preparação para execução e avaliação do status.
O processo de testes básico, assim, deve conter estes passos:
• Planejamento e controle;
• Análise e desenho;
• Implantação e execução;
• Avaliar critério de saída e relatórios;
• Atividades de fechamento da fase de testes.
Mesmo que logicamente ordenadas, algumas vezes estas fases podem se
sobrepor e ocorrer simultaneamente. Não podemos nos esquecer também que
Testes é um processo iterativo, ou seja, estes passos ocorrerão dentro de cada
nível de teste visto anteriormente.
A primeira camada de planos e testes é conhecida como Plano Mestre de
Testes. As camadas subseqüentes são tratadas como refinamentos adicionais
ao Plano Mestre e podem ser chamados de Planos Detalhados de testes.
9.1. Planejamento e controle
Planejamento é a atividade de verificar a missão do teste, definir os
objetivos do teste e especificar as atividades de testes necessárias para atingir à
missão e aos objetivos. Planejar por si só já é um processo completo. Desta
maneira, planejar passo a passo garante um plano construído sistematicamente
e completamente.
Controle é uma atividade contínua de comparar o progresso atual com o
esperado no plano. Para controlar o teste, este deve ser monitorado durante
todo o processo.
Planejamento de testes possui como maiores atividades:
• Determinar escopo e riscos, além de identificar os objetivos do
teste;
• Determinar a abordagem do teste (técnicas, itens a serem testados,
cobertura, identificação e envolvimento dos times);

44. 35
• Determinar os recursos necessários para o teste (por exemplo,
pessoas, ambiente, computadores);
• Implantar a estratégia de testes;
• Agendar tarefas de análise e desenho de testes;
• Agendar implantação do teste, execução e avaliação;
• Determinar o critério de saída do teste.
Controle dos testes possui como maiores atividades:
• Mensurar e analisar os resultados;
• Monitorar e documentar o progresso, cobertura do teste e critério de
saída;
• Iniciar ações corretivas, quando necessário;
• Tomar decisões.
9.1.1. Escopo do teste
O objetivo geral em testar é diminuir os riscos inerentes a sistemas. Assim,
áreas devem ser identificadas para serem focados os testes que atendem a
determinados riscos/problemas, e devem ser adereçados pela estratégia de
teste.
É necessário focar o teste porque não existem recursos ilimitados
(pessoas, tempo, etc.) e não é possível testar-se todo o sistema exaustivamente.
Com este foco, podemos denominar o escopo do teste como os atributos de um
sistema que devem ser testados para garantir que os requisitos técnicos e de
negócios sejam atendidos.
9.1.2. Análise de risco
Medir o risco antes de testar ajuda a identificar aplicações de alto risco, e a
aumentar o esforço de testes, e também ajuda a focar em áreas de maior risco
onde o teste deve ser mais detalhado. Geralmente, quanto maior o custo
potencial de um erro, maior o esforço de testes designado para evitar estes
erros.
As áreas de risco de maior influência em um projeto são: tamanho do
projeto, experiência com a tecnologia e estrutura do projeto.
9.1.3. Objetivos do teste
São aqueles que devem ser atingidos para garantir que os objetivos do
sistema serão atingidos e que este se demonstrará aceitável ao cliente.

45. 36
Os objetivos do teste devem focar-se nas grandes atividades de testes que
devem ser realizadas para finalizar com sucesso o teste do sistema. O propósito
de se definir os objetivos de testes é definir critérios de avaliação de quando o
teste estará completo. Os objetivos do teste baseiam-se em requisitos de
negócio, requisitos técnicos e riscos.
9.1.4. Estratégia do teste
É o conjunto de atividades que serão desenvolvidas para atingir os
objetivos do teste. Por exemplo, se o escopo do teste é o desempenho, a
estratégia do teste será o teste de stress/volume e teste de desempenho feitos
no nível do teste de Integração antes que todo o sistema passe pelo teste de
sistemas.
Para formar a estratégia, devem ser levados em conta os riscos, restrições
e exposições, se existentes. Os planos estratégicos direcionarão as futuras
necessidades de recursos e tempo.
9.1.5. Gerenciamento de problemas e controle de mudanças
Gerenciamento de problemas é o processo pelo qual os problemas são
controlados e rastreados dentro de um projeto de desenvolvimento. É muito
importante que a mesma ferramenta de gerenciamento de problemas seja usada
no projeto inteiro e esta é uma ferramenta chave para os testadores.
Controle de mudanças ou gerenciamento de mudanças controla todas as
mudanças feitas no projeto, como requisitos, etc.
9.2. Análise e desenho do teste
Análise e desenho do teste é a fase onde os objetivos gerais do teste são
transformados em condições tangíveis de teste e desenho de teste.
As maiores atividades na análise e desenho do teste são:
• Rever a base de testes (requisitos, arquitetura, desenho);
• Identificar condições ou requisitos de teste e dados necessários de
teste baseado na análise dos itens do teste, especificações,
comportamento ou estrutura;
• Criar os casos de teste;
• Avaliar a testabilidade dos requisitos e do sistema;

46. 37
• Desenhar a preparação de ambiente necessária e identificar
quaisquer necessidades de infra-estrutura e ferramentas.
9.2.1. Revisão da base de testes
Antes da criação dos casos de teste em si, devemos identificar qual a base
de testes, ou seja, quais são os requisitos, como é a arquitetura e desenho dos
sistemas a serem testados. É imprescindível que a primeira atividade do
testador, ao entrar em contato com o sistema pela primeira vez, seja ler toda a
documentação disponível, começando pelo plano mestre de testes.
Desta maneira, temos como atividades:
• Identificar a documentação do sistema existente;
• Compreender qual o nível do teste a ser feito;
• Compreender o critério de entrada e saída desta fase de testes;
• Examinar o modelo de dados e diagrama de contexto da aplicação;
• Obter a visão e compreensão geral do sistema.
9.2.2. Identificação das condições e requisitos de teste
Após a compreensão do sistema a ser testado, devem-se identificar quais
serão as condições e requisitos que serão testados nesta fase. Por exemplo, a
criação de um caso de teste para um sistema Mainframe difere da criação de um
caso de teste para um sistema baseado em web. Da mesma maneira,
dependendo do nível do teste, o caso de teste é completamente diferente, além
do requisito que deve ser seguido. Caso estejamos testando o nível de teste
unitário, devemos nos ater aos requisitos de componente; caso o nível seja um
teste de integração, devemos testar os requisitos de sistema, e assim por diante.
Da mesma maneira devemos nos preocupar com as condições do teste,
quais serão os cenários e abrangência do teste a ser feito. Nesta fase, devemos
nos preocupar com a criticidade do sistema assim como a relação
custo/benefício. Como já dito anteriormente, um sistema médico deve ser 100%
testado por ser um sistema de alta criticidade.
9.2.3. Criação dos casos de teste
A criação dos casos de teste deve focar-se nas técnicas de teste,
ferramentas, estratégias de criação e integração além das características
básicas do sistema a ser testado.
Assim, após a compreensão do universo onde o sistema se enquadra, da
identificação dos requisitos a serem testadas e as condições, devemos
transformar estes requisitos em casos de teste.

47. 38
Para tal tarefa, usamos as técnicas de caixa preta e caixa branca vistas
anteriormente. Ao nos preocuparmos em transformar requisitos em casos de
testes, precisamos considerar se os testes serão feitos em processos batch, em
telas web, “client server” e considerarmos também o exercício dos testes válidos
e inválidos. O tipo de documentação também deve ser levado em consideração
(extrair um caso de teste de um requisito é diferente de extrair um caso de teste
de um caso de uso). Outro ponto fundamental a ser considerado é que os casos
de teste são criados para serem reutilizados (regressão).
Para construir um caso de teste devemos:
• Compreender o requisito;
• Determinar a abordagem a ser usada (caixa preta ou caixa
branca);
• Desenvolver as condições de teste a serem usadas;
• Desenvolver o cabeçalho do caso de teste;
• Criar os passos do teste;
• Definir os resultados esperados;
• Desenvolver os procedimentos e dados (pré-requisitos e pré-
condições para que este teste possa ocorrer, dados necessários,
tipo de login, etc.).
Para transformar um caso de uso em um caso de teste podemos:
• Logicamente agrupar os casos de uso. Este agrupamento
normalmente é baseado em uma funcionalidade ou seqüência de
funcionalidades;
• Determinar as estratégias e técnicas de teste que serão aplicadas
aos casos de uso e identificar entradas válidas e condições para os
testes. Exemplos de técnicas e abordagens: técnicas “basis-path”,
cobertura condicional de qualquer condição, técnicas de teste em
loop e métodos de classe de equivalência;
• Criar testes para entradas e condições inválidas e inesperadas;
• Verificar que todos os casos de usos tenham casos de teste
associados.
9.2.4. Automação: quando usar
Uma consideração sempre importante na criação dos casos de teste é
quando utilizar a automação dos casos de teste. Atualmente, muito se fala em
automação dos casos de teste, nos seus benefícios e pontos positivos. Mas até
que ponto isto é apenas um modismo e não uma necessidade?

48. 39
Ao ser considerada a automação dos casos de teste devemos considerar
um tempo maior para a criação do script do teste (que normalmente é
programado), o expertise da equipe de testes na ferramenta de automação e em
programação, e a real necessidade de automação.
Quando estamos lidando com uma aplicação GUI (Graphic User Interface)
altamente volátil, o tempo de construção dos scripts do caso de teste não
justifica a automação, visto que o tempo de vida desta aplicação e do script
criado é muito pequeno. Agora, se estamos falando de um conjunto de casos de
teste de regressão, para uma aplicação estável, que é executado semanalmente
antes de um novo release o investimento na criação dos scripts para automação
possui retorno total.
Ao mesmo tempo, existem alguns tipos de teste que obrigatoriamente
devem ser automatizados, como os testes de carga e stress. É praticamente
impossível, do ponto de vista financeiro, contratar 300 testadores para executar
o mesmo tipo de teste simultaneamente. Nestes casos, a automação é
essencial.
O processo decisório da automação de um caso de teste deve possuir as
seguintes perguntas:
1. Automatizar este caso de teste e executá-lo apenas uma vez custa
mais do que executá-lo manualmente apenas uma vez. Quanto
mais?
2. Um teste automatizado possui uma linha do tempo finita, durante o
qual deve recuperar este custo adicional. Este teste provavelmente
deixará de ser válido mais cedo ou mais tarde? Quais são os
eventos responsáveis por diminuir seu tempo de vida?
3. Durante seu tempo de vida, qual a probabilidade deste caso de teste
encontrar novos defeitos (além daqueles encontrados a primeira vez
que foi executado)? Quanto o custo desta incerteza justifica o custo
da automação?
Como visto, automatizar não é sempre indicado. Devemos sempre levar em
consideração a aplicação em si, sua volatilidade, expertise da equipe e
custo/benefício da automação para somente então, decidir se deve haver
automação e quais são os testes que devem ser automatizados.
9.2.5. Avaliar a testabilidade dos requisitos e do sistema
Em um mundo ideal, esta avaliação deveria ser feita na fase de elicitação
de requisitos pela equipe de testes já participante do processo. Infelizmente,
muitas vezes a equipe de testes é envolvida somente na fase específica destes.
Quando isto ocorre, a equipe de testes deve verificar se os requisitos

49. 40
apresentados são testáveis, ou seja, se são claros, quantitativos, objetivos e não
são ambíguos e/ou ambivalentes.
Um exemplo de um requisito não testável seria um que diz: “O sistema
deve possuir um tempo de resposta adequado”. Adequado é subjetivo, e muitas
vezes o que é adequado a uma pessoa não é adequado à outra. O requisito
ideal neste caso seria: “O sistema deve possuir um tempo de resposta de no
máximo 3 segundos”. Este requisito é quantitativo, objetivo e, desta maneira,
testável.
9.2.6. Desenhar a preparação de ambiente e necessidades de infra-
estrutura
Após a criação dos casos de teste, a equipe de testes possui a visão geral
de quais as necessidades de infra-estrutura e quais os dados que o sistema
deve possuir para que os testes possam ocorrer.
É neste exato momento que a equipe de testes deve fazer um relatório com
suas necessidades de infra-estrutura e dados e fazer uma reunião onde devem
ser verificados se estes pontos já estão em ordem para que a execução dos
testes comece sem empecilhos. Nesta reunião devem participar o gerente de
testes, o gerente do projeto, assim como o responsável pela arquitetura e pelo
ambiente. Todos reunidos devem decidir se o ambiente está pronto, se todo o
código foi compilado, se todos os casos de teste estão criados e revistos, e se
todos os dados necessários ao teste estão presentes.
Caso obtenha-se uma resposta afirmativa para todos estes pontos, é
acordado por todos que a execução dos testes pode começar.
9.3. Execução dos testes
A execução dos testes é a fase onde todos os casos de testes criados
devem ser executados, os defeitos relatados, arrumados e retestados para
garantir que foram consertados com sucesso.
As maiores atividades desta fase são:
• Executar os casos de teste manuais ou automatizados, caso seja o
planejado;
• Relatar o resultado da execução do teste gravando as versões do sistema
em teste, ferramentas de teste e dados;
• Comparar os resultados reais com os resultados esperados;

50. 41
• Reportar as discrepâncias como incidentes e analisá-las de maneira a
encontrar sua causa (gerenciamento de defeitos);
• Repetir as atividades de teste para cada discrepância (re-execução do
teste para confirmar se o incidente foi corrigido).
9.4. Avaliação do critério de saída e relatórios
Avaliar o critério de saída é a fase onde a execução dos testes é avaliada
de acordo com os objetivos definidos ao teste. Por exemplo, um critério de saída
seria 100% dos casos de teste executados, todos os defeitos com severidade 1
e 2 arrumados e de severidade 3 e 4 adereçados (mesmo que não arrumados,
que tenham sido definidos que serão arrumados em uma próxima versão).
A fase de avaliação do critério de saída possui as seguintes atividades:
• Verificar os resultados dos testes em relação ao critério de saída
especificado no plano de testes;
• Avaliar se mais testes são necessários ou se o critério de saída
deveria ser modificado;
• Escrever um relatório resumo da execução dos testes aos
stakeholders.
9.5. Atividades de encerramento dos testes
A fase de encerramento dos testes ocorre após o término da execução e
serve para apresentar os resultados do teste, se o critério de saída foi atingido
com sucesso, além de uma reunião de lições aprendidas.
A reunião de lições aprendidas serve para toda a equipe de testes se
pronunciarem sobre fatos que ocorreram positivos e deveriam ser repetidos em
novas versões, fatos que ocorreram que atrasaram ou prejudicaram o teste,
enfim, todos os fatos relevantes à fase de testes são avaliados para melhoria
contínua da fase de testes em novas versões e novos projetos.
As atividades do encerramento dos testes possuem as seguintes
atividades:
• Verificar quais entregáveis planejados foram entregues, o
encerramento dos relatórios dos incidentes ou a abertura de pedidos
de mudanças àqueles que continuam abertos, além da
documentação do aceite do sistema;
• Finalizar e arquivar o testwarexiv
, ambiente de testes e sua infra-
estrutura para reuso posterior;
• Entrega do testware para a organização de manutenção;

51. 42
• Análise das lições aprendidas para futuras versões e projetos
visando a melhoria da maturidade da equipe de testes.
9.6. Resumo
Como visto neste capítulo, o processo de testes é um projeto em si dentro
de outro projeto. Por este motivo, deve ser cuidadosamente planejado,
analisado, desenvolvido e construído.
Desta maneira, o esforço da equipe de testes começa junto com o projeto
em si, com uma equipe menor, e este esforço vai crescendo conforme o
desenvolvimento do software até obter sua atividade máxima na execução,
diminuindo depois disso, conforme gráfico a seguir:
Curva 'S'
0
50
100
150
200
250
300
350
400
Tempo
CasosdeTeste
Figura 7 - Curva S - Esforço de Teste

52. 43
10. Papéis e profissões existentes em testes
Cada dia que passa os testes tornam-se mais importantes no mercado de
trabalho. E, como a qualidade tornou-se fator fundamental, sem o qual uma
empresa não alcança os níveis mais altos de CMM, também aumentou muito a
importância de profissionais de testes experientes.
Por esta razão, a importância da divulgação dos papéis, profissões e da
carreira de testes dentro de uma empresa torna-se fundamental. As empresas
devem deixar de colocar apenas profissionais juniores em testes e, quando
amadurecem profissionalmente, os direcionarem a área de desenvolvimento e
encarar a área de testes como algo sério e profissional, indicando que há sim
uma carreira de sucesso em testes.
10.1. Testador
O testador desempenha o papel mais simples entre os papéis na equipe de
testes. Ele é responsável por executar os casos de testes que já foram criados,
relatando os incidentes.
Normalmente são usados profissionais mais juniores para este papel. Se
bem treinados e guiados, eles podem continuar na carreira de testes, como
Analista de Testes. Caso seu perfil seja mais técnico, ele pode ser um Analista
de Testes técnico como, por exemplo, um especialista em automação de testes
ou um especialista em testes de carga e desempenho.
10.2. Analista de testes - negócios
O Analista de Testes focado em Negócios desempenha o papel de criar os
casos de testes baseado nos requisitos, extrapolando cenários e fazendo
estimativas para quantidade de casos de testes e tempo de criação. Este
profissional possui uma grande visão analítica e é capaz de compreender o
negócio e o ambiente onde o sistema está inserido.
Normalmente o Analista de Testes focado em Negócios trabalha nos níveis
de Testes de Integração, Testes de Sistemas e Testes de Integração de
Sistemas.
Com o tempo e experiência, o Analista de Testes focado em Negócios pode
desempenhar o papel de Líder de Equipe, coordenando a equipe de testes e
atuando como o braço direito do gerente de testes.

53. 44
10.3. Analista de testes - técnico
O Analista de Testes com foco técnico é um profissional de TI que
desempenha um importante papel na equipe de testes. Como ele possui um
grande conhecimento de programação, ele é um profissional perfeito para criar
os casos de teste automatizados, além de atuar como especialistas nos testes
de carga e desempenho.
Normalmente, este profissional também possui um vasto conhecimento nas
ferramentas específicas de teste para fazer sua automação e os testes de
carga/stress/desempenho.
10.4. Líder de equipe
O Líder de Equipe desempenha o papel de coordenação dos Analistas de
Testes e Testadores, atuando como o braço direito do Gerente de Testes.
Possui uma forte visão gerencial, bom relacionamento em equipe e foco nos
resultados.
Este profissional é responsável pelo reporte diário da criação e execução
dos testes, criação dos gráficos como Curva S e administração das ferramentas
de testes, como criação dos scripts e cabeçalhos de testes.
10.5. Gerente de testes
O Gerente de Testes é um gerente de projeto que atua gerenciando todas
as atividades e custos da fase de testes. Este profissional possui a visão
gerencial e profundos conhecimentos nas técnicas de gerenciamento de
projetos, como PMIxv
. Atua diretamente com o Gerente do Projeto do Sistema e
assegura a correta execução da fase de Testes e de todas as atividades
inerentes a esta.
É responsável por todos os relatórios gerencias, pela criação do Plano
Mestre de Testes, definição do critério de entrada e saída das fases de teste.
10.6. Gerente de defeitos
O Gerente de Defeitos é um profissional que atua como a ponte entre o
time de testes e o time de desenvolvimento gerenciando as incidências
encontradas e priorizando sua correção.

54. 45
Possui como principal característica a comunicação e gerenciamento de
conflitos, garantindo uma tranqüila execução e correção de defeitos. Também é
responsável por gerenciar reuniões diárias de status da correção de defeitos,
criação de relatórios gerenciais sobre quantidade, qualidade e causa de defeitos
e por aplicar técnicas de redução de defeitos garantindo a melhoria contínua do
ciclo de desenvolvimento da aplicação.
10.7. Arquiteto de testes
O Arquiteto de Testes é um profissional técnico de TI responsável por
desenhar e criar a infra-estrutura do ambiente de testes e de toda a solução de
testes, como um todo.
Este profissional atua como um verdadeiro arquiteto da solução e do
ambiente, definindo quais ferramentas, servidores devem ser utilizados, além
dos dados, backup e gerenciamento de versões.
10.8. Resumo
Neste capítulo listamos somente os papéis mais comuns e importantes da
equipe de testes. Obviamente, existem muitos outros papéis e com certeza com
o aprofundamento das técnicas e ferramentas de testes muitas outras profissões
serão criadas na carreira de testes.
O mais importante é que os executivos de TI percebam que a carreira de
testes existe, não é modismo e deve ser exercida em todos os projetos de
desenvolvimento de sistemas. E, com o tempo, a devida importância a este
profissional seja reconhecida, e que cursos superiores e de pós-graduação
específicos na área de testes sejam criados.

55. 46
11. Defeitos e seu gerenciamento
Uma das definições e propósito de testes é “encontrar defeitos”. Por esta
razão, entender a necessidade do gerenciamento de defeitos é essencial ao
entendimento do que são os testes. Mas, antes de compreender o que é o
gerenciamento dos defeitos, devemos entender o que é um defeito.
Desta maneira, podemos definir que um Defeito é qualquer erro, falha ou
não conformidade na aplicação ou em qualquer documentação relacionada a
esta (requisitos, casos de uso, etc.).
O gerenciamento de defeitos é um conjunto de processos para gerenciar a
rastreabilidade e conserto dos defeitos encontrados durante o teste e
desempenhar a análise causal deste. As atividades principais são coletar,
armazenar, reportar, analisar e garantir a integridade dos dados dos defeitos.
11.1. Objetivos do gerenciamento de defeitos
Entendendo o que é o gerenciamento de defeitos, compreender seus
objetivos torna-se muito simples. Os objetivos são:
• Facilitar a resolução dos defeitos assegurando a consistência dos
dados fornecidos e assegurar que o defeito foi entendido e recriado
por parte da equipe de desenvolvedores;
• Facilitar a comunicação entre desenvolvedores e testadores;
• Melhorar tanto o produto final como o processo de desenvolvimento
e gerenciamento de defeitos;
• Manter um histórico de defeitos levantados que serão usados para
criação de relatórios e que poderão ser consultados em versões
futuras.
11.2. Atividades do gerenciamento de defeitos
Para atingir os objetivos descritos acima, o gerente de defeitos deve:
• Identificar e registrar os defeitos levantados: o candidato a defeito
deve ser identificado como válido ou não;
• Identificar e definir responsabilidades: verificar a integridade das
informações fornecidas (se são suficientes ou não para recriar o
defeito), definir o responsável pela sua resolução e se possível
definir um prazo;