1

TESTE DE SOFTWARE

1- INTRODUO

Teste de software o processo de execuo de um produto para determinar se ele atingiu
suas especificaes e funcionou corretamente no ambiente para o qual foi projetado. O seu
objetivo revelar falhas em um produto, para que as causas dessas falhas sejam identificadas e
possam ser corrigidas pela equipe de desenvolvimento antes da entrega final.
O conceito de teste de software pode ser compreendido atravs de uma forma simples,
testar um software significa analisar atravs de uma execuo planejada se o seu comportamento
corre de acordo com o especificado. O objetivo principal desta tarefa descobrir o maior nmero
possvel de falhas dispondo do mnimo de esforo, ou seja, mostrar aos desenvolvedores se os
resultados esto ou no de acordo com os padres estabelecidos.
Falar de testes de software muito mais do que falar de execuo de testes. Testar um
software e relatar impresses e no conformidades fornecer um diagnstico do estado da
aplicao, e muito importante que esse diagnstico seja o mais completo e preciso possvel,
porque ele provavelmente vai servir de base para tomadas de decises em relao ao projeto que
est sendo analisado. Testar uma aplicao question-la, atravs de casos de teste e
principalmente de observaes, para analisar as respostas obtidas, pois estas podem revelar
defeitos.

Podemos entender por defeito tudo o que ameaa a qualidade do produto, levando em
considerao que qualidade o que o cliente quer. E o que o cliente quer relativo, porque vai
depender da finalidade da aplicao a ser desenvolvida. Por exemplo, uma aplicao pode estar
em conformidade com a documentao de requisitos e ainda assim o cliente achar que ela no
tem qualidade, pois apresenta demora em realizar determinada operao. Dependendo de onde a
aplicao ser utilizada, restries de tempo podem ser cruciais.
No se pode garantir que todo software funcione corretamente, sem a presena de erros,
visto que os mesmos muitas vezes possuem um grande nmero de estados com frmulas,
atividades e algoritmos complexos. O tamanho do projeto a ser desenvolvido e a quantidade de
2

pessoas envolvidas no processo aumentam ainda mais a complexidade. Idealmente, toda
permutao possvel do software deveria ser testada. Entretanto, isso se torna impossvel para a
ampla maioria dos casos devido quantidade impraticvel de possibilidades. Falhas podem ser
originadas por diversos motivos. Por exemplo, a especificao pode estar errada ou incompleta,
ou pode conter requisitos impossveis de serem implementados, devido a limitaes de hardware
ou software. A implementao tambm pode estar errada ou incompleta, como um erro de um
algoritmo. Portanto, uma falha o resultado de um ou mais defeitos em algum aspecto do
sistema.
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.
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, 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.








3


2- REFERENCIAL TERICO
De acordo com Melissa Pontes (2009), a qualidade de um software pode estar fortemente
relacionada existncia de defeitos inseridos durante o desenvolvimento ou manuteno de um
produto. Uma das maneiras de identificar os defeitos de uma aplicao de forma que eles possam
ser corrigidos atravs das atividades de teste de software. Devido sua importncia e
complexidade, testes de software podem ser responsveis por uma parcela considervel dos
custos de um projeto, por isso, esse assunto merece ateno por parte das organizaes que
desejam sucesso com a conduo das atividades do processo de testes.
Segundo Myers (2004), h princpios primordiais para o teste de software. O caso de
teste deve definir a sada esperada, de forma a reduzir a interpretao do critrio de sucesso. A
sada da execuo do teste deve ser exaustivamente analisada. Os casos de teste devem verificar
no somente as condies invlidas de execuo, como tambm as condies vlidas. Outro
conceito apresentado utilizar pessoas e organizaes diferentes para a implementao e para a
verificao. A entidade de teste possui uma viso destrutiva do sistema, em busca de erros,
enquanto a entidade de programao possui uma viso construtiva, em busca da implementao
de uma especificao.
Myers tambm aborda o esforo para se construir casos de teste. Deve-se evitar testes
descartveis, pois a qualidade do teste piora gradualmente com as iteraes de desenvolvimento.
Em contrapartida, h o teste de regresso, que permite quantificar a evoluo da qualidade de
software, mantendo e executando novamente testes realizados anteriormente.
O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a
probabilidade de existncia de erros num certo trecho de cdigo proporcional quantidade de
erros j encontrada anteriormente. Basicamente, erros aparecem em grupos. Trechos especficos
de cdigo de um software qualquer esto mais propensos a ter erros que outros.



4


3- DESENVOLVIMENTO
3.1- VISO GERAL NA UTILIZAO DOS TESTES DE SOFTWARE

No se pode garantir que todo software funcione corretamente, sem a presena de erros,
visto que os mesmos muitas vezes possuem um grande nmero de estados com frmulas,
atividades e algoritmos complexos. O tamanho do projeto a ser desenvolvido e a quantidade de
pessoas envolvidas no processo aumentam ainda mais a complexidade. Idealmente, toda
permutao possvel do software deveria ser testada. Entretanto, isso se torna impossvel para a
ampla maioria dos casos devido quantidade impraticvel de possibilidades. A qualidade do
teste acaba se relacionando qualidade dos profissionais envolvidos em filtrar as permutaes
relevantes.
Falhas podem ser originadas por diversos motivos. Por exemplo, a especificao pode
estar errada ou incompleta, ou pode conter requisitos impossveis de serem implementados,
devido a limitaes de hardware ou software. A implementao tambm pode estar errada ou
incompleta, como um erro de um algoritmo. Portanto, uma falha o resultado de um ou mais
defeitos em algum aspecto do sistema.
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
5

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.
Um desenvolvimento de software organizado tem como premissa uma metodologia de trabalho.
Esta deve ter como base conceitos que visem a construo de um produto de software de forma
eficaz. Dentro desta metodologia esto definidos os passos necessrios para chegar ao produto
final esperado.

3.2- TCNICAS
Existem vrias 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. Segue abaixo algumas das tcnicas mais conhecidas.
Tcnica Estrutural (Teste caixa-branca)
Tcnica de teste que avalia o comportamento interno do componente de software (Figura
1). 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 e teste de
caminhos lgicos (PRESSMAN, 2005)

Figura 1. Tcnica de Teste Estrutural.
Os aspectos avaliados nesta tcnica de teste dependero da complexidade e da tecnologia
que determinarem a construo do componente de software, cabendo, portanto, avaliao de
6

outros aspectos alm dos citados anteriormente. O testador tem acesso ao cdigo fonte da
aplicao e pode construir cdigos para efetuar a ligao de bibliotecas e componentes.
Este tipo de teste desenvolvido analisando-se o cdigo fonte e elaborando-se casos de teste que
cubram todas as possibilidades do componente de software. Dessa maneira, todas as variaes
originadas por estruturas de condies so testadas. A Listagem 1 apresenta um cdigo fonte,
extrado de (BARBOSA et al., 2000) que descreve um programa de exemplo que deve validar
um identificador digitado como parmetro, e a Figura 2 apresenta o grafo de programa extrado
a partir desse cdigo, tambm extrado de (BARBOSA et al., 2000). A partir do grafo deve ser
escolhido algum critrio baseado em algum algoritmo de busca em grafo (exemplo: visitar todos
os ns, arcos ou caminhos) para gerao dos casos de teste estruturais para o programa
(PFLEEGER, 2004).
Listagem 1. Cdigo fonte do programa identifier.c (BARBOSA et al., 2000)
/* 01 */ {
/* 01 */ char achar;
/* 01 */ int length, valid_id;
/* 01 */ length = 0;
/* 01 */ printf ("Digite um possvel identificador\n");
/* 01 */ printf ("seguido por <ENTER>: ");
/* 01 */ achar = fgetc (stdin);
/* 01 */ valid_id = valid_starter (achar);
/* 01 */ if (valid_id)
/* 02 */ length = 1;
/* 03 */ achar = fgetc (stdin);
/* 04 */ while (achar != '\n')
/* 05 */ {
/* 05 */ if (!(valid_follower (achar)))
/* 06 */ valid_id = 0;
/* 07 */ length++;
/* 07 */ achar = fgetc (stdin);
/* 07 */ }
/* 08 */ if (valid_id && (length >= 1) && (length < 6) )
/* 09 */ printf ("Valido\n");
/* 10 */ else
/* 10 */ printf ("Invalido\n");
/* 11 */ }

7


Figura 2. Grafo de Programa (BARBOSA et al., 2000).
Um exemplo bem prtico desta tcnica de teste o uso da ferramenta livre JUnit para
desenvolvimento de casos de teste para avaliar classes ou mtodos desenvolvidos na
linguagem Java. A tcnica de teste de Estrutural recomendada para os nveis de Teste da
Unidade e Teste da Integrao, cuja responsabilidade principal fica a cargo dos desenvolvedores
do software, que so profissionais que conhecem bem o cdigo-fonte desenvolvido e dessa forma
conseguem planejar os casos de teste com maior facilidade. Dessa forma, podemos auxiliar na
reduo dos problemas existentes nas pequenas funes ou unidades que compem um software.
Teste Funcional (Teste caixa-preta)
Tcnica de teste em que o componente de software a ser testado abordado como se
fosse uma caixa-preta, ou seja, no se considera o comportamento interno do mesmo (Figura 3).
Dados de entrada so fornecidos, o teste executado e o resultado obtido comparado a um
resultado esperado previamente conhecido. Haver sucesso no teste se o resultado obtido for
igual ao resultado esperado. O componente de software a ser testado pode ser um mtodo, uma
funo interna, um programa, um componente, um conjunto de programas e/ou componentes ou
mesmo uma funcionalidade. A tcnica de teste funcional aplicvel a todos os nveis de teste
(PRESSMAN, 2005).

8


Figura 3. Tcnica de Teste Funcional.
Essa tcnica aplicvel a todas as fases de teste teste unitrio, teste de integrao, teste de
sistema e teste de aceitao. A aplicao de critrios de teste leva o testador a produzir um
conjunto de casos de teste (ou situaes de teste).
Caixa-cinza
A tcnica de teste de caixa-cinza um mesclado 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.
Regresso
Essa uma tcnica de teste aplicvel a uma nova verso de software ou necessidade de
se executar um novo ciclo de teste durante o processo de desenvolvimento. Consiste em se
aplicar, a cada nova verso do software ou a cada ciclo, todos os testes que j foram aplicados
nas verses ou ciclos de teste anteriores do sistema.
Tcnicas no funcionais
Outras tcnicas de teste existem para testar aspectos no-funcionais do software, como
por exemplo, a adequao a restries de negcio, adequao a normas, ou restries
tecnolgicas. Em contraste s tcnicas funcionais mencionadas acima, que verificam a produo
pelo sistema de respostas adequadas de suas operaes, de acordo com uma especificao, as
tcnicas no funcionais verificam atributos de um componente ou sistema que no se relacionam
com a funcionalidade (por exemplo, confiabilidade, eficincia, usabilidade, manutenibilidade e
portabilidade).
9

Uma delas o uso conjunto de teste de desempenho e teste de carga, que verifica se o software
consegue processar grandes quantidades de dados, e nas especificaes de tempo de
processamento exigidas, o que determina a escalabilidade do software. O teste de usabilidade
necessrio para verificar se a interface de usurio fcil de se aprender e utilizar. Entre
verificaes cabveis esto a relao da interface com conhecimento do usurio, a
compreensibilidade das mensagens de erro e a integridade visual entre diferentes
componentes. J o teste de confiabilidade usado para verificar se o software seguro em
assegurar o sigilo dos dados armazenados e processados. O teste de recuperao usado para
verificar a robustez do software em retornar a um estado estvel de execuo aps estar em um
estado de falha.
Uma prtica comum testar o software aps uma funcionalidade ser desenvolvida, e antes dela
ser implantada no cliente, por um grupo de profissionais diferente da implementao. Essa
prtica pode resultar na fase de teste ser usada para compensar atrasos do projeto,
comprometendo o tempo devotado ao teste. Outra prtica comear o teste no mesmo momento
que o projeto, num processo contnuo at o fim do projeto.
Em contrapartida, algumas prticas emergentes como a programao extrema e
o desenvolvimento gil focam o modelo de desenvolvimento orientado ao teste. Nesse processo,
os testes de unidade so escritos primeiro (TDD), por engenheiros de software. Antes da
implementao da unidade em questo, o teste falha. Ento o cdigo escrito, passando
incrementalmente em pores maiores dos casos de teste. Os testes so mantidos junto com o
resto do cdigo fonte do software, e geralmente tambm integra o processo de construo do
software.
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). Assim, o
objetivo o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema
funcionando independentemente do todo.
Teste de integrao
10

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. 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
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
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
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,
11

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.
Candidato a lanamento
Ultimamente, e principalmente na comunidade de software livre, comum utilizar o
termo candidato a lanamento (release candidate) para indicar uma verso que candidata a ser a
verso final, em funo da quantidade de erros encontradas. Tais verses so um passo alm do
teste beta, sendo divulgadas para toda a comunidade.

3.3- O CICLO DE VIDA DOS TESTES
O Ciclo de Vida dos Testes composto de 5 fases: Planejamento, Preparao,
Especificao, Execuo e Entrega.
Planejamento: Nesta fase elaborada a Estratgia de Teste e o Plano de Teste.
Preparao: 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: Nesta fase temos as seguintes atividades: Elaborar/ Revisar casos de testes e
Elaborar/ Revisar roteiros de testes.
Execuo: Os testes so executados e registrado os resultados obtidos.
Entrega: Esta a ltima fase do ciclo de vida de testes, onde o projeto finalizado e toda
documentao finalizada e arquivada.
O processo de teste de software pode produzir diversos artefatos. O caso de
teste geralmente consiste de uma referncia a um identificador ou requisito de uma
especificao, pr-condies, eventos, uma srie de passos a se seguir, uma entrada de dados,
uma sada de dados, resultado esperado e resultado obtido. A srie de passos (ou parte dela) pode
estar contida num procedimento separado, para que possa ser compartilhada por mais de um caso
de teste.
12

Um script de teste a combinao de um caso de teste, um procedimento de teste e os dados do
teste. Uma coleo de casos de teste chamada de suite de teste. Geralmente, ela tambm
contm instrues detalhadas ou objetivos para cada coleo de casos de teste, alm de uma
seo para descrio da configurao do sistema usado.
A especificao de teste chamada plano de teste.
3.4- PAPIS
Segue abaixo alguns dos papis que uma pessoa pode desenvolver num projeto de teste
de software. Uma pessoa pode acumular mais de um dos papis citados, de acordo com
caractersticas e restries de projetos de desenvolvimento de software nas quais estejam
inseridas. Nas fases de teste de unidade e de integrao, por exemplo, os papis de arquiteto de
teste e analista de teste podem ser assumidos pelo analista de sistemas do projeto; o papel de
testador pode ser assumido pelo programador ou por um segundo programador que atue num
processo de programao em pares. Na fase de teste de sistema, num contexto em que haja uma
equipe de teste independente, pode haver profissionais acumulando os papis de arquiteto de
teste, analista de teste e testador.
O lder (ou gerente) do projeto de testes a pessoa responsvel pela liderana de um projeto de
teste especfico, normalmente relacionado a um sistema de desenvolvimento, seja um projeto
novo ou uma manuteno. J o engenheiro (ou arquiteto) de teste o tcnico responsvel pelo
levantamento de necessidades relacionadas montagem da infraestrutura de teste, incluindo-se o
ambiente de teste, a arquitetura de soluo, as restries tecnolgicas, as ferramentas de teste.
tambm responsvel pela liderana tcnica do trabalho de teste e pela comunicao entre a
equipe de teste e a equipe de projeto (ou equipe de desenvolvimento).
O analista de teste o tcnico responsvel pela operacionalizao do processo de teste. Deve
seguir as orientaes do gerente de teste ou do arquiteto de teste para detalhar a forma de
execuo dos testes e as condies de teste necessrias. Tambm deve focar seu trabalho nas
tcnicas de teste adequadas fase de teste trabalhada. Tambm no campo de anlise, o analista
de ambiente o tcnico responsvel pela configurao do ambiente de teste e pela aplicao das
ferramentas necessrias para tal. Esse profissional deve ser especializado em arquiteturas de
13

soluo e nos sistemas operacionais e softwares de infraestrutura que regem o ambiente. Ele ser
responsvel por tornar disponvel o ambiente de teste.
O testador o tcnico responsvel pela execuo de teste. Ele deve observar as condies de
teste e respectivos passos de teste documentados pelo analista de teste e evidenciar os resultados
de execuo. Em casos de execues de teste mal-sucedidas, esse profissional pode tambm
registrar ocorrncias de teste (na maioria das vezes, defeitos) em canais atravs dos quais os
desenvolvedores tomaro conhecimento das mesmas e tomaro as providncias de correo ou
de esclarecimentos.
Por fim, o automatizador de teste o tcnico responsvel pela automao de situaes de
teste em ferramentas. Ele deve observar as condies de teste e respectivos passos de teste
documentados pelo analista de teste e automatizar a execuo desses testes na ferramenta
utilizada. Normalmente so gerados scripts de teste que permitam a execuo de ciclos de teste
sempre que se julgar necessrio, desde claro, que sejam garantidas as mesmas condies
iniciais do ciclo de teste (valores de dados, estados dos dados, estados do ambiente, etc..)
3.5- VALE A PENA GASTAR TEMPO TESTANDO?
Por que fazer hoje algo que se pode deixar para amanh? Esta filosofia aplicada ao teste
pode trazer conseqncias bastante graves. Problemas so inevitveis e o quanto antes forem
encontrados, melhor. Humanos no so infalveis e tm dificuldades de lidar com seus prprios
erros. Desenvolvedores de software no gostam de encontrar problemas em seus cdigos
cuidadosamente elaborados. Analistas de requisitos normalmente preferem ignorar a
possibilidade de que no tenham compreendido o que o cliente realmente precisa. Isto faz parte
da nossa natureza!
J que erros podem acontecer no desenvolvimento de um software, temos duas alternativas:
1) Os problemas no software sero descobertos pelos seus usurios, quando o software estiver
sendo usado; ou
2) Os desenvolvedores e testadores do software iro, por meio de um teste eficaz, identificar e
remover os problemas existentes no software antes de liber-lo para uso.
Nas duas alternativas citadas, problemas no software so identificados, mas na segunda podemos
evitar que os usurios sejam prejudicados. Esta opo muito mais interessante; at mesmo
14

porque corrigir um problema no software muito mais fcil e barato quando ele est sendo
desenvolvido do que quando ele j est em uso.

3.6- DESASTRES PROVOCADOS POR FALHAS DE SOFTWARE
Terminal sem comunicao, O sistema est fora do ar, voc pode voltar mais tarde?,
segmentation fault, O software MS-X terminou de forma anormal, deseja mandar um
relatrio?.
Certamente voc j se deparou alguma vez com problemas causados por falhas de software. Mais
do que inconvenientes estes eventos podem trazer conseqncias graves.
Software permeia o dia a dia das pessoas no mundo atual. Existem aplicaes em elevadores, em
aparelhos de TV, em automveis, em celulares, etc. Alm disso, existem tambm as aplicaes
consideradas crticas como software de controle de usinas nucleares, de apoio em aeronaves,
embutido em msseis e radares, controle de pacientes em hospitais, etc.
Devido a esta forte dependncia, a ocorrncia de algum problema em aplicaes de software,
pode levar a situaes de grandes financeiras e at mesmo perda de vidas humanas.
Exemplos:
Ariane: Exploso do foguete 40 segundos aps a decolagem;
Therac: Entre 1985 e 1987, 6 acidentes causando mortes por overdoses de radiao;
Denver airport: Atraso na abertura do aeroporto devido a erros no sistema automtico de
transporte de bagagens com perdas estimadas em US$360 Milhes;

3.7- 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
15

grau em que um conjunto de caractersticas inerentes a um produto, processo ou sistema cumpre
os requisitos inicialmente estipulados para estes.No desenvolvimento de software, a qualidade do
produto est diretamente relacionada qualidade do processo de desenvolvimento
1
, desta forma,
comum que a busca por um software de maior qualidade passe necessariamente por uma
melhoria no processo de desenvolvimento.Rodney Brooks, diretor do Laboratrio de Inteligncia
Artificial e Cincia da Computao do MIT, define qualidade como a conformidade aos
requisitos. Essa definio exige determinar dois pontos: I) o que se entende por conformidade; e
II) como so especificados - e por quem - os requisitos.

3.8- MODELOS DE QUALIDADE
CMMI
MPS.BR
ISO 9126
ISO 15504
ISO 12207















16







4- CONCLUSO

O teste de software uma das atividades mais custosas do processo de desenvolvimento
de software, pois pode envolver uma quantidade significativa dos recursos de um projeto. O rigor
e o custo associado a esta atividade dependem principalmente da criticalidade da aplicao a ser
desenvolvida. Diferentes categorias de aplicaes requerem uma preocupao diferenciada com
as atividades de teste.
Um ponto bastante importante para a viabilizao da aplicao de teste de software a utilizao
de uma infra-estrutura adequada. Realizar testes no consiste simplesmente na gerao e
execuo de casos de teste, mas envolvem tambm questes de planejamento, gerenciamento e
anlise de resultados. Apoio ferramental para qualquer atividade do processo de teste
importante como mecanismo para reduo de esforo associado tarefa em questo, seja ela
planejamento, projeto ou execuo dos testes. Aps ter sua estratgia de teste definida, tente
buscar por ferramentas que se encaixem na sua estratgia. Isso pode reduzir significantemente o
esforo de tal tarefa.
Alm disso, importante ressaltar que diferentes tipos de aplicaes possuem diferentes tcnicas
de teste a serem aplicadas, ou seja, testar uma aplicao web envolve passos diferenciados em
comparao aos testes de um sistema embarcado. Cada tipo de aplicao possui caractersticas
especificas que devem ser consideradas no momento da realizao dos testes.







17















REFERNCIAS

Artigo Engenharia de Software - Introduo a Teste de Software
PFLEEGER, S. L., Engenharia de Software: Teoria e Prtica, Prentice Hall- Cap. 08, 2004.
Revista Engenharia de Software Magazine n 11
Disponvel em: http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-
teste-de-software/8035#ixzz2wiwzkeYZ. Acesso em 28 de Maro de 2014
Disponvel em: http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-
teste-de-software/8035. Acesso em 05 de Maio de 2014
Disponvel em: http://www.sebrae.com.br/setor/tecnologia-da-informacao/o-setor/artigos-e-
publicacoes/9991-introducao-a-testes-de-software/BIA_9991. Acesso em 05 de Maio de
2014. Acesso em 16 de Maio de 2014
Disponvel em: http://www.softwarepublico.gov.br/5cqualibr/xowiki/Teste. Acesso em 16 de
Maio de 2014








18