Qualidade de software

Thiago Carlos de Andrade

MBA Profissional em Sistemas de Informao - Prof FBIO LUIZ BIGATI

Resumo
Este artigo visa a anlise das melhores prticas de produo de software em relao
qualidade. Dentro dessa proposta ser estudado os fundamentos da qualidade no processo e
no produto. Esta anlise ser efetivada atravs dade pesquisa qualitativa e bibliogrfica, com
coleta de dados em livros e sites, e posterior anlise dos dados .

Palavras-chave: Qualidade de software, fundamentos da qualidade, produto, processo

ABSTRACT
This article aims to examine the best software production practices in
relation to the quality. Within this proposal will be studied the
fundamentals of quality in the process and the product. This analysis will
be carried through ity qualitative and bibliographic research, with data
collection in books and websites, and subsequent data analysis.

Keywords: software quality, quality fundamentals, product, process

SUMRIO

Captulo 1
1.Fundamentos de qualidade de software
1.1 - Introduo
1.2 -A O que qualidade?
1.3- Engenharia de Software
1.4 - Metodologias de produo de software
Captulo 2
2.Valores e custos de qualidade
Captulo 3
3.Modelos e caractersticas de qualidade
Captulo 4
4.Qualidade do processo versus qualidade da produo
Captulo 5
5.Garantia de qualidade de software
Captulo 5
6.Verificao e validao
Captulo 7
7.Revises e auditorias
Captulo 8
8.Requisitos de qualidade
Captulo 9

9.Medidas de qualidade de software

Consideraes finais
Referncias bibliogrficas

A qualidade de software uma rea de conhecimento da engenharia de

software que objetiva garantir a qualidade do software atravs da
definio e normatizao de processos de desenvolvimento. Apesar dos
modelos aplicados na garantia da qualidade de software atuarem
principalmente no processo, o principal objetivo garantir um produto
final que satisfaa s expectativas do cliente, dentro daquilo que foi
acordado inicialmente.
Segundo a norma ISO 9000 (verso 2000), a qualidade o grau em que
um conjunto de caractersticas inerentes a um produto, processo ou
sistema cumpre os requisitos inicialmente estipulados para estes.

Captulo 1
1.Fundamentos de qualidade de software
1.1 - Introduo
Segundo Pressman (2006), um software um conjunto composto por
instrues de computador, estruturas de dados e documentos; Na era
atual o software to importante quanto era a geladeira para o sculo 20.
No vivemos mais sem o uso do mesmo, porm, assim como todo
produto, o software precisa ser utilizvel. Diante do exposto, ser
discorrido nesse artigo a qualidade de softwre.

1.2 - O que qualidade?

A qualidade total e excelncia so princpios que promovem a criao de

valor e o encantamento dos clientes.
Paulo Eduardo Dubie
Termo de grande abrangncia. A Qualidade a adequao ao uso. a
conformidade s exigncias. Esta a definio tcnica estabelecida pelo
ISO INTERNATIONAL STANDARDIZATION ORGANIZATION, situado na Sua
e responsvel pelas normas de Qualidade, em diversos setores, no mundo
inteiro.
O enfoque na qualidade e da qualidade evolui medida que as relaes
sociais e econmicas do homem se tornam mais complexas
Pode-se dizer que a histria mais recente da qualidade comeou com a
Revoluo Industrial e a disseminao da produo em srie.

1.3- A Engenharia de Software

A Engenharia de Software pautada no Guide to the SoftWare Engineering
Body of Knowledge (SWEBOK).
O SWEBOK um documento criado sob o patrocnio da IEEE
com a finalidade de servir de referncia em assuntos
considerados, de forma generalizada pela comunidade, como
pertinentes a rea de Engenharia de Software.
A Engenharia de Software surgiu aos poucos em respostas crise do
software.
A crise do software foi um termo utilizado nos anos 1970, quando a
engenharia de software era praticamente inexistente. O termo expressava
as dificuldades do desenvolvimento de software frente ao rpido
crescimento da demanda por software, da complexidade dos problemas a
serem resolvidos e da inexistncia de tcnicas estabelecidas para o
desenvolvimento de sistemas que funcionassem adequadamente ou
pudessem ser validados. As causas da crise do software esto ligadas a

complexidade do processo de software e a relativa imaturidade da

engenharia de software como profisso.
A maior parte dos projetos continuam com estes problemas ainda na
atualidade, assim pode se dizer que a crise continua vigente ainda na
atualidade.
O objetivo da Engenharia de Software Desenvolver Software como uma
Atividade Industrial E inserir as mesmas sistemticas existentes em
outras reas da engenharia:
custos aceitveis; gerenciamento do processo de desenvolvimento;
garantia do trabalho em equipe e; desenvolvimento de softwares
com qualidade.

1.4 - Metodologias de produo de software

Na Engenharia de Software as principais abordagens de Metodologias de

Desenvolvimento de Software so:
1. Metodologias Clssicas (Tradicionais)
Tambm conhecidas como Metodologias orientadas a planejamento, as
Metodologias Clssicas dominaram a forma de desenvolvimento de
softwares at o incio da dcada de 90, Entretanto, estas metodologias
devem ser aplicadas apenas em situaes em que os requisitos do
sistema so estveis e os requisitos futuros so previsveis.
Metodologias ou Processos orientados a documentao so, de certa
forma, barreiras impostas ao desenvolvimento, pois muitas organizaes
no possuem recursos para processos pesados de produo de software.
Por esta razo, as organizaes pequenas acabam por no usar nenhum
processo. Isto pode trazer efeitos negativos no que diz respeito a
qualidade do produto final, alm de dificultar a entrega do software nos
prazos, custos e funcionalidades previamente definidas.

2. Metodologias geis e o Manifesto gil

A expresso Metodologias geis tornou-se conhecida em 2001, quando

especialistas em processos de desenvolvimento de software
representando entre outros, os mtodos Scrum e Extreme Programming
(XP), foram estabelecidos princpios e caractersticas comuns destes
mtodos. Assim foi criada a Aliana gil e efetuou-se o estabelecimento
do Manifesto gil.

2. 1 Extreme Programming (XP):

A Extreme Programming (XP) uma Metodologia gil para equipes
pequenas e mdias que desenvolvem software baseado em requisitos
vagos e que se modificam rapidamente. Entre as principais diferenas da
XP em relao s Metodologias Clssicas esto o feedback constante, a
abordagem incremental e o encorajamento da comunicao entre as
pessoas.
A maioria das regras da XP causa surpresa no primeiro contato e muitas
no fazem sentido se aplicadas isoladamente. a fora de seu conjunto
que sustenta o sucesso da XP, trazendo uma verdadeira revoluo no
desenvolvimento de software.
O principal objetivo da XP dar agilidade ao desenvolvimento do projeto e
busca garantir a satisfao do cliente. As prticas, regras, e os valores da
XP garantem um agradvel ambiente de desenvolvimento de software
para os seus seguidores.

3. Valores de qualidade
Qualidade de Software segundo A NBR ISO/IEC 9126-1
Funcionalidade (Satisfao das Necessidades)
Confiabilidade (Imunidade a Falhas)
Usabilidade (Facilidade de Uso)
Eficincia (Rpido e "Enxuto")
Manutenibilidade (Facilidade de Manuteno)

Portabilidade (Uso em outros Ambientes)

3.1

Custo da Qualidade de Software

A qualidade no totalmente algo que podemos obter de forma

gratuita. Para tanto, investimentos financeiros, treinamentos,
softwares e outras iniciativas precisam ser realizadas em adio
para a busca da qualidade de software como um todo.
Segundo Barti (2002), "Um dos maiores desafios a ser
considerados estabelecer um modelo de custos relacionados a
implantao de um processo de garantia da qualidade de
software." (BARTI, 2002, p. 29)
No modelo apresentado, Barti (2002) prope a criao de duas
categorias separadas para os custos relacionados a conformidade
e o custo da no-conformidade:
Custo da Deteco de Defeitos: Pode-se aqui fazer claramente
referncias para o termo controle da qualidade, ou seja, o foco est
exatamente no produto. As atividades aqui realizadas so orientadas ao
produto desenvolvido, e estas incluem:

Revises de requisitos;
Revises de Modelagem;
Revises de Planos de Teste;
Inspees de cdigo;
Testes de Software.

1. Custo da Preveno de Defeitos: Assim como deteco de

defeitos est associada ao controle da qualidade, a preveno de
defeitos est associada a garantia da qualidade, ou seja, o foco est

exatamente no processo. As atividades aqui realizadas so

orientadas ao processo, e estas incluem:
Definio de Metodologias;
Treinamentos;
Ferramentas de apoio ao processo de desenvolvimento;
Definio de Polticas;
Procedimentos;
Padres;
Especificaes e convenes;
Planejamento do SQA;
Relatrios de Qualidade para melhoria de processo.
2. Custo da No-Conformidade: Por outro lado, o custo da noconformidade est relacionado s perdas que o projeto ter, no
optando pela deteco e preveno de defeitos:
''Re-revises'';
Re-testes;
Correes de cdigo-fonte e documentao muito
constantes;
Reestruturao;
Redistribuio das verses do software;
Atrasos no cronograma;
Falhas na produo.
Com isso, "O modelo apresentado dever ser associado a todas as
atividades de um processo de engenharia de software. Em todos os
projetos a serem construdos ou modificados, todas as atividades
deveriam ter uma poltica de alocao de custos semelhante ao modelo
apresentado." (BARTI, 2002, p. 29)

Captulo 4
4. Qualidade do processo versus qualidade da produo
Um dos principais motivos para que organizaes de software adotem
uma viso de melhoria contnua de seus processos o fato da qualidade
do produto final depender diretamente da qualidade do processo de
software adotado.
Uma parte importante da melhoria de processos a avaliao de
processos. A avaliao sistemtica da qualidade de um processo, de seus
ativos (atividades, ferramentas, procedimentos etc) e de seus produtos
resultantes essencial para apoiar a implementao de estratgias de

melhoria.
Dada a amplitude e complexidade do processo de Avaliao e Melhoria do
Processo (AMP) e as fortes relaes com outros processos, com destaque
para a medio, prover apoio automatizado a esse processo requer,
geralmente, diversas ferramentas.
A crescente demanda por produtos de software com alto grau de atendimento aos
requisitos do cliente e que apresentem melhores resultados em termos de prazo,
custo e qualidade dos produtos/servios tem motivado organizaes do mundo
inteiro a adotarem modelos de maturidade. Esses modelos tm como premissa que
a qualidade do produto dependente da qualidade do processo no qual ele
desenvolvido, por essa razo o foco desses modelos o processo. A essncia dos
modelos definir uma trilha aonde se estabelecem nveis de maturidade para que a
empresa os percorra rumo a qualidade. Essa trilha passa de um estado de produo
artesanal para o industrial com uma produo efetiva e profissional.

Um desses modelos de maturidade o MPS.Br que foi criado no Brasil em 2002

com o intuito de melhorar a qualidade dos processos e produtos da indstria
nacional.
O uso de um modelo de maturidade permite que uma organizao tenha seus
mtodos e processos avaliados de acordo com as boas prticas em gerenciamento
e com um conjunto de parmetros externos.
O mais conhecido o
Capability Maturity Model Integration
Software Engineering Institute - SEI.

(CMMi), do

O CMMI pode ser organizado atravs de duas formas: Contnua e estagiada. Pelo
modelo estagiado, mais tradicional e mantendo compatibilidade com o CMM, uma
organizao pode ter sua maturidade medida em 5 nveis:
Nvel 1 - Inicial (Ad hoc):
Ambiente instvel. O sucesso depende da
competncia de funcionrios e no no uso de processos estruturados;
Nvel 2 - Gerenciado:
Capacidade de repetir sucessos anteriores pelo
acompanhamento de custos, cronogramas e funcionalidades;
Nvel 3 - Definido:

O processo de desenvolvimento de software bem

definido, documentado e padronizado a nvel organizacional;

Nvel 4 - Gerenciado quantitativamente:
Realiza uma gerncia quantitativa
do processo de software e do produto por meio de mtricas adequadas;
Nvel 5 - Em otimizao:
Usa a informao quantitativa para melhorar
continuamente e gerenciar o processo de desenvolvimento. At maro/2012,
no Brasil, h somente 13 empresas neste nvel.3
O (MPS.BR), ou Melhoria de Processos do Software Brasileiro,
simultaneamente um movimento para a melhoria e um modelo de
qualidade de processo voltada para a realidade do mercado de pequenas
e mdias empresas de desenvolvimento de software no Brasil. O MPS.BR
contempla 7 nveis de maturidade, de A a G, sendo a primeira o mais
maduro. At agosto/2012, no Brasil, h somente 2 empresas neste nvel.4
Enfatiza-se, dentro do MPS-BR, o uso das principais abordagens internacionais voltadas para
a definio, a avaliao e a melhoria dos processos de software. Tal fato torna o MPS-BR
compatvel inclusive com as prticas do CMMI. H ainda no MPS-BR uma estrutura de
nveis de maturidade, de forma similar quela existente dentro do CMMI.
Os diferentes nveis de maturidade do MPS-BR constituem um meio para indicar qual o nvel
da empresa que se est considerando. Cada classificao possvel atesta, assim, diferentes
graus no controle de processos e qual a qualidade que se pode esperar da organizao que a
detm.

A seguir esto listados os 7 nveis de maturidade previstos pelo MPS-BR:

A Em Otimizao: h a preocupao com questes como inovao e anlise de causas.
B Gerenciado Quantitativamente: avalia-se o desempenho dos processos, alm da
gerncia quantitativa dos mesmos.
C Definido: aqui ocorre o gerenciamento de riscos.
D Largamente Definido: envolve verificao, validao, alm da liberao, instalao e
integrao de produtos, dentre outras atividades.
E Parcialmente Definido: considera processos como treinamento, adaptao de
processos para gerncia de projetos, alm da preocupao com a melhoria e o controle
do processo organizacional.
F Gerenciado: introduz controles de medio, gerncia de configurao, conceitos sobre
aquisio e garantia da qualidade.
G Parcialmente Gerenciado: neste ponto inicial deve-se iniciar o gerenciamento de

requisitos e de projetos.
A certificao MPS-BR tambm tem sido solicitada em licitaes governamentais. Logo,
empresas interessadas em participar de projetos conduzidos por rgos do governo podem se
utilizar desta metodologia para ampliar seu ramo de atuao.
Pode-se considerar ainda o MPS-BR como uma importante alternativa ao CMMI em
organizaes de mdio e pequeno porte. Isto se justifica em virtude do alto investimento
financeiro que o CMMI representa, o que torna o mesmo mais indicado s grandes empresas
de desenvolvimento.

Modelos de processo de software

Um modelo de processo de desenvolvimento de software, ou simplesmente
modelo de processo, pode ser visto como uma representao, ou
abstrao dos objetos e atividades envolvidas no processo de software.
Alm disso, oferece uma forma mais abrangente e fcil de representar o
gerenciamento de processo de software e consequentemente o progresso
do projeto.
Exemplos de alguns modelos de processo de software;
Modelos ciclo de vida
Sequencial ou

Cascata

(do ingls

waterfall) - com fases distintas de

especificao, projeto e desenvolvimento.

Desenvolvimento iterativo e incremental
- desenvolvimento iniciado
com um subconjunto simples de
Requisitos de Software
e
iterativamente alcana evolues subsequentes das verses at o
sistema todo estar implementado
Evolucional ou
Prototipao
- especificao, projeto e
desenvolvimento de
prottipos.
V-Model - Parecido com o modelo cascata, mas com uma organizao melhor,
que permite que se compare com outros modelos mais modernos.
Espiral
- evoluo atravs de vrios ciclos completos de
especificao, projeto e desenvolvimento.
Captulo 5

5.Garantia de qualidade de software

A qualidade pode ser medida atravs do grau de satisfao em que as
pessoas avaliam determinado produto ou servio. No entanto, esse
produto ou servio pode ter qualidade para algumas pessoas e para
outras nem tanto, ou seja, a qualidade algo subjetivo.
O termo TQM (Total Quality Management), amplamente usado nas
organizaes, tambm descreve uma abordagem para a melhoria da
qualidade. De acordo com Kan (2002), "O termo tem tomado vrios
significados, dependendo de quem interpreta e como se aplica." (KAN,
2002, p. 30). Independente dos seus vrios tipos de implementao, os
elementos chave do TQM podem ser resumidos conforme abaixo:
Foco do Cliente (Customer Focus) - O objetivo atingir a satisfao total
do cliente. O foco do cliente inclui o estudo das necessidades e vontades
do cliente, coleta de requisitos do cliente e a medio e gerenciamento da
satisfao do cliente.

Melhoria de Processo (Process Improvement) - O objetivo reduzir as

variaes de processo e atingir a melhoria da qualidade contnua.
Este elemento inclui ambos os processos de negcio e o processo de
desenvolvimento do produto. Atravs da melhoria de processo, a
qualidade do produto ser reforada.

Segundo ainda a NBR ISO 8402, o conceito de qualidade "A totalidade

das caractersticas de uma entidade que lhe confere a capacidade de
satisfazer s necessidades explcitas e implcitas". As necessidades
explcitas so aquelas expressas na definio formal de requisitos
propostos pelo cliente. Esses requisitos definem as condies em que o
produto ou servio devem ser utilizados bem como seus objetivos, funes
e o desempenho esperado. J as necessidades implcitas so aquelas que,
embora no expressas pelo cliente nos documentos de requisitos, so
necessrias para o usurio. Esto includos nessas classes tanto os
requisitos que no precisam ser declarados por serem bvios como
aqueles requisitos que no so percebidos como necessrios no momento
que o produto foi desenvolvido, mas que pela gravidade de suas
conseqncias devem ser atendidos.

Diante dessa complexidade na definio da palavra qualidade, Pressman

(2005) sugere que a qualidade de software seja implementada e no
somente uma idia ou desejo que uma organizao venha a ter. Para
tanto, Pressman (2005) faz as seguintes colocaes sobre qualidade de
software:
"Definir explicitamente o termo qualidade de software, quando o
mesmo dito";(PRESSMAN, 2005, p. 193)
"Criar um conjunto de atividades que iro ajudar a garantir que cada
produto de trabalho da engenharia de software exiba alta qualidade";
(PRESSMAN, 2005, p. 193)
"Realizar atividades de segurana da qualidade em cada projeto de
software";(PRESSMAN, 2005, p. 193)
"Usar mtricas para desenvolver estratgias para a melhoria de
processo de software e, como conseqncia, a qualidade no produto
final"; (PRESSMAN, 2005, p. 193)

Captulo 6
6.Verificao e validao
Sistemas possuem restries de qualidade e confiabilidade Qualidade de
sw: satisfao dos requisitos funcionais, de desempenho e normas
explicitamente declarados. Reduo de custos e aumento da qualidade
e confiabilidade nos processo e produto de sw Estima-se que 40% a
50% do esforo de desenvolvimento de sistemas so empregados em
atividades de verificao e validao.
Em Engenharia de Software (IEEE 1012): Validao: estamos
construindo o produto certo? o software faz o que o usurio requisitou?
Verificao: estamos construindo o produto corretamente? o
software est de acordo com sua especificao?''
Validao: Confirmar por testes e com provas objetivas que
requisitos particulares para um determinado uso foram cumpridos.
Busca provar que o software implementa cada um dos requisitos
corretamente e completamente ou seja, tenta responder pergunta: O
produto correto foi construdo?
Verificao: Confirmar por testes e com provas objetivas que requisitos
especificados foram cumpridos. Visa garantir que os produtos de uma
dada fase implementam em sua totalidade as entradas para aquela fase,

ou seja, tenta responder pergunta: O produto foi construdo

corretamente?

Existem duas tcnicas fundamentais de verificao de software:

Dinmica: implica em execuo do cdigo=> TESTES; Esttica: anlises
e inspees sem execuo do cdigo
Teste de software
O
teste do software
a
investigao
do
software
a fim de
fornecer informaes sobre sua
qualidade
em relao ao contexto em que ele
deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.
O teste um processo realizado pelo testador de software, que permeia outros
processos da
engenharia de software, e que envolve aes que vo do
levantamento de requisitos
at a execuo do teste propriamente dito.
O teste de software pode ser visto como uma parcela do processo de
qualidade
de software. A qualidade da aplicao pode e, normalmente, varia
significativamente de sistema para sistema.
Os atributos qualitativos previstos na norma

ISO 9126

so:

Funcionalidade
Confiabilidade
Usabilidade
Eficincia
Manutenibilidade
Portabilidade
De forma geral, mensurar o bom funcionamento de um software envolve compar-lo
com elementos como especificaes, outros softwares da mesma linha, verses
anteriores do mesmo produto, inferncias pessoais, expectativas do cliente, normas
relevantes, leis aplicveis, entre outros. Enquanto a especificao do software diz
respeito ao processo de verificao do software, a expectativa do cliente diz respeito
ao processo de validao do software. Por meio da verificao ser analisado se o
produto foi feito corretamente, se ele est de acordo com os requisitos
especificados. Por meio da validao ser analisado se foi feito o produto correto, se
ele est de acordo com as necessidades e expectativas do cliente.

Tcnicas[editar

editar cdigo-fonte]

Existem muitas maneiras de se testar um software. Mesmo assim, existem as

tcnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre
linguagens estruturadas
que ainda hoje tm grande valia para os sistemas
orientados a objeto. Apesar de os
paradigmas de desenvolvimento
serem
completamente diferentes, o objetivo principal destas tcnicas continua a ser o
mesmo, encontrar falhas no software. Abaixo esto descritas algumas das tcnicas
mais conhecidas.
Caixa-branca[editar
Ver artigo principal:

editar cdigo-fonte]
teste de caixa-branca

Tambm chamada de teste estrutural ou orientado lgica, a tcnica de caixabranca avalia o comportamento interno do
componente de software. Essa
tcnica trabalha diretamente sobre o
cdigo fonte
do componente de
software para avaliar aspectos tais como: teste de condio,
teste de fluxo de
dados, teste de ciclos, teste de caminhos lgicos, cdigos nunca
executados.
Caixa-preta[editar
|
editar cdigo-fonte]
Ver artigo principal:
Teste de caixa-preta
Tambm chamada de teste funcional, teste comportamental, orientado a dado ou
orientado a
entrada e sada, a tcnica de caixa-preta avalia o
comportamento externo docomponente de software, sem se considerar o
comportamento interno do mesmo.4
Dados de entrada so fornecidos, o
teste executado e o resultado obtido comparado a um resultado esperado
previamente conhecido. Como detalhes de implementao no so considerados,
os
casos de teste
so todos derivados da especificao.
Quanto mais entradas so fornecidas, mais rico ser o teste. Numa situao ideal
todas as entradas possveis seriam testadas, mas na ampla maioria dos casos isso
impossvel.5
Outro problema que a especificao pode estar ambgua em
relao ao sistema produzido, e como resultado as entradas especificadas podem
no ser as mesmas aceitas para o teste.6
Uma abordagem mais realista para o
teste de caixa-preta escolher um subconjunto de entradas que maximize a riqueza
do teste. Pode-se agrupar subconjuntos de entradas possveis que so processadas
similarmente, de forma que testar somente um elemento desse subconjunto serve
para averiguar a qualidade de todo o subconjunto. Por exemplo, em um sistema que
aceita um
inteiro
como entrada, testar todos os casos possveis pode gerar
pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da
especificao do sistema, pode-se encontrar um subconjunto de inteiros que
maximizem a qualidade do teste. Depende do propsito do sistema, mas casos
possveis incluem inteiros pares, inteiros mpares, zero, inteiros positivos, inteiros

negativos, o maior inteiro, o menor inteiro.

Caixa-cinza[editar

editar cdigo-fonte]

A tcnica de teste de caixa-cinza uma mescla do uso das tcnicas de caixa-preta e

de caixa-branca. Isso envolve ter acesso a
estruturas de dados
e
algoritmos
do componente a fim de desenvolver os casos de teste, que so
executados como na tcnica da caixa-preta. Manipular entradas de dados e formatar
a sada no considerado caixa-cinza pois a entrada e a sada esto claramente
fora da caixa-preta. A caixa-cinza pode incluir tambm o uso de
engenharia
reversa
para determinar por exemplo os limites superiores e inferiores das
classes, alm de mensagens de erro.
Teste de unidade[editar
|
editar cdigo-fonte]
Ver artigo principal:
teste de unidade
Tambm conhecida como teste unitrio ou teste de mdulo, a fase em que se
testam as menores unidades de software desenvolvidas (pequenas partes ou
unidades do sistema).10
O universo alvo desse tipo de teste so as
subrotinas, mtodos, classes ou mesmo pequenos trechos de cdigo.
Assim, o objetivo o de encontrar falhas de funcionamento dentro de uma
pequena parte do sistema funcionando independentemente do todo.
Teste de integrao[editar
|
editar cdigo-fonte]
Ver artigo principal:
teste de integrao
Na fase de teste de integrao, o objetivo encontrar falhas provenientes da
integrao interna dos componentes de um sistema. Geralmente os tipos de falhas
encontradas so de transmisso de dados. Por exemplo, um componente A pode
estar aguardando o retorno de um valor X ao executar um mtodo do componente
B; porm, B pode retornar um valor Y, gerando uma falha. O teste de integrao
conduz ao descobrimento de possveis falhas associadas
interface do
sistema.No faz parte do escopo dessa fase de teste o tratamento de interfaces
com
outros
sistemas (integrao entre sistemas). Essas interfaces so
testadas na fase de teste de sistema, apesar de, a critrio do gerente de projeto,
estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente
construdo.
Teste de sistema[editar
|
editar cdigo-fonte]
Ver artigo principal:
teste de sistema
Na fase de teste de sistema, o objetivo executar o sistema sob ponto de vista de
seu usurio final, varrendo as funcionalidades em busca de falhas em relao aos
objetivos originais. Os testes so executados em condies similares de ambiente,
interfaces sistmicas e massas de dados quelas que um usurio utilizar no seu
dia-a-dia de manipulao do sistema. De acordo com a poltica de uma organizao,
podem ser utilizadas condies reais de ambiente, interfaces sistmicas e massas
de dados.

Teste de aceitao[editar
|
editar cdigo-fonte]
Ver artigo principal:
teste de aceitao
Geralmente, os testes de aceitao so realizados por um grupo restrito de usurios
finais do sistema, que simulam operaes de rotina do sistema de modo a verificar
se seu comportamento est de acordo com o solicitado. Teste formal conduzido para
determinar se um sistema satisfaz ou no seus critrios de aceitao e para permitir
ao cliente determinar se aceita ou no o sistema. Validao de um software pelo
comprador, pelo usurio ou por terceira parte, com o uso de dados ou cenrios
especificados ou reais. Pode incluir testes funcionais, de configurao, de
recuperao de falhas, de segurana e de desempenho.
Teste de operao[editar
|
editar cdigo-fonte]
Ver artigo principal:
teste de operao
Nessa fase o teste conduzido pelos administradores do ambiente final em que o
sistema ou software entrar em ambiente produtivo. Vale ressaltar que essa fase
aplicvel somente a sistemas de informao prprios de uma organizao, cujo
acesso pode ser feito interna ou externamente a essa organizao. Nessa fase de
teste devem ser feitas simulaes para garantir que a entrada em produo do
sistema ser bem sucedida. Envolve testes de instalao, simulaes com
cpia
de segurana
dos
bancos de dados, etc.. Em alguns casos um sistema
entrar em produo para substituir outro e necessrio garantir que o
novo sistema continuar garantindo o suporte ao negcio.
O Ciclo de Vida dos Testes[editar

editar cdigo-fonte]

O Ciclo de Vida dos Testes composto de 5 fases: Planejamento, Preparao,

Especificao, Execuo e Entrega.
Planejamento[editar

editar cdigo-fonte]

Nesta fase elaborada a Estratgia de Teste e o Plano de Teste.

Preparao[editar

editar cdigo-fonte]

O objetivo desta fase preparar o Ambiente de Teste (equipamentos, pessoal,

ferramentas de automao, massa de testes) para que os testes sejam executados
conforme planejados.
Especificao[editar

editar cdigo-fonte]

Nesta fase temos as seguintes atividades: Elaborar/ Revisar casos de testes e

Elaborar/ Revisar roteiros de testes.
Execuo[editar

editar cdigo-fonte]

Os testes so executados e os resultados obtidos so registrados.

Entrega
Esta a ltima fase do ciclo de vida de testes, onde o projeto finalizado e toda

documentao finalizada e arquivada.

Captulo 7
7.Revises e auditorias
O que o IEEE 1028?
Como todo padro elaborado pelo IEEE (l-se I trs E), o 1028 fruto do trabalho
voluntrio de alguns membros do IEEE. E sendo um padro, eles nos traz algumas
importantes e relevantes informaes a respeito de reviso de software. Mas sempre bom
lembrar, que ele deve ser usado com bom senso, pois o contexto sempre prevalece sob o
padro (ou deveria prevalecer).
O IEEE 1028 nos traz cinco tipos de reviso de software, junto com os procedimento
necessrios para a execua de cada tipo. Est fora do escopo do padro questes como:
quando uma reviso se faz necessria? como escolher qual tipo de reviso deve ser usado?
Os 5 tipos de reviso abordados so:

Revises gerenciais;

Revises tcnicas;

Inspees;

Walk-throughs;

Auditrias.
Os cinco tipos de reviso
Segue abaixo, a traduo do anexo B do padro, que contm uma tabela comparativa entre
os tipos de reviso (o texto original est numa linguagem meio chata de entender, e no
consegui melhorar muito na traduo se notarem algum erro ou melhoria, por favor me
avisem):

Caracterstica

Reviso
gerencial

Objetivo

Garantir o
progresso;
recomendar aes
corretivas;
garantir alocao
correta dos
recursos

Tomada de
deciso

A equipe de
gerenciamento

Reviso tcnica Inspeo

Avaliar a
conformidade do
estado atual com
as especificaes
e planos;
garantir
integridade da
mudana
A equipe de
reviso solicita

Encontrar
anomalias; verificar
decises; verificar
a qualidade do
produto

Walk-through

Auditria

Encontrar
anomalias;
examinar
alternativas;
melhorar o
produto; frum
para aprendizado

Avaliao
independente de
cumprimento com
os objetivos de
padres e
regulamentos

A equipe de reviso A equipe

Organizao
escolhe as
concorda com as auditada, iniciador,

traa o curso da
ao; decises
so feitas na
reunio ou como
resultado das
recomenda-es
O lder verifica
que itens so
fechados; a
Verificao das verificao das
mudanas
mudanas
deixada para
outros controles
do projeto
Tamanho
Duas ou mais
recomendado
pessoas
do grupo
Gerentes,
liderena tcnica
Quem participa e algumas
pessoas de outras
reas
Normalmente o
Grupo da
gerente
liderana
responsvel
Moderado para
Volume de
muito, depende
materiais
dos objetivos da
reunio

aos gerentes ou
a liderana
tcnica que
atuem nas
recomendaes

disposies prdefinidas do
mudanas para
comprador, cliente
produto; os
serem feitas pelo
ou usurio
defeitos devem ser autor
removidos

O lder verifica
que itens so
fechados; a
verificao das
mudanas
deixada para
outros controles
do projeto

O lder verifica que

itens so fechados;
a verificao das
mudanas
deixada para
outros controles do
projeto

O lder verifica
que itens so
fechados; a
verificao das
mudanas
deixada para
outros controles
do projeto

Responsabili-dade
da organizao
auditada

Trs ou mais
pessoas

Trs a seis pessoas

Duas a sete
pessoas

Uma a sete
pessoas

Liderena
tcnica e
algumas pessoas
de outras reas

Pessoas da rea
com acompanhemento documentado

Auditores,
Liderena tcnica
organizao
e algumas
auditada, pessoal
pessoas de
de gerncia e
outras reas
tcnico

Normalmente o Um facilitador
engenheiro lder treinado

O facilitador ou o
O auditor lder
autor

Moderado para
muito, depende Relativa-mente
dos objetivos da baixo
reunio

Relativa-mente
baixo

Moderado para
muito, depende dos
objetivos da
reunio