O documento discute o cenário atual do desenvolvimento de software, onde muitos projetos não atendem às especificações dos clientes, ultrapassam prazos e custos. Isso ocorre devido à falta de qualidade nos processos e produtos. O texto também aborda a importância de se ter equipes de teste para validar os requisitos e garantir a satisfação do cliente.

1. DÉBONY SCHMIDT
A IMPORTÂNCIA DA QUALIDADE E TESTES DE SOFTWARE
Guarulhos
2011

2. DÉBONY SCHMIDT
A IMPORTÂNCIA DA QUALIDADE E TESTES DE SOFTWARE
Trabalho de conclusão de curso
apresentado à Faculdade Eniac,
referente ao curso de Sistemas de
Informação.
Prof. Neiva Coelho Marostica
Guarulhos
2011

3. Schmidt, Débony
A importância da Qualidade e Testes de Software. –
São Paulo, 2011.83f.
Trabalho de Conclusão de Curso – Faculdade
Eniac – Sistemas de Informação.
Orientador: Neiva Coelho Marostica

4. Aluno: Débony Schmidt
Título: A importância da Qualidade e Testes de Software
A banca examinadora dos Trabalhos de Conclusão em sessão pública realizada
em ____/____/______, considerou o(a) candidato(a):
( ) aprovado ( ) reprovado
1) Examinador(a)______________________________________________________
2) Examinador(a)______________________________________________________
3) Examinador(a)______________________________________________________

5. Dedicatória
Dedico este trabalho a Deus em primeiro
lugar e aos meus pais e irmã que sempre
estiveram ao meu lado e proporcionaram
toda a estrutura para alcançar meus
objetivos. Apoiando e incentivando meu
crescimento.

6. Agradecimentos
Agradeço aos meus familiares e amigos pelo
apoio. E agradeço também aos professores
Lúcio Luzetti, Neiva Coelho Marostica e Rita
de Cássia que me auxiliaram no
desenvolvimento deste trabalho.

7. “Se tivesse seis horas para
derrubar uma árvore, eu
passaria as primeiras quatro
horas afiando o machado”
(Abraham Lincoln)

8. Resumo
Este trabalho exibe conteúdo relevante sobre os problemas encontrados
atualmente nas empresas de desenvolvimento de software.
A maioria dos softwares implantados não estão atendendo as especificações
dos clientes, estão ultrapassando os prazos e custos previstos na definição do
projeto.
A principal causa destes problemas é a falta de qualidade nos processos e no
produto desenvolvido.
Ter um software criado com qualidade desde sua definição garante a
satisfação dos clientes, menor quantidade de erros e manutenções realizadas.
Para garantir esta qualidade é necessário possuir uma equipe de testes, que
será responsável por validar todos os processos e varrer o software verificando se
todos os requisitos foram atendidos sem apresentar nenhum erro.
O resultado deste investimento são produtos melhores com maior
confiabilidade e a equipe interagindo na busca de um produto satisfatório a todo
momento cumprindo com os objetivos definidos.
Palavras-Chave: Cenário Atual do Software, Qualidade de Software e Testes
de Software.

9. Abstract
This work displays relevant content on the problems encountered in today's
software development companies.
Most of the software deployed are not meeting customer specifications, are
beyond the time and cost provided in the project definition.
The main cause of these problems is the lack of quality in processes and
product development.
Having created a software quality since its definition ensures customer
satisfaction, fewer errors and maintenance carried out.
To ensure this quality is necessary to have a test team, who will be
responsible for validating all the software processes and sweep checking that all
requirements have been met without showing any error.
The results of this investment are better products with greater reliability and
staff interacting in pursuit of a satisfactory product at all times complying with the
defined objectives.
Keywords: Current Scenario Software, Software Quality and Software Testing.

10. Figuras
Figura 1 - Elementos chave do TQM Total Quality Management (Gestão da
Qualidade Total).......................................................................................................................8
Figura 2 - Pilares da Qualidade de Software.................................................................... 11
Figura 3 - Ciclo de desenvolvimento no qual qualidade resume-se a testes de
software .................................................................................................................................. 13
Figura 4 - Possíveis níveis de maturidade previstos no modelo CMM ........................ 15
Figura 5 - Esforço dedicado à correção de defeitos no desenvolvimento de software
................................................................................................................................................. 18
Figura 6 - Erros, defeitos e falhas ...................................................................................... 20
Figura 7 - Erro de código: "If" sem "End If"....................................................................... 21
Figura 8 - Exemplo de erro na especificação................................................................... 22
Figura 9 - Incidência de defeitos nas etapas de desenvolvimento ............................... 23
Figura 10 - Custo da Qualidade.......................................................................................... 24
Figura 11 - Regra 10 de Myers........................................................................................... 25
Figura 12 - Modelo de relacionamento entre desenvolvimento e testes ..................... 31
Figura 13 - Ponto de equilíbrio dos testes ........................................................................ 32
Figura 14 - Execução Testes Caixa Branca ..................................................................... 34
Figura 15 - Execução Teste Caixa Preta .......................................................................... 36
Figura 16 - Fases dos Testes ............................................................................................. 38
Figura 17 - Modelo IEEE STD 829-1998 .......................................................................... 41
Figura 18 - RUP – Caso de Uso......................................................................................... 43
Figura 19 - Fluxo dos Testes .............................................................................................. 49
Figura 20 - Documentos necessários para o processo de Teste ................................. 51
Figura 21 - Ferramenta Selenium ...................................................................................... 54
Figura 22 - Ferramenta BadBoy......................................................................................... 55
Figura 23 - Ferramenta Canoo WebTest .......................................................................... 56
Figura 24 - Ferramenta JMeter........................................................................................... 57
Figura 25 - Ferramenta TestLink........................................................................................ 58
Figura 26 - Ferramenta Bugzilla ......................................................................................... 59
Figura 27 - Ferramenta Mantis ........................................................................................... 60

11. Tabelas
Tabela 1 - Categorias dos Custos Operacionais da Função Qualidade ........................6

12. Sumário
1. Cenário Atual.....................................................................................................................3
2. Qualidade de Software ....................................................................................................7
2.1 Definição da Qualidade ............................................................................................7
2.2 Histórico da Qualidade .............................................................................................9
2.3 Gerenciando a Qualidade ..................................................................................... 10
2.3.1. Planejando a Qualidade................................................................................. 11
2.3.2. Garantia da Qualidade ................................................................................... 11
2.3.3. Controle da Qualidade ................................................................................... 12
2.4 Aplicando a Qualidade .......................................................................................... 12
2.5 CMM (Capability Maturity Model) ........................................................................ 14
2.5.1 Apresentação do CMM .................................................................................. 14
2.5.2 Impacto da Maturidade .................................................................................. 17
2.6 Qualidade e Defeitos ............................................................................................. 18
2.6.1 Erro, Defeito e Falha ...................................................................................... 19
2.6.2 Bug .................................................................................................................... 20
2.7 O custo da qualidade............................................................................................. 23
2.8 A Garantia da Qualidade de Software (GQS) ................................................... 25
3. Testes de Software........................................................................................................ 27
3.1 Fundamentos de Teste ......................................................................................... 27
3.2 Pré-conceitos dos testes....................................................................................... 28
3.3 A importância dos Testes ..................................................................................... 29
3.4 Princípios de Teste ................................................................................................ 31
3.5 Técnicas de Teste.................................................................................................. 32
3.5.1 Testes de Caixa Branca................................................................................. 33
3.5.2 Testes de Caixa Preta .................................................................................... 35
3.5.3 Testes de Caixa Cinza ................................................................................... 37
3.6 Estágios dos Testes............................................................................................... 38
3.6.1 Teste de Unidade............................................................................................ 38
3.6.2 Teste de Integração........................................................................................ 38
3.6.3 Teste de Sistema ............................................................................................ 39
3.6.4 Teste de Aceitação......................................................................................... 39
3.7 Elaboração dos Testes.......................................................................................... 39

13. 3.7.1 Documentação dos Testes............................................................................ 39
3.7.2 Plano de Casos de Teste .............................................................................. 41
3.8 Execução dos Testes ............................................................................................ 48
3.9 Relatórios de Teste................................................................................................ 50
3.10 Ferramentas de Teste........................................................................................ 53
Considerações Gerais.......................................................................................................... 61
Referências............................................................................................................................ 62
Meios Impressos ............................................................................................................... 62
Meios Digitais..................................................................................................................... 62
TERMO DE COMPROMISSO E RESPONSABILIDADE............................................... 70

14. 1
Introdução
O presente trabalho apresentará o resultado de estudos sobre A importância
dos Testes de Software.
O tema foi escolhido por atuar na área de testes e verificar a falta de
conhecimento de equipes de Tecnologia da Informação sobre o assunto e também
pelo interesse de divulgar e expandir o trabalho das equipes de Qualidade.
Será apresentado neste trabalho o impacto positivo nos softwares produzidos
com qualidade que como resultado obtém a satisfação dos Clientes a redução de
custos com correções e trabalhos e maior confiança no produto produzido.
O objetivo principal é entender que um software pronto não é apenas um
software entregue e sim um software com garantia de qualidade.
Atualmente as empresas de desenvolvimento de software estão com o foco
voltado ao Planejamento do que será desenvolvido e se cumprirão com os prazos e
custos previstos. E os resultados obtidos nem sempre estão sendo satisfatórios, o
número de projetos que não atendem ao planejamento aumentou significadamente e
os motivos mais impactantes são requisitos e especificações do Cliente que não são
atendidos, falhas geradas durante o desenvolvimento e após a implantação e custos
maiores que o orçamento.
Após a implantação de um software, se o mesmo apresentar problemas e
divergências nas informações o custo realizado será maior do que o previsto, e os
prejuízos serão acumulados tanto para o Cliente quanto para a Empresa.
O prejuízo gerado para o Cliente é de ter investido em um projeto pronto a ser
entregue na data acordada, porém, este prazo é prorrogado quando erros são
encontrados. E para a Empresa o prejuízo é de ter gastos maiores com retrabalho,
alocar equipes para a correção sendo que poderiam estar dando andamento a

15. 2
outros projetos e arcar com os custos, pois, após a data acordada com o Cliente ser
ultrapassada o mesmo passa a não ter mais responsabilidade sobre os gastos
gerados.
Estudos demonstram que softwares sem qualidade além de não
compensarem o esforço aplicado, tornam-se softwares sem confiabilidade na
informação e com grande possibilidade de ao passar do tempo não serem mais úteis
para o objetivo determinado.
Para garantir a qualidade de um software empresas de Tecnologia passaram
a investir em equipes de testes, demonstrando que o capital investido em pessoas
qualificadas para este trabalho reduz o custo investido em softwares “problemáticos”
e aumenta a satisfação do Cliente com os produtos entregues.
A equipe de testes é responsável por minimizar erros de desenvolvimento da
aplicação e garantir que o software a ser implantado atenda todas as especificações
exigidas pelo Cliente.
Para complementar estas afirmações a apresentação do tema será abordada
em quatro capítulos, que descrevemos a seguir:
O primeiro capítulo apresentará as considerações gerais sobre o cenário atual
das empresas de software e o motivo de apresentarem grande quantidade de falhas
após a implantação.
O segundo capítulo abordará a Qualidade de Software, todas as definições e
a importância de um produto final que atenda as necessidades do Cliente.
No terceiro capítulo o processo de teste será apresentado com todas as
especificações e formas de trabalho.
E para encerrar apresento minhas considerações finais.

16. 3
1. Cenário Atual
Os clientes atualmente estão se tornando mais exigentes com os softwares,
buscando projetos que atendam o planejamento de custos, prazos e qualidade. [1]
Muitas empresas (geralmente de médio e grande porte) contratam pessoas
em curto espaço de tempo para desenvolverem uma aplicação para o Cliente. O que
acontece em muitos casos é que ou a aplicação demora muito para ser entregue por
restrição de prazo e às vezes de custo, ou é entregue no prazo, porém, com a
restrição de qualidade afetada. [1]
As empresas estão buscando a tecnologia para reduzir custos e
ampliarem sua forma de atuação. Estão sofisticando seus sistemas
para tomar decisões cada vez mais complexas, com a intenção de
ganhar eficiência, eficácia e controle. Tudo isso pode ser observado
através de vários indicadores econômicos, como volume de negócios
feitos para indústria de software e hardware, proporção de horas de
profissionais diretamente ligados à tecnologia por total de horas de
profissionais, entre outros. [2]
Com esta cobrança do mercado atual por melhores tecnologias, a área de
desenvolvimento de software obteve um grande aumento em suas demandas,
porém, criados com pouca capacidade de sucesso. [3]
Um dos motivos para as empresas não atenderem as demandas de
softwares com qualidade é a própria falta dos processos de desenvolvimento serem
cumpridos corretamente. Muitas não entendem ou aplicam um processo de
engenharia de software da forma que deveriam, comprometendo o resultado dos
projetos que por muitas vezes falham ou até mesmo não são finalizados. (BARTIÉ,
2002)
Bartié demonstra resultados de um estudo americano sobre a realidade deste
mercado (é importante levar em consideração que os americanos são muito mais
exigentes e preparados do que o mercado nacional):

17. 4
 Mais de 30% dos projetos são cancelados antes de serem
finalizados.
 Mais de 70% dos projetos falham nas entregas das
funcionalidades esperadas.
 Os custos extrapolam em mais de 180% os valores originalmente
previstos.
 Os prazos excedem em mais de 200% os cronogramas originais.
Muitas empresas acreditam que a forma que utilizam para o desenvolvimento
funcionará sempre, não percebem que o processo tem avançado, e que para
obterem sucesso precisam adquirir um modelo de qualidade. [2]
A utilização de software de qualidade garante a segurança nas
transações, dos negócios, das pessoas envolvidas e mantém alta
disponibilidade dos serviços. Produtos e serviços são considerados
aceitáveis se apresentarem desempenho dentro de certos limites.
Muito se fala atualmente e muitos estudos confirmam, que os
scanners instalados em pontos-de-venda, nos supermercados, lojas
de departamentos e outros estabelecimentos registram preços
incorretos com um frequência que varia de 1% a 3%, em virtude de
erros na base de dados ou defeitos do scanner. Isso significa que
somente 97% dos preços estão corretos, o que não impede essas
empresas de continuarem operando normalmente. No entanto, na
área de software a coisa se complica. Ou o software funciona
corretamente ou é requerida uma ação de alteração para acertá-lo.
Qual empresa utilizaria um sistema de contabilidade que apresente
precisão de 97%? Dos softwares é sempre esperado desempenho
sem falhas. Manter a confiabilidade de desempenho em altíssimo
nível continua sendo um dos principais desafios da indústria de
software. [4]
Os softwares que são desenvolvidos sem atender as necessidades
especificadas pelo Cliente, ou que, ao serem implantados apresentem erros ou
inconsistências geram alto custo tanto para o Cliente quanto para a Empresa. O
custo arcado pelo Cliente é de pagar por um produto a ser entregue perfeitamente
em uma determinada data e não receber, ou de receber e ter de paralisar os
processos por falhas apresentadas no software. Já o custo arcado pela Empresa é
de alocar equipes que façam as correções, gerando retrabalho e falta de mão de
obra em novos projetos e custear o tempo de atraso para a entrega do software
pronto ao Cliente. [5]

18. 5
Para que as empresas aumentem a produtividade e obtenha redução de
custos como muitas almejam, é necessário que os produtos desenvolvidos
obtenham qualidade, que não haja retrabalhos e insatisfação do Cliente. [3]
Qualidade de Software é a área de conhecimento da Engenharia de Software
que objetiva garantir a qualidade do software através da definição e normatização de
processos de desenvolvimento. [6]
Nos anos 80 o conceito de qualidade passou a ser utilizado na conferência de
cada parte garantindo que estaria correta. [2]
A preocupação com a qualidade de software é importante devido a
algumas razões óbvias. Ninguém gosta de software com bugs1
.Bugs
podem causar prejuízos que variam desde a mera necessidade de
reiniciar o sistema operacional até a perda de satélites de milhões de
dólares (como o Clementine, um satélite construído para designar
alvos, no projeto Guerra nas Estrelas, o qual, quando recebeu um
comando para mirar um ponto na superfície lunar, ativou os foguetes
direcionais e ficou girando até acabar o combustível...). Bugs podem
fazer um banco perder milhões e perder a confiança dos cliente sou
parar por horas uma companhia telefônica, impedindo a realização
de telefones interurbanos (como já ocorreu com a AT&T). Mas não é
só isso. Os esforços pela qualidade na indústria automobilística
provaram a tempos que a qualidade não tem custo. Ao contrário do
que muita gente pensa, os investimentos em qualidade pagam-se em
pouco tempo. [7]
Muitas empresas deixam de aderir o processo de qualidade, pois, acreditam
ter um custo maior, porém, o que temos visto é que praticar a qualidade reduz o
custo de muitos projetos devido a possibilidade de se prever os gastos que serão
realizados com o processo de qualidade, já correções, retrabalho e falta de
produtividade são custos que não são previsíveis. [7]
1 Bugs: Este termo é geralmente usado em informática quando é encontrado um erro em algum
programa, ou seja, quando algum programa age de maneira inesperada ou fora do comum. [8]

19. 6
Tabela 1 - Categorias dos Custos Operacionais da Função Qualidade
Fonte: [4]
Todo gasto realizado com a qualidade deve ser considerado investimento e
possível de prever, já os custos ocasionados por falhas durante o desenvolvimento
ou após entregar o produto não são previsíveis e podem causar prejuízos
financeiros e perda de confiança pelos clientes. [4]
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 produto e do processo de desenvolvimento. As
empresas já entenderam que praticar softwares não adequados,
além de prejudicar a imagem da organização aumenta
significativamente os custos totais do desenvolvimento. Isso
consome a rentabilidade dos projetos de software, além de ampliar
os riscos de insucesso dos projetos existentes. [2]

20. 7
2. Qualidade de Software
2.1 Definição da Qualidade
Há várias definições que podem ser atribuídas a Qualidade:
“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”. (BARTIÉ, 2002 p.16)
“A totalidade das características de uma entidade que lhe confere a
capacidade de satisfazer as necessidades explicitas e implícitas”. [2]
“Conformidades com os requisitos funcionais e de desempenho
explicitamente declarados, padrões de desenvolvimento explicitamente
documentados e características implícitas, que são esperadas em todo software
desenvolvido profissionalmente.” [2]
Segundo Silva (2010) [2] há ainda outras três possíveis definições para
qualidade:
 Estar em conformidade com os requisitos dos Clientes;
 Antecipar e satisfazer as necessidades dos Clientes;
 Documentar tudo o que se deve ser feito, e fazer tudo o que foi
documentado.
“O termo tem tomado vários significados, dependendo de quem interpreta e
como se aplica”. [9]
De acordo com Campos apud Kan (2008) [9] para se obter a Gestão da
Qualidade Total (TQM)2 é necessário atingir os seguintes objetivos:
2 A gestão da qualidade total é uma estratégia de administração orientada a criar consciência de
qualidade em todos os processos organizacionais. [10]

21. 8
Figura 1 - Elementos chave do TQM Total Quality Management (Gestão da Qualidade
Total)
Fonte: [9]
Foco do Cliente (Customer Focus) - O objetivo é atingir a
satisfação total do cliente. O foco do cliente inclui o estudo das
necessidades e vontades do cliente, coleta de requisitos do cliente e
a medição e gerenciamento da satisfação do cliente.
Melhoria de Processo (Process Improvement) - O objetivo é
reduzir as variações de processo e atingir a melhoria da qualidade
contínua. Este elemento inclui ambos os processos de negócio e o
processo de desenvolvimento do produto. Através da melhoria de
processo, a qualidade do produto será reforçada.
Lado Humano da Qualidade (Human Side of Quality) - O objetivo
é criar a cultura de qualidade por toda a empresa. As áreas de foco
incluem liderança, apoio da alta gerência, participação total de todos
os colaboradores da empresa, e outros fatores humanos como
sociais e psicológicos.
Métricas, Modelos, Medições e Análises (Metrics, Models,
Measurement and Analysis) - O objetivo é direcionar a melhoria
contínua em todos os parâmetros da qualidade por um sistema de
medição orientado a metas. [9]
Diante da dificuldade de definir a qualidade, Campos apud Pressman (2008)
[9] sugere que a qualidade de software seja implementada e não somente uma idéia
ou desejo que uma organização venha ter. Com isso as equipes devem levar
qualidade em todo o processo de desenvolvimento com a colaboração de todos.

22. 9
2.2 Histórico da Qualidade
Nos tempos anteriores ao século XX, a qualidade era vista somente como
responsabilidade do artífice que era responsável pelo desenvolvimento de produtos.
Somente em 1916 foi que realmente a função de qualidade passou a ser exercida
pelos Laboratórios Bell3 e em seguida por todas as fábricas. (PRESSMAN, 2002)
“No inicio do desenvolvimento de software, a atividade de teste era
encarada como a simples tarefa de percorrer o código para corrigir
problemas já conhecidos. Essas correções eram feitas pelos próprios
desenvolvedores, não existindo recursos específicos para esta
atividade. Devido esse motivo, os testes eram realizados somente
muito tarde, quando o produto já estava quase ou totalmente pronto.
Apesar de essa situação estar associada a uma prática muito ruim de
desenvolvimento de software, ela ainda continua presente em muitas
organizações”. [2]
Para koscianski apud Juran e Gryna (1988) [12] a qualidade esta presente
desde muitos anos atrás, quando por exemplo para que as construções egípcias
tivessem o tamanho correto era usado o “cúbito”, unidade de medida que
correspondia ao tamanho do braço do faraó que estivesse no posto, e a cada lua
cheia deveriam ser feitas novas medições para cada construção, caso as medições
não fossem feitas ou houvessem erros as punições poderiam ser severas até
mesmo levando os responsáveis a morte.
Ainda segundo Koscianski apud Vincente (2004) [12] podemos encontrar a
qualidade também nos templos da Grécia e Roma antiga, catedrais medievais, onde
utilizavam apenas compassos e cordas para realizarem estas construções. Mesmo
sem ferramentas adequadas, sem instruções de como realizar o “projeto”, todos
obtiveram sucesso ao serem finalizados, isto, foi devido ao planejamento realizado,
para se iniciar algo tão grandioso deveriam planejar muito bem como seria a
execução e os resultados esperados.
3 Bell Telephone Laboratories ou Bell Labs era originalmente o braço de pesquisa e de
desenvolvimento AT&T dos Estados Unidos, desenvolvendo uma série de tecnologias consideradas
revolucionárias desde comutadores telefónicos, cabos de telefone, transístores, LEDs, lasers, a
linguagem de programação C e o sistema operativo Unix. [11]

23. 10
As empresas de desenvolvimento de software no inicio de suas atividades
utilizavam como metodologia de qualidade os próprios desenvolvedores verificando
os códigos em busca de falhas e inconsistências, porém, esta não é a melhor prática
a se fazer devido a testes viciados, que não forçam o erro. [2]
Em 1957 surgiu o conceito de testes de Software, mas muitos ainda
utilizavam apenas ao final dos projetos, isto resultava em softwares que ainda
geravam muito retrabalho. Somente nos anos 80 foi que as empresas notaram a
importância de testes serem realizados paralelamente ao desenvolvimento.
Garantindo que cada fase estava correta. [2]
Segundo Tamashiro (2010) [13] entre os anos 80 e 90 os resultados dos
testes passaram a ser positivos e as empresas passaram a aplicar recursos para
obterem as melhores práticas reduzindo os custos com acertos de falhas e o
crescimento de áreas próprias de teste.
2.3 Gerenciando a Qualidade
Bartié (2002) subdividia a Qualidade de Software em três pilares
fundamentais para a boa prática da atividade, o planejamento da qualidade, a
garantia da qualidade e o Controle da Qualidade.

24. 11
Figura 2 - Pilares da Qualidade de Software
Fonte: (BARTIÉ, 2002)
2.3.1. Planejando a Qualidade
Esta fase será utilizada para identificar quais os padrões de qualidade que
serão aplicados a estrutura dos projetos, porém, a utilização destes padrões varia de
empresa para empresa ou ditados pelos clientes. (PRESSMAN, 2002)
É importante neste momento definir todas as ferramentas e procedimentos
estabelecidos, pois servirão como base para futuras revisões ou auditorias.
(FIORINI, ARNLT, & BAPTISTA, 1998)
2.3.2. Garantia da Qualidade
Processo que será responsável por certificar que as atividades e o os
objetivos determinados serão atingidos, garantindo a correta execução do que foi
determinado. [12]

25. 12
Para Gomes (2010) [4], a Garantia da Qualidade tem como objetivo prover
confiança sobre a conformidade de produtos e serviços e requisitos especificados e
que venham ao encontro das necessidades dos usuários.
2.3.3. Controle da Qualidade
É responsável por verificar se os resultados dos projetos estão atendendo os
processos da qualidade durante o desenvolvimento. Para medir, é realizado um
acompanhamento da eficácia do desenvolvimento, para que, quando a qualidade
não seja realizada em algum ponto, haja tempo de executar ações de manutenção
mantendo o nível correto de qualidade. (BARTIÉ, 2002)
2.4 Aplicando a Qualidade
A qualidade de software é projetada num produto ou sistema. Ela
não é imposta após o fato. Por essa razão, a SQA inicia-se de fato
com o conjunto de métodos e ferramentas técnicas que ajudam o
analista a conseguir uma especificação de elevada qualidade e o
projetista a desenvolver um projeto de elevada qualidade.
(PRESSMAN, 2002)
Para (BARTIÉ, 2002) muitas empresas de desenvolvimento acreditam que o
processo é composto por etapas, e desta forma aplicam os testes em um período
determinado somente para isto, porém, os testes devem ser realizados desde o
inicio do projeto identificando erros nas fases iniciais e reduzindo os custos com
manutenção.

26. 13
Figura 3 - Ciclo de desenvolvimento no qual qualidade resume-se a testes de software
Fonte: (BARTIÉ, 2002)
O grupo de Qualidade trabalha junto com o projeto de software já
durante seus estágios iniciais, estabelecendo planos, padrões e
procedimentos, que irão adicionar valor ao projeto de software, e que
satisfazem as restrições do projeto e das políticas da organização.
Participando no estabelecimento de planos, padrões e
procedimentos o grupo de qualidade garante que esses se ajustem
às necessidades do projeto. Também verifica se os planos, padrões
e procedimentos serão utilizáveis para efetuar as revisões e as
auditorias ao longo do ciclo de vida do software. Revisa as atividades
do projeto, audita artefatos de software ao longo do ciclo de vida e
proporciona uma visão à gerência que permite verificar se o projeto
de software está seguindo o planejado. (FIORINI, ARNLT, &
BAPTISTA, 1998)
Isso determina que seja necessário garantir a qualidade em todas as partes
do processo, não iniciando uma nova etapa caso ainda há erros na etapa atual.
Antes de analisar os requisitos, deve-se garantir que o conceito do projeto possui
qualidade, antes de iniciar a definição da arquitetura do projeto, os requisitos devem
ter sido descritos com qualidade, antes de codificar deve-se garantir que a
modelagem foi feita corretamente e assim por diante em todas as fases. (BARTIÉ,
2002)
“Qualidade não é uma fase do ciclo de desenvolvimento de software, é parte
de todas as fases” (BARTIÉ, 2002)
O Centro de Pesquisa SEI (Software Engineering Institute) patrocinado pelo
Departamento de Defesa dos Estados Unidos realizou um dos trabalhos mais
importantes de analise da maturidade de organização das empresas. E o resultado

27. 14
disso foi a elaboração do CMM (Capability Maturity Model), um modelo que propõe o
processo de software com melhoria continua. [2]
2.5 CMM (Capability Maturity Model)
2.5.1 Apresentação do CMM
Capability Maturity Model (CMM), foi desenvolvido para estruturar o processo
de desenvolvimento de uma forma com mais controle e eficácia. Para que estes
sejam alcançados o CMM funciona de forma gradativa, partindo do principio de que
a empresa não possui nenhum modelo de organização dos processos, e
aumentando a eficiência de etapa em etapa, até que todos as etapas estejam sendo
executadas corretamente. [2]
O modelo se baseia em cinco níveis de maturidade, no qual estes níveis
representam o crescimento da maturidade no desenvolvimento. Este nível de
maturidade é avaliado de organização para organização, demonstrando qual o
controle que possuem sobre o processo no geral. (BARTIÉ, 2002)
Os níveis são incrementais, ou seja, não é possível sair do nível 1 e atingir o
nível 3 sem completar o nível 2, e cada um visualiza apenas os pontos em que sua
organização permite. (BARTIÉ, 2002)

28. 15
Figura 4 - Possíveis níveis de maturidade previstos no modelo CMM
Fonte: (BARTIÉ, 2002)
No nível 1 a organização está sem nenhum modelo de maturidade, e para
que esta etapa seja cumprida é importante o desempenho de todos os
colaboradores, pois, não possuem ainda os processos que possam auxiliar. Como
esta etapa exige maior agilidade, mesmo cumprindo com o especificado,
normalmente os prazos e orçamentos não são cumpridos. [14]
No nível 2 a definição de como será o gerenciamento de software e como
funcionará sua implementação já estão estabelecidos. E para planejar e gerenciar os
novos projetos são analisados os pontos que foram eficazes em projetos anteriores,
permitindo à organização repetir estes pontos utilizando as melhores práticas.
Sempre praticando, documentando, garantindo, treinamento e com foco nas
melhorias continuas. [2]
Este nível é considerado como um método disciplinado devido ao
planejamento e documentação estáveis, e permite que os processos que obtiveram
sucesso se repitam em todos os projetos. [2]

29. 16
No nível 3 todos os processos e procedimentos já estão especificados e
documentados. Sendo estes, a base para este nível e sempre adaptados com
melhorias continuas. Com os padrões especificados a organização consegue
determinar que sejam aplicados em todo o desenvolvimento estabelecendo
objetivos. [14]
A diferença entre os níveis 2 e 3 é que, no nível 2 são estabelecidos padrões
para os projetos, que podem haver particularidades e objetivos diferentes. Já no
nível 3 são estabelecidos padrões para a organização como um todo, unidos com os
do nível 2. “Como resultado, os processos realizados através da organização são
consistentes exceto pelas diferenças permitidas pelos guias.” [14]
Neste nível é possível organizar métodos dinâmicos para o desenvolvimento,
acrescentando, modificando ou removendo atividades, variando de acordo com as
especificações dos projetos. [2]
É criado um grupo denominado SEPG (Software Engineering Process Group),
onde serão responsáveis por determinar e documentar todas as etapas do processo.
Esta equipe determina os pontos do processo possibilitando a “customização”
estabelecendo em quais situações e quando serão aplicados. [2]
“Neste nível é possível visualizar claramente como cada projeto em execução
está evoluindo.” [2]
No nível 4 o processo de gerenciamento irá utilizar todas as métricas para
monitorar o empenho no processo de desenvolvimento, estabelecendo metas
quantitativas. [14]
São avaliadas a produtividade e qualidade de todas as etapas do
desenvolvimento, como item de uma forma de medição, utilizando um banco de
dados que obtenha toda a análise de dados dos processos definidos no projeto.

30. 17
Sendo estas medições consistentes e com grande definição. Disponibilizando bases
para que sejam avaliados os processos do projeto. [2]
E o nível 5 após ter todas as metas definidas nos níveis anteriores, os
processos passam a ter melhorias contínuas determinadas pelo aprendizado
adquirido das causas comuns dos processos, sendo medidos e acompanhados. [14]
Este nível tem como papel principal utilizar os resultados do nível 4 para que
sejam aplicadas mudanças com o foco na melhoria dos processos para que os
objetivos sejam todos atendidos com qualidade. [14]
2.5.2 Impacto da Maturidade
Um dado importante que o SEI4
estima é o fato de que as 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 adquirindo 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 do tempo total do desenvolvimento, custo final do projeto,
número de profissionais envolvidos e o nível de confiabilidade que
esta empresa alcança quando atinge esse patamar de excelência
organizacional. (BARTIÉ, 2002)
4 A Software Engineering Institute (SEI) define iniciativas específicas destinadas a resolver os
problemas que impedem a maturidade e capacidade das organizações para adquirir, construir e
desenvolver sistemas previsivelmente no prazo, dentro do custo esperado, atendendo os requisitos e
sem vulnerabilidade. [15]

31. 18
Figura 5 - Esforço dedicado à correção de defeitos no desenvolvimento de software
Fonte: (BARTIÉ, 2002)
Para empresas que possuem pouca maturidade, o esforço gerencial para
manter software com qualidade é maior, devido a falta de preparação para executar
atividades de grande porte, não possuírem organização nos processos e
documentação adequada. [2]
“A maior parte das organizações é resistente à inovação do processo de
desenvolvimento, pois acredita que o aperfeiçoamento é uma atividade impraticável.”
[2]
2.6 Qualidade e Defeitos
Defeitos de software são os principais motivos que geram retrabalho, custos,
não cumprimento de prazos, redução da produtividade e insatisfação do Cliente.
(BARTIÉ, 2002)
E estes defeitos encontrados nos softwares recebem muitos nomes e
definições, como “problemas, falhas, ocorrências, incidentes, não conformidades e

32. 19
inconsistências. Também podemos empregar palavras existentes na língua inglesa
como bugs, crash e abends”. (BARTIÉ, 2002)
Qual a melhor palavra para descrever que um software “travou” ou não está
agindo de forma correta? [12]
2.6.1 Erro, Defeito e Falha
É importante distinguir falha, erro e defeito para que se crie uma linguagem
comum entre os membros de uma equipe e para que se possa fazer uma análise de
causa raiz quando um problema ocorre.” [16]
O erro significa que algo não está funcionando corretamente no software,
gerando inconsistências na aplicação. É conseqüência de uma falha, mas não são
todas as falhas que resultam em um erro, pois, a seqüência de execução pode não
gerá-los. [16]
Um defeito no software pode ser originado por omissão de alguma
informação, declaração de dados, controles incorretos ou vários outros motivos.
Caso um defeito não seja identificado ele passa a ser uma falha na execução do
software. [17][17]
A falha é quando um software não se comporta da forma esperada, ou não
retorna os resultados esperados. [17]

33. 20
Figura 6 - Erros, defeitos e falhas
Fonte: [17]
2.6.2 Bug
É um erro no funcionamento comum de um software, também
chamado de falha na lógica programacional de um programa de
computador, e pode causar discrepâncias no objetivo, ou
impossibilidade de realização, de uma ação na utilização de um
programa de computador ou apenas uma trava no sistema. [8]
O termo é utilizado para descrever problemas que não tem explicação, e esta
presente no mundo da informática a muito tempo. Tomas Edison em seus circuitos
elétricos já mencionava os bugs. [8]
O Bug pode ser designado como um erro na execução de um software,
possivelmente resultando em inconsistências nos resultados esperados de um
programa. Abaixo a figura demonstra um exemplo da definição de Bug durante a
criação do código de um sistema, que quando é executado pelo usuário não se
comporta da forma correta, resultando em uma falha. [18]

34. 21
Figura 7 - Erro de código: "If" sem "End If"
Fonte: [18]
Há uma imagem de que os bugs são encontrados somente no código fonte.
Assim como, entendem que somente o desenvolvedor e a equipe de qualidade são
os responsáveis pelos bugs. Nas duas afirmações a visão esta errada, pois os e
bugs podem ser gerados em todo o processo no desenvolvimento, como por
exemplo, resultados de uma especificação de requisito, análise, modelo de dados ou
interface do sistema feitos de forma incorreta. (BARTIÉ, 2002)

35. 22
Figura 8 - Exemplo de erro na especificação.
Fonte: [18]
Os erros estão em todas as etapas do processo, porém, estudos reforçam
que a maior parte está presente nas fases iniciais do projeto. No produto final são
encontrados muitos erros que resultaram da má especificação e clareza dos
objetivos que deveriam ser cumpridos. Se a qualidade fosse aplicada desde a
definição do projeto muitos erros seriam identificados prematuramente evitando que
fossem migrados para as outras fases. (BARTIÉ, 2002)

36. 23
Figura 9 - Incidência de defeitos nas etapas de desenvolvimento
Fonte: (BARTIÉ, 2002)
2.7 O custo da qualidade
“O custo da qualidade inclui todos os custos decorrentes da busca da
qualidade ou da execução das atividades relacionadas à qualidade.” (PRESSMAN
R. , 2002)
Os custos investidos em qualidade são todos aqueles investimentos em um
produto ou serviço para que atendam a qualidade total e podem ser divididos em
custos da conformidade e custos da não conformidade. (BARTIÉ, 2002)
Os custos da conformidade são aplicados para alocar pessoas, processos e
ferramentas que previnam e detectem os erros do processo durante o
desenvolvimento. E os custos da não conformidade são aqueles ligados ao processo
de reparação de falhas ocorrido no decorrer do processo ou após a entrega do
produto. (BARTIÉ, 2002)
A cada uma das fases está determinado um custo. Todos somados resultam
no custo total da qualidade contemplando o custo da construção. [19]

37. 24
Figura 10 - Custo da Qualidade
Fonte: [19]
Custo de Falhas – Envolve todos os custos associados a produtos
defeituosos, que já foram entregues aos usuários ou disponibilizados
em produção e que geraram algum tipo de falha. Esses custos
referem-se ao retrabalho para reparação de produtos defeituosos, ou
a prejuízos decorrentes das falhas no software. Incluem-se nesta
categoria, também os custos associados à manutenção de um Help
Desk.
Custo de Avaliação – Esse custo refere-se ao que é gasto em
procedimentos de verificação e em testes dos produtos de software
para identificação de defeitos, após a sua construção e antes que
sejam disponibilizados para uso ou implantados em produção.
Contempla tanto produtos intermediários, como documentos de
requisitos, modelos de dados ou especificações, como também o
produto de software final.
Custo de Prevenção – Mais que um custo, é um investimento
realizado para se evitar erros e fazer o trabalho certo na primeira
tentativa. É um investimento com retorno a médio ou longo prazo e
que contempla a criação de métodos e procedimentos, a melhoria de
processos, a capacitação dos profissionais, a aquisição de
ferramentas e o planejamento da qualidade. Esse custo ocorre antes
da criação do produto. [19]
O custo da qualidade passa a ser sempre investimento quando realizado com
o intuito de melhorar e garantir o correto desenvolvimento de um produto. Porém,

38. 25
para que este processo seja aplicado corretamente deve ser aplicado um montante
de dinheiro, profissionais e tempo. Para reduzir estes investimentos é importante
identificar as atividades com maior importância e criticidade. (BARTIÉ, 2002)
Para demonstrar a evidente vantagem de se manter um processo de
qualidade Bartié exibe o gráfico da Regra 10 de Myers5 demonstrando que identificar
os erros nas fases iniciais do processo custam menos dos que os ocorridos nas
fases finais.
Figura 11 - Regra 10 de Myers
Fonte: (BARTIÉ, 2002)
2.8 A Garantia da Qualidade de Software (GQS)
O grupo de Garantia do Software tem como principal papel representar o
Cliente, quanto às avaliações sobre o software desenvolvido, analisando se o
software atende de forma correta os padrões de qualidade, se a parte técnica
5
A Regra 10 de Myers indica que o custo da correção dos defeitos tende a ser cada vez
maior tanto mais tarde ele for descoberto. Defeitos encontrados nas fases iniciais da etapa
de desenvolvimento do software são mais baratos de serem corrigidos do que aqueles
encontrados na produção. [20]

39. 26
respeitou adequadamente os papéis para cada atividade dentro do desenvolvimento.
(PRESSMAN, 2002)
O objetivo da GQS é fornecer resultados sobre a eficiência das etapas
utilizadas pelo desenvolvimento e sobre a qualidade do produto que será entregue.
Para exibir estes resultados, a equipe realiza um exame meticuloso no software
buscando encontrar se existem desvios de padrões e especificações determinadas
ou que necessite de melhorias. [21]
Esta verificação deve ocorrer em todas as etapas do processo de
desenvolvimento com o intuito de prever defeitos antes do produto ser finalizado.
[21]
Todo processo de desenvolvimento por muitas vezes gera produtos
defeituosos, é importante obter um processo que descubra esses defeitos e garanta
o bom funcionamento do projeto. Estes defeitos geram problemas tanto para a
imagem da empresa quanto para o negócio. E para garantir que não impactem no
projeto e que sejam corrigidos foi criada a área a de Testes de Software. (BASTOS,
A. et. al., 2007)
“A atividade de teste de software combina uma estratégia de múltiplos passos
com uma série de métodos de projeto de casos de testes6 que ajudam a garantir
uma detecção de erros efetiva”. (PRESSMAN, 2002)
6 Casos de Testes: é aquele documento que possui entradas dentro inseridas no sistema/programa
e suas saídas esperadas. Mostra os caminhos percorridos por um módulo, caso de uso ou
funcionalidade dentro do projeto. Servem como base para que os testadores possam executar os
testes manualmente, mas podemos cria-los com o intuito de automatizar os casos e devem cobrir o
máximo de situações possíveis. [22]

40. 27
3. Testes de Software
3.1 Fundamentos de Teste
A atividade de teste é um ponto importante no processo de garantia da
qualidade e tem como responsabilidade representar a avaliação final da
especificação, projeto e processo de codificação. (PRESSMAN, 2002)
A atividade de teste constitui uma anomalia interessante para o
engenheiro de software. Durante as fases de definição e
desenvolvimento anteriores, o engenheiro tenta construir o software,
partindo de um conceito abstrato para uma implementação tangível.
Agora, surge a fase de testes. O engenheiro cria uma série de casos
de teste que têm a intenção de “demolir” o software que ele
construiu. De fato, a atividade de teste é um passo do processo de
engenharia de software que poderia ser visto (psicologicamente, pelo
menos) como destrutivo, em vez de construtivo.(PRESSMAN, 2002
p.787)
Os testes são executados na maioria das empresas como etapa do
desenvolvimento, e por muitas vezes é realizado pelos desenvolvedores ou
usuários. O objetivo é reduzir os defeitos originados pelo desenvolvimento.
(BASTOS, A. et. al., 2007)
Em um novo formato, os testes começam a ser realizados por profissionais
especializados para esta função, com uma metodologia apropriada e não mais por
um desenvolvedor. Pois, nem analistas, nem desenvolvedores, nem usuários
possuem capacidade técnica para execução dos testes. (BASTOS, A. et. al., 2007)
Se os testes forem realizados com sucesso serão identificados erros no
software. A área de testes exibe que o software desenvolvido atende as
especificações determinadas pelos requisitos. Além disso, a atividade de teste
proporciona confiabilidade no produto. (PRESSMAN, 2002)

41. 28
É importante saber que a atividade de teste não garante que os bugs não
existirão, ela apenas demonstra se há defeitos presentes no software. (PRESSMAN,
2002)
3.2 Pré-conceitos dos testes
Para que os testes sejam aplicados de forma correta é necessário eliminar
alguns pré-conceitos existentes em muitas equipes:
 A equipe de testes é inimiga da área de desenvolvimento: não há o
objetivo de demonstrar que alguns são mais competentes que os outros, ou que
erram constantemente. Existe apenas o intuito de produzir produtos com qualidade.
 Desenvolvedores com pouca qualidade podem testar sistemas: para
que os testes tenham a correta funcionalidade é necessário ter uma equipe
capacitada, e que por muitas vezes necessitem até de certificados para comprovar
sua qualificação.
 Após terminar o desenvolvimento de software a equipe de teste
realizará seu papel: os testes devem ser executados desde o principio do projeto,
os testes executados no final do desenvolvimento são os realizados pelo cliente,
para apenas validar que o produto atende suas necessidades. (BASTOS, A. et. al.,
2007)
Outros pré-conceitos, segundo Davidson (2011) [23]:
 “...Implemente, se der tempo a gente testa.”
 “o importante é entregar... os testes, deixa que o cliente faz para gente...”
 “o prazo vai estourar... Então sacrifique os testes..”
 “entregue com bugs, mas entregue em dia, depois agente arruma…”

42. 29
 “sabemos que nosso software está cheio de bugs, então vamos cobrar
uma manutenção mensal do nosso cliente para consertá-los…”
 “testar não é uma atividade importante…”
 ”…como vamos testar se não temos tempo?”
 “…testar pra que? perda de tempo.”
 “pra desenvolver sem teste é X, com teste é X2…“
Por mais absurdas que pareçam ser estas afirmações, muitas empresas
aplicam ainda estes conceitos. (BASTOS, A. et. al., 2007)
3.3 A importância dos Testes
Para que um software seja de alta qualidade é imprescindível que os testes
sejam realizados. Há um descuido quando isso não ocorre, já que não são
analisados os impactos de um produto com má qualidade. O negócio ou mesmo
vidas (em caso de software para aparelho médico, aviões e etc.) podem sofrer as
consequências de um software sem testes ou que não foram buscados os bugs
adequadamente. [24]
Exemplo disso:
Três anos atrás, o Station Casinos idealizou uma ótima promoção
para atrair clientes: oferecer 25 dólares de jogo gratuito em máquinas
caça-níqueis a partir de seus cartões de fidelidade eletrônicos.
Funcionou como mágica, apostadores afluíram ao cassino em
bandos. Era para ser uma boa estratégia de negócios.
Porém, em uma sexta-feira, logo depois de iniciada a promoção,
quando os jogadores inseriram seus cartões nas máquinas, nada
aconteceu. O grande número de pessoas tentando acessá-las e ao
mesmo tempo em que o departamento de contabilidade rodava
diversas aplicações financeiras travou os servidores que
armazenavam toda a informação promocional. Irados, jogadores
atiraram seus cartões de fidelidade no chão e iniciaram um tumulto.
Uma reação nada boa. [24]
O problema foi causado devido à falta de testes para um volume de acessos
tão grande, fazendo com que a empresa deixasse de ganhar dinheiro e tivesse que

43. 30
criar outra promoção para se redimir do erro e os clientes ficaram insatisfeitos com o
ocorrido. [24]
Outros exemplos:
A empresa Symantec proprietária do software antivírus Norton que
em junho de 2007 teve de compensar 50 mil vítimas de uma
atualização que retirava arquivos de sistema de uso, dando a elas
uma extensão de 12 meses da licença do Norton e uma cópia da
ferramenta Norton Save & Restore 2.0. (LOPES & CARNEIRO) [25]
Em 1988, o navio US Vicennes derrubou um Airbus 320 causando a
morte de 290 pessoas, a falha foi atribuída ao software de
reconhecimento do navio que confundiu o avião com um F-14. [25]
Todo software desenvolvido tem como objetivo atender demandas, e para que
seja garantida a eficácia dos programas é necessário testar os softwares, pois,
sempre existirá a probabilidade de se existirem defeitos, bem como reduzir custos e
identificar as qualidades dos softwares como: “confiabilidade, qualidade,
desempenho, usabilidade, portabilidade, segurança, recuperabilidade e outras.” [25]
Segue abaixo um modelo de relacionamento entre o desenvolvimento do
software os testes.

44. 31
Figura 12 - Modelo de relacionamento entre desenvolvimento e testes
Fonte: (BASTOS, A. et. al., 2007)
3.4 Princípios de Teste
Os testes devem ser executados em todas as etapas do projeto, mas, é
importante saber identificar até que momento os testes poderão ser executados,
para isto há duas situações a serem analisadas. (BASTOS, A. et. al., 2007)
 Cobranças sobre prazos de projeto, onde os testes são interrompidos antes
do tempo definido, ou seja, não foram realizados todos os testes pré-definidos e o
risco de ocorrerem defeitos é muito maior.

45. 32
 Excesso de testes, quando são executados mais testes do que o previsto,
ultrapassando o tempo estimado e com um gasto maior do que o necessário.
(BASTOS, A. et. al., 2007)
Figura 13 - Ponto de equilíbrio dos testes
Fonte: (BASTOS, A. et. al., 2007)
O custo das falhas que possam vir a ocorrer num ambiente de
produção não compensa o gasto adicional de dinheiro para tentar
evitá-las. No caso de um software usado nos controles de um avião,
o ponto de equilíbrio ficará bastante à direita, ao passo que, no caso
de um site Web de páginas estáticas, esse ponto estará bem a
esquerda. Quanto mais critico for o software, mais testes serão
gastos para garantir a qualidade desse produto. Isso equivale a dizer
que quem define a quantidade de testes é a criticidade do negócio.
(BASTOS, A. et. al., 2007)
3.5 Técnicas de Teste
Durante o processo de desenvolvimento de um software serão aplicados dois
tipos de teste, o de verificação e o de validação. O teste de verificação é responsável
por certificar a qualidade de todos os pontos do desenvolvimento, concentrando-se

46. 33
em duas formas de avaliação, a Revisão voltada para a documentação e a Auditoria
que garante a qualidade das atividades realizadas. Já o teste de Validação após
receber o software finalizado, é responsável por apontar os erros gerados em
processos isolados ou no produto completo, para que estes testes abordem todas as
áreas do software são definas algumas técnicas para a execução dos mesmos.
(BASTOS, A. et. al., 2007)
3.5.1 Testes de Caixa Branca
O teste de caixa branca é responsável por avaliar a parte interna do software,
atuando diretamente no código fonte avaliando os testes de condição, fluxo de
dados, ciclos, caminhos lógicos. [27]
O objetivo principal é apontar defeitos utilizando a simulação de condições
que realizem corretamente a estrutura feita durante a codificação. Possuem grande
eficiência na identificação de erros, porém, são mais difíceis de implantar. (BARTIÉ,
2002)

47. 34
Figura 14 - Execução Testes Caixa Branca
Fonte: (BARTIÉ, 2002)
Para a realização dos testes de caixa branca foram definidos testes
específicos para cada situação. (BASTOS, A. et. al., 2007)
3.5.1.1 Teste de Estresse
O teste de estresse é executado para forçar situações extremas de utilização
do software, avaliando até que ponto exigir em memória, espaço em disco e CPU. É
importante analisar a quantidade de dados que recebe acima da média estipulada.
(BASTOS, A. et. al., 2007)
3.5.1.2 Teste de Execução
É responsável por analisar o tempo de resposta, da execução e de
performance do software em produção. Em um software feito por etapas e por
equipes diferentes este teste seria responsável por executar o teste por completo.
[26]
3.5.1.3 Teste de Recuperação
Este teste analisa a capacidade do software de recuperar as informações ao
ser reiniciado após uma perda da integridade. Exige que o software retorne em uma
etapa do processo onde a continuidade não seja afetada. (BASTOS, A. et. al., 2007)

48. 35
3.5.1.4 Teste de Operação
São testes utilizados no ambiente de operação em que atuará, com usuários
que irão executar a ação e com os procedimentos determinados verificando se a
aplicação irá funcionar adequadamente. (BASTOS, A. et. al., 2007)
3.5.1.5 Teste de Conformidade
Verifica se o produto final atende a todas as especificações de padrão,
normas, procedimentos e as guias de TI. [26]
3.5.1.6 Teste de Segurança
É um procedimento importante para se avaliar a segurança das informações
do software, garantindo a confidencialidade e proteção dos dados. Este teste tem o
objetivo de evitar que informações sejam acessadas por pessoas não autorizadas
comprometendo o negócio ou fornecendo informações para empresas concorrentes.
(BASTOS, A. et. al., 2007)
3.5.2 Testes de Caixa Preta
É responsável por analisar o comportamento externo do software, sem se
preocupar se internamente os processos estão sendo executados corretamente.
Para executar são inseridos dados de entrada, os testes são executados e o
resultado da execução é comparado ao resultado esperado. Para que o teste seja
cada vez mais funcional é importante fornecer todas as entradas de dados possíveis.
[27]
O teste de caixa preta não exige que o responsável tenha conhecimento
lógico da tecnologia aplicada, os testes são mais simples do que o de caixa branca.
A única dificuldade de realizar este tipo de teste é exigir que a equipe responsável

49. 36
pela homologação realize um planejamento detalhado e apurado para que seja
possível identificar todos os cenários possíveis. (BARTIÉ, 2002)
Figura 15 - Execução Teste Caixa Preta
Fonte: (BARTIÉ, 2002)
3.5.2.1 Teste de Requisitos
Os testes de requisitos analisam se o software esta executando de forma
correta as funcionalidades e se possui capacidade de continuar eficiente após ser
utilizado por um período contínuo. (BASTOS, A. et. al., 2007)
3.5.2.2 Teste de Regressão
Tem o objetivo de analisar se algo foi alterado de como era realizado antes da
nova funcionalidade ser aplicada, ou seja, é retestar etapas já testadas após uma
alteração no software. São executados tanto no software quanto na documentação.
(BASTOS, A. et. al., 2007)
3.5.2.3 Teste de Tratamento de Erros
Estes testes são executados forçando os erros no sistema, para analisar a
capacidade do software de lidar com informações incorretas. Exigindo que o
responsável pelo teste pense de forma negativa e informe dados de entrada
incorretos, analisando a forma de resposta do software. [26]

50. 37
3.5.2.4 Teste de Suporte Manual
Analisa se os manuais e guias para os usuários estão sendo feitos de forma
correta, se estão completos. [26]
3.5.2.5 Teste de Interconexão
São executados quando o software em questão possui conexão com outros
softwares, analisando se os dados estão sendo transferidos de forma correta.
(BASTOS, A. et. al., 2007)
3.5.2.6 Teste de Controle
Assegura que o processamento seja realizado conforme sua
intenção. Entre os controles estão a validação de dados, a
integridade dos arquivos, as trilhas de auditoria, o backup e a
recuperação, a documentação, entre outros. [26]
3.5.2.7 Teste Paralelo
Realizar uma comparação dos dados gerados pela nova versão do software
com a versão anterior, exigindo que os dados de entrada sejam os mesmos
executando em duas versões do mesmo software, caso os requisitos sejam os
mesmo apenas as versões foram alteradas os resultados devem ser iguais nas
duas. (BASTOS, A. et. al., 2007)
3.5.3 Testes de Caixa Cinza
Os testes de caixa cinza utilizam tanto os testes de caixa preta quanto os
testes de caixa branca, envolvendo a estrutura dos dados e os algoritmos.
Fornecendo dados de entrada e verificando a execução interna destes dados
validando a saída dos mesmos. [26]

51. 38
3.6 Estágios dos Testes
Figura 16 - Fases dos Testes
Fonte: (BARTIÉ, 2002)
3.6.1 Teste de Unidade
É realizado em unidades menores do sistema, analisando métodos e partes
pequenas do código em busca de falhas de execução. Verificando individualmente
estas pequenas etapas para garantir que cada uma está sendo executada
corretamente. [28]
3.6.2 Teste de Integração
Este teste garante que não haverá erros quando todas as etapas individuais
do sistema forem executadas de forma integrada. Normalmente são encontrados

52. 39
erros de transição de dados. Não faz parte deste teste avaliar a conexão com outros
sistemas (teste de interconexão). [28]
3.6.3 Teste de Sistema
Realiza a execução do sistema como um todo para verificar as funções
seguindo os cenários criados para os testes. [26]
3.6.4 Teste de Aceitação
Esta fase é realizada pelos usuários do sistema, validando se o que foi
desenvolvido atende as especificações solicitadas. É um teste a ser realizado pelo
cliente solicitante de forma formal para que avalie se irá aceitar ou não o sistema.
[28]
3.7 Elaboração dos Testes
3.7.1 Documentação dos Testes
Na etapa de Testes de um projeto, o tempo gasto com a documentação dos
testes é de 50% a 60%. (BASTOS, A. et. al., 2007)
Através da Norma IEEE 829-19987 foram definidos documentos para a equipe
de testes, entre eles o documento de elaboração dos testes. O Plano de Teste é o
documento que será origem para os demais documentos. (BASTOS, A. et. al., 2007)
Plano de Teste: Documenta todo o planejamento para a realização dos
testes, apontando os itens que serão testados, quais atividades serão executadas e
os riscos dos testes. Identifica também quais serão os ambientes a serem testados.
(BASTOS, A. et. al., 2007)
7 IEEE 829, também conhecido como o Padrão 829 para Documentação de Teste de Software, é um
padrão IEEE que especifica a forma de uso de um conjunto de documentos em oito estágios
definidos de teste de software, cada estágio potencialmente produzindo seu próprio tipo de
documento. O padrão especifica o formato desses documentos, mas não estipula se todos eles
devem ser produzidos, nem inclui qualquer critério de conteúdo para esses documentos. [29]

53. 40
Durante a fase de Elaboração dos Testes serão utilizados três documentos:
Especificação do projeto de Teste: Documento detalhado sobre o plano de
teste, identificando também os casos de teste e procedimentos que serão utilizados,
apresentando os critérios para aprovação. (BASTOS, A. et. al., 2007)
Especificação de casos de Teste: Serão descritos os casos de teste,
identificando quais os dados de entrada a serem utilizados, quais serão os
resultados, ações e formas de execução dos testes. Este documento pode também
ser chamado de Plano de Caso de Testes. (BASTOS, A. et. al., 2007)
Especificação do procedimento de Teste: Demonstra todas as
necessidades para operar o software e os casos de teste com objetivo de atender o
planejamento de testes. Este documento tem por objetivo ser seguido sem nenhum
imprevisto. (BASTOS, A. et. al., 2007)

54. 41
Figura 17 - Modelo IEEE STD 829-1998
Fonte: (BASTOS, A. et. al., 2007)
3.7.2 Plano de Casos de Teste
É o documento que aponta o planejamento dos testes elaborados de acordo
com os requisitos determinados no desenvolvimento do sistema. Determinando os
itens a serem testados, o principal objetivo deste documento é registrar a maior
quantidade de cenários possíveis. Os cenários serão representados por um grupo
de casos de testes que serão verificados de acordo com uma listagem de
procedimentos. (BARTIÉ, 2002)

55. 42
3.7.2.1 Casos de Teste
A melhor definição para casos de teste é o maior detalhamento possível de
um teste, com especificações de telas e formulários. São identificadas as
informações que serão utilizadas durante o teste e quais serão os resultados
retornados. Um caso de teste considerado bom deve conter: (BASTOS, A. et. al.,
2007)
 Identificação das condições de testes:
o Pré-condições;
o Pós-condições;
o Critério de aceitação.
 Identificação dos casos de testes (o que testar).
 Detalhamento da massa de entrada e de saída.
 Critérios especiais, caso necessário, para a geração da massa
de teste.
 Especificação das configurações de ambiente no qual o teste
será executado: sistema operacional, ferramentas necessárias,
origem dos dados etc. (onde testar)
 Definir o tipo de implementação do teste: automática/manual
(como testar).
 Listar as interdependências, caso existam, entre os casos de
teste. (BASTOS, A. et. al., 2007)
3.7.2.2 Derivação do Caso de Teste
Para os testes funcionais um caso de teste costuma ser derivado de um caso
de uso. É necessário criar um caso de teste que atenda a cada caso de uso.
(BASTOS, A. et. al., 2007)
Na metodologia RUP os casos de uso possuem vários caminhos refletindo, os
possíveis fluxos básicos e alternativos, sendo identificados pelas setas. (BASTOS,
A. et. al., 2007)

56. 43
Figura 18 - RUP – Caso de Uso
Fonte: (BASTOS, A. et. al., 2007)
O fluxo básico ou principal, representado pela linha preta e retilínea,
é o caminho mais simples através do caso de uso. Cada fluxo
alternativo começa no fluxo principal e depois, de acordo com uma
condição especifica, é executado. Os fluxos alternativos podem
retornar ao fluxo básico (como, por exemplo, os fluxos alternativos 1
e 3 da imagem acima), podem se originar de outro fluxo alternativo
(fluxo alternativo 2) ou terminar o caso de uso sem retornar a um
fluxo (fluxos alternativos 2 e 4). (BASTOS, A. et. al., 2007)
Com os caminhos exibidos na figura é possível identificar os cenários de uso.
Possibilitando a criação dos cenários de teste. (BASTOS, A. et. al., 2007)
3.7.2.3 Exemplos de Caso de Teste
Casos de Teste elaborados de acordo com a visão de Bastos, A.et. al. (2007).
3.7.2.3.1 Apresentação do Software
O software exibirá dois campos: Login e Senha.
O software exibirá as seguintes opções de confirmação: Ok e Limpar.

57. 44
Caso o usuário acione a opção Limpar:
 O software deverá excluir as informações de Login e Senha.
Caso o usuário acione a opção Ok:
 O software verifica o preenchimento do Login e Senha que são campos
obrigatórios.
 O software valida as informações inseridas nos campos Login e Senha.
Exceções do Software
E1 – Campos de preenchimento obrigatório.
Se o usuário não preencher um dos campos ou os dois:
 O software exibirá uma mensagem informativa: “O(s) <<campo>>
deve(m) ser preenchido(s)” e retorna para a tela inicial.
E2 – Verificação de login e senha.
Caso um dos campos não tenha sido preenchido corretamente o software
apresentará a mensagem informativa: “O dados não são válidos” e retorna para a
tela inicial.
E3 – Login bloqueado
O software valida se o login informado esta bloqueado, exibe a mensagem
informativa: “Login bloqueado” e retorna para a tela inicial.
Regras de Negócio
RN01 – Bloqueio de Login
Caso o usuário realize três tentativas incorretas de acesso ao software, o
mesmo irá bloquear o acesso deste login.
Regras de Usabilidade
US01 – Formatação
O campo Login não deverá realizar a diferenciação de letras maiúsculas e
minúsculas (case insensitive), já o campo senha deverá realizar esta diferenciação
(case sensitive).

58. 45
SISTEMA EMPRESARIAL
Login:
Senha:
Protótipo da Tela
3.7.2.3.2 Definição Casos de Teste
CT01 – Campos Obrigatórios
Pré-Condições Acessar a tela de login.
Pós-Condições Software exibe mensagem de erro.
Detalhamento
PA*: O usuário não informa o login ou senha.
PA: O usuário aciona a opção Ok.
PS**: O software valida se os campos obrigatórios estão
preenchidos.
PS: O software exibe a mensagem “O(s) <<campo>> deve(m)
ser preenchido(s)”
Massa de Entrada
e Saída
Não aplica
Critérios
Especiais
Não aplica
Ambiente SO Windows Vista Professional, browser Google Chrome.
Implementação Manual
Iteração 1ª
Interdependências Não aplica.
*PA: Passo do Autor
**PS: Passo do Software

59. 46
CT02 – Login incorreto
Pré-Condições Acessar a tela de login.
Pós-Condições Software exibe mensagem de erro.
Detalhamento
PA: O usuário informa o login incorreto e senha correta.
PA: O usuário aciona o opção Ok.
PS: O software valida que os campos foram preenchidos.
PS: O software valida se o Login informado esta cadastrado e
se a Senha informada é valida.
PS: O software exibe a mensagem “Os dados não são
válidos”.
Massa de Entrada
e Saída
Login incorreto e senha correta.
Critérios
Especiais
Não aplica
Ambiente SO Windows Vista Professional, browser Google Chrome.
Implementação Manual
Iteração 1ª
Interdependências Não aplica.
CT03 – Senha incorreta
Pré-Condições Acessar a tela de login.
Pós-Condições Software exibe mensagem de erro.
Detalhamento
PA: O usuário insere um Login correto e uma senha incorreta.
PA: O usuário aciona a opção Ok.
PS: O software valida se os campos foram preenchidos.
PS: O software valida se o Login informado esta cadastrado e
se a Senha informada é valida.
PS: O software exibe a mensagem “Os dados não são

60. 47
válidos”.
Massa de Entrada
e Saída
Login correto e Senha incorreta.
Critérios
Especiais
Não aplica
Ambiente SO Windows Vista Professional, browser Google Chrome.
Implementação Manual
Iteração 1ª
Interdependências Não aplica.
CT04 – Login bloqueado
Pré-Condições Acessar a tela de login.
Pós-Condições Software exibe mensagem de erro.
Detalhamento
PA: O usuário insere um Login correto e uma senha incorreta
por três vezes. Na quarta vez,
PS: O software bloqueia o login
PS: O software valida se o login está bloqueado
PS: O software exibe a mensagem “Login bloqueado”.
Massa de Entrada
e Saída
Login correto e Senha incorreta por quatro tentativas
Critérios
Especiais
Não aplica
Ambiente SO Windows Vista Professional, browser Google Chrome.
Implementação Manual
Iteração 1ª
Interdependências Não aplica.

61. 48
CT05 – Login efetuado corretamente
Pré-Condições Acessar a tela de login.
Pós-Condições Acessar o software.
Detalhamento PA: O usuário informa corretamente o Login e Senha.
PA: O usuário aciona a opção Ok.
PS: O software valida se os campos foram preenchidos.
PS: O software valida se o Login e Senha informados são
válidos.
PS: O software valida se o Login está bloqueado.
PS: O software valida se o Login está inativo.
PS: O software autentica o Login.
Massa de Entrada
e Saída
Login correto e Senha correta.
Critérios
Especiais
Não aplica
Ambiente SO Windows Vista Professional, browser Google Chrome.
Implementação Manual
Iteração 1ª
Interdependências Não aplica.
3.8 Execução dos Testes
Segundo Bastos, A.et. al. (2007) após ser desenvolvido o plano de testes a
próxima etapa será a execução dos testes, importante que quanto mais detalhado e
fiel ao sistema o plano de testes estiver, mais fácil será o trabalho do testador. Para
cada etapa dos testes há um responsável por eles, sendo:
Testes Unitários – Programadores
Testes de Integração - Analistas de Sistemas

62. 49
Testes de Sistema – Analistas de Teste
Testes de Aceitação – Usuários com a ajuda dos analistas de teste.
Quem irá executar os testes e como serão executados deve estar registrado
no Plano de Testes.bem como os resultados de cada. (BASTOS, A. et. al., 2007)
Abaixo segue figura que exibe como devem ser realizados os testes:
Figura 19 - Fluxo dos Testes
Fonte: (BASTOS, A. et. al., 2007)
3.8.1 Execução de Testes Unitários
Os testes unitários são os primeiros a serem executados, e devem ser
executados pelos programadores, os testes são criados durante a etapa de
desenvolvimento. O principal objetivo é testar isoladamente cada parte do software
para garantir que irão funcionar corretamente. [30]

63. 50
3.8.2 Execução dos Testes de Integração
Para Bastos, A.et. al. (2007) após serem executados todos os testes unitários,
os analistas devem executar os testes de integração e garantir que os componentes
integrados funcionarão com sucesso. Os itens a serem testados são:
 Validação de todos os links entre as diversas camadas;
 Controles de Segurança;
 Teste de carga e de desempenho / performance dos
diversos componentes, considerando-se os bancos de
dados e a rede;
 Sequência de inclusão, exclusão, consulta e alteração;
 Execução completa de uma transação;
 Testes para situações especiais, como, por exemplo,
um banco de dados vazio ou uma parte da rede fora do
ar;
 Acurácia dos dados de saída.
3.8.3 Execução dos Testes de Sistema
Após todos os testes de integração serem finalizados e realizados com
sucesso, começam os testes de sistema. O teste de sistema tem como papel
garantir que todos os requisitos do sistema foram atendidos e implantados
corretamente. E serão executados pela equipe de testes. (BASTOS, A. et. al., 2007)
3.1.1 Execução dos Testes de Aceitação
Serão executados pelos usuários ou gestores do sistema utilizando os
próprios requisitos definidos para validar. A equipe de testes pode participar desta
validação para auxiliar os usuários.
3.9 Relatórios de Teste
A norma IEEE 829-1998 define alguns relatórios para acompanhar o processo
de teste dos projetos:
 Log de Teste;
 Incidentes de Teste;
 Sumário de Teste;

64. 51
Figura 20 - Documentos necessários para o processo de Teste
Fonte: (BASTOS, A. et. al., 2007)
3.9.1 Relatório Log de Teste
Todas as informações que forem relevantes durante a etapa de testes devem
ser registradas neste relatório, é composto pelos seguintes itens:
 Identificador: identificador único e específico para o relatório, por
exemplo, o nome do sistema com número do release mais data e
hora do teste;

65. 52
 Descrição: identificar o que foi testado e o ambiente em que o
teste foi executado incluindo hardware, quantidade de memória
utilizada, etc;
 Atividades e eventos: para cada evento, identificar data/hora,
tempo utilizado e responsável;
 Descrição da execução: descrever o que foi feito e identificar os
responsáveis pela atividade incluindo testadores, observadores e
operadores;
 Resultados dos procedimentos: para cada execução, descrever
os resultados encontrados podendo ser sucesso ou não;
 Informações sobre ambiente de teste: informar qualquer
condição específica do ambiente de teste, caso seja necessário;
 Eventos imprevistos: descrever detalhadamente o que
aconteceu antes e depois de uma atividade ou evento inesperado.
[31]
3.9.2 Relatório Incidentes de Teste
O relatório de incidentes registra todas as informações de diferenças que
ocorreram entre o resultado determinado e o realizado durante a realização dos
casos de teste. Os itens apontados devem ser detalhados o máximo possível para
repassar à equipe de desenvolvimento, é composto pelos itens:
 Identificador do relatório: identificador único e específico para o
relatório, por exemplo, release testado mais o identificador de um
caso de teste;
 Sumário da ocorrência: uma breve descrição do incidente;
identificar os itens de teste envolvidos indicando sua versão, caso
seja necessário; adicionar referência para a especificação do caso de
teste, assim o desenvolvedor que for corrigir o defeito terá uma base
de documento de teste além do documento de requisitos e adicionar
também o relatório de log de teste, se necessário;
 Descrição do incidente: prover uma descrição do incidente
incluindo os seguintes itens:
 Entradas;
 Resultados esperados;
 Resultados encontrados;
 Problemas;
 Data e hora do incidente;
 Procedimentos para reproduzir o problema;
 Ambiente;
 Tentativas para repetir o problema;
 Testadores;
 Observadores.
Vale lembrar que outras informações podem ser incluídas sempre
que necessário e nem sempre todos os campos acima serão
necessários.

66. 53
 Impacto: indicar qual o impacto que o incidente terá no plano de
teste de execução podendo falhar, bloquear o(s) testes(s) ou até
mesmo uma possível mudança no caso de teste ou requisitos. Se
possível, informar a prioridade e severidade do incidente.Os
incidentes de teste devem ser armazenados em um repositório e,
caso necessário, revisar o relatório de incidentes de teste com as
partes interessadas. [31]
3.9.3 Relatório Sumário de Teste
O objetivo deste relatório é resumir todas as informações relacionadas aos
testes. É composto pelos itens:
 Identificador: identificador único e específico para o relatório, por
exemplo, release e/ou projeto testado;
 Sumário: sumarizar a evolução das atividades de teste
identificando os itens testados e o ambiente utilizado para execução
dos testes;
 Variações: informar qualquer procedimento diferente do que
estava especificado no plano de teste e procedimentos de teste;
especificar o motivo da utilização do procedimento alternativo;
 Avaliações do processo: avaliação resumida do processo
adotado contra o especificado no plano de teste; identificar as
funcionalidades ou combinações de teste que não foram exercitadas
explicando a razão; qualquer ocorrência que possa impactar na
qualidade do software/produto deve ser considerada;
 Sumário dos resultados: sumarizar os resultados de teste
identificando o número de casos de teste executados, número de
defeitos encontrados, número de defeitos fechados e abertos, etc;
 Avaliação do(s) teste(s): proporcionar uma avaliação global de
cada item, incluindo suas limitações. Essa avaliação deve ser
baseada nos resultados dos casos de teste e nos critérios de
aprovação/reprovação;
 Sumário de atividades: resumir os recursos envolvidos no
projeto de teste, número total de horas utilizadas no projeto, tempo
total utilizado para cada atividade principal, etc;
 Aprovações: listar o nome e títulos das pessoas responsáveis
pela aprovação do projeto de teste incluindo os relatórios. [31]
3.10 Ferramentas de Teste
3.9.4 Testes em Aplicações Web
 Selenium: É um software que permite criar scripts de execução dos
testes automatizados. Funciona como uma continuação do Firefox e possibilita
salvar, alterar e depurar todos os testes.
O download da ferramenta pode ser feito no site http://seleniumhq.org. [32]

67. 54
Figura 21 - Ferramenta Selenium
Fonte: [33]
 Watir: Foi desenvolvido para criar testes automatizados para ambiente
web. Para realizar os testes o ambiente é realizado diretamente no navegador
simulando a utilização do usuário. Pode ser usado nos browsers Internet Explorer,
Firefox, Linux e Mac.
O download da ferramenta pode ser feito no site http://wtr.rubyforge.org. [34]
 BadBoy: É uma ferramenta criada em C++, que armazena todas as
atividades realizadas em um browser, permitindo modificar parâmetros, inserir
textos, cor e etc.
O download da ferramenta pode ser feito no site http://www.badboy.com.au.
[35]

68. 55
Figura 22 - Ferramenta BadBoy
Fonte: [35]
 Canoo WebTest: É uma ferramenta que possui o código aberto para a
criação de testes de automação em ambiente web.
O download da ferramenta pode ser feito no site http://WEBtest.canoo.com.
[36]

69. 56
Figura 23 - Ferramenta Canoo WebTest
Fonte: [37]
3.9.5 Testes de Desempenho
 JMeter: É uma ferramenta da Apache que permite a execução de testes
de carga e stress do sistema.
O download da ferramenta pode ser feito no site
http://jakarta.apache.org/jmeter. [33]

70. 57
Figura 24 - Ferramenta JMeter
Fonte: [38]
3.9.6 Gerenciar Casos de Teste
 TestLink: É uma ferramenta que gerencia os casos de teste e execução
dos casos
O download da ferramenta pode ser feito no site http://www.teamst.org. [33]

71. 58
Figura 25 - Ferramenta TestLink
Fonte: [39]
3.9.7 Gerenciar Defeitos
 Bugzilla: É uma ferramenta que se baseia em Web aplicando suporte ao
Mozilla, identificando defeitos.
O download da ferramenta pode ser feito no site http://www.bugzilla.org. [40]

72. 59
Figura 26 - Ferramenta Bugzilla
Fonte: [40]
 Mantis: É uma ferramenta que gerencia defeitos encontrados pela equipe
de testes, foi desenvolvida em linguagem PHP e possui o código aberto.
O download da ferramenta pode ser feito no site http://www.mantisbt.org. [41]

73. 60
Figura 27 - Ferramenta Mantis
Fonte: [42]

74. 61
Considerações Gerais
Os problemas enfrentados pelas equipes de software são principalmente
causados pela falta de conhecimento e organização para gerar produtos com
qualidade.
Os gastos realizados com softwares “problemáticos” são muito maiores do
que se as empresas se preocupassem com o que está sendo feito.
A qualidade deve ser encarada como um investimento e uma forma de
produzir softwares melhores. Vale salientar que a equipe de Desenvolvimento deve
entender que a equipe de Testes irá aprimorar o trabalho realizado.
Todos os esforços realizados para se obter um software com qualidade são
muito mais rentáveis do que gerar trabalhos, manutenções e perder a confiabilidade
dos Clientes.

75. 62
Referências
Meios Impressos
 BARTIE, Alexandre. Garantia da Qualidade de Software. Rio de Janeiro:
Elsevier, 2002.
 BASTOS, Anderson; RIOS, Emerson; CRISTALLI, Ricardo; MOREIRA,
Trayahú. Base de conhecimento em teste de software. São Paulo: Martins,
2007.
 FIORINI, Soeli T.; STAA, Arnlt Von; BAPTISTA, Renan Martins. Engenharia
de Software com CMM. Rio de Janeiro: Brasport, 1998
 PRESSMAN, Roger. Engenharia de Software. São Paulo: Makron Books,
2002.
Meios Digitais
[1].(NOGUEIRA, 2010)
Disponível em:
http://infoblogs.com.br/frame/goframe.action?contentId=202979
Acessado em 25 de Setembro de 2011 às 20h27min
[2].(SILVA, 2010)
Disponível em:
http://www.artigonal.com/programacao-artigos/a-garantia-da-qualidade-de-software-no-
processo-de-desenvolvimento-1836900.html
Acessado em: 25 de Setembro de 2011 às 20h28min
[3].(TAVARES, 2011)
Disponível em:
http://qualidadeeteste.blogspot.com/2011/05/qualidade-de-software-parte-i.html
Acessado em: 25 de Setembro de 2011 às 21h: 00min

76. 63
[4].(GOMES N. S., 2010)
Disponível em:
http://www.fazenda.gov.br/ucp/pnafe/cst/arquivos/Qualidade_de_Soft.pdf
Acessado em: 25 de Setembro de 2011 às 21h10min
[5].(ENGHOLM, 2010)
Disponível em:
http://www.livrariacultura.com.br/imagem/capitulo/22123724.pdf
Acessado em 25 de Setembro de 2011 às 21h18min
[6].(SIMÕES, 2008)
Disponível em:
http://www.slideshare.net/alsimoes/qualidade-de-software
Acessado em 25 de Setembro de 2011 às 21h34min
[7].(LOURENÇO, 1997)
Disponível em:
http://qualidade-de-software.blogspot.com/2010/03/qualidade-de-software-um-compromisso-
da.html
Acessado em 25 de Setembro de 2011 às 21h48min
[8]. (ANDRADE, 2007)
Disponível em:
http://www.infoescola.com/informatica/bug/
Acessado em 12 de Novembro de 2011 às 16h54min
[9].(CAMPOS, 2008)
Disponível em:
http://www.linhadecodigo.com.br/artigo/1712/Qualidade-Qualidade-de-Software-e-Garantia-
da-Qualidade-de-Software-s%C3%A3o-as-mesmas-coisas.aspx
Acessado em 29 de Setembro de 2011 às 12h10min

77. 64
[10]. (WADA, 2007)
Disponível em:
http://www.cmqv.org/website/artigo.asp?cod=1461&idi=1&moe=212&id=4467
Acessado em 12 de Dezembro de 2011 às 17h07min
[11]. (ALCATEL-LUCENT, 2006)
Disponível em:
http://www.alcatel-lucent.com/wps/portal/BellLabs
Acessado em 16 de Novembro 2011 às 13h03min
[12]. (KOSCIANKI & SOARES, 2007)
Disponível em:
http://www.martinsfontespaulista.com.br/anexos/produtos/capitulos/241804.pdf
Acessado em 16 de Outubro de 2011 às 13h07min
[13]. (TAMASHIRO A. , 2010)
Disponível em:
http://dftestes.gershon.info/index.php/Cap%C3%ADtulo_1:_Testar_%C3%A9_t%C3%A3o_f%
C3%A1cil,_que_at%C3%A9_a_minha_m%C3%A3e_testaria!
Acessado em 16 de Outubro de 2011 às 13h21min
[14]. (GONÇALVES & BOAS, 2011)
Disponível em:
http://www.brasilacademico.com/tas/CMM_versao_1_2.pdf
Acessado em 12 de Novembro de 2011 às 18h16min
[15]. (SOUZA, 2010)
Disponível em:
http://www.blogcmmi.com.br/gestao/a-historia-do-sei
Acessado em 16 de Novembro às 13h11min

78. 65
[16]. (MARTINS, 2009)
Disponível em:
http://atitudereflexiva.wordpress.com/2009/07/22/falha-erro-e-defeito/
Acessado em 23 de Outubro de 2011 às 18h23min
[17]. (TAMASHIRO, Principais Diferenças entre Erro, Defeito e Falha no
Software, 2010)
Disponível em:
http://qabrasil.blogspot.com/2010/07/principais-diferencas-entre-erro.html
Acessado em 23 de Outubro de 2011 às 17h37min
[18]. (GALEOTE, 2010)
Disponível em:
http://blog.prasabermais.com/2010/05/18/qual-a-origem-dos-bugs-de-software/
Acessado em 23 de Outubro de 2011 às 19h21min
[19]. (GOMES E. , 2010)
Disponível em:
http://basedetestedesoftware.blogspot.com/2010/05/o-custo-da-qualidade-de-
software.html
Acessado em 23 de Outubro de 2011 às 22h32min
[20]. (INTELLECTUS, 2011)
Disponível em:
http://www.intellectusitservices.com.br/index.php/component/content/article/57-
frontpage/177-ipad-mania-in-the-uk-as-thousands-await-the-launch-
Acessado em 30 de Outubro de 2011 às 11h25min
[21]. (MSW, 2000)
Disponível em:
http://www.mswconsult.com.br/quali_4.html
Acessado em 30 de Outubro de 2011 às 11h17min

79. 66
[22]. (NOGUEIRA, Casos de Teste, 2007)
Disponível em:
http://www.testexpert.com.br/?q=node/90
Acessado em 30 de Outubro de 2011 às 11h23min
[23]. (DAVIDSON, 2011)
Disponível em:
http://rederia.net/2011/07/23/a-ascensao-do-teste-de-software/
Acessado em 30 de Outubro de 2011 às 12h33min
[24]. (TESTEXPERT apud ComputerWorld, 2007)
Disponível em:
http://www.testexpert.com.br/?q=node/422
Acessado em 30 de Outubro de 2011 às 17h51min
[25]. (LOPES & CARNEIRO)
Disponível em:
http://www.univicosa.com.br/arquivos_internos/artigos/ImportanciadoProcessodeTest
edeSoftwareemTI.pdf
Acessado em 30 de Outubro de 2011 às 18h31min
[26]. (ALMEIDA, 2010)
Disponível em:
http://www.linhadecodigo.com.br/Artigo.aspx?id=2775
Acessado em 05 de Novembro de 2011 às 14h30min
[27]. (TOZELLI, 2008)
Disponível em:
http://qualidade-de-software.blogspot.com/2010/01/teste-de-caixa-branca.html
Acessado em 05 de Novembro de 2011 às 14h10min

80. 67
[28]. (LOURENÇO, Fases de Testes, 2010)
Disponível em:
http://www.artigonal.com/programacao-artigos/processo-de-teste-de-software-
505672.html
Acessado em 05 de Novembro de 2011 às 15h36min
[29]. (AGAPITO, 2007)
Disponível em:
http://www.testexpert.com.br/?q=node/366
Acessado em 05 de Novembro de 2011 às 17h02min
[30]. (SILVA F. R.)
Disponível em:
http://www.devmedia.com.br/post-22284-Testes-de-software-Teste-Unitario.html
Acessado em 06 de Novembro de 2011 às 13h15min
[31]. (QUEZADA, 2009)
Disponível em:
http://gustavoquezada.blogspot.com/2009/08/para-continuar-com-o-assunto-relatorio.html
Acessado em 06 de Novembro de 2011 às 15h09min
[32]. (CAMPOS R. , 2011)
Disponível em:
http://www.profissionaisti.com.br/2011/03/testes-automatizados-utilizando-selenium-ide/
Acessado em 06 de Novembro de 2011 às 15h23min
[33]. (COSTA, 2008)
Disponível em:
http://www.testexpert.com.br/?q=node/591
Acessado em 06 de Novembro de 2011 às 15h25min
[34]. (SOARES, 2007)
Disponível em:

81. 68
http://www.testexpert.com.br/?q=node/383
Acessado em 06 de Novembro de 2011 às 15h38min
[35]. (HEINEBERG, 2008)
Disponível em:
http://www.testexpert.com.br/?q=node/383
Acessado em 06 de Novembro de 2011 às 15h49min
[36]. (PAIVA, 2011)
Disponível em:
http://teste-software.blogspot.com/2011/06/abaixo-listaremos-algumas-ferrametnas.html
Acessado em 06 de Novembro de 2011 às 15h59min
[37]. (FREITAS, 2008)
Disponível em:
http://wilsondev.blogspot.com/2008/07/automao-de-testes-com-canoo-webtest.html
Acessado em 06 de Novembro de 2011 às 16h00min
[38]. (JAVA, 2011)
Disponível em:
http://blog.marcoreis.net/2011/08/05/tutorial-rapido-como-rodar-teste-de-carga-com-jmeter/
Acessado em 06 de Novembro de 2011 às 16h10min
[39]. (RIBEIRO, 2010)
Disponível em:
http://blog.marcoreis.net/2011/08/05/tutorial-rapido-como-rodar-teste-de-carga-com-jmeter/
Acessado em 06 de Novembro de 2011 às 16h10min
[40]. (MOZILLA EUROPE)
Disponível em:
http://www.mozilla-europe.org/pt/products/bugzilla/
Acessado em 06 de Novembro de 2011 às 16h24min
[41]. (FERNANDO, 2008)

82. 69
Disponível em:
http://www.testexpert.com.br/?q=node/677
Acessado em 06 de Novembro de 2011 às 16h29min
[42]. (CAETANO)
Disponível em:
http://www.devmedia.com.br/articles/viewcomp.asp?comp=8036
Acessado em 06 de Novembro de 2011 às 16h31min

83. 70
TERMO DE COMPROMISSO E RESPONSABILIDADE
Guarulhos, 16 de Novembro de 2011
Pelo presente, eu abaixo assinado declara, sob as penas da lei, que o
presente trabalho é inédito e original, desenvolvido especialmente para os fins
educacionais a que se destina e que, sob nenhuma hipótese, fere o direito de autoria
de outrem.
Para maior clareza, firmo o presente termo de originalidade.
Débony Schmidt
Autenticidade e exclusividade sob as penas da Lei 9610/98