Alexandre Bartie-Garantia de Qualidade de Software PDF

© 2002, Elsevier Editora Ltda.
Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998.

Nenhuma parte deste livro, sem autorização prévia por escrito da editora,
poderá ser reproduzida ou transmitida sejam quais forem os meios empregados:
eletrônicos, mecânicos, fotográficos, gravação ou quaisquer outros.
Editoração Eletrônica
RioTexto
Copidesque
Cláudia Gomes de Amorim
Revisão Gráfica
Andréa Campos Bivar
Projeto Gráfico
Elsevier Editora Ltda.
Conhecimento sem Fronteiras
Rua Sete de Setembro, 111 – 16º andar
20050-006 – Centro – Rio de Janeiro – RJ – Brasil
Rua Quintana, 753 – 8º andar

04569-011 – Brooklin – São Paulo – SP – Brasil
Serviço de Atendimento ao Cliente

0800-0265340
[email protected]
ISBN 13: 978-85-352-1124-5

ISBN 10: 85-352-1124-1
Nota: Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem ocorrer erros de digitação, im-
pressão ou dúvida conceitual. Em qualquer das hipóteses, solicitamos a comunicação ao nosso Serviço de Atendimento
ao Cliente, para que possamos esclarecer ou encaminhar a questão.
Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou perdas a pessoas ou
bens, originados do uso desta publicação.
CIP-Brasil. Catalogação-na-fonte.
Sindicato Nacional dos Editores de Livros, RJ
B295p
Bartié, Alexandre
Garantia da qualidade de software : adquirindo maturidade
organizacional / Alexandre Bartié. – Rio de Janeiro :
Elsevier, 2002 – 13a Reimpressão.
ISBN 85-352-1124-1
1. Software – Testes. I. Título
02-1253. CDD — 005.14

CDU — 004.415.5
Dedico este livro às pessoas mais importantes de minha vida:
Minha esposa Ivone,

por compartilhar comigo todo seu amor, desejos, sonhos e alegrias...
Meus pais, Carlos e Dalva,

por estarem presentes e me apoiarem nos momentos mais difíceis...
Minha afilhada Caroliny,

por me lembrar de que a felicidade está ao alcance de nossas mãos...
O Autor
Alexandre Bartié é pós-graduado em Capacitação Gerencial pela FEA-USP e

em Gestão Empresarial pelo Instituto Trevisan. É bacharel em Administra-
ção de Empresas pela Fundação Santo André.
Há 13 anos trabalha no gerenciamento de processos voltados à qualidade
e engenharia de software, tendo atuado em grandes empresas, como
TecBan, Caixa Econômica Federal, Fininvest, BBA, BNP, Interclínicas,
Johnson & Johnson, Itautec e Gessy Lever.
Seus últimos trabalhos estão voltados à modelagem e implantação de
processos de fábrica de software e testes baseados nas mais conceituadas me-
todologias do mercado, como RUP, CMM, PMI, UML, OOP, tecnologia dot-
Net e utilização de ferramentas da família Rational e Compuware.
O autor pode ser encontrado no seguinte endereço eletrônico:

E-mail: [email protected]
Prefácio
Com o passar dos anos, estamos verificando um aumento da influência

da tecnologia nas mais diversas áreas da sociedade. Isso, como todos sabe-
mos, é um processo aparentemente irreversível. O nível de dependência de
vários setores da sociedade com relação aos sistemas de informação está em
constante crescimento e em alguns casos chega a ser uma necessidade.
Assim, uma estruturação do setor de Tecnologia da Informação com o obje-
tivo de promover o aumento da qualidade e confiabilidade de seus produtos
não só se tornou um diferencial competitivo, mas também pré-requisito
para sua existência.
Temos observado que uma miríade de novas metodologias, ferramentas
de produtividade e soluções vêm surgindo ao longo dos últimos anos visan-
do auxiliar os profissionais da área de TI na consolidação de um processo
eficiente que garanta a qualidade de seus produtos. Esse processo de organi-
zação encontra paralelo na história do setor industrial, no qual, em meados
do século XVIII, se empregava um processo produtivo artesanal e primitivo,
que foi, ao longo de dois séculos, evoluindo até culminar nas fábricas total-
mente robotizadas que conhecemos.
Seguindo esses mesmos passos, a área de Engenharia de Software chega
ao início do século XXI com um enorme desafio pela frente: o de consolidar
um processo que assegure total qualidade a seus produtos e serviços, acom-
panhando a velocidade das mudanças tecnológicas atuais, as milhares de so-
luções disponíveis no mercado e a divergência de interesses das empresas
envolvidas na área.
Diante desse cenário, verificamos esforços de vários profissionais em
todo o mundo para superar esse desafio. O livro que está em suas mãos é
GARANTIA DA QUALIDADE DE SOFTWARE
mais uma nobre iniciativa nesse sentido, provando que é possível alcançar o
sucesso nessa área. Este é, além de uma coletânea das melhores práticas da
Área de Qualidade de Software apresentadas de forma estruturada e de fácil
compreensão, um guia para sua implementação que aborda com amplitude
diferentes aspectos que permeiam o assunto, como ferramentas de produti-
vidade e gerenciamento de ambientes, tornando-se, dessa forma, leitura
obrigatória para o profissional de TI. É uma mescla entre a visão acadêmica e
a realidade empresarial, demonstrando a viabilidade e a aplicação dessas
práticas no dia-a-dia da organização. Sabemos que o território a percorrer é
inóspito, porém não tão desconhecido como no passado. O mapa para se
atingir o sucesso está diante de você.
Consultor de Qualidade e Engenharia de Software

Introdução
Totalmente alinhado com as mais modernas metodologias existen-

tes no mercado (RUP – Rational Unified Process; CMM – Capability Matu-
rity Model, Swebok – Software Engineering Body of Knowledge e PMI – Pro-
ject Management Institute), este livro coloca você diante dos conceitos mais
avançados sobre como aplicar um Processo de Garantia da Qualidade de
Software em sua empresa.
Com uma abordagem simplificada e de fácil entendimento, o livro possi-
bilita aos leitores assimilar gradualmente os aspectos mais relevantes envol-
vidos na implantação de um Processo de Garantia da Qualidade de Software.
Estabelece uma visão corporativa de qualidade de software e prepara a orga-
nização ao desafio de incorporar esses conceitos em seu dia-a-dia.
Combinando visão acadêmica com realidade empresarial, o livro apre-
senta um modelo metodológico viável tanto para as organizações que nunca
iniciaram um SPI (Software Process Improvement), quanto às organizações
que buscam atingir os níveis CMM 2 e 3. A busca pela viabilidade na aplica-
ção das melhores práticas voltadas à garantia da qualidade de software torna
este livro peça-chave para uma verdadeira revolução em sua organização.
O livro apresenta os seguintes tópicos:
Introdução à Qualidade de Software
Processo de Garantia da Qualidade de Software
Garantindo a Qualidade do Processo (Testes de Verificação)
Garantindo a Qualidade do Produto (Testes de Validação)
Gerenciamento do Testware
Estruturas da Documentação
Métricas da Qualidade de Software
Aplicações Reais
Parte I • Introdução à Qualidade de Software

Esta parte apresenta ao leitor o desafio de implantação de um processo de
Garantia da Qualidade de Software. Demonstra todas as argumentações ne-
cessárias para sensibilizar empresários, diretores, gerentes, desenvolvedo-
res e clientes sobre a importância de um processo “confiável” para a produ-
ção de softwares que atendam às reais necessidades de negócios. Exibe in-
formações, análises e conclusões referentes à importância estratégica de se
buscar melhores índices de produtividade e assertividade dos trabalhos. De-
fine o real objetivo dos testes e estabelece a atitude “zero-defeito” na organi-
zação. Demonstra como os erros estão distribuídos nas diversas etapas do
desenvolvimento e os custos relacionados à falta de qualidade do processo.
Parte II • Processo de Garantia de Qualidade de Software

Nesta parte é apresentado o modelo conceitual de Garantia da Qualidade de
Software, no qual são enfocadas as principais características desse processo.
O objetivo é apresentar uma visão clara da dimensão e escopo do modelo e
estabelecer critérios que auxiliem na decisão de implantar gradativamente
as várias etapas do processo. Percorrendo temas como priorização dos traba-
lhos, atuação em sistemas legados e em desenvolvimento e resgate do co-
nhecimento de negócios inseridos nos aplicativos, o leitor é apresentado a
diversos cenários organizacionais nas quais são apresentadas soluções que
reduzem os riscos de implantação desse processo.
Parte III • Garantia da Qualidade do Processo

Esta parte apresenta o conceito de testes de verificação que deverão ser
aplicados em todo o ciclo de desenvolvimento do software e garantir a qua-
lidade de cada etapa do processo. O leitor é apresentado a um processo sis-
temático de avaliação da qualidade em cada etapa do processo, asseguran-
do que cada planejamento, análise e decisão seja documentada e avaliada
adequadamente por grupos de revisão e acompanhamento. São apresenta-
dos um conjunto de métodos e técnicas que viabilizam e auxiliam a estru-
turação desses trabalhos.
Introdução
Parte IV • Garantia da Qualidade do Produto

Nesta parte é apresentado o conceito de testes de validação (testes de soft-
ware) que deverão ser aplicados nos diversos componentes tecnológicos ge-
rados durante o processo de engenharia de software e garantir a qualidade da
solução tecnológica como um todo. São demonstrados métodos e técnicas
que estruturam e viabilizam um processo que garanta uma evolução confiá-
vel do produto tecnológico, assegurando que tanto as novas quanto as anti-
gas funcionalidades estão em conformidade com os requisitos definidos.
São definidas três etapas evolutivas do teste – os testes unitários (que garan-
tem a qualidade da unidade de software), os testes integrados (que garantem
a qualidade das integrações entre as unidades) e os testes de sistema (que ga-
rantem a qualidade da solução como um todo).
Parte V • Gerenciamento do Testware

Nesta parte o autor apresenta o conceito de gerenciamento do “testware”
que estabelece uma gestão equivalente ao que acontece ao software. Identifi-
ca diversos aspectos que são extremamente relevantes ao processo de quali-
dade de software, como gerenciamento de versões (dos planos de testes,
controladores e massas de testes), reutilização dos testes, estratégias para re-
dução de custos, aumento da produtividade e aumento da eficiência na de-
tecção dos problemas, gerenciamento dos testes em diversos ambientes (de-
senvolvimento, testes/homologação e produção), definição de perfis de pro-
fissionais, metodologias e ferramentas.
Parte VI • Estruturas da Documentação

Nesta parte o autor ressalta a importância da documentação dentro de um
processo de qualidade de software. A formalização e registro do planejamen-
to e a execução dos trabalhos fazem com que toda a organização tenha aces-
so a como estão planejadas as atividades de qualidade e quais foram os resul-
tados obtidos através desse processo. Apresenta uma estrutura de documen-
tos que facilita o gerenciamento e controle das informações referentes ao
planejamento e execução das atividades de qualidade.
Parte VII • Métricas da Qualidade de Software

Nesta parte o autor apresenta a importância de uma organização empregar
indicadores para o suporte à tomada de decisões e concentrar os esforços
nos pontos mais críticos do processo. É apresentado um modelo de indica-
dores que mensuram tanto o nível de qualidade do processo quanto o nível
de qualidade do produto. Em relação ao produto, são apresentados diversos
indicadores de cobertura dos testes, informando o nível de segurança garan-
tido pelas atividades de qualidade de software. Em relação ao processo, são
apresentados indicadores que permitem monitorar a eficiência do processo
de desenvolvimento de software, exibindo análises de distribuição de defei-
tos (por fornecedor, impacto, categoria e componente) e o nível de eficiên-
cia do processo de detecção de erros. Também são apresentadas técnicas que
auxiliam a análise das informações obtidas.
Parte VIII • Aplicações Reais

Nesta parte o autor demonstra algumas situações práticas que permitem me-
lhor aplicabilidade dos conceitos apresentados nos capítulos anteriores.
Aborda a problemática em relação à aplicação dos processos de qualidade
em sistemas legados e softwares que estão em desenvolvimento. Apresenta
diversos tipos de sistemas e suas respectivas abordagens para a prática de
testes de software, construindo controladores para aplicar os testes unitári-
os e a utilização de simuladores na substituição de dispositivos físicos e de
outros sistemas, permitindo maximizar as possibilidades de automação dos
testes.
PARTE I
Introdução à
Qualidade de Software
“Se tivesse seis horas para derrubar uma

árvore, eu passaria as primeiras quatro
horas afiando o machado.”
ABRAHAM LINCOLN
PARTE II
Processo de Garantia de
“Os homens prudentes sabem tirar proveito

de todas as suas ações, mesmo daquelas a
que são obrigados pela necessidade.”
MAQUIAVEL
PARTE III
Garantindo a
Qualidade do Processo
“O planejamento não diz respeito a decisões

futuras, mas às implicações futuras de
decisões presentes.”
PETER DRUCKER
PARTE IV
Garantindo a Qualidade
do Produto
“O insucesso é apenas uma oportunidade

para recomeçar com mais inteligência.”
HENRY FORD
PARTE V
Gerenciamento
do Testware
“Somos o que repetidamente fazemos.

A excelência, portanto, não é um feito,
mas um hábito.”
ARISTÓTELES
PARTE VI
Estruturas
da Documentação
“Falta de tempo é desculpa daqueles que

perdem tempo por falta de métodos.”
ALBERT EINSTEIN
PARTE VII
Métricas
de Qualidade
do Software
“Toda manhã, na África, um leão acorda.

Ele sabe que deverá correr mais rápido
do que a gazela, ou morrerá de fome.
Quando o sol surge no horizonte,
não importa se você é o leão ou a gazela,
é melhor você começar a correr!”
DITADO POPULAR ITALIANO
PARTE VIII
Aplicações Reais
“Existe o risco que você não pode

jamais correr e existe o risco que
você não pode deixar de correr.”
PETER DRUCKER
CAPÍTULO 1
A Busca pela
Qualidade
Nos primórdios do desenvolvimento de software, a atividade de teste

era encarada como a simples tarefa de navegar pelo código e corrigir proble-
mas já conhecidos. Tais tarefas eram realizadas pelos próprios desenvolve-
dores, não existindo recursos dedicados a essa atividade. Dessa forma, os
testes eram somente realizados tardiamente, quando o produto já estava
pronto ou quase. Apesar de essa situação estar associada a uma má prática de
desenvolvimento de software, ela ainda continua presente em muitas orga-
nizações.
Em 1957, o conceito Teste de Software conseguiu ampliar seus valores e
se tornou um processo de detecção de erros de software, mas testar ainda era
encarado como uma atividade que ocorria no final do processo de desenvol-
vimento.
No início da década de 1970, o processo de desenvolvimento de software
passou a ter uma abordagem mais profunda com a engenharia de software
sendo adotada como modelo para as universidades e organizações, porém,
havia pouco consenso sobre o que viria a ser teste. Somente em 1972 é que
haveria a primeira conferência formal sobre testes na Universidade da Caro-
lina do Norte.
Foi Myers, em 1979, quem produziu um dos primeiros trabalhos mais
completos e profundos sobre um processo de teste. Nesse trabalho, Myers já
definia testes como um “processo de trabalho com a intenção de encontrar
erros”. Sua premissa era a de que se o objetivo do teste fosse apenas provar a
boa funcionalidade de um aplicativo, seriam encontrados poucos defeitos,

uma vez que toda a energia do processo de testes seria direcionada apenas na
comprovação desse fato. Porém, se o objetivo for identificar erros, um maior
número de problemas será encontrado, uma vez que os profissionais de qua-
lidade buscarão vários cenários para avaliar o comportamento do software.
Essa premissa provocou uma revolução na forma de abordar o problema,
porém os testes continuavam a ser executados tardiamente.
No início dos anos 1980, surgiram os primeiros conceitos de qualidade de
software. Nessa abordagem, desenvolvedores e testadores trabalhavam juntos
desde o início do processo de desenvolvimento. Cada fase tinha sua atividade
de conferência, de forma a garantir que a etapa estava completa e bem com-
preendida. Muitas organizações foram formadas e muitos dos padrões que
utilizamos hoje nasceram nessa época, como os padrões americanos forma-
dos pelo IEEE (Institute of Eletrical and Electronics Engineers) e ANSI (Ame-
rican National Stantards Institute) e os internacionais como ISO (Internatio-
nal Stantards Organization). No entanto, foi o modelo CMM (Capability Ma-
turity Model), elaborado pelo Software Engineering Institute, que ganhou
maior dimensão e importância para as organizações de software, tornando-se
um modelo de avaliação mais reconhecido internacionalmente.
Somente nos anos 1990 é que ferramentas de teste começaram a ser pro-
duzidas. Determinados testes que não eram possíveis de serem executados
agora poderiam ser feitos através de ferramentas desenhadas para determi-
nados objetivos. As ferramentas trariam alta produtividade e qualidade no
processo de teste. Hoje, entendemos que a aquisição de ferramentas é vital
ao sucesso e viabilização de um trabalho desse porte – a implantação de um
processo de garantia da qualidade de software.
1.1. Cenário Atual do Desenvolvimento de Software

O que estamos percebendo é que, de forma rápida e constante, as organiza-
ções estão aumentando sua dependência tecnológica e isso significa que
suas operações internas estão sendo conduzidas e direcionadas por um con-
junto cada vez maior de sistemas informatizados.
Trata-se de uma tendência natural. As organizações estão buscando efi-
ciência para conseguir sobreviver em um ambiente cada vez mais hostil – o de
um mercado cada vez mais competitivo. As empresas estão buscando a tecno-
logia para reduzir custos e ampliar sua forma de atuação. Estão sofisticando
seus sistemas para tomar decisões cada vez mais complexas, com a intenção
A Busca pela Qualidade
de ganhar eficiência e controle. Tudo isso pode ser observado através de diver-
sos indicadores econômicos, como volume de negócios feitos pela indústria
de software e hardware, proporção de horas de profissionais diretamente liga-
dos à tecnologia por total de horas de profissionais, entre outros.
Nesse cenário todas as variáveis envolvidas no processo de desenvolvi-
mento de software têm um nível crescente de complexidade. Com isso, os
riscos de mau funcionamento aumentam proporcionalmente à complexida-
de desse ambiente, tornando-se mais difícil produzir softwares com um “ní-
vel de qualidade” desejado.
Tabela 1.1
Evolução do processo de qualidade e de testes de software
Evolução das Organizações Desenvolvedoras de Software
Características 1960 1980 2000
Tamanho do Software Pequeno Médio Muito

Grande
Complexidade do Software Baixa Média Alta
Tamanho da Equipe de Pequeno Médio Grande
Desenvolvimento
Padrões e Metodologias de Interno Moderado Sofisticado
Desenvolvimento
Padrões e Metodologias de Qualidade Interno Emergente Sofisticado

e Testes
Organizações de Qualidade e Testes Bem Poucas Algumas Muitas
Reconhecimento da Importância da Pequeno Algum Significante
Qualidade
Tamanho da Equipe de Qualidade e Pequeno Pequeno Grande
Testes
Apesar do enorme avanço do desenvolvimento de software nos últimos 40

anos, muitas empresas estão presas a antigos paradigmas, o que impede seu
amadurecimento no processo de desenvolvimento. Elas não percebem que seus
ambientes estão cada vez mais complexos, o que exige posturas cada vez mais
difíceis. Não percebem que implantar um processo de garantia da qualidade
de software não é uma opção a ser estudada, mas parte de uma estratégia de
sobrevivência em um mercado cada vez mais exigente e competitivo.
1.2. A Realidade dos Projetos de Software

Apesar de todas as organizações concordarem em apontar a tecnologia da
informação como um dos aspectos mais estratégicos para se viabilizar o
aprimoramento e a inovação de seus produtos e serviços, o que perma-
nentemente vemos é um festival de amadorismo e ineficiência ao nos de-
pararmos com o processo de desenvolvimento de um software ou mesmo
uma necessidade de mudanças para adaptação às novas necessidades do
mercado.
As indústrias de software estão despreparadas para atender às rápidas
necessidades dos mercados simplesmente porque não investiram no aperfe-
içoamento de seus processos internos. O que estamos afirmando aqui é que
a maioria das empresas que fornecem softwares a sua organização são “ama-
doras”, ou seja, desconhecem completamente um processo de engenharia
de software. Traduzindo: não existe qualquer garantia de que a solução tec-
nológica contratada será entregue dentro do prazo e a custos negociados; na
verdade, existe um alto risco de esse projeto se perder no meio do caminho e
ser considerado mais um “mico” organizacional.
Podemos transformar essas afirmações em números. Estudos america-
nos apontam uma triste realidade para os projetos de desenvolvimento de
software, o que demonstra quão imaturas estão as indústrias de software. Os
estudos apontam para a seguinte realidade:
Mais de 30% dos projetos são cancelados antes de serem finalizados.

Mais de 70% dos projetos falham nas entregas das funcionalidades es-
peradas.
Os custos extrapolam em mais de 180% os valores originalmente pre-
vistos.
Os prazos excedem em mais de 200% os cronogramas originais.
Devemos considerar que o mercado americano é muito mais exigente e

melhor preparado do que o nacional. Devemos considerar que os profissio-
nais americanos recebem uma carga de treinamento muito maior do que a de
nossos profissionais, os investimentos em metodologias e aquisições de fer-
ramentas são práticas comuns em todas as empresas americanas, as equipes
são maiores e a presença de auditores e consultores especializados é fre-
qüente no processo de desenvolvimento de projetos críticos e com novas ca-
racterísticas tecnológicas. Também levo em consideração o lado mais objeti-
A Busca pela Qualidade
vo e formal das empresas e profissionais americanos, que possuem obsessão

no planejamento e cumprimento de metas.
Mesmo sem um número para a realidade brasileira, acredito que estamos
em uma situação delicada. Cada vez mais as organizações estão consideran-
do a possibilidade de contratação de empresas “estrangeiras” para desenvol-
ver projetos de tecnologia de software, ou seja, estamos perdendo espaço
para empresas internacionais que investiram no aperfeiçoamento de seus
processos de desenvolvimento de software (SPI – Software Process Impro-
vement).
A globalização está chegando no Brasil não somente nos chamados “pa-
cotes prontos”, como grandes ERPs (Enterprise Resource Planning) ou
CRMs (Customer Relationship Management), mas agora para empresas que
fornecem o desenvolvimento da aplicação sob medida. As barreiras da lín-
gua inglesa já deixaram de ser obstáculo para as empresas e as notações
como UML (Unified Modeling Language) permitem a troca de informações
de projeto com maior nível de precisão, portanto, muitos mercados como a
Índia (destaque-se no mercado mundial pelo nível de competência que suas
empresas de softwares alcançaram) tornam-se cada vez mais atraentes para
muitas empresas nacionais.
CAPÍTULO 2
Adquirindo Maturidade
Organizacional
Um dos objetivos de se implantar um processo de qualidade de software é

estabelecer um processo que garanta e gerencie o nível de qualidade do pro-
duto e do processo de desenvolvimento. As empresas já entenderam que fa-
bricar softwares “não-adequados”, além de prejudicar a imagem da organi-
zação, aumenta significativamente os custos totais de desenvolvimento. Isso
consome a rentabilidade dos projetos de software, além de ampliar os riscos
de insucesso dos projetos existentes.
Na verdade, softwares “não adequados” são sintomas da falta de controle
do processo de desenvolvimento, e as grandes indústrias de software já perce-
beram isso. A cada ano mais informações, técnicas, metodologias, ferramen-
tas e empresas especializam-se em assuntos cada vez mais voltados a como apri-
morar o processo de engenharia de software – trata-se do desafio deste livro.
Um dos mais importantes trabalhos de avaliação da maturidade organi-
zacional de uma empresa de software foi produzido pelo Software Enginee-
ring Institute (SEI), um centro de desenvolvimento e pesquisa patrocinada
pelo Departamento de Defesa dos Estados Unidos e filiado à Universidade
Carnegie Mellon. Sua missão foi produzir um trabalho que possibilitasse às
organizações aperfeiçoar a qualidade final de seus produtos finais, empre-
gando o “estado da arte” no desenvolvimento de software.
O resultado desse trabalho foi o modelo Capability Maturity Model
(CMM), que tem como foco o processo de software na proposta de melhoria
Adquirindo Maturidade Organizacional
contínua, trazendo disciplina e controle no desenvolvimento e manutenção

do software. Essas seriam as chaves para aperfeiçoar a qualidade do desen-
volvimento de produtos de software.
2.1. O Modelo CMM

O Capability Maturity Model (CMM) definido pelo Software Engineering
Institute (SEI) descreve uma estrutura de trabalho que possui todos os ele-
mentos necessários para tornar um processo de desenvolvimento de softwa-
re mais eficiente e controlado. O CMM baseia-se em um modelo evolutivo
de maturidade, no qual as organizações partem de uma total falta de controle
e gerenciamento dos processos (imaturidade organizacional) para gradati-
vamente adquirir novas competências, incrementando seu nível de eficiên-
cia e maturidade em relação aos diversos processos críticos envolvidos em
um desenvolvimento de software.
O modelo de processo CMM, baseia-se em cinco níveis de maturidade
organizacional. Cada nível representa um estágio de maturidade dentro do
processo de desenvolvimento de software. Cada organização tem seu nível
individual de maturidade, refletindo seu grau de controle sobre o processo
como um todo.
Nenhuma empresa consegue sair do nível 1 e chegar ao nível 3 sem antes
passar pelo nível 2. Cada nível é um pré-requisito para o outro e cada organi-
NÍVEL 5: FOCO NO APERFEIÇOAMENTO

OTIMIZADO
OTIMIZADO DO PROCESSO
NÍVEL 4: PROCESSO MEDIDO E

MENSURÁVEL
GERENCIADO CONTROLADO
NÍVEL 3: PROCESSO CARACTERIZADO E

PADRONIZADO
DEFINIDO BEM ENTENDIDO
NÍVEL 2: TAREFAS “MESTRAS” PODEM SER

CULTURAL
REPETITIVO REPETIDAS CONTINUAMENTE
NÍVEL 1: ANÁRQUICO PROCESSO IMPREVISÍVEL E

INICIAL POUCO CONTROLADO
Figura 2.1 Possíveis níveis de maturidade previstos no modelo CMM

zação consegue enxergar somente o que sua maturidade permite. Apesar

disso, as organizações podem usar de maneira vantajosa processos descritos
em níveis de maturidade superiores aos que se encontram.
Mudar de nível não é uma atividade simples; requer uma ruptura nos pa-
drões culturais da organização. Quebrar velhos hábitos e rever processos de
trabalho exige muito treinamento, envolvimento e dedicação, além de con-
sumir tempo e dinheiro, ou seja, é um processo de muito suor e trabalho.
Mais de 85% das organizações ainda está no nível 1, ou seja, está produ-
zindo software de forma desordenada e sem controles. À medida que o tem-
po vai passando, se essas empresas não evoluírem em sua forma de pensar e
agir, estarão condenadas a desaparecer. Para não parecer que o desafio de
atingir o nível 5 é impossível, algumas poucas empresas atingiram esse pata-
mar organizacional. Parece que dar os primeiros passos é a tarefa mais com-
plexa a ser realizada.
2.2. Áreas-chave do Processo (KPAs)

As áreas-chave do processo constituem a primeira divisão sistemática den-
tro dos níveis de maturidade de uma organização. Esses grupos de ativida-
des, quando executadas em conjunto, satisfazem um conjunto de metas re-
levantes para a melhoria da capacitação do processo. O CMM considera cada
área-chave um processo particular.
Os níveis de maturidade descrevem os problemas mais predominantes
daquele nível. Uma organização migra de um nível a outro sempre que con-
segue operacionalizar todas as áreas-chave específicas de um nível.
2.2.1. CMM-Nível 2
No nível de maturidade definido como Repetitível, as políticas de gerencia-
mento do software e os procedimentos detalhados para sua implementação
estão estabilizados. O planejamento e o gerenciamento dos novos projetos
são baseados na experiência adquirida em projetos similares anteriormente
executados. Um dos objetivos a serem alcançados no CMM-Nível 2 é tornar
corporativos todos os processos de gerenciamento de software, o que permi-
tirá à organização repetir sistematicamente as melhores práticas internas es-
tabelecidas pelas várias experiências adquiridas em projetos anteriores. Um
efetivo processo de gerenciamento de software deve ser praticado, docu-
mentado, garantido, treinado, medido e constantemente melhorado.
Tabela 2.1
Distribuição das áreas-chave pelos níveis de maturidade
Nível Processo Processo Processo de

CMM Gerencial Organizacional Engenharia
1 -x-x-x- -x-x-x- -x-x-x-

2 – Supervisão e Rastreamento -x-x-x- -x-x-x-
do Projeto de Software
– Garantia de Qualidade
de Software
– Gerência de Subcontratação
de Software
– Gerência de Configuração
de Software
– Gerência de Requisitos
– Planejamento do Projeto
de Software
3 – Coordenação entre Grupos – Definição – Engenharia
– Gerência de Software do Processo de Produto
Integrada da Organização de Software
– Foco no Processo – Revisões
da Organização pelos Pares
– Programa
de Treinamento
4 – Gerência Quantitativa -x-x-x- – Gerência
de Processos de Qualidade
de Software
5 -x-x-x- – Gerência – Prevenção
da Evolução de Defeitos
de Processos
– Gerência
da Evolução
da Tecnologia
Projetos em organizações com CMM-Nível 2 têm controles básicos de

gerenciamento de software. As estimativas de tempo, recursos e custos do
software são baseadas nos históricos dos projetos anteriores e projetadas
através dos requisitos estabelecidos no atual projeto. Os gerentes de softwa-
re possuem um controle de rastreabilidade em relação aos custos, cronogra-
mas, funcionalidades e defeitos. Os problemas são identificados na mesma
etapa em que são gerados, evitando a propagação de erros para fases anterio-
res. Os requisitos de software e todos os produtos gerados durante o desen-
volvimento são sistematicamente monitorados, possibilitando a evolução

do tamanho e complexidade destes. Os padrões de desenvolvimento do soft-
ware são definidos e a organização garante que estão sendo sistematicamen-
te seguidos. As organizações CMM–Nível 2 que empregam terceiros para
desenvolver todo ou parte dos processos de desenvolvimento devem estru-
turar políticas claras e padronizadas de como estabelecer vínculos precisos e
transparentes no relacionamento cliente-fornecedor.
O processo de software de uma organização CMM-Nível 2 pode ser en-
tendido como um processo disciplinado, pois as políticas de planejamento e
rastreamento do projeto de software estão estáveis e as práticas de sucesso
aplicadas a determinados projetos, podem ser convenientemente repetidas
corporativamente. O processo de software está sob o controle de um conso-
lidado modelo de gerenciamento de projetos regido por planos objetivos e
realistas, estimados a partir de experiências de projetos anteriores.
As KPAs do Nível 2 são:
Gerenciamento de requisitos
Planejamento de projetos de software
Supervisão e rastreamento do projeto de software
Gerenciamento de subcontratação de software
Garantia da qualidade de software
Gerenciamento de configuração de software
2.2.2. CMM-Nível 3
No nível de maturidade classificado como Definido, os diversos processos
padronizados de desenvolvimento de software estão adequadamente docu-
mentados. Os processos de gerenciamento do software estão conveniente-
mente integrados aos processos de engenharia de software, tornando o mo-
delo de processos único e integrado às diversas áreas organizacionais. Os
processos estabelecidos em organizações CMM–Nível 3 são usados e ajusta-
dos para auxiliar os gerentes e profissionais de software a ganharem mais
produtividade.
A organização busca as melhores práticas de engenharia de software
quando padronizam seus processos de software. Há um grupo responsável
por estabelecer e documentar as atividades do processo de software denomi-
nado SEPG (Software Engineering Process Group). Um amplo programa de
treinamento corporativo deverá ser implementado para desenvolver geren-
tes e profissionais e capacitá-los a desempenhar melhor suas funções, em-

pregando uma política contínua de transferência do conhecimento e ade-
quado desenvolvimento e aprimoramento de habilidades.
As organizações CMM–Nível 3 conseguem gerenciar processos dinâmi-
cos de desenvolvimento de software. A partir de um processo padrão de de-
senvolvimento, essas organizações podem acrescentar, modificar ou elimi-
nar atividades, dependendo das características e riscos envolvidos no proje-
to, possibilitando a criação de um processo de desenvolvimento “customi-
zado” a cada situação. A equipe do SEPG estabelece os pontos do processo
que possibilitam a “customização” e estabelece os critérios de flexibilização
e em quais situações serão empregadas. Um processo bem definido inclui
pré-requisitos para início das fases do projeto, artefatos obrigatórios e opci-
onais, padrões e modelos de referência, procedimentos de execução dos tra-
balhos, mecanismos de verificação de documentos, artefatos de saída e crité-
rios de finalização das etapas. Nesse nível, é possível visualizar claramente
como cada projeto em execução está evoluindo.
O processo de software de uma organização CMM-Nível 3 pode ser en-
tendido como padronizado e consistente porque ambas as atividades de en-
genharia e desenvolvimento estão estáveis e replicáveis. Todos os aspectos
relativos a um produto de software como custos, atividades e funcionalida-
des estão sob controle e a qualidade do software é medida e registrada. Existe
uma visão corporativa do processo de desenvolvimento, um entendimento
claro sobre as atividades e responsabilidades estabelecidas nesse processo de
software.
As KPAs do Nível 3 são:
Gerência integrada de software

Coordenação entre grupos
Definição do processo da organização
Foco no processo da organização
Programa de treinamento
Engenharia de produto de software
Revisões pelos pares
2.3. Impacto da Maturidade no Processo de Qualidade

Um dado importante que o SEI estima é o fato de que empresas de nível
dedicam cerca de 55% dos esforços direcionados para corrigir defeitos do
projeto de software desenvolvido. À medida que a empresa vai adquirin-

do maturidade, esses índices vão sendo gradativamente reduzidos para
35%, 20%, 10% até a empresa alcançar o nível 5 e reduzir esse patamar
para 5%. Imagine o impacto no tempo total de desenvolvimento, custo fi-
nal do projeto, número de profissionais envolvidos e o nível de confiabi-
lidade que essa empresa alcança quando atinge esse patamar de excelên-
cia organizacional.
Esforço de
Correção
60% 55%
50%
40% 35%
30%
20%
20%
10%
10% 5%
1 2 3 4 5 Nível de
Maturidade
Figura 2.2 Esforço dedicado à correção de defeitos

no desenvolvimento de software
O esforço gerencial para promover um processo de qualidade de soft-

ware é muito maior para empresas que possuem pouca maturidade organi-
zacional. Isso é fácil de entender, pois essas organizações estão pouco prepa-
radas para realizar atividades desse porte – não possuem processos bem es-
truturados, não há documentações adequadas e padronizadas; ainda não es-
tão completamente compreendidos os benefícios dos processos de qualida-
de de software e testes a serem aplicados em todos os ciclos do desenvolvi-
mento; a maioria das pessoas acredita que os problemas do desenvolvimento
são meramente tecnológicos, não necessitando de revisões dos processos e
mudanças na cultura da empresa; não existe participação efetiva dos clientes
e usuários nos processos de desenvolvimento, aumentando os riscos de o
produto não atender às reais necessidades; a maior parte da organização é re-
sistente à inovação do processo de desenvolvimento, pois acredita que o
aperfeiçoamento é uma atividade impraticável.
Esforço
Gerencial
25%
25%
20%
15%
15%
10%
10%
Esforço 5%
5% ZERO
1 2 3 4 5 Nível de
Maturidade
Figura 2.3 Esforço gerencial para alcançar níveis maiores de maturidade

CAPÍTULO 3
Definindo Qualidade
de Software
Qualquer decisão tomada durante o processo de desenvolvimento do

software pode comprometer sua qualidade final. Na verdade, o produto final
do processo de desenvolvimento é exatamente o somatório de todas as deci-
sões e realizações geradas durante todo o ciclo de desenvolvimento. Se dese-
jarmos produzir software com alta qualidade, é necessário investir em quali-
dade em todos os pontos do processo.
Qualidade de Software é um processo sistemático que

focaliza todas as etapas e artefatos produzidos com o
objetivo de garantir a conformidade de processos e
produtos, prevenindo e eliminando defeitos.
Figura 3.1 Definição de qualidade de software
3.1. Dimensão da Qualidade do Software

Softwares mal testados provocam prejuízos enormes às organizações. Um
simples erro interno do projeto poderá encadear requisições de compras
desnecessárias, solicitar manutenções de equipamentos antes do período
Definindo Qualidade de Software
ideal, produzir estatísticas falsas de produtividade, distribuir rendimentos

de forma desproporcional, entre outros. Os problemas podem afetar até a to-
mada de decisões de gerentes, diretores e acionistas da organização. São pro-
fissionais que estão apoiando-se nas informações de sistemas informatiza-
dos para minimizar riscos, direcionar esforços, promover investimentos,
sempre com o objetivo de tornar a organização mais eficiente e rentável. A
qualidade das decisões está intimamente ligada à qualidade das informações
disponibilizadas pelos diversos sistemas organizacionais.
No entanto, é impossível obter um software de qualidade com processos
de desenvolvimento frágeis e deficientes, portanto, não é possível estabele-
cer um processo de garantia da qualidade que não enfoque simultaneamente
o produto tecnológico e o processo de desenvolvimento desse software.
Assim, podemos estabelecer duas dimensões fundamentais para atingirmos
a qualidade do software: a dimensão da qualidade do processo e da qualida-
de do produto.
3.1.1. Dimensão da Qualidade do Processo

Quando estamos diante do desafio de garantir a qualidade de um software,
estamos, na verdade, estabelecendo uma cultura de não-tolerância a erros,
ou seja, estamos estruturando processos que possuam mecanismos de inibi-
ção e impedimento de falhas, possibilitando que os diversos artefatos gera-
dos durante o ciclo de desenvolvimento tenham procedimentos que avaliam
sua qualidade, possibilitando a identificação prematura de defeitos nesses
artefatos.
O termo “artefato” aqui empregado não pode ser entendido apenas
como um produto tecnológico, mas qualquer saída produzida por uma ativi-
dade do ciclo de desenvolvimento. Devemos incluir aqui todos os requisitos
levantados, modelos e especificações de negócios, arquitetura física, modelo
de dados e classes, distribuição de componentes, análises de custos, proje-
ções financeiras, ou seja, todos os documentos gerados durante o desenvol-
vimento do software. Todas as atividades cujo foco principal é garantir a
qualidade de cada etapa do processo de engenharia de software devem ser
consideradas dentro da dimensão da garantia da qualidade do processo de
engenharia de software.
Esse é um dos aspectos mais negligenciados dentro das empresas que
atuam com a produção e fornecimento de softwares. Na maioria dos casos,
não existe um processo formal de desenvolvimento e, quando existe, ele
apenas está no papel, não sendo respeitado pelas diversas equipes de desen-
volvimento. Portanto, se sua organização deseja produzir softwares com
qualidade, uma das primeiras providências a serem tomadas é estabelecer
um processo mínimo de desenvolvimento. Não poderemos garantir a quali-
dade de algo que não existe.
3.1.2. Dimensão da Qualidade do Produto

Essa dimensão de qualidade é muito evidente dentro do processo de desen-
volvimento de software. Qualquer empresa de software possui uma aborda-
gem para realizar testes nos produtos de softwares gerados durante o ciclo
de desenvolvimento. É comum que nos cronogramas existam fases específi-
cas para testes, apesar de elas serem, na maior parte das vezes, substituídas
por atividades de correção e manutenção do software.
Essa dimensão da qualidade tem por principal objetivo garantir a quali-
dade do produto tecnológico gerado durante o ciclo de desenvolvimento.
Todas as atividades que tenham por objetivo “estressar” telas e funcionali-
dades de um sistema informatizado podem ser categorizadas na dimensão
da garantia da qualidade do produto tecnológico.
Apesar de bastante empregadas nas organizações, o grau de eficiência
dessas atividades é assustadoramente baixo, o que incentiva as empresas a
substituírem tais atividades pela correção de problemas. São vários os mo-
tivos para a constatação desse fato, mas os principais pontos são: falta de
planejamento das atividades de testes, ausência de testes que validem fun-
cionalidades antigas e ausência de um processo de automação dos testes e
conferências.
3.2. Medindo a Qualidade através dos Testes

Uma constante confusão que observo nas empresas é estabelecer uma visão
limitada sobre testes durante o ciclo de desenvolvimento de software. Por
questões históricas, os profissionais de tecnologia somente visualizam os
testes como atividades a serem aplicadas em softwares. Essa confusão é re-
forçada em algumas metodologias que utilizam outros nomes para represen-
tar essas atividades como revisões, inspeções e auditorias, entretanto, esses
nomes apenas categorizam técnicas diferenciadas para testes de documen-
tos que indiretamente avaliam a qualidade de uma fase do ciclo de desenvol-
vimento. Na verdade, o processo de qualidade de software utiliza-se dos tes-
tes em todo o ciclo de desenvolvimento, de forma a garantir tanto o processo

de engenharia quanto o produto de software desenvolvido.
3.2.1. Testes que Garantem a Qualidade

do Processo
A qualidade dos processos pode ser medida através de testes aplicados em
documentos gerados em cada fase do desenvolvimento. Como cada etapa
deve produzir um conjunto de documentos, é possível estabelecer a qualida-
de nas várias fases do ciclo de desenvolvimento do software através da quali-
dade dos documentos produzidos. Se esses documentos apresentarem um
alto nível de defeitos e não atingirem um nível mínimo de qualidade, é possí-
vel reconstruir o documento ou até mesmo reexecutar a fase inteira. Esses
testes são conhecidos como testes de verificação.
Os testes de verificação são também conhecidos como testes estáticos,
pois seus principais alvos são os documentos gerados durante todo o ciclo
de desenvolvimento do software. O processo de engenharia decompõe as
atividades de desenvolvimento visando criar um processo sistemático de
condução dos projetos de software. Para avaliar a qualidade desse processo,
é necessário garantir a qualidade dos documentos produzidos em cada etapa
do desenvolvimento.
3.2.2. Testes que Garantem a Qualidade

do Produto
A qualidade dos produtos de softwares pode ser garantida através de siste-
máticas aplicações de testes nos vários estágios do desenvolvimento da apli-
cação. Esses testes são conhecidos como testes de validação porque, quando
construímos uma unidade de software, validamos sua estrutura interna e
sua aderência aos requisitos estabelecidos. Avaliamos sua integração com as
demais unidades de softwares existentes, validando as interfaces de comuni-
cação existentes entre os componentes de software. Quando determinado
subsistema ou mesmo a solução está finalizada, validamos a solução tecno-
lógica como um todo, submetendo a testes de todas as categorias possíveis.
Os procedimentos de testes aplicados diretamente em softwares são
também conhecidos pelo nome de testes de software ou testes dinâmicos. Os
testes de software, em sua maioria, podem sofrer um alto nível de automa-
ção, o que possibilita a criação de complexos ambientes de testes que simu-
lam diversos cenários de utilização. Quanto mais cenários simulados, maior

o nível de validação que obtemos do produto, caracterizando maior nível de
qualidade do software desenvolvido.
3.2.3. Definição Comum de Testes

De forma geral, todas as equipes de desenvolvimento aplicam testes em seus
softwares, independentemente se os testes são bem planejados, bem estrutu-
rados e de como são executados. O fato é que esses testes não são suficientes
para detectar os erros que estão inseridos dentro de uma aplicação. Um dos
motivos básicos para que isso ocorra é na forma com que esses profissionais
encaram os testes de software. Abaixo, algumas definições encontradas pe-
las diversas equipes de desenvolvimento:
Teste é o processo
Teste é o processo Teste é o processo
de provar que
de demonstrar que de demonstrar que
determinadas coisas
os defeitos não algo funciona
fazem o que
estão presentes. corretamente.
deveriam fazer.
Figura 3.2 Simplificação das definições dos testes
Todos enxergam os testes como uma forma de provar que tudo está bem
e funcionando conforme o estabelecido. Todas as definições difundidas so-
bre testes dão uma dimensão positiva sobre o problema, ou seja, o entendi-
mento sobre testes é sempre colocado sobre o prisma de avaliar se tudo está
funcionando adequadamente. O fato é que é mais fácil provar que “algo fun-
ciona” do que provar que “algo não funciona”, o que significa que teremos
um menor esforço em provar o funcionamento de um software do que o con-
trário. E é exatamente isso que sentimos quando colocamos uma equipe in-
dependente de qualidade para avaliar determinado projeto de software –
como essa equipe não está envolvida emocionalmente nem politicamente
com o projeto, terá um comportamento muito mais objetivo e direto, indo
exatamente nos pontos que inicialmente o projeto deveria atender e por mo-
tivos desconhecidos foram abandonados ou não atendidos corretamente.
TESTES PARA PROVAR QUE

ALGO NÃO ESTÁ CORRETO
TESTES PARA PROVAR
QUE ALGO ESTÁ CORRETO
Cenários Positivos Cenários Negativos
Cenários Positivos Estendidos Estendidos
Visão do Comuns
Visão do
Analista de Analista de
Sistemas Testes
Figura 3.3 Visões dos testes por perspectivas diferentes
Se nosso objetivo é apenas provar que as coisas estão funcionando,

significa que idealizaremos um conjunto de cenários favoráveis à utiliza-
ção de um software ou um documento qualquer, mas se nosso objetivo
passa a ser o de provar a não-adequação de algo, temos que ir além dos ce-
nários positivos comuns e estender nossa abstração e identificar um mai-
or volume de cenários positivos. Nesse processo de refinamento dos tes-
tes, devemos incluir um esforço adicional em identificar os cenários ne-
gativos.
3.2.4. A Definição Correta sobre Testes

Entender que o objetivo dos testes é “provar que algo não funciona” é um
avanço significativo na compreensão de um processo de qualidade de soft-
ware. Não adianta termos documentações incompletas, imprecisas e ambí-
guas. É necessário buscar um maior nível de qualidade em todos os produ-
tos (sejam documentos ou softwares) produzidos em todas as fases do ci-
clo de desenvolvimento. Esses documentos auxiliarão as equipes a toma-
rem decisões mais corretas sobre o projeto de software que refletirá em um
produto com maior conformidade com as necessidades dos clientes e usuá-
rios. Portanto, os testes em documentos deverão não somente analisar se as
definições foram registradas, mas se estas foram escritas de forma a não dar
margens a dúvidas e se estão em conformidade com as demais. Se o docu-
mento registra decisões que foram analisadas, devemos avaliar se tais deci-
sões estão apoiadas em informações e análises objetivas e não por dados in-
fundados ou meras suposições.
Teste é um processo sistemático e planejado que tem

por finalidade única a identificação de erros.
Figura 3.4 Definição ampliada de testes
3.2.5. Limitações dos Testes

Todo o processo de qualidade de software deve prevenir a todos sobre um ele-
vado nível de confiança em relação a processos de testes executados. Infeliz-
mente, a maioria dos testes é executada sem planejamento, com massas de da-
dos não controladas, ambientes com alta interferência e com alta incidência
de procedimentos manuais, tornando este processo muito frágil e pouco efi-
ciente. Com um forte planejamento e formalização destas atividades, conse-
guimos obter um alto nível de eficiência desse processo, porém nunca podere-
mos afirmar que um software estará totalmente livre de erros, mesmo que
possuíssemos todos os recursos profissionais e tecnológicos disponíveis.
Devemos ter em mente que os testes podem ser usados para mostrar a
presença de erros, mas nunca sua ausência. A razão óbvia para essa conclu-
são é o fato de que um processo de qualidade, por melhor que ele seja, não
conseguirá cobrir todas as infinitas combinações existentes em um ambien-
te de execução real.
A qualidade de um software é definida pelo número de requisitos que fo-
ram adequadamente testados e estão em conformidade com o especificado.
Obter mais qualidade significa aumentar o grau de cobertura e testar novos
requisitos e inserir novos cenários que não estavam sendo considerados.
Quanto maior a extensão dos testes, maior será a qualidade do software e
menor será os riscos de erros, uma vez que mais cenários foram testados e ade-
quadamente validados. Assim, os esforços de testes devem ser orientados pelo
risco existente e pelo impacto que a falta de qualidade causará ao ambiente in-
terno e externo da organização. Deve estar relacionada diretamente à política
de gerenciamento de riscos aplicada ao software e pela organização, amplian-
do ou reduzindo os esforços, dependendo dos cenários envolvidos.
3.2.6. Atitude Zero-defeito

Foi Glenford J. Myers no livro The Art of Software Testing que corretamente
vinculou a palavra testes com o compromisso da identificação de erros. O
23
autor é um respeitável estudioso no assunto e possui diversos estudos e pu-

blicações sobre processos de testes de software. Uma de suas conclusões so-
bre o tema é entender que Zero-defeito é algo inatingível, ou seja, pela com-
plexidade envolvida e pelo número altíssimo de situações existentes, tor-
na-se impossível imaginar um produto de software livre de erros. Não po-
demos nos enganar sempre existirão erros a serem descobertos, porém, o
desafio de um processo de garantia da qualidade é justamente tornar esse ris-
co o mais próximo possível do zero.
A qualidade de software trabalha com o conceito Zero-defeito, que re-
presenta a não-tolerância a erros de dentro de um processo de qualidade de
software. O objetivo é definir um processo que contenha mecanismos de ini-
bição de defeitos, impedimento que falhas sejam criadas e propagadas para
as fases seguintes. Todo o processo é desenhado para minimizar a incidência
de problemas.
3.3. Os Pilares da Qualidade de Software

Aqui faremos referência aos trabalhos realizados no PMI (Project Manage-
ment Institute) que organizou o chamado PMBOK (Project Management
Body of Knowledge) no qual o processo de gerenciamento da qualidade é
subdividido em três subprocessos complementares:
Processo de Garantia da
Qualidade do Software
Planejamento da Garantia da Controle da

Qualidade Qualidade Qualidade
Todas as atividades Todas as atividades, Todas as atividades,

referentes ao planejamento técnicas e procedimentos técnicas e procedimentos
das atividades da qualidade realizados com o objetivo relacionados a medir e
e os esforços na prevenção de identificar erros em monitorar a qualidade do
de defeitos. artefatos do software. processo e do produto
de software.
Figura 3.5 Os Pilares da garantia da qualidade de software

3.3.1. Planejamento da Qualidade

Processo destinado a identificar quais padrões de qualidade são relevantes
para o projeto e determinar como satisfazê-los. É realizado em paralelo com
outros processos de planejamento e tem como produto o Plano da Garantia
da Qualidade de Software (SQA Plan – Software Quality Assurance Plan) e
todos os planejamentos mais direcionados (Estratégias de Testes das diver-
sas categorias existentes).
3.3.2. Garantia da Qualidade

Processo que engloba a estruturação, sistematização e execução das ativida-
des que terão como objetivo garantir o adequado desempenho de cada etapa
do desenvolvimento, satisfazendo os padrões de qualidade definidos no pro-
cesso. Aqui estarão relacionados os testes de verificação (testes estáticos) e
os testes de validação (testes dinâmicos ou testes de softwares) previstos em
todas as etapas do ciclo de desenvolvimento.
3.3.3. Controle da Qualidade

Processo que se concentra no monitoramento e desempenho dos resultados
do projeto para determinar se ele está atendendo aos padrões de qualidade
no processo de desenvolvimento. Trata-se de um processo contínuo e siste-
mático de acompanhamento da eficiência do desenvolvimento em diversos
pontos de controle, possibilitando às gerências e profissionais envolvidos
acompanhar variações de qualidade e promover ações corretivas e preventi-
vas para manter o nível de qualidade desejado. Avaliará sistematicamente a
qualidade do processo em execução e a qualidade do produto tecnológico
que está sendo desenvolvido.
3.4. Onde Devemos Aplicar Qualidade?

Um dos erros mais comuns sobre qualidade é o modo como este é inserido
dentro do processo de engenharia de software. Todos tendem a pensar o
desenvolvimento de software como uma linha do tempo. Dessa forma, de-
finimos metodologias e processos de trabalho para produzir software e ga-
rantirmos que as etapas serão cumpridas e o produto terá seu ciclo comple-
to de desenvolvimento. O erro é acreditar que dentro desse processo existe
um período alocado especialmente para a realização dos testes.
Esforço
para Obter
Qualidade
Modelo de Análise e Implemen- Testes de Disponibili-

Requisitos
Negócios Modelagem tação Software zação
Tempo
Figura 3.6 Ciclo de desenvolvimento no qual qualidade

resume-se a testes de software
Dessa forma, cometemos o equívoco de acreditar que somente obtere-

mos qualidade após a codificação de partes do produto a ser desenvolvido.
Isso fere com a idéia de identificar os erros nas fases iniciais do processo de
desenvolvimento de software, evitando a migração dos erros e, conseqüen-
temente, elevando os custos de correção.
“Qualidade não é uma fase do ciclo de

desenvolvimento de software…
...é parte de todas as fases.”
Figura 3.7 Qualidade em todo o ciclo do processo de desenvolvimento
Isso significa que devemos garantir a qualidade de todas as etapas do

processo de desenvolvimento do software, de forma a garantir que não inici-
emos uma nova fase caso esta ainda não tenha sido bem finalizada e entendi-
da. Em outras palavras, devemos garantir a concepção do sistema desejado
antes de analisarmos os requisitos de negócios, devemos garantir a análise
dos requisitos antes de iniciarmos o processo de arquitetura do software, de-
vemos garantir a modelagem do software antes de codificarmos o produto,
devemos garantir o código antes de executá-lo. Dessa forma, estamos ampli-
ando a concepção de garantia da qualidade dentro do processo de engenha-
ria de software como um todo.
3.4.1. Onde Estão os Defeitos?

Os defeitos são conhecidos por seus vários nomes. Podem ser chamados de erros,
problemas, falhas, ocorrências, incidentes, não conformidades e inconsistên-
cias. Também podemos empregar palavras existentes na língua inglesa como
bugs, crash, abends. Apesar de esses nomes representarem naturezas de defei-
tos diferentes, eles demonstram um desvio de qualidade no ato de elabora-
ção de um documento, na execução de uma atividade, na construção de um
componente de software. São esses desvios de qualidade que produzem re-
trabalho, aumentam os custos do projeto, dilatam os prazos de entrega do
software, diminuem a produtividade e aumentam a insatisfação do cliente.
Existe uma visão comum de entender que os defeitos somente são pro-
venientes do código-fonte do produto. Também se entende que somente os
profissionais de desenvolvimento, qualidade e testes são os responsáveis por
um software sem defeitos. Em ambas as afirmações, estão cometendo um
grave erro: primeiro, os erros são gerados durante todo o processo de enge-
nharia do software – são os resultados de traduções imperfeitas de requisitos e
especificações que provocam a maior parte dos problemas. Através de estudos
realizados, é possível constatar que a participação das diversas áreas reduz
drasticamente o risco de insucesso do projeto. Significa que as áreas de desen-
volvimento e qualidade deverão interagir continuamente com as áreas de ne-
gócio, produção, suporte, infra-estrutura e atendimento a cliente.
Os erros ocorrem em todas as fases do processo de desenvolvimento de
software, porém, estudos demonstram que a maior incidência dos erros está
concentrada nas fases iniciais do processo de desenvolvimento. Muitos dos
Análise e Modelagem
Requisitos
27%
56%
Implementação
7%
Outros
10%
Figura 3.8 Incidência de defeitos nas etapas do desenvolvimento
erros identificados no produto final são provenientes da má especificação e

entendimento sobre os objetivos a serem alcançados. Se nosso objetivo é re-
duzir, ao máximo, o nível de erros dentro do processo de desenvolvimento
de software, devemos nos concentrar nas atividades iniciais do processo.
Dessa forma, estaríamos identificando prematuramente os erros e impedin-
do que estes migrassem para outras fases.
3.4.2. Qualidade em Todo o Ciclo de Desenvolvimento

Se os erros estão concentrados nas fases iniciais do ciclo de desenvolvimen-
to, devemos investir mais tempo nas atividades de especificação e modela-
gem da solução. Isso faria com que muitos dos erros fossem eliminados em
função de um levantamento mais criterioso e bem estruturado, porém, a re-
dução dos erros somente ocorrerá se em todas as etapas do processo de de-
senvolvimento existir procedimentos que avaliem a qualidade do que foi
produzido. Dessa forma, cada etapa teria seus produtos adequadamente ava-
liados e vistoriados, atestando a qualidade destes e impedindo que uma nova
fase seja iniciada sem que tenha sido concluída adequadamente.
Ter um processo de garantia da qualidade em todo o ciclo de desenvolvi-
mento do software permite que um número maior de defeitos sejam desco-
bertos antecipadamente, evitando a migração destes para as fases seguintes.
Isso fará com que os custos referentes às não-conformidades caiam drastica-
mente, tornando o processo mais estável e menos caótico. Também fará com
que os prazos para implantação do software sejam reduzidos em função do
menor índice de retrabalhos, refletindo em um aumento na satisfação do cli-
ente (produto mais confiável), uma equipe mais motivada (menos retraba-
lho e atividades mais construtivas) e uma empresa mais fortalecida (clientes
querem trabalhar com empresas que honram prazos e compromissos).
Processo de Garantia da Qualidade de Software

Requisitos
Tempo
Figura 3.9 Garantia da qualidade de software em todo o ciclo de desenvolvimento

Dessa forma, a resposta à pergunta Onde devemos aplicar Qualidade? tor-

na-se simples – devemos aplicar qualidade em todo o ciclo de desenvolvimento.
A cultura da qualidade cria um ambiente favorável para prevenção e detecção
de erros, transformando o processo de desenvolvimento em uma atividade com
etapas monitoradas e constantemente avaliadas, tornando o processo confiável.
3.5. O Custo da Qualidade de Software

O custo da qualidade pode ser entendido como todo o investimento realiza-
do com a finalidade de um produto ou serviço atingir a qualidade desejada.
Esses investimentos alocam todos os esforços relacionados aos custos das
não-conformidades (defeitos e suas correções) como todos os custos relaci-
onados à manutenção da conformidade dos produtos e serviços a serem pro-
duzidos (esforço de garantir a qualidade).
3.5.1. Custos da Conformidade

Os custos da conformidade são todos os investimentos realizados para planejar
e manter toda uma infra-estrutura de pessoas, processos e ferramentas cujo ob-
jetivo é prevenir e detectar erros do processo. Tudo que é realizado com a inten-
ção de melhorar e garantir o processo de desenvolvimento deve ser considerado
custo da conformidade, ou seja, o custo para se obter e garantir qualidade.
Planejamento dos trabalhos

Treinamentos (processos, técnicas e ferramentas)
Controles do processo de desenvolvimento
Testes (estáticos e dinâmicos)
Revisões de documentos
Auditorias de processos
3.5.2. Custos da Não-conformidade

Os custos da não-conformidade são todos os custos de atividades ligadas ao
esforço de reparar falhas de produtos originados no decorrer do processo de
desenvolvimento. Todas as conseqüências financeiras causadas por esses
defeitos devem ser computadas nos custos da não-conformidade. Tudo que
é realizado ou gerado em função de defeitos produzidos durante os projetos
de software deve ser encarado como não conformidade, ou seja, os custos
provenientes da falta de qualidade.
Refugos
Retrabalhos
Ações corretivas
Atrasos nos cronogramas
Perdas financeiras e operacionais
Perdas de oportunidades
3.6. Um Modelo de Custo de Qualidade de Software

Um dos maiores desafios a ser considerados é estabelecer um modelo de cus-
tos relacionados à implantação de um processo de garantia da qualidade do
software. Sem esse modelo, nunca teremos uma real compreensão sobre o
impacto financeiro causado por processos deficientes e o quanto representa
financeiramente a relação investimento versus melhoria da qualidade.
O modelo apresentado adiante consegue estabelecer uma dupla visão re-
lacionada sobre a qualidade de um software. Para um efetivo controle dos
custos necessitamos visualizar não somente os custos da não-conformidade
(falta de qualidade), mas os custos relacionados à obtenção da qualidade
(esforço para alcançar a qualidade). Nesse modelo, os custos da conformida-
de são separados em duas categorias: os custos da detecção dos defeitos, re-
lacionados a todas as atividades que visam garantir e detectar problemas nos
diversos produtos (documentos, relatórios, softwares) gerados durante o ci-
clo de desenvolvimento, e os custos de prevenção dos defeitos, relacionados
a todas as atividades que tenham por objetivo reduzir o nível de falhas das
diversas etapas do desenvolvimento.
Esse modelo apresentado deverá ser associado a todas as atividades de
um processo de engenharia de software. Em todos os projetos a serem cons-
truídos ou modificados, todas as atividades deveriam ter uma política de alo-
cação de custos semelhante ao modelo apresentado. Será uma grande sur-
presa aos proprietários, gerentes, profissionais e clientes perceberem quanto
representa percentualmente os custos de não-conformidade de um processo
de desenvolvimento. Com isso devidamente medido e publicado a todos os
interessados, acredito que todos estarão sensibilizados da necessidade de
mudar a forma como conduzir os projetos de software, valorizando os traba-
lhos de aperfeiçoamento de processos. Lembro que não será uma atividade
simples e necessitará muito esforço e determinação para alcançar esse con-
trole aqui proposto, porém, este será o único caminho para se obter o real
controle financeiro sobre esses fatores.
Custo do
Projeto
Custo da Custo do
Qualidade Desenvolvimento
…
Custo da Custo da
Conformidade Não-conformidade
- Re-Revisões
- Retestes
- Correção
Custo da Custo da º Código
Detecção de Defeitos Prevenção de Defeitos
º Documentação
- Revisões - Metodologias - Reestruturação
º Problema - Treinamento - Redistribuição da versão
º Requisitos - Ferramentas - Atrasos nos Cronogramas
- Políticas - Falhas da Produção
º Modelagem
- Procedimentos Existe uma co-relação entre
º Planos de Testes
- Planejamento os custos da não-conformidade
º Scripts de Testes - Análises com os investimentos em
- Inspeção de Código - Métricas prevenção de defeitos. Quanto
- Testes (primeira execução) - Relatório de Qualidade maiores esses investimentos, menor
- Auditorias - Projetos de Inovação a incidência das não-conformidades.
Figura 3.10 Modelo de custo da qualidade de software
3.7. O Custo da Propagação dos Defeitos

Todo e qualquer tipo de erro custa dinheiro. Não estamos só falando da alo-
cação de tempo e recursos para produzir algo defeituoso, mas também nos
danos provocados pelo erro, bem como sua identificação, correção, teste e
implantação da correção, porém, segundo estudos de Myers, quanto mais
tardiamente descobrimos os erros, mais caros estes se tornam. Ele aplica a
chamada “regra de 10” aos custos da correção dos erros. Significa que, quan-
do um erro não é identificado, os custos de sua correção multiplicam-se por
10 para cada fase em que o erro migra.
Analisando o gráfico mostrado na Figura 3.11, fica evidente a vantagem
de possuirmos um processo de detecção de problemas de forma a não evitar
que um erro “migre de uma fase a outra”, fazendo com que os custos de cor-
reção multipliquem-se. Devemos entender que testar nas fases iniciais sai
mais barato do que nas fases mais tardias do processo de desenvolvimento.
“Erros na produção são extremamente caros.”
10.000
1.000
100
10
1
Requisitos Análise e Código Teste de Produção

Modelagem Software
Ciclo de Desenvolvimento de Software
Figura 3.11 Regra de 10 de Myers
3.8. A Relação Custo versus Qualidade

Em um mundo sem restrições, a decisão de implementar um processo com-
pleto de qualidade em todo o ciclo de desenvolvimento de um software não
seria problema. Porém, aplicar esses conceitos envolve grande montante de
dinheiro, recursos profissionais e tempo, e nem sempre teremos condições
para fazê-los. No mundo real, bons profissionais conseguem direcionar seus
esforços e contornar as restrições que lhes são impostas. Isso significa priori-
zar as atividades importantes e dar maior ênfase aos softwares e etapas mais
críticas e problemáticas. Dessa forma, poderemos minimizar os riscos envol-
vidos na atividade de desenvolvimento de um software e implantar um efeti-
vo processo de garantia da qualidade.
Outros aspectos estão também relacionados à maturidade organizacio-
nal do cliente, ou seja, se esse ainda não possui um processo estruturado de
desenvolvimento de software, com certeza não será possível estabelecer um
processo de qualidade completo. A falta de documentos básicos inviabili-
zam esse processo, pois o desenvolvimento é tão informal que não haverá
documentações e especificações a serem inspecionadas.
Completo
CUSTO Parcial
DA
QUALIDADE
Produto Acabado
Auditoria
EFETIVIDADE NO PROCESSO DE
IDENTIFICAÇÃO DE DEFEITOS
Figura 3.12 Custo da qualidade versus efetividade do processo
Auditoria: Nível superficial de um processo de qualidade. Verifica se

as atividades e documentos estão respeitando as estruturas e padrões
estabelecidos. Trata-se de uma análise do esqueleto do processo. Não
é avaliada a qualidade dos documentos gerados nem do software de-
senvolvido pela equipe.
Produto Acabado: Nível mais praticado nas organizações. O processo
de qualidade somente é iniciado após o software ter sido transformado
em um produto tecnológico. São aplicados todos os testes possíveis no
produto acabado.
Parcial: Nível intermediário de qualidade. O processo de teste ini-
cia-se juntamente com o processo de estruturação interna do software
e o acompanha ao longo de seu ciclo de desenvolvimento. Os testes
são orientados por requerimentos e especificações funcionais.
Completo: Trata-se de um efetivo processo de garantia da qualidade
do software. O processo inicia-se conjuntamente com o levantamento
de requisitos do software. Todas as etapas são completadas segundo
um critério de finalização previamente estabelecido, os documentos
são todos analisados e revisados pela equipe de qualidade de software
e todas as categorias de testes são aplicadas no software desenvolvido.
CAPÍTULO 4
Entendendo o Processo
de Qualidade de Software
Não é possível conceber um processo de garantia da qualidade de soft-

ware sem integrá-lo com o ciclo de desenvolvimento de software. Um bom
processo de qualidade é aquele que cria uma relação “um-para-um” entre as
fases de desenvolvimento e as atividades a serem desempenhadas pela equi-
pe de qualidade. Essa relação bilateral promove a colaboração entre as áreas
e reforça a idéia do objetivo comum.
4.1. Modelo de Qualidade de Software em “U”

O Processo de Qualidade de Software está decomposto em fases que se orga-
nizam em um formato em “U”. Cada fase tem uma numeração indicando a
seqüência de execução dos testes a serem aplicados. O objetivo do processo
de qualidade é garantir que durante o ciclo de desenvolvimento do software
produza efetivamente todos os produtos previstos na metodologia emprega-
da e que o aplicativo que está sendo construído esteja adequado com os re-
quisitos documentados. Os testes de verificação visam garantir o processo
de engenharia do software, enquanto os testes de validação estão focados na
garantia da qualidade do produto de software.
TESTES DE VERIFICAÇÃO TESTES DE VALIDAÇÃO
Modelo
de Disponibilização
Negócios de Solução
1 8
Verificação Validação
de do
Negócios Aceite
Especificação Sistema
de Especificado ou
Requisitos Modificado
2 Clientes 7
Verificação Patrocinadores Validação
de Usuários do
Requisitos Sistema
Análise e Unidade Integração

Modelagem Implementação Especificada ou Especificada ou
Modificada Modificada
3 4 5 6
Verificação, Verificação Validação Validação
Análise e da da da
Modelagem Implementação Unidade Integração
Figura 4.1 Visão do modelo de processo de qualidade de software em “U”
4.2. Formas Básicas de um Teste

O processo de desenvolvimento de software pressupõe dois momentos bem
definidos. O primeiro é a fase de coleta de informações de negócios e o pla-
nejamento da arquitetura do software. Essa fase caracteriza-se pelo esforço
em criar um perfeito entendimento entre o negócio a ser atendido e o soft-
ware a ser construído. Nesse momento, não existem componentes tecnoló-
gicos, mas sim documentos que especificam o comportamento a ser assimi-
lado pelo software a ser construído, como se estivéssemos criando uma
grande maquete do projeto de software – é nesse primeiro momento que
uma forma básica de teste destaca-se: os testes de verificação.
A segunda fase do desenvolvimento do software caracteriza-se pela existência
de um componente computacional (seja parte ou um todo de uma solução). De-
vemos aplicar um conjunto de testes que avaliam a qualidade do produto de soft-
ware desenvolvido em relação aos requisitos identificados nas fases anteriores – é
neste momento que a outra forma básica de teste aparece: os testes de validação.
Entendendo o Processo de Qualidade de Software
4.2.1. Teste = Verificação + Validação

Historicamente, as empresas vêm aplicando seus testes baseando-se nos
princípios dos testes de validação. Como já vimos, os erros são criados nas
fases iniciais do processo de desenvolvimento, o que torna os custos de não
conformidades mais caros, uma vez que estes crescem exponencialmente
quando migram de uma fase à outra. Apesar de ser muito positivo algumas
empresas construírem ambientes para a realização dos testes de validação,
estas não estão dirigindo seus esforços para as fases iniciais do processo de
software, portanto, os custos de correções dessas organizações e o número
de incidência de erros nos softwares desenvolvidos serão muito altos nas fa-
ses de testes de validação.
Testes de verificação e validação são complementares. Em hipótese algu-
ma, estes deverão ser encarado como atividades redundantes. Tanto um
quanto o outro possui naturezas e objetivos distintos, fortalecendo o proces-
so de detecção de erros e aumentando a qualidade final do produto. Um bom
processo de qualidade de software deverá potencializar essas duas formas de
testes de modo que os esforços sejam minimizados e os resultados sejam os
mais positivos possíveis.
4.2.2. Testes de Verificação

Os testes de verificação podem ser entendidos como um processo de audito-
ria de atividades e avaliação de documentos gerados durante todas as fases
do processo de engenharia de software. As verificações devem ser aplicadas
a todos os produtos (documentos, gráficos, manuais, códigos-fonte) que são
produzidas em cada etapa do processo, evitando que dúvidas e assuntos
“mal resolvidos“ migrem para a próxima fase. Dessa forma, reduziremos os
níveis de retrabalho, uma vez que esses defeitos não serão introduzidos nos
softwares que serão construídos.
A principal característica dos testes de verificação é o fato de não envol-
ver o processamento de softwares. Na verdade, esss atividades antecedem a
criação do aplicativo, exatamente para garantir que todas as decisões e defi-
nições estabelecidas foram adequadamente entendidas e aceitas pelos diver-
sos grupos que integrarão o processo de desenvolvimento.
Durante o levantamento e a definição da solução tecnológica, muitas
ações deverão ser realizadas para garantir a qualidade das atividades e docu-
mentos produzidos em cada etapa do desenvolvimento como a realização de
revisões de documentos e auditorias de qualidade.
Modelo Especificação Análise e Implementação

de de Modelagem
Negócios Requisitos
1 2 3 4
Verificação Verificação Verificação, Verificação

de de Análise e da
Negócios Requisitos Modelagem Implementação
Figura 4.2 Etapas dos testes de verificação
Os testes de verificação serão aplicados respeitando os estágios de desen-

volvimento:
Testes na etapa de definição das necessidades e características de ne-

gócios a serem atendidas pela solução.
Testes na etapa de identificação dos requisitos funcionais e não funcio-
nais que a solução tecnológica deverá contemplar.
Testes na etapa de definição do modelo de arquitetura da solução tec-
nológica.
Testes na etapa de construção dos softwares que atenderão às defini-
ções da arquitetura estabelecida.
4.2.3. Testes de Validação

Os testes de validação podem ser entendidos como um processo formal de
avaliação de produtos tecnológicos que podem ser aplicados em componen-
tes isolados, módulos existentes ou mesmo nos sistemas como um todo. Seu
objetivo é avaliar a conformidade do software com os requisitos e especifica-
ções analisadas e revisadas nas etapas iniciais do projeto.
A característica dos testes de validação é a presença física do software e
de seu processamento em um ambiente tecnologicamente preparado para
tais atividades. Os testes serão baseados no comportamento do software, se-
gundo diversas condições que serão simuladas, para que sejam comparados
com as especificações produzidas pela área de negócios. Na maioria dos ca-
sos, esses testes expõem mais sintomas do que propriamente erros, ou seja, a
maioria dos defeitos de um software não se apresenta na forma mais explíci-
ta, como uma interrupção do processamento ou uma não-execução de uma
funcionalidade, mas sim na forma mais camuflada e difícil de diagnosticar,
Entendendo o Processo de Qualidade de Software
Unidade Integração Sistema Disponibilização

Especificada ou Especificada ou Especificado ou de
Modificada Modificada Modificado Solução
5 6 7 8
Validação Validação Validação Validação

da da do do
Unidade Integração Sistema Aceite
Figura 4.3 Etapas dos testes de validação
como um ajuste financeiro errado, um cálculo de imposto irregular, uma

amortização de financiamento imprecisa ou mesmo alocação de estoque in-
devida, portanto, os resultados do processamento dos softwares serão os
principais pontos de validação.
Durante o desenvolvimento do software, determinadas categorias de
testes serão aplicadas utilizando ferramentas, técnicas e abordagens diferen-
ciadas. As atividades relacionadas a planejamento, modelagem, execução e
conferência dos testes de software deverão ocorrer em paralelo às atividades
de construção de componentes executáveis.
As validações serão aplicadas respeitando-se os estágios de desenvolvi-
mento:
Testes em componentes executáveis isolados recém-criados e alte-

rados.
Testes de interface entre componentes à medida que eles vão sendo in-
tegrados.
Testes em sistemas ou módulos completos.
Aceite de um sistema ou módulos pelos clientes e usuários.
CAPÍTULO 5
Incremental
O desenvolvimento de software deve empregar mecanismos para ga-

rantir que os esforços sejam devidamente direcionados a um objetivo co-
mum. Torna-se necessário evidenciar as fases de desenvolvimento para que
possamos estabelecer pontos de controle e tornar gerenciável o processo de
desenvolvimento, portanto, um ciclo de desenvolvimento é uma representa-
ção de como o processo obtém organização e controle nas atividades de
construção de um software.
5.1. Ciclo de Desenvolvimento em Cascata

No modelo de desenvolvimento mais tradicional, os projetos são estrutura-
dos segundo um conjunto de etapas bem definidas que são completadas se-
qüencialmente, sendo que uma etapa alimentará as próximas com decisões,
documentos e informações sobre o produto a ser desenvolvido.
Essa abordagem é chamada de processo em cascata (waterfall), pois en-
cadeia seqüencialmente as etapas formando degraus de execução. Essa abor-
dagem foi largamente aplicada nas indústrias de software, por sua facilidade
de gerenciamento e entendimento por todos os profissionais. Também pos-
sibilita manter especialista em cada fase do processo, facilitando o particio-
namento do trabalho.
Invariavelmente, essa abordagem resulta em um grande problema quan-
do a etapa de implementação encerra-se e iniciamos a etapa de testes do soft-
Qualidade de Software Incremental

Requisitos
Tempo
Figura 5.1 Ciclo de desenvolvimento tradicional (waterfall)
ware. Nesse momento, todas as inconsistências de levantamentos de requi-

sitos, deficiências de análise e modelagem do projeto, e erros na implemen-
tação do software estão perigosamente concentrados. Essa concentração de
problemas tornará o processo de correção extremamente complexo e de alto
risco. Mudanças maciças produzem uma nova onda de defeitos, sendo ne-
cessárias várias revisões de documentos e, muitas vezes, aplicar uma rees-
truturação em todo o projeto. O fracasso dos projetos começa a acontecer
nesse ponto, no qual entramos na fase de ingerência do processo.
A ingerência caracteriza-se pela perda de controle das três variáveis
mais importantes de um processo de desenvolvimento: custos, recursos e
prazos. Os custos começam a crescer, uma vez que nada de novo é desen-
volvido e todos os esforços concentram-se em fazer funcionar o que teori-
camente já deveria estar funcionando. Os profissionais têm dificuldades de
se posicionar em relação a suas atividades e em que situação elas se encon-
tram, impossibilitando qualquer planejamento das atividades, conduzin-
do os profissionais na simples tarefa de “ir fazendo até fechar todos os bu-
racos”. Os prazos são ampliados em função do número acentuado de retra-
balhos realizados. Sucessivas prorrogações são realizadas pela falta de en-
tendimento sobre o quanto o produto está estável. Enfim, a ingerência é o
puro “caos organizacional”.
Muitos projetos fracassaram principalmente porque empregaram esse
tipo de abordagem que conduz o projeto a centrar suas ações na “realização
das tarefas”, sem que nenhum produto “parcial” seja produzido. Isto faz
com que clientes, gerentes e profissionais de desenvolvimento não tenham
uma referência “concreta” sobre os resultados a serem alcançados, tornando
o processo agradável inicialmente e estafante no final.
Devemos entender que a maioria dos profissionais tem dificuldades em
lidar com coisas abstratas e as documentações não serão suficientes para sa-
ciar tal necessidade. Corremos um grande risco quando não é disponibiliza-
do um produto “parcial” para que ocorra uma avaliação concreta dos resul-
tados alcançados.
Tabela 5.1
Representação de um típico projeto em cascata (diagrama de Gantt)
Etapas do Processo Primeiro Mês Segundo Mês Terceiro Mês Quarto Mês
1a 2a 3a 4a 1a 2a 3a 4a 1a 2a 3a 4a 1a 2a 3a 4a
semana semana semana semana semana semana semana semana semana semana semana semana semana semana semana semana
Modelo de Negócios
Requisitos de Software
Análise e Modelagem
Implementação do Software
Testes de Software
Disponibilização do Software
Sob a perspectiva de gerenciamento do projeto, essa abordagem aten-

de perfeitamente, pois estrutura adequadamente as atividades de forma
lógica e gradativa, possibilitando uma sensata operacionalização dos
procedimentos de trabalho, porém, sob a perspectiva técnica do projeto,
ela não proporciona um mecanismo de aprendizado gradativo nem possi-
bilita mecanismos de correção de rumos durante o processo de desenvol-
vimento.
5.2. Ciclo de Desenvolvimento Iterativo

Necessitamos ter um processo com um encadeamento de atividades similar
ao processo em cascata, porém com ciclos curtos de desenvolvimento, de
forma a possibilitar reavaliações constantes do projeto e um mecanismo ide-
al para assimilar conhecimentos de forma gradativa.
Sob o ponto de vista do projeto, o ciclo de desenvolvimento de software
passa a ser visto como uma sucessão de iterações, na qual o software ganha
sucessivos incrementos de funcionalidades até que atenda à totalidade dos
requisitos esperados. Cada iteração deve fornecer um produto “executável”,
devidamente testado e pronto a ser utilizado, resultando em um subconjun-
to de uma visão completa do sistema. Deve ser operacional, sob a perspecti-
va das necessidades do cliente, e completo, sob a perspectiva da engenharia
do produto construído.
Análise
Modelo de Implemen- Disponibili- Evolução
Requisitos e Testes
Negócios Design tação zação I
E
v
o Análise
Modelo de Implemen- Disponibili- Evolução
Requisitos e Testes
l Negócios tação zação II
Design
u
ç
ã
Análise
o Modelo de Implemen- Disponibili- Evolução
Requisitos e Testes
Negócios Design tação zação III
Análise
Modelo de Implemen- Disponibili- Produto
Requisitos e Testes
Negócios Design tação zação Final
Figura 5.2 Ciclo de desenvolvimento iterativo

5.2.1. Definindo uma Iteração

Uma iteração direciona todo um esforço de desenvolvimento em direção a
um release específico – um produto estável, que possui um controle de ver-
são e acompanha todos os outros elementos necessários a sua utilização,
como modificações do banco de dados, migrações de informações, rotinas
de instalação, documentações, entre outros.
Uma iteração é um completo ciclo de desenvolvimento aplicado a uma
pequena fração do produto de software. Uma iteração percorre todos os pro-
cessos envolvidos no decorrer do desenvolvimento, como o gerenciamento de
requerimentos, análise e modelagem, implementação e testes de software. Tra-
ta-se de um pequeno projeto em cascata inserido dentro de um projeto maior.
5.2.2. Definindo um “Release”

Um release pode ser interno ou externo. Um release interno é usado somen-
te pela equipe interna de desenvolvimento como resultado de um ponto de
controle ou para uma demonstração a clientes e usuários. Um release exter-
no é uma versão do produto distribuída para os usuários finais. Um release
não é necessariamente um produto completo, ele pode conter apenas uma
fração das funcionalidades que, teoricamente, deveria contemplar. O release
deve ser produzido em intervalos regulares para “forçar” a equipe de desen-
volvimento a produzir “resultados” concretos. Essas versões parciais são es-
tratégicas para o sucesso do desenvolvimento do software, pois permitirão
aos usuários e clientes experimentarem uma pequena amostra do que virá a
ser o software completo, possibilitando feedback antecipado de eventuais
não-conformidades ou desconfortos gerados pelo produto.
À medida que são realizadas as iterações, serão inseridas novas funciona-
lidades e características ao produto, de forma que o software “cresça” na me-
dida de seu desenvolvimento (incrementos sucessivos). A grande diferença
dessa abordagem é o planejamento cuidadoso de cada iteração, para que
possamos gerar um release funcional pronto a ser distribuído para nossos
clientes e usuários.
5.3. Ciclo de Teste Iterativo

Um processo de desenvolvimento possui muitas iterações. Durante uma
única iteração, vários componentes serão produzidos e alterados, gerando
uma nova versão do componente que deve ser adequadamente testada. Em
cada nova iteração, esse componente sofrerá um novo refinamento, exigin-
do uma nova bateria de testes. Em cada refinamento, novos cenários de tes-

tes vão sendo incorporados e armazenados para que sejam futuramente apli-
cados em futuros estágios do desenvolvimento.
Esses refinamentos implicam contínuos ajustes no planejamento, mo-
delagem, execução dos testes, o que significa que haverá sempre certo ní-
vel de retrabalho toda vez que um componente sofrer uma mudança.
Enquanto os requisitos não se estabilizarem, não haverá possibilidade de
estabilizar os testes.
Iteração 1 Iteração 2 Iteração 3 - Iteração N
Solução X Solução X Solução X Solução X
Tempo
Reaproveitamentos dos
Testes em Novas Funcionalidades
testes em cada nova
Testes em Funcionalidades Anteriores iteração
Figura 5.3 Ciclo de teste iterativo e reaproveitamento dos testes
A abordagem iterativa dá um grande foco para os testes de regressão.

Empregando o exemplo abaixo é possível verificar como os testes podem ser
reaproveitados em cada novo refinamento executado. Na primeira iteração,
apenas uma fração da solução está disponível, sendo necessário um pequeno
esforço de teste para validar suas funcionalidades. Na segunda iteração, o
software ganha novas funcionalidades e parte dos testes é reaproveitada da
primeira iteração. Na terceira iteração o mesmo fato se repete, novas funcio-
nalidades são adicionadas e a maioria dos testes executados na iteração ante-
rior é reaproveitada, seguindo esse ciclo sucessivamente até que os requisi-
tos se estabilizem e a solução receba a última bateria de testes.
O fato de a maior parte dos testes se repetir muitas vezes já compensa o
esforço de automação dos testes. A falta de automação dos testes vai se tor-
nando mais crítica à medida que avançamos no desenvolvimento do softwa-
re e muitas funcionalidades precisam ser testadas. O risco de que as novas al-
terações tenham comprometido as funcionalidades anteriores tende a au-
mentar ainda mais à medida que o software vai se tornando mais complexo.
Definitivamente, a automação de testes é algo crítico para obtermos um pro-
cesso que garanta a qualidade do software desenvolvido.
5.4. Ciclo de Qualidade Iterativa

O processo de qualidade do software deve garantir todo o ciclo de desenvol-
vimento de sistemas. O planejamento da qualidade deve começar junto com
o planejamento do software, ou seja, desde o início do projeto. A modelagem
e a execução das atividades ligadas à garantia da qualidade do software são
tão árduas e complexas quanto as atividades de construção de softwares.
Se esse esforço de qualidade não acontecer de maneira efetiva, um longo
ciclo de desenvolvimento será necessário, e uma fase inteira de “correções
de defeitos” será inserida no cronograma do projeto, dilatando os prazos de
entrega do produto. As atividades de desenvolvimento serão cada vez mais
substituídas por atividades de manutenção de erros, reduzindo a produtivi-
dade da equipe de desenvolvimento.
Somente com a simples aplicação dos testes de verificação nos documentos
gerados em cada iteração planejada no ciclo de desenvolvimento, podemos
identificar uma série de inconsistência nas documentações do produto, possibi-
litando suas correções antes mesmo de executar os testes. Quanto mais cedo
um defeito é descoberto, menor será o impacto no planejamento do projeto.
Cada nova iteração do projeto de desenvolvimento possui seu ciclo inde-
pendente de qualidade, de forma a garantir os objetivos de cada ciclo de de-
senvolvimento. As atividades de qualidade deverão considerar a evolução
incremental da aplicação, sendo necessário reavaliar constantemente a qua-
lidade dos documentos que necessitam ser adequados em relação às mudan-
ças e inovações inseridas em cada ciclo evolutivo.
Necessitamos avaliar se as novas funcionalidades (geradas através de
melhorias ou correções do modelo de negócios) estão sendo adequadamen-
te assimiladas em cada ciclo evolutivo do projeto. É preciso avaliar o impac-
Iteração 1 Iteração 2 Iteração 3 ... Iteração N
Ciclo da Ciclo da Ciclo da Ciclo da

Qualidade Qualidade Qualidade Qualidade
#1 #2 #3 #N
Um Novo Ciclo de
Qualidade em cada nova Tempo
Iteração
Figura 5.4 Ciclo de qualidade iterativa

to e a consistência dos documentos em relação às mudanças inseridas em

cada ciclo, de forma que os novos requisitos não invalidem os requisitos
existentes nos ciclos anteriores.
5.5. Critérios de Finalização

Um dos aspectos mais importantes a serem estabelecidos durante os proce-
dimentos de qualidade é estabelecer os critérios de finalização dessas ativi-
dades, ou seja, determinar quais serão os indicadores que determinarão se
determinado documento, atividade ou software alcançou o nível de qualida-
de desejado.
Os critérios de finalização servirão como uma referência aos grupos de
qualidade para aplicarem os procedimentos e somente darem por encerrada
uma atividade quando esses critérios forem plenamente satisfeitos. É muito
importante estabelecer que, em todas as atividades de qualidade, existirá,
ao menos, um critério de finalização definido.
Para termos uma idéia de como devemos empregar os critérios de finali-
zação, daremos alguns exemplos de aplicação prática desse instrumento:
Tabela 5.2
Critério de finalização para especificação de requisitos funcionais
Especificação de Requisitos Funcionais
Modelo de Casos de Uso
– Todos os casos de usos estão descritos adequadamente.

– Todos os atores possuem nome e descrição.
– Todos os atores que representam sistemas externos devem possuir estereótipo
adequado.
– Todos os casos de usos devem estar rastreados com as necessidades do cliente.
– No caso de existir abreviações nas descrições, todas devem estar presentes no
glossário.
Especificações de Requisitos Funcionais
– Todos os casos de usos possuem especificação funcional.

– Foi identificado o cenário de pré-condição.
– Foi realizado o detalhamento dos cenários alternativos.
– Foi realizado o detalhamento dos cenários de exceção.
– Foi identificado o cenário de pós-condição.
Tabela 5.3
Critério de finalização da inspeção de código
Inspeção de Código
Análise de Complexidade do Código
– Não existir classes de altíssima complexidade no componente.

– Componentes terem até 20% do código com complexidade alta.
– Componentes terem até 60% do código com complexidade média.
Padrões de Nomenclaturas
– Todas as variáveis têm prefixos consistentes.

– Todas as funções têm prefixos consistentes.
– Todas as classes e componentes têm prefixos consistentes.
Tabela 5.4
Critério de finalização dos testes de validação
Testes de Validação Iteração
Validação das Unidades (Caixa Branca) #1 #2 #3 ... #N
– Cobertura em componentes de alta criticidade. 80% 80% 90% ... 100%

– Cobertura em componentes de média criticidade. – 80% 90% ... 100%
– Cobertura em serviços de alta complexidade. 80% 80% 90% ... 100%
Validação das Unidades (Caixa Preta) #1 #2 #3 ... #N
– Cobertura dos requisitos funcionais de alta 100% 100% 100% ... 100%
criticidade.
– Cobertura dos requisitos funcionais. – 40% 50% ... 70%
– Cobertura dos requisitos de segurança. 50% 70% 80% ... 100%
– Cobertura dos requisitos de usabilidade. – 50% 75% ... 100%
Validação das Integrações #1 #2 #3 ... #N
– Testes em componentes que dependam da – 50% 70% ... 100%

classe modificada.
Validação do Sistema (Testes Funcionais) #1 #2 #3 ... #N
– Cobertura dos requisitos funcionais de alta 100% 100% 100% ... 100%
criticidade.
– Cobertura dos requisitos funcionais de média 60% 70% 90% ... 100%
criticidade.
– Cobertura mínima de requisitos funcionais. 50% 60% 80% ... 100%
Tabela 5.4
Critério de finalização dos testes de validação (continuação)
Testes de Validação Iteração
Validação do Sistema (Testes Não Funcionais) #1 #2 #3 ... #N
– Cobertura dos requisitos não funcionais de alta 100% 100% 100% ... 100%
criticidade.
– Cobertura dos requisitos de performance. 50% 70% 85% ... 100%
– Cobertura dos requisitos de configuração. 50% 50% 50% ... 100%
– Cobertura dos requisitos de versionamento. 50% 70% 80% ... 100%
– Cobertura dos requisitos de instalação. – – – ... 100%
Validação do Aceite Formal #1 #2 #3 ... #N
– Executar 100% dos requisitos de alta criticidade. 100% 100% 100% ... 100%
– Executar 20% dos requisitos funcionais. – 20% – ... 20%
– Executar 20% dos requisitos de segurança. 20% 20% 20% ... 20%
– Executar 100% dos requisitos de instalação. – – – ... 100%
CAPÍTULO 6
Por que os Processos

de Qualidade
de Software Fracassam
Muitas tentativas de implantação de processos de qualidade de soft-

wares fracassaram. Isso ocorre porque muitos processos foram distorcidos e
inadequadamente executados, o que gerou grandes frustrações, além de sig-
nificativos prejuízos financeiros.
6.1. Ausência de Gerência de Qualidade Independente

Quando estruturamos uma área de qualidade de software, disponibilizamos
uma infra-estrutura que contempla recursos físicos (máquinas, ferramen-
tas), recursos humanos (especialistas em planejamento e execução dos tes-
tes) e experiências acumuladas (metodologias, técnicas, conhecimento ad-
quiridos). Quanto melhor for o gerenciamento dessa infra-estrutura física,
intelectual e humana, maior serão os benefícios a serem adquiridos em fun-
ção do investimento realizado.
Apesar de todo o investimento realizado na estruturação de ambiente de
testes, aquisição de ferramentas e contratação de profissionais, muitas orga-
nizações não criam uma área de qualidade de software, deixando o gerencia-
mento para outra área já existente. A falta de gerenciamento direto sob essa
estrutura disponibilizada minimizará os benefícios que poderão ser conse-
guidos com um processo de qualidade de software.
Por que os Processos de Qualidade de Software Fracassam
6.2. Ausência de Procedimentos de Testes

Automatizados
Apesar de sabermos que um processo 100% automatizado é difícil de se al-
cançar, devemos investir o máximo que pudermos na automação dos pro-
cessos de testes. Isso porque a utilização de procedimentos manuais durante
o processo de teste não é recomendada, já que se trata de um modelo exte-
nuante e “não confiável“.
Extenuante pelo fato de que todas as vezes que determinada funcionali-
dade é inserida ou modificada, todas as outras funcionalidades devem ser
novamente testadas, o que exige grande esforço de repetição, tornando esta
atividade inviável. Para viabilizar os procedimentos manuais, é necessário
reduzir o volume de cenários a serem retestados, reduzindo o nível de cober-
tura dos testes e, conseqüentemente, aumentando a probabilidade de novos
erros não serem identificados. Isso reflete nos custos e na confiabilidade do
processo.
Não confiável porque faltam garantias reais sobre como o profissional de
testes está operacionalizando tais atividades, não sendo possível garantir
que este seguiu criteriosamente as recomendações estabelecidas no planeja-
mento, empregando todos os cenários existentes, executando a seqüência
correta dos procedimentos de testes, entrando com as informações adequa-
das às condições que estão sendo testadas e, finalmente, conferindo se ocor-
reu o comportamento esperado. As interferências humanas no processo tor-
nam o modelo muito frágil, o que pode desacreditar todo o esforço que está
sendo realizado.
6.3. Qualidade É Sempre Aplicada Tardiamente

no Desenvolvimento
A maioria das organizações que “amadureceram” seus processos de desen-
volvimento ainda insistem em acreditar que os testes devem ocorrer somen-
te após a produção do software ou quando este estiver parcialmente pronto.
Isso equivale a dizer que somente obteremos qualidade na fase posterior ao
desenvolvimento; porém, conforme argumentado nos tópicos anteriores, o
maior volume de erros concentra-se nas fases iniciais de levantamento e mo-
delagem do software. Mesmo que somente apliquemos testes nas fases finais
do projeto, não significa que será dessa forma pelo resto de nossas vidas.
Portanto, inserir os profissionais ligados ao processo de qualidade de
software na equipe de desenvolvimento somente reforça o conceito de quali-
dade como uma única etapa dentro do processo de criação de um software.

Devemos ampliar os conceitos de qualidade e aplicar testes em todos os pon-
tos do processo, tornando o processo de engenharia de software mais con-
trolado e confiável, possibilitando o efetivo gerenciamento do projeto de de-
senvolvimento.
6.4. Ausência de Profissionais Capacitados

em Qualidade de Software
É muito comum observarmos organizações utilizarem seus profissionais de
desenvolvimento para estruturar e organizar processos de qualidade de soft-
ware. Essa falta de especialização afetará a eficiência do processo de garantia
da qualidade de software, podendo comprometer todo o esforço de implan-
tação desses processos na organização.
Muitas vezes, acreditamos que, pelo simples fato de o profissional ter ex-
periência em desenvolvimento, este já está capacitado a desempenhar o pa-
pel de “analista de testes”, porém, é necessário lembrar que esse profissional
tem um paradigma bem diferente do profissional de desenvolvimento.
Enquanto um deve planejar a construção de um software, o outro deve avali-
ar sua solidez.
Profissionais ligados às atividades de qualidade de software (revisores,
auditores, analistas de testes e automatizadores) devem possuir a metodolo-
gia totalmente desenhada para atender seu maior objetivo – encontrar falhas
em todo o ciclo de desenvolvimento do projeto de software. Para isso, esses
profissionais devem direcionar seus esforços em aperfeiçoar essa metodolo-
gia, padronizar as documentações e procedimentos de qualidade e reduzir
os esforços no planejamento e na operacionalização dessas atividades.
O foco da área de desenvolvimento é produzir o software e nunca garan-
tir a qualidade de software. Cabe a essa área compreender todas as exigências
da área de negócios, as disponibilidades e restrições tecnológicas existentes
e as demais características operacionais para que o produto tecnológico
adapte-se o mais perfeitamente possível aos processos que irá suportar. Deve
estar preocupado com uma documentação adequada para garantir que o co-
nhecimento do projeto não permaneça apenas na cabeça de alguns profissi-
onais. Deve atentar à qualidade da solução encontrada, de forma a garantir
um projeto mais flexível e pronto para crescer e suportar mudanças. Deve
oferecer s interface amigável, de forma a proporcionar ao usuário facilidade
de uso e agilidade operacional. Deve acompanhar as evoluções tecnológicas
para manter seu produto sempre “novo” conceitualmente e tecnologica-

mente, oferecendo cada vez mais recursos e facilidades ao usuário final. Pa-
rece que os desenvolvedores – analista de sistemas, administradores de da-
dos, designers e programadores – estão com sua agenda lotada e, portanto,
não possuem tempo para garantir que tudo isso esteja funcionando.
6.5. Falta de um Modelo Corporativo de Qualidade

Esse sintoma está intimamente ligado à ausência direta de uma gerência de
qualidade de software. Sem esse gerenciamento, é comum que cada “projeto
de software” encontre sua forma mais particular e “eficiente” de estruturar um
processo de garantia da qualidade de software. A falta de um modelo corpora-
tivo que discipline esse processo fragiliza qualquer esforço de implantação.
O processo de qualidade deve ser um modelo único que gerencie as di-
versas atividades que ocorrem nos vários ambientes existentes, de forma a
garantir rigorosos processos de qualidade em todas as etapas do desenvolvi-
mento do software. Esse modelo deve contemplar uma gradual assimilação
desses conceitos por parte da organização, sob o risco de não se tornar ope-
racional; portanto, o planejamento corporativo e o treinamento dos profissio-
nais para enraizar e melhor absorver os conceitos que serão exigidos durante
o processo de implantação são chaves, para o sucesso desse processo.
6.6. Foco em Testes Progressivos Aumentam Riscos

Em muitas organizações, as empresas direcionam seus esforços nos chama-
dos testes progressivos. Os testes progressivos somente focalizam as novas
implementações realizadas no software, desconsiderando as funcionalida-
des anteriores.
Essa abordagem é extremamente tentadora, pois reduz drasticamente o
esforço de implementação de um ambiente de testes. Em contrapartida, não
garante que as antigas funcionalidades continuem comportando-se adequa-
damente, existindo alta probabilidade de as novas versões inserirem novos
defeitos e de estes não serem identificados pelos testes de software, aumen-
tando a incidência de erros no ambiente de produção.
6.7. Deficiência no Planejamento dos Testes

O planejamento é um exercício mental que produz uma visão sobre como
resolver um conjunto de situações, antecipando os passos de realização de
um trabalho. Estudamos o problema, analisamos as soluções, operacionali-

zamos uma seqüência de atividades e prevemos eventuais riscos e insuces-
sos. Dessa forma, estaremos nos preparando para o projeto a ser realizado.
Se pensarmos no curto prazo, o planejamento exigirá maior esforço de
trabalho. Maior esforço sempre é sinônimo de maiores custos, maior volu-
me de horas trabalhadas maior número de profissionais envolvidos. No en-
tanto, analisando o ciclo de vida do software e sua expectativa de se manter
ativo por um período de cinco anos, temos que planejar as atividades de for-
ma a reduzir os custos de manter esse ambiente de testes operacional por
todo esse período. Se negligenciarmos o planejamento, além de aumentar as
chances de insucesso na detecção de erros, os custos finais provocados pela
ineficiência e inflexibilidade do modelo serão muito mais altos.
É por isso que um bom planejamento deve ter como objetivo uma visão
de longo prazo, para que esse investimento realizado seja pago no decorrer
dos meses. O planejamento de testes deve valorizar aspectos como reaprove-
itamento de cenários de testes já realizados, mecanismos de reexecução de
testes e conferência de resultados, redução do impacto das mudanças nas
documentações/procedimentos de testes já implementados e redução de es-
forço na manutenção das diversas versões de testes, para cada versão de soft-
ware existente.
6.8. Sob Pressão, os Testes São Sacrificados

Em todos os projetos de desenvolvimento de software é comum encontrar-
mos uma fase dedicada à atividade de teste de software. No cronograma do
projeto, a etapa de testes é descrita como uma fase posterior à codificação do
software, já considerado, nesse momento, um produto acabado.
FASES COM MAIOR CONSUMO DE TEMPO E RECURSOS

Requisitos
Tempo
Figura 6.1 Fases que consomem maior tempo e recursos

no planejamento do software
Por diversas razões, os prazos de entrega de um software são sempre maio-

res do que o planejado e os custos do projeto extrapolam o orçamento inicial.
Com isso, é comum a área de desenvolvimento buscar atalhos, com a finali-
dade de compensar os atrasos e obter um produto tecnológico o mais rapida-
mente possível. Os atalhos serão obtidos da redução de tempo dedicado às
fases que mais consomem recursos do projeto. Esse tempo ganho será dire-
cionado à etapa de codificação do produto final.
Foco do
Projeto
Pressão Pressão

Requisitos

no ciclo de desenvolvimento real
As primeiras etapas sacrificadas são as de modelagem e estruturação da

solução. São fases que, mal feitas, trarão conseqüências diretas na flexibili-
dade e manutenção da aplicação. Sem essas fases, o desenvolvimento passa a
codificar uma solução “pouco pensada”, sem considerar os diversos aspec-
tos de negócio a longo prazo.
Com o atraso já entrando na casa dos meses, é comum a área de desen-
volvimento sacrificar também a etapa dos testes. A fase não é totalmente eli-
minada, porém perde eficiência em sua principal missão – detecção dos er-
ros. A redução de tempo ocorre eliminando a fase de planejamento de testes,
que consome mais da metade do tempo desse processo. Dessa forma, per-
de-se muito na qualidade dos testes finais, deixando processo de testes caó-
tico e falho.
6.9. Ausência de um Ambiente de Testes Isolado

O processo de validação de um software exige um ambiente exclusivo de tes-
tes, isolado de qualquer interferência dos demais ambientes de desenvolvi-
mento e produção. A interferência entre ambientes pode comprometer a
qualidade dos testes, bem como a confiabilidade das informações e proces-
sos executados. Esse isolamento garante que nenhuma atividade externa
prejudicará a execução dos procedimentos de testes, aumentando o nível de
eficiência dos trabalhos. Nesse ambiente, encontramos equipamentos dedi-

cados, ferramentas de testes já instaladas e sistemas parcialmente instalados
com seus respectivos softwares de apoio.
A gestão isolada do ambiente proporciona à área de testes uma auto-
nomia de como e em que momento devemos executar os testes de deter-
minada aplicação. Com isso, em eventuais modificações emergenciais de
uma aplicação, poderemos submeter o software a rigorosos procedimen-
tos de testes sem que exista risco de manipulação ou interferência de ati-
vidades externas, portanto, mesmo que determinados testes sejam exe-
cutados no ambiente de desenvolvimento (planejados e executados pelos
próprios desenvolvedores), outras categorias de testes (com objetivos di-
ferentes) deverão ser processadas no ambiente de testes, com total isola-
mento entre ambos.
6.10. Transferir o Planejamento

ao Analista de Sistemas
Quando o planejamento é feito pelo analista de sistemas e não pelo analista
de testes, uma enorme possibilidade de problemas surge. Temos que ter
em mente que o profissional de testes não é o analista de sistemas, mas sim
o analista de testes. Somente ele tem a percepção e experiência das diversas
categorias de testes existentes, sabe como organizá-los e como empre-
gá-los, propiciando mais eficiência na detecção de erros – que é nosso prin-
cipal objetivo.
O analista de sistemas tem uma tendência natural de produzir testes vá-
lidos, ou seja, aqueles já suportados pela aplicação. Ele sabe o que o sistema
está consistindo e o que não está. Ele já decidiu o que vale a pena tratar den-
tro da aplicação. Dessa forma, ele não tentará submeter o software a condi-
ções que ele tem consciência de que o aplicativo não terá êxito. Com isso,
obteremos um conjunto de testes “viciados”, já que se baseiam em condi-
ções já discutidas no desenvolvimento. Já o analista de testes atua com total
imparcialidade no planejamento e na criação dos cenários para aplicar na va-
lidação do software. Sua missão é criar variações de comportamento no soft-
ware, nas quais apontem situações não previstas pela equipe. Cabe a esse
profissional ir além da percepção do analista de sistemas e planejar testes sob a
mais variadas condições existentes no negócio.
6.11. Dificultar o Acesso do Analista

de Testes ao Software
Quando o analista de testes não possui acesso ao software a ser testado, a
qualidade da compreensão do sistema fica comprometida. O software não é
apenas o objeto de teste, mas também uma importante fonte de informações.
Usando a aplicação, é possível identificar regras de negócio muitas vezes es-
quecidas nas documentações e pelos analistas de sistemas. É comum desco-
brirmos regras de negócio, exercitando ações dos usuários – descobrir que
somente é possível rentabilizar uma carteira de investimentos após o encer-
ramento das transações comerciais; descobrir que os campos obrigatórios
mudam em função do tipo de negociação utilizada; descobrir que somente
após a abertura do caixa é possível realizar as transações financeiras.
O software, além de ampliar a compreensão do negócio, auxilia no pro-
cesso de refinamento e validação do planejamento dos testes. À medida que
o analista de testes estabelece determinados cenários e condições para exe-
cução, é possível verificar se essas informações têm a qualidade necessária a
ser empregada durante a realização dos testes.
CAPÍTULO 7
Benefícios de um Processo
de Qualidade de Software
Qualquer tipo de erro gera custo financeiro à organização. Enquanto o

software não é implantado, os erros identificados ficam restritos ao projeto
como retrabalho, sendo necessário contabilizar os custos de identificação do
problema, remodelagem, recodificação, teste e nova implantação. Quando
esse software já está em produção, os custos de um erro ultrapassam a fron-
teira do projeto e passam a interferir nos resultados financeiros e operacio-
nais das diversas áreas da organização. Nesse caso, devemos incluir no custo
do erro não somente os aspectos diretamente ligados ao projeto, mas tam-
bém os prejuízos financeiro e operacional provocados pelo defeito gerado.
7.1. Torna o Ciclo de Desenvolvimento Confiável

Como os softwares tornaram-se cada dia mais importantes para as organiza-
ções, minimizar os riscos de um erro significa poupar a empresa dos custos
provenientes desse fato. Mesmo sendo impossível atingir o tão esperado
software bug-free, devemos então criar uma estrutura e processos que pro-
porcionem um ambiente favorável e que permita a detecção do maior núme-
ro possível de erros.
Nenhum processo de engenharia de software, por melhor idealizada,
planejada e executada que for, não poderá garantir um software sem erros.
Seguindo esse raciocínio, devemos entender que em todas as aplicações de
software, um conjunto de defeitos está incorporado à aplicação e pronto a se
Benefícios de um Processo de Qualidade de Software
manifestar quando determinado conjunto de situações for combinados,

provocando, assim, uma falha no comportamento esperado do software.
A missão de descobrir defeitos, quando tratada na dimensão e com a im-
portância que realmente lhe cabe, cria consciência e atitudes direcionadas ao
“Zero-defeito”. Tal atitude está voltada à não-proliferação dos erros, ou seja,
uma percepção de que tudo que estamos fazendo pode comprometer a quali-
dade final do software a ser desenvolvido. Tudo que venha a interferir na qua-
lidade final do produto deve ser repensado no contexto “zero-defeito”.
7.2. Garante Ações Corretivas no Ciclo

de Desenvolvimento
Em um projeto de desenvolvimento no qual o processo de garantia da quali-
dade do software não está sendo empregado, os erros são produzidos conti-
nuamente, mas ninguém está administrando sua freqüência, reincidência
ou gravidade. Ninguém está analisando as áreas do software que estão sofren-
do maior incidência de problemas de forma a estudar as origens “reais” dos
problemas – erros são apenas sintomas, devemos localizar as reais causas
dos problemas de desenvolvimento.
A equipe de qualidade, através de um levantamento estatístico referente
aos erros identificados, pode demonstrar os pontos do projeto que apresen-
tam maior incidência de problemas, possibilitando ações corretivas durante
o ciclo de desenvolvimento do software. As ações corretivas têm por objeti-
vo minimizar problemas que estão sendo identificados durante o desenvol-
vimento.
7.3. Evita a Ingerência do Projeto de Software

A ingerência (perda da capacidade de gerenciar) de um projeto de software
ocorre principalmente quando o gerente perde o controle do que está sendo
desenvolvido. Isso ocorre pelo fato de não existir instrumento capaz de ava-
liar se o que está construído tem a qualidade desejada, ou seja, comporta-se
como foi especificado. A ingerência acentua-se à medida que um maior nú-
mero de erros é produzido pelos desenvolvedores, aumentando o número
de retrabalho do grupo. O esforço de desenvolvimento passa a ser lentamen-
te direcionado para a correção de programas que “deixaram de funcionar”
em função das mudanças realizadas. Essas correções e mais as novas imple-
mentações provocam novos erros em programas já desenvolvidos. O senti-
mento da equipe é de crescente desmotivação, pois a constatação de todos é

que os erros se multiplicam sem parar, criando uma sensação de impotência
diante da situação. Toda a equipe está insegura em relação à qualidade do
software, ou seja, ninguém mais está confiante em relação ao prazo de entre-
ga deste.
7.4. Amplia as Chances de Sucesso

do Projeto de Software
Administrar um projeto de desenvolvimento de software para o sucesso sig-
nifica eliminar ou minimizar os riscos e conflitos existentes. Existem diver-
sos fatores que podem contribuir com a qualidade final do produto – profis-
sionais experientes e bem treinados, metodologias e ferramentas adequadas,
participação constante dos usuários finais, bom entendimento do problema
e modelagem da solução flexível em longo prazo.
Isoladamente, um perfeito processo de garantia da qualidade de software
não garante sucesso ao projeto de desenvolvimento de um software, uma
vez que este não ataca todos os possíveis riscos inerentes de um projeto; po-
rém, um bom processo de qualidade minimiza diversos pontos críticos de
um projeto de desenvolvimento de um software – identifica prematuramen-
te erros em documentos e análises realizadas, garante que cada fase do de-
senvolvimento produziu os documentos obrigatórios e que estes foram ade-
quadamente revisados pelas áreas responsáveis, garante o comportamento
do software nas diversas condições existentes, monitora seu comportamen-
to sob condições extremas de acesso, mantém o software em situações de
contingência e cenários de exceção.
Torna-se verdadeiro afirmar que o processo de qualidade amplia as
chances de sucesso de um projeto de desenvolvimento porque agrega ao
software confiabilidade, fator fundamental para o sucesso de um projeto.
7.5. Amplia a Produtividade do Desenvolvimento

A primeira impressão é a de que, quanto mais pessoas direcionam seus esfor-
ços na produção de um software, mais rapidamente teremos uma solução
tecnológica disponível e mais cedo estaremos nos beneficiando desse inves-
timento; portanto, ampliar o número de desenvolvedores significa aumen-
tar a capacidade de produção da equipe, possibilitando encurtar prazos e ob-
ter mais rapidamente o resultado esperado. Mas isso não é verdade absoluta.
Estudos demonstram que a desorganização se amplia à medida que coloca-

mos mais pessoas para interagir em um ambiente caótico. O que devemos é
melhorar a qualidade desse trabalho e, somente assim, em um acrescentar
novos recursos direcionados ao desenvolvimento do projeto.
7.5.1. Fator Desorganização

Todo projeto tecnológico tem seus níveis de desorganização: uns são mais
acentuados, outros menos. A desorganização reflete o número de erros ge-
rados e o quanto este se propagou nas fases do projeto. Quanto maior o nú-
mero de erros e maior a propagação destes, maior será o nível de desorgani-
zação do projeto estudado. A desorganização reflete a produtividade da
equipe de desenvolvimento e, conseqüentemente, os retrabalhos do proje-
to tecnológico.
Processos Deficientes
Informalidade nas Decisões
Falta de Qualidade do Produto

Falta de Planejamento
Ferramentas Inadequadas
Complexidade do Negócio Desorganização
Pouca Comunicação
Complexidade Tecnológica
Figura 7.1 Fatores que contribuem para a desorganização de um projeto
A entrada de um novo profissional em um projeto altamente desorgani-

zado (altos índices de erros) deve ser encarada de forma positiva caso esse
profissional seja direcionado a atividades deficientes do projeto, contribuin-
do na redução do nível de “desorganização”, refletindo imediatamente em
menos erros, menor índice de retrabalho e, conseqüentemente, maior pro-
dutividade da equipe como um todo, do contrário, a entrada desse profissio-
nal somente aumentará o nível de desorganização do projeto.
7.5.2. Fator Retrabalho

O fator retrabalho está intimamente ligado ao fator desorganização. É comum
encontrarmos projetos de software que parecem nunca conseguir atingir um
nível básico de funcionalidade. Os prazos são ampliados, as equipes aumenta-
das, mais recursos financeiros são direcionados ao projeto, porém não se con-
segue reverter o quadro caótico. Trata-se de uma equipe que apesar de aumen-
tar o número de profissionais dedicados ao projeto, não conseguiu aumentar
sua produtividade. Parece que esse cenário não é tão incomum assim.
Podemos explicar isso da seguinte forma. Uma equipe tem sua produti-
vidade prejudicada quando o nível de retrabalho é muito alto. O retrabalho
tira os profissionais da atividade de produzir “algo novo” pela atividade de
“corrigir algo defeituoso”. Cada novo desenvolvedor potencializa o nível de
desorganização, trazendo mais “retrabalho” ao projeto. Será mais um profis-
sional gerando erros em seu próprio código e nos códigos de seus colegas.
Será mais alguém participando do desenvolvimento, ampliando as dificul-
dades de comunicação da equipe e direcionamento de um objetivo comum.
Em um determinado momento, iremos perceber que o projeto tem a maior
parte de seus recursos direcionados a “fazer o que já foi feito”. Para o cliente
final, trata-se de um projeto sem fim, sem prazo determinado para acabar.
Nível de
Retrabalho Demonstra alto índice
de desorganização
4 x Mais
3 x Mais
Demonstra médio índice
de desorganização
2 x Mais
Demonstra baixo índice
de desorganização
1 x Mais
Número de
Profissionais
1 3 5 7 9 Alocados no Projeto
Figura 7.2 Influência da desorganização no nível de retrabalho
Através do gráfico, fica fácil entender que apenas incluir novos profissio-
nais não resolve o problema da produtividade do projeto. É necessário in-
vestir em recursos que melhorem a qualidade do processo de desenvolvi-
mento, reduzindo a desorganização. Uma equipe de qualidade elevará o ní-
vel de produtividade do processo de desenvolvimento, garantindo melhor
aproveitamento dos recursos já existentes.
7.6. Evitam a Propagação de Erros

Um dos maiores benefícios que os testes agregam a um projeto de software é
o fato de existir um processo de qualidade de software que garanta a “regres-
sividade” de uma aplicação – ou seja, garanta que a manutenção ocorrida na
aplicação não afetou o comportamento das outras funcionalidades. Mesmo
um sistema em produção, que roda diariamente de forma segura, pode ter
suas funcionalidades comprometidas caso necessite de pequena alteração
para se adequar a uma nova condição de negócio. Sem um processo de testes
regressivos, os testes se concentrarão nas partes do software que sofreram as
mais recentes modificações (testes progressivos), descartando qualquer
possibilidade de essas mudanças propagarem erros para outros módulos.
Trata-se de uma situação muito comum do dia-a-dia dos desenvolvedores.
Fato 1
Módulo A Módulo B
O programa do
Módulo A foi
modificado com a
intenção de adaptar
o aplicativo às novas
regras financeiras.
Fato 3
Porém, um programa do
Fato 2 Módulo C Módulo B apresenta
Como precaução, o dependência direta com o
Módulo A foi programa modificado.
totalmente testado.
Infelizmente, o erro já foi
propagado e agora está em
produção.
Figura 7.3 Exemplo de propagação de erros durante uma mudança
7.7. Automação de Testes Reduz Custos do Projeto

Automação de testes é a utilização de ferramentas de testes que simulem
usuários ou atividades humanas de forma a não empregar procedimentos
manuais no processo de execução dos testes. Requer profissionais especiali-
zados, exigindo mais detalhes no planejamento e tempo adicional para o de-
senvolvimento e automação dos testes.
A automação dos testes é altamente desejada por diversos fatores, inclu-
sive em termos de custos finais. Como esse processo requer um investimen-
to inicial, a automação passa a ser encarada como mais um trabalho a ser rea-
lizado. À medida que reexecutamos os testes, o ganho de tempo, controle,
confiabilidade e as diversas possibilidades existentes com essa tecnologia,
fica clara a vantagem inerente a esse processo.
Esta tabela, extraída do The Newsletter of the Quality Assurance (1995),
demonstra um estudo, que envolve 1.750 casos de testes e 700 defeitos exis-
tentes. Nesse estudo fica evidente que processos de testes baseados em ferra-
mentas de automação são mais econômicos, rápidos e eficientes do que os
processos manuais de testes.
Tabela 7.1
Comparativo entre testes manuais e automatizados
Etapas dos Testes Teste Teste Melhoria

Manual Automatizado (%)
Planejamento 32 40 -25%
Definição dos Casos de Testes 262 117 55%
Execução dos Testes 466 23 95%
Conferência dos Testes 117 58 50%
Gerenciamento do Erro 117 23 80%
Relatórios Finais 96 16 83%
Duração Total (em Horas) 1.090 277 75%
CAPÍTULO 8
Entendendo os
Testes de Verificação
Quando uma organização não possui um processo formal de testes de

verificação, muitas fases de um projeto são encerradas sem que determina-
dos pontos tenham sido totalmente “estressados” ou mesmo levantados. São
buracos que ganharão dimensões enormes à medida que o projeto avança
em suas novas fases. Somente quando parte do produto estiver disponível é
que esses “pontos não analisados” serão novamente pauta de discussões,
provocando reestruturações no projeto e inevitáveis retrabalhos.
Portanto, é missão dos testes de verificação avaliar se toda a documentação
gerada e todas as atividades que estão sendo desempenhadas são conduzidas
adequadamente, gerando um modelo de software aderente às necessidades dos
clientes, pautadas em definições claras, com regras e objetivos compreendidos
por todos os grupos que estão participando do ciclo de desenvolvimento. Esses
testes avaliam a qualidade de todo o processo que está suportando o projeto de
software, validando se todas as documentações e atividades geradas estão den-
tro de um padrão desejável, reduzindo os riscos de falhas de interpretação que
seriam inseridas no produto de software no momento de sua construção.
8.1. Estruturando um Processo Sistemático

de Verificações
Na maioria das organizações de software, existem aplicações práticas dos
conceitos que envolvem os chamados testes de verificação, que focalizam
as documentações e atividades executadas durante as etapas do ciclo de

desenvolvimento; porém, o que observamos é que essas organizações mi-
nimizam a importância desse tipo de atividade, aplicando os conceitos
apenas em alguns poucos documentos produzidos durante o ciclo de de-
senvolvimento.
Além de um escopo reduzido, essas atividades são realizadas sem qual-
quer planejamento e formalização, sendo opcional a presença de pesso-
as-chave para avaliar os levantamentos e decisões registradas nas documen-
tações. Os testes de verificação devem ser sistematizados, planejados e devi-
damente aplicados, de forma a se tornarem parte integrante do processo de
engenharia de software, e conduzidos por uma equipe independente da área
de desenvolvimento (preferencialmente pela área de Garantia da Qualidade
do Software), de forma a garantir maior eficiência e nível adequado de pro-
fundidade nesses trabalhos. Se esse processo estiver nas mãos de profissio-
nais de desenvolvimento, será pouco eficiente na detecção de defeitos, sen-
do as reuniões simplesmente informativas. Uma área independente condu-
zirá esse processo com total autonomia, sendo mediador entre o cliente
(aquele que necessita das informações documentadas com um alto nível de
qualidade) e o fornecedor (aquele que gerou a documentação e tem outras
mil coisas pendentes para fazer).
Muitas pesquisas afirmam que o simples hábito de realizar revisões já ga-
rante um alto nível de detecção de defeitos, porém, é fato que esse número
pode ser muito mais expressivo se estabelecermos a sistematização e o pla-
nejamento desses trabalhos. Assim, a verificação feita de forma estruturada,
com objetivos bem definidos, período estipulado e a participação de pessoas
com visões diferentes do problema tende a ser mais efetiva do que um sim-
ples processo de revisão casual.
8.2. Aumentando a Eficiência das Verificações

Inspeções e revisões técnicas são termos comuns e bem familiares à maioria
das pessoas. Isso porque não é incomum encontramos organizações que
aplicam essas técnicas dentro de seu processo de desenvolvimento de soft-
ware. Dessa forma, a primeira impressão é acreditarmos que esses métodos
não são muito eficientes nem adequados para detecção de problemas, uma
vez que essas mesmas organizações são grandes fábricas de erros. Então,
onde está o problema com esses procedimentos de inspeção que deixam pas-
sar tantos furos nas definições e soluções encontradas?
Entendendo os Testes de Verificação
O problema está em como tais atividades estão sendo realizadas. Não

devemos somente realizar a tarefa, mas fazê-la da forma mais adequada
possível. As verificações devem obedecer a regras para que todos os obje-
tivos das reuniões sejam alcançados, todos os profissionais tenham a
oportunidade de participar e que todos os pontos a serem discutidos te-
nham sido adequadamente esgotados pelos revisores. Essas regras per-
mitirão maior eficiência dos trabalhos de verificação, pois disciplinam
tais atividades. Somente dessa forma, as atividades de verificação passa-
rão a ser um instrumento fundamental na detecção de erros do processo
de desenvolvimento de software.
8.2.1. Profundidade das Análises e Discussões

Quando as organizações aplicam inspeções e revisões técnicas estão, na
maioria das vezes, em busca de erros de padronização, ou seja, verificando
se os documentos e atividades estão sendo feitos dentro de um modelo es-
tabelecido. Apesar de isso ser importante, faz com que o revisor permaneça
na superfície do problema. O revisor não somente tem que examinar se os
documentos foram gerados na cor, tamanho e nomenclaturas desejados,
mas se estes estão coerentes, possuem nomes e definições claras, se suas es-
truturas estão bem definidas e flexíveis, e até avaliar se não existia um jeito
mais simples e fácil de alcançar o mesmo produto final. Dessa forma, uma
peça burocrática do processo torna-se um elemento que agrega mais valor
ao produto final.
8.2.2. Uniformidade das Atividades

Outro fator importante é como individualmente cada revisor está conduzin-
do seus trabalhos. Caso não existam regras claras do que deve ser ou não
analisado, cada revisor encontrará um jeito próprio de abordar o problema e
focalizar no que este acredita ser fundamental. Estruturar os trabalhos do
revisor e treiná-los adequadamente são tarefas fundamentais ao sucesso des-
sas atividades.
A utilização de checklists auxilia na uniformização e padronização do
que será avaliado e dos padrões esperados em cada documentação. Esse ins-
trumento orienta os trabalhos dos revisores e possibilita uma forma única de
abordar os documentos e atividades a serem auditadas.
8.2.3. Continuidade e Freqüência

É comum que as atividades de verificação somente ocorram nos estágios ini-
ciais do projeto, pois são as fases em que é gerado o maior número de docu-
mentos e registros de informações. No entanto, é natural que o projeto sofra
a inserção de melhorias ou mesmo uma reestruturação de aspectos funda-
mentais do negócio, de modo a interferir nas estruturas e definições estabe-
lecidas. Isso significa que os projetos estão sendo modificados sem que ocor-
ra uma nova onda de revisões com o objetivo de avaliar se o que está sendo
proposto está coerente e que todos os impactos da mudança estejam bem
claros a todas as áreas envolvidas. As atividades de verificação devem ser
executadas sempre que o projeto sofrer mudanças, de forma a manter a inte-
gridade das documentações e, conseqüentemente, garantir que todas as de-
cisões tomadas sejam devidamente analisadas e compartilhadas pelas áreas
interessadas.
8.2.4. Revisores Experientes

Os revisores devem ser profissionais experientes que possuam afinidade
com os documentos e materiais que estão sendo colocados em discussão. Se
a verificação for aplicada a documentos que retratam o domínio do proble-
ma, os revisores devem conhecer a fundo as características do negócio para
poder confrontar o documento com as definições nele estabelecidas. Se o
documento retratar a arquitetura da aplicação, os revisores devem conhecer
profundamente as tecnologias envolvidas e os impactos gerados pela esco-
lha de determinada configuração de softwares e hardwares.
As reuniões de verificações de documentos podem ser uma excelente es-
cola para profissionais que necessitam assimilar um conhecimento específi-
co sobre um determinado assunto do projeto de software, porém, devemos
ter claro que profissionais inexperientes contribuem muito pouco para as
atividades de verificação. Devemos considerar que o maior objetivo das revi-
sões é possibilitar a identificação de erros e que o processo de capacitação e
aprendizado deve ser visto como um ganho secundário.
8.2.4. Presença de um Moderador nas Reuniões

Se estamos dispondo de tempo e recursos para revisar as documentações ge-
radas durante o processo de desenvolvimento, devemos garantir que esse es-
forço está sendo adequadamente utilizado. A presença de um moderador
torna as reuniões mais produtivas, uma vez que sua principal missão é man-
ter o processo dentro do foco e dos propósitos da reunião.
O moderador não deveria ter a responsabilidade de revisar os documentos,
sob pena de prejudicar seu desempenho como condutor das reuniões. Sua atri-
buição é garantir que todos os pontos estão recebendo a devida atenção por to-
dos os participantes e propiciar aos revisores iguais oportunidades de expor
seus pensamentos e comentários. Bons moderadores ampliam as chances de su-
cesso das revisões, pois aumentam as incidências de detecção de problemas.
8.2.6. Revisões Curtas e Bem Focadas

As revisões são mais efetivas quando são curtas e bem direcionadas. Quanto
mais longas as reuniões, maior será a dispersão dos revisores, uma vez que
serão introduzidos muito mais tópicos para revisar. As revisões deveriam
durar por volta de duas horas e ter um conjunto de assuntos reduzidos e re-
lacionados. Isto facilita o trabalho do grupo de revisores, auxiliando-os na
condução dos trabalhos. Se um documento for muito longo, é recomendável
dividir a revisão em várias sessões, com foco bem reduzido. Isso permitirá ao
processo de verificação ser muito mais efetivo.
8.2.7. Identificar Problemas, Não Resolvê-los

Uma das razões para que as revisões falhem em sua intenção de encontrar pro-
blemas e inconsistências nos documentos é o fato de os participantes estende-
ram suas discussões não somente para o problema, mas para sua resolução. A
resolução de um problema requer investigação, análise e reflexão detalhada, o
que não é possível durante uma reunião de revisão. Quando um problema é
identificado, devemos estabelecer quem irá estudá-lo e corrigi-lo. A revisão
deverá estar focada em identificar os problemas, não em resolvê-los.
Se determinado problema requerer discussão mais profunda, uma nova
reunião deverá ser marcada para a discussão desse ponto. Isso permitirá aos
participantes terem um tempo para refletir e analisar alguns aspectos que
não estavam suficientemente claros. O mais importante é fazer com que as
reuniões tenham ritmo e não fiquem presas a determinados assuntos.
8.2.8. Concluir as Revisões

Em processos de verificação pouco formais, é comum que após a execução
de revisões nenhum documento seja gerado. Quando isso ocorre, perdemos
parte da história das decisões do projeto de desenvolvimento. Isso porque

um documento mostra a situação final, mas não apresenta a justificativa de
tais definições ou soluções terem sido apresentadas. É muito comum que
decisões tomadas no passado sejam novamente contestadas no futuro, o que
requer documentação que justifique determinadas decisões. O relatório de
conclusão das verificações deve estabelecer os motivos da mudança de deci-
sões e definições dos documentos, exatamente para podermos justificá-los e
rastreá-los no futuro.
8.3. Papéis Existentes em uma Reunião de Verificação

Durante a execução das reuniões de verificações, diversos papéis deverão
ser aplicados para o adequado desempenho das atividades. Cada profissio-
nal deverá ter consciência do papel que está desempenhando, quais são
seus objetivos e seus limites. Deverão entender que a reunião somente terá
êxito se cada profissional desempenhar adequadamente o papel o qual foi
designado.
8.3.1. Moderador
O moderador tem por objetivo fazer cumprir a agenda estabelecida na
reunião. Deve manter os revisores dentro do tópico em discussão, evitan-
do desvios na condução dos trabalhos. O moderador deve trazer as discus-
sões paralelas para o grupo e possibilitar a todos participar igualmente
dos debates. Preferencialmente, deve ser um profissional da área de qua-
lidade.
8.3.2. Escrivão
O escrivão mantém registrados todos os pontos de discussão e documenta as
ações estabelecidas pelo grupo para posterior execução. Um escrivão não
poderá assumir a tarefa de revisar os documentos, sob pena de falhar nos re-
gistros enquanto está participando de discussões sobre o documento. Ape-
sar de ser sempre colocado em segundo plano, o escrivão exerce um impor-
tante papel nas reuniões. Ele cuidará da memória da reunião, registrando os
pontos discutidos, as divergências e decisões tomadas pelo grupo, que serão
resgatadas no futuro, caso haja falhas detectadas nas próximas etapas do de-
senvolvimento.
8.3.3. Autor
O autor é o criador do documento a ser revisado. O autor deve explicar o
documento e fornecer informações fundamentais à compreensão do con-
teúdo do material (caso o documento não seja auto-explicativo, isto já in-
dica a necessidade de melhoria). Um aspecto importante é não focar as dis-
cussões no autor, mas sim no documento. Isso significa que o autor so-
mente inicia o processo de discussão, dando uma rápida visão e explana-
ção sobre o documento, responder questionamentos quando solicitado e
esclarecer dúvidas dos revisores. Além disso, ele apenas acompanha os tra-
balhos de revisão.
8.3.4. Revisor
São os profissionais que estarão única e exclusivamente voltados para a dis-
cussão do documento e identificação de problemas. Os revisores deverão
respeitar as regras da reunião e a condução dos trabalhos pelo moderador.
Deverão evitar debater assuntos que não estão na agenda da reunião e se es-
quivar de discussões paralelas. Devem focar o entendimento e a melhoria do
documento, não a discussão propriamente dita.
CAPÍTULO 9
Métodos Estruturados
de Verificação
Os testes de verificação devem garantir a qualidade de todas as etapas do

desenvolvimento de sistemas. A qualidade será obtida através da correta
construção de documentos e a adequada realização das atividades previstas
no processo corporativo de engenharia de software. Portanto, os testes de
verificação devem concentrar-se em dois aspectos bem distintos: as ativida-
des de verificação que focalizam as documentações, as chamadas revisões, e
as que avaliam as atividades, as chamadas auditorias. As duas situações são
consideradas métodos estruturados, pois possuem planejamento, regras de
condução e necessitam de profissionais qualificados para desempenhar es-
sas funções e acompanhar seu progresso.
Revisões Foco nas Documentações
Qualidade
do
Processo de
Auditorias Foco nas Atividades
Software
Figura 9.1 Métodos estruturados de verificação

Métodos Estruturados de Verificação
9.1. Revisões
A revisão é um processo “humano” de análise de determinado documento.
Esse processo requer pessoas adequadamente treinadas para desempenhar
seus papéis durante a condução das atividades de verificação. Existem mui-
tas formas de organizar as sessões de revisões, sendo que cada uma delas
possui suas características e particularidades. Para cada fase do processo
de criação de documentos poderemos aplicar um tipo diferente de revisão:
na fase de elaboração inicial do documento, poderemos aplicar a revisão
isolada, cujo objetivo é fazer validações parciais do documento. Na fase de
validação do documento poderemos aplicar a revisão formal, cujo objeti-
vo é validar o documento finalizado com todos os grupos interessados. Na
fase de divulgação, poderemos aplicar as reuniões de acompanhamento,
cujo objetivo é garantir a leitura do documento por todas as pessoas-chave
envolvidas.
Criação Validação Divulgação
Irtoprçl
hkhg
][gfg~f
Irtoprçl
hkhg
Moderador çlkçj Autor Irtoprçl
hkhg
Autor ][gfg~f ][gfg~f
çlkçj Documento çlkçj
Documento Documento
Revisor
Grupo de Autor Grupo de
Revisão Acompanhamento
Revisão Revisão Reunião de
Isolada Formal Acompanhamento
Figura 9.2 Fases de criação de documentos e respectivos tipos de revisões
9.1.1. Revisões Isoladas

Esse é um método de verificação pouco explorado mas muito eficiente na
detecção prematura de erros de definições e soluções registradas. Trata-se
de uma verificação individual do material produzido, executada por alguém
diferente do autor, que tem por objetivo revisar e identificar o maior número
possível de problemas.
A idéia aqui é antecipar a revisão dos documentos com entregas de ver-
sões ainda não acabadas, para que sofra análise e julgamento sobre os tópi-
cos já abordados. Isso possibilita correções nos documentos durante sua
fase de concepção.
Essas revisões permitem o contato antecipado dos revisores com as do-

cumentações que estão sendo geradas, o que auxilia na familiaridade com o
formato de como determinadas regras estão sendo organizadas e registradas.
O grande cuidado que devemos tomar aqui é para que as revisões não
ocorram apenas de forma unilateral. Como a ação dos revisores será isolada,
poderá um único revisor propor mudanças que prejudiquem uma visão in-
tegrada do problema. Como o autor pode ter essa visão de conjunto mais
apurada, o revisor pode interpretar a negativa de mudanças como uma im-
posição do autor a alterações em seu trabalho.
Nesse caso, o autor deverá fazer uma rápida reunião para decidir qual ca-
minho trilhar. Se essas situações tornarem-se muito recorrentes, as ações de
revisões isoladas podem prejudicar o andamento de concepção do documen-
to, atrasando os trabalhos. Isso indica que as áreas envolvidas não estão com-
preendendo a extensão dos problemas que estão sendo abordados. Neste
caso, o melhor a fazer é propor uma reunião na qual seja explicado o propósito
dos trabalhos para todo o grupo de revisores, de forma a não permanecerem
dúvidas estruturais em relação à solução que está sendo documentada.
Outro grande problema aqui é a chamada “revisão superficial” dos docu-
mentos. Isso ocorre quando o revisor não está preparado para interpretar o
documento ou tem pouca iniciativa para realizar sugestões ou mesmo críti-
cas. A tendência neste caso seria apenas uma revisão superficial do docu-
mento, como erros gramaticais e sugestões estéticas, não sendo analisado o
conteúdo das decisões apontadas, dando um falso parecer de qualidade so-
bre o documento. Quando executadas nesse formato, essas revisões serão
pouco eficientes e detectarão poucos erros.
9.1.2. Revisões Formais

As revisões formais são as mais efetivas e bem estruturadas técnicas existen-
tes de verificação. Baseiam-se em reuniões com um grupo de profissionais
responsáveis em identificar falhas presentes em documentos gerados nas di-
versas etapas do desenvolvimento. A identificação de erros é obtida através
da análise e discussão de tópicos presentes na documentação.
As revisões têm regras próprias que devem ser respeitadas, objetivando o
maior sucesso da condução desses trabalhos, que visam à identificação do
maior número possível de erros nas documentações.
O autor do documento estará presente somente para responder às dúvi-
das e eventuais questões levantadas pelos revisores, não podendo conduzir a
reunião. Assim, evitamos que o autor desvie de assuntos complicados e omi-

ta trechos da documentação que não estão adequadamente finalizados. Com
a participação limitada do autor, o documento poderá ser analisado de uma
perspectiva diferente, possibilitando identificar de imediato potenciais in-
terpretações equivocados sobre um determinado assunto.
Todos os participantes devem ter estudado e ter afinidade com o docu-
mento e assuntos tratados por este. Dessa forma, cada participante deve, in-
dividualmente, preparar-se para coletar o maior número possível de infor-
mações antes da referida reunião. Os profissionais envolvidos nesse proces-
so devem ter experiências e conhecimentos diferentes, para que todas as de-
cisões sejam analisadas por diversos ângulos, aumentando o nível de análise
de cada tópico a ser discutido, uma vez que possuem uma perspectiva dife-
rente dos autores dos documentos. Assim, suas contribuições serão funda-
mentais para o aperfeiçoamento da solução.
Após a execução das reuniões de revisão, é fundamental documentar
tudo que foi discutido, os principais problemas detectados, suas correções e
as sugestões de melhoria a serem executadas. Esse material deverá ser pro-
duzido pela equipe de garantia da qualidade de software que deverá apresen-
tá-lo aos autores dos documentos. Os autores realizarão as mudanças e irão
produzir uma nova versão da documentação, que deverá ser submetida a
uma nova revisão, porém com um enfoque somente nos pontos modificados
(lembre-se de que a primeira revisão apenas apontou imprecisões que deve-
riam ser corrigidas e essa nova revisão necessita avaliar se tais mudanças eli-
minaram os defeitos anteriormente apontados).
9.1.3. Reuniões de Acompanhamento

Essa forma de verificação é menos formal do que as reuniões de revisão, uma
vez que não necessita de uma adequada preparação por parte dos participan-
tes. Somente o apresentador (que é o autor do documento) prepara-se para a
reunião, enquanto que os demais participantes simplesmente comparecem.
O objetivo maior dessas reuniões é tornar o documento e o discurso familiar
a todos os participantes, enquanto a detecção de erros torna-se uma preocu-
pação secundária.
As reuniões de acompanhamento são interessantes porque permitem en-
volver um número maior de pessoas do que nas reuniões de inspeção, permitin-
do que mais pessoas envolvam-se na dinâmica do ciclo de desenvolvimento do
software e, conseqüentemente, possuam mais colaboradores nesse processo.
Esses tipos de reuniões são, invariavelmente, menos eficientes do que as

inspeções em termos de detecção de problemas. Isso ocorre pelo despreparo
dos participantes e também pelo fato de ser o autor do documento quem
conduz a dinâmica da reunião, sendo comum que determinados assuntos
sejam estrategicamente não citados para que exista um sentimento de que
tudo está indo muito bem. Essas reuniões devem substituir, com vantagens,
as famosas “coletas de assinaturas”, que não incentivam os profissionais a
debaterem as decisões registradas nos documentos.
Uma forma eficiente de conduzir essas reuniões é distribuindo o mate-
rial a todos os participantes para que todos possam analisar as documenta-
ções em questão. Será agendada uma reunião na qual todos poderão debater
dúvidas e divergências existentes e, somente no final desta, caso exista um
consenso em relação à condução dos trabalhos e as decisões tomadas, é que
efetivamente será realizada a coleta de assinaturas. Para a adequada efetivi-
dade desse método de verificação, todos que são afetados por aquelas docu-
mentações deveriam estar presentes na lista de assinaturas do documento e
comparecer à reunião.
Isso evitaria o chamado efeito retardado: mudar as coisas depois que
determinados assuntos já foram encerrados simplesmente porque alguns
profissionais não interpretaram adequadamente todas as decisões registra-
das nos documentos e mesmo assim o assinaram. Na “coleta de assinatu-
ras” é muito comum as pessoas não lerem adequadamente o material dis-
ponibilizado.
9.2. Auditorias
As auditorias concentram-se nas atividades críticas de um processo de enge-
nharia de software. O principal objetivo das auditorias de qualidade é avaliar
se em determinado projeto as diversas equipes estão respeitando o processo
de desenvolvimento, se estão registrando os defeitos encontrados, se estão
produzindo as atas de reuniões, se estão realizando as reuniões de revisões,
se estão realizando as documentações obrigatórias, se estão envolvendo cli-
entes e usuários nos processos e se estão atualizando continuamente o mapa
de riscos dos projetos. Enfim, os auditores da qualidade são os grandes
“guardiões do processo”.
Esses profissionais devem estar muito atentos às chamadas “quebras de
processos”, muito comuns em projetos de desenvolvimento de software. As
quebras são muito freqüentes em organizações que não possuem etapas bem
definidas e ainda estão dando os primeiros passos na criação de um processo

corporativo de desenvolvimento de software.
O comportamento de “desrespeitar o processo” é sempre justificado pe-
los profissionais que estão atuando em projetos de software com a argumen-
tação de que estes são diferentes dos demais e determinados procedimentos,
documentos e controles são desnecessários. É verdade que as atuais meto-
dologias pregam que os processos de software devem adequar-se a determi-
nadas categorias de sistemas, exigindo uma flexibilidade dos processos em
atender níveis de exigências diferentes em cada situação. Apesar de essa afir-
mação ser correta, devemos ter cuidado com essa linha de argumentação,
pois cada equipe tenderá a definir o que é importante e fundamental em um
projeto de software, estabelecendo quais documentos e procedimentos de-
vem ser realizados, criando uma verdadeira confusão metodológica. Somen-
te um grupo que represente o modelo corporativo de desenvolvimento po-
derá estabelecer as regras do processo de engenharia de software.
Um trabalho de base corrigirá essa falta de processos corporativos. Será
necessária a existência de uma equipe de profissionais, preferencialmente a
equipe de processos de engenharia de software – SEPG (Software Enginee-
ring Process Group), para estabelecer o conjunto mínimo de controles e do-
cumentações que deverá ser obrigatório a todos os projetos, e quais catego-
rias de sistemas deverão apresentar controles e procedimentos adicionais.
Caso isso não aconteça, os auditores de qualidade não terão parâmetros para
conduzir seus trabalhos.
9.3. Aplicando o Processo de Verificação

Como vimos, existem várias abordagens que podemos aplicar para a realiza-
ção efetiva de um processo de verificação de documentos ou mesmo de vali-
dação de atividades executadas em determinadas etapas do ciclo de desen-
volvimento. Aqui estabelecemos um conjunto de procedimentos e regras
que auxiliarão as equipes de qualidade na prática e condução dessas revi-
sões, ampliando as chances de identificação prematura de erros de levanta-
mento e das decisões.
9.3.1. Planejando as Reuniões de Verificação

Uma das primeiras decisões a serem consideradas no planejamento das veri-
ficações é estabelecer o alvo dos trabalhos e definir o grupo que participará
das atividades a serem realizadas. Todos os membros do grupo devem ser

orientados em relação às regras e objetivos a serem alcançados com as ativi-
dades de verificação.
É recomendável que esse grupo seja heterogêneo, com profissionais de
diferentes áreas, habilidades e especialidades, permitindo que as análises e
discussões sejam aplicadas sobre várias perspectivas diferentes, garantindo
uma revisão do documento sob as várias dimensões do problema.
No planejamento dos trabalhos deverá ser considerado o número de
profissionais que desempenharão os papéis de revisores dos documentos. O
dimensionamento será em função da complexidade, importância e impacto
que esse documento poderá trazer a determinadas áreas da empresa. Poucos
revisores deixam o processo pouco eficiente, pois teremos pouca diversida-
de de opiniões e, conseqüentemente, poucos elementos que subsidiarão a
equipe para decidir se determinado documento está adequado ou não. Em
contrapartida, muitos revisores poderão deixar as reuniões longas e pouco
produtivas, reduzindo a eficiência das atividades de revisões. Muitos profis-
sionais geram um excesso de divergência de opiniões que resultam em mui-
tas discussões e poucas conclusões, o que deve ser evitado. Um número ade-
quado de revisores gira em torno de quatro a sete profissionais.
9.3.2. Preparando os Profissionais

Feito o planejamento adequado das reuniões, é necessário preparar os parti-
cipantes para que recebam o máximo de informações possíveis sobre o tema
a ser discutido na reunião. Cabe aos profissionais que estão organizando as
reuniões estruturar uma fonte de informações que possibilite agregar co-
nhecimento a todos que estarão participando do processo.
O acesso à documentação que será alvo das revisões também é estraté-
gico para o sucesso dessas atividades. Antes de executarmos as revisões,
devemos distribuir os documentos a todos os participantes, dando opor-
tunidade a todos de lerem os materiais e assimilar todos os tópicos a se-
rem discutidos.
Durante esse período de distribuição, os revisores devem estudar os do-
cumentos e realizar diversos questionamentos referentes à falta de entendi-
mento, ausência de exemplos ou comentários, à falta de estudos comproba-
tórios, entre outros pontos. Uma semana é um prazo adequado para um con-
veniente estudo das documentações, sendo possível estender por algumas
semanas, dependendo da carga de serviços e do volume do material.
9.3.3. Executando a Verificação de Documentos

Durante as revisões, o profissional que está conduzindo as reuniões deverá
garantir que todos os pontos dos documentos foram questionados e avalia-
dos pelos revisores. Se a reunião não for orientada pela estrutura de tópicos
do documento, corre-se um alto risco de dispersão dos assuntos, dificultan-
do o controle de cobertura final do documento. Seguir a estrutura do mate-
rial a ser revisado dá ao grupo uma possibilidade concreta de avaliar se a or-
dem dos assuntos está adequadamente montada e se existe a necessidade de
anexar fontes complementares de informações para fundamentar algumas
decisões.
A condução de um processo de verificação segue uma seqüência lógica
simples. As principais atividades a serem executadas estão listadas abaixo:
Um tópico é definido e será escopo das discussões.

Uma questão é levantada por um revisor.
A questão é discutida e avaliada.
Os revisores confirmam a existência do defeito.
O defeito é registrado e detalhado para que seja corrigido pelos autores.
Outras questões são levantadas até que todas tenham sido analisadas.
Um novo tópico é identificado até que todos tenham sido discutidos.
Os trabalhos de revisão têm como objetivos a identificação de problemas.

Todos os documentos deverão ser analisados com um olhar crítico, exploran-
do e questionando todos os pontos do trabalho. Quando determinada questão
é levantada, os revisores devem analisar os motivos do não-entendimento.
Revisões são, muitas vezes, encaradas como críticas aos autores, o que
torna essa tarefa mais difícil, porém, devemos entender que nosso propósito
está em fazer melhor nosso trabalho, e as revisões estão simplesmente aper-
feiçoando o documento. Todos nós temos a ganhar com esse processo, até
mesmo o autor, que poderá contar com o apoio de outros profissionais, divi-
dindo a responsabilidade pelo trabalho.
9.4. Aplicando Checklist na Verificação

Checklist é um poderoso instrumento a ser aplicado nas revisões de docu-
mentos e auditorias de processos de trabalho, pois possibilita direcionar
todas as atividades dos testes de verificação, criando uma abordagem úni-
ca de como avaliar a qualidade de um documento. Esse direcionamento é
realizado através de “guias” que orientam as auditorias e inspeções de do-

cumentos, reduzindo o grau de subjetividade em relação ao que deve ser
avaliado ou não.
A checklist deve ser utilizada como um acessório durante as fases de veri-
ficação, pois orienta o profissional a investigar diversos aspectos em relação
ao documento ou atividade. Apesar de considerada essencial, devemos ver a
checklist apenas como um “guia” que disciplina a atividade.

de de Análise e da
Checklist Checklist Checklist Checklist

de de Análise e da
Figura 9.3 Checklist aplicada nas diversas fases dos testes de verificação
A prática de checklist é muito empregada nas organizações, porém, mui-

tas recomendações obrigatórias são desconsideradas, prejudicando a quali-
dade de documentos e produtos que estão sendo gerados. O profissional de
qualidade poderá empregar essas checklists e avaliar sua aderência com o
que está sendo praticado.
CAPÍTULO 10
Analisando Cada Fase dos

Testes de Verificação
Cada fase do projeto de software cumpre uma importante etapa de en-

tendimento do problema e da definição de uma solução mais adequada às
necessidades do cliente. Cabe ao processo de qualidade de software garantir
que cada etapa está sendo concluída adequadamente para que a etapa poste-
rior seja desempenhada da forma mais tranqüila e produtiva possível.
A etapa de verificação tem importância fundamental no processo de qua-
lidade, pois focaliza suas ações nas etapas iniciais do projeto, nas quais ge-
ralmente ocorre a maior incidência de defeitos geralmente associados a defi-
nições erradas ou a falhas nas decisões realizadas.
Tabela 10.1
Análise das fases dos testes de validação
Fase da Principais Principais Atividades da

Verificação Produtos Fase de Verificação
Modelo de G Modelo de Negócios G Revisar Contexto do Mercado

Negócios G Análise de Riscos e Necessidades do Cliente
G Árvore de Decisão G Revisar Riscos do Projeto
G Estudo de Viabilidade G Auditar Alternativas de Execução
do Projeto
G Revisar Estudo de Viabilidade
do Projeto
Tabela 10.1
Análise das fases dos testes de validação (continuação)
Fase da Principais Principais Atividades da

Verificação Produtos Fase de Verificação
Especificação G Especificação G Revisar Especificação de Requisitos

de Requisitos dos Requisitos Funcionais
G Rastreabilidade G Revisar Especificação de Requisitos
Não-Funcionais
G Revisar Priorização de Requisitos
G Auditar Rastreabilidade de
Requisitos
Análise e G Arquitetura da G Revisar Arquitetura da Aplicação

Modelagem Aplicação G Revisar o Modelo Estático
G Modelos Estáticos do Projeto de Software
G Modelos Dinâmicos G Revisar o Modelo Dinâmico
G Modelos de do Projeto de Software
Distribuição G Revisar Nível de Componentização
G Revisar Nível de Reutilização
Implementação G Código-fonte G Revisar o Código-fonte

G Componentes G Avaliar Complexidade
G Manual do Usuário do Código-fonte
G Auditar Rastreabilidade entre
Componentes
G Revisar Manual do Usuário
Normalmente, as etapas de um projeto de software produzem documen-

tos sem que estes sofram uma avaliação direta, o que impede que determina-
dos problemas sejam avaliados por diferentes ângulos, aumentando os ris-
cos das decisões formalizadas serem inconsistentes na sua prática. É nesse
ponto que o processo de verificação ganha força e torna-se um importante
mecanismo de prevenção de defeitos, pois atua diretamente na fonte das de-
cisões e avalia se determinadas atividades críticas do processo de software
estão sendo realizadas.
10.1. Verificação de Negócios

Normalmente, a fase de modelagem de negócios não é convenientemente
explorada nos projetos de desenvolvimento de software. Como é nessa fase
que estabelecemos o primeiro contato com as necessidades, expectativas e
exigências do cliente, conseguimos estabelecer uma macrovisão da extensão
Analisando Cada Fase dos Testes de Verificação
Modelo • Modelar as necessidades e estabelecer uma macrovisão.

de • Identificar expectativas e exigências do cliente.
Negócios • Estimar prazos e custos do projeto de software.
1
Verificação • Verificar aderência do modelo de negócios com a macrovisão.
de • Verificar as expectativas e exigências do projeto.
Negócios • Verificar se projeções foram realizadas criteriosamente.
Figura 10.1 Objetivo da verificação de negócios
do projeto e dos principais objetivos a serem alcançados com a construção

de um novo software. Atender a essas expectativas é crucial para o sucesso
de um projeto de software.
Assim, espera-se que nessa fase exista uma modelagem de negócios
que possibilite a criação da macrovisão, a qual possibilitará um dimensi-
onamento adequado dos recursos humanos, físicos e financeiros neces-
sários para a construção do software e para sua adequada operacionaliza-
ção. Com essa visão bem definida e os prazos e custos adequadamente
projetados, poderemos avaliar se é vantajoso ou não dar prosseguimento
ao projeto.
10.1.1. Pontos de Verificação

O objetivo dessa fase é garantir que os diversos documentos produzidos te-
nham total aderência às necessidades apontadas pelos clientes. Muitas ve-
zes, os projetos são iniciados sem que os clientes tenham validado essa ma-
crovisão, fazendo com que a equipe do projeto superestime as necessidades
do cliente, criando um “canhão para matar uma única mosca”. O exercício
de revisar esses documentos com o cliente possibilita explorar alguns aspec-
tos que podem inviabilizar um projeto de software, fazendo com que o clien-
te perca uma oportunidade real de negócios devido ao mau dimensionamen-
to do problema.
Abaixo estão relatados alguns pontos que poderiam ser considerados
críticos para se avaliar a qualidade desses documentos.
Avaliar se todas as necessidades, metas e exigências foram listadas.

Verificar se a modelagem de negócios cobre todas as necessidades.
Conferir se as projeções realizadas são baseadas em métricas e indica-
dores confiáveis.
Avaliar a existência de alternativas a essa solução.
Avaliar o retorno sobre o investimento em cada alternativa exis-

tente (ROI).
Validar as opções de investimento (árvore de decisão).
10.1.2. Um Exemplo de Checklist

Deverá existir uma única checklist para cada documento produzido na fase
de verificação da modelagem de negócios. Nesta etapa, é conveniente que
todos os documentos gerados sejam revisados pelo cliente, uma vez que se-
rão eles que “pagarão a conta” caso as coisas não sejam adequadamente bem
planejadas.
Tabela 10.2
Exemplo de checklist do modelo de negócios
Checklist do Modelo de Negócios
Levantamento das Necessidades do Cliente
– Todas as necessidades foram devidamente registradas. o Sim o Não
– Cada necessidade apontada possui uma descrição. o Sim o Não
Definição das Características do Software
– Cada característica atende ao menos a uma necessidade o Sim o Não

identificada.
– Cada característica possui uma descrição clara. o Sim o Não
– Cada característica possui exemplos que auxiliam seu o Sim o Não

entendimento.
– Existe uma rastreabilidade entre características e o Sim o Não
necessidades.
Tabela 10.3
Exemplo de checklist da proposta de projeto de software
Checklist da Proposta de Projeto de Software
Definição dos Objetivos do Projeto
– Todos os objetivos foram apontados e claramente o Sim o Não

descritos.
– Todos os objetivos podem ser quantificáveis. o Sim o Não
Tabela 10.3
Exemplo de checklist da proposta de projeto de software (continuação)
Checklist da Proposta de Projeto de Software
Definição dos Objetivos do Projeto
– Todos os objetivos possuem data-limite para ocorrer. o Sim o Não
– Existe rastreabilidade entre objetivos e necessidades. o Sim o Não
Definição dos Riscos
– Todos os riscos foram identificados e adequadamente o Sim o Não

descritos.
– Existe um plano de ação para cada risco definido. o Sim o Não
– Foram definidos “impacto” e ”probabilidade” para cada o Sim o Não

risco apontado.
10.1.3. Um Exemplo de Critério de Finalização

Como se trata de uma fase extremamente crítica do projeto de software, é re-
comendável estabelecer um critério de finalização apoiado no aceite de toda a
documentação referente à modelagem de negócios e ao documento que des-
creve as condições técnicas e financeiras a que será submetido esse projeto;
portanto, abaixo estão listados alguns critérios que poderiam ser empregados:
Modelagem de negócios assinada pelas diretorias e gerências envol-

vidas.
Proposta de projeto de software assinada pelas diretorias e gerências
envolvidas.
10.2. Verificação de Requisitos

Uma vez encerrada a fase de modelagem de negócios, temos um projeto que
possui orçamento definido, objetivos e necessidades a serem alcançados,
além de uma macro-visão que possibilita definir o escopo do projeto de soft-
ware com relativa precisão. Portanto, nesta nova fase do processo de enge-
nharia de software, teremos agora a missão de detalhar todos os aspectos
funcionais e não funcionais relativos à solução a ser construída, estabelecen-
do todo o conjunto de especificações de negócio em seu nível máximo de de-
talhamento.
O sucesso de qualquer projeto de software depende dessa fase de defini-

ção dos requisitos. É neste momento que as áreas de negócios e tecnologia
detalham e estabelecem a “verdadeira dimensão” do projeto, apontando to-
dos os aspectos a serem implementados. Também é aí que refinamos a ex-
pectativa do cliente em relação ao produto, uma vez que o nível de detalha-
mento possibilita a descoberta de aspectos que não tinham sido previstos.
Caso seja necessário, serão rediscutidos custos e prazos com o cliente, para
que sejam introduzidas as novas características no projeto do software.
Especificação • Identificar os requisitos funcionais.

de • Identificar os requisitos não funcionais.
Requisitos • Identificar a arquitetura da aplicação.
2
Verificação • Verificar consistência dos requisitos funcionais.
de • Verificar consistência dos requisitos não funcionais.
Requisitos • Verificar rastreabilidade entre requisitos e necessidades.
Figura 10.2 Objetivo da verificação de requisitos
Os requisitos direcionarão todas as fases posteriores do desenvolvimen-

to do software, estabelecendo um escopo para o produto final. Esses requisi-
tos são registrados sem especificar como serão implementados. Servem tam-
bém para ajudar a definir a arquitetura e avaliar o sistema à medida que este
evolui em seu desenvolvimento.
A qualidade dos requisitos é um importante indicador de uma organiza-
ção. Bons controles de requisitos estão geralmente associados ao nível de
maturidade organizacional. É comum que no avançar do projeto novos re-
quisitos venham a ser incorporados, provocando mudanças e aumento do
volume total de trabalho. Gerenciar bem essa demanda adicional de requisi-
tos significa controlar os impactos de tempo e recursos que isso irá deman-
dar, portanto, trata-se de uma fase crítica do processo como um todo.

Nessa etapa, os revisores deverão concentrar-se na identificação de todos os
requisitos funcionais e não funcionais de um software. É muito comum nes-
sa fase que os requisitos sejam relatados de forma simplificada, sem que
exista real entendimento sobre o item que está sendo listado. Cada requisito
deve ser claro o suficiente para que não produza uma interpretação errada
sobre sua real intenção, o que provocaria falha na concepção do produto, ge-
rando custo adicional no projeto de software.
Assim, cabe aos profissionais que estão atuando como revisores investi-
gar esses requisitos e garantir sua adequada definição. Abaixo estão relata-
dos alguns exemplos de pontos que poderiam ser considerados críticos na
avaliação da qualidade dos requisitos.
Completo: Todos os requisitos do projeto devem estar documenta-

dos.
Claro: Cada requisito deve expressar seu propósito em relação ao pro-
jeto.
Simples: Cada requisito deve expressar sua essência com uma simples
definição.
Preciso: Cada requisito deve ser exato, não dar margens a dúvidas.
Consistente: Cada requisito não deve possuir conflitos com outros re-
quisitos existentes.
Relevante: Cada requisito deve pertencer ao escopo do projeto em
questão.
Testável: Cada requisito deverá fornecer informações que possibili-
tem quantificar se um determinado item foi adequadamente imple-
mentado.
Factível: Cada requisito deve ser viável em sua implementação, avali-
ando as condições financeiras, humanas e tecnológicas disponíveis no
projeto.
Expressões como ser um software seguro, fácil de usar, fácil de manter,

com boa performance, são muitas vezes citadas mas nunca bem explicadas.
Cada uma parece ser uma grande armadilha que deve ser desarmada e essa é
a missão dos revisores. Quando estamos lendo os requisitos pelo ponto de
vista da qualidade, essas afirmações passam a ter valor fundamental, afinal,
será através desses parâmetros que iremos avaliar se os requisitos foram ade-
quadamente implementados.
Quando um revisor encontrar a frase “As consultas a pedidos deverão ter
uma boa performance”, este logo tentará estabelecer parâmetros mensurá-
veis, como por exemplo, “As consultas a pedidos (100 usuários simultanea-
mente em sites diferentes) deverão ocorrer em até 10 segundos”. Dessa for-
ma, estabelecemos um acordo de serviço entre a área de negócios e a de tec-
nologia, sendo devidamente documentado como um requisito do software.

Tabela 10.4
Exemplo de checklist de requisitos
Checklist de Requisitos
Diagrama de Casos de Uso
– Existe um modelo de casos de uso para cada subsistema o Sim o Não

identificado.
– Todos os casos de usos estão adequadamente descritos. o Sim o Não
– Todos os atores estão adequadamente representados. o Sim o Não
Levantamento de Requisitos
– Cada caso de uso representa um requisito funcional. o Sim o Não
– Existe rastreabilidade entre requisitos identificados e o Sim o Não

necessidades.
– Requisitos foram avaliados por importância, volatilidade o Sim o Não
e criticidade.
Especificações Funcionais
– Cada requisito funcional possui uma especificação o Sim o Não

detalhada.
– As especificações contemplam os fluxos básicos, o Sim o Não
alternativos e exceção.
– As especificações contemplam pré-requisitos e o Sim o Não
pós-condições.
Especificações Não Funcionais
– Todas as categorias de requisitos não funcionais foram o Sim o Não

levantadas.
– Cada requisito não funcional possui uma especificação o Sim o Não
detalhada.
– Todas as dependências dos componentes foram o Sim o Não
estabelecidas.

O critério de finalização da fase de levantamento dos requisitos deve garan-
tir que todos os requisitos foram adequadamente identificados pelo projeto
de software. Os requisitos devem refletir todas as características funcionais e
não funcionais que o cliente espera receber quando o software está disponi-
bilizado, funcionando como uma espécie de contrato de serviço. Portanto,

as especificações que detalham esses requisitos serão revisadas com a área
usuária para que não exista um desvio das expectativas originais do cliente
em relação ao software que está sendo desenvolvido. Alguns critérios que
poderiam ser empregados para finalizar essa fase são:
Especificações funcionais criadas e revisadas.

Especificações não funcionais criadas e revisadas.
Rastreabilidade entre requisitos e entre necessidades.
10.3. Verificação da Análise e Modelagem

Uma vez determinados os requisitos que são esperados, conseguimos pro-
duzir uma imagem mais nítida sobre o que deveremos atender, possibilitan-
do a modelagem de uma solução mais aderente e flexível às exigências e ex-
pectativas do cliente.
Nessa etapa o objetivo é definir uma solução tecnológica que suporte
não somente os requisitos estabelecidos pelo cliente, mas também requisi-
tos de qualidade que deverão ser atendidos pela arquitetura do software a ser
modelada. A modelagem de uma boa arquitetura deve contemplar caracte-
rísticas como flexibilidade (capacidade de absorver mudanças e arranjos di-
ferenciados de processamento), escalabilidade (suportar o crescimento de
transações), ser reutilizável (intensificar a reutilização de partes do software).
Tudo isso deverá estar inserido no contexto da solução tecnológica que será
definida nessa fase.
Muitas vezes, as soluções modeladas nem sempre são adequadas ao longo
prazo, evidenciando falhas no processo de definição da arquitetura. As revi-
sões possibilitam validar determinados aspectos críticos de uma solução, ava-
liando a existência de mecanismos que suportem um alto nível de parametri-
zação, possibilitando assimilar mudanças nos negócios e em tecnologias.
Análise e • Modelar uma solução que suporte todos os requisitos.

Modelagem • Modelar uma arquitetura flexível, escalável e reutilizável.
• Modelar uma arquitetura que suporte mudanças.
3
Verificação • Verificar consistência da arquitetura da solução.
Análise e • Verificar aderência de requisitos funcionais com a solução.
Modelagem • Verificar aderência de requisitos não funcionais com a solução.
Figura 10.3 Objetivo da verificação de análise e modelagem


O objetivo desta fase não está somente na avaliação da aderência da solução
tecnológica aos requisitos funcionais e não funcionais estabelecidos pelo
cliente, mas também em avaliar a modelagem da solução como um todo.
Nessa fase, as revisões devem simular cenários de mudanças que possibili-
tem avaliar o quanto a solução consegue absorver as modificações de negó-
cios e tecnologias que poderão ocorrer ao longo do tempo, simulando um
impacto direto na arquitetura da solução modelada. Abaixo, alguns pontos
que poderiam ser avaliados durante esse processo:
Avaliar se todos os requisitos funcionais e não funcionais contemplam

a solução.
Avaliar se a arquitetura suporta o crescimento e a segurança desejados.
Avaliar se a arquitetura suporta futuras mudanças de negócios e de
tecnologia.
Avaliar se a arquitetura pode ser operacionalizada em vários am-
bientes.
Avaliar as restrições e problemas conhecidos da arquitetura a ser ado-
tada.

Uma checklist de verificação da análise e modelagem deverá existir para cada
documento a ser revisado. Caso o projeto esteja utilizando diagramas UML
para representar as decisões de modelagem e da arquitetura, poderemos em-
pregar uma checklist que siga as seguintes características.
Tabela 10.5
Exemplo de checklist de diagramas UML
Checklist do Diagramas UML
Diagramas de Classes
– Todas as classes possuem nome e descrição adequados. o Sim o Não
– Todos os atributos da classe possuem nome e descrição o Sim o Não

adequados.
– Todos os serviços da classe possuem nome e descrição o Sim o Não
adequados.
Tabela 10.5
Exemplo de checklist de diagramas UML (continuação)
Checklist do Diagramas UML
Diagrama de Estado
– Todas as transições de estado possuem um serviço o Sim o Não

ou evento associado.
– Todos os estados possuem nome e descrição o Sim o Não
adequados.
– Todas as transições de estado refletem o real ciclo o Sim o Não

de vida da classe.
Diagramas de Componentes
– Os packages agrupam componentes com as mesmas o Sim o Não

características.
– Cada componente agrupa classes de única camada: user, o Sim o Não
business, data.
– Todas as dependências dos componentes foram o Sim o Não
estabelecidas.
Tabela 10.6
Exemplo de checklist de arquitetura
Checklist da Arquitetura
Suportar Mudanças nos Negócios
– Existem parametrizações que modificam a funcionalidade o Sim o Não

da aplicação.
Suportar Mudanças Tecnológicas
– O software possui independência do banco de dados. o Sim o Não
– O software possui independência do sistema operacional. o Sim o Não
– O software possui independência de browsers. o Sim o Não

O critério de finalização da fase de análise e modelagem deve garantir que a so-
lução tecnológica que foi modelada atende adequadamente a todos os requisi-
tos dos clientes, além de incorporar características que deixam a arquitetura
flexível e aderente a futuras mudanças. Essa arquitetura deverá ser validada

com toda a equipe de profissionais, inclusive a equipe técnica do cliente, que
discutirá todos os pontos referentes à utilização da solução modelada. Alguns
critérios que poderiam ser empregados para finalizar essa fase são:
Diagramas estáticos (classes e objetos) criados e revisados.

Diagramas dinâmicos (estados, seqüência e atividades) criados e revi-
sados.
Diagramas de distribuição (componentes e implantação) criados e re-
visados.
10.4. Verificação da Implementação

Essa fase encerra o ciclo de verificação de testes. Nela, toda a documentação
produzida pelas fases anteriores serão transformadas em código de uma de-
terminada linguagem de desenvolvimento. A maioria das organizações co-
meça seu ciclo de verificação nessa fase. Como muitas delas possuem um
fraco processo de coleta de requisitos e modelagem de negócio, tal verifica-
ção torna-se inócua. Transformar em código especificações ruins, incom-
pletas e imprecisas acarreta produtos não adequados e pouco confiáveis.
• Traduzir os modelos em estruturas internas dos códigos.

Implementação • Traduzir os requisitos de negócios, regras e comportamentos
em código-fonte.
4
Verificação • Garantir que fontes estão compatíveis com os modelos.
da • Garantir normas e padrões de desenvolvimento.
Implementação • Garantir reduzido nível de complexidade das fontes.
Figura 10.4 Objetivo da verificação da implementação
Algumas empresas de software realizam um processo formal de verifica-

ção do código produzido. Os testadores avaliam linha por linha em busca de
erros, analisam alternativas melhores e mais simples de produzir os mesmos
resultados, comentam nomes e declarações não compatíveis com os docu-
mentos gerados nas fases anteriores. Enfim, produzem um qualitativo pro-
cesso de verificação do código-fonte; porém, esse processo pode ser extre-
mamente informal, no qual cada desenvolvedor avalia o código de outro
profissional em busca de erros realizados.

O objetivo dessa fase é garantir a qualidade do código-fonte gerado pela
equipe de desenvolvimento. Essa qualidade será atribuída pela prática das
chamadas “regras da boa programação”, que podem contemplar diversas
normas e padrões corporativos seguidos pelas diversas equipes de desenvol-
vimento. Abaixo estão relatados alguns exemplos de pontos que poderiam
ser considerados críticos para avaliar a qualidade dos fontes.
Comparar os modelos de arquitetura com os códigos-fontes.

Utilizar ferramenta de análise estática para avaliar a complexidade dos
fontes.
Avaliar as mensagens apresentadas ao usuário final.
Inspecionar a existência de rotinas de tratamentos de erros nos pro-
cessos críticos.
Inspecionar se o volume de comentários é suficiente.
Inspecionar a legibilidade do código.
Inspecionar o padrão de nomenclaturas existentes.

Uma checklist da implementação deverá contemplar um único documen-
to a ser inspecionado. No caso de linguagens de programação, alguns
pontos da checklist serão específicos de cada tecnologia, enquanto que
outros pontos serão comuns a todas as linguagens existentes. No caso de
revisões dos bancos de dados, também existirá uma checklist específica
para essa verificação.
Tabela 10.7
Exemplo de checklist de código-fonte
Checklist do Código-fonte em Visual Basic
Comparação do Modelo de Arquitetura do Software com o Código-fonte
– Todas as classes do modelo foram implementadas. o Sim o Não
– Todos os métodos de cada classe foram o Sim o Não

implementados.
– Todos os atributos de cada classe foram o Sim o Não
implementados.
Tabela 10.7
Exemplo de checklist de código-fonte (continuação)
Checklist do Código-fonte em Visual Basic
Mensagens Apresentadas ao Usuário Final
– Nenhuma mensagem apresenta erros gramaticais. o Sim o Não
– Todas as mensagens são claras e bem objetivas. o Sim o Não
– Todas as mensagens apresentam ícones adequados ao o Sim o Não

contexto.
Legibilidade do Código
– Todas as estruturas estão adequadamente identadas. o Sim o Não
– Não existem linhas agrupadas com IF, SELECT, FOR o Sim o Não
NEXT e FOR EACH.
– Tratamentos de erros e desvios sempre estão no final o Sim o Não
das rotinas.
– Todas as declarações de variáveis e constantes estão no o Sim o Não
início da rotina.
– Não existem vários comandos em uma única linha. o Sim o Não
Volume de Comentários
– Todas as rotinas possuem descrição sobre seu o Sim o Não

comportamento.
– Todos os desvios de rotinas possuem um comentário. o Sim o Não
Tabela 10.8
Exemplo de checklist do banco de dados
Checklist do Banco de Dados
Comparação do Modelo de Dados com o Banco de Dados
– Todas as tabelas do modelo de dados foram o Sim o Não

implementadas.
– Todos os campos de cada tabela foram implementados. o Sim o Não
– Todos os índices de cada tabela foram implementados. o Sim o Não
– Todos os stored procedures de cada tabela foram o Sim o Não

implementados.
– Todas as visões do modelo de dados foram implementadas. o Sim o Não
– Todos os campos de cada visão foram implementados. o Sim o Não


Podemos empregar uma ferramenta cujo objetivo é realizar, de forma auto-
mática, inspeções nos códigos gerados pela equipe de desenvolvimento.
Essa ferramenta realizará uma análise de normas e padrões relacionada às
boas práticas de programação. Também será realizada análise da complexi-
dade do código-fonte produzido pelos programadores, o que permitirá ava-
liar se os códigos estão sendo bem construídos ou não. O resultado dessa
análise será uma lista de não-conformidades que deverá ser analisada pela
equipe de desenvolvimento até que os critérios de finalização sejam alcança-
dos, considerando neste momento o código-fonte OK.
Análise de Normas e Padrões de Codificação

Será necessário parametrizar a ferramenta com as práticas de codificação da
organização, como padrões de variáveis, bibliotecas de uso comum, padrões
de internacionalização, regras de portabilidade entre versões de sistemas
operacionais, entre outros.
A ferramenta irá melhorar a qualidade final do código-fonte, uma vez
que conduz o programador a utilizar padrões conhecidos de trabalho, facili-
tando o entendimento e, conseqüentemente, a manutenção dos códigos-
fonte. Abaixo estão relacionados os critérios de finalização segundo a análi-
se de Normas e Padrões:
Critérios analisados durante a Tolerância a Erros por Severidade

inspeção do código
Alta Média Baixa
Banco de Dados Nenhuma Nenhuma Nenhuma

Internacionalização Nenhuma Nenhuma Nenhuma
Lógica Nenhuma Nenhuma Nenhuma
Performance Nenhuma 10 erros 10 erros
Portabilidade Nenhuma Nenhuma Nenhuma
Usabilidade 5 erros 10 erros 20 erros
APIs do Windows Nenhuma Nenhuma Nenhuma
Critérios Analisados: identificam todos os critérios que serão auto-

maticamente analisados e apontados como não-conformidades do có-
digo-fonte.
Tolerância a Erros: estabelece os níveis de erros tolerados para cada
critério analisado pela ferramenta.
Análise da Complexidade do Código

A ferramenta realiza a análise da complexidade dos códigos-fonte inspecio-
nados, identificando quais rotinas estão com complexidade acima da permi-
tida pelos padrões definidos pela organização. A ferramenta utiliza as métri-
cas de McCabe para determinar o nível de complexidade do código (comple-
xidade ciclomática) e identificar a probabilidade.
Complexidade Avaliação da Esforço de Probabilidade de

Ciclomática Complexidade Manutenção e Teste Inserção de Erros
<5 Simples Baixo esforço 1%

5-10 Moderada Médio esforço 5%
11-20 Difícil Grande esforço 10%
21-50 Muito difícil Muito complexo 30%
> 50 Impossível testar Refazer –
Onde:
Complexidade Ciclomática: é o nível de complexidade de um códi-

go-fonte segundo as métricas definidas por McCabe.
Avaliação da Complexidade: estabelece as categorias de complexi-
dades possíveis a serem atribuídas a um código-fonte segundo os cri-
térios de McCabe.
Esforço de Manutenção e Teste: dimensiona o esforço necessário
para a realização de testes de caixa branca e realização de manu-
tenções nas diversas categorias de complexidades de um códi-
go-fonte.
Probabilidade de Inserção de Erros: dimensiona a possibilidade do
risco associado às categorias de complexidades de uma determinada
manutenção inserir um novo erro no código-fonte.
Segundo o critério de finalização pela análise de complexidade de códi-

go, segundo as métricas definidas por McCabe, somente serão considerados
em conformidade os fontes que estiverem de acordo com os critérios estabe-
lecidos pela seguinte tabela:
Complexidade Avaliação da Percentual Máximo

Ciclomática Complexidade Permitido
<5 Simples 100%
5-10 Moderada 20%
11-20 Difícil 5%
21-50 Muito difícil Não permitido
> 50 Impossível testar Não permitido
Observação: Notem que esse critério de finalização estabelece um padrão

mínimo de qualidade do código-fonte, ou seja, existe uma tolerância para os
códigos “difícil” e “moderado” desde que não representem mais de 5% e 20%,
respectivamente. No entanto, os códigos categorizados como “muito difícil” e
“impossível de testar” não serão aceitos em hipótese alguma. Trata-se de uma
regra que está explícita tanto para desenvolvedores quanto para os profissionais
da área de qualidade. Cabe aos desenvolvedores produzir códigos segundo esse
critério, enquanto cabe aos profissionais de qualidade garantirem que esses
valores estão sendo respeitados.
CAPÍTULO 11
Entendendo os
Testes de Validação
Contrários aos testes de verificação, que avaliavam as documentações

e atividades com o objetivo de detectar erros ou quebras do processo, os tes-
tes de validação possuem agora um produto computacional que pode ser
executado. Nesta fase do processo de desenvolvimento, o software construí-
do passa a ser objeto de nosso interesse. Cabe aos profissionais voltados à re-
alização dos testes de software buscarem todos os meios e recursos possíveis
para criar infra-estrutura que possibilite identificar o maior número de er-
ros, gerando o menor esforço possível.
Os testes de validação têm por objetivo identificar o maior número pos-
sível de erros tanto nos componentes isolados quanto na solução tecnológi-
ca como um todo. O sucesso da validação está apoiado diretamente em um
forte planejamento de todas as atividades de testes, nas quais a concentração
dos trabalhos de validação nos componentes mais complexos e nos requisi-
tos mais críticos contribui para aumentar a eficiência dos procedimentos de
detecção de defeitos, uma vez que esses componentes concentram a maior
quantidade de erros.
11.1. Estratégias Fundamentais dos Testes

Os testes de validação envolvem a execução total ou parcial do software a ser
avaliado, porém, existem duas únicas abordagens para conduzir um proces-
so de validação: pela estratégia caixa branca ou pela estratégia caixa preta.
A estratégia escolhida determina o modo como iremos estabelecer o pro-

blema e como serão conduzidos os procedimentos de testes visando minimi-
zar esforços e ampliar as chances de detecção de erros que estão inseridos no
software.
Caixa Branca Caixa Preta
Figura 11.1 Estratégias fundamentais dos testes
A aplicação de testes de caixa preta não exclui a necessidade de aplicar-

mos os testes de caixa branca e vice-versa. Na verdade, essas estratégias são
complementares e não exclusivas, o que significa que teremos um produto
de maior qualidade se ambos os processos foram aplicados nas etapas de va-
lidação do software.
11.1.1. Estratégia de Caixa Branca

Os testes de caixa branca são conhecidos dessa forma porque são baseados
na arquitetura interna do software. Esses testes empregam técnicas que ob-
jetivam identificar defeitos nas estruturas internas dos programas através da
simulação de situações que exercitem adequadamente todas as estruturas
utilizadas na codificação.
Para realizar os testes de caixa branca é necessário que o profissional de
testes conheça a tecnologia empregada pelo software, bem como possua
um adequado conhecimento da arquitetura interna da solução, ou seja,
Caminho A
Início do Término do
Processamento Processamento
Caminho B
Figura 11.2 Visão de testes de caixa branca

Entendendo os Testes de Validação
esse profissional deverá ter acesso a fontes, estruturas dos bancos de dados
e realizar todos os testes previstos no processo de validação de componen-
tes de software.
Os testes de caixa branca são conhecidos por sua alta eficiência na detec-
ção de erros, porém também são conhecidos por serem difíceis de se imple-
mentar. Os testes de caixa branca podem ser modelados e estruturados pelos
próprios profissionais do desenvolvimento, porém existirá uma carga adi-
cional de trabalho a esses profissionais. Uma área de profissionais de testes
pode ser uma solução inicialmente mais cara, porém gerará resultados mais
rápidos e significativos, o que pode eventualmente pagar ou até mesmos re-
verter em resultados financeiros visíveis. Porém, não fique tentado em colo-
car esse profissional de testes sob o “guarda-chuva” da área de desenvolvi-
mento. Tal atitude somente minimizará os resultados que poderão ser alcan-
çados por uma equipe que atue de forma independente. Lembre-se: a área de
desenvolvimento tem por meta “construir softwares” e será cobrada para
isso. Pressionada, essa área poderá sacrificar alguns processos de testes para
honrar seus compromissos, o que não aconteceria se essas atividades fossem
desempenhadas por uma outra área.
11.1.2. Estratégia de Caixa Preta

A estratégia de caixa preta utiliza técnicas para garantir que os requisitos do
sistema são plenamente atendidos pelo software que foi construído. Não é seu
objetivo verificar como ocorrem internamente os processamentos no softwa-
re, mas se o algoritmo inserido no software produz os resultados esperados.
A grande vantagem da estratégia de caixa preta é o fato de esta não reque-
rer conhecimento da tecnologia empregada ou dos complexos conceitos de
implementação aplicados internamente no software, o que reduz a dificul-
dade de encontrar um profissional capacitado a modelar os testes de caixa
Estímulos Resultados
Produzidos Gerados
Figura 11.3 Visão de testes de caixa preta

preta dessa aplicação. O conhecimento requerido do profissional de testes é

o conhecimento dos requisitos, suas características e comportamentos espe-
rados, para que seja possível avaliar o software através dos resultados gera-
dos pela aplicação.
Os testes de caixa preta são conhecidos por serem mais simples de se im-
plantar do que os testes de caixa branca. Na verdade, ambos são complexos e
exigem grande esforço de planejamento e automação dos procedimentos, po-
rém os testes de caixa preta são freqüentemente encontrados nas organizações,
em forma de testes manuais executados por profissionais ou mesmo usuários
do sistema, o que facilita a introdução desse conceito nas organizações (qual
empresa não tem pelo menos uma pessoa para ficar testando a aplicação?).
O grande desafio de se implantar o método de caixa preta nas organizações é
convencer a área que já executa as atividades de homologação e começar a exi-
gir um planejamento mais apurado e transparente para que todas as outras áreas
possam ter acesso a todos os cenários de testes que estão sendo executados;
também introduzir o conceito de massa controlada, para que possamos garantir
que todos os cenários estejam sendo adequadamente simulados e os resultados
comparados com uma massa confiável; finalmente, substituir o moroso e can-
sativo processo manual por um processo automatizado e confiável.
11.2 Abordagens Fundamentais dos Testes

Existem diversas formas de se planejar e identificar os casos a serem apli-
cados nos testes de validação, porém todo o direcionamento dos testes
(testdrivers) será baseado exclusivamente em requisitos da solução tecnoló-
gica a ser desenvolvida ou na estrutura interna do código-fonte a ser imple-
mentado. Cada uma dessas abordagens possui um conjunto de métodos di-
ferentes de planejamento e obtenção dos casos de testes de validação; cabe
aos profissionais de testes buscar a forma mais eficiente e adequada à realiza-
ção dessas atividades.
11.2.1 Testes Baseados na Estrutura Interna

Com base no modelo de implantação da solução de software, os testes re-
querem um conhecimento profundo da tecnologia e do projeto de desenvol-
vimento, de forma a exercitarem adequadamente todas as estruturas inter-
nas do projeto, visando à validação de todos os algoritmos empregados pelo
software. Como os testes exigem conhecimento interno do software, sempre
empregaremos a estratégia caixa branca para abordá-los.
Entendendo os Testes de Validação
Caixa Branca Caixa Preta
.....................................
............................................
.....................................
.............................
..........................................
............................................
.............................
......................................
............................................
Testes Baseados na Estrutura Interna Testes Baseados nos Requisitos
Figura 11.4 Abordagens fundamentais dos testes
11.2.2. Testes Baseados em Requisitos

Os testes são baseados nos documentos de requisitos e modelados através de
especificações funcionais e suplementares. Requisitos devem ser decompos-
tos em casos de testes de forma a avaliarem todos os cenários existentes e vali-
darem todas as variações (fluxos de processamento alternativos e de exceção)
que uma solução tecnológica deve suportar. Como os testes de requisitos po-
dem ser aplicados sem conhecimento da arquitetura interna do software ou
do código-fonte, estes deveriam sempre empregar a estratégia de caixa preta.
11.3. Progressividade e Regressividade dos Testes

Qualquer processo de desenvolvimento de software deve contemplar um
modelo eficiente para incorporar mudanças durante e depois da construção
da aplicação. Essas mudanças provocam, muitas vezes, alterações estrutu-
rais que afetam funcionalidades já implementadas, gerando defeitos em
pontos do software que estavam anteriormente perfeitos.
A maior parte dos esforços dos testes aplicados atualmente nas empresas
está concentrada nas funcionalidades recém-construídas ou modificadas,
não existindo qualquer mecanismo que avalie se essas mudanças provoca-

ram problemas em outras funcionalidades existentes, aumentando conside-
ravelmente os riscos de uma pequena mudança gerar problemas no ambien-
te de produção.
Cenário A Cenário B Cenário B.1
Erro !
Cliente Cliente
Cliente Cliente Ocasional Ocasional
VIP Regular
Cliente Cliente Cliente Cliente
VIP Regular VIP Regular
Pedidos Pedidos Pedidos
Nesta versão, o sistema atende duas Foi gerada uma nova versão e Essas reduções de preços aumentaram
categorias de clientes, sendo que o somente aplicados testes repentinamente a requisição de
progressivos, porém, a política de pedidos. A área de vendas comemorou
VIP responde por 75% do faturamento.
por apenas quatro horas essa nova
A necessidade de políticas de negociação de VIP foi
situação. O erro foi identificado e a
negociação para clientes ocasionais indevidamente afetada com essa solução foi disponibilizada rapidamente.
gera demanda para uma mudança, provocando reduções nos Foram seis horas para
nova funcionalidade. preços de linhas inteiras de produtos. a solução completa.
Figura 11.5 Risco da ausência dos testes regressivos
11.3.1. Testes Progressivos

Todos os casos de testes nascem como testes de progressão e acabam se tor-
nando posteriormente testes de regressão durante o ciclo de vida do produ-
to. Os testes de progressão são elaborados de acordo com a evolução do pro-
duto. À medida que o software ganha novas funcionalidades, um novo con-
junto de testes deve ser criado. Na abordagem dos testes de progressão, so-
mente é necessário testar as inovações do software, assumindo que nenhum
erro foi introduzido após seu processo de desenvolvimento.
11.3.2. Testes Regressivos

Trata-se de reexecutar um subconjunto (total ou parcial) de testes previa-
mente executados. Seu objetivo é assegurar que as alterações ou inserções de
determinados segmentos do produto (durante uma manutenção ou melho-
rias implementadas) não afetaram outras partes do produto. Toda nova ver-
são do produto deveria ser submetida a uma nova sessão de testes para detec-
tar eventuais impactos em outras funcionalidades.
CAPÍTULO 12
Categorias de
Testes de Software
Muitas organizações e seus profissionais têm dificuldade em distin-

guir as diversas motivações que levam à realização dos testes de software. É
claro que todos os testes têm por objetivo a identificação de erros, porém de-
vemos entender que a localização de todo e qualquer tipo de defeito exigirá
um esforço muito grande da equipe de testes. Se não temos tempo nem re-
cursos suficientes para executar todos os procedimentos de testes, devemos
planejar uma estratégia na qual estabelecemos quais tipos de erros quere-
mos prioritariamente encontrar.
Se avaliarmos uma simples operação de saque, poderemos entender por
que é tão importante possuir uma clara compreensão do que estamos real-
mente querendo testar. Se nosso objetivo for identificar todos os cenários de
testes dessa operação, nosso universo de possibilidades será muito amplo,
dificultando os trabalhos de levantamento. Quando isso ocorre, é comum
observarmos que os cenários de testes criados são muito dispersivos, pois
objetivam identificar toda e qualquer natureza de defeitos. No levantamento
abaixo, percebemos que a lista atende a objetivos de testes bem diferencia-
dos: existem testes ligados aos requisitos de negócios, testes relacionados à
performance do software, testes relativos à compatibilidade com outros am-
bientes de execução e até mesmo testes de segurança da aplicação, ou seja,
tudo é importante e deve ser testado.
Cenários de Testes
- simular saques acima do saldo disponível;
- simular saques com cartão vencido;
Depósito - avaliar se a duração do saque dura até 30 segundos em um universo de 5 milhões
de correntistas e 100 milhões de movimentação bancária;
- simular saque com defeito no cash dispenser;
- simular saque com impressora dos fornecedores A, B e C;
Saque - avaliar se a senha do cartão está sendo requisitada antes e depois da transação;
- simular dois saques simultâneos na mesma conta corrente;
- simular saque na conta poupança;
Transfe- - avaliar se a senha adicional e randômica está sendo requisitada no início
rência da operação.
- simular saques no Windows 95, 98, NT e 2000;
- avaliar se todas as telas possuem ajuda.
Figura 12.1 Levantamento dos cenários sem os conceitos de categorização
É muito comum organizações que fazem de tudo um pouco em relação a

testes, o que demonstra falhas no conceito de categorização que está sendo
aplicado, refletindo menor qualidade do planejamento da validação do soft-
ware. Isso acontece porque os profissionais de testes planejam trabalhos de
naturezas totalmente diferentes em uma única abordagem e levantamento.
Misturar categorias de testes (usabilidade, funcionais, carga, performance,
contingência) faz com que os trabalhos de levantamento dos cenários sejam
superficiais e incompletos, pois perdem qualidade em função da amplitude
dos testes que estamos buscando.
12.1 Organizando em Categorias de Testes

Se nosso levantamento focar uma única categoria de testes, poderemos me-
lhor conduzir o processo, possibilitando concentrar nossas energias em
uma única perspectiva de defeitos a serem identificados. Isso facilita o dire-
cionamento do levantamento e possibilita a realização de reuniões mais rá-
pidas e produtivas. É claro que determinadas categorias com importância re-
duzida poderão ser planejadas em conjunto, agrupadas em um único levan-
tamento em função da existência de poucos cenários e baixa criticidade.
Nossa preocupação maior é sempre com as categorias mais complexas e im-
portantes, que exigem maior esforço e alto nível de qualidade dos levanta-
mentos. Não podemos deixar que determinadas categorias críticas sejam
prejudicadas por outras de menor importância.
Se observarmos esse levantamento e compará-lo ao realizado anterior-
mente, conseguiremos demonstrar claramente a vantagem da segmentação
desses cenários. Fica óbvio aqui que a categorização dos cenários possibilita
Categorias de Testes de Software
organizar melhor todo o planejamento dos testes, facilitando o entendimen-

to de como a área estará conduzindo o esforço de validação do software. Per-
ceba que é mais simples refinar os cenários de testes quando o agrupamos
em categorias, o que amplia a cobertura dos testes e aumenta a eficiência da
detecção de defeitos.
Tabela 12.1
Levantamento dos cenários aplicando-se os conceitos de categorização
Funcional Segurança Usabilidade Performance
– simular saques – simular saques – avaliar se todas – avaliar se a

acima do saldo com cartão as telas possuem duração do saque
disponível vencido ajuda dura até 30
– simular saque na – avaliar se a – avaliar se as segundos em um
conta poupança senha do cartão mensagens são universo de 5
– simular saque está sendo claras e objetivas milhões de
acima do valor do requisitada antes e – avaliar se o correntistas e
limite da conta depois da padrão visual é 100 milhões de
– simular saque transação mantido em todos movimentação
com valores não – avaliar se a os momentos bancária
múltiplos das senha adicional e – avaliar se todas – garantir que a
notas randômica está as operações manipulação com
– simular saques sendo requisitada possuem dispositivos
sem notas no cash no início da caminhos de fuga físicos no saque
dispenser operação não ultrapasse 10
– simular saque segundos da
noturno acima do operação
valor permitido
Carga e Configuração Recuperação Contingência

Concorrência
– simular dois – simular saque – simular saque – disparar

saques com impressora com defeito no processo de
simultâneos na dos fornecedores cash dispenser instalação
mesma conta A, B e C – simular saque emergencial
corrente – simular saques com defeito na
– simular 10.000 no Windows 95, impressora
saques 98, NT e 2000 – simular saque
simultâneos – simular saque com falha de
com impressora conexão com a
dos fornecedores central
X, Y e Z – simular saque
com queda de
energia
É fundamental entender que cada categoria possui seu ciclo de teste in-
dependente, uma vez que suas naturezas são muitas vezes conflitantes, não
possibilitando a coexistência. Um exemplo disso é a realização de testes fun-
cionais e de performance ao mesmo tempo. No primeiro teste, o fundamen-
tal é a existência de uma massa criteriosamente selecionada para que todas
as ações sejam avaliadas e comparadas com o comportamento esperado. No
segundo teste, o que interessa é a monitoração dos tempos de resposta em
relação ao acesso simultâneo de determinado número de profissionais, sen-
do necessário estar com um volume de informações compatíveis com o am-
biente de produção. Suportar essas duas atividades simultaneamente signifi-
ca conciliar interesses totalmente conflitantes.
12.2. Entendendo as Categorias de Testes

Visando aumentar a eficiência da detecção do maior número possível de ce-
nários de testes, é fundamental que o levantamento dessas informações
ocorra de forma categorizada. Durante o planejamento dos testes, devemos
estudar quais categorias de testes serão aplicadas ao processo de validação
do software e, somente após essa definição, identificaremos todos os cená-
rios existentes para cada transação a ser estudada. Essa categorização estabe-
lecerá como serão organizados e estruturados os diversos cenários a serem
executados, possibilitando à equipe de testes conduzir seus trabalhos de for-
ma mais objetiva e melhor focada.
Tabela 12.2
Comparação entre levantamentos de testes
Testes sem Categorização Testes com Categorização

(sem Foco) (com Foco)
1. Levantamentos unificados. 1. Levantamentos categorizados.

2. Superficialidade do levantamento. 2. Profundidade dos levantamentos.
3. Única documentação dos testes. 3. Documentações categorizadas.
4. Visão única dos testes. 4. Visão categorizada dos testes.
5. Falta de priorização das categorias. 5. Priorização das categorias.
6. Falta de métricas para cada categoria. 6. Métricas de esforço e eficiência das
categorias.
7. Aplicação de todas as categorias sem 7. Somente categorias relevantes são
avaliação. aplicadas.
8. Dificuldade em segregar a execução 8. Execuções separadas de testes,
dos testes. flexibilizando a operação.
Cada categoria de teste possui um determinado objetivo a ser alcançado.

Esse objetivo define o propósito da realização dos testes, estabelecendo um
escopo das ações e planejamentos desses trabalhos. Sem esse escopo, existi-
ria uma dispersão natural no esforço de criação dos testes de um determina-
do sistema.
Portabilidade
Desempenho Recuperação
Saque
Configuração Usabilidade
Funcional
Figura 12.2 Visão categorizada dos testes de software
12.2.1. Teste de Funcionalidade

Essa categoria de testes tem por objetivo simular todos os cenários de negó-
cio e garantir que todos os requisitos funcionais sejam implementados. Os
testes funcionais exigem profundo conhecimento das regras de negócio de
uma aplicação para que todas as variações possíveis sejam simuladas, obten-
do o máximo de cobertura dos cenários de negócio.
Os testes funcionais devem ser direcionados pelos documentos de espe-
cificação funcional. Esses documentos descrevem o comportamento que o
software deve assumir nos diversos cenários existentes para cada requisito
de negócio. Os testes de funcionalidade são caracterizados pelo foco em ne-
gócios.
A idéia é garantir que não existam diferenças entre os requisitos funcio-
nais e o comportamento do software construído. Os testes serão aplicados
sem que exista uma preocupação direta com o algoritmo interno do softwa-
re, empregando apenas a utilização de valores de entrada e saída como refe-
rencial para a avaliação da conformidade do requisito. Trata-se da categoria
mais prioritária entre as demais, pois representa a aderência do software em
relação às regras de negócio. Esses testes podem ser executados validando as
seguintes situações:
As pré-condições de uma transação de negócios.

O fluxo de dados de uma transação de negócios.
O cenário primário de uma transação de negócios.
Os cenários alternativos de uma transação de negócios.
Os cenários de exceção de uma transação de negócios.
As pós-condições de uma transação de negócios.
12.2.2. Teste de Usabilidade

Essa categoria de testes tem por objetivo simular as condições de utilização
do software sobre a perspectiva do usuário final. Dessa forma, esses testes fo-
calizam a facilidade de navegação entre as telas da aplicação, a clareza de tex-
tos e mensagens que são apresentados ao usuário, o acesso simplificado de
mecanismos de apoio ao usuário, o volume reduzido de interações para rea-
lizar uma determinada função, padronização visual, entre outros aspectos.
A idéia desses testes é medir o nível de facilidade disponibilizada pela
aplicação, de modo a deixar o software mais simples e intuitivo. Também
podemos avaliar se o software cumpre com os requisitos de usabilidade, que
podem contemplar eventuais correções de erros ou mesmo avisar sobre
ações que podem danificar ou perder, de forma irreversível, dados perten-
centes ao usuário – botão desfazer alteração e cancelar operação, além do
alerta Esta operação excluirá seu histórico. Deseja continuar?.
Esses testes podem ser executados da seguinte forma:
Entrar em cada tela e avaliar a facilidade de navegação entre elas.

Realizar n operações e depois desfazê-las.
Realizar procedimentos críticos e avaliar mensagem de alerta.
Avaliar número de passos para realizar as principais operações.
Avaliar a existência de ajuda em todas as telas.
Realizar n buscas no manual de ajuda e validar os procedimentos su-
geridos.
12.2.3. Teste de Carga (Stress)

Essa categoria de testes tem por objetivo simular condições atípicas de utili-
zação do software, provocando aumentos e reduções sucessivas de transa-
ções que superem os volumes máximos previstos para o software, gerando
contínuas situações de pico e avaliando como o software e toda a infra-
estrutura estão se comportando. A idéia é avaliar como todo o conjunto da
solução lida com variações sucessivas de processamento. Esses testes são

recomendados para serem aplicados em softwares de missão crítica, pois reque-
rem muito esforço na operacionalização.
Elevando e reduzindo sucessivamente o número de transações simul-

tâneas.
Aumentando e reduzindo o tráfego de rede.
Aumentando o número de usuários simultâneos.
Combinando todos esses elementos.
12.2.4.Teste de Volume
Essa categoria de testes tem por objetivo determinar os limites de processa-
mento e carga do software e de toda infra-estrutura da solução. Contrário
aos testes de carga, esse tipo não focaliza oscilações de processamento, mas o
aumento contínuo dos parâmetros de execução.
É operacionalizado através de incrementos sucessivos de volume das
operações realizadas com o software, até que este atinja o limite máximo ao
qual toda a infra-estrutura está preparada para processar. A idéia é conhecer
os limites da solução e avaliar o quão próximo ou distante esses requisitos
estão deste limite.
Podem ser executados da seguinte forma:
Aumentando sucessivamente o volume de transações.

Aumentando sucessivamente o volume de consultas.
Aumentando sucessivamente o tamanho de arquivos a serem proces-
sados.
12.2.5. Teste de Configuração (Ambiente)

Essa categoria de testes tem por objetivo executar o software sobre diversas
configurações de softwares e hardwares. A idéia é garantir que a solução tec-
nológica “rode” adequadamente sobre os mais variados ambientes de pro-
dução previstos nas fases de levantamento dos requisitos. Esses testes são
recomendados para serem aplicados em softwares de missão crítica, pois reque-
rem muito esforço para operacionalizá-los.
Podem ser executados da seguinte forma:
Variando os sistemas operacionais (incluindo versões).

Variando os browsers.
Variando os hardwares que irão interagir com a solução.
Combinando todos esses elementos.
12.2.6. Teste de Compatibilidade (Versionamento)

Essa categoria de testes tem por objetivo executar o software interagindo
com as versões anteriores de outras aplicações ou dispositivos físicos (soft-
wares ou hardwares). Durante os procedimentos de mudança, é comum
ocorrer a “quebra de compatibilidade” de uma versão mais recente com a an-
terior, o que significa que alguma interface foi modificada (um layout de ar-
quivo, um parâmetro novo de uma função, uma alteração em um nome de
uma biblioteca), provocando incompatibilidade com as rotinas que utiliza-
vam essas interfaces.
A idéia aqui é garantir que as novas versões estão suportando antigas in-
terfaces, submetendo a aplicação a trocar informações com componentes
que utilizam os protocolos de versões anteriores. Esses testes podem ser exe-
cutados da seguinte forma:
Importando-se os dados gerados pela solução anterior

Comunicando-se com todas as versões de layout (atual e anteriores).
12.2.7. Teste de Segurança

Essa categoria de testes tem por objetivo detectar as falhas de segurança que
podem comprometer o sigilo e a fidelidade das informações, bem como pro-
vocar perdas de dados ou interrupções de processamento. Esses ataques à
segurança do software podem ter origens internas ou externas, provenientes
de hackers, quadrilhas especializadas, profissionais descontentes ou mesmo
pessoas com intenções de ganhos ilícitos.
A idéia é avaliar o nível de segurança que toda a infra-estrutura oferece,
simulando situações que provocam a quebra de protocolos de segurança, ex-
pondo quais são os pontos de maior fragilidade e risco de ocorrerem ataques.
Validar todos os requisitos de segurança identificados.

Tentar acessar funcionalidades e informações que requerem perfil
avançado.
Tentar invadir/derrubar o servidor de dados/internet.
Tentar extrair backups de informações sigilosas.
Tentar descobrir senhas e quebrar protocolos de segurança.
Tentar processar transações geradas de fontes inexistentes.
Tentar simular comportamento/infecção por vírus.
12.2.8. Teste de Performance (Desempenho)

Essa categoria de testes tem por objetivo determinar se o desempenho, nas
situações previstas de pico máximo de acesso e concorrência, está consisten-
te com os requisitos definidos. O critério de sucesso aqui estabelecido é em-
pregar o volume de transações e tempo de resposta obtidos nos testes e com-
pará-los com os valores-limite especificados.
Para esses testes, devemos especificar claramente o cenário que deseja-
mos obter e apontar quais são os tempos de resposta considerados factíveis à
realização de cada um. Omitir informações significa a criação de um cenário
irreal, impossibilitando avaliar se o desempenho está condizente com o es-
perado.
Validar todos os requisitos de desempenho identificados.

Simular n usuários acessando a mesma informação, de forma simultâ-
nea.
Simular n usuários processando a mesma transação, de forma simultâ-
nea.
Simular n% de tráfego de rede.
Combinar todos esses elementos.
12.2.9. Teste de Instalação

Essa categoria de testes tem por objetivo validar os procedimentos de insta-
lação de uma aplicação, bem como avaliar se estes possibilitam as várias al-
ternativas previstas nos requisitos identificados. A idéia é aplicar as muitas
variações de instalação (normal e as alternativas) e avaliar seu comporta-
mento durante esses procedimentos. Recomenda-se que o próprio usuário
realize essas instalações.
Realizar a primeira instalação do software.

Realizar a instalação de um software já instalado.
Realizar a instalação de atualização de um software.
Realizar a instalação de software em vários ambientes distintos.
Realizar todas as alternativas de instalação.
Validar pré-requisitos de instalação do software.
12.2.10. Teste de Confiabilidade e Disponibilidade

Essa categoria visa monitorar o software por um determinado período de
tempo e avaliar o nível de confiabilidade da arquitetura da solução. Essas in-
formações devem ser coletadas durante a execução dos próprios testes de
sistema, identificando sempre quando uma interrupção foi produzida por
uma falha da infra-estrutura (confiabilidade) e contabilizando o tempo ne-
cessário para resolução desse problema (disponibilidade).
Essas monitorações são interessantes de serem realizadas junto com os
testes de aceite (alpha-teste), nos quais o ambiente fica totalmente disponí-
vel para os usuários e a incidência de falhas está geralmente associada à in-
fra-estrutura da solução. Em outras situações, as interrupções provenientes
de defeitos de software prejudicariam os índices de confiabilidade e disponi-
bilidade da aplicação.
Os testes podem ser executados da seguinte forma:
Monitorar permanentemente o ambiente de aceite (alpha-teste).

Identificar todas as interrupções do ambiente (confiabilidade).
Identificar o tempo de interrupção do ambiente (disponibilidade).
12.2.11. Teste de Recuperação

Essa categoria tem por objetivo avaliar o comportamento do software após a
ocorrência de um erro ou de determinadas condições anormais. Algumas
aplicações suportam soluções de missão crítica, exigindo alto índice de dis-
ponibilidade do software. Nesse caso, a arquitetura da aplicação deve ser to-
lerante a falhas, ou seja, no caso de erros de qualquer natureza, o software
deve ter a capacidade de se manter em execução até que a condição de impe-
dimento desapareça. Os testes de recuperação devem também contemplar
os procedimentos de recuperação do estado inicial da transação interrompi-
da, impedindo que determinados processamentos sejam realizados pela me-

tade e sejam futuramente interpretados como completos.
Esses testes podem ser executados do seguinte modo:
Interromper o acesso à rede.

G por alguns instantes
G por um longo período
Interromper o processamento.
G desligar o micro
G desligar o servidor
Gerar arquivos, cancelar o processamento e avaliar se existem arqui-
vos gerados.
12.2.12. Teste de Contingência

Essa categoria de testes visa validar os procedimentos de contingência a se-
rem aplicados à determinada situação prevista no planejamento do softwa-
re. A idéia é simular os cenários de contingência e avaliar a precisão dos pro-
cedimentos. Esses testes devem ser realizados pela própria equipe de plan-
tão, na qual o tempo total de execução do plano de contingência também
será avaliado.
Os testes podem ser executados da seguinte forma:
Instalação emergencial de uma aplicação

Recuperação da perda de conexão da filial com a matriz.
12.3. Priorizando as Categorias de Testes

Um único sistema poderá ser submetido a várias categorias de testes, caben-
do a todas as áreas envolvidas no desenvolvimento do software estabelecer
quais categorias serão aplicadas durante os procedimentos de validação. O
critério para estabelecer quais categorias serão executadas deve estar basea-
do nas características do sistema e dos riscos envolvidos no projeto.
É fundamental compreender que existe uma relação delicada entre custo
e benefício dos trabalhos de testes. As categorias de testes mais importantes
são aquelas que irão garantir aspectos vitais do software. Outras categorias
irão atacar aspectos secundários e bem menos importantes. O fundamental é
entender que existe um esforço e custos envolvidos na decisão de empregar
ou não determinada categoria de testes.
Um instrumento simples a ser utilizado é a priorização das categorias

dentro da perspectiva de importância e risco relacionado ao sistema. Todos
os esforços dos testes deverão se concentrar nas categorias prioritárias, por
serem mais críticas ao software. As outras categorias deverão ser realizadas
em um segundo momento caso exista tempo e recursos para tal.
Uma forma eficiente de se estabelecer prioridades nas categorias de testes
é idealizar uma tabela na qual serão avaliadas as características mais críticas de
um software e submetê-las a todas as áreas que estão participando do processo
de desenvolvimento da aplicação. Como existe uma tendência natural das
áreas estabelecerem que tudo é altamente crítico, podemos definir que so-
mente três itens poderão receber o mesmo grau de importância, forçando to-
das as áreas a melhor avaliarem os pesos dados a cada critério definido.
Tabela 12.3
Exemplo de priorização das categorias de testes
Características da Aplicação Importância
01. Funcional Essencial

02. Desempenho Médio Impacto
03. Confiabilidade/Disponibilidade Alto Impacto
04. Segurança Essencial
05. Carga e Concorrência Alto Impacto
06. Usabilidade Médio Impacto
07. Compatibilidade Essencial
08. Portabilidade Baixo Impacto
09. Contingência Alto Impacto
10. Instalação Médio Impacto
11. Distribuição Alto Impacto
12. Recuperação Alto Impacto
Após a execução do levantamento, esses dados deverão ser compilados e

seus resultados apresentados formalmente às áreas, possibilitando que to-
dos comparem com suas impressões individuais e que tenham a oportunida-
de de discutir determinados pontos de conflito. Também é importante res-
saltar a todos que esse resultado será empregado como instrumento de prio-
rização dos testes, ou seja, as características que exercem maior preocupa-
ção com o grupo serão as primeiras a serem realizadas.
CAPÍTULO 13
Métodos Estruturados
de Validação
Como vimos, os métodos de verificação baseiam-se em técnicas de tes-

tes estáticos para avaliar a qualidade dos documentos gerados durante todas
as etapas do desenvolvimento do software; porém, para avaliarmos a quali-
dade de um sistema, devemos executar testes dinâmicos, de modo a subme-
ter o software a determinadas condições de uso e analisar se o comporta-
mento está de acordo com o esperado. Portanto, quanto maior o volume de
cenários ao qual será submetido, mais qualidade terá o software.
A utilização de métodos com o objetivo de identificar o maior número
possível de situações de testes é muito mais efetiva do que simplesmente
abordar o problema sem empregar alguma sistemática de trabalho. O objeti-
vo de identificar erros no software será mais abrangente se empregarmos al-
gumas técnicas para auxiliar na identificação dos cenários de testes.
13.1. Definindo Casos de Testes

Toda a ênfase dos testes de validação está nos métodos que visam identificar
todos os cenários possíveis de testes – os chamados casos de testes. Cada
um deles representa uma situação diferenciada e única de comportamento
no software, objetivando identificar um defeito não previsto durante todo o
ciclo de desenvolvimento. Como possuímos duas abordagens clássicas para
lidar com os testes de software (abordagens por requisitos ou estrutura in-
terna), as técnicas de obtenção de casos de testes sempre estarão associadas a
um desses dois critérios. Essa associação é fundamental para que a equipe de

desenvolvimento possa rastrear a origem dos casos de testes e, conseqüente-
mente, avaliar quais deles deverão ser aplicados quando alguma mudança
ocorrer nos itens originais (requisitos ou estruturas internas).
No entanto, os métodos a serem utilizados mudam conforme a aborda-
gem de testes que estamos empregando. Se estivermos realizando testes ba-
seados em requisitos, empregaremos determinadas técnicas para identificar
os casos de testes, o mesmo acontecendo para os testes baseados na estrutura
interna do software. Todas essas formas básicas têm papel fundamental para
garantir que o produto final venha comportar-se da forma mais adequada
possível. Portanto, cabe aos profissionais de testes produzirem um número
suficiente de casos de testes para cada abordagem existente.
A G H I J L Caso de Teste 1
A B I P J L Caso de Teste 2
A B C D E Caso de Teste 3
Caso de Teste 4
A B F E
Abordagem Caixa Branca

C D
B E
A
Início do F
Processamento Término do
Processamento
G H I J L
Figura 13.1 Técnicas caixa branca para obtenção dos casos de testes
Um dos maiores desafios de um processo de garantia da qualidade é con-

seguir medir o grau de qualidade alcançado nos testes de software. Se em
nosso entendimento o maior volume de casos de testes significa o maior nú-
mero de cenários adequadamente simulados e garantidos, então devemos
buscar todas as alternativas possíveis e inseri-las em nosso processo de teste
de software, de forma a refinar e ampliar o nível de cobertura alcançado.
É através dos casos de testes que poderemos monitorar os avanços da
qualidade de um software, avaliando os históricos de cobertura dos testes no
decorrer dos sucessivos ciclos de interações do desenvolvimento do software.
Métodos Estruturados de Validação
Requisito A Abordagem Caixa Preta

Caso de Teste A.1
Caso de Teste A.2
Caso de Teste A.3
Caso de Teste A.4
Requisito B
Caso de Teste B.1
Caso de Teste B.2
Caso de Teste B.3
Caso de Teste B.4
Figura 13.2 Técnicas caixa preta para obtenção dos casos de testes
Dessa forma, os casos de testes se transformam no elemento mais essencial

de um processo de teste de um software.
O processo de validação do software somente terá resultados efetivos se
os profissionais de testes conhecerem as principais técnicas de obtenção de
casos de testes. Devemos ter sempre em mente que a qualidade de um siste-
ma é determinada pelo que conseguimos “garantir” e isso será possível se
conseguirmos simular o maior número de cenários possíveis de execução.
13.2. Métodos Caixa Preta para Obtenção

dos Casos de Testes
Obter um software com qualidade garantida pressupõe a existência de um
processo de desenvolvimento que assegure o comportamento do software
comparando-o com os requisitos estabelecidos no início do projeto. Deve-
mos sempre entender que o principal objetivo de um processo de validação
de um software é a identificação de um conjunto de situações que serão em-
pregadas em forma de testes, com o objetivo de identificar erros.
Portanto, a maior variedade de cenários permitirá o maior conjunto de
simulações que serão avaliadas e comparadas com os requisitos contratados,
o que torna importante a utilização de métodos que permitam identificar o
maior número de casos de testes, de forma a garantir a maior variedade de
cenários de execução do sistema.
13.2.1. Método de Decomposição de Requisitos

Como sabemos, os requisitos direcionam todo o processo de desenvolvi-
mento de software. Cada requisito de software carrega consigo um conjunto
de cenários possíveis dentro de uma realidade do sistema que irá atendê-lo.
A decomposição de um requisito em cenários é fundamental para explo-

rarmos todas as possibilidades envolvidas na dinâmica do software. É im-
prescindível explorarmos todos os cenários possíveis para cada requisito
existente. Didaticamente, poderemos decompor cada requisito em três ce-
nários distintos:
Cenário Primário: trata-se da situação mais básica de compreensão de

um requisito de software. Aqui devemos idealizar um cenário ótimo,
no qual não existam problemas ou exceções a regras. Trata-se da re-
presentação de um cenário perfeito que será usada como linha mestra
para entendermos os outros cenários existentes.
Cenários Alternativos: são as variações possíveis dentro do cenário
primário, isto é, os caminhos alternativos ou situações equivalentes
que conduzirão ao mesmo objetivo. Pagar com cartão, cheque ou vale-
transporte é uma variação da forma de pagamento. Pagar à vista ou
parcelado é uma variação das condições de pagamento.
Cenário de Exceção: trata-se de possíveis problemas e inconsistências
que impedem a finalização de determinado requisito. São todas as
condições impeditivas que podem ocorrer a qualquer requisito. Um
cliente não cadastrado, um cartão inválido ou problemas com cheques
devolvidos são impeditivos para que uma venda ocorra.
SISTEMA DE VENDAS
Cenário Primário
• Cliente realiza pagamento em dinheiro.
Cenários Alternativos
• Cliente realiza pagamento com cheque.
• Cliente realiza pagamento com cartão de crédito.
Realizar • Cliente realiza pagamento parcelado.
Pagamentos • Cliente realiza pagamento da última parcela.
• Cliente realiza pagamento adiantado.
• Cliente realiza pagamento em atraso.
Cenários de Exceção
• Cliente realiza pagamento com cartão inválido.
• Cliente realiza pagamento com cheque bloqueado.
• Cliente realiza pagamento com cheque e histórico de mau pagador.
Figura 13.3 Decomposição de requisitos em cenários de testes

13.2.2. Método de Análise de Documentos

Um outro método muito efetivo para a identificação dos casos de testes é a
utilização de documentos que são produzidos com a intenção de detalhar
comportamentos e regras de negócios. Qualquer documento pode conter
elementos fundamentais para auxiliar na localização de novos casos de tes-
tes e no refinamento e ampliação do esforço de planejamento dos testes. No
caso do projeto de software empregar a UML como padrão de documenta-
ção, as principais fontes para obter os casos de testes são os diagramas de ati-
vidades e os diagramas de estados.
O diagrama de atividades pode representar todo o fluxo de processa-
mento de um determinado evento de negócio, revelando todos os caminhos
alternativos (caminhos positivos) e as situações que impossibilitam a finali-
zação desse evento (cenários negativos). Um bom diagrama de atividades
deverá revelar o conjunto completo de casos de testes que deverão ser inseri-
dos no planejamento dos testes. No caso de eventos de negócios complexos,
esse diagrama poderá ser desmembrado em outros diagramas de atividades,
devendo também ser contemplado na modelagem de cenários de testes. É mui-
to comum, no diagrama de atividades, a omissão dos fluxos que conduzem
às situações de impedimento do processo, o que pode levar ao profissional
de teste a falsa idéia de que não existem cenários negativos nesse diagrama.
Diagrama de
A Atividades Casos de Testes
Identificados
Diagrama de
Casos de Uso Cenários Positivos
A E
B A F E
Cenários Negativos
F C
A B
D A C
A D
E
Figura 13.4 Diagrama de atividades como fonte de identificação

dos casos de testes
Outro exemplo de como podemos obter os casos de testes empregando a

documentação existente no projeto de software é o diagrama de estado,
que, a seguir, representa o ciclo de vida de um livro. Cada transição de um
estado para outro do livro deverá ser considerada um caso de teste (cenários
positivos), enquanto que as transições “proibidas” deverão ser inseridas
como cenários negativos, uma vez que também deverão ser testadas.
Diagrama de Casos de Testes

Estados Identificados
Doação
Destruição
Cenários Cenários
Compra
Positivos Negativos
1 6
Catalogação Refugado 1 2
1 1 3
Classificação Refugo
1 2 2 4
2 5 2 3 3 5
Recuperação
Disponível Restauração 3 4 4 6
4 2 5
Empréstimo Disponibiliza Restaurar
4 5 6 4
3 4 5 6
Devolução
Emprestado Análise 6
Figura 13.5 Diagrama de estados como fonte de identificação

dos casos de testes
13.2.3. Métodos Caixa Branca para Obtenção

dos Casos de Testes
Quando trabalhamos com testes de caixa branca, estamos planejando os
testes de forma a melhor exercitar as estruturas internas do software em
busca do maior número possível de erros. Os métodos aplicados nos tes-
tes de caixa branca são técnicas bem diferentes das aplicadas nos métodos
de caixa preta.
Os métodos que serão aqui apresentados deverão guiar todos os traba-
lhos de levantamento e identificação dos casos de testes a serem aplicados na
estratégia caixa branca. Esses cenários de testes devem ser modelados para
que atendam ao maior número de situações, exigindo o menor esforço pos-
sível para executá-los.
13.2.4. Método de Cobertura de Linhas de Código

Esse é o método mais tradicional de cobertura de testes de caixa branca, pois
trata-se da forma mais simplificada de medição existente nesse tipo de estra-
tégia. Nessa abordagem, os testes de cobertura são medidos pelo número de
linhas que são “acionadas” sempre que determinado conjunto de casos de

testes é executado. Dessa forma, se determinado código-fonte possui 100 li-
nhas e durante a execução dos testes conseguimos executar 87, nossos testes
obtiveram 87% de cobertura do código-fonte.
O grande objetivo nesse tipo de cobertura de testes é conseguir alcançar
100% da execução do código-fonte, o que equivale a dizer que todas as li-
nhas foram exercitadas ao menos uma vez durante a execução dos testes.
Apesar de não ser impossível atingir a cobertura total das linhas do códi-
go-fonte, essta tarefa é complexa e muito trabalhosa, exigindo certo grau de
determinação do profissional que cuidará desses testes.
Inicialmente a tarefa parece ser simples, porque com poucos casos de
testes, conseguimos alcançar mais do que 65% da cobertura do código-
fonte. Isso ocorre porque um único caso de teste exercitará grande parte
das linhas disponíveis. À medida que inserimos mais casos ao nosso pro-
cesso de teste, percebemos que a progressão dos trabalhos caminha em um
ritmo bem lento porque a maioria dos casos de testes que serão inseridos
posteriormente possui um mesmo fluxo de processamento, diferenciando-
se em pequenos trechos do código. Dessa forma, será necessário um grande
conjunto de casos de testes para que consigamos obter a cobertura comple-
ta, o que significa grande esforço para se atingir a meta.
Código-fonte Caminho Básico Caminho Alternativo Caminho-Exceção

Completo 75% de Cobertura 86% de Cobertura 100% de Cobertura
A A A A
F F F F
E B E B E B E B
C C C C
D D D D
Figura 13.6 Progressão de cobertura do código-fonte

13.2.5. Método de Cobertura de Caminhos

É muito comum encontrarmos profissionais de testes que desconheçam ou-
tros métodos de cobertura relacionados aos testes de caixa branca. Devemos
entender que atingir 100% do código não significa estar diante de um soft-
ware sem defeitos, mas que nossos casos de testes conseguiram exercitar to-
das as instruções de um código-fonte, o que é insuficiente para a detecção de
todos os defeitos de execução do software. É por isso que outros modelos
ampliam a simplificada visão da cobertura de linhas de código e aumentam
as chances de detecção dos defeitos de software.
Nesse modelo de cobertura de testes de caixa branca, o foco está na análi-
se de todos os fluxos alternativos de processamento de determinado código-
fonte. O objetivo é identificar um conjunto de casos de testes que possibili-
tem exercitar todos os possíveis caminhos de execução e localizar falhas de
iniciação de variáveis ou mesmo fluxos não previstos de processamento, que
podem conduzir a erros de execução.
Código-Fonte Caminho #1 Caminho #2 Caminho #3 Caminho #4

Completo if1=N e if2=N if1=S e if2=N if1=N e if2=S if1=S e if2=S
A A A A A
If1 = ? B B B B B
C C C C C
If2 = ? D D D D D
E E E E E
F F F F F
Figura 13.7 Progressão da cobertura de caminhos do código-fonte
Esse modelo de cobertura analisa a estrutura interna de cada rotina exis-

tente no código-fonte e identifica todos os casos de testes que representam
todos os fluxos internos de processamento, de forma a exercitar todos os ca-
minhos que o software suportará no ambiente de produção.
Por ser muito complexo estabelecer uma cobertura integral de todos os
eventuais caminhos de processamento de um software, esse método de co-
bertura é direcionado apenas em trechos dos códigos-fonte que representam

alta criticidade de processamento ou que necessitam de precisão nas opera-
ções aritméticas, como os conhecidos cálculos matemáticos, as análises fi-
nanceiras e operações de segurança de acesso (rotinas de criptografia, vali-
dação de transações financeiras e outras operações).
13.2.6. Método de Cobertura de Desvios Condicionais

Essa técnica tem por objetivo detectar erros nas condições lógicas aplica-
das no código-fonte. Os casos de testes são construídos de forma a permitir
variação dos valores que determinam a execução dos diversos fluxos alter-
nativos existentes no código-fonte. O desenho interno do software é o
principal elemento para a modelagem dos casos de testes. Podemos aplicar
três níveis diferentes de refinamentos para cobrir o maior número de
condições possíveis:
Cobertura de Os casos de testes devem ser suficientes para que cada

Múltiplas condição existente seja combinada com todas as outras
Condições condições possíveis.
Cobertura Os casos de testes devem ser suficientes para que cada

de condição simples assuma valores verdadeiro ou falso
Condições pelo menos uma vez.
Cobertura Os casos de testes devem ser suficientes para que cada

de condição composta assuma os valores verdadeiro e falso
Decisões pelo menos uma vez.
Figura 13.8 Níveis de cobertura de desvios condicionais
Cobertura de Decisões
Esse método de cobertura avalia se todas as decisões existentes no código-
fonte são exercitadas durante a execução dos testes de caixa branca. Signifi-
ca que cada IF... THEN... ELSE... ENDIF, ou comando similar encontrado
nos fontes, terão casos de testes que assumirão os valores verdadeiro ou fal-
so. Isso garante que toda decisão de processamento existente tenha seus
possíveis caminhos adequadamente exercitados.
Cobertura de Condições
Contrário à cobertura de decisões, que leva em consideração apenas os co-
mandos que executam desvios de processamento, esse modelo de cobertura
focaliza a expressão que representa a condição de desvio existente no códi-
go-fonte.
Em uma condição de desvio do tipo IF idade>=18 AND sexo=“M”
THEN... o que será focalizado será a expressão idade >= 18 e sexo = “M”. Os
casos de testes deverão cobrir individualmente todas as condições possíveis:
[idade<18; idade=18; idade>18] e [sexo=M; sexo< >M]. Aí, com apenas
três casos de testes, atenderíamos a todos os cenários de execução possíveis:
CT1=[i=17,s=’M’]; CT2=[i=18;s=’F’]; CT3=[i=19;s=’F’].
Cobertura de Múltiplas Condições

Esse modelo emprega o mesmo critério do tópico anterior, diferenciado-se
apenas pelo fato de que os casos de testes devem contemplar todas as múlti-
plas combinações possíveis.
Nesse modelo de cobertura, para a mesma expressão idade>=18 AND
sexo=“M” serão necessários seis casos de testes para atender às múltiplas
condições de testes:
CT1=[i=17,s=’M’]; CT2=[i=17;s=’F’], CT3=[i=18,s=’M’];
CT4=[i=18;s=’F’], CT5=[i=19,s=’M’]; CT6=[i=19;s=’F’].
13.2.7. Método de Cobertura de Laços

Os erros mais comumente encontrados em laços de programação são os re-
ferentes à falta de iniciação de variáveis (ocorre quando o laço não é executa-
do), quando as variáveis sofrem iniciações contínuas (ocorre quando um
trecho do código está inserido incorretamente dentro do laço de execução)
ou quando um laço atinge seu limite de execução (ocorre quando determi-
nada variável possui uma dimensão limite).
Os testes de laços concentram-se exclusivamente na lógica dos laços de
programação inseridos nos códigos-fonte. Trata-se de um conjunto de ins-
truções que devem ser executadas até a satisfação de determinada condição.
Os laços apresentam-se em quatro configurações distintas, envolvendo pro-
cedimentos de testes diferenciados:
Sendo a condição: ((A+B) > C) e ((D+E) = F)
...
Verdadeiro Falso
?
... ...
CASOS DE TESTES
Cobertura • ((A+B) > C) e ((D+E) = F) = Verdadeiro

• ((A+B) > C) e ((D+E) = F) = Falso
de
Decisões
CASOS DE TESTES
• ((A+B) MAIOR QUE C) e ((D+E) IGUAL A F)

• ((A+B) MENOR QUE C) e ((D+E) IGUAL A F)
Cobertura
• ((A+B) IGUAL A C) e ((D+E) IGUAL A F)
de • ((A+B) MAIOR QUE C) e ((D+E) MENOR QUE F)
Condições • ((A+B) MAIOR QUE C) e ((D+E) MAIOR QUE F)
CASOS DE TESTES
• ((A+B) MAIOR QUE C) e ((D+E) MAIOR QUE F)

Cobertura • ((A+B) MAIOR QUE C) e ((D+E) IGUAL A F)
• ((A+B) MAIOR QUE C) e ((D+E) MENOR QUE F)
de
• ((A+B) IGUAL A C) e ((D+E) MAIOR QUE F)
Múltiplas
• ((A+B) IGUAL A C) e ((D+E) IGUAL A F)
Condições • ((A+B) IGUAL A C) e ((D+E) MENOR QUE F)
• ((A+B) MENOR QUE C) e ((D+E) MAIOR QUE F)
• ((A+B) MENOR QUE C) e ((D+E) IGUAL A F)
• ((A+B) MENOR QUE C) e ((D+E) MENOR QUE F)
Figura 13.9 Volume dos casos de testes em relação ao modelo

de cobertura de desvios
Laço Falta de Iniciação Iniciação Estouro

OK de Variáveis Contínua Variável Indexada
OK Erro Erro Erro
A=0
A=0 A=0 A=0 Soma[7]
A=A+1 A=A+1
A=A+1 A=A+1 A Soma[A]
A A A<=8
A<8
Figura 13.10 Erros comuns em laços encontrados nos códigos-fonte
SIMPLES ANINHADOS CONCATENADOS NÃO ESTRUTURADOS
Figura 13.11 Tipos de laços encontrados nos códigos-fonte
Laços Simples
Para testar um laço simples que não possua restrição referente à sua freqüên-
cia de execução, os casos de testes abaixo atenderiam a todas as condições de
execução a serem analisadas. Nesse tipo de laço simples, não existe um limi-
te de execução, podendo ser infinitamente processado.
Não executar o laço.

Executar uma iteração do laço.
Executar duas iterações do laço.
Para testes de laços simples cujo número máximo de iterações possíveis

é “n” (limites de execução determinados por arrays), os casos de testes são
mais numerosos, pois também contemplam os testes com o controle de limi-
tação do laço.
Não executar o laço.

Executar uma iteração do laço.
Executar duas iterações do laço.
Executar n iterações do laço.
Executar n+1 iterações do laço.
Laços Aninhados
Os laços aninhados são estruturas de laços montadas uma dentro da outra,
criando uma verdadeira árvore lógica de execução. A abordagem utilizada
nos testes de laços simples não é recomendável, pois o número de casos de
testes pode ser proibitivo. Para reduzir o volume de casos de testes, devemos
adotar os seguintes procedimentos:
Deve-se iniciar o teste a partir do laço mais interno, aplicando a técni-

ca de teste de laço simples. Nesse ponto, os outros laços devem reali-
zar apenas uma iteração.
Partindo-se do laço mais interno para o mais externo, nessa ordem,
devemos testar cada um deles com a mesma abordagem dos testes de
laços simples, sendo que os laços internos já foram testados e pode-
riam assumir qualquer número de iterações.
Laços Concatenados
Os laços concatenados são estruturas de laços seqüencializados pela lógica
definida na estrutura do código-fonte. Se esses laços concatenados forem in-
dependentes entre si, recomenda-se a utilização da técnica de laços simples.
Entretanto, se esses laços são dependentes, ou seja, o contador do primeiro é
usado como valor inicial do próximo laço, recomenda-se a utilização da téc-
nica de laços aninhados.
Laços Não Estruturados

A utilização desse tipo de laço revela má prática de programação e deve ser
evitada, mesmo que a linguagem de programação ofereça esse recurso. Este
é conhecido como desvio “não condicional” e apresenta-se na forma do co-
mando GOTO, um velho conhecido de programadores. Os fontes que uti-
lizam esse recurso invariavelmente são difíceis de entender e manter, pro-
piciando a introdução de erros nas eventuais manutenções do código. Mui-
tas vezes, esses comandos são empregados da mesma forma que tradicional-
mente usamos os comandos FOR... NEXT, DO... WHILE ou REPEAT...
UNTIL, tornando esse comando tão comum como os outros. No entanto,
seria prudente que este fosse substituído por seus correspondentes mais tra-
dicionais, a fim de evitar as más práticas de programação.
13.3. Métodos de Refinamento dos Casos de Testes

Os refinamentos são técnicas que possibilitam aumentar a extensão de cober-
tura e ampliar os cenários que representam os casos de testes alternativos e de
exceção. Quando estamos planejando os testes, devemos identificar o menor
conjunto de cenários que cubra o maior número de situações possíveis. É fun-
damental identificar os casos de testes que tenham a maior probabilidade de
revelar defeitos e eliminar os casos redundantes de forma a aumentar a efi-
ciência do processo de identificação de erros, com o menor esforço possível.
13.3.1. Refinamento por Partição de Equivalência

A partição de equivalência é um método que divide o domínio de entrada de
dados em classes (grupos de valores). Cada classe representa um possível
erro a ser identificado, permitindo que os casos de testes redundantes de
cada classe identificada sejam eliminados sem que a cobertura dos cenários
existentes seja prejudicada.
Cada entrada deve ser analisada objetivando identificar um conjunto de
valores válidos e inválidos. Desse conjunto, extraímos as classes e obtemos os
casos de testes. Exemplificando, em um sistema de gestão de contratos, a ida-
de válida dos clientes varia entre 18 e 120 anos. As classes identificadas são os
valores abaixo de 18, valores entre 18 e 120, valores acima de 120. Para cada
uma dessas classes, existem um conjunto de valores que têm, potencialmente,
a mesma capacidade de detectar erros, sendo dispensável a execução de vários
testes para valores pertencentes à mesma classe de equivalência.
Tabela 13.1
Exemplo de refinamento por partição de equivalência
Entrada Valores Classes Casos

Permitidos de Teste
Idade Número entre 18 a 120 Idade = 20

(esse valor é obtido através da 18 e 120 < 18 Idade = 10
digitação da data de aniversário)
> 120 Idade = 150
13.3.2. Refinamento por Valores-limite

Esse método é complementar à partição por equivalência. Na abordagem
anterior, qualquer valor dentro de uma classe identificada seria candidato ao
caso de teste selecionado. Aqui, os valores-limite são os casos de testes natu-
rais de cada classe identificada. Em tese, o software está mais susceptível ao
erro nas fronteiras dos domínios de dados do que propriamente nas regiões
centrais, portanto, utilizar casos de testes que percorram as fronteiras dos
domínios aumenta mais a probabilidade de identificação de erros.
Outra diferença é que, no método de partição por equivalência, o foco
estava nas condições de entrada, enquanto que as condições de saída não
eram exploradas. Nesse método de análise de valores-limite, tanto os valores
de entrada quanto os de saída deverão ser analisados.
Tabela 13.2
Exemplo de refinamento por valores-limite
Entrada Valores Classes Casos de

Permitidos Teste

(esse valor é obtido através da 18 e 120 Idade = 120
< 18 Idade = 17
> 120 Idade = 121
Negativa Idade = – 18
(data futura)
Perceba que, no método de partição por equivalência, os casos de testes

empregam um valor qualquer desde que este represente adequadamente a
classe de equivalência. Aqui, a abordagem é complementada, empregando
valores-limite aos casos de testes, aumentando as chances de identificação

de um problema sem ampliar o número de casos de testes.
Também foi criada mais uma classe dentro das já existentes – a classe
Idade Negativa. Essa classe foi identificada como uma eventual saída possí-
vel caso o software venha “erradamente” aceitar idades negativas (datas de
nascimento superiores ao dia corrente), como uma idade válida.
13.3.3. Refinamento por Probabilidade de Erro

Esse método é um velho conhecido dos desenvolvedores porque está basea-
do na intuição e experiência de testar condições que normalmente provo-
cam erros. Produz bons resultados, pois concentram alta probabilidade de
identificação de defeitos no software. Um histórico de origens de erros bem
montado poderá destacar quais situações são as mais recorrentes e ampliar o
conjunto de itens mais problemáticos. Abaixo estão alguns dos mais tradi-
cionais erros que a equipe de desenvolvimento comete na hora de imple-
mentar softwares:
Tabelas Vazias ou Nulas: Ocorre quando existem processamentos

que lidam com tabelas do banco de dados ou arquivos-texto sem infor-
mação, produzindo listas vazias que não estavam previstas pelo pro-
gramador. Um exemplo dessa situação é entrarmos em uma tela de ca-
dastramento sem que existam informações nesse cadastro. Nessa situa-
ção, é comum o software provocar um erro ao acessar a tela.
Nenhuma Ocorrência: Ocorre quando executamos alguma operação
porém não existem informações a serem processadas. Um exemplo
disso é uma tela na qual são apresentados pedidos pendentes de pro-
cessamento e que podem ser visualizados através de um simples “du-
plo clique”. Caso não existam pedidos pendentes e seja realizada a vi-
sualização dos pedidos, o software poderá provocar erro de execução.
Primeira Execução: É muito comum ocorrerem erros que somente se
manifestam na primeira vez que executamos uma determinada opera-
ção. Um bom exemplo disso é a abertura de uma conta corrente, na
qual existe uma iniciação do saldo dessa conta. Quando formos execu-
tar a primeira operação para movimentar a conta, a operação de soma
ou subtração do saldo falha porque este não foi iniciado com ZERO,
mas sim com o valor NULO, impossibilitando a operação: sld_conta =
sld_atual + vlr_deposito.
Valores Brancos ou Nulos: Ocorre na entrada de dados ou durante a

leitura de registros de uma tabela. Muitas vezes, os programadores
não prevêem que determinadas informações “obrigatórias” não estão
sendo corretamente preenchidas e o processamento gera um erro de
execução.
Valores Inválidos e Negativos: Esse erro ocorre freqüentemente após
a entrada de dados incorretos, provocados pelo processamento equi-
vocado de determinadas informações inconsistentes que conseguiram
ser digitadas pelo usuário.
Tabela 13.3
Exemplo de refinamento por probabilidade de erro
Entrada Valores Classes Casos de

Permitidos Teste

(esse valor é obtido através da 18 e 120 Idade = 120
< 18 Idade = 17
> 120 Idade = 121
Zero Idade = Zero
Negativa Idade = – 18
(data futura)
Branco Idade = Nula
(data não
digitada)
Inválida Idade =
Inválida
(data
incorreta)
CAPÍTULO 14
Analisando Cada Fase

dos Testes de Validação
Em determinado momento do projeto, todos os levantamentos e deci-

sões realizadas são materializados em produtos tecnológicos que foram
construídos para atender às especificações definidas na etapa inicial do pro-
cesso. Os testes de validação têm por objetivo avaliar a qualidade desse pro-
duto nas mais variadas dimensões possíveis: em relação à sua estrutura in-
terna, na aderência às regras de negócios estabelecidas, nos parâmetros de
performance esperados pelo produto, na total compatibilidade com uma lis-
ta de ambientes na qual a solução será executada, além de uma série de ou-
tras categorias de testes que poderíamos aplicar.
Ao contrário dos testes de verificação, que atuam em artefatos e procedi-
mentos de trabalho, os testes de validação são aplicados diretamente nos soft-
wares que estão sendo construídos, tendo a árdua missão de identificar erros
que foram introduzidos na solução tecnológica no decorrer do projeto.
Os testes de baixo nível são assim caracterizados por exigir dos profissio-
nais de testes um profundo conhecimento da estrutura interna do produto.
Podem ser realizados pelo próprio desenvolvedor ou por um profissional
dedicado a essa finalidade. Essa decisão depende da maturidade organizacio-
nal, criticidade da aplicação, disponibilidade de recursos e das restrições or-
çamentárias do projeto.
Analisando Cada Fase dos Testes de Validação
Tabela 14.1
Análise das fases dos testes de validação
Fase da Categorias de Características da Fase de Validação

Validação Testes Aplicadas
Teste de G Estrutura Interna G Estratégia caixa branca e caixa

Unidade G Funcionalidade preta.
G Usabilidade G Testa partes do software.
Teste de Baixo Nível
G Segurança G Requer conhecimento da estrutura

interna.
G Executada pelo desenvolvedor ou
profissional de teste.
Teste de G Interfaces G Estratégia de caixa branca e caixa
Integração G Dependências preta.
entre G Testa integrações entre partes do
Componentes software.
G Requer conhecimento da
arquitetura interna do software.
G Executada pelo desenvolvedor ou
profissional de teste.
Teste de G Funcionais G Estratégia de caixa preta.
Sistema G Não Funcionais G Os testes são aplicados no
• Performance software como um todo.
• Instalação Não requer conhecimento da
Teste de Alto Nível
• Recuperação estrutura interna do software.

• Carga G Requer ambiente muito
semelhante ao da produção.
G Deve ser executada por um grupo
de teste independente.
Teste de G Funcional G Estratégia de caixa preta.
Aceitação G Usabilidade G Os testes são aplicados no
G Segurança software como um todo.
G Não requer conhecimento da
estrutura interna do software.
G Requer ambiente muito
semelhante ao da produção.
G Deve ser executado pelos usuários
finais.
Os testes de alto nível são assim caracterizados por não requererem

conhecimento da estrutura interna do produto, possibilitando testes com maior
“nível de abstração”. Esses testes são executados por uma equipe indepen-
dente de testes, sendo guiados pelas especificações de negócio e pela lista de
requisitos do software.
14.1. Validação da Unidade

A validação da unidade de software é a primeira etapa do processo de valida-
ção que tem por objetivo testar componentes individuais de uma aplicação.
Essencialmente, os testes unitários são orientados à estrutura interna de im-
plementação do componente que estaremos validando, o que os caracteriza
como testes de caixa branca. Nessa estratégia de testes, o objetivo é executar
o software de forma a exercitar adequadamente toda a estrutura interna de
um componente, como os desvios condicionais, os laços de processamento e
todos os possíveis caminhos alternativos de execução. Dessa forma, estare-
mos validando a estrutura interna do componente e atestando a capacidade
de processamento sob os mais variados cenários de execução.
Todo componente de software deve ser criado para atender a um deter-
minado conjunto de requisitos que foram identificados durante o processo
de desenvolvimento da aplicação. São eles que justificam a existência desse
componente dentro da arquitetura tecnológica idealizada pela equipe de ar-
quitetos de software; porém, mesmo um componente com uma estrutura in-
terna perfeita validada adequadamente por um conjunto completo de testes
de caixa branca pode não estar contemplando adequadamente todos requi-
sitos que foram estabelecidos e relacionados a esse componente. Desta for-
ma, a validação de uma unidade de software somente será completa se apli-
carmos testes em sua estrutura (caixa branca) e testes que validem seus re-
quisitos (caixa preta).
Unidade • Traduzir os modelos em estruturas internas dos códigos.

Especificada ou • Traduzir os requisitos de negócios, regras e comportamentos em
Modificada código-fonte.
5
Validação • Garantir máxima cobertura do código-fonte.

da • Garantir o processamento de diferentes caminhos.
Unidade • Garantir que determinados requisitos estejam implementados.
Figura 14.1 Objetivo da validação da unidade de software
O objetivo dos testes de unidade de software (ou testes unitários) é

garantir a qualidade de determinado componente tecnológico, avalian-
do sua estrutura interna e a perfeita adequação com seus requisitos.
Abaixo estão relatados alguns exemplos de pontos de validação que po-
deriam ser considerados críticos para avaliar a qualidade dos compo-
nentes de software.
Pontos de validação de testes unitários que empregam métodos de caixa branca
Exercitar todas as linhas de código existentes no código-fonte.

Exercitar todos os desvios condicionais existentes no código-fonte.
Exercitar todos os fluxos alternativos de processamento.
Pontos de validação de testes unitários que empregam métodos de caixa preta
Validar todos os requisitos funcionais relacionados ao componente.

Validar todos os requisitos de usabilidade relacionados ao componente.
Validar todos os requisitos de sistema relacionados ao componente.
14.1.1. Validação de Unidades com Testes

de Caixa Branca
Os testes unitários que empregam métodos de caixa branca têm por objetivo
examinar detalhadamente segmentos do código-fonte e simular o processa-
mento dos componentes, de modo a exercitar sua estrutura interna da forma
mais variada possível, avaliando se o código-fonte da unidade testada está
adequadamente implementado para suportar todos os fluxos de processa-
mento planejados nos testes.
Para executar os testes de caixa branca será necessário construir um con-
trolador de testes com o objetivo de disparar rotinas “encapsuladas” na uni-
dade de software e avaliar os resultados gerados e compará-los com o espera-
do. Os controladores deverão produzir um log de execução, identificando
quais casos de testes obtiveram sucesso e quais falharam, permitindo a cor-
reção dos pontos de não-conformidade da unidade de software. Esse mesmo
processo será executado até que a unidade não apresente falhas na sua estru-
tura interna.
A grande desvantagem dessa configuração de testes é o fato de exigir
um profissional de grande experiência na linguagem de desenvolvimento a
qual o software está implementado, e um alto nível de compreensão e co-
nhecimento de toda a arquitetura interna do projeto tecnológico, bem
como padrões utilizados, modelo de dados, ferramentas de desenvolvi-
mento utilizadas, o que exigiria do profissional total envolvimento no pro-
cesso de criação do software (isso não quer dizer pertencer à equipe de de-
senvolvimento).
Log de
Caso de Execução
Caso de
Teste
Teste
Caso de << Software >>
Teste << Testware>>
Controlador
Resultado
de Testes
doResultado
Teste
do Resultado
Teste
do Teste
Figura 14.2 Objetivo da validação da unidade de software
Por esse motivo, é natural que essas atividades sejam transferidas para o
próprio desenvolvedor das unidades de software, pois este possui toda a car-
ga de conhecimento necessária para realizar as atividades. O grande proble-
ma aqui é o chamado conflito de interesses: o desenvolvedor está sempre
sendo pressionado a construir softwares com rapidez, o que significa que
testar sempre será uma atividade secundária para ele.
A utilização de um ou mais profissionais para integrar o processo de
desenvolvimento e aplicar os testes de caixa branca é altamente aconselhá-
vel, pois eliminaria os riscos de os testes serem superficiais e pouco eficien-
tes. Se o gerente do projeto de desenvolvimento está vendo esses recursos
como custos adicionais, recomendo avaliar quanto dos projetos anteriores
foram gastos com manutenção corretiva. Se essas informações forem le-
vantadas (o que normalmente nunca ocorre), veremos que o modelo no
qual estamos trabalhando há anos baseia-se na premissa de que essas cor-
reções são características naturais de projetos de softwares complexos e
que nada podemos fazer para lidar com o problema. Devemos sempre lem-
brar que são essas falhas que encarecem e inviabilizam o produto e serviços
de software, que reduzem as margens de lucro e que impedem o aumento
de produtividade da equipe.
14.1.2. Validação de Unidades com Testes

de Caixa Preta
Para os testes de caixa preta aplicados em unidades de software, as valida-
ções serão baseadas na arquitetura da aplicação, sendo possível identificar
quais requisitos são mais adequados aplicar durante os testes de cada unida-
de. Projetos orientados a objetos normalmente são separados em pacotes de
especialização (packages) que facilitam a organização e representam melhor
a arquitetura aplicada ao projeto de software. Cada pacote existente agrupa

um conjunto de componentes que tem as mesmas características e finalida-
des, possibilitando identificar um padrão único de abordagem dos testes:
User Packages: Para pacotes de componentes que lidam especifica-

mente com a interface do usuário (telas de cadastramento, consul-
tas e visualização de relatórios), deveríamos aplicar testes baseados
em requisitos de usabilidade, pois testariam todas as opções de na-
vegações, padrões de telas e cores, acesso fácil a mecanismos de aju-
da, digitações de dados inválidos e não digitação de campos obriga-
tórios.
Business Packages: Para pacotes de componentes que lidam especifi-
camente com as transações de negócios da aplicação (saques, depósi-
tos, transferência intercontas, transferência interbancária, extrato de
movimentação, aplicação e resgate de investimentos), deveríamos
aplicar testes baseados nos requisitos funcionais, pois testariam todas
os cenários básicos, alternativos e de exceção que estão vinculados às
regras de negócios da aplicação.
Data Packages: Para pacotes de componentes que lidam especifica-
mente com as transações de dados (tabelas de banco de dados, sto-
red-procedures, extratores de dados externos, transações de backup e
recuperação de dados), deveríamos aplicar testes baseados nos re-
quisitos de armazenamento e de recuperação das informações.
Utilities-Packages: Para pacotes de componentes utilitários que
apóiam e reduzem os esforços do desenvolvimento de outros paco-
tes (acesso ao banco de dados, controle de arquivos físicos, comu-
nicação com sistemas office-automation, bibliotecas de criptogra-
fia), deveríamos aplicar testes baseados em requisitos de sistemas
coletados durante o desenrolar do projeto de software. Esses requi-
sitos são gerenciados corporativamente pela organização para que
todos os outros projetos possam se beneficiar desses componentes
utilitários.
<< Software >> <<Testware >>

Arquitetura da Aplicação Arquitetura dos Testes
Requisitos:
<<Software>> <<Testware>>
Usabilidade
User User
Packages TestPacks
Requisitos:
Funcionais
Business Business
Packages TestPacks
Requisitos:
Armazenamento e
Recuperação de Dados
Data Data
Packages TestPacks
Requisitos:
Sistemas
Utilities Utilities
Packages TestPacks
Figura 14.3 Testes unitários baseados na arquitetura da aplicação
14.1.3. Validação de Unidades com Abordagem Isolada

Nesse tipo de abordagem, as unidades são testadas de forma totalmente iso-
lada das demais, eliminando a dependência existente entre outras unidades
de software. Isso possibilita que os testes ocorram em qualquer seqüência ou
momento do projeto de desenvolvimento, uma vez que os componentes que
são acionados por essa unidade não necessitam estar prontos ou funcionan-
do corretamente. Em contrapartida, esse tipo de configuração dos testes
unitários exige grande esforço de criação de simuladores (que não são sim-
ples de projetar e implementar) para cada componente que é acionado pela
unidade que será alvo dos testes.
Os testes isolados de unidades de software permitem uma condição per-
feita para um ambiente de testes. Primeiro porque eliminam dependências,
não sendo necessária a existência física de outros componentes para que
você possa testar sua unidade. Segundo, sem essas dependências, não existe
seqüência de execução dos testes, permitindo a realização de testes paralelos
de unidades, eliminando o gerenciamento dos pré-requisitos dos testes (so-
mente realizar os testes dessa unidade quando os componentes F, G e H fo-
ram construídos e validados).
Pela própria estratégia dos testes isolados, não existem iterações dinâmi-
cas com outras unidades de software, ou seja, as chamadas realizadas a ou-
tros componentes são somente realizadas de forma simulada, não ocorrendo
realmente tais operações. Portanto, existe um risco real de que determinado
Arquitetura Completa do Aplicativo Arquitetura do Teste da Unidade E
Unidade Unidade Unidade Controlador

A B C Testes-E
Unidade Unidade Unidade

D
Isolado
E E
Unidade
F Unidade Simulador Simulador
Unidade J H J
H
Unidade Unidade Simulador
G I I
Figura 14.4 Testes unitários com abordagem isolada
componente tenha modificado sua chamada (incluído um novo parâmetro

ou modificado o nome de uma função), deixando incompatível a chamada
para esse novo componente. Nessa abordagem, a integração entre nossa uni-
dade a ser testada e o componente modificado poderia não ser atualizada e,
mesmo assim, passaria nos testes unitários, uma vez que o simulador tam-
bém não atualizou essa mudança. Dessa forma, essa abordagem torna essen-
cial o chamado teste de integração de unidades de software, pois somente
nesse estágio dos testes é que conseguiríamos detectar o problema.
Particularmente, acredito que essa abordagem é mais teórica do que prá-
tica, pois é muito complexo construir simuladores para todos os componen-
tes envolvidos no projeto. Porém, acredito que uma nova geração de ferra-
mentas de testes construirá esses simuladores de forma dinâmica para nós,
eliminando o esforço de seu desenvolvimento. Até lá, teremos que aguardar
e empregar outras abordagens de testes unitários.
14.1.4. Validação de Unidades com Abordagem Top-down

Os testes unitários estão intimamente ligados à forma como é conduzido o
processo de desenvolvimento do software. Nos projetos estruturados, aten-
didos tipicamente por processos de análise estruturada ou análise essencial,
as unidades são produzidas através de refinamentos sucessivos do projeto,
ou seja, quando estamos criando uma unidade de software, os níveis supe-
riores estão todos construídos e validados, enquanto que os níveis inferiores
ainda não foram construídos.
Dessa forma, quando disponibilizarmos uma determinada unidade a ser

validada, todas as demais unidades que acionam seus serviços e que estão lo-
calizadas em níveis hierárquicos superiores estarão disponíveis para inte-
grar os testes unitários como substituto natural dos controladores de testes.
Já as unidades inferiores não terão sido criadas, necessitando da construção
de simuladores para responder a eventuais chamadas acionadas pela unida-
de a ser testada.
Unidade Unidade Unidade Unidade Unidade

A B C B C

D
Top-down
E E
Unidade
Unidade J H J
H
G I I
Figura 14.5 Testes unitários com abordagem top-down
A vantagem apontada nessa abordagem é o direcionamento explícito dos

testes com relação aos requisitos de negócios suportados pela aplicação.
Como é natural que as unidades de maior nível suportem as telas de navega-
ção do sistema, os testes poderão ser direcionados facilmente por essas es-
truturas, facilitando a análise de requisitos que não estão sendo atendidos
pela aplicação ou que estão aparecendo em duplicidade. Ao contrário dos
testes isolados, os testes top-down já exercitam as interfaces entre unidades
no sentido de cima para baixo. Esses ciclos de integrações podem ser visuali-
zados no estágio de validação das integrações com abordagem top-down.
A desvantagem dessa abordagem é o fato de ela estar fortemente apoiada
na construção de simuladores, o que aumenta significativamente os esforços
de construção de um ambiente de testes nessas condições. Outro ponto pro-
blemático é o fato de que, à medida que avançamos no projeto e atingimos ní-
veis mais baixos de estruturação, os índices de cobertura são menores devido
à dificuldade de simular operações de baixo nível de funcionalidade, como
tratamento de erros e restrições de segurança, o que torna o processo lento e

muito pouco flexível, necessitando de uma completa navegação da estrutura
sempre que for preciso acionar funcionalidades que estão inseridas em unida-
des de nível hierárquico inferior.
14.1.5. Validação de Unidades com Abordagem Bottom-up

Nessa abordagem, os testes unitários acompanham a estratégia de desenvol-
vimento baseado em projetos não estruturados, os chamados projetos orien-
tados a objetos. Nesses projetos, não existe uma hierarquia de unidades
como eram modeladas as soluções baseadas nas análises estruturadas e es-
senciais. Nesse tipo de projeto tecnológico, os problemas são fragmentados
em um conjunto de pequenas unidades especializadas de software que aten-
derão isoladamente a uma pequena fração do processo. Essas pequenas fra-
ções poderão ser empregadas em outros processos a serem modelados, ma-
ximizando o nível de reutilização do projeto de software.
Como é característica dos projetos orientados a objetos, uma única fun-
cionalidade pode demandar a criação de um grande conjunto de unidades –
chamadas de classes. À medida que cada unidade é criada para atender a uma
pequena fração da funcionalidade, esta deve ser testada isoladamente, ava-
liando se suas operações especializadas foram adequadamente implementa-
das. Após a validação isolada de cada unidade, torna-se necessário testar to-
das em conjunto, avaliando se a funcionalidade foi integralmente atendida
pelas unidades desenvolvidas. Seguindo os próprios conceitos do desenvol-
vimento baseado em objetos, as unidades mais básicas serão codificadas an-
tes das classes que utilizarão os serviços que serão disponibilizados. Dessa
forma, os testes exigirão controladores de testes para simular as chamadas às
rotinas especializadas das classes, já que não serão necessários à utilização
de simuladores, pois o processo de criação é de baixo para cima.
A vantagem dessa abordagem é a facilidade de realizar testes nas unida-
des mais básicas do projeto, o que potencializa os testes de classes em proje-
tos orientados a objetos. Nessa abordagem, os testes podem atingir a cober-
tura total da estrutura interna, possibilitando a simulação de todos os fluxos
alternativos de processamento, além de exercitar os diversos desvios de con-
dições existentes no código-fonte. Ao contrário dos testes isolados, os testes
bottom-up já exercitam as interfaces entre unidades de baixo para cima.
Esses ciclos de integração podem ser visualizados no estágio de validação
das integrações com abordagem bottom-up.
Unidade Unidade Unidade Controlador

A B C Testes-E

D E
Bottom-up E
Unidade
Unidade J H J
H
G I I
Figura 14.6 Testes unitários com abordagem bottom-up
A desvantagem dessa abordagem é a crescente complexidade que os tes-

tes irão ganhando à medida que progredimos e subimos os níveis de intera-
ção com outras unidades, reduzindo o nível de cobertura estrutural alcança-
do pelos testes.
14.2. Validação da Integração

Os testes de integração são uma natural continuação dos testes unitários. À
medida que as unidades vão sendo construídas ou modificadas, estas devem
manter a compatibilidade com outros componentes já existentes. Esses tes-
tes são orientados pela própria arquitetura do projeto tecnológico, na qual
são colocados diversos componentes para que sejam processados e tenham
suas interfaces exercitadas e validadas.
Os testes de integração podem ser entendidos como o segundo estágio
do processo de validação de componentes de software. Esses testes têm por
objetivo validar a compatibilidade entre componentes da mesma arquitetura
tecnológica. A compatibilidade de um componente é quebrada sempre que
existe uma alteração ou exclusão de uma rotina ou propriedade pública de
um componente. Quando isso ocorre, todos os outros componentes que em-
pregam essas rotinas ou propriedades estão automaticamente incompatíveis
com o componente modificado, gerando erros durante a execução do soft-
ware. São exatamente esses erros que devem ser identificados nesse estágio
dos testes de software.
As integrações podem ser executadas nos mais variados níveis existentes

na arquitetura de um software. É possível testar as integrações entre classes
de um determinado componente, testar integrações entre componentes, tes-
tar as integrações entre módulos e entre subsistemas.
Unidade • Traduzir o modelo de arquitetura em componentes tecnológicos.

Especificada ou • Traduzir os requisitos de negócios, regras e comportamentos em
Modificada código-fonte.
6
• Garantir a perfeita interface entre os diversos componentes existentes
Validação na arquitetura tecnológica.
da • Garantir a perfeita colaboração entre componentes.
Integração • Garantir que determinados requisitos estejam implementados.
Figura 14.7 Objetivo da validação das integrações de software
O objetivo dos testes de integração é validar as interfaces entre compo-

nentes da mesma arquitetura tecnológica. Essas interfaces representam as
trocas dinâmicas de informações que ocorrem entre componentes durante a
execução de um software. Abaixo estão relatados alguns pontos de validação
que poderiam ser considerados críticos para se avaliar a qualidade das inter-
faces entre componentes de software.
Exercitar todas as dependências existentes entre componentes.

Exercitar todas as interfaces existentes em um componentes.
Exercitar todos os parâmetros de interfaces de um componente.
Exercitar todas as propriedades públicas de um componente.
14.2.1. Validação das Integrações com Abordagem Big-bang

A integração Big-bang é, provavelmente, o método de integração mais fre-
qüente empregado na prática. Os componentes são testados individualmen-
te (testes de unidades) e depois integrados todos de uma única vez. Esse tipo
de teste de integração é o que requer menos esforço, mas geralmente o resul-
tado é desastroso. Diagnosticar um erro nessa situação é bastante complexo,
pois é difícil identificar qual dos componentes está produzindo o defeito.
Na verdade, essa abordagem resume-se na aplicação de testes de integra-
ção realizados após a construção de todas as unidades de software, ou seja,
esses testes ocorrem com a aplicação de todas as unidades ao mesmo tempo,
não havendo ciclos parciais de integração.
Teste de Unidade Teste de Integração
BIG
BANG
Figura 14.8 Validação das integrações entre unidades com abordagem big-bang
14.2.2. Validação das Integrações com Abordagem

Top-down
Nessa abordagem, os ciclos de integração seguem a filosofia do desenvolvi-
mento estrutural comumente conhecido como desenvolvimento Top-down.
Nesse modelo de desenvolvimento, as unidades de maior nível hierárquico
são criadas inicialmente, sofrendo um processo de refinamento e decompo-
sição sucessivos, até que seja alcançado o menor nível estrutural do projeto e
todas as unidades tenham sido criadas. À medida que as unidades são cons-
truídas e alteradas, os testes de integração avaliam se as interfaces com ou-
tras unidades continuam compatíveis.
A integração Top-down pode ser realizada em largura ou em profundida-
de. Quando a abordagem for testada em profundidade, simuladores serão
substituídos ao longo da estrutura do projeto. Se a abordagem for em largu-
ra, os simuladores serão substituídos verticalmente, lembrando que, nesse
tipo de integração cada novo módulo integrado é testado.
Nível 1 Nível 2 Nível 3 Nível 4
T T
S
S
T S
S S T S
T S S S T
T S S S
S T
S S S
T S
S S
T T S T
S
S S
T
S S T S S S S
T
S S
S Componentes de Software
T S T
S
T Componentes de Testware
T
Figura 14.9 Testes de integração com a abordagem top-down
INTEGRAÇÃO EM PROFUNDIDADE INTEGRAÇÃO EM LARGURA
S S
S S S S
S S T T T T T
T T T
Figura 14.10 Tipos de integração top-down
14.2.3. Validação das Integrações com Abordagem

Bottom-up
Nesse tipo de abordagem os componentes de níveis mais básicos da arquite-
tura do aplicativo são conjuntamente testados por controladores construí-
dos para simular as interações dinâmicas e suas interfaces. À medida que
evoluímos nos testes de integração, componentes reais substituem os con-
troladores anteriores e novos controladores de testes são criados para simu-
lar as interfaces de um maior nível da arquitetura. Esses níveis de integração
Integração Nível 1 Integração Nível 2 Integração Nível 3
S
T S
S
S S
S S
S S
T S S S S
T S S
S S S S S
S
S S
T S S
T
S S
S
S S
T S S
S S
S S S
S
S S S
S T S S
T S
S S
S
S S
S
S Componentes de Software
S
T S S
T Componentes de Testware
S
Figura 14.11 Testes de integração com a abordagem bottom-up
seguem até que não existam mais níveis a serem alcançados, atingindo o ní-
vel máximo de integração que os componentes podem chegar.
Em cada nível de integração descrito, existe um controlador criado exclu-
sivamente para realizar os testes de interfaces entre os componentes de soft-
ware. Perceba que os ciclos de evolução dos testes de integração são todos mo-
delados a partir da estrutura do aplicativo, sendo necessário somente decidir
quantos níveis serão necessários para realizar todos os testes de integração.
14.2.4. Validação das Integrações com Abordagem Mista

Esse modelo de validação das integrações de unidades de software represen-
ta uma combinação das abordagens Bottom-up e Top-down, visando à utiliza-
ção do que existe de melhor nas duas técnicas empregadas. Abaixo estão
apontadas as principais vantagens e desvantagens de cada abordagem.
Tabela 14.2
Testes de integração com a abordagem mista
Bottom-up Top-down
Principais G Permite que as unidades G O módulo principal (main) é

Características mais básicas (e talvez as testado primeiro.
mais críticas) sejam testadas G Apenas uma unidade é
mais cedo. integrada a cada ciclo.
G As unidades podem ser G Maior ênfase nos protótipos
integradas em vários ciclos visuais.
de testes, de acordo com a
necessidade do
planejamento.
G Maior ênfase na
funcionalidade e no
desempenho dos módulos.
Vantagens G Não há necessidade de G Não há necessidade de

simuladores. controladores.
G Maior facilidade de adaptar G Com o módulo principal
os testes aos recursos (main) e alguns módulos se
humanos disponíveis para obtém um protótipo nas
executá-los. fases iniciais.
G Maior cobertura das unidades G Erros de interfaces são
mais básicas e que atendem detectados mais cedo.
a aspectos críticos de G Facilita a orientação dos
processamento. testes de funcionalidades da
G Erros na arquitetura da aplicação.
solução são detectados mais
cedo.
Desvantagens G Necessidade de G Necessidade de simuladores.

controladores. G Erros na arquitetura da
G Muitas unidades devem ser solução são detectados
integradas antes de se tardiamente.
conseguir operacionalizar G Como as fases iniciais são
uma funcionalidade. muito prolongadas, torna-se
G Erros nas interfaces visuais difícil sincronizar o ritmo de
são detectados mais tarde. desenvolvimento e a
disponibilidade dos recursos
de testes.
Comentários G A produção do código G Na prática, é muito difícil

avança mais rapidamente do utilizar uma abordagem
que através da abordagem puramente Top-down
Top-down.
G Em geral essa abordagem é
mais intuitiva.
14.3. Validação do Sistema

A validação do sistema é o estágio do processo de validação mais mal com-
preendido e difícil de operacionalizar de todos. Ao contrário dos outros ní-
veis, os testes de sistema validam a solução como um todo. Quando atingi-
mos esse estágio dos testes, a maior parte das falhas de funcionalidade deve
ter sido detectada nos testes unitários e nos testes de integrações.
Como os testes de sistemas contam com uma infra-estrutura mais com-
plexa de hardware (mais próximo do ambiente real de produção), os testes
de sistema deveriam concentrar-se mais nos aspectos de performance, se-
gurança, disponibilidade, instalação, recuperação, entre outros. Nesse ní-
vel de testes, determinados aspectos das funcionalidades que não puderam
ser testados deverão integrar o planejamento dos testes de sistema, como
testes de integrações com sistemas externos (sem simulação), testes com
dispositivos físicos (hardware), utilitários externos e operacionalização
do ambiente tecnológico.
Planejar os testes de sistemas não é tarefa fácil, pois exige o perfeito enten-
dimento dos requisitos não funcionais de um software, que muitas vezes não
são claramente descritos ou representam cenários extremamente complexos.
Os requisitos não funcionais podem tanto definir cenários simples de testes
(suportar 1.000 transações de saque por minuto) como podem descrever ce-
nários complexos, que envolvem muitos aspectos simultâneos (processar um
extrato em, no máximo, 30 segundos, existindo uma concorrência de acesso
de 500 usuários simultâneos e com volume de dados da ordem de 2 milhões
de correntistas e 350 milhões de movimentações bancárias).
Unidade
Especificada ou • Atender os requisitos não funcionais da solução tecnológica.
Modificada • Modelar uma arquitetura que atenda a todos os os requisitos da solução.
Validação • Garantir os requisitos não funcionais.

do • Validar a infra-estrutura a ser aplicada na produção.
Sistema • Validar interfaces com sistemas e dispositivos físicos.
Figura 14.12 Objetivo da validação do sistema
Nessa fase, a falta de um método único de como planejar e operacionalizar

os testes de requisitos não funcionais (testar uma carga de 100.000 registros
ou validar um procedimento de recuperação de backup) exige uma grande
dose de criatividade por parte da equipe de testes. Uma das formas encontra-
das para organizar os testes é relacioná-los em categorias, com objetivos bem

definidos e distintos. Essa organização facilitará o planejamento e a execução
dos testes, uma vez que os cenários que possuem características e comporta-
mentos semelhantes estarão agrupados em uma mesma categoria.
Seja em qualquer situação, os testes de sistema não devem ser encarados
como a última coisa a ser feita antes de colocarmos o sistema em produção.
O desenvolvimento incremental prevê vários ciclos de desenvolvimento e,
em cada um destes, os testes de sistemas deverão ser executados. Isso fará
com que erros de arquiteturas sejam prematuramente identificados, além de
identificar alterações de desempenho e capacidade de carga da solução, mui-
tas vezes provocada por mudanças aplicadas na arquitetura do software.
14.3.1. Validação dos Sistemas com Abordagem Isolada

Se nosso objetivo é validar os requisitos funcionais de toda uma aplicação,
torna-se fundamental a execução de um conjunto de cenários de negócios
que exigiria a interação de vários sistemas simultaneamente, o que inviabili-
zaria qualquer tentativa de realizar esses testes de forma integrada.
Mesmo conseguindo criar um ambiente integrado, seria inviável percor-
rer o fluxo natural das informações relativas aos testes partindo do sistema A,
exportando para o sistema B, que enviaria para o sistema D até chegar no siste-
ma e na condição que estamos validando. Isso tornaria o processo de teste len-
to, além de pouco operacional. Sem contar com o fato de que qualquer inter-
rupção de processamento dos outros sistemas poderia inviabilizar a continui-
dade dos testes, tornando o processo muito instável e pouco confiável.
Portanto, a abordagem de realizar os testes de sistema de forma isolada
dos demais sistemas facilitaria a administração dos diversos cenários de ne-
gócios que estaremos simulando durante os testes, evitando as dependên-
cias existentes. Nessa abordagem, cada sistema seria substituído por um si-
mulador, que produziria as respostas necessárias para alimentar a execução
do sistema que estamos testando, possibilitando a criação dos mais variados
cenários, minimizando os esforços de planejamento e execução dos testes.
A utilização de simuladores reduz a complexidade do planejamento,
montagem e execução dos testes, uma vez que as dependências com outros
sistemas desaparecem, facilitando a realização dos múltiplos cenários de ne-
gócios, que seriam difíceis de operacionalizar com uma abordagem integra-
da. Esses mesmos simuladores poderão ser aplicados nos testes unitários e
de integração, já que também deverão enfrentar as mesmas dificuldades em
operacionalizar seus procedimentos de testes.
<Simulador>
<< Batch >>
Sistema
A
Sistema
D
<< On-line >>
<< Batch >>
<< On-line >> <Simulador>

Sistema-
alvo Sistema << On-line >>
B Sistema
E
<< On-line >>

<< Batch >>
<Simulador>
<< Batch >>
Sistema
C
Sistema
<< Batch >> F
Figura 14.13 Simuladores nos testes de sistema deixam

o ambiente mais gerenciável
14.3.2. Validação dos Sistemas com Abordagem

Integrada
Cada sistema que incluímos no contexto dos testes traz uma gama de dificul-
dades adicionais: lidar com um número maior de profissionais, disponibili-
zar uma infra-estrutura para suportar o aplicativo, instalar e parametrizar o
sistema para atender a nossos propósitos, além de esbarrarmos com as pró-
prias dependências do sistema com outros aplicativos. Se uma coisa puxa a
outra, teremos que trazer grande parte dos sistemas existentes na organiza-
ção, o que pode tornar essa atividade complexa e inviável.
Porém, em algumas situações, necessitamos validar condições que ne-
cessitam da interação real com as aplicações para que as medições sejam obti-
das nas condições mais próximas de um ambiente de produção. Nesse caso, os
simuladores poderiam “esconder” gargalos de processamento, uma vez que
estes não utilizariam a infra-estrutura disponível para processar seus resulta-
dos, apontando falsos índices de performance. Neste caso, uma abordagem
integrada forneceria um cenário mais favorável para aplicar os testes.
É fundamental avaliar quando é necessário integrar os sistemas em um
único ambiente e definir quais integrações são relevantes para atender às ne-
cessidades dos testes a serem executados. Conforme representado acima,
somente as operações on-line foram mantidas, pois estas realmente conso-
Sistema << Batch >>

A
Sistema
D
<< On-line >>
<< Batch >>
Sistema- << On-line >> Sistema

alvo B << On-line >>
Sistema
E
<< On-line >>

<< Batch >>
Sistema
C << Batch >> << Batch >>
Sistema
F
Figura 14.14 Testes de sistemas integrados identificam gargalos

de processamento
mem o processamento e a infra-estrutura durante a execução de determina-

das condições de testes, proporcionando representação mais fiel do que a
encontrada no ambiente de produção.
14.4. Validação do Aceite

A validação do aceite é o último estágio do processo de validação. Trata-se
do último processo formal de detecção de erros no sistema, antes de sua dis-
ponibilização no ambiente de produção. Nessa etapa, o software é disponi-
bilizado para clientes e usuários com o objetivo de estes validarem todas as
funcionalidades requisitadas no início do projeto. Os usuários terão a opor-
tunidade de interagir com um sistema completo, exaustivamente testado
pela equipe de testes.
Se ao chegar a essa etapa do processo de garantia da qualidade de softwa-
re e a solução ainda apresentar muitas falhas, é sinal de que os processos de
detecção de defeitos anteriormente executados (unitários, de integração e
de sistemas) não estão sendo efetivos, ou seja, não foram corretamente imple-
mentados, indicando falhas nos processos anteriores.
Assim como nos testes de sistema, os procedimentos de aceite deverão
ser realizados a cada ciclo de implementação da solução, permitindo corre-
• Disponibiliza a solução para clientes e usuários validarem o software

Disponibiliza
e suas funcionalidades.
Solução
• Estratégia de implatação gradativa da solução.
8
Validação • Última etapa para detectar erros na solução.

do Aceite • Permite aos usuários validarem o software (Alpha-teste).
• Permite realizar no ambiente do cliente (Beta-teste).
Figura 14.15 Objetivo da validação do aceite
ções antecipadas de determinados pontos que não foram adequadamente

atendidos pelo software.
Como essa é a última oportunidade efetiva de detectar falhas no software,
poderemos empregar o aceite como uma estratégia para reduzir riscos de uma
implantação maciça, na qual um erro vital não detectado pode comprometer a
imagem da solução como um todo. Dessa forma, podemos dividir o aceite em
três momentos distintos: o Aceite Formal, Alpha-teste e o Beta-teste.
HOMOLOGAÇÃO (ACEITE DA SOLUÇÃO) DISTRIBUIÇÃO
Aceite Alpha- Beta- Todos os

Formal teste teste Clientes
ACEITE FORMAL IMPLANTAÇÃO ALPHA IMPLANTAÇÃO BETA IMPLANTAÇÃO TOTAL

Clientes planejam e Clientes são convidados Clientes selecionados Todos os clientes
realizam os testes do a operar o software no recebem o software para recebem o software
software. fornecedor. operar em seu ambiente. devidamente testado.
Figura 14.16 Estágios do processo de aceite de um software
14.4.1. Aceite Formal

Nessa abordagem, o processo de aceite torna-se uma natural continuação
dos testes de sistema. Aproveitando-se de toda a infra-estrutura existente no
ambiente de homologação (inclusive dos simuladores), o aceite formal
segue um rigoroso planejamento das atividades de testes, cabendo aos pró-
prios clientes e usuários determinarem o que deverá ser testado e validar se
os requisitos foram adequadamente implementados.
Na maior parte das vezes, o aceite formal restringe-se apenas às funcio-

nalidades de negócio, deixando outros requisitos fora do escopo desses tes-
tes. Esses processos poderão ser totalmente automatizados pela equipe de
testes, cabendo a conferência ser realizada pelos próprios clientes e usuários
selecionados para realizar esse tipo de atividade.
Esse tipo de aceite é muito empregado em projetos que são desenvolvi-
dos para atender a um grupo de empresas, possibilitando a criação de um co-
mitê que atestará a aderência do software às necessidades do grupo. Tam-
bém são aplicados nas situações em que os estágios anteriores dos testes não
são executados ou são pouco eficientes.
14.4.2. Alpha-teste
Nesse estágio do aceite, os clientes são convidados a operar o software den-
tro de um ambiente simulado, localizado internamente na empresa criadora
do software, porém fisicamente separada do ambiente de desenvolvimento.
Os usuários poderão interagir diretamente com a aplicação, simulando ope-
rações e transações de todos os tipos. Cabe aos profissionais que estão geren-
ciando o processo de aceite garantir que todos os usuários convidados estão
exercitando todos os pontos mais críticos da aplicação, possibilitando as
chances de encontrar defeitos em procedimentos implantados.
A principal característica do Alpha-teste é a ausência de um formalismo
no processo de validação, não existindo regras rígidas de execução ou proce-
dimentos de aceite. O objetivo é capturar a naturalidade dos próprios usuá-
rios e dar a eles a possibilidade de realizar seus próprios testes. Apesar de ser
fundamental deixar o usuário livre para executar todas as funcionalidades
do software, é recomendável formalizar um conjunto reduzido de procedi-
mentos, de forma a garantir um mínimo de cobertura do aceite realizado pe-
los usuários. Mesmo não existindo a garantia efetiva de que este seguirá tais
procedimentos, esses procedimentos funcionarão como uma espécie de
checklist do aceite.
14.4.3. Beta-teste
Nesse estágio do aceite, clientes serão convidados a operar o produto utili-
zando suas próprias instalações físicas para que o software possa ser subme-
tido às mesmas transações do dia-a-dia. Não se trata de uma implantação de-
finitiva, mas sim de uma implantação em paralelo. O Beta-teste pode ocorrer
até que o cliente sinta-se seguro em realizar a mudança de aplicativo (seja ela
uma troca de sistema ou uma atualização de versão). Durante toda a execu-

ção do Beta-teste, o cliente contará com o acompanhamento direto da em-
presa fornecedora do sistema ou da equipe que desenvolveu o software para
que corrija qualquer eventual falha que possa existir na aplicação e prejudi-
car a imagem de solidez da solução tecnológica.
Os clientes que participarão desse estágio dos testes deverão ser aqueles
que executam toda ou grande parte das funcionalidades existentes no apli-
cativo, de forma a ser bem representativo em relação aos demais clientes. O
Beta-teste pode ser planejado em vários ciclos que englobam um número
cada vez maior de clientes até que o aceite seja efetivo e o processo de im-
plantação do software seja iniciado.
CAPÍTULO 15
Conceito do Testware
Da mesma forma que existe uma gestão de software, deve existir uma
gestão equivalente ao testware, ou seja, todos os cuidados existentes no de-
senvolvimento de software devem existir no desenvolvimento de compo-
nentes que objetivam a automação dos procedimentos de testes.
Ao contrário do que se imagina, as atividades de testes não podem ser en-
caradas como uma tarefa passageira que pode ser realizada sem controle ou
padrão. Igualmente a software, testware tem significativo valor porque pode
ser reutilizado sem incorrer em um novo custo de redesenvolvimento a cada
execução.
Essa gestão deve estar preocupada com os aspectos críticos do testware:
criar e manter um ambiente de testes, mantê-lo sob controle através de um
sistema de gerenciamento de configurações, utilizar-se de rotinas de arma-
zenamento periódico (backups), instituir padrões de elaboração de docu-
mentos e relatórios e formar profissionais capacitados a lidar com as ferra-
mentas e metodologias de testes.
15.1. Entendendo o Conceito de Testware

Este é um dos conceitos mais fundamentais que devemos assimilar quando
implantamos um processo de validação do software. Da mesma forma que os
engenheiros de hardware produzem hardware e os engenheiros de software
produzem software, os engenheiros de testes produzem testware.
Testware são todos os produtos gerados nas fases de verificação e valida-
ção. Incluem-se todas as formas de documentações, automações e relatórios
HARDWARE SOFTWARE TESTWARE
• Manutenção Corretiva. • Políticas de Armazenamento.

• Manutenção Preventiva. • Políticas de Acesso e Segurança.
• Inspeções Constantes. • Gestão de Configurações e Mudanças.
• Controle de Instalações • Backups.
• Planejamento de Substituição. • Atualizações Constantes..
Figura 15.1 Conceito de testware
produzidos. São as checklists, o planejamento e especificações de testes, as

rotinas automatizadas de execução de testes, os casos de testes, a massa de
testes e os relatórios finais de validação do software.
Apesar de o testware ser um subproduto do processo de desenvolvimen-
to do software, ele é tão importante quanto o próprio software porque o test-
ware foi criado com a premissa de que, para desenvolver um bom produto, é
preciso ter bons processos de testes. Caso estes não existam ou não sejam
executados, não é possível assegurar que o software tenha qualidade.
Dessa forma, perder uma rotina automatizada ou uma especificação de
testes é tão crítico quanto perder uma especificação de negócios ou mesmo
um código-fonte. Os processos de testes e desenvolvimento estão tão interli-
gados que um não funciona sem o outro.
15.2. Testware Aplicado nos Vários Ambientes

Um software, para ser utilizado, necessita de um conjunto de equipamentos
(processadores, servidores, estações, terminais) denominados hardware.
Também requer um conjunto de programas de computadores (sistemas
operacionais, bancos de dados, gerenciadores de rede) denominados soft-
ware. A combinação desses dois elementos, hardware e software, definimos
como infra-estrutura.
Durante o processo de desenvolvimento de um software, cada fase pos-
sui uma missão diferente, requerendo uma configuração de hardware e
software adequada a esses objetivos. Cada ciclo de vida do software (desen-
volvimento, teste de homologação e produção) requer uma infra-estrutura

diferenciada, necessitando de um local físico distinto, ao qual chamamos
de ambiente.
“Ambiente é um local físico onde existe uma

infra-estrutura de hardware e software
adequada a uma determinada missão.”
Figura 15.2 Definição de ambiente
AMBIENTE AMBIENTE AMBIENTE

DE DE TESTE E DE
DESENVOLVIMENTO HOMOLOGAÇÃO PRODUÇÃO
CICLO DE VIDA DO SOFTWARE
EM EM EM EM
DESENVOLVIMENTO TESTE HOMOLOGAÇÃO PRODUÇÃO
Figura 15.3 Gestão de ambientes
15.2.1. Ambiente de Desenvolvimento

O ambiente de desenvolvimento tem como missão maior fornecer toda a inf-
ra-estrutura necessária de hardware e software para a confecção de um novo
software. Toda essa infra-estrutura deve estar disponível à equipe de desen-
volvimento de software, ou seja, aos analistas e programadores.

DE DE TESTE E DE
Porém, esse ambiente deverá ser segmentado em duas partes: uma para
atender às necessidades da equipe de desenvolvimento e a outra para aten-
der às necessidades de testes da própria equipe de desenvolvimento. Como
nosso enfoque aqui são somente testes de software, interessa-nos apenas a
segunda segmentação do ambiente de desenvolvimento, que não exigirá os
softwares de apoio ao desenvolvimento, as chamadas ferramentas CASE
(Computer Aided Systems Engineering). Essas atividades necessitarão de
um outro conjunto de ferramentas que serão empregadas para auxiliar no
processo de automação dos testes.
Dentro do ambiente de desenvolvimento, na segmentação voltada ex-
clusivamente a testes, deverão ser aplicados os testes unitários e de integra-
ção. Esses testes poderão ser aplicados tanto pela própria equipe de desen-
volvimento quanto por uma equipe de testes independente. Como esses tes-
tes exigem um alto grau de conhecimento da arquitetura do software a ser
testado, é mais natural que os testes fiquem sendo inicialmente de responsa-
bilidade da própria equipe de desenvolvimento, porém, a experiência de-
monstra que os testes realizados por uma equipe externa permitem maior
nível de eficiência e cobertura, além de possibilitar um alto grau de automa-
ção dos testes. Se não existem grandes restrições orçamentárias, uma equipe
de teste independente é extremamente recomendável.
AMBIENTE DE DESENVOLVIMENTO AMBIENTE DE TESTE E HOMOLOGAÇÃO
TESTE:
TESTE: SISTEMA TESTE:
UNIDADE
DESENVOLVIMENTO ACEITAÇÃO
INTEGRAÇÃO CATEGORIA:
FUNCIONAL
FONTES CARGA CATEGORIA
CATEGORIA
ESTRUTURA INTERNA PERFORMANCE ACEITE FORMAL
FUNCIONAL
INSTALAÇÃO ALPHA-TESTE
USABILIDADE
SEGURANÇA
EM DESENVOLVIMENTO EM TESTE EM HOMOLOGAÇÃO
Figura 15.4 Ambiente de desenvolvimento
15.2.2. Ambiente de Teste e Homologação

Esse ambiente tem como missão maior fornecer toda a infra-estrutura neces-
sária de hardware e software para a realização dos testes de requisitos do
software. Toda essa infra-estrutura deve estar disponível exclusivamente
para essa finalidade, de forma a garantir um ambiente ideal de simulação,
não existindo interferência nenhuma com outras atividades da organização.

DE DE TESTE E DE
Sua infra-estrutura deve contemplar um ambiente muito semelhante ao

de produção para possibilitar o maior número de testes possíveis nas condi-
ções mais próximas de um ambiente real (principalmente os testes relativos
a desempenho, volume, carga e segurança). Esse ambiente deve contemplar
um conjunto de hardware e software construídos com a finalidade de intera-
gir com o software de forma automatizada, possibilitando a execução e con-
ferência dos testes de forma flexível e otimizada.
Sempre que for necessário importar massas de dados de produção com o
propósito de integrá-las ao processo de testes, é recomendável aplicar técni-
cas de criptografia nas informações, impossibilitando que os dados tor-
nem-se de conhecimento dos profissionais que atuam nesse ambiente de
testes e homologação.
AMBIENTE DE TESTE E HOMOLOGAÇÃO AMBIENTE DE PRODUÇÃO
TESTE:
SISTEMA TESTE:
TESTE:
ACEITAÇÃO
CATEGORIA: ACEITAÇÃO
CARGA PRODUÇÃO
PERFORMANCE CATEGORIA
CATEGORIA:
VOLUME ACEITE FORMAL
BETA-TESTE
SEGURANÇA
EM TESTE EM HOMOLOGAÇÃO EM PRODUÇÃO
Figura 15.5 Ambiente de teste e homologação
Nesse ambiente, ocorrem todos os testes de sistema que validam os re-

quisitos de software levantados, como os requisitos funcionais, seguran-
ça, performance, entre outros. Os testes são realizados com as técnicas de
caixa preta, nas quais não se requer um conhecimento interno do softwa-
re. Os testes são gerados com a finalidade de provocar variações específi-
cas de negócio e verificar como estas foram tratadas. Através da análise
desse comportamento, a conferência é realizada e o teste é dado como
bem-sucedido ou não.
Os testes de aceite (aceite formal e Alpha-teste), que são executados

pelos próprios usuários finais do software, também são realizados nesse am-
biente, pois possuem infra-estrutura muito semelhante a que será encontra-
da no ambiente de produção. Nesse ambiente, grupos de usuários e clientes
são convidados a manipular a “nova versão” do software, simulando as ope-
rações do dia-a-dia.
15.2.3. Ambiente de Produção

O ambiente de produção tem como missão maior fornecer toda a infra-
estrutura necessária de hardware e software para que o produto desempenhe
plenamente as funcionalidades para as quais foi projetado. É nesse ambiente
que o software produz os resultados esperados, ou seja, todas as operações
aqui realizadas são “reais”, representando todas as transações de negócios
realizadas pelo cliente. Dessa forma, esse ambiente deve ser altamente con-
trolado e seguro de invasões.

DE DE TESTE E DE
Através do número de erros identificados no ambiente de produção, po-

demos mensurar o quanto está sendo efetivo o esforço do processo de quali-
dade do software, comparando com os níveis de defeitos que ocorriam antes
da implantação de um processo completo de garantia da qualidade. Dessa
forma, podemos medir os ganhos da não-incidência de erros na produção e
avaliar o ponto no qual o processo de qualidade passa a produzir um retorno
de investimento.
Através dos erros ocorridos no ambiente de produção, a equipe de testes
planejará um conjunto de novos casos de testes, evitando que esses erros sejam
reincidentes, melhorando a confiabilidade do produto ao longo do tempo.
Nesse ambiente são realizados os chamados Beta-testes (fase final do pro-
cesso de homologação do software). Nessa fase, apenas um grupo de usuá-
rios selecionados terá acesso a uma “nova versão” do produto que está ainda
sob acompanhamento da equipe de testes de software.
AMBIENTE DE TESTE E HOMOLOGAÇÃO AMBIENTE DE PRODUÇÃO
TESTE:
SISTEMA TESTE:
TESTE:
ACEITAÇÃO
CATEGORIA: ACEITAÇÃO
CARGA PRODUÇÃO
PERFORMANCE CATEGORIA
CATEGORIA:
VOLUME ACEITE FORMAL
BETA-TESTE
SEGURANÇA
EM TESTE EM HOMOLOGAÇÃO EM PRODUÇÃO
Figura 15.6 Ambiente de produção
15.3. Gerenciando o Baseline

Para que possam ser realizados os testes de software, uma infra-estrutura de
hardware e software deve ser levantada de forma a possibilitar a criação de
um ambiente de testes adequado a cada sistema.
O baseline é o resultado do esforço de criação de um ambiente inicial
pronto para sofrer o processamento dos testes planejados. São várias ativida-
des que resultam em sua construção:
Ponto de Corte: É recomendável que a base de dados do ambiente de

teste seja obtida do ambiente de produção. Isso possibilita uma imedia-
ta familiarização com as informações do ambiente, facilitando no pla-
nejamento dos casos de testes. O ponto de corte é a atividade de “con-
gelamento” das informações do ambiente de produção, a ser realizada
em data preestabelecida.
Critérios de Redução e Limpeza: Muitas vezes, a base de dados obtida
no ponto de corte é extremamente grande, não sendo necessária, nem
recomendável, a migração total das informações por questões relati-
vas a espaço e tempo adicional de processamento. Para isso, os profis-
sionais de testes, juntamente com as áreas envolvidas, definem crité-
rios para redução e limpeza da base de dados sem que isso prejudique
o planejamento e a conferência das informações.
Criptografia: Alguns dados de produção podem ser sigilosos e não po-
deriam ser identificados. Deve-se, neste caso, empregar ferramentas
de criptografia.
Informações Adicionais: Durante o planejamento dos testes, algu-
mas informações deverão ser incorporadas à massa de dados de for-
ma a criar artificialmente alguns cenários que não estão adequada-

mente representados em uma base de dados e que serão necessárias
para a execução dos testes.
Seleção de Componentes: Identificar todos os componentes necessá-
rios para a execução do software. São arquivos ou mesmo referências que
o software necessita para desempenhar todas as suas funcionalidades.
AMBIENTE DE PRODUÇÃO BASELINE
• Ponto de Corte
• Redução e Limpeza
Base de • Informações Adicionais Base de
Dados • Criptografia Dados
Componentes Componentes
• Seleção de Componentes.
A cada execução dos testes, as informações contidas no banco de dados

tornam-se obsoletas, uma vez que as condições iniciais são modificadas pela
própria execução dos testes. Portanto, o baseline torna-se um instrumento
adequado para recuperar a condição inicial de testes, sendo necessário ser
restabelecido sempre que iniciarmos um novo ciclo de validação.
CAPÍTULO 16
Gestão Organizacional
O modelo organizacional baseado em departamentos é o mais encontra-

do dentro das empresas, onde cada departamento responde por um conjun-
to de tarefas e responsabilidades – caso estas não sejam feitas, esta área será a
responsável pelo mau desempenho. Além de ser estático, esse modelo orga-
nizacional leva cada departamento a se organizar de forma isolada, preocu-
pada apenas com seu universo restrito de problemas e sua própria sobrevi-
vência.
Quando tentamos conduzir um novo projeto de desenvolvimento de
software, é necessária a colaboração das diversas áreas envolvidas, uma vez
que todos terão sua parcela de responsabilidade sobre o projeto, porém,
existe uma dificuldade natural na condução de projetos dentro de uma orga-
nização. Parece que a gerência de cada departamento está apenas interessada
em resolver sua parte, e ninguém está vendo o todo operacional. Essa falta de
visão, torna o trabalho diário difícil de ser executado – coisas simples tor-
nam-se complexas pela simples falta de colaboração entre as áreas.
Negócios Desenvolvimento Testes Produção Infra-estrutura

Nível
Gerencial
Nível
Operacional
Figura 16.1 Áreas que participam de um processo de desenvolvimento

Para contornar esse problema, muitas organizações estão adotando os

chamados trabalhos em equipe. Esse modelo organizacional tem diversas
vantagens em relação aos estáticos modelos departamentais. Cada vez que a
organização necessita de um “novo projeto”, um líder é selecionado e este
recruta determinado conjunto de profissionais da mais diversas áreas – ne-
gócios, produção, homologação, desenvolvimento e suporte. A equipe tem
um objetivo bem definido e um prazo predeterminado para existir. Dessa
forma, os membros da equipe não sofrem interferências e conseguem reali-
zar os trabalhos de forma sincronizada, reduzindo as dificuldades e atritos
provenientes das negociações entre gerentes.
16.1. Organização de Projetos em Equipe

As vantagens desse formato é o fato de não ferir o modelo organizacional da
empresa, ou seja, mesma ela se organizando de forma departamental, é pos-
sível aplicar os conceitos de trabalho em equipe. Os departamentos e suas
gerênciais continuam existindo, porém não terão autonomia para interferir
nos trabalhos gerenciados pelo líder do projeto de desenvolvimento. Tam-
bém não poderão desalocar ou substituir qualquer profissional, a não ser
por motivos muito bem justificados.
Nível
Gerencial Líder de Projeto
Nível
Operacional
Negócios Desenvolvimento Testes Produção Infra-estrutura
Figura 16.2 Estrutura de um projeto com equipes de trabalho
Nesse modelo, é necessária a existência de uma equipe reguladora (Área

de Gestão dos Projetos de Software), tendo como principal objetivo avaliar a
condução de cada projeto de desenvolvimento e promover uma sinergia en-
tre eles. Sua missão é monitorar a execução de todos os projetos de desenvol-
vimento de software, avaliando a boa condução dos processos, advertir para
eventuais negligências e desvios de procedimentos estabelecidos e arbitrar
sobre discussões e impasses que surgirem.
Gestão dos
Projetos de Software
Líder de Projeto Líder de Projeto Líder de Projeto

Software “A” Software “B” Software “C”
Equipe de Equipe de Equipe de

Trabalho Trabalho Trabalho
Figura 16.3 Comitê de gestão dos projetos de software
Esse comitê é uma equipe multidisciplinar que representa as diversas

áreas de interesse envolvidas durante o processo de desenvolvimento de
software – área de negócios, produção, testes, desenvolvimento e suporte.
Cada um desses profissionais fica responsável por acompanhar sua área de
especialização e identificar falhas e dificuldades existentes. Seu papel é ape-
nas monitorar o desempenho dos diversos projetos tecnológicos e identifi-
car necessidades de melhoria.
16.2. Criando uma Área de Testes de Software

Uma das primeiras tentativas de organizar a área de testes de software é alo-
car esses profissionais nas áreas já existentes – nas áreas de desenvolvimento
e de produção. O ambiente de testes e homologação funcionaria como um
“local” no qual profissionais de outras áreas teriam o compromisso de reali-
zar determinados procedimentos de testes. Os arquitetos de testes e automa-
tizadores tendem a ser recursos do desenvolvimento, enquanto os executo-
res dos testes tendem a ser recursos da área de produção. O ambiente de au-
tomação ainda não é percebido como área, não possuindo uma gerência di-
reta sob o ambiente. Dessa forma, os profissionais de testes terão dificulda-
des de uma interação direta e dinâmica, criando mecanismos pouco eficien-
tes de troca de informações.
Área de Área de
Desenvolvimento Produção
Nível
Gerencial
Nível Hiato
Operacional
Analistas e Analista de Testes Executores de Analistas de

Programadores Automatizadores Testes Produção
Figura 16.4 Ausência de uma área de testes independente
A melhor forma de organizar um ambiente de testes é transformá-lo em

uma nova área organizacional. Os profissionais de testes focados exclusi-
vamente no processo de testes deverão pertencer a essa nova área, que terá
autonomia sobre as demais áreas da organização. Dessa forma, garantimos
que o processo de testes seja realizado sem a interferência das outras áreas,
permitindo uma eficiência na gestão e operacionalização do ambiente. Sob
uma única gerência, os profissionais de testes terão condições de se organi-
zar de forma mais eficiente, garantindo um nível de qualidade e velocidade
referente aos testes a serem planejados e aplicados em cada software a ser
validado.
Área de Área de Área de

Desenvolvimento Testes e Homologação Produção
Nível
Gerencial
Nível
Operacional
Analistas de Sistemas Analistas de Testes, Analistas de

Programadores Automatizadores e Executores Produção
Figura 16.5 Criação de uma área de testes de software independente

16.3. Criando uma Área de Qualidade de Software

A maioria das organizações possui visão limitada e distorcida de como
modernizar e evoluir o processo de desenvolvimento de software. As
empresas adotam as Metodologias de Desenvolvimento de Software
(MDS) como o principal processo da organização, porém, a MDS de
qualquer organização gira em torno de uma única área principal – a área
de desenvolvimento.
Desenvolvimento
Negócio Produção
Metodologia de
Desenvolvimento
Infra-estrutura Testes
de Software
(MDS)
Projetos Mudanças
Figura 16.6 A MDS faz o processo de software girar em torno

da área de desenvolvimento
Um software de qualidade não depende apenas de um bom processo de

desenvolvimento, mas de algo que contemple todas as disciplinas envol-
vidas em um processo de engenharia de software – deve contemplar o ge-
renciamento de requisitos, da análise e modelagem, da implementação, dos
testes de software, de mudanças, do ambiente tecnológico, da distribuição
da aplicação e o próprio gerenciamento do projeto. Trata-se de trocar uma
visão totalmente CENTRALIZADA para uma visão UNIFICADA do proces-
so de engenharia de software, colocando a área de desenvolvimento no mes-
mo nível de importância das outras áreas.
Dessa forma, o processo de engenharia de software ganha uma dimensão
bem maior – o processo de Garantia da Qualidade de Software, que contem-
pla todas as áreas e gestões necessárias para atingir um produto de alta quali-
dade e confiabilidade. Será necessária a existência de uma nova área com o
propósito de garantir a adequada execução do processo e atestar a qualidade
do software produzido. Sua missão é garantir, de forma corporativa, a uni-
formidade no processo idealizado pela equipe de Engenharia de Software,
advertindo sobre eventuais negligências e quebras de processos estabeleci-
dos. Também deverá arbitrar em determinados momentos nos quais surgi-
rem impasses entre as diversas áreas.
Engenharia Qualidade
de Software Processo de Software
(SEPG) UNIFICADO (SQA)
de Software
Projetos
Negócio Produção
Infra-estrutura Testes
Desenvolvimento Mudanças
Figura 16.7 A área de qualidade de software atua sobre processos de software

CAPÍTULO 17
Gestão
dos Profissionais
A missão Qualidade de Software está cada vez mais associada a uma dis-
ciplina fundamental do processo de desenvolvimento de software. Significa
que estamos diante de uma profissão, uma nova carreira a ser seguida. De-
vemos treinar esses profissionais para aprimorar seus conhecimentos e
ampliar sua visão sobre o processo de garantia da qualidade.
Em um primeiro momento, é possível empregar profissionais de desen-
volvimento para compor as equipes de qualidade de software. Isso é perfei-
tamente compreensível em razão de não existirem profissionais formados
no mercado, porém, é fundamental compreender que os profissionais que
atuam nessa nova área, além de possuírem desejável vivência na cultura de
desenvolvimento de software, deverão utilizar técnicas, metodologias e fer-
ramentas bem diferenciadas dos profissionais de desenvolvimento.
17.1. Gerências da Qualidade

O processo de gerenciamento da garantia da qualidade pode estar centraliza-
do em uma única gerência que contemple todos os aspectos da qualidade –
processos (testes de verificação) e produto (testes de validação), como pode
estar segmentado por uma dessas especializações. Um gerenciamento inde-
pendente representa menor nível de complexidade a ser administrada indi-
vidualmente, possibilitando atender a organização como um todo de forma
mais eficiente e melhor focada.
17.1.1. Gerência da Qualidade de Software

É a responsável pela área de Garantia da Qualidade do Software (SQA – Soft-
ware Quality Assurance) que responde pelo gerenciamento dos profissio-
nais de qualidade envolvidos na verificação das diversas etapas de um pro-
cesso de engenharia de software. Sua atuação está voltada diretamente à ges-
tão da garantia da qualidade do processo de software, podendo também ser
expandida para a qualidade do produto, que contempla a Gerência de Teste
de Software. Tem por objetivo avaliar a aderência entre o processo de desen-
volvimento estabelecido e as práticas dos diversos profissionais envolvidos
durante esse processo. Cuida de uma única visão dos trabalhos realizados
nos diversos projetos existentes, negociando eventuais conflitos entre ou-
tras áreas.
17.1.2. Gerência de Testes de Software

É o responsável pela Gerência do Teste de Software que responde pelo ge-
renciamento de todo o processo de testes de software aplicados em uma
organização. Sua atuação está voltada especificamente à estruturação e
condução de um processo de teste de software consistente, que visa à exe-
cução de testes nos mais variados níveis e categorias existentes. Sua mis-
são não está em garantir a adequada realização do processo de engenharia
de software, mas sim na validação do produto tecnológico que está sendo
produzido.
17.2. Profissionais dos Testes de Verificação

Os profissionais voltados aos testes de verificação possuem uma forte visão
de metodologias e processos pois necessitarão transitar por todas as áreas da
organização, avaliando documentos e auditando procedimentos de traba-
lho. A experiência em tecnologia auxilia a execução de determinadas inspe-
ções técnicas e revisões de documentos que empregam padrões e notações
que devem ser respeitadas.
17.2.1. Revisores de Documentos

Esse é um profissional que estará encarregado em conduzir as reuniões
de revisão de documentos e avaliar o nível de qualidade que está sendo
obtido com esse processo. Seu maior objetivo não é contribuir direta-
Gestão dos Profissionais
mente com a reunião de revisão, mas difundir a prática da revisão e garan-

tir a boa aplicação das técnicas durante as atividades de revisão. Auxiliará
no planejamento e execução das revisões e até mesmo na formação de no-
vos revisores.
17.2.2. Auditores da Qualidade

Esse é um profissional voltado a garantir a adequada execução de determi-
nados procedimentos críticos que podem comprometer a qualidade final do
produto de software. Os auditores devem conhecer perfeitamente o proces-
so de engenharia de software e identificar quais pontos estão sendo adequa-
damente seguidos e quais são os pontos de maior fragilidade, relatando as
eventuais quebras de processo que ocorrem em um projeto.
17.3. Profissionais dos Testes de Validação

Esses profissionais devem ter uma forte formação tecnológica e uma alta es-
pecialização em procedimentos de testes de software. Trata-se de uma das
mais novas carreiras da área de tecnologia de software que prometem re-
compensar financeiramente os profissionais que dominem as ferramentas
de testes e consigam automatizar o processo de validação. Um bom conheci-
mento do processo de desenvolvimento de software possibilita aos profissi-
onais aplicar os conceitos de reutilização e componentização na disciplina
dos testes, o que pode significar um ambiente de automação mais flexível e
adaptável a futuras mudanças.
17.3.1. Arquiteto de Testes

É o responsável pela definição de uma arquitetura baseada no reaproveita-
mento de componentes de testes já existentes, minimizando esforços de
construção e de futuras manutenções. Tende a ter uma visão mais corporati-
va do processo, uma vez que seu maior objetivo será planejar a arquitetura
dos diversos ambientes de testes existentes. Deverá ter conhecimentos em
engenharia de software para aplicar os mesmos conceitos nos componentes
de testes, uma vez que auxiliará o analista de testes no planejamento dos
controladores e simuladores, de forma a obter um maior nível de reutiliza-
ção de código possível.
17.3.2. Analista de Testes

Esse profissional é o responsável pelo planejamento, organização e controle
de todo o processo de levantamento, modelagem e definições de como os
testes serão organizados e aplicados em uma única aplicação. O analista
deve possuir uma alta capacidade de abstração de cenários de testes, de for-
ma a compreender o problema e disponibilizar uma solução mais eficiente
possível, reduzindo os esforços e ampliando a efetividade do testes.
17.3.3. Automatizador de Testes

Esse profissional é o responsável pela codificação de componentes de testes
que visam automatizar o processo de testes. Esses profissionais são especia-
listas em determinadas ferramentas (lembrando que existem uma variedade
de situações de testes que requer produtos com objetivos diferentes e, con-
seqüentemente, especialistas diferentes). O automatizador estará interagin-
do continuamente com o arquiteto de testes para minimizar o risco de a au-
tomação não refletir o planejamento realizado. Este profissional também
poderá automatizar o processo de conferência, lembrando que devemos
sempre estar atentos a erros nesse processo, pois uma rotina de conferência
errada poderá sugerir um processo satisfatório quando, na verdade, trata-se
de um erro.
17.3.4. Executor de Testes

Esse profissional é o responsável pela execução diária (testes ativos) ou es-
porádica (teste sob demanda) de um conjunto específico de testes planeja-
dos e devidamente automatizados. Esse profissional emprega ferramentas
integradas ao planejamento e à automação de scripts, de forma a auxiliar o
processo de preparação, execução e conferência dos testes. O executor (tes-
ter) será responsável por avaliar cada erro identificado, registrá-los e enca-
minhá-los para correção.
CAPÍTULO 18
Gestão de
Componentes de Testes
O esforço de desenvolvimento também ocorre nos bastidores dos testes

de software. A criação de programas, com intenção de auxiliar as atividades
de execução e conferência dos testes, será mais intensa à medida que opta-
mos por deixar cada vez mais automatizados nossos procedimentos de tes-
tes. A automação exige um esforço inicial de criação, porém possibilita uma
incomparável eficiência e confiabilidade, impossível de ser atingida com
procedimentos manuais.
Esses componentes de testware devem ser tão bem planejados como
qualquer outro componente de software. Podemos utilizar a notação
UML para planejarmos todas as funcionalidades previstas para esses
componentes. Durante a modelagem de componentes de testes, devemos
buscar sempre o maior nível de reutilização possível, possibilitando uma
redução no número de códigos-fonte relativos a testes de software. Esses
componentes devem ser criados para facilitar e dinamizar todos os níveis
de testes existentes – os testes unitários, integrados, de sistemas e de acei-
te da solução.
Basicamente são dois os tipos de componentes de testes fundamen-
tais: controladores e simuladores. Estes são produzidos em paralelo ao
processo de desenvolvimento do software e são essenciais às atividades
de automação dos testes. São responsáveis por automatizar todo um con-
junto de ações e cenários, possibilitando criar um ambiente de testes di-
nâmico e flexível.
18.1. Controladores de Testes (Test-drivers)

Os test-drivers, aqui apelidados de controladores, são programas desenvol-
vidos especificamente com a finalidade de testar uma unidade de software.
Esses controladores executam chamadas à unidade a ser testada, definindo
uma ordem de execução e um conjunto de parâmetros de entrada que possi-
bilitam testes nos mais diversos cenários existentes.
Os controladores devem “disparar” rotinas encapsuladas de uma deter-
minada unidade e avaliar se os resultados estão “em conformidade” com o
esperado. Ao se executar o disparo, serão exigidos parâmetros que serão ali-
mentados através de uma massa de testes “externa e parametrizável”, de for-
ma a permitir a inserção de novos testes sem que exija mudanças no contro-
lador. Eles são empregados tanto para provocar os diversos cenários de tes-
tes planejados quanto para exercitar a estrutura interna do código-fonte,
possibilitando a medição da cobertura dos testes de caixa branca.
O motivo pelo qual devemos criar controladores está no fato de permiti-
rem o processamento automatizado dos testes proporcionando “rapidez e
confiabilidade” na execução das validações das unidades de softwares. Sem
eles, os testes unitários seriam exaustivos e quase inviáveis, necessitando de
um enorme esforço de teste sempre que existir uma necessidade de modifi-
car o código-fonte de uma unidade de software.
Componentes de Software Controladores de Testes
<< Software >> << Testware >>
Componente A Controlador A
<< Software >> << Testware >>

Classe B TC Classe B
+ Serviço X: + TC Serviço X:
<< Software >> + Serviço Y: + TC Serviço Y: << Testware >>
Classe A + Serviço Z: + TC Serviço Z: TC Classe A
+ Serviço A: + Propriedade X: + TC Propriedade X: + TC Serviço A:
+ Serviço B: + Propriedade Y: + TC Propriedade Y: + TC Serviço B:
+ Serviço C: + Propriedade Z: + TC Propriedade Z: + TC Serviço C:
+ Propriedade A: + TC Propriedade A:
+ Propriedade B: + TC Propriedade B:
+ Propriedade C: + TC Propriedade C:
Figura 18.1 Controladores são criados para testar cada unidade de software
Gestão de Componentes de Testes
Todos os controladores criados para realizar os testes de uma unidade de

software poderão ser perfeitamente reutilizados durante a execução dos tes-
tes integrados. Isso pode ser entendido pelo fato de que, ao criarmos os con-
troladores, cada unidade será testada de forma exaustiva, tendo a garantia de
que as chamadas a outras unidades serão indiretamente testadas durante a
execução dos testes unitários.
Portanto, qualquer mudança de interface que ocorra a uma unidade de
software poderá refletir uma perda de compatibilidade com componentes
de software que utilizam-se do serviço que foi modificado. Basta executar-
mos os controladores dessas unidades e aplicar seus respectivos testes unitá-
rios para garantir se a nova interface foi assimilada por todos os componen-
tes do projeto.
18.2. Simuladores (Stubs)

Os stubs, aqui apelidados de simuladores, são programas que simulam o
comportamento de uma unidade de software ou hardware. Os simuladores
substituem determinadas unidades reais que dificultam ou limitam determi-
nados testes de software. Sua finalidade é reduzir os esforços de execução
dos testes e potencializar as chances de detecção de defeitos. Proporciona
flexibilidade na montagem de cenários de testes e potencializa a automação
em todos os estágios de validação do software.
Os simuladores são muito úteis, pois eliminam as dependências naturais
entre aplicativos (softwares) e dispositivos físicos (hardwares) que integram
uma solução informatizada. Criam artificialmente “respostas simuladas”
que imitam conversas entre aplicativos, possibilitando testes nas mais varia-
das situações, criando uma infra-estrutura de testes favorável à identificação
de erros.
Os simuladores são comumente empregados para substituir componen-
tes de hardware que integram uma solução tecnológica. Os sistemas real
time são exemplos perfeitos disso – estão cada vez mais presentes em setores
da economia que exigem alto grau de automação de suas atividades. Como
esses dispositivos fazem uma leitura real do ambiente, dificultam a criação
de cenários de testes, necessários para avaliar se o comportamento do soft-
ware está adequado com as especificações realizadas. Os simuladores trazem a
vantagem de criar “cenários artificiais” que dificilmente seriam operaciona-
lizados em condições reais de utilização.
Ambiente Real Ambiente Simulado
Sistema de
Carregamento Sistema de
Esteira Rolante Carregamento
<< Simulador>>
<< Hardware>> Controlador de
Esteira
Controlador de
Esteira
Figura 18.2 Utilizando simuladores para eliminar dependências de hardware
Os simuladores também são empregados para substituir softwares que

dificultam a realização de testes em determinados aplicativos. Muitas vezes
a realização de uma simples transação requer o processamento de um outro
sistema, introduzindo uma complexidade muito alta para gerar o volume de
variações necessárias para atender a todos os cenários de testes possíveis. O
simulador reduz drasticamente essa complexidade, pois simplifica o meca-
nismo de resposta em comparação com o sistema original. Com regras bem
simples, podemos fazer com que o simulador interaja diretamente com o
aplicativo que estamos testando e forneça respostas que possibilitem atingir
extensa cobertura de testes, aumentando as chances de detecção de defeitos
no software.
CAPÍTULO 19
Gestão
das Ferramentas
A utilização de ferramentas em um processo de qualidade de software é

tão interessante quanto empregar ferramentas de apoio ao desenvolvimento
de software. O emprego de testes manuais somente é recomendável quando
não existir uma alternativa disponível no mercado. Essas ferramentas são
denominadas CAST (Computer-Aided Software Testing).
Como os testes de verificação de software são baseados, na maioria das
vezes, em documentos de requisitos e especificações, sua automação tor-
na-se extremamente complexa. Mesmo assim, um conjunto de ferramentas
poderá auxiliar na elaboração e gerenciamento de checklists a serem aplica-
das, na gestão dos documentos e controles de suas versões, e em outras di-
versas atividades a serem desempenhadas.
Em relação aos testes de validação, o ideal é criar um ambiente de testes
altamente automatizado. Isso irá refletir em uma redução de custos, melhor
controle e confiabilidade do processo, maior flexibilidade, além de aumen-
tar a efetividade do próprio processo, ou seja, as chances de sucesso na iden-
tificação de erros são mais significativas quando empregamos ferramentas
de testes.
AS INTEGRAÇÕES ENTRE AS DIVERSAS CATEGORIAS
Planejamento Modelagem
de e
Testes Automação
Suporte
aos
Testes
Revisões Execução
e e
Inspeções Conferência
Figura 19.1 Categorias das ferramentas de testes
19.1. Ferramentas de Planejamento de Testes

São ferramentas que apóiam o processo de planejamento dos trabalhos de
testes, definindo escopos, abordagens, recursos, agendando reuniões e pro-
gramando atividades. Geralmente estão apoiadas na coleta inicial de requisi-
tos de software, possibilitando dimensionar o esforço e complexidades en-
volvidas no processo de desenvolvimento.
Essas ferramentas também auxiliam no processo de documentação ini-
cial, possibilitando gerar planejamentos padronizados e na elaboração de es-
timativas de tempo e custos, além de dimensionar as equipes de acordo com
o tempo disponível.
19.1.1. Análise de Criticidade

Essas ferramentas apóiam o processo de priorização de sistemas, identifi-
cando quais sistemas devem ser testados inicialmente. Isso possibilita dire-
cionar esforços de forma eficiente, gerando resultados em curto espaço de
tempo. Permite estimar tempo, custos e equipes através da análise da com-
plexidade de cada software, baseando-se nos requisitos a serem cumpridos.
Gestão das Ferramentas
CARACTERÍSTICAS ENCONTRADAS NESSA CATEGORIA
ANÁLISE DE
CRITICIDADE
Planejamento
de
Testes GERADOR DE
DOCUMENTOS
Figura 19.2 Características das ferramentas de planejamento dos testes
19.1.1. Gerador de Documentos

São ferramentas que facilitam o processo de documentação, através da utili-
zação de parametrizações e modelos de documentos. Gerenciam as versões
de modelos e possibilitam organizar um work-flow de preparação, elabora-
ção, inspeção e aceite dos documentos.
19.2. Ferramentas de Revisões e Inspeções

São ferramentas que apóiam o processo de verificação do software, ou seja,
auxiliam nas revisões de documentos e inspeções técnicas que podem ser
aplicadas em todas as etapas do processo de desenvolvimento.
ANÁLISE DE
COMPLEXIDADE
COMPREENSÃO DO
Revisões CÓDIGO
e
Inspeções
ANÁLISE SINTÁTICA DE
SEMÂNTICA
Figura 19.3 Características das ferramentas de revisões e inspeções

19.2.1. Análise de Complexidade

Desenvolvedores experientes sabem que em 20% do código estão 80% dos
problemas. Essas ferramentas auxiliam a identificar onde estão as áreas mais
complexas e, conseqüentemente, quais possuem maior risco de introduzir
novos erros. Também auxiliam a quantificar o esforço e os custos dos testes
a serem empregados.
19.2.2. Compreensão de Código

Auxiliam na atividade de inspecionar códigos-fonte, possibilitando avaliar a
aderência a padrões de programação estabelecidos pela organização, como:
padrões de nomes, utilização de rotinas corporativas, nível de comentários,
entre outros. Também identifica variáveis não utilizadas, sub-rotinas in-
ternas não acionadas, APIs incompatíveis com determinados sistemas opera-
cionais que a aplicação deverá rodar, entre outras características.
19.2.3. Análise Sintática e de Semântica

São ferramentas que localizam erros na sintaxe e na semântica dos coman-
dos empregados no código, os quais o compilador não acusaria. Dessa for-
ma, é possível identificar defeitos antes de os testes formais serem iniciados.
19.3. Ferramentas de Modelagem e Automação

As ferramentas de modelagem auxiliam no processo de construção e docu-
mentação de como serão testados todos os requisitos de negócio. Possibili-
tam registrar os procedimentos de testes a cada cenário estabelecido e o pro-
cesso de conferência dos dados.
As ferramentas de automação dos testes possibilitam o desenvolvimento
de scripts automatizados, de forma a viabilizar um processo de teste com as
atividades de entrada e conferência de valores totalmente automatizados.
19.3.1. Modelagem de Testes

Auxilia no processo de planejamento e construção dos testes, identificando
os diversos cenários estabelecidos para cada requisito a ser testado. Estabe-
lece um conjunto de procedimentos a serem executados para cada cenário
indicado, definindo como os testes se comportarão durante sua execução.
Determina as informações que devem ser empregadas em cada procedimen-
MODELAGEM
DE TESTES
GERADOR DE
Modelagem MASSA DE DADOS
e
Automação
AUTOMATIZADOR DE
SCRIPTS
Figura 19.4 Características das ferramentas de modelagem e automação
to de teste, atingindo o menor nível de detalhamento. A modelagem dos tes-

tes é um processo mental, sendo que nenhuma ferramenta substituirá a ex-
periência e abstração de um bom analista de testes; porém, essas ferramentas
auxiliam na estruturação das idéias, facilitando a compreensão das decisões
que estão sendo tomadas.
19.3.2. Gerador de Massa de Dados

É extremamente útil contar com uma ferramenta que possibilite gerar auto-
maticamente uma massa de dados baseada no planejamento dos testes e cri-
térios estabelecidos de forma a garantir uma massa diferenciada para cada
dia e nas circunstâncias desejadas.
19.3.3. Automatizador de Scripts

O processo de automação requer ferramentas que possibilitem a interação
entre as rotinas automatizadas e os softwares a serem testados. Também re-
quer que essas ferramentas possuam recursos de conferências automáticas,
possibilitando capturar valores em telas, arquivos, relatórios ou mesmo em
bancos de dados. Dessa forma, essas ferramentas automatizarão não somen-
te as atividades de entrada de informações, como o processo de conferência
(análise da saída das informações).
19.4. Ferramentas de Execução e Conferência

As ferramentas de execução e conferência possibilitam o gerenciamento e o
controle no processo de execução, reexecução e medição dos testes planeja-
dos. As ferramentas possibilitam integração entre as demais fases, de forma a
executar somente os testes selecionados no planejamento.
EXECUTOR DE
SCRIPTS
Execução ANÁLISE DE SIMULADORES DE

COBERTURA PERFORMANCE
e
Conferência
TESTADORES DE
MEMÓRIA
Figura 19.5 Características das ferramentas de execução e conferência
19.4.1. Executor de Scripts

Essas ferramentas estão sempre integradas aos softwares de planejamento de
testes e desenvolvimento de scripts, de forma a executar os procedimentos na
ordem e freqüências preestabelecidas. Permite a gestão do ciclo de testes como
um todo, como o controle de execução de cada caso de testes, o controle da ree-
xecução dos testes e os desvios de testes provocados por erros inesperados.
19.4.2. Análise de Cobertura

Possibilita estabelecer uma métrica de cobertura do teste através do monito-
ramento das linhas de código executadas. Os testes de caixa branca reque-
rem esse tipo de ferramenta, pois possibilita visualizar áreas do código não
cobertas pelos testes em execução.
19.4.3. Testadores de Memória

Auxiliam no processo de detecção de problemas em relação ao uso e aloca-
ção de memória pela aplicação. Trata-se de um ponto sensível em sistemas
client-server, pois podem deixar o software instável. As ferramentas devem

ser específicas para cada linguagem e ambiente. As melhores ferramentas da
categoria são simples de usar e apresentam preços acessíveis.
19.4.4. Simuladores e Medidores de Performance

Nessa categoria é impossível conceber a idéia de realizar testes sem empre-
gar ferramentas específicas. É impraticável, por exemplo, simular a consulta
simultânea de mil usuários em uma determinada situação, ou a visita de 500
internautas à home-page de sua empresa, sem a utilização efetiva de ferra-
mentas. Essas ferramentas estão diretamente ligadas aos testes de sistema,
como os testes de carga, volume e performance.
19.5. Ferramentas de Suporte aos Testes

Essas ferramentas apóiam atividades que não estão diretamente ligadas ao
processo de testes, porém garantem que determinados itens fundamentais
desse processo estão sendo bem gerenciados.
GERENCIAMENTO DE
DEFEITOS
Suporte
aos
Testes GERENCIAMENTO DE
CONFIGURAÇÕES
Figura 19.6 Características das ferramentas de suporte aos testes
19.5.1. Gerenciamento de Defeitos

Essa ferramenta também é conhecida por outros nomes: gerenciamento de
erros, gerenciamento de problemas, registro de ocorrências, controle de in-
cidências etc. Seu objetivo é acompanhar e controlar os defeitos identifica-
dos durante o ciclo de vida do software e monitorá-los até sua solução final.
Essas ferramentas permitem parametrizações de forma a “customizar” um

work-flow de resolução de problemas, para melhor adaptar-se à estrutura do
cliente. Essas ferramentas produzem um grande número de indicadores de
qualidade, como percentual de erros por severidade, análise da eficiência da
resolução dos problemas, distribuição de erros por fase do processo, entre
outros indicadores.
19.5.2. Gerenciamento de Configurações

Permite controle e coordenação das mudanças efetuadas em documenta-
ções, fontes e ambientes físicos. Sua maior contribuição é estabelecer rela-
ções entre diversos artefatos de software e identificá-los através de um único
controle de versão, dessa forma, não é possível acessar documentos de deter-
minada versão enquanto estamos modificando fontes de uma versão ante-
rior. Essas ferramentas são largamente empregadas nos ambientes de desen-
volvimento e produção, sendo adequado utilizar-se da mesma ferramenta
para o gerenciamento do testware.
CAPÍTULO 20
Gestão dos
Custos de Testware
Profissionais, ferramentas, tempo e dinheiro são recursos limita-

dos que reduzem nossa capacidade plena de desenvolver determinado tra-
balho. Significa que nosso esforço está limitado na forma como estamos or-
ganizando nossos trabalhos. Não se trata apenas de fazer as coisas, mas fazer
da forma mais organizada possível. Significa que, se fizermos um bom traba-
lho hoje, teremos menos trabalho amanhã.
Assim como os profissionais de desenvolvimento, que devem sempre
inovar em seus métodos e procedimentos visando ganhar eficiência e redu-
zir custos de desenvolvimento e manutenção, os profissionais de testes tam-
bém têm o mesmo objetivo: organizar o testware de forma a ser o mais eficien-
te e reutilizável possível.
A cada nova versão de um software torna-se necessário realizar um novo
conjunto de testes, visando avaliar as melhorias implementadas. Também é
necessário reexecutar um conjunto de casos de testes (todos ou partes), vi-
sando avaliar se as mudanças realizadas danificaram outras partes do soft-
ware que já funcionavam.
Os custos relativos à execução dos testes de progressão não são impor-
tantes. São importantes os custos de execução dos testes de regressão, pois
estes devem ser continuamente executados ao longo da vida do software. A
cada nova versão existente, um conjunto de procedimentos, já executado,
volta a ser realizado.
PREPARAÇÃO EXECUÇÃO CONFERÊNCIA

DO DOS DOS
AMBIENTE TESTES TESTES
Figura 20.1 Itens que compõem os custos de execução dos testes
20.1. Custos de Preparação do Ambiente

Aqui o objetivo é reduzir o tempo e o esforço envolvidos no processo de pre-
parar o ambiente para que este esteja pronto para sofrer a execução dos tes-
tes. São diversas atividades que são realizadas nessa etapa, como preparação
de hardware, configuração de software, adequação do ambiente para o teste
(aquisição de licenças, instalações diversas), identificação dos testes que de-
vem ser executados e seus elementos associados (geração da massa de testes,
rotinas de scheduling de testes, procedimentos de testes para cada caso de
testes a ser executado, base de dados devidamente tratada).
Existem duas abordagens básicas a serem empregadas na preparação de
um ambiente de testes: o ambiente sob demanda e o ambiente ativo.
Tabela 20.1
Alternativas na preparação do ambiente
Ambiente sob Demanda Ambiente Ativo
G custo de preparação do ambiente G sem custo de preparação do ambiente

G custo de execução único G custo de execução diário
G planejamento mais simples G planejamento mais complexo
G ambiente deve ser criado G ambiente sempre “pronto”
G custo de desmontagem do ambiente G sem custo de desmontagem do
G menor esforço de automação ambiente
G maior esforço de automação
Não é desejável que uma organização tenha uma abordagem única sobre
o problema. É perfeitamente possível (e desejável) conviver com as duas
abordagens simultaneamente. Somente os sistemas considerados críticos
(vitais ao negócio) deverão estar no ambiente ativo. Os demais seguirão as
regras do ambiente sob demanda.
Gestão dos Custos de Testware
20.1.1. Ambiente sob Demanda

Nessa abordagem os sistemas são instalados e todo o ambiente é preparado
visando à execução dos testes. Os sistemas são retirados do ambiente assim
que o processo de testes tenha sido finalizado. Nessa abordagem, não exis-
te o compromisso de continuidade, o que significa que o esforço de monta-
gem e desmontagem se repetirá sempre que for requisitado um novo ciclo
de testes.
20.1.2. Ambiente Ativo

Nessa abordagem todos os sistemas desse ambiente têm seus testes proces-
sados diariamente. Esses sistemas são instalados uma única vez e considera-
dos sistemas ativos. Possuem uma massa de testes diferenciada para cada
dia, evitando que esta se torne inconsistente.
O ambiente ativo é um conceito interessante, pois permite que sejam
eliminados os tempos e custos recorrentes de preparação do ambiente em
cada processo de teste. Este cria um espírito de “prontidão” no processo de
validação do software. Como o ambiente está sempre apto ao processa-
mento de testes, mudanças emergenciais poderão ser rapidamente subme-
tidas ao ambiente ativo. Dessa forma, minimizamos riscos de colocar um
sistema em produção sem que este não tenha sido submetido a um proces-
so formal de testes.
Um ambiente ativo exige um alto grau de automação (que é extrema-
mente desejável). Os processos de testes devem diariamente fluir o mais per-
feitamente possível: massas de testes e scheduling devem ser continuamente
ajustadas e processadas.
20.2. Custos de Execução dos Testes

O objetivo é minimizar o tempo e o esforço envolvido no processo de execu-
ção dos testes. Basicamente, esses custos estão associados tanto à tecnologia
de execução dos testes (manual ou automação) quanto ao grau de cobertura
dos testes (regressão total ou regressão parcial) a serem executados.
Tabela 20.2
Alternativas na execução dos testes
Regressão Total Regressão Parcial
Teste Manual G baixo risco de não-cobertura G alto risco de não cobertura

G alto custo de execução G custo de execução menor
G execução lenta G execução lenta
G reutilização zero G reutilização zero
G interferências humanas G interferências humanas
Teste G baixo risco de não-cobertura G alto risco de não-cobertura

Automatizado G baixo custo de execução G menor custo de execução
G execução rápida possível
G reutilização total G execução mais rápida
G sem interferências humanas possível
G reutilização total
G sem interferências humanas
20.2.1. Testes Manuais

Trata-se da utilização de recursos humanos para realizar todos os procedi-
mentos de testes especificados. Requer um número muito grande de digita-
dores e um controle eficiente de documentos em circulação – uma vez modi-
ficados, estes devem ser substituídos e o anterior destruído. O risco inerente
a essa tecnologia é a grande incidência de erros humanos no processo –
não-execução dos procedimentos na ordem estabelecida e valores digitados
erradamente.
O teste manual deve ser visto com grande restrição. Investir em um pro-
cesso de validação de software e não investir em automação parece ser um
contra-senso. Mesmo em testes não reincidentes (como aconteceu no ano
2000 ou quando ocorrem fusões de empresas), a automação tem papel estra-
tégico, pois possibilita a realização de diversos ciclos repetidos de testes que
ocorrem quando há grande freqüência dessas situações.
20.2.2. Testes Automatizados

Trata-se da utilização de ferramentas de testes que possibilitem simular
usuários ou atividades humanas de forma a não requerer procedimentos ma-
nuais no processo de execução dos testes. Requer profissionais especializa-
dos e tempo no desenvolvimento da automação dos testes.
Gestão dos Custos de Testware
A automação dos testes é altamente desejada por diversos fatores, inclu-

sive em termos de custos finais. Como esse processo requer um investimen-
to inicial, a automação passa a ser encarada como mais um trabalho a ser rea-
lizado. À medida que reexecutamos os testes, o ganho de tempo, controle,
confiabilidade e as diversas possibilidades existentes com essa tecnologia fi-
cam claros como vantagem inerente a esse processo.
20.2.3. Testes de Regressão Total

Nessa abordagem todos os testes são realizados sem qualquer exceção.
Não existe risco nesse processo, porém os custos de execução dos testes
são ampliados. Essa escolha deve estar baseada em uma análise crítica na
relação custos versus risco e em um bom processo de rastreabilidade de
requisitos.
20.2.4. Testes de Regressão Parcial

Nessa abordagem somente um subconjunto dos casos de testes é executado.
Esse subconjunto deve ser identificado através de uma afinidade de negócio
existente entre os casos de testes e as alterações realizadas. Apesar de os cus-
tos serem menores, os riscos de algum caso de teste significativo deixar de
ser selecionado é muito alto, fragilizando o processo de testes. Os testes de
regressão parcial, por envolverem uma dose maior de risco, deveriam ser en-
carados somente quando os custos dos testes de regressão total fossem proi-
bitivos.
20.3. Custos de Conferência dos Testes

O objetivo é minimizar o tempo e o esforço envolvido no processo de confe-
rência e eventual detecção de erros do software. Basicamente, os custos des-
sas atividades dependem da estratégia de conferência, podendo ser manual
ou automatizada.
Qualquer automação realizada no processo de testes poderá empregar
estes três cenários distintos de conferência:
Conferência Automatizada (Automação Completa)

Conferência Manual por Suíte de Teste (Automação Parcial)
Conferência Manual no Final do Processo (Automação Parcial)
Tabela 20.3
Alternativas na conferência dos testes
Conferências Manuais Conferências Automatizadas
G planejamento mais simples G planejamento mais complexo

G maior custo de reexecução G menor custo de reexecução
G execução mais lenta G execução mais rápida
G reutilização zero G reutilização total
G com interpretações humanas G sem interpretações humanas
20.3.1. Conferências Manuais

Trata-se da utilização de recursos humanos para realizar todos os procedi-
mentos de conferência especificados. Requer um grande esforço de compa-
ração de resultados, análise de relatórios e inspeções de arquivos gerados. As
conferências manuais exigem disciplina e um trabalho bem sistemático. De-
vem ser desempenhadas pelos usuários mais graduados e responsáveis pela
gestão do negócio atendida pelo sistema. Um risco inerente desse processo é
a conferência não ser realizada a contento e um determinado caso de teste
errado ser dado como satisfatório. Esse risco é minimizado caso o profissio-
nal seja diretamente responsável pelo aceite final do sistema.
As conferências manuais somente devem ser empregadas quando reali-
zamos testes de aceitação. O usuário somente estará confortável caso possa
avaliar e analisar os resultados dos testes com os próprios olhos.
20.3.2. Conferências Automatizadas

Trata-se da utilização de ferramentas de testes que possibilitem simular usuá-
rios ou atividades humanas de forma a não requerer procedimentos manuais
no processo de conferências. Requer profissionais especializados e tempo no
desenvolvimento da automação das conferências, que devem ser empregadas
em todas as outras situações de testes. As automações propiciam alta eficiên-
cia de detecção de defeitos no processo de validação do software.
A automação da conferência dos testes é altamente desejada por diversos
fatores, inclusive em termos de custos finais. À medida que reexecutamos os
testes, o ganho de tempo, controle e confiabilidade no processo de conferên-
cia deixam nítidas as vantagens.
CAPÍTULO 21
Documentação
do Planejamento
Os documentos são fundamentais para formalizar o processo de quali-

dade de software, possibilitando a todos acompanhar a evolução dos traba-
lhos, sem que necessitem estar diretamente envolvidos. Também possibili-
tam rastrear como as atividades foram planejadas, em que condições foram
executadas e quais defeitos foram identificados.
Na Figura 21.1 está relacionada toda estrutura de documentação refe-
rente ao planejamento da qualidade de um único software.
21.1. Plano de Garantia da Qualidade do Software

Esse é o primeiro documento e o de mais alto nível gerado pelo processo de
qualidade de software. Deve ser elaborado com o objetivo de formalizar o
processo de qualidade a ser iniciado, envolvendo todos os integrantes do
projeto de desenvolvimento, inclusive os clientes, usuários e consultorias
contratadas.
Esse documento é gerado com o objetivo de definir uma visão comum de
todo o esforço de garantir a qualidade que será executado durante do o ciclo
de desenvolvimento do software. Essa atividade pode ser empregada como
forma de transferência de conhecimento, apontando situações positivas e
negativas de outros projetos. Nessa formalização também ocorre um esforço
de convencimento dos ganhos que serão proporcionados por um processo
de garantia da qualidade.
ESTRATÉGIA
VERIFICAÇÃO
MODELO DE NEGÓCIOS
ESTRATÉGIA
VERIFICAÇÃO
PLANO- REQUISITOS
MESTRE DE
VERIFICAÇÃO ESTRATÉGIA
VERIFICAÇÃO
ANÁLISE & DESIGN
ESTRATÉGIA
VERIFICAÇÃO
PLANO DE IMPLEMENTAÇÃO
GARANTIA DA
QUALIDADE DO
SOFTWARE
CASO DE SUÍTE DE
TESTE TESTE
ESTRATÉGIA
VALIDAÇÃO
UNIDADE
CASO DE SUÍTE DE
TESTE TESTE
ESTRATÉGIA
PLANO- VALIDAÇÃO
MESTRE DE INTEGRAÇÃO
VALIDAÇÃO
ESTRATÉGIA
VALIDAÇÃO
SISTEMA
ESTRATÉGIA
VALIDAÇÃO
ACEITAÇÃO
Figura 21.1 Estrutura de documentação do planejamento
PLANO-
MESTRE DE
VERIFICAÇÃO
PLANO DE
GARANTIA DA
QUALIDADE DO
SOFTWARE
PLANO-
MESTRE DE
VALIDAÇÃO
Figura 21.2 Plano de garantia da qualidade do software

Documentação do Planejamento
Os seguintes itens devem ser abordados:
Propósito do documento
Apresentação do processo de verificação e validação
Gerenciamento da garantia da qualidade do software
Equipe de revisões e auditorias (garantir a qualidade do processo)
Equipe de testes de software (garantir a qualidade do produto)
Histórico de experiências passadas e benchmarking
Prinicipais documentações a serem empregadas
Referências a ferramentas, técnicas e metodologias
Referências a padrões, práticas, convenções e métricas
Gerenciamento do testware
Treinamentos necessários
Política de gerenciamento de riscos
Estimativas e macrocronograma
21.2. Plano-mestre de Verificação

Esse é o documento de mais alto nível gerado no processo de verificação do
software e está subordinado ao Plano de Garantia da Qualidade do Software.
Deve ser elaborado com o objetivo de definir e estruturar o processo de veri-
ficação, estabelecendo a visão da equipe de verificação, uniformizando os
conhecimentos, experiências e expectativas dos diversos grupos que inte-
gram o processo de desenvolvimento de software.
ESTRATÉGIA
VERIFICAÇÃO
MODELAGEM DE NEGÓCIOS
ESTRATÉGIA
VERIFICAÇÃO
PLANO DE
PLANO- REQUISITOS
GARANTIA DA
MESTRE DE
QUALIDADE DO
VERIFICAÇÃO ESTRATÉGIA
SOFTWARE VERIFICAÇÃO
ANÁLISE & DESIGN
ESTRATÉGIA
VERIFICAÇÃO
IMPLEMENTAÇÃO
Figura 21.3 Plano-mestre de verificação

Propósito do documento
Detalhes do ciclo do processo de verificação
Principais atividades de verificação
Definição de papéis e responsabilidades da equipe de verificação
Principais documentos a serem empregados
Principais documentos a serem gerados
Referências a técnicas, métodos e ferramentas a serem empregados
Referências a padrões, políticas, formatos a serem adotados
Contratação de treinamento e mentoring
Relatórios a serem produzidos
Cronograma das etapas da verificação
Riscos e contingências
21.2.1. Estratégias de Verificação

Esse é o documento de mais baixo nível gerado no processo de verificação
do software e está subordinado ao Plano-mestre de Verificação. Para cada
fase de verificação, existirá uma estratégia documentada. Seu objetivo é esta-
belecer uma visão clara de como será operacionalizado o processo, estabele-
cendo um escopo bem definido de trabalho, organização das atividades de
levantamentos, definições dos riscos e suas contingências.
ESTRATÉGIA
VERIFICAÇÃO
MODELAGEM DE NEGÓCIOS
ESTRATÉGIA
VERIFICAÇÃO
PLANO DE REQUISITOS
PLANO-
GARANTIA DA
MESTRE DE
QUALIDADE DO ESTRATÉGIA
VERIFICAÇÃO
SOFTWARE VERIFICAÇÃO
ANÁLISE & DESIGN
ESTRATÉGIA
VERIFICAÇÃO
IMPLEMENTAÇÃO
Figura 21.4 Estratégias de verificação

Objetivo do documento
Detalhamento das atividades de verificação
Definição dos grupos de revisão e auditoria
Definição dos papéis e responsabilidades
Documentos que serão verificados
Documentos que não serão verificados
Lista de documentos a serem produzidos
Critério de finalização dos testes
Checklists que serão empregadas
Técnicas, ferramentas e padrões a serem empregados
Cronograma detalhado
Lista de aprovação
21.3 Plano-mestre de Validação

Esse é o documento de mais alto nível gerado no processo de validação do
software e está subordinado ao Plano de Garantia da Qualidade do Software.
Deve ser elaborado com o objetivo de definir e estruturar o processo de vali-
dação, estabelecendo a visão da equipe de validação do software e uniformi-
zando os conhecimentos, experiências e expectativas dos diversos grupos
que integram o processo de desenvolvimento de software.
ESTRATÉGIA
VALIDAÇÃO
UNIDADE
ESTRATÉGIA
VALIDAÇÃO
PLANO DE INTEGRAÇÃO
PLANO-
GARANTIA DA
MESTRE DE
VALIDAÇÃO
SOFTWARE VALIDAÇÃO
SISTEMA
ESTRATÉGIA
VALIDAÇÃO
ACEITE
Figura 21.5 Plano-mestre de validação

Detalhamento das atividades de validação
Definição dos grupos de validação
Áreas do software que serão verificadas
Áreas do software que não serão verificadas
Lista de componentes de testes a serem criados (controladores e simu-
ladores)
21.3.1. Estratégias de Validação

Esse é o documento de mais alto nível gerado em cada fase da validação do
software e está subordinado ao Plano-mestre de Validação. Para cada fase de
validação existirá uma estratégia documentada.
Seu objetivo é estabelecer uma visão clara de como será operacionaliza-
do o processo, estabelecendo um escopo bem definido de trabalho e nivelan-
do expectativas em relação aos testes de software. Também identifica quais
assuntos deverão ser futuramente levantados e detalhados nas fases poste-
riores, aponta riscos e contingências do processo e define os próximos pas-
sos a serem executados.
ESTRATÉGIA
VALIDAÇÃO
UNIDADE
ESTRATÉGIA
VALIDAÇÃO
PLANO DE INTEGRAÇÃO
PLANO-
GARANTIA DA
MESTRE DE
VERIFICAÇÃO
SOFTWARE VALIDAÇÃO
SISTEMA
ESTRATÉGIA
VALIDAÇÃO
ACEITE
Figura 21.6 Estratégias de validação

Detalhamento das atividades de verificação
Definição dos grupos de validação do software
Definição dos papéis e responsabilidades
Escopo do teste (itens a serem validados e itens que não serão validados)
Arquitetura do ambiente de teste
Critério de finalização dos testes
21.3.2. Casos de Testes

Esse documento registra todo o planejamento dos testes de determinados
requisitos que foram estabelecidos durante o desenvolvimento do software.
Esse documento estabelece o que será testado, sendo seu principal objetivo
identificar o maior número de cenários e variações de determinado requisito
de software. Cada cenário será representado por um conjunto de casos de
testes que será validado por uma lista de procedimentos incorporados em
uma suíte de testes que será posteriormente elaborada.
Os casos de testes estabelecem quais informações serão empregadas duran-
te os testes desses cenários e quais serão os resultados esperados, estabelecendo
a massa crítica de testes necessária para validar todos os requisitos do software.
Identificação das condições de testes

Identificação dos casos de testes (o que testar)
Definição de cada caso de teste identificado
Detalhamento da massa de entrada
Detalhamento da massa resultante
Critérios especiais para geração da massa de testes (d+0, d-30, m+1,
a+18)
Responsáveis pelo levantamento
Definir agenda de levantamentos (como testar)
Cronograma
ESTRATÉGIA DE
VALIDAÇÃO
DA UNIDADE
CASOS DE SUÍTE DE
TESTE TESTE
ESTRATÉGIA DE
VALIDAÇÃO DA
INTEGRAÇÃO
CASOS DE SUÍTE DE
TESTE TESTE
ESTRATÉGIA DE
VALIDAÇÃO
DO SISTEMA
CASOS DE SUÍTE DE
TESTE TESTE
ESTRATÉGIA DE
VALIDAÇÃO
DO ACEITE
Figura 21.7 Casos de testes
21.3.3. Suítes de Testes

Esse é o documento que finaliza o processo de detalhamento dos testes de
validação, identificando como todos os casos de testes serão executados e
validados. A suíte de testes estabelece como será testado um determinado
conjunto de casos de testes, definindo quais procedimentos e em que ordem
serão executados, possibilitando validar o comportamento esperado dos vá-
rios cenários de um determinado requisito de software.
ESTRATÉGIA DE
VALIDAÇÃO
DA UNIDADE
CASOS DE SUÍTE DE
TESTE TESTE
ESTRATÉGIA DE
VALIDAÇÃO DA
INTEGRAÇÃO
CASOS DE SUÍTE DE
TESTE TESTE
ESTRATÉGIA DE
VALIDAÇÃO
DO SISTEMA
CASOS DE SUÍTE DE
TESTE TESTE
ESTRATÉGIA DE
VALIDAÇÃO
DO ACEITE
Figura 21.8 Suítes de testes

Identificação de suítes de testes

Descrição das suítes de testes
Pré-requisitos de cada suíte
Definir os procedimentos de iniciação dos testes (setup-up)
Definir os procedimentos de execução dos testes
Definir os procedimentos de conferência dos testes
Definir os procedimentos de limpeza e finalização dos testes (clean-up)
Definir agenda de levantamentos para detalhamentos
CAPÍTULO 22
Relatórios da
Qualidade do Software
Os relatórios têm por finalidade registrar todas as atividades relaciona-

das ao processo de qualidade do software. São utilizados como instrumentos
de medição e análise, permitindo compreender como o software compor-
tou-se durante as fases de verificação e validação.
Na Figura 22.1está relacionada toda estrutura de relatórios referente à
execução de testes de um único software.
22.1. Executando as Verificações

Devem ser aplicadas todas as atividades planejadas na estratégia de verifica-
ção pertinente à fase executada, ou seja, preparar e agendar todas as reuniões
de revisão e todas as auditorias (algumas serão realizadas sem aviso prévio).
As atividades de verificações serão executadas segundo os planejamentos
definidos pelas estratégias definidas para cada uma das etapas.
Cada revisão ou auditoria deve possuir os seguintes itens a serem abor-
dados:
Definição do grupo de revisão

Definição dos papéis de cada participante
Planejamento da revisão (recursos, tempo e materiais)
Agendamento da revisão
Distribuição dos documentos a serem revisados
Relatórios da Qualidade do Software
RELATÓRIO DE
VERIFICAÇÃO DO
MODELO DE NEGÓCIOS
RELATÓRIO DE
VERIFICAÇÃO DE
EXECUÇÃO DOS REQUISITOS
PLANEJAMENTO
TESTES DE
DA VERIFICAÇÃO
VERIFICAÇÃO RELATÓRIO DE
VERIFICAÇÃO DE
ANÁLISE & DESIGN
RELATÓRIO DE
VERIFICAÇÃO DE
IMPLEMENTAÇÃO
LOG DE OCORRÊNCIAS NA
EXECUÇÃO DA VALIDAÇÃO DA
UNIDADE UNIDADE
INTEGRAÇÃO INTEGRAÇÃO
EXECUÇÃO DOS RELATÓRIO
PLANEJAMENTO
TESTES DE FINAL-
DA VALIDAÇÃO TESTE
VALIDAÇÃO LOG DE OCORRÊNCIAS NA
EXECUÇÃO DO VALIDAÇÃO DO
SISTEMA SISTEMA
ACEITAÇÃO ACEITAÇÃO
Figura 22.1 Estrutura de relatórios da qualidade
ESTRATÉGIA DE RELATÓRIO DE
VERIFICAÇÃO DA VERIFICAÇÃO DA
MODELAGEM DE NEGÓCIOS MODELAGEM DE NEGÓCIOS
VERIFICAÇÃO VERIFICAÇÃO
DOS REQUISITOS EXECUÇÃO DOS DOS REQUISITOS
TESTES DE
ESTRATÉGIA DE VERIFICAÇÃO RELATÓRIO DE
ANÁLISE & DESIGN ANÁLISE & DESIGN
IMPLEMENTAÇÃO IMPLEMENTAÇÃO
Figura 22.2 Executando as verificações

22.1.1. Relatório de Verificações

Esse documento é uma análise e sumário de todas as revisões e auditorias
realizadas durante as etapas de verificação. Ao final do processo de execução
dos testes de verificação, deve ser elaborado um documento que resuma to-
das as atividades realizadas. Cada fase de verificação deverá ter seu relatório
final produzido individualmente, de forma que seja possível rastrear as ati-
vidades desempenhadas.
MODELAGEM DE NEGÓCIOS MODELAGEM DE NEGÓCIOS
VERIFICAÇÃO VERIFICAÇÃO
DOS REQUISITOS EXECUÇÃO DOS DOS REQUISITOS
TESTES DE
ESTRATÉGIA DE VERIFICAÇÃO RELATÓRIO DE
ANÁLISE & DESIGN ANÁLISE & DESIGN
IMPLEMENTAÇÃO IMPLEMENTAÇÃO
Figura 22.3 Relatório de verificações
Cada atividade executada deve gerar um documento que possua os se-

guintes itens a serem abordados:
Lista de documentos revisados

Objetivo de cada documento e sua versão
Técnicas e atividades executadas
Número de participantes
Tamanho do material inspecionado
Número de reuniões realizadas
Tempo total de realização da inspeção
Lista de defeitos identificados
Sumário de defeitos (por categorias)
Recomendações e comentários
22.2. Executando as Validações

Devem ser aplicadas todas as atividades planejadas na estratégia de valida-
ção pertinente à fase executada, ou seja, preparar o ambiente e executar todo
o conjunto de testes elaborados na fase de planejamento.
ESTRATÉGIA DE LOG DE EXECUÇÃO OCORRÊNCIAS DE

VALIDAÇÃO DE VALIDAÇÃO VALIDAÇÃO DA
DA UNIDADE DA UNIDADE UNIDADE

VALIDAÇÃO DA DE VALIDAÇÃO VALIDAÇÃO DA
INTEGRAÇÃO EXECUTANDO DA INTEGRAÇÃO INTEGRAÇÃO
RELATÓRIO
TESTES DE FINAL
ESTRATÉGIA DE VALIDAÇÃO LOG DE EXECUÇÃO OCORRÊNCIAS DE
VALIDAÇÃO DE VALIDAÇÃO VALIDAÇÃO DO
DO SISTEMA DO SISTEMA SISTEMA

VALIDAÇÃO DE VALIDAÇÃO VALIDAÇÃO
DO ACEITE DO ACEITE DO ACEITE
Figura 22.4 Executando as validações
Cada execução deve possuir os seguintes itens a serem abordados:
Montagem do plano de execução dos testes

Preparação do ambiente de testes
Geração da massa de testes (entrada e saída)
Execução do plano de execução dos testes
22.2.1. Log de Execução

Esse documento tem por objetivo registrar todos os procedimentos reali-
zados durante a execução de um ciclo de testes, bem como apontar as even-
tuais interrupções e reprocessamentos ocorridos. O log de execução é uma
prova de que os testes foram processados.
Cada ciclo de teste tem atividade executada e deve gerar um documento
que possua os seguintes itens a serem abordados:
Data de execução
Escopo do processamento
Condições de processamento
Lista de itens processados
Itens processados (%)

Itens reprocessados (%)
Tempo de processamento
Lista de itens não processados
Comentários


RELATÓRIO
TESTES DE
FINAL

Figura 22.5 Log de execução
22.2.2. Ocorrências da Validação

Esse documento tem por objetivo registrar todas as ocorrências (suspeitas e
identificações de erros) geradas durante a execução dos testes. Esse docu-
mento contém todas as informações referentes ao erro que foi identificado
durante o ciclo de testes (telas, descrições de ações, mensagens de erros, in-
formações referentes ao ambiente).


RELATÓRIO
TESTES DE
FINAL

Figura 22.6 Ocorrências da validação

Cada atividade executada deve gerar um documento que possua os se-

guintes itens a serem abordados:
Identificação do erro
Data de registro do erro
Descrição do erro
Classificação do erro
Condições do momento em que ocorreu o erro
Seqüências de ações que produziram o erro
Telas capturadas referentes ao erro
Dados sobre o ambiente
Prioridade na resolução
22.2.3. Relatório Final da Validação

Após o término de todas as etapas do processo de validação, um documento
final é produzido com o objetivo de resumir todos os sucessos e insucessos
alcançados. Esse documento também proporcionará uma oportunidade
para rever comportamento e propor ações de melhoria nos próximos pro-
cessos de validação do sistema.


RELATÓRIO
TESTES DE
FINAL

Figura 22.7 Relatório final da validação
Cada atividade executada deve gerar um documento com os seguintes

itens a serem abordados:
Resumo dos principais fatos do processo de validação

Resumo dos resultados obtidos
Comparação com resultados esperados

Avaliação crítica do processo
Recomendações para melhorias futuras
Comentários
Aprovação
CAPÍTULO 23
Medições
Há uma infinidade de dúvidas e questões que vem à tona todos os dias.

São perguntas que muitas vezes envolvem decisões e estas estão sempre as-
sociadas a algum risco. Se nosso objetivo é o sucesso do desenvolvimento do
software, significa que devemos minimizar nossos riscos através de um bom
processo de tomada de decisões. Tomar decisões baseadas somente na intui-
ção é altamente perigoso, ainda mais em um processo complexo como esse.
As informações são fundamentais para que possamos melhor compreender
nossos problemas e atuarmos de forma mais eficiente no dia-a-dia.
As respostas às decisões estão contidas nas diversas informações que o
próprio processo de desenvolvimento está gerando. Basta criarmos um pro-
cesso que contemple o registro destas informações e então utilizá-las da forma
mais inteligente possível para que possamos melhorar nossas decisões e dire-
cionar mais eficientemente nossos esforços na resolução de problemas mais
críticos. Podemos criar diversos critérios de classificação dos indicadores, de
forma a melhorar gerenciar todos os aspectos de um projeto de software. Nos
exemplos que irão seguir, estaremos criando apenas três grupos de indicado-
res para medir o processo de desenvolvimento do software: são os indicadores
de cobertura e eficiência dos testes e os indicadores de defeitos.
Tanto os indicadores de cobertura quanto os de eficiência dos testes es-
tão diretamente associados à medição do Processo de Garantia da Qualida-
de do Software, que estabelece o grau de abrangência dos testes aplicados ao
software como um todo. Essa cobertura pode empregar como referência os
requerimentos do software, os casos de testes, número de linhas de progra-
mas e o número de componentes existentes. Também estabelece o nível de

eficiência da detecção de defeitos, medindo o quanto efetivo foi o processo
de garantia da qualidade aplicado no projeto.
Os indicadores de defeitos do processo estão associados ao Processo de
Engenharia de Software, que estabelece uma medida que define o nível de
eficiência de todas as atividades relacionadas ao desenvolvimento do soft-
ware. Pode medir se determinadas etapas do processo estão tornando-se
mais ou menos eficientes, avaliar o comportamento dos defeitos (se estão
aumentando ou diminuindo), a presteza na resolução dos defeitos encontra-
dos (volume de defeitos abertos e fechados) e estabelecer critérios de com-
paração entre vários projetos em execução.
23.1. Indicadores de Cobertura

Os indicadores de cobertura fornecem o quanto, percentualmente, o produ-
to de software foi adequadamente testado. Essa medida está, na maioria das
vezes, relacionada a quantos requisitos de software foram submetidos a tes-
tes (requeriment-based) ou o quanto das linhas de código foram devidamente
testadas (code-based).
A estratégia de cobertura dos testes deverá empregar ao menos uma das
abordagens citadas. Devemos esclarecer que essas duas abordagens são
complementares, pois buscam defeitos de naturezas diferentes, portanto, o
emprego das duas abordagens ampliará as chances de detecção de proble-
mas, reduzindo os riscos de migração de defeitos.
Conhecer o nível de cobertura dos testes de software é estabelecer um
controle efetivo sobre o produto de software desenvolvido. Através desse
critério, podemos estabelecer o nível de risco (não cobertura) existente no
software, estabelecer o nível de esforço necessário para atingir um maior
grau de cobertura dos testes, auxiliar nas estimativas de futuras projeções de
testes de software, entre outros.
Um dos maiores desafios de um processo de qualidade é conseguir medir
o grau de cobertura dos testes de um software, ou seja, do esforço realizado
pela equipe de testes, do quanto efetivamente conseguimos testar.
Se todos os requisitos estão adequadamente documentados, uma estra-
tégia baseada em sua cobertura pode ser suficiente para quantificar o percen-
tual de abrangência dos testes de software. Se aplicarmos os testes baseados
no código-fonte, empregaremos testes que deverão “exercitar” as rotinas de
programação e avaliar o número de linhas testadas durante o processo, esta-
Medições
.....................................
............................................
.....................................
.............................
..........................................
............................................
.............................
......................................
............................................
Cobertura de Requisitos Cobertura da Estrutura Interna

Figura 23.1 Indicadores de cobertura dos testes
belecendo um percentual de cobertura do código-fonte. Em sistemas críti-

cos, estsa abordagem é altamente recomendada.
23.1.1. Cobertura do Planejamento dos Testes

O nível de cobertura do planejamento dos testes indica quanto percentualmen-
te do software possui testes adequadamente planejados e automatizados. Esse
indicador estabelece o grau de risco existente no software. Produtos com menor
cobertura dos testes apresentam maior probabilidade de defeitos no ambiente
de produção. Esse indicador possibilita medir esse risco e estabelecer níveis di-
ferentes para cada sistema em execução, possibilitando reduzir os esforços.
COBERTURA DO
PLANEJAMENTO Total de Requisitos com Cobertura dos Testes
DE REQUISITOS
Total de Requisitos
Figura 23.2 Índice de cobertura do planejamento de requisitos
COBERTURA DO
PLANEJAMENTO DE Total de Linhas de Código Cobertas pelos Testes
CÓDIGO-FONTE
Total de Linhas de Código
Figura 23.3 Índice de cobertura do planejamento do código-fonte

A figura a seguir compara o atual índice de cobertura do sistema a ser tes-

tado com o padrão exigido para cada nível de criticidade do aplicativo. Quan-
to mais críticos os sistemas forem, maiores serão os impactos causados por
erros do software, necessitando de controles mais rigorosos sobre o software,
o que reflete em níveis de cobertura de testes maiores.
COBERTURA DE Criticidade dos Sistemas COBERTURA

REQUISITOS CÓDIGO-FONTE
Alta
15% Criticidade
90% 90%
25%
80%
75%
70%
Média
60% Criticidade
85% 75%
Baixa
Criticidade
Figura 23.4 Análise da cobertura dos testes
23.1.2. Cobertura da Execução dos Testes

Esse indicador tem por objetivo dimensionar, percentualmente, quanto dos
casos de testes já foram executados. Utiliza-se esse indicador para informar
como está evoluindo o processo de execução dos testes. Observe que, nesse
indicador, não está em questão se os casos de testes falharam ou não, mas se
estes já foram aplicados no processo de validação do software.
O indicador de cobertura de execução dos testes poderá ser apresenta-
do de forma genérica ou segmentado por categorias, como, por exemplo:
nível de cobertura por requisitos de negócio, tecnológicos, de segurança,
entre outros.
COBERTURA DA
EXECUÇÃO DE Total de Casos de Testes Executados
REQUISITOS
Total de Casos de Testes dos Requisitos
Figura 23.5 Índice de cobertura de execução de requisitos

Medições
COBERTURA DA
EXECUÇÃO DE Total das Linhas de Código Executadas pelos Testes
CÓDIGO-FONTE
Total de Linhas de Código a Serem Testadas
Figura 23.6 Índice de cobertura de execução do código-fonte
100%
80%
60%
40%
20%
#1 #2 #3 #4 #5
Figura 23.7 Evolução da cobertura da execução dos testes
Esse indicador tem por objetivo dimensionar, percentualmente, quanto

dos casos de testes já foram executados. Utiliza-se esse indicador para infor-
mar a evolução do processo de execução dos testes. Não está em questão se
os casos de testes obtiveram sucesso ou não. O objetivo é executar 100% dos
casos de testes.
23.2. Indicadores de Eficiência dos Testes

Como serão necessários muitos esforços para alcançar o nível de qualidade
esperado, torna-se fundamental a existência de indicadores que possibili-
tem avaliar o volume de erros detectados em cada etapa do processo. Aqui,
nosso enfoque é avaliar a eficiência dos testes estáticos (realizados em docu-
mentos) e a eficiência dos testes dinâmicos (realizados em softwares).
23.2.1. Eficiência da Verificação

Medir a eficiência da verificação é muito importante, pois as atividades de
verificação são trabalhosas e introduzem custos e esforços adicionais no
processo. A missão da verificação é conseguir identificar o maior número de
erros, de forma a reduzir, ao mínimo, o número de incidências nas fases de

validação. As atividades de verificação são mais soltas e subjetivas do que os
testes realizados em componentes de software, o que dificulta a percepção
de realizar um bom trabalho. Uma forma para medirmos o nível de eficiência
dessa etapa é através do volume de erros ocorridos após o processo de verifi-
cação. Maior incidência de erros revela falta de qualidade das revisões de do-
cumentos, necessitando investir melhor nessas atividades. Esse indicador
deverá também levar em consideração a complexidade do software (empre-
garemos o número de linhas do código-fonte ou o total de requisitos), para
que se possa comparar os processos de diversos projetos.
EFICIÊNCIA
DA Total de Erros da Validação + Total de Erros em Produção
VERIFICAÇÃO
Total de Linhas do Código-fonte ou Total de Requisitos
Figura 23.8 Índice de eficiência da verificação
23.2.2. Eficiência da Validação

Para que possamos identificar o nível de eficiência da validação, precisamos
monitorar o ambiente de produção e registrar todos os erros que ocorrerem
nesse ambiente. Muitos erros em produção indicam que as atividades de va-
lidação não estão sendo bem planejadas, ou seja, o analista de teste deverá
abstrair mais casos de testes, cobrindo um número maior de situações.
EFICIÊNCIA
DA Total de Erros da Validação
VALIDAÇÃO
Total de Erros da Validação + Total de Erros em Produção
Figura 23.9 Índice de eficiência da validação
23.2.3. Eficiência das Etapas dos Testes

A análise da eficiência de cada uma das etapas dos testes possibilita avaliar
quais mecanismos de detecção de defeitos devem ser melhorados e quais es-
tão funcionando. Como sabemos, as etapas iniciais do processo de engenha-
ria de software produzem mais defeitos do que as etapas seguintes, pois são
Medições
nesses momentos que os requisitos são definidos e toda a concepção do soft-

ware é criada. Cabe ao processo de garantia da qualidade de software ter pro-
cedimentos eficientes de detecção de defeitos, para que estes sejam identifi-
cados o mais cedo possível, evitando que tais falhas migrem para as etapas
seguintes do projeto.
Como estamos enfocando o processo de garantia da qualidade de softwa-
re, perceberemos que, com essas informações, começaremos a entender me-
lhor onde estão os pontos de fragilidade do projeto e onde necessitamos de
mais eficiência na detecção dos defeitos, lembrando que esses indicadores
tendem a ser mais precisos e sofisticados à medida que a organização consi-
ga estabelecer fases mais bem definidas e garantir que as ocorrências de defe-
itos estão sendo registradas. Processos de coletas deficientes podem gerar
informações distorcidas e minimizar graves problemas organizacionais.
80
72
60 57
39
40 34
18
20 15 15
13 11
Modelagem de Negócios Requisitos Análise e Modelagem

Implementação Teste de Unidades Teste de Integração
Teste de Sistema Aceite Produção
Figura 23.10 Distribuição de defeitos por etapas
Com bases em informações históricas, poderemos avaliar como está a

eficiência dos testes em todas as etapas do processo de garantia de qualidade
do software. Podemos avaliar se os índices de detecção de defeitos estão de
acordo com parâmetros de qualidade estabelecida a partir de experiências
passadas (extraídos de projetos realizados anteriormente). São informações
que devem ser empregadas para auxiliar no gerenciamento e na condução
das atividades de testes e melhoria do processo de detecção de defeitos.
23.3. Indicadores de Defeitos

Defeitos são falhas de comportamento do software em relação aos requisitos
estabelecidos. A qualidade do software determina o quanto esse software
está próximo dos requisitos e será através dos defeitos encontrados que de-
terminaremos a distância que teremos de percorrer até atingirmos o patamar
de qualidade desejado.
Os defeitos devem ser analisados combinando diversas técnicas e ferra-
mentas, empregando desde simples contagens de defeitos até complexas
análises estatísticas. Toda essa estrutura analítica deverá subsidiar os geren-
tes e profissionais envolvidos no processo de desenvolvimento de software.
Será através dessas análises que decisões importantes serão tomadas, como a
finalização de uma determinada etapa no processo, a implantação do soft-
ware no cliente até a negociação de aumentar prazos e recursos do projeto.
Sabemos quão delicados são esses pontos e, infelizmente, essas decisões são
feitas baseadas em impressões e subjetividades, o que, na prática, significa
falta de controle do processo.
Será através dos defeitos do software que estabeleceremos o nível de qua-
lidade do processo de desenvolvimento. Através de relatórios de origens de
defeitos podemos identificar os pontos mais frágeis do processo e, dessa for-
ma, direcionar esforços para melhorar a eficiência das etapas, tornando-as
mais assertivas e reduzindo os riscos de migração de erros.
O volume de defeitos de um software também proporciona um excelente
indicador de confiança do produto. As análises mais comuns de defeitos es-
tão abaixo representadas:
Distribuição de defeitos por categorias
Prioridade de resolução de defeitos
Severidade dos defeitos
Defeitos por fornecedor
Defeitos por componentes
Idade dos defeitos
Comportamento dos defeitos
23.3.1. Distribuição de Defeitos por Categoria

O indicador de distribuição de defeitos tem por objetivo classificar os defei-
tos para que possam ser estudados e avaliados, de forma a proporcionar uma
base de informações que direcionem os trabalhos de prevenção de defeitos a
serem realizados pela área de qualidade.
Medições
Inicialmente, é comum que os defeitos sejam classificados pela ótica do

usuário, uma vez que este é quem realiza o relato sobre o problema ocorrido.
Essa categorização pode ser entendida como o sintoma do defeito, ou seja,
como este é apresentado ao usuário.
Outra categorização poderá ser realizada após posterior análise sobre a
ocorrência do defeito. Durante a simulação do problema, avaliou-se que a
falha de execução do software é localizada apenas naquela estação, o que ca-
racterizaria como uma falha na instalação local do produto. Esse defeito de-
verá sofrer categorização diferente da anterior, uma vez que este aponta a
origem, não o sintoma do problema.
Essas duas categorizações poderão fornecer informações preciosas para a
equipe de qualidade, possibilitando direcionar esforços baseados em dados
estatísticos coletados durante o ciclo de desenvolvimento, os quais poderão
ser convertidos em ações diferenciadas, como novos treinamentos, revisão de
processos, mudanças em documentos, aquisição de ferramentas e terceiriza-
ção de determinadas atividades. Como exemplo de classificação, segue uma
lista de eventuais sintomas que poderiam ser relatados pelo usuário final:
Falha na Estética
Falha no Ambiente
41%
15%
Erro Fatal
8%
Falha Operacional
Funcionamento
10%
Incorreto
Não Funcional
21%
5%
Figura 23.11 Distribuição de defeitos por categoria
Erro Fatal (o software é derrubado durante a execução de uma funcio-

nalidade).
Funcionamento Incorreto (o software não se comporta como o
desejado).
Não Funcional (a funcionalidade não está disponível).

Falha Operacional (utilização incorreta levou ao erro).
Falha na Estética (não está correspondendo à estética desejada).
Falha no Ambiente (queda do banco de dados ou da rede corporativa).
23.2.3. Prioridade dos Defeitos

Cada defeito de software produz impacto diferente no meio em que o cer-
ca. Em sistemas de negócios, muitos erros de software podem levar a or-
ganização a perder grandes volumes de negócios apenas por uma parali-
sação de poucos minutos. Outros sistemas podem ser interrompidos por
períodos mais longos, porém também terão prejuízos significativos caso
não exista uma resolução no dia seguinte. Outros sistemas podem perma-
necer dias e até semanas sem funcionar, porém não provocarão grandes
prejuízos.
Aqui estamos avaliando a importância do sistema em relação ao meio em
que o software está inserido. Cada funcionalidade provoca um impacto dife-
rente nos negócios e um defeito será considerado crítico se interrompe um
processamento de alta importância nas transações de negócios. Podemos
classificar os defeitos da seguinte forma:
Urgente
Alta Prioridade
Média Prioridade
Baixa Prioridade
A análise dos indicadores de prioridade dos defeitos pode fornecer im-

portantes conclusões sobre o comportamento do projeto, apresentando um
interessante instrumento de gerenciamento muito mais objetivo. Como
exemplo, podemos estabelecer que um grande volume de erros estabeleci-
dos como urgentes e de alta criticidade obrigará uma revisão estrutural na
condução do processo de desenvolvimento.
Esse indicador pode fornecer um excelente critério de sucesso sobre
projetos de desenvolvimento de software. Podemos estabelecer que, na
primeira execução dos testes funcionais de determinado componente,
obter total ausência de erros Urgentes e um número inferior a três erros
de Alta Prioridade pode ser entendido como um processo realizado com
relativo sucesso.
Medições
20
15
10
Urgente Alta Média Baixa

Prioridade Prioridade Prioridade
Figura 23.12 Distribuição dos defeitos por prioridade
Também podemos empregar esse indicador nos critérios de finalização

dos trabalhos, estabelecendo que sistemas de média criticidade com ausên-
cia de erros Urgentes e de Alta Prioridade podem ser implantados no ambi-
ente de testes e homologação.
23.3.3. Distribuição de Defeitos por Fornecedor

Esse indicador pode ser usado por organizações que empregam diversos siste-
mas terceirizados em seus ambientes de produção. É muito comum observar-
mos como a falta de qualidade dos fornecedores de software pode complicar a
vida dessas organizações, aumentando os gastos com testes de software e ge-
Fornecedor E
20% Fornecedor F
20%
Fornecedor D
4%
Fornecedor A
16%
Fornecedor C Fornecedor B
29% 11%
Figura 23.13 Distribuição de defeitos por fornecedor
rando maior número de problemas no ambiente de produção. Uma distribui-

ção de erros por fornecedor possibilitaria demonstrar quais empresas estão
trazendo um maior número de problemas para dentro da organização.
Esse indicador deverá ser empregado para monitorar o comportamento
da qualidade de seus fornecedores, podendo ser utilizado como instrumento
de negociação contínua. Como é possível estabelecer mecanismos de com-
paração entre fornecedores, podemos empregar os melhores números como
referências a outras empresas e estabelecer prazos para que estas alcancem o
mesmo patamar de qualidade, sob pena de não participarem de novos proje-
tos de desenvolvimento. Com certeza, os fornecedores estarão mais preocu-
pados em atender as suas exigências e irão melhorar seus processos internos
de desenvolvimento, refletindo em uma redução de defeitos em seus soft-
wares construídos.
23.3.4. Distribuição de Defeitos por Componentes

Uma solução é composta por um conjunto específico de componentes de soft-
ware e hardware. Quando um sistema apresenta um volume considerável de
problemas, muitas vezes isso é conseqüência direta de má modelagem de um
ou mais componentes. Falhas de modelagem são mais comuns do que imagi-
namos e suas conseqüências podem ser desde lentidões de processamento até
quedas freqüentes do software. Registrar quais são os componentes que estão
desestabilizando o software pode ser um ótimo indicador para justificar uma
total remodelagem e conseqüente redução nos futuros defeitos.
Hardware A
21%
Componente D Hardware B
35% 11%
Componente A
5%
Componente B
16%
Componente C
12%
Figura 23.14 Distribuição de defeitos por componentes (software e hardware)

Medições
Ao mesmo tempo em que identificamos os componentes mais instáveis

do projeto, também localizamos os componentes que apresentam a menor
incidência de defeitos, possibilitando avaliar quais práticas estão permitin-
do gerar uma codificação mais eficiente. Essa equipe poderá assessorar as
outras, de forma a transferir essas práticas e disseminar seu sucesso para ou-
tros grupos, melhorando os índices de qualidade de todos os componentes
do projeto.
Essas análises devem ocorrer durante a execução do ciclo de desenvolvi-
mento, de forma a possibilitar um gerenciamento mais pró-ativo do proces-
so. À medida que os defeitos são coletados e identificados os componentes
mais problemáticos, cabe ao gerente do projeto analisar as informações e
propor ações para minimizar os defeitos.
23.3.5. Distribuição de Defeitos por Idade

Uma forma simples de analisarmos a eficiência da correção de defeitos do
software é avaliar o tempo que determinado defeito leva para ser soluciona-
do. Esse indicador proporciona uma visão sobre o volume de trabalho das
diversas equipes que estão atuando diretamente no desenvolvimento do
software.
40
35
30
25
20
15
10
5
0
1-5 dias 6-10 dias 11-15 dias 16-20 dias
Figura 23.15 Distribuição dos defeitos por idade
Se um grande volume de “erros antigos” permanece em desenvolvimen-

to, isso leva a acreditar que a equipe de desenvolvimento está muito atarefa-
da, o que indica problemas com o volume de desenvolvimento. Porém, se es-
ses mesmos “erros antigos” foram corrigidos mas ainda aguardam a execu-
ção dos testes de validação, podemos inferir que os recursos dedicados a tes-
tes estão muito sobrecarregados.
100%
80%
60%
40%
20%
0%
#1 #2 #3 #4 #5 #6
Em Análise Em Desenvolvimento Em Teste
Figura 23.16 Distribuição dos defeitos por situação
23.3.6. Comportamento do Defeito

A combinação de indicadores referentes à situação do defeito pode demons-
trar tendência no comportamento do projeto em descobrir e resolver proble-
mas identificados. No início do ciclo de testes, é comum que o volume de
novos erros tenha uma tendência crescente, pois as atividades de testes são
executadas e muitos defeitos descobertos. Após esse ponto, a curva de defei-
tos em aberto cai lentamente até atingir o ponto zero.
No entanto, o comportamento dos defeitos pode não corresponder a essa
situação. Se a curva de defeitos em aberto se mantiver alta, é sinal de defi-
ciência no processo de correção dos defeitos (corrige um e insere novos er-
45
40
35
30
Novos
25
20 Em Aberto
15 Fechados
10
5
0
#1 #2 #3 #4 #5 #6 #7 #8
Figura 23.17 Tendências dos defeitos durante o ciclo de vida dos testes
Medições
ros) ou nos procedimentos de testes (a cada execução dos testes encontra-

mos erros não identificados anteriormente). Os dois sintomas devem ser
atacados porque prejudicam o andamento do projeto.
É possível tomar decisões importantes apenas monitorando essas infor-
mações; por exemplo, é possível propor uma atualização de versão se existi-
rem somente erros de baixa severidade. Também é possível negociar mais
tempo caso os erros em aberto, de alta e média severidades sejam muito altos
e o prazo para a atualização da nova versão esteja próximo.
23.3.7. Outros Indicadores

Existe uma infinidade de outros indicadores que podem ser monitorados
dentro de um processo de qualidade de software, porém, os abaixo relacio-
nados são fundamentais para a boa gestão do processo:
Média de tempo de correção de problemas

Média de erros por complexidade do sistema
Média de custos de um erro:
J Custo do erro na produção
J Custo da investigação e diagnóstico
J Custo da correção
J Custo de teste
J Custo da implantação
23.4. Avaliando os Indicadores

É muito importante que as organizações empreguem continuamente indica-
dores em todas as situações. Por razões culturais que desconheço (talvez
pelo apego à informalidade ou mesmo pela orientação dos trabalhos de cur-
to prazo), a maioria das empresas não está acostumada a utilizar métricas no
seu dia-a-dia. Os gerentes de informática dificilmente sabem quanto custou
efetivamente produzir um software, desconhecem como foi distribuído esse
esforço, qual parte do software consumiu mais tempo e se a produtividade
da equipe está melhorando ou piorando. Estão sempre na escuridão, toman-
do decisões baseadas na experiência e na impressão. Parece que esse modelo
está cada vez mais incompatível com as exigências de eficiência necessárias
para que as organizações mantenham-se competitivas; portanto, comece a
trabalhar já seus indicadores de qualidade antes que seja tarde demais.
23.4.1. Histórico das Informações

Sempre acompanhe o comportamento de seus indicadores. É fundamental
analisarmos se a tendência de um determinado valor é de estabilidade, cres-
cimento ou queda. Quando existirem mudanças abruptas de comportamen-
to, analisar quais são os motivos para esse comportamento. Todo esse co-
nhecimento acumulado fará com que decisões futuras sejam melhor imple-
mentadas e planejadas com essas informações.
Produtividade
20 Troca
Retrabalho de
Tecnologia
15
10
Figura 23.18 Histórico de produtividade e retrabalho
23.4.2. Diagrama de Causa e Efeito

Quando estamos diante de um problema (efeito), devemos analisar os possí-
veis fatores (causas) que alimentam a situação. O diagrama de causa e efeito
(também conhecido como espinha de peixe) é um excelente instrumento
para se documentar e analisar quais são os fatores que geram determinado
Falha na Implantação Homologação

Automação Emergencial Manual
dos Testes
Erros
no
Ambiente
de
Produção
Ausência Falha no
de Testes Planejamento
Regressivos dos Testes
Figura 23.19 Diagrama de causa e efeito (espinha de peixe)

Medições
problema. Sua representação é muito simples – cada causa é uma das espi-
nhas que representam a contribuição para a geração de um determinado
problema.
23.4.3. Diagrama de Paretto

Quando estamos definindo uma relação causa-efeito, podemos aplicar uma
regra genérica chamada 80-20 que estabelece uma relação entre esfor-
ço-benefício. A regra demonstra que 20% das causas representam 80% dos
problemas; os 20% dos itens representam 80% dos custos; 20% das ativida-
des representam 80% dos esforços.
Com base na regra 80-20, necessitamos focar nossas investigações em
apenas 20% dos itens, pois a melhoria nesses pontos irá gerar benefícios mui-
to mais expressivos. Dessa forma, o diagrama de Paretto é empregado para
determinar quais são os itens da lista dos 20% que iremos trabalhar.
45 %
40%
33 %
30%
20%
13 %
7%
10%
2%
Homologação Ausência Falha no Implantação Falha na

Manual de Testes Planejamento Emergencial Automação
Regressivos dos Testes dos Testes
Figura 23.20 Distribuição dos defeitos por prioridade
23.4.4. Cuidados na Análise das Informações

Devemos ter muito cuidado quando estamos comparando projetos e equi-
pes por meio da análise de informações históricas e indicadores. Necessita-
mos sempre questionar se as grandezas entre as informações são as mesmas,
por exemplo, um fornecedor X com 30 erros e o fornecedor Y com 10 pode
nos levar a uma falsa conclusão de que o segundo possui melhor qualidade
do que o primeiro; porém, isso pode mudar se o primeiro fornecedor for res-
ponsável por muito mais sistemas do que o segundo fornecedor. Mesmo que
ambos apenas forneçam um único sistema, estes possuem complexidades e
abrangências muito distintas, impossibilitando uma simples comparação
com os valores brutos. Torna-se fundamental estabelecer medida de com-
plexidade que possibilite converter esses valores em unidades de mesma
grandeza, possibilitando a comparação entre projetos. Nesse mesmo exem-
plo, poderíamos utilizar os requisitos como nossa unidade de complexida-
de: o fornecedor X atende 1.000 requisitos enquanto o fornecedor Y atende a
somente 200. Realizando uma simples operação matemática conseguimos
ajustar esses indicadores e obter números com as grandezas idênticas – o
primeiro fornecedor apresenta-se como o mais eficiente, pois produz 30 erros
em cada 1.000 requisitos, enquanto o segundo fornecedor produz 50 erros com
o mesmo volume de requisitos.
Outro fator muito importante é a qualidade da informação que está sen-
do coletada para alimentar esse banco de conhecimento sobre os projetos.
Na maioria dos levantamentos realizados os indicadores são irreais, pois, in-
tencionalmente, querem esconder a ineficiência do processo atual de desen-
volvimento (como se ninguém soubesse disso). Sem informações reais, nos-
sas decisões serão limitadas e irão produzir resultados pouco expressivos.
Muitas vezes quem está registrando as informações não foi devidamente
orientado e não compreende como estas serão empregadas para auxiliar o
próprio andamento do projeto. Cabe à gerência acompanhar cada profissio-
nal envolvido no processo de engenharia do software, orientando os mem-
bros da equipe sobre a importância de métricas consistentes e de sua depen-
dência direta com os procedimentos de coletas de informações, para que to-
das decisões sejam tomadas com base em informações que expressem a rea-
lidade dos fatos, mesmo que essa realidade seja dolorosa.
Com informações reais e um processo de tomada de decisões bem plane-
jado, teremos um gerenciamento do projeto muito mais eficiente e bem ob-
jetivo, possibilitando a todos os membros da equipe realizar uma auto-avalia-
ção de seu próprio trabalho, distribuindo a responsabilidade da boa execução
do projeto a todos os integrantes do projeto.
CAPÍTULO 24
Aplicando Testes
em Softwares
Em uma organização, podemos encontrar softwares em duas situações

diferentes: em produção (legado) ou em processo de desenvolvimento. Em
ambas as situações, os processos de testes podem ser aplicados em sua totali-
dade, independentemente do grau de documentação que está sendo produ-
zido. É claro que um processo de desenvolvimento mais formal tornará a ati-
vidade de testes muito mais produtiva do que um processo informal de de-
senvolvimento.
Quando estamos criando um planejamento de testes para um sistema
legado, devemos considerar que as documentações são incompletas e a
maior parte das informações está com os profissionais que atuam direta-
mente no desenvolvimento da aplicação. Não existe documentação for-
mal das regras de negócio que estão sendo aplicadas internamente em um
aplicativo que está em produção. Os processos de testes podem ser uma
excelente oportunidade para se resgatar esse conhecimento que está per-
dido na organização.
Os sistemas em desenvolvimento já obedecem a uma lógica diferente,
pois temos a oportunidade de conduzir o processo de forma a garantir que
determinados documentos sejam produzidos e facilitem as atividades de tes-
tes. Nesse cenário, os testes acontecem paralelamente ao desenvolvimento,
garantindo que cada parte do software seja validada em relação a sua estru-
tura interna e em relação aos requisitos que este implementou.
Sistema
<< Batch >>
Dependente
Sistema
1
Dependente
2.1
<< On-line >>
<< Batch >>
Sistema Sistema
<< On-line >>
a ser Dependente
<< On-line >> Sistema
Testado 2
Dependente
2.2
<< On-line >>
<< Batch >>
Sistema
Dependente << Batch >>
<< Batch >>
3 Sistema
Dependente
2.2
Figura 24.1 A ausência de simuladores deixa os testes complexos e inviáveis
24.1. Testes em Softwares Legados

Sistemas legados são os sistemas que já estão em produção e, portanto, são
somente atualizados quando são submetidos a melhorias, adaptações a re-
gras preeexistentes, ou mesmo para correção de erros identificados. Na maior
parte das vezes, esses sistemas não possuem um bom planejamento de testes
que garanta a qualidade final ao software a ser disponibilizado na produção
quando estes forem submetidos a uma manutenção corretiva ou na inserção
de novas funcionalidades.
24.1.1. A Documentação do Projeto como Fonte Inicial

A documentação sempre é citada como fonte confiável de informações
(apesar de sabermos que estas quase nunca estão atualizadas). Alguns
profissionais não entendem por que necessitamos de mais informações
para podermos produzir um volume de cenários de testes adequado aos
processos que o sistema contempla, mesmo tendo acesso a essa docu-
mentação “tão rica em detalhes”. Cabe esclarecer que a maior parte des-
sas documentações existentes nesses sistemas é limitada, incompleta e
imprecisa, fruto da falta de sincronismo entre a documentação e as mu-
danças que vão sendo agregadas ao software, sem existir a prerrogativa de
atualizar os documentos.
Aplicando Testes em Softwares
Nesses sistemas, a documentação, na maior parte das vezes, será aplica-

da como fonte inicial de informações, de forma a criar uma visão “superfi-
cial” sobre o software e sobre os aspectos de negócio que estão sendo trata-
dos dentro do aplicativo. Não são necessários apenas documentos técnicos,
muitas vezes manuais orientados ao usuário podem auxiliar na compreen-
são do software; porém, necessitaremos de informações mais precisas e de-
talhadas nos próximos passos do planejamento dos testes.
24.1.2. O Analista de Sistemas como Fonte Principal

Nos sistemas legados, não existem mais discussões com as áreas de negócio e
as documentações já foram produzidas (com um nível insuficiente de infor-
mações). Dessa forma, a única maneira de o analista de testes produzir seu
planejamento é levantar essas informações com o próprio analista de sistemas
responsável, uma vez que ele conhece todas as particularidades do software,
suas deficiências, seu escopo, suas interfaces, entre outros softwares.
Lembramos que o analista de testes deve utilizar-se de todos os mecanis-
mos possíveis para tentar interpretar o software, utilizando o próprio aplica-
tivo e lendo todas as documentações existentes. Porém, o analista de siste-
mas será a fonte mais “confiável”, confrontando com todas as demais infor-
mações. Isso não significa deixar o analista de sistemas planejando os testes,
o que seria totalmente incoerente com nosso discurso. Ele apenas estará
apoiando “continuamente” o analista de testes na definição dos cenários que
possam validar as regras de negócio.
24.1.3. Área de Negócio Valida os Casos de Testes

A área de negócio atua como validadora do planejamento dos testes, anali-
sando todos os cenários que estão sendo incorporados para garantir a quali-
dade final do produto. A área de negócio também pode contribuir com o le-
vantamento dos casos de testes, apontando situações críticas e de exceções,
contribuindo para ampliar o nível de qualidade do teste e aumentando as
chances de detecção de problemas.
24.2. Testes em Softwares em Desenvolvimento

Quando estamos diante do desenvolvimento de um novo software, a área
de qualidade deve organizar-se para atuar paralelamente ao desenvolvi-
mento, pensando e planejando o processo de validação do software. No en-
tanto, o analista de testes necessita de uma fonte de informações perma-

nente para que este entenda o contexto de negócio ao qual o software está
inserido e, assim, produzir os testes necessários para garantir sua adequa-
da funcionalidade.
24.2.1. A Documentação do Projeto como Fonte Principal

A documentação sempre é citada como fonte de informação do projeto.
Sempre que nos deparamos com um novo projeto de desenvolvimento, exis-
te uma promessa de produzir uma documentação “perfeita”. Porém, a expe-
riência demonstra que as várias mudanças de processos e metodologias con-
tribuíram muito para o aperfeiçoamento das documentações, mas não ga-
rantem uma documentação sem falhas. Nesse exato momento alguém pode
estar especificando regras de negócio e deixando vários cenários sem docu-
mentação simplesmente porque ainda existe grande informalidade no pro-
cesso de desenvolvimento. Enquanto isso ocorrer, os documentos estarão
incompletos e desatualizados, gerando uma dificuldade de empregá-los
como uma “fonte única de informação”.
24.2.2. Não Envolver Usuários Diretamente nos Testes

Quando encontramos a falta ou imprecisão de documentos em um ambiente
de desenvolvimento, constatamos o nível de informalidade existente no
processo. A falta de informações confiáveis é um grande impeditivo para um
bom planejamento dos testes. Nessa condição, os usuários são os primeiros
a serem lembrados, pois representam a própria essência de negócio da qual a
aplicação suportará. Porém, aplicar novos levantamentos com usuários se-
ria inviável, uma vez que estes já foram entrevistados pelos analistas de siste-
mas e não estão dispostos a sofrer o mesmo interrogatório. Devemos descar-
tar os usuários como uma nova fonte primária de informações.
24.2.3. Não Depender das Informações do Analista

Sem uma documentação precisa e sem acesso aos usuários, o próximo nome a
ser recomendado para abastecer o analista de testes com informações é o pró-
prio analista de sistemas – responsável por desenvolver a solução. Porém, o
analista de sistemas é um recurso dedicado na solução do software. Suas aten-
ções e energias estão direcionadas a modelar uma solução capaz de refletir os
processos de negócio e suportar as diversas operações do dia-a-dia. Somente
dispensará um tempo ao analista de testes quando sentir que suas tarefas fo-
ram cumpridas e bem encaminhadas. Caso isso não ocorra, este pode prejudi-
car o planejamento dos testes em função de sua falta de disponibilidade em
transferir os conhecimentos de negócio adquiridos durante o projeto. Portan-
to, devemos descartar os analistas de sistemas como principal fonte de infor-
mações.
24.2.4. Participar das Reuniões de Definição dos Negócios

Sem uma documentação precisa, sem a disponibilidade dos usuários e
sem a ajuda do analista de sistemas para repassar o conhecimento do ne-
gócio não será possível ao analista de testes obter um conjunto de infor-
mações para realizar um planejamento de testes de alto nível. A única saí-
da é incluir esse profissional nas etapas iniciais do processo de engenha-
ria do software, participando das principais reuniões de definições do
software. À medida que as decisões são tomadas, os analistas já estão cien-
tes das complexidades de negócio envolvidas e poderão planejar seus tes-
tes com maior probabilidade de detectar erros. Assim, a única saída é en-
volver o analista de testes o mais cedo possível no processo de desenvol-
vimento do software.
24.3. Testes Podem Dilatar os Prazos de Implantação

Os sistemas em desenvolvimento devem ser considerados um problema à
parte. Por não estarem em produção, é natural que exista uma forte “pressão
organizacional” para que o software seja rapidamente disponibilizado para
os usuários finais. A tarefa de aplicar um processo efetivo de teste de softwa-
re adiciona uma nova fase no processo de desenvolvimento e isso significa
mais tempo e dinheiro para colocarmos um software em produção. O im-
pacto disso é um aumento nos prazos de finalização de um projeto de desen-
volvimento de software, uma vez que a fase de testes consumirá tempo e re-
cursos adicionais anteriormente não empregados.
Dependendo de como o processo de qualidade é organizado, teremos
uma maior ou menor eficiência operacional. É importante avaliar que,
determinadas situações engessam o processo, reduzindo seu dinamismo,
podendo provocar uma alta ociosidade e dependência de outras áreas.
Existem 2 abordagens possíveis para implantar um processo de testes em
projetos de software em desenvolvimento: o modelo “lento” e o modelo
“rápido”.
PROCESSO DE TESTES OCORRENDO EXATAMENTE

APÓS O TÉRMINO DO SOFTWARE. Tempo Gasto sem
Modelo Otimização
“lento”

Requisitos

Requisitos
Modelo
“rápido” Tempo Gasto com Tempo
PROCESSO DE TESTES QUE OCORRE
PARALELAMENTE AO DESENVOLVIMENTO
Otimização Ganho
DO SOFTWARE
Figura 24.2 Abordagens possíveis para a aplicação dos testes
O modelo “lento” é caracterizado por um processo seqüencial, no qual

os profissionais de testes somente atuarão após o término do software, ou
seja, todo o planejamento e automação dos testes deverá acontecer somente
após a finalização do software, dilatando os prazos para a realização dos tes-
tes do aplicativo. A falta de tempo deixará os processos curtos, sem planeja-
mento e pouco eficientes.
O modelo “rápido” é caracterizado pelo paralelismo. A participação dos
analistas e automatizadores de testes ocorre desde as fases iniciais do proces-
so de desenvolvimento do software para que os tempos de planejamento e
construção sejam diluídos durante as fases iniciais, provocando redução no
tempo final de implantação do software, portanto, a participação dos profis-
sionais de testes durante todo o processo de desenvolvimento é de extrema
importância no prazo final de implantação do aplicativo.
É importante salientar que os analistas e automatizadores estão partici-
pando das fases iniciais com o objetivo de planejar e construir o ambiente de
testes e não para avaliar a qualidade e precisão dos documentos gerados pela
equipe de desenvolvimento. Isso será tarefa de outro profissional com foco
específico na atividade (revisores e auditores), analisando a qualidade e a
padronização de documentos e atividades realizadas dentro do processo de
engenharia de software.
24.4. Classificando Sistemas

Seguindo o critério de “retenção e disponibilização da informação” pode-
mos classificar os sistemas em três formas distintas: sistemas real-time,
on-line e batch.
24.4.1. Sistemas Real-time

O critério de retenção da informação avalia a capacidade do sistema em
identificar os fatos geradores e registrá-los no exato momento em que estão
ocorrendo. Esses sistemas conseguem interagir diretamente com o meio
ambiente sem que exista a necessidade de eventos humanos para alimentar
essas informações. Os sistemas que possuem a capacidade de retenção da in-
formação “em tempo real” são chamados de sistemas real-time.
Esses sistemas são complexos, pois necessitam de funcionamento “con-
tínuo”, o que exige uma característica fundamental – tolerância a falhas. Isso
significa a existência de contingências automatizadas impedindo sua queda.
A retenção da informação em tempo real somente é possível através do em-
prego de dispositivos físicos que coletam informações do meio ambiente,
seja a umidade do ar, temperatura ambiente, velocidade de uma esteira e a
localização de automóveis.
À medida que intensificamos o uso de tecnologia nos processos de negó-
cio, mais presente está a utilização de dispositivos físicos que automatizem o
processo de coleta de dados, tornando mais viável e freqüente o emprego de
softwares baseados em tecnologia real-time. Essas tecnologias estão cada
vez mais acessíveis e integradas ao conjunto de soluções tecnológicas exis-
tentes em uma organização.
24.4.2. Sistemas On-line e Batch

O critério de disponibilização da informação avalia como uma solução tec-
nológica distribui a informação, seja através de coletores de dados (disposi-
tivos físicos), seja através da alimentação manual por usuários.
Se essas informações são distribuídas no ato em que são registradas, en-
tão podemos considerar que o sistema libera seqüencialmente cada informa-
ção recebida e a disponibiliza “uma após a outra”, formando uma cadeia
contínua e linear de dados que estarão acessíveis a outros sistemas. Esses sis-
temas são chamados de sistemas on-line. Porém, outros sistemas compor-
tam-se de forma diferenciada, não disponibilizando as informações no mes-
mo momento em que são registradas. Os dados são acumulados e somente
disponibilizados quando determinado intervalo de tempo ou ação ocorre.

Quando distribuídas, essas informações são repassadas “em lotes” a outros
sistemas, caracterizando os sistemas batch.
24.4.3. Dimensão Tempo em Cada Tipo de Sistema

Em qualquer plataforma tecnológica é comum encontrarmos aplicativos que
possuam as características de sistemas real-time, on-line e batch ao mesmo tem-
po. Nesses casos, esses aplicativos serão classificados segundo seu comporta-
mento mais comum ou pela funcionalidade mais representativa do sistema.
Os sistemas on-line e batch são os mais presentes nas organizações, po-
rém, cada vez mais encontramos soluções baseadas em sistemas real-time.
As tecnologias estão ficando mais estáveis e baratas, aumentando o interesse
por esse tipo de solução.
Sistemas real-time, como o próprio nome diz, tem como característica
fundamental a dimensão tempo. São sistemas mais complexos, pois necessi-
tam lidar com mais variáveis do que um típico sistema on-line. O sistema real-
time precisa estar preparado para manipular respostas obedecendo a limites
de tempo preestabelecidos, permitir execução simultânea através do proces-
samento paralelo, ser confiável e tolerante a falhas.
:Mundo Real :Fato Gerador :Registrador :Integrador
T0 Criar()
T1 Registrar()
T2 Integrar()
Figura 24.3 Dimensão tempo em sistemas batch
T0 Criar()
T1 Registrar() Integrar()
Figura 24.4 Dimensão tempo em sistemas on-line

T0 Criar() Registrar() Integrar()
Figura 24.5 Dimensão tempo em sistemas real-time

CAPÍTULO 25
Simulando
Integrações Batch
É muito comum encontrarmos sistemas que trocam informações em lote

(batch) com outros aplicativos, sejam eles internos ou externos à organiza-
ção. Em ambas as situações, as operações do sistema dependem diretamente
do processamento e envio dessas informações por outros aplicativos, crian-
do um obstáculo adicional na realização de testes. Se desejarmos provocar
uma determinada situação no sistema, teremos que interagir com os outros
softwares de forma a produzir o resultado desejado. Muitas vezes, temos que
percorrer um longo processo para possibilitar a simulação de um determina-
do cenário, o que aumenta muito a complexidade dos testes.
Imaginemos que nossa solução a ser testada é um sistema de vendas.
Esse sistema coleta todas as entradas de pedidos realizadas pelos vendedo-
res, nas quais são informados os produtos e suas quantidades, descontos e as
condições de pagamento negociadas com o cliente.
Em um determinado momento do dia, todos os pedidos cadastrados se-
rão enviados em lote ao sistema de Análise de Crédito para que sofram avalia-
ção detalhada do risco envolvido em cada transação. Como as entregas são
imediatas e os pagamentos em até 120 dias, o risco financeiro dessas opera-
ções é muito alto.
Simulando Integrações Batch
Ambiente Client-server Ambiente Mainframe
Exporta Pedidos Pedidos Importa Pedidos

Recém-cadastrados Digitados para Análise de Crédito
Sistema Sistema de
de Análise de
Vendas Crédito
Importa Resultado Pedidos Exporta Resultado

da Análise de Crédito Analisados da Análise de Crédito
Figura 25.1 Representação de troca de informações batch entre sistemas
25.1. Identificando o Alvo dos Testes

Se atentarmos ao fato de que estamos testando o Sistema de Vendas, obser-
varemos que determinadas funções são de “responsabilidade” desse sistema
enquanto que outras são “atribuições” do Sistema de Análise de Crédito.
Dessa forma, poderemos reduzir as dependências e riscos de nossos testes
eliminando um fator de esforço e complexidade de nosso trabalho – o pró-
prio Sistema de Análise de Crédito.
Inicialmente, pode parecer estranha essa decisão, mas tenha a certeza de
que estamos escolhendo a solução mais simples e eficiente. Se você tem al-
guma dúvida em relação a isso, então pense em uma outra situação. Imagine
que tal integração não fosse com um sistema de sua organização, mas um sis-
tema de terceiros. Em nenhuma hipótese poderíamos contar com esse siste-
ma em nosso ambiente, pois ele pertence a outra empresa. Para seguir uma
única linha de raciocínio, estabeleceremos que todos os outros sistemas se-
rão eliminados do ambiente de testes.
Seguindo a lógica dessa abordagem, devemos focalizar os testes de
integrações batch somente nas “importações e exportações”, que são de
responsabilidades do sistema em questão, reduzindo o escopo dos tra-
balhos.
A eliminação do Sistema de Análise de Crédito poupará a organiza-
ção de envolver profissionais de outros aplicativos, facilitando o pró-
prio trabalho da equipe responsável pelo Sistema de Vendas. O que ini-
cialmente parecia ser um grande problema, começa a se tornar uma
grande solução.
Ambiente Client-server
Exporta Pedidos
Recém-Cadastrados Pedidos
Digitados
Sistema
de
Vendas
Pedidos
Importa Resultado Analisados
da Análise de Crédito
Figura 25.2 Alvo dos testes identificados
É muito comum encontrarmos sistemas que trocam informações com dezenas

de outros aplicativos e, em cada interação sistema-sistema, podem trocar
diferentes tipos de arquivos, com estruturas e conteúdos totalmente
diferenciados. É claro que o esforço será muito maior nessas situações, porém
poderemos aplicar a mesma abordagem aqui apresentada.
25.2. Testando a Exportação Batch

Um dos requisitos do sistema de vendas é o de enviar lotes de pedidos re-
cém-cadastrados para os sistemas de análise de crédito, com o objetivo de ve-
rificar as condições financeiras dos clientes e autorizar/rejeitar o faturamento.
Esse teste tem por objetivo avaliar se o arquivo-texto gerado durante o
processo de exportação de pedidos recém-cadastrados possui a forma e o
conteúdo adequados aos requisitos funcionais estabelecidos. A validação
desse arquivo deverá ser feita seguindo os seguintes critérios:
Avaliar se todos os pedidos recém-cadastrados estão neste arquivo.

Avaliar se todas as informações do pedido estão corretamente gravadas.
Avaliar se os tamanhos e posições dos campos estão de acordo com
seu layout.
Avaliar se os controles (cabeçalho e rodapé) estão consistentes com os
dados.
Avaliar se o nome do arquivo e o local de geração estão corretos.
A análise do arquivo-texto gerado pode parecer uma tarefa simples, po-

rém envolve uma série de complicações que dificultam tal operação. Mui-
tos sistemas possuem layouts de exportação extremamente complexos,
com muitos campos e variações em seu formato, aumentando os riscos de
problemas no posicionamento, ordem das informações, consistências de
controles, entre outros aspectos. Tudo isso deveria ser levado em conside-
ração no momento de avaliar se o arquivo de exportação foi gerado ade-
quadamente.
Exporta Pedidos
Recém-cadastrados
Sistema
de Pedidos
Vendas Digitados
Figura 25.3 Testes de exportação de arquivos
25.2.1. Conferência da Exportação de Arquivos

Poderíamos aplicar algumas técnicas diferentes para conferir se o arqui-
vo-texto está em conformidade com as especificações. São elas: a conferên-
cia manual, simulação de importação e comparação de arquivos.
Conferência Manual de Arquivos

Na técnica de conferência manual, os procedimentos seriam realizados
através de interação humana, na qual seria avaliado cada layout existente no
arquivo, a contagem de caracteres, a verificação de alinhamento e conteúdo
das informações. O problema dessa técnica está no fato de ser morosa, alta-
mente sujeita a erros, além de ser operacionalizada manualmente sempre
que ocorrer alguma mudança no processo.
Conferência por Simulação de Importação

Nessa abordagem, empregamos o simulador de importação, um compo-
nente de testes que será desenvolvido pela própria equipe de testes com a
finalidade de analisar a estrutura de layout do arquivo e atestar sua “con-
formidade” com as especificações. O grande problema dessa abordagem é
o fato de somente a estrutura do arquivo ser analisada, não contemplando a

análise do conteúdo das informações (se todos os pedidos cadastrados fo-
ram adequadamente gerados, por exemplo). Apesar de ser simples de im-
plementar e permitir a automação dos testes, essa técnica deixaria escapar
defeitos que podem provocar grandes erros no ambiente de produção
(como, por exemplo, deixar pedidos sem sofrer faturamento), o que é um
grande risco para se correr.
Conferência por Comparação de Arquivos

A técnica de conferência por comparação de arquivos é extremamente efi-
ciente e fácil de se implementar. A idéia consiste na comparação de dois ar-
quivos: o primeiro gerado pelo sistema durante o processo de exportação e o
segundo um arquivo “pré-validado” pelos profissionais envolvidos no pro-
cesso de teste. Esses dois arquivos deverão ser idênticos em relação a sua es-
trutura e conteúdo das informações. Os arquivos pré-validados são chama-
dos aqui de arquivos de referência e são incorporados ao baseline do siste-
ma. O planejamento desses arquivos parte do princípio de que em um ambiente
de testes tudo é controlado, ou seja, nada ocorre ao acaso, possibilitando
planejar cada arquivo que será gerado pelo sistema. Se algo der errado, os la-
youts não serão idênticos e, então, um erro será diagnosticado.
Exporta Pedidos Arquivo de Arquivo de

Sistema Recém-cadastrados Exportação Referência
Comparação
de
Vendas Pedidos Pedidos
Digitados Digitados
Figura 25.4 Conferência através da comparação de arquivos
25.2.2. Detalhando os Cenários para Exportação

Se nosso desejo é testar as exportações desse sistema, é muito importante de-
finir todos os outros requisitos comportamentais dessa funcionalidade:
No término da exportação dos pedidos, todos os pedidos na situação
Digitados deverão estar com a situação Em Análise. Deverá ser criado
um arquivo-texto de nome e local estabelecidos na parametrização do
sistema. Ao final do processo será apresentada a mensagem Exporta-
ção de pedidos digitados realizada com sucesso!.
A geração do arquivo somente ocorre quando existem pedidos digita-

dos; caso contrário, a mensagem Não existem pedidos a serem enviados
será apresentada ao usuário.
Quando solicitada uma exportação, todos os pedidos digitados serão
armazenados em um arquivo-texto de layout preestabelecido. Se o ar-
quivo de exportação anterior ainda estiver presente (não processado),
as novas informações serão inseridas (acumuladas) nesse mesmo ar-
quivo, sem prejuízo das informações anteriores
Identificando os Cenários de Testes

Conhecendo todos os requisitos funcionais relativos à exportação dos pedi-
dos, podemos ampliar todos os cenários de testes que poderemos empregar.
Neste diagrama, já representamos a decisão de empregar a técnica de com-
paração de arquivos para avaliar a funcionalidade da exportação dos pedidos
recém-cadastrados.
Executar a exportação
sem que existam Nenhum
pedidos digitados Arquivo
Cenários Possíveis: 1 Criado
Exporta Pedidos
Recém-cadastrados Executar a exportação
com pedidos Arquivo de
digitados Exportação
2 Arquivo de
Executar a exportação Pedidos Referência
Comparação
Sistema sem pedidos Digitados
de digitados, com arquivo-
Vendas texto gerado e ainda Arquivo de
Ref-01.txt
Comparação
não processado Exportação
3
Executar a exportação Pedidos
com pedidos Digitados
digitados, com arquivo- Arquivo de
texto gerado e ainda Arquivo de Referência
não processado Exportação Comparação
4
Pedidos Ref-02.txt
Acumulados
Figura 25.5 Cenários de exportação e respectivos arquivos de referência
Uma das formas de se conferir automaticamente a qualidade do arquivo-texto

gerado é através de um processo de comparação de arquivos. Durante o
planejamento dos testes, serão especificadas o volume e as características dos
pedidos que deverão ser lançados durante a execução dos testes. Dessa forma, é
possível prever qual será o resultado esperado após o processamento da
exportação. Como já sabemos o resultado, esse arquivo é montado
“artificialmente” e será parte integrante da massa de testes.
Estabelecendo os Procedimentos de Testes

Abaixo estão detalhados todos os procedimentos de testes individualizados
para cada cenário existente. Os cenários podem ser uma ótima maneira de se
medir a complexidade dos testes. Quanto mais cenários existentes, maiores
serão as situações a serem simuladas, maior será o esforço de planejamento,
automação e execução dos testes.
Processo: Exportação de Pedidos Recém-cadastrados
Cenário #1
Executar a exportação sem que existam pedidos digitados
Pré-requisitos G Garantir que não existam pedidos digitados.

G Garantir que existam outros pedidos.
G Garantir que não exista arquivo-texto de exportação.
Ações G Executar exportação de pedidos.
Conferências G Mensagem Não existem pedidos a serem enviados.

G Confirmar que o arquivo-texto não foi gerado.
G Confirmar que a situação de outros pedidos não foi
modificada.
Cenário #2
Executar a exportação com pedidos digitados

G Garantir que não exista arquivo-texto de exportação.
Ações G Executar cadastramento de pedidos.

G Executar exportação de pedidos.
Conferências G Mensagem Exportação de pedidos digitados realizada com

sucesso!.
G Confirmar que o arquivo-texto foi gerado.
G Comparar arquivo gerado com arquivo referência
Ref-01.txt.
G Confirmar que pedidos digitados estão com situação Em
Análise.
G Confirmar que outros pedidos não tiveram suas situações
modificadas.
Processo: Exportação de Pedidos Recém-cadastrados
Cenário #3
Executar a exportação sem pedidos digitados,

com arquivo-texto gerado e ainda não processado

G Garantir que exista arquivo-texto de exportação
anterior.
Ações G Executar exportação de pedidos.
Conferências G Mensagem Não existem pedidos a serem enviados.

G Confirmar que o arquivo-texto de exportação não foi
alterado.
Ref-01.txt.
G Confirmar que situação de outros pedidos não foi
modificada.
Cenário #4
Executar a exportação com pedidos digitados,

com arquivo-texto gerado e ainda não processado

G Garantir que exista arquivo-texto de exportação.
Ações G Executar cadastramento de pedidos.

G Executar exportação de pedidos.
Conferências G Mensagem Exportação de pedidos digitados realizada com

sucesso!.
G Confirmar que os novos pedidos foram inseridos no
arquivo de exportação.
Ref-02.txt.
G Confirmar que pedidos digitados estão com situação
Em Análise.
G Confirmar que outros pedidos não tiveram suas situações
modificadas.
25.3. Testando as Importações Batch

Após a operação de envio “em lotes” de pedidos recém-cadastrados ao siste-
ma de Análise de Crédito, este retornará um arquivo que conterá todo o re-
sultado dessa análise, liberando ou não determinados pedidos para o fatura-
mento, portanto, devemos analisar todas as possibilidades de retorno dos
pedidos e, dessa forma, testar os cenários envolvidos no processo de impor-
tação batch.
Nosso objetivo é testar o processo de importação dessas informações, de
forma a avaliar se o software tratou adequadamente os dados contidos nesse
arquivo, realizando as atualizações necessárias. A validação dessa funciona-
lidade deverá ser feita seguindo os seguintes critérios:
Avaliar se todos os pedidos enviados foram corretamente atualizados.

Avaliar se existem pedidos com dois ou mais dias aguardando avaliação.
Avaliar se o risco de reprocessamento de um arquivo está descartado.
Avaliar se erros no layout são corretamente tratados pelo processo.
Por existirem várias interações entre sistemas, é comum que as pessoas

acreditem (principalmente clientes e usuários) que somente com uma troca
de informações “reais” entre os aplicativos poderemos garantir o processa-
mento adequado dessas operações.
Essa premissa é extremamente perigosa. Devemos levar em considera-
ção que os outros sistemas também possuem suas dependências de outros
aplicativos e demandariam suas próprias necessidades. Parece um cenário
difícil de se gerenciar e de altos riscos. Como os sistemas são cada vez mais
“integrados”, sempre devemos encontrar uma alternativa que possibilite a
realização dos testes sem criar um ambiente complexo demais para adminis-
trá-lo. Acredito que precisamos começar a “pensar diferente” e planejar com
mais realismo nossos processos de testes.
Importa Resultado Arquivo

Sistema da Análise de Crédito Simulado
de
Vendas Pedidos
Analisados
Figura 25.6 Testes para importação de arquivos

Uma das vantagens de não envolvermos outros sistemas é que podemos

simular todas as suas interfaces externas, criando “artificialmente” arquivos
que simulem a troca de informações entre aplicativos. Dessa forma, podere-
mos submeter o processo de importação a um número acentuado de cená-
rios possíveis, deixando nossos testes mais amplos e, conseqüentemente,
mais completos.
25.3.1. Simulando Integrações Batch

Para podermos testar os cenários envolvidos em uma importação de arqui-
vos, devemos ter nosso elemento mais básico: os arquivos de integração. Po-
rém, com a ausência do Sistema de Análise de Crédito, esstes arquivos não
serão mais criados da forma convencional, portanto, precisaremos encon-
trar uma nova fonte para “construirmos” esses arquivos.
Podemos aplicar duas abordagens diferentes para obtermos a relação de
arquivos de importação que necessitamos durante os testes. São elas: massa
de produção ou massa simulada.
Massa de Produção
Essa abordagem caracteriza-se pela utilização de “arquivos reais” do am-
biente de produção e sua reutilização nos procedimentos de testes. Todos
os dias, muitos arquivos batch são criados durante o processamento nor-
mal e essa abordagem pode ser empregada para alimentar o ambiente de
testes. Esta pode parecer “mágica”, porém possui muitas restrições e res-
salvas.
As ressalvas ficam por conta do fato de não existir um controle efetivo
sobre o tipo de informações que está sendo enviado ao ambiente de tes-
tes, ou seja, não existe garantia de que todos os cenários estão sendo pro-
cessados. Isso impossibilita a realização da conferência dos resultados de
forma automatizada, reduzindo a velocidade e a eficiência da execução
dos testes. Também temos um problema adicional com o grande volume
de dados de produção, obrigando a realização de procedimentos de redu-
ção das informações.
As restrições estão no impedimento de realizar testes com layouts erra-
dos, como desalinhamento de campos, troca de ordem das informações e al-
gumas inconsistências de controles. Isso impossibilita avaliar como o siste-
ma se comporta nas situações de exceção.
Massa Simulada
Essa abordagem baseia-se na construção “sob medida” de arquivos que em-
pregam informações cuidadosamente planejadas, de forma a criar “artifici-
almente” os diversos cenários desejados. Apesar de um maior esforço de pla-
nejamento e criação desses arquivos, essa abordagem proporciona maior
flexibilidade na realização dos testes. Será possível criar arquivos sem conte-
údos, com falhas de layout, com pedidos que nunca existiram ou que já fo-
ram processados. Enfim, podemos manipular e gerar todos os cenários ne-
cessários para os testes.
A utilização de uma massa simulada significa que temos o controle total
das informações que estarão contidas nos arquivos. Significa que podere-
mos não somente automatizar o processo de importação dos dados, mas
também os procedimentos de conferência (devemos analisar se os pedidos
tiveram suas situações convenientemente alteradas após a importação). Isso
faz com que essa abordagem seja a melhor escolha a ser tomada durante os
testes de importação de arquivos.
25.3.2. Detalhando os Cenários para Importação

Se nosso desejo é testar as importações desse sistema, é muito importante
definir todos os outros requisitos comportamentais dessa funcionalidade:
Durante a realização das importações, todos os pedidos presentes no

arquivo deverão ter suas situações modificadas em relação às respos-
tas obtidas pela análise de crédito. Para os créditos recusados, deverão
ser atualizados os motivos da recusa. No final do processamento será
apresentada a mensagem Importação da Análise de Crédito realizada
com sucesso.
Durante a realização da importação, caso existam alguns itens que não
puderam ser lidos ou por erro de posicionamento dos campos ou por
outro motivo qualquer, estes deverão ser apresentados. A mensagem
Alguns erros ocorreram durante o processamento! deverá ser apresenta-
da. Também deverá ser criado um log de erros com todos os itens não
processados. Esse log deverá ser apresentado no final do processa-
mento com problemas.
O processo de importação somente ocorrerá se existir o arquivo fisica-
mente disponível. Caso contrário, a mensagem Não foi encontrado o
arquivo de Análise de Crédito será apresentada ao usuário.
Caso tentemos reprocessar um determinado arquivo, o sistema deverá

apresentar a mensagem Este arquivo já foi anteriormente processado! e
finalizará a operação.
Após o processamento de uma importação, caso existam pedidos
que estejam com dois dias em análise de crédito, estes deverão ser
apresentados ao usuário no final do processamento. Deverá ser
mostrada a mensagem Alguns pedidos estão em análise há dois dias ou
mais! ao usuário. Essa lista deverá ser enviada, por e-mail, ao Ge-
rente de Vendas e Gerente de Crédito e Cobrança.
Conhecendo todos os requisitos funcionais relativos à importação da

análise de crédito, podemos ampliar todos os cenários de testes a empregar.
Neste diagrama, já representamos os arquivos de simulação que serão utili-
zados para testar as funcionalidades das importações.
Executar a importação sem a

existência do arquivo
Cenários Possíveis: 1
Importa Resultado
da Análise de Crédito Executar a importação com o
arquivo disponível
2 Arquivo
Executar a importação com o Simulado
arquivo já processado
3 Simula-01.txt
Sistema
de Executar a importação de
Vendas pedidos com dois dias em Arquivo
pendência de análise de crédito Simulado
4
Simula-02.txt
Executar a importação com Arquivo

problemas em alguns itens Simulado
5
Simula-03.txt
Figura 25.7 Cenários de importação e respectivos arquivos de simulação
25.3.3. Estabelecendo os Procedimentos de Testes

Adiante estão detalhados todos os procedimentos de testes individualizados
para cada cenário existente. Os cenários podem ser uma ótima maneira de se
medir a complexidade dos testes. Quanto mais cenários existentes, maiores
serão as situações a serem simuladas e maior será o esforço de planejamento,
automação e execução dos testes.
Processo: Importa Resultado da Análise de Crédito
Cenário #1
Executar a importação sem a existência do arquivo
Pré-requisitos G Garantir que não exista arquivo-texto de importação.
Ações G Executar importação da análise de crédito.
Conferências G Mensagem Não foi encontrado o arquivo de Análise de

Crédito.
Cenário #2
Executar a importação com o arquivo disponível
Pré-requisitos G Garantir que existam pedidos que aguardam análise de

crédito.
G Garantir que exista arquivo de simulação
Simula-01.TXT.
Conferências G Mensagem Importação da Análise de Crédito realizada

com sucesso.
G Confirmar se o arquivo foi excluído.
G Confirmar se as situações dos pedidos foram alteradas
corretamente.
G Confirmar os motivos para os pedidos com recusa de
crédito.
Cenário #3
Executar a importação com arquivo já processado
Pré-requisitos G Garantir que exista arquivo de simulação

Simula-01.TXT.
G Garantir que o arquivo Simula-01.TXT já tenha sido
processado.
Conferências G Mensagem Este arquivo já foi anteriormente

processado!.
G Confirmar se a operação foi cancelada.
Processo: Importa Resultado da Análise de Crédito
Cenário #4
Executar a importação de pedidos com dois dias em pendência

de análise de crédito
Pré-requisitos G Garantir que existam pedidos aguardando análise de crédito

há dois dias.
G Garantir que exista arquivo de simulação Simula-02.TXT.
Conferências G Mensagem Alguns pedidos estão em análise há dois dias

ou mais!.
G Confirmar exibição da lista de pedidos com dois dias em
análise ao usuário.
G Confirmar e-mail para o Gerente de Vendas e de Crédito e
Cobrança.
G Confirmar se e-mail possui lista de todos pedidos com dois
dias em análise.
Cenário #5
Executar a importação da análise de crédito com problemas em alguns itens
Pré-requisitos G Garantir que existam pedidos que aguardam análise de

crédito.
G Garantir que exista arquivo de simulação Simula-03.TXT.
Conferências G Mensagem Alguns erros ocorreram durante o

processamento!.
G Confirmar a existência do log de erros.
G Verificar se log de erros foi apresentado ao final do
processo.
G Confirmar se todos itens “ruins” estão no log de erros.
G Confirmar se itens “bons” foram corretamente atualizados.
CAPÍTULO 26
Simulando
Softwares
Muitos sistemas realizam processamentos que envolvem funcionali-

dades existentes em outros aplicativos. A execução de todas as funcionalida-
des de um determinado sistema está diretamente condicionada à presença
física de outros aplicativos que serão acionados durante a execução de deter-
minados eventos.
Em ambas as situações, as operações do sistema dependem diretamente
do processamento dessas funcionalidades externas, criando um obstáculo
adicional na realização de testes. Para percorrermos todos os cenários possí-
veis e testar todos os requisitos do software, seremos obrigados a disponibi-
lizar todos os sistemas que suportem essas funcionalidades.
Imaginemos que nossa solução é um sistema de Vendas que necessita
submeter todos os pedidos lançados a uma análise de crédito corporativa.
Essa análise será feita por um outro sistema, denominado GESTÃO DE
CRÉDITO, que terá como objetivo reduzir os riscos financeiros com maus
pagadores.
A análise do pedido será realizada através de uma transação on-line re-
quisitada ao sistema Gestão de Crédito que executa a monitoração de todo o
histórico comercial do cliente, além de obter uma posição real da situação fi-
nanceira do cliente em todo o mercado nacional, fornecido por uma empre-
sa especializada em análises financeiras de pessoas jurídicas. Enquanto essa
análise não é finalizada, o pedido continua aguardando o resultado da análi-
se de crédito.
Simulando Softwares
Pedido
Digitado
<< Software >> Pedido << Software >>

Sistema de Analisado Sistema de
Vendas Gestão de Crédito
Figura 26.1 Representação em UML de uma troca de informações entre sistemas
Tabela 26.1
Critérios para análise de crédito do pedido
Resultado Critério
G Restrição G Cliente está em processo de falência.

Automática G Cliente está ou esteve em concordata nos últimos dois
anos.
G Cliente tem restrições no mercado financeiro.
G Análise Individual G Cliente possui duplicatas não pagas.
G Volume negociado está acima de 100% da média de
vendas anteriores.
G Volume acumulado está acima de 100% da média
mensal.
G Primeira compra.
G Aprovação G Passar pelos critérios de restrição automática.
Automática G Passar pelos critérios de análise individual.
26.1. Entendendo o Ciclo de Análise de Crédito

O sistema de gestão de crédito não está dentro do escopo dos testes do siste-
ma de vendas. Porém, ele está inserido no meio do processo de faturamento,
necessitando de sua execução para dar continuidade ao ciclo de vida do pe-
dido. Essa análise do pedido leva em consideração todas as transações finan-
ceiras realizadas pelo cliente e também sua situação em relação ao mercado.
Dependendo da saúde financeira do cliente, seus pedidos serão automa-
ticamente rejeitados, não existindo qualquer forma de liberação posterior.
Outros critérios podem requerer uma intervenção manual, na qual um ana-
lista de crédito avaliará os riscos que envolvem a efetivação desse pedido,
podendo aceitar ou recusar, segundo uma análise criteriosa e individualiza-
da da situação. Se o cliente não se enquadrar em qualquer dessas situações,
Receber
Pedidos Em
Análise
[Reprovação Eletrônica] [Aprovação Eletrônica]

Processar Análise [Análise Manual] Processar Análise
Processar Análise
[Reprovação Manual] [Aprovação Manual]

Crédito Análise Individual Análise Análise Individual Crédito
Recusado Manual Aceito
Enviar Enviar
Pedidos Já Pedidos
Enviado
[90 dias após a análise]

Excluir Pedido
Figura 26.2 Ciclo de análise de crédito no sistema de gestão de crédito
seu pedido será automaticamente liberado. A representação do ciclo de vida

de liberação de crédito de um pedido encontra-se na Figura 26.2:
Envolver esse sistema somente aumenta a complexidade dos testes a se-
rem realizados no sistema de vendas, pois envolve a interação com outro sis-
tema que nada tem a ver com nosso escopo de testes. A solução é criar um
mecanismo que crie artificialmente respostas e simule todos os possíveis
comportamentos desse sistema.
26.2. Entendendo o Ciclo de Vida do Pedido

A dependência de processamento entre dois sistemas adiciona uma comple-
xidade que em nada contribui para as atividades de testes. Quando deseja-
mos realizar testes funcionais, as dependências dificultam a criação de cená-
rios, pois exigem uma difícil preparação do sistema que realizará os proces-
samentos externos, além de ser necessária a manipulação direta com esse
aplicativo.
Diante desse cenário, percebemos como seria mais complexo envolver o
sistema de gestão de crédito durante a realização dos testes do sistema de
Simulando Softwares
Vendas. Para que todos os casos de testes fossem executados, seria necessá-
rio um planejamento mais complexo a fim de que todas as possíveis varia-
ções de resultados pudessem ser operacionalizadas. A utilização de um si-
mulador reduziria o esforço de planejamento e execução dos casos de testes,
tornando mais simples os processamentos que envolvem diretamente a aná-
lise dos pedidos. Também evitaria a instalação e gerenciamento de mais um
sistema no ambiente de testes.
Criar
Pedidos Pedido
Digitado A transação de análise é
uma requisição direta ao
Enviar sistema de
para Análise gestão de crédito.
Pedido
em Análise
[Crédito Reprovado] [Crédito Aprovado]

Reprovar Pedido Aprovar Pedido
Pedido Pedido Pedido

Rejeitado Aprovado Faturado
[30 dias após a reprovação] [90 dias após o faturamento]

Excluir Pedido Excluir Pedido
Figura 26.3 Definição do ciclo de vida do pedido no sistema de vendas
26.3. Criando os Cenários de Testes

Como nosso objetivo é apenas validar o sistema de vendas, devemos nos
concentrar apenas nas funcionalidades que farão diferença para esse aplica-
tivo, descartando alguns cenários de testes que não são representativos para
validar esse software. No caso específico da análise de crédito, não necessita-
mos de todos os cenários que normalmente aplicaríamos se fôssemos validar
os procedimentos de análise de crédito.
Devemos nos concentrar apenas nos cenários de negócios relevantes ao
sistema de vendas, não sendo necessário validar todas as situações que de-
vem ocorrem “dentro” do sistema de gestão de crédito. Portanto, iremos res-
tringir situações de análise de pedido em apenas quatro cenários: um pedido
que é rejeitado automaticamente, outro pedido que é aprovado automatica-

mente e mais dois pedidos que são submetidos a uma avaliação individual,
sendo que um deles é posteriormente rejeitado e o outro aprovado. Dessa
forma, minimizamos o esforço de teste e garantimos todos os cenários possí-
veis de ocorrer dentro do escopo de testes do sistema de vendas.
Tabela 26.2
Cenários necessários para validar análise de crédito
Cenários de Testes Análise Pedido Pedido

Individual Rejeitado Liberado
Cliente está em processo de falência. X

Cliente está ou esteve em concordata nos X
últimos dois anos.
Cliente tem restrições no mercado financeiro. X
Cliente possui duplicatas não pagas. X X
X X
Volume negociado está acima de 100% da X X
média de vendas anteriores. X X
Volume acumulado está acima de 100% da X X
média mensal. X X
Primeira compra. X X
X X
Liberação automática. X
Tabela 26.3
Cenários necessários para validar o sistema de vendas
Cenários de Testes Análise Pedido Pedido

Individual Rejeitado Liberado
Pedido é rejeitado automaticamente. X

Pedido sofre avaliação individual e posterior X X
rejeição.
Pedido sofre avaliação individual e posterior X X
aprovação.
Pedido é aprovado automaticamente X
Simulando Softwares
26.4. Construindo um Simulador de Software

Uma vez tomada a decisão de criar um simulador para substituir o sistema
de gestão de crédito, devemos planejar como será definida a estrutura desse
simulador. Aqui devemos tomar cuidado de não criar um simulador que so-
mente atenda às necessidades dos testes do sistema de vendas. É muito co-
mum que uma aplicação seja utilizada por vários outros sistemas, exigindo a
mesma estratégia de criação de um simulador para atender a seus respecti-
vos cenários de testes, portanto, o simulador deve ser uma solução corpora-
tiva e nunca individual, devendo contemplar todos os cenários envolvidos
no sistema de crédito.
Restrições de Crédito
Restrição Automática:
l Cliente está em processo de falência.
<< Simulador >> l Cliente está ou esteve em concordata nos últimos dois anos.
l Cliente tem restrições no mercado financeiro.
GESTÃO DE
Análise Individual:
CRÉDITO l Cliente possui duplicatas não pagas.
l Volume negociado está acima de 100% da média de vendas anteriores.
l Volume acumulado está acima de 100% da média mensal.
l Primeira compra.
Figura 26.4 Lista de restrições de crédito que serão contempladas no simulador
Utilizando um diagrama de classes em notação UML, podemos repre-

sentar a complexidade do simulador a ser criado: o Simulador Gestão de
Crédito. Este realizará todas as operações que o sistema original desempe-
nha, não necessitando da realização de qualquer adaptação de interface no
sistema que iremos testar. Isso garante a compatibilidade entre o simulador
e o aplicativo original que, eventualmente, poderá ser substituído para reali-
zar outras categorias de testes.
<< Classe >>

Simulador
<< Simulador >>
– Valor Pedido: Currency
GESTÃO DE
CRÉDITO
+ Analisar (prmPedido: Long) : Boolean
– LerValor (prmPedido: Long) : Currency
– GravaResultado (prmResultado: Boolean, prm Motivo: Long)
Figura 26.5 Classe que contempla as operações do simulador

Podemos nos questionar em relação a quem, eventualmente, deveria ser

o responsável por construir o simulador de determinado sistema. Em uma
situação como essa, na qual os softwares vendas e gestão de crédito já estão
construídos, estamos lidando com sistemas legados, nos quais determinadas
atividades não foram realizadas (rastreabilidade de requisitos, especificação
funcional e não funcional, modelo de negócios), o que dificulta, porém não
impede, a realização dos trabalhos de testes. Dessa forma, a criação do simu-
lador passa a ser tarefa daquele que necessita de sua criação – no caso, a pró-
pria equipe de projeto do sistema de vendas.
Em uma condição ideal, a responsabilidade de criação e manutenção do
simulador deve ser da equipe que desenvolveu o próprio sistema que está
sendo acionado – no caso, o sistema de gestão de crédito. E esta que conhece
as interfaces e poderá canalizar todas as necessidades e materializá-las em
um simulador único e corporativo. No caso de mudanças em relação ao pro-
jeto de software, a equipe estará apta a realizar diretamente as “customiza-
ções” no simulador e providenciar a sua substituição, divulgando o que mu-
dou e os motivos. Assim, um projeto de desenvolvimento de um novo soft-
ware deveria contemplar a criação de seu próprio simulador para que outros
sistemas possam realizar seus testes de forma mais eficiente.
26.5. Parametrização do Simulador de Software

Um simulador deverá parametrizar seu comportamento através de um con-
junto de condições preestabelecidas chamadas de parametrizações do simu-
lador. Trata-se da definição de critérios que estabelecem como será o com-
portamento do simulador sob determinadas situações de estímulo, ou seja,
especificaremos como o simulador deverá reagir para que possamos prever
os resultados e criar os cenários que estamos buscando reproduzir. No caso
do simulador de gestão de crédito, existe apenas uma única função pública
que está sendo empregada pelos diversos sistemas da organização, inclusive
o sistema de vendas.
Nesta tabela, estão sendo demonstradas as parametrizações de compor-
tamento dessa função e como será produzido o resultado esperado. O simu-
lador deverá ser implementado seguindo essas especificações, de forma a ga-
rantir o maior conjunto de cenários simulados possíveis, substituindo o
aplicativo original em sua totalidade.
Simulando Softwares
Tabela 26.4
Parametrizações efetuadas no simulador de gestão de crédito
Serviço Valor Pedido Resultado # Motivo da Restrição
Analisar x <=100 Rejeitado 01 Cliente está em processo de

falência.
100< x <=200 Rejeitado 02 Cliente está ou esteve em

concordata – últimos dois anos.
200< x <=300 Rejeitado 03 Cliente tem restrições no

mercado financeiro.
300< x <=400 Rejeitado 04 Cliente possui duplicatas não

pagas
400< x <=500 Aprovado
500< x <=600 Rejeitado 05 Volume negociado está acima

de 100% da média de vendas
anteriores.
700< x <=800 Rejeitado 06 Volume acumulado está acima

de 100% da média mensal.
900< x <=1000 Rejeitado 07 Primeira compra do cliente.
1000< x <=1100 Aprovado
x >=2000 Aprovado – –
Perceba que a parametrização desse simulador requer direta intervenção

do banco de dados, pois necessita analisar o valor do pedido para que possa
ser estabelecido o resultado da análise de crédito. Esse serviço é executado
pelo LerValor(prmPedido: Long) que tem por objetivo obter o valor do pedi-
do recebido como parâmetro. Com essa informação em mãos, podemos rea-
lizar a rejeição ou liberação do pedido, seguindo a especificação definida.
Será através do serviço GravaResultado(prmResultado: Boolean, prmMotivo:
Long) que o pedido será atualizado conforme o resultado previsto (aprovado
ou rejeitado) sendo enviado o número do motivo descrito na tabela acima.
Ambos os serviços são internos, representados por “–”, para que seja
mantida a compatibilidade com a interface original, que tem apenas uma
única função pública chamada Analisar, que está representada por “+”.
Ler Valor obterá o valor

<< Classe >>
total do pedido para que
Simulador
possa sofrer a avaliação
parametrizada.
– Valor Pedido: Currency
Grava Resultado + Analisar (prmPedido: Long) : Boolean

atualizará o resultado da – LerValor (prmPedido: Long) : Currency
análise diretamente no – GravaResultado (prmResultado: Boolean, prm Motivo: Long)
pedido avaliado.
Figura 26.6 Serviços internos do simulador possibilitam

substituição total do aplicativo
CAPÍTULO 27
Simulando
Hardwares
Um dos maiores obstáculos para a execução de testes automatizados é

quando nos deparamos com sistemas que possuem forte dependência com
dispositivos físicos (hardwares). Isso é muito comum em áreas de automa-
ção bancária, industrial e comercial, nas quais a solução software e hardware
se misturam, dificultando a realização de testes.
O problema com os dispositivos físicos é que eles são pouco flexíveis e
necessitam de interação direta e real. Dessa forma, não é possível realizar si-
mulações com os dispositivos físicos, pois estes são projetados para realizar
uma leitura real do ambiente.
Vamos imaginar que nossa solução é um terminal de auto-atendimento
(ATM). Esses terminais, encontrados aos montes em shoppings e supermer-
cados, são um conjunto de soluções de software e hardware, porém, muitos
testes a serem aplicados no software irão depender diretamente do compor-
tamento do hardware, o que aumentaria as dificuldades dos testes, impedin-
do-os de serem automatizados.
Imaginaremos que nosso objetivo é validar alguns requisitos que um ter-
minal de atendimento (ATM) deveria levar em consideração.
Um ATM deverá desabilitar a operação de saque caso não existam no-

tas físicas disponíveis no Cash Dispenser.
Um ATM somente pode permitir saques de valores múltiplos relativos
às notas disponíveis do Cash Dispenser.
Um ATM somente pode permitir saques que não excedam o volume

disponível no Cash Dispenser.
Um ATM deverá cancelar a operação de saque caso o Cash Dispenser
não tenha sucesso em abrir a gaveta de acesso ao dinheiro.
Um ATM deverá cancelar a operação de saque caso o correntista não te-
nha retirado nenhuma das notas disponibilizadas pelo Cash Dispenser.
Um ATM deverá realizar o saque parcial caso o correntista ter retirado
apenas algumas das notas disponibilizadas pelo Cash Dispenser.
<< Software >> << Hardware >>

ATM Impressora
Comunicação
Tem Papel = Sim
Operacional = Sim
Deseja sacar
qual quantia?
<< Hardware >>

Comunicação Cash Dispenser
XXXXXXX
Nota 10 = 5.000 Unidades
Nota 50 = 2.500 Unidades
Figura 27.1 Solução ATM com o dispositivo físico Cash Dispenser
Percebemos que todos os requisitos levantados possuem uma estreita li-

gação com o dispositivo físico Cash Dispenser que foi propositalmente repeti-
do para realçar essa dependência. Com esses poucos requisitos, podemos já
antecipar qual seria a dificuldade de realizar esses testes com a presença física
do hardware. Teríamos que colocar e tirar as notas “fisicamente” do Cash Dis-
penser para habilitar ou desabilitar a operação de saque; trocar “fisicamente” o
conjunto de notas para simularmos aceitar ou rejeitar saques com valores
múltiplos; “fisicamente” impedir que a gaveta do Cash Dispenser se abra du-
rante a operação de saque, para simular uma falha no acesso às notas e retirar
parcialmente as notas disponibilizadas, simulando um saque parcial.
Ao persistir em conduzir os testes interagindo software com hardware,
teremos um esforço muito grande em executar todos os procedimentos de
testes e uma total inviabilidade em sua automação. Nesse caso, o simulador
seria uma grande alternativa, uma vez que eliminaria as interações com o
Cash Dispenser.
Simulando Hardwares
<< Software >>

<< Software >> Comunicação
ATM
Impressora
Deseja sacar Virtual
qual quantia?
<< Software >>
Comunicação
Cash Dispenser
XXXXXXX
Virtual
Figura 27.2 Solução ATM com o Cash Dispenser Virtual
Devemos lembrar que os testes unitários devem ser executados antes dos
testes integrados. Dessa forma, precisamos avaliar se o software ATM está
interagindo adequadamente com todos os cenários possíveis, inclusive se
está tratando todas as possíveis respostas geradas pelo dispositivo físico
Cash Dispenser. Nos testes do desenvolvimento (unitário e integrado), esses
hardwares são substituídos por simuladores para aumentar o nível de efi-
ciência da automação dos testes a serem executados.
Testes do Desenvolvimento
ATM Cash Dispenser Impressora
<< Software >> Testados pelo

Fornecedor
ATM
<< Hardware >> << Hardware >>

Cash Dispenser Impressora
Virtual Virtual Cash Dispenser Impressora
Figura 27.3 Visão do teste de desenvolvimento da solução ATM
27.1. Construindo um Simulador de Hardware

Uma vez tomada a decisão de criar um simulador de hardware, torna-se ne-
cessário planejar a estrutura desse simulador. Essa estrutura será baseada no
modelo de interface do hardware a ser simulado, ou seja, todas as operações
suportadas pelo hardware e que serão empregadas durante os testes deverão
ser reproduzidas no simulador. Analisando o Cash Dispenser, podemos idea-
lizar a seguinte interface:
O que faz o Cash-Dispenser?
Cash • Informa se existem notas no Cash Dispenser.

Dispenser • Informa se dado valor é múltiplo das notas existentes no Cash Dispenser.
Virtual • Informa se dado valor é muito maior do que o montante existente no Cash Dispenser.
• Informa se a porta do Cash Dispenser foi aberta.
• Informa o montante em dinheiro retirado pelo usuário após a abertura da gaveta.
Figura 27.4 Especificando o simulador Cash Dispenser
Utilizando um diagrama de classes em notação UML, podemos represen-

tar a complexidade do componente de teste a ser criado: o Cash Dispenser
Virtual. Esse simulador realizará todas as operações do dispositivo “real” e
enviará as respostas de acordo com a parametrização estabelecida em cada
“serviço disponibilizado”.
<< Classe >>

Simulador
+ existem notas: Boolean

Cash
Dispenser + AbrirGaveta(prmValor: Currency):Boolean
Virtual + FecharGaveta():Boolean
+ IsMutiplo(prmValor: Currency):Boolean
+ ExistemNotas():Boolean
+ IsSuficiente(prmValor: Currency):Boolean
Figura 27.5 Classe que suportará as operações do simulador
27.2. Parametrização do Simulador

As regras a serem adotadas para definir o comportamento do simulador são
chamadas de parametrizações do simulador. Essas parametrizações defini-
rão um critério de comportamento, tornando previsíveis as respostas do si-
mulador. Conhecendo esses critérios, poderemos modelar as massas de tes-
tes, de forma a produzir os cenários que desejamos.
Uma vez conhecida a interface que será adotada pelo simulador, torna-se
necessário estabelecer os critérios de parametrização para cada serviço dis-
ponível pela unidade “real”. O número de critérios possíveis está diretamen-
te relacionado ao número de cenários que desejamos reproduzir.
Simulando Hardwares
AbrirGaveta() FecharGaveta()
<< Software >>
ATM
ExistemNotas()
Deseja sacar
qual quantia? << Software >>
IsMultiplo()
Cash Dispenser
XXXXXXX IsSuficiente() Virtual
Figura 27.6 Representação da interface do Cash Dispenser Virtual
27.2.1. Definindo os Parâmetros do Simulador

Por exemplo, o serviço IsMultiplo( ) deve avaliar se determinado valor é múl-
tiplo das notas existentes no Cash Dispenser. Em uma situação real, o dispo-
sitivo físico verificaria se o valor informado é múltiplo das notas existentes,
ou seja, se quero sacar R$115,00 e somente existem notas de R$10,00 e
R$50,00, será impossível disponibilizar a quantia.
Em uma situação simulada, essa “dependência” com as notas “físicas”
deixa de existir. Isso porque nosso objetivo é testar se o comportamento do
software ATM nos diversos cenários existentes, portanto, basta estabele-
cermos uma regra para que o simulador entenda quando um valor é múlti-
plo ou não.
Neste exemplo, estaremos definindo que o simulador entenderá que os
valores pares serão considerados múltiplos, enquanto que os valores ímpa-
res serão considerados não múltiplos. Se desejarmos avaliar como o softwa-
re está tratando as situações de valores não múltiplos, basta executarmos sa-
ques com valores ímpares. Assim, o software ATM, ao acionar o serviço
IsMultiplo( ), terá como resposta um valor negativo e deverá se comportar
de forma diferente de uma resposta positiva, recusando o valor digitado e re-
quisitando um novo valor.
Na tabela a seguir estão sendo demonstradas as parametrizações de
comportamento do simulador. O simulador deverá respeitar esses requi-
sitos e retornar com os valores aqui definidos, de forma a possibilitar a
previsão dos resultados e, conseqüentemente, validar os comportamen-
tos do software.
Tabela 27.1
Parametrizações efetuadas no Cash Dispenser Virtual
Serviço Cenário Valor Retorno
ExistemNotas Tem notas existem_notas = Sim Sim
Não tem notas existem_notas = Não Não
IsMultiplo É múltiplo = Impar Sim
Não é múltiplo = Par Não
IsSuficiente É suficiente <= 500,00 Sim
Não é suficiente > 500,00 Não
AbrirGaveta Abriu normalmente <= 300,00 Sim
Não abriu > 300,00 Não
FecharGaveta Fechou sem dinheiro < 200,00 0
Fechou com dinheiro parcial > 200,00 Valor – 100
Fechou com todo dinheiro = 200,00 Valor
27.2.2. Exemplo de um Simulador de Hardware

Seguindo os critérios acima estabelecidos, demonstramos uma possível co-
dificação para o Cash Dispenser Virtual:
Option Explicit
‘ Propriedades do Simulador
Public existem_notas As Boolean
‘ Métodos do Simulador
Public Function ExistemNotas( ) As Boolean
ExistemNotas = existem_notas
End Function
Public Function IsMultiplo(prmValor As Currency) As Boolean

IsMultiplo = ((prmValor / 2) = (prmValor \ 2))
End Function
Public Function IsSuficente(prmValor As Currency) As Boolean

IsSuficente = (prmValor <= 500)
End Function
Simulando Hardwares
Public Function AbrirGaveta(prmValor As Currency) As Boolean

AbrirGaveta = (prmValor <= 300)
End Function
Public Function FecharGaveta(prmValor As Currency) As Currency

If prmValor = 200 Then
FecharGaveta = prmValor
ElseIf prmValor < 200 Then
FecharGaveta = 0
Else
FecharGaveta = prmValor – 100
End If
End Function
27.3. Testando o Simulador

Apesar de os simuladores serem apenas instrumentos para agilizar os testes,
deixando-os mais flexíveis e mais automatizados, estes necessitam ser testa-
dos sempre que seu código-fonte for alterado. As alterações a serem realiza-
das nos simuladores podem ser tanto para adequá-los a eventuais mudanças
em suas parametrizações, quanto para adequá-los a mudanças de interfaces
ocorridas na unidade real.
Para a realização dos testes de simuladores procederemos da mesma for-
ma como executamos os testes com unidades de software – construiremos
um controlador de testes.
Alimenta Log de
Dados de AbrirGaveta() FecharGaveta()
Execução
Entrada
<< Software >> ExistemNotas()
<< Software >>

Controlador Executa
IsMultiplo()
Cash Dispenser Cash Dispenser
Virtual IsSuficiente() Virtual
Dados de Compara
Saída
Figura 27.7 Testando o Cash Dispenser Virtual

Devemos ser muito cautelosos com os simuladores, pois estes podem

prejudicar a execução dos testes. Assim, não é exagero a construção de um
controlador de testes para os simuladores, uma vez que necessitamos garan-
tir, de forma rápida e segura, que os requisitos de comportamento do simu-
lador estão sendo corretamente seguidos.
CAPÍTULO 28
Criando um
Controlador de Testes
Imaginemos uma pequena função que calcula um prêmio adicional

para os empregados. Essa função foi construída atendendo aos seguintes re-
quisitos de negócios:
Todo bônus é calculado sobre o salário bruto.

Empregados com 50 anos ou mais terão direito a 5% de bônus.
Empregados noturnos terão 10% sobre o salário.
Para melhor ilustrar, segue abaixo o código de implementação dessa

função:
Public Function ObtemPremioAdicional

(prmSalario As Double, prmIdade As Integer, prmTrabalhoNoturno As Boolean)
As Double
Dim vlPercentual As Integer
VlPercentual = 0
‘ Prêmio de 5 % sobre o salário

If prmIdade >= 50 Then
vlPercentual = vlPercentual + 5
End If
‘ Prêmio de 10 % sobre o salário

If prmTrabalhoNoturno Then
vlPercentual = vlPercentual + 10
End If
ObtemPremioAdicional = (prmSalario * vlPercentual / 100)
End Function
28.1. Definindo a Massa de Testes

Observando a lista de requisitos ou mesmo o código-fonte associado, é pos-
sível determinar o volume de cenários possíveis para a situação apresentada.
Cada cenário será testado de forma a avaliar a conformidade do código-fonte
com os requisitos definidos. Para cada cenário identificado é necessário es-
tabelecer um conjunto de valores de entrada e um outro conjunto de dados
de saída.
Entradas Processamento Saídas
Casos Casos
deCasos Unidade deCasos
Testede Casos a ser Testede Casos
Teste de Testada Teste de
Teste Teste
Figura 28.1 Criando uma massa de testes para aplicar no controlador
28.1.1. Definindo a Entrada de Dados

Os dados de entrada são modelados de forma a atender o cenário a ser testa-
do. Por exemplo, se nosso objetivo é criar um cenário referente à Ganhar a
bonificação referente à idade devemos definir que a idade do profissional seja
de 55 anos ou mais e que este trabalhe durante o dia, de forma a não ter direi-
to à bonificação pelo período noturno. Portanto, os dados de entrada de cada
cenário deverão ser estudados conjuntamente, de forma a garantir o resulta-
do desejado.
Criando um Controlador de Testes
Sem Bonificação
Salário = R$1.000,00
Idade = 35 anos
Noturno = Não
Bonificação Idade
Idade = 55 anos
Noturno = Não Unidade
a Ser
Bonificação Noturno Testada Saídas
Idade = 35 anos
Noturno = Sim
Bonificação por idade +

Trabalho Noturno
Idade = 55 anos
Noturno = Sim
Figura 28.2 Identificando a massa de testes de entrada
28.1.2. Definindo a Saída de Dados

Os dados de saída são modelados de acordo com os dados de entrada e em re-
lação à expectativa de resultados apontados pelos requisitos de negócios de-
finidos. Será através dos dados de saída que poderemos avaliar se o compor-
tamento da unidade está em conformidade com os requisitos levantados.
Tendo em mãos todos os cenários possíveis, podemos construir uma ta-
bela que demonstre todas as combinações possíveis de serem executadas du-
rante os testes. Com essa combinação em mãos, temos a massa de dados a ser
aplicada durante os testes dessa unidade.
Tabela 28.1
Estruturação da massa de testes a ser aplicada no controlador
Casos de Testes Condições dos Testes Resultado
Salário Idade Noturno Bonificação
Sem Bonificação 1.000,00 35 Não –
Bonificação por Idade 1.000,00 55 Não 50,00
Bonificação por Trabalho 1.000,00 35 Sim 100,00

Noturno
Bonificação por Idade + por 1.000,00 55 Sim 150,00

Trabalho Noturno
Sem Bonificação
Sem Bonificação
(Entradas)
Unidade (Saídas)
a Ser
Testada
Idade = 35 anos
Bonificação = R$0,00
Noturno = Não
Bonificação Idade
Bonificação Idade
(Entradas)
Unidade (Saídas)
a Ser
Testada
Idade = 55 anos
Noturno = Não
Bonificação por trabalho

Bonificação por Trabalho
Noturno (Entradas)
Unidade Noturno
a Ser (Saídas)
Testada
Idade = 35 anos
Noturno = Sim
Bonificação por Idade +

Bonificação por Idade +
Trabalho Noturno
Unidade Trabalho Noturno
(Entradas)
a Ser (Entradas)
Salário = R$ 1.000,00
Testada
Idade = 55 anos
Noturno = Sim
Figura 28.3 Identificando a massa de testes de saída
28.2. Especificando um Controlador de Testes

Os controladores serão criados, única e exclusivamente, para a realização de
testes de execução do software. Os controladores podem ser codificados em
qualquer linguagem, porém é recomendável o emprego de alguma ferra-
menta de teste para auxiliar na construção destes controladores, inclusive
na montagem das massas de testes. Caso isso não seja possível, a tarefa de
construção desses controladores será um pouco mais “espinhosa”.
28.2.1. Estrutura Básica de um Controlador

De qualquer forma, os controladores são estruturas de programas relativa-
mente simples, que seguem essa estrutura básica de comportamento:
Ler uma fonte externa de entrada de dados.

Processar uma determinada rotina da unidade a ser testada.
Ler uma fonte externa de saída de dados e comparar os resultados.
Gerar um log de execução do controlador.
Log de
Execução
Dados
Geração Ok
de Entrada
Log de Execução Ok
1000;35;Não Alimenta
ERRO
1000;55;Não
Ok
1000;35;Sim
1000;55;Sim
Controlador Unidade
de Testes Executa a ser
da Unidade Testada
Dados de
Saída
0
50 Compara
100
150
Figura 28.4 Estrutura básica de um controlador de testes
Os controladores serão executados sempre que ocorrer alguma modifi-

cação no código-fonte da unidade correspondente, independentemente da
parte do código alterada. Dessa forma, garantimos que a unidade mantém
suas características originais, ou seja, após as mudanças, todo seu comporta-
mento continua adequado aos requisitos de negócios.
28.2.2. Definindo o Log do Controlador

Durante a execução do controlador, este deverá comparar os resultados ob-
tidos com os dados de saída previstos no planejamento das massas de testes
do controlador. Caso exista alguma divergência, esta será apontada automa-
ticamente no log de execução, que deverá ser analisado após o término da
execução do controlador.
Tabela 28.2
Estruturação do Log de execução gerado pelo controlador
Casos de Testes Condições dos Testes Resultado Log de Execução

Salário R$ Idade Noturno Bonificação R$ Testado Situação
Sem Bonificação 1.000,00 35 Não – Sim OK
Bonificação por Idade 1.000,00 55 Não 50,00 Sim Ok
Bonificação por 1.000,00 35 Sim 100,00 Sim Erro
Trabalho Noturno
Bonificação por Idade + 1.000,00 55 Sim 150,00 Sim Ok
por Trabalho Noturno
28.2.3. Exemplo de um Controlador

Abaixo é apresentado um exemplo de como poderia ser codificado um con-
trolador para validar o comportamento da rotina ObtemPremioAdicional.
Nota-se que esta estrutura será similar a de outros controladores existentes.
Private Const PATH_ DADOS = “C:\Testes Unidade\”

Private Const DADOS_ENTRADA = “Entradas.txt”
Private Const DADOS_SAIDA = “Saidas.txt”
Private Const DADOS_LOG = “Log-Execucao.txt”
Public Function TestarObtemPremioAdicional( )
Dim vlArquivoEntrada, vlArquivoSaida, vlArquivoLogExecucao As New

CLS_ARQUIVO
Dim vlSalario As Double : vlIdade As Integer : vlNoturno As Boolean
Dim vlPosicaoLinha As Long : vlResultadoEsperado As Double
‘ Abre Arquivos de Entrada e Saída / Cria Log de Execução
vlArquivoEntrada.Abrir PATH_ DADOS, DADOS_ENTRADA, prmSeparador:=";"

vlArquivoSaida.Abrir PATH_ DADOS, DADOS_SAIDA
vlArquivoLogExecucao.Criar PATH_ DADOS, DADOS_LOG
With vlArquivoEntrada
‘ Executa o número de linhas que existirem no arquivo de entradas
For vlPosicaoLinha = 1 To .Linhas.Count
‘ Define Parâmetros de Entrada
vlSalario = Val(.Linhas(vlPosicaoLinha).Conteudos(1).conteudo)
vlIdade = Val(.Linhas(vlPosicaoLinha).Conteudos(2).conteudo)
vlNoturno = (.Linhas(vlPosicaoLinha).Conteudos(3).conteudo = “S”)
‘ Define Parâmetros de Saídas Esperados
With vlArquivoSaida.Linhas(vlPosicaoLinha)
vlResultadoEsperado = Val(.texto)
End With
‘ Executa Rotina a ser testada e monta “Log de Execução”
With vlArquivoLogExecucao.Linhas
If vlResultadoEsperado = ObtemPremioAdicional(vlSalario, vlIdade,

vlNoturno) Then
.NovaLinha prmTexto:="Ok"
Else
.NovaLinha prmTexto:="Erro"
End If
End With
Next
End With
vlArquivoLogExecucao.Salvar
vlArquivoEntrada.Fechar
vlArquivoSaida.Fechar
vlArquivoLogExecucao.Fechar
End Function
CAPÍTULO 29
Um Exemplo Real:
O Novo SPB
Recentemente, o Banco Central (Bacen) reestruturou a forma como

todos os bancos realizariam transações financeiras. No formato anterior, to-
das as instituições financeiras realizavam suas operações durante o dia e so-
mente no final do expediente é que as transações seriam “conciliadas”. Se al-
guma instituição não conseguisse “fechar” as transações, o Banco Central
era obrigado a “saldar a dívida” e assumir o prejuízo, evitando um mal maior
para o sistema financeiro brasileiro. Como sabemos, várias instituições fali-
ram e por várias vezes o Banco Central necessitou “fechar a conta”. Essa de-
ficiência no sistema financeiro brasileiro aumenta o chamado Risco Brasil e
eleva as taxas de juros para empréstimos internacionais, uma vez que o risco
de não-pagamento por uma quebra generalizada é maior.
A proposta com o novo SPB (Sistema de Pagamento Brasileiro) é exata-
mente minimizar o risco de quebra do setor financeiro, realizando as transa-
ções no momento em que estão acontecendo (real-time). Nesse formato, se
alguma instituição não tem “lastro” para efetivar determinada operação, esta
não será autorizada pelo Banco Central. Dessa forma, o Banco Central moni-
tora permanentemente a saúde financeira das instituições, eliminando o ris-
co de uma “quebra nos pagamentos”, o que reduz o Risco Brasil e deixa nos-
so país mais competitivo no cenário mundial.
Um Exemplo Real: O Novo SPB
29.1. Dinâmica do Novo SPB

Quando uma instituição financeira realiza determinada operação, esta deve
passar obrigatoriamente pelo Banco Central, estabelecendo uma conciliação
real-time das transações financeiras. O Banco Central cuidará do gerencia-
mento e repasse das mensagens às outras instituições, intervindo quando
uma operação inconsistente estiver acontecendo. Porém, todas as transa-
ções de uma instituição financeira são suportadas por sistemas informatiza-
dos. Em função da necessidade de “enviar mensagens” ao Banco Central, es-
ses sistemas deverão ser adaptados para que as transações sejam monitora-
das diretamente pelo Banco Central.
Mensagem 1 Mensagem 2
Instituição Instituição
Financeira Banco Financeira
“A” Resposta Central Resposta “B”
Figura 29.1 Dinâmica “real” das transações gerenciadas pelo Banco Central
29.2. Testes Não Funcionais no Novo SPB

O Banco Central, consciente do volume de mudanças existente para adaptar
todos os sistemas da organização, disponibilizou um ambiente de testes, cria-
do com a intenção de permitir a troca de mensagens entre instituições finan-
ceiras, para que estas simulem situações de negócios em um ambiente mais
próximo do real, possibilitando validar aspectos como performance, infra-
estrutura, limites de transações, gargalos, entre outros.
Como podemos observar na Figura 29.2, esse ambiente de testes possibi-
lita a execução de simulações financeiras entre as diversas instituições exis-
tentes, de modo a gerar a criação de cenários nas mais variadas situações pas-
síveis de ocorrer em um ambiente de produção.
O que inicialmente parece ser uma vantagem, torna-se um grande
problema – para que possamos criar os cenários, dependemos de como a insti-
tuição financeira está tratando as mensagens que nós estamos enviando. Se
lembrarmos que essa instituição também está planejando seus próprios tes-
tes, dificilmente conseguiremos convencê-la de disponibilizar seu tempo
para testar a aplicação de terceiros.
Instituição
Financeira
“A”
Mensagem 1
Banco
Minha Central Instituição
Instituição Financeira
Financeira Resposta “B”
Ambiente
de Testes
Instituição
Financeira
“C”
Figura 29.2 Ambiente de testes disponibilizado pelo Banco Central
O ambiente disponibilizado pelo Banco Central atende adequadamen-

te à realização de testes de requisitos não funcionais, porém, os testes de
negócios seriam inviáveis nesse cenário, pois criariam dependência direta
com outras instituições para provocar as simulações necessárias. Assim,
torna-se necessário buscar uma alternativa viável para realizar os testes
funcionais.
29.3. Testes Funcionais no Novo SPB

No ambiente disponibilizado pelo Banco Central, a criação de diversos cená-
rios de negócios criaria uma dinâmica muito complexa e extremamente de-
pendente das outras instituições financeiras, às quais não temos nenhum
controle efetivo. Portanto, necessitamos criar uma arquitetura de testes que
nos permita simular todas as situações de negócios que desejamos sem que
existam dependências que limitem nossas atividades de testes – trata-se de
uma aplicação real de um simulador de software.
Com a criação de um simulador Bacen, será possível criar qualquer ce-
nário de negócio sem envolver diretamente nenhuma instituição financei-
ra, além de não existir tempo de espera de mensagens, uma vez que o pró-
prio simulador encarrega-se de gerar as respostas no formato e conteúdo
ao qual este foi parametrizado. Com essa solução, conseguimos automati-
zar um processo de testes de forma rápida e flexível, eliminando todos os
aspectos de dependências que poderiam afetar o bom planejamento dos
testes funcionais.
Um Exemplo Real: O Novo SPB
Instituição
Financeira
“A”
Mensagem 1
Minha Instituição
Simulador
Instituição Resposta Financeira
Financeira
Bacen “B”
Instituição
Financeira
“C”
Figura 29.3 Dinâmica “simulada” das operações gerenciadas pelo Banco Central
Cabe lembrar que os testes como o SPB são algo definitivo, e sempre que
ocorrerem mudanças em sistemas da área financeira a troca de mensagens
pode ter sido comprometida, sendo adequado existir um método eficiente
que valide todas as combinações de negócios possíveis, o que justificaria um
considerável investimento financeiro para obtermos esse simulador.
Antes de iniciarmos um esforço de construção deste, vale a pena avaliar
se existe algum fornecedor de software que está disposto ou que já o cons-
truiu para uma outra instituição, o que reduziria os investimentos de tempo
e dinheiro a serem direcionados a essa atividade.
Índice de Figuras
Figura 2.1 Possíveis níveis de maturidade previstos no

modelo CMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figura 2.2 Esforço dedicado à correção de defeitos no
desenvolvimento de software . . . . . . . . . . . . . . . . . . . . . 14
Figura 2.3 Esforço gerencial para alcançar níveis maiores de
maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figura 3.1 Definição de qualidade de software . . . . . . . . . . . . . . . . 16
Figura 3.2 Simplificação das definições dos testes . . . . . . . . . . . . . . 20
Figura 3.3 Visões dos testes por perspectivas diferentes . . . . . . . . . 21
Figura 3.4. Definição ampliada de testes. . . . . . . . . . . . . . . . . . . . . . 22
Figura 3.5 Os pilares da garantia da qualidade de software . . . . . . . 23
Figura 3.6 Ciclo de desenvolvimento no qual qualidade
resume-se a testes de software . . . . . . . . . . . . . . . . . . . . 25
Figura 3.7 Qualidade em todo o ciclo do processo de
desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 3.8 Incidência de defeitos nas etapas do desenvolvimento . . 26
Figura 3.9 Garantia da qualidade de software em todo o ciclo de
desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 3.10 Modelo de custo da qualidade de software . . . . . . . . . . . 30
Figura 3.11 Regra de 10 de Myers . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 3.12 Custo da qualidade versus efetividade do processo . . . . 32
Figura 4.1 Visão do modelo de processo de qualidade de
software em “U” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 4.2 Etapas dos testes de verificação . . . . . . . . . . . . . . . . . . . 38
Figura 4.3 Etapas dos testes de validação. . . . . . . . . . . . . . . . . . . . . 39

Figura 5.1 Ciclo de desenvolvimento tradicional (Waterfall) . . . . . 41
Figura 5.2 Ciclo de desenvolvimento iterativo . . . . . . . . . . . . . . . . 43
Figura 5.3 Ciclo de teste iterativo e reaproveitamento dos testes . . 45
Figura 5.4 Ciclo de qualidade iterativa . . . . . . . . . . . . . . . . . . . . . . 46
no planejamento do software . . . . . . . . . . . . . . . . . . . . . 54
no ciclo de desenvolvimento real . . . . . . . . . . . . . . . . . . 55
Figura 7.1 Fatores que contribuem para a desorganização de um
projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 7.2 Influência da desorganização no nível de retrabalho . . . 62
Figura 7.3 Exemplo de propagação de erros durante uma
mudança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 9.1 Métodos estruturados de verificação . . . . . . . . . . . . . . . 74
Figura 9.2 Fases de criação de documentos e respectivos tipos
de revisões. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figura 9.3 Checklist aplicado nas diversas fases dos testes
de verificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figura 10.1 Objetivo da verificação de negócios . . . . . . . . . . . . . . . . 85
Figura 10.2 Objetivo da verificação de requisitos . . . . . . . . . . . . . . . 88
Figura 10.3 Objetivo da verificação de análise e modelagem. . . . . . . 91
Figura 10.4 Objetivo da verificação da implementação . . . . . . . . . . . 94
Figura 11.1 Estratégias fundamentais dos testes . . . . . . . . . . . . . . . 104
Figura 11.2 Visão de testes de caixa branca . . . . . . . . . . . . . . . . . . . 104
Figura 11.3 Visão de testes de caixa preta . . . . . . . . . . . . . . . . . . . . 105
Figura 11.4 Abordagens fundamentais dos testes . . . . . . . . . . . . . . 107
Figura 11.5 Risco da ausência dos testes regressivos . . . . . . . . . . . . 108
Figura 12.1 Levantamento dos cenários sem os conceitos
de categorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Figura 12.2 Visão categorizada dos testes de software. . . . . . . . . . . 113
Figura 13.1 Técnicas caixa branca para obtenção dos casos
de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Figura 13.2 Técnicas caixa preta para obtenção dos casos de
testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Índice de Figuras
Figura 13.3 Decomposição de requisitos em cenários de testes. . . . 124

Figura 13.4 Diagrama de atividades como fonte de identificação
dos casos de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Figura 13.5 Diagrama de estados como fonte de identificação
dos casos de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Figura 13.6 Progressão de cobertura do código-fonte . . . . . . . . . . . 127
Figura 13.7 Progressão da cobertura de caminhos do código-fonte 128
Figura 13.8 Níveis de cobertura de desvios condicionais . . . . . . . . 129
Figura 13.9 Volume dos casos de testes em relação ao modelo
de cobertura de desvios. . . . . . . . . . . . . . . . . . . . . . . . . 131
Figura 13.10 Erros comuns em laços encontrados nos
códigos-fonte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Figura 13.11 Tipos de laços encontrados nos códigos-fonte . . . . . . . 132
Figura 14.1 Objetivo da validação da unidade de software . . . . . . . 140
Figura 14.2 Objetivo da validação da unidade de software . . . . . . . 142
Figura 14.3 Testes unitários baseados na arquitetura da aplicação . 144
Figura 14.4 Testes unitários com abordagem isolada . . . . . . . . . . . 145
Figura 14.5 Testes unitários com abordagem top-down . . . . . . . . . 146
Figura 14.6 Testes unitários com abordagem bottom-up . . . . . . . . 148
Figura 14.7 Objetivo da validação das integrações de software . . . . 149
Figura 14.8 Validação das integrações entre unidades com
abordagem big-bang . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Figura 14.9 Testes de integração com a abordagem top-down . . . . 151
Figura 14.10 Tipos de integração top-down . . . . . . . . . . . . . . . . . . . 151
Figura 14.11 Testes de integração com a abordagem bottom-up. . . . 152
Figura 14.12 Objetivo da validação do sistema . . . . . . . . . . . . . . . . . 154
Figura 14.13 Simuladores nos testes de sistema deixam
o ambiente mais gerenciável . . . . . . . . . . . . . . . . . . . . . 156
Figura 14.14 Testes de sistemas integrados identificam gargalos
de processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Figura 14.15 Objetivo da validação do aceite . . . . . . . . . . . . . . . . . . 158
Figura 14.16 Estágios do processo de aceite de um software. . . . . . . 158
Figura 15.1 Conceito de testware. . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Figura 15.2 Definição de ambiente . . . . . . . . . . . . . . . . . . . . . . . . . 165
Figura 15.3 Gestão de ambientes . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Figura 15.4 Ambiente de desenvolvimento . . . . . . . . . . . . . . . . . . . 166

Figura 15.5 Ambiente de teste e homologação . . . . . . . . . . . . . . . . 168
Figura 15.6 Ambiente de produção . . . . . . . . . . . . . . . . . . . . . . . . . 169
Figura 16.1 Áreas que participam de um processo de
desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Figura 16.2 Estrutura de um projeto com equipes de trabalho . . . 172
Figura 16.3 Comitê de gestão dos projetos de software. . . . . . . . . . 173
Figura 16.4 Ausência de uma área de testes independente . . . . . . . 174
Figura 16.5 Criação de uma área de testes de software
independente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Figura 16.6 A MDS faz o processo de software girar em torno
da área de desenvolvimento . . . . . . . . . . . . . . . . . . . . . 175
Figura 16.7 A área de qualidade de software atua sobre processos
de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Figura 18.1 Controladores são criados para testar cada unidade
de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Figura 18.2 Utilizando simuladores para eliminar dependências
de hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Figura 19.1 Categorias das ferramentas de testes. . . . . . . . . . . . . . . 186
Figura 19.2 Características das ferramentas de planejamento dos
testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Figura 19.3 Características das ferramentas de revisões e
inspeções. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Figura 19.4 Características das ferramentas de modelagem e
automação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Figura 19.5 Características das ferramentas de execução e
conferência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Figura 19.6 Características das ferramentas de suporte aos testes . . 191
Figura 20.1 Itens que compõem os custos de execução dos testes . 194
Figura 21.1 Estrutura de documentação do planejamento . . . . . . . 202
Figura 21.2 Plano de garantia da qualidade do software . . . . . . . . . 202
Figura 21.3 Plano-mestre de verificação . . . . . . . . . . . . . . . . . . . . . 203
Figura 21.4 Estratégias de verificação . . . . . . . . . . . . . . . . . . . . . . . 204
Figura 21.5 Plano-mestre de validação . . . . . . . . . . . . . . . . . . . . . . 205
Figura 21.6 Estratégias de validação . . . . . . . . . . . . . . . . . . . . . . . . 206
Índice de Figuras
Figura 21.7 Casos de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Figura 21.8 Suítes de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Figura 22.1 Estrutura de relatórios da qualidade . . . . . . . . . . . . . . . 211
Figura 22.2 Executando as verificações . . . . . . . . . . . . . . . . . . . . . . 211
Figura 22.3 Relatório de verificações . . . . . . . . . . . . . . . . . . . . . . . . 212
Figura 22.4 Executando as validações . . . . . . . . . . . . . . . . . . . . . . . 213
Figura 22.5 Log de execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Figura 22.6 Ocorrências da validação . . . . . . . . . . . . . . . . . . . . . . . 214
Figura 22.7 Relatório final da validação. . . . . . . . . . . . . . . . . . . . . . 215
Figura 23.1 Indicadores de cobertura dos testes . . . . . . . . . . . . . . . 221
Figura 23.2 Índice de cobertura do planejamento de requisitos . . . 221
Figura 23.3 Índice de cobertura do planejamento do código-fonte . . 221
Figura 23.4 Análise da cobertura dos testes . . . . . . . . . . . . . . . . . . . 222
Figura 23.5 Índice de cobertura de execução de requisitos . . . . . . . 222
Figura 23.6 Índice de cobertura de execução do código-fonte . . . . 223
Figura 23.7 Evolução da cobertura da execução dos testes . . . . . . . 223
Figura 23.8 Índice de eficiência da verificação . . . . . . . . . . . . . . . . 224
Figura 23.9 Índice de eficiência da validação. . . . . . . . . . . . . . . . . . 224
Figura 23.10 Distribuição de defeitos por etapas . . . . . . . . . . . . . . . . 225
Figura 23.11 Distribuição de defeitos por categoria . . . . . . . . . . . . . 227
Figura 23.12 Distribuição dos defeitos por prioridade . . . . . . . . . . . 229
Figura 23.13 Distribuição de defeitos por fornecedor . . . . . . . . . . . . 229
Figura 23.14 Distribuição de defeitos por componentes
(software e hardware) . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Figura 23.15 Distribuição dos defeitos por idade . . . . . . . . . . . . . . . 231
Figura 23.16 Distribuição dos defeitos por situação . . . . . . . . . . . . . 232
Figura 23.17 Tendências dos defeitos durante o ciclo de vida
dos testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Figura 23.18 Histórico de produtividade e retrabalho . . . . . . . . . . . . 234
Figura 23.19 Diagrama de causa e efeito (espinha de peixe) . . . . . . . 234
Figura 23.20 Distribuição dos defeitos por prioridade . . . . . . . . . . . 235
Figura 24.1 A ausência de simuladores deixa os testes complexos
e inviáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Figura 24.2 Abordagens possíveis para a aplicação dos testes . . . . . 244
Figura 24.3 Dimensão tempo em sistemas batch . . . . . . . . . . . . . . . 246

Figura 24.4 Dimensão tempo em sistemas on-line . . . . . . . . . . . . . 246
Figura 24.5 Dimensão tempo em sistemas real-time . . . . . . . . . . . . 247
Figura 25.1 Representação de troca de informações batch entre
sistemas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Figura 25.2 Alvo dos testes identificados. . . . . . . . . . . . . . . . . . . . . 250
Figura 25.3 Testes de exportação de arquivos . . . . . . . . . . . . . . . . . 251
Figura 25.4 Conferência através da comparação de arquivos . . . . . 252
Figura 25.5 Cenários de exportação e respectivos arquivos de
referência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Figura 25.6 Testes para importação de arquivos . . . . . . . . . . . . . . . 256
Figura 25.7 Cenários de importação e respectivos arquivos
de simulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Figura 26.1 Representação em UML de uma troca de informações
entre sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Figura 26.2 Ciclo de análise de crédito no sistema de gestão
de crédito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Figura 26.3 Definição do ciclo de vida do pedido no sistema
de vendas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Figura 26.4 Lista de restrições de crédito que serão contempladas
no simulador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Figura 26.5 Classe que contempla as operações do simulador . . . . 267
Figura 26.6 Serviços internos do simulador possibilitam
substituição total do aplicativo . . . . . . . . . . . . . . . . . . . 270
Figura 27.1 Solução ATM com o dispositivo físico Cash Dispenser . 272
Figura 27.2 Solução ATM com o Cash Dispenser Virtual . . . . . . . . 273
Figura 27.3 Visão do teste de desenvolvimento da solução ATM . . 273
Figura 27.4 Especificando o simulador Cash Dispenser . . . . . . . . . 274
Figura 27.5 Classe que suportará as operações do simulador . . . . . 274
Figura 27.6 Representação da interface do Cash Dispenser
Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Figura 27.7 Testando o Cash Dispenser Virtual . . . . . . . . . . . . . . . 277
Figura 28.1 Criando uma massa de testes para aplicar no
controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Figura 28.2 Identificando a massa de testes de entrada . . . . . . . . . . 281
Índice de Figuras
Figura 28.3 Identificando a massa de testes de saída . . . . . . . . . . . . 282

Figura 28.4 Estrutura básica de um controlador de testes . . . . . . . . 283
Figura 29.1 Dinâmica “real” das transações gerenciadas pelo
Banco Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Figura 29.2 Ambiente de testes disponibilizado pelo Banco Central . . 288
Figura 29.3 Dinâmica “simulada” das operações gerenciadas pelo
Banco Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Índice de Tabelas
Tabela 1.1 Evolução do processo de qualidade e de testes de

software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Tabela 2.1 Distribuição das áreas-chave pelos níveis de
maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Tabela 5.1 Representação de um típico projeto em cascata
(diagrama de Gantt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Tabela 5.2 Critério de finalização para especificação de requisitos
funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Tabela 5.3 Critério de finalização da inspeção de código. . . . . . . . . 48
Tabela 5.4 Critério de finalização dos testes de validação . . . . . . . . 48
Tabela 7.1 Comparativo entre testes manuais e automatizados . . . . 64
Tabela 10.1 Análise das fases dos testes de validação . . . . . . . . . . . . 83
Tabela 10.2 Exemplo de Checklist do modelo de negócios . . . . . . . . 86
Tabela 10.3 Exemplo de Checklist da proposta de projeto de
software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Tabela 10.4 Exemplo de Checklist de requisitos . . . . . . . . . . . . . . . . 90
Tabela 10.5 Exemplo de Checklist de diagramas UML. . . . . . . . . . . . 92
Tabela 10.6 Exemplo de Checklist de arquitetura . . . . . . . . . . . . . . . 93
Tabela 10.7 Exemplo de Checklist de código-fonte . . . . . . . . . . . . . . 95
Tabela 10.8 Exemplo de Checklist do banco de dados . . . . . . . . . . . . 96
Tabela 12.1 Levantamento dos cenários aplicando-se os conceitos
de categorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Tabela 12.2 Comparação entre levantamentos de testes . . . . . . . . . 112
Tabela 12.3 Exemplo de priorização das categorias de testes . . . . . 120
Índice de Tabelas
Tabela 13.1 Exemplo de refinamento por partição de

equivalência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Tabela 13.2 Exemplo de refinamento por valores-limite . . . . . . . . . 135
Tabela 13.3 Exemplo de refinamento por probabilidade de erro . . . 137
Tabela 14.1 Análise das fases dos testes de validação . . . . . . . . . . . 139
Tabela 14.2 Testes de integração com a abordagem mista . . . . . . . . 153
Tabela 20.1 Alternativas na preparação do ambiente . . . . . . . . . . . . 194
Tabela 20.2 Alternativas na execução dos testes . . . . . . . . . . . . . . . 196
Tabela 20.3 Alternativas na conferência dos testes . . . . . . . . . . . . . 198
Tabela 26.1 Critérios para análise de crédito do pedido . . . . . . . . . 263
Tabela 26.2 Cenários necessários para validar análise de crédito . . 266
Tabela 26.3 Cenários necessários para validar o sistema de vendas. 266
Tabela 26.4 Parametrizações efetuadas no simulador de gestão
de crédito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Tabela 27.1 Parametrizações efetuadas no Cash Dispenser Virtual . 276
Tabela 28.1 Estruturação da massa de testes a ser aplicada no
controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Tabela 28.2 Estruturação do log de execução gerado pelo
controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Bibliografia
_____. Advanced Coverage Metrics for Object-Oriented Software.

IPL Information Processing Ltd. – 1999.
_____. Application Test in The Real World.
Compuware Corporation – 2000.
_____. Higher Process Maturity.
Rational Software Corporation and Q-Labs (White Paper) – 2001.
_____. Microsoft Solutions Framework and The Rational Process.
Rational Software Corporation (White Paper) – 2001.
_____. Organisational Aproaches for Unit Testing.
_____. Reaching CMM Levels 2 and 3 with the Rational Unified Process.
_____. Solutions Development Discipline - Application Model.
Microsoft Corporation – 1997.
_____. Structural Coverage Metrics.
_____. Why Bother to Unit Test?
IPL Information Processing Ltd. –1996.
_____. Guide to Software Engineering Body of Knowledge (SWEBOK).
IEEE Software - Maio de 2001.
Fowler, Martin. UML distilled: a brief guide to standard object modeling lan-
guage / Martin Fowler with Kendall Scott – 2nd ed.
New York: Addison Wesley Longman, Inc., 1999.
Heumann, Jim. Generating Test Cases from Use Cases.
Rational Software Corporation (The Rational Edge) – Junho de 2001.
Bibliografia
Juran, J. M. A Qualidade desde o Projeto.

São Paulo: Pioneira Thomson Learning, 2001.
Kit, Edward. Software Testing in the Real World. Addison-Wesley, 2000.
Kruchten, Philippe. From Waterfall to Interactive Lifecycle.
Kruchten, Philippe. The Rational Unified Process: an Introduction.
São Paulo: Addison-Wesley, 1999.
Paul R. Reed, Jr. Desenvolvendo Aplicativos com Visual Basic e UML.
São Paulo: Makron Books, 2000.
Pigoski, Thomas M. Pratical Software Maintenance.
New York: John Wiley & Sons Inc., 1999.
Vargas, Ricardo Viana. Gerenciamento de Projetos – 2a edição.
Rio de Janeiro: Brasport, 2000.
Weinberg, Gerald M. Software com Qualidade – Vol. II: Medidas de Primeira
Ordem. São Paulo: Makron Books, 1994.
Yeh, Hsiang-Tao. Software Process Quality.
New York: McGraw-Hill, 1993.

Alexandre Bartie-Garantia de Qualidade de Software PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Alexandre Bartie-Garantia de Qualidade de Software PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Alexandre Bartie-Garantia de Qualidade de Software PDF

Enviado por

Direitos autorais:

Formatos disponíveis

© 2002, Elsevier Editora Ltda.

Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998.

Rua Quintana, 753 – 8º andar

Serviço de Atendimento ao Cliente

ISBN 13: 978-85-352-1124-5

1. Software – Testes. I. Título

02-1253. CDD — 005.14

Minha esposa Ivone,

Meus pais, Carlos e Dalva,

Minha afilhada Caroliny,

Alexandre Bartié é pós-graduado em Capacitação Gerencial pela FEA-USP e

O autor pode ser encontrado no seguinte endereço eletrônico:

Com o passar dos anos, estamos verificando um aumento da influência

Consultor de Qualidade e Engenharia de Software

Totalmente alinhado com as mais modernas metodologias existen-

Parte I • Introdução à Qualidade de Software

Parte II • Processo de Garantia de Qualidade de Software

Parte III • Garantia da Qualidade do Processo

Parte IV • Garantia da Qualidade do Produto

Parte V • Gerenciamento do Testware

Parte VI • Estruturas da Documentação

Parte VII • Métricas da Qualidade de Software

Parte VIII • Aplicações Reais

“Se tivesse seis horas para derrubar uma

“Os homens prudentes sabem tirar proveito

“O planejamento não diz respeito a decisões

“O insucesso é apenas uma oportunidade

“Somos o que repetidamente fazemos.

“Falta de tempo é desculpa daqueles que

“Toda manhã, na África, um leão acorda.

“Existe o risco que você não pode

Nos primórdios do desenvolvimento de software, a atividade de teste

boa funcionalidade de um aplicativo, seriam encontrados poucos defeitos,

1.1. Cenário Atual do Desenvolvimento de Software

Evolução das Organizações Desenvolvedoras de Software

Características 1960 1980 2000

Tamanho do Software Pequeno Médio Muito

Padrões e Metodologias de Qualidade Interno Emergente Sofisticado

Apesar do enorme avanço do desenvolvimento de software nos últimos 40

1.2. A Realidade dos Projetos de Software

 Mais de 30% dos projetos são cancelados antes de serem finalizados.

Devemos considerar que o mercado americano é muito mais exigente e

vo e formal das empresas e profissionais americanos, que possuem obsessão

Um dos objetivos de se implantar um processo de qualidade de software é

contínua, trazendo disciplina e controle no desenvolvimento e manutenção

2.1. O Modelo CMM

NÍVEL 5: FOCO NO APERFEIÇOAMENTO

NÍVEL 4: PROCESSO MEDIDO E

NÍVEL 3: PROCESSO CARACTERIZADO E

NÍVEL 2: TAREFAS “MESTRAS” PODEM SER

NÍVEL 1: ANÁRQUICO PROCESSO IMPREVISÍVEL E

Figura 2.1 Possíveis níveis de maturidade previstos no modelo CMM

zação consegue enxergar somente o que sua maturidade permite. Apesar

2.2. Áreas-chave do Processo (KPAs)

Nível Processo Processo Processo de

1 -x-x-x- -x-x-x- -x-x-x-

Projetos em organizações com CMM-Nível 2 têm controles básicos de

volvimento são sistematicamente monitorados, possibilitando a evolução

tes e profissionais e capacitá-los a desempenhar melhor suas funções, em-

Mais de 30% dos projetos são cancelados antes de serem finalizados.

Gerência integrada de software

Planejamento dos trabalhos

Auditoria: Nível superficial de um processo de qualidade. Verifica se