UNIVERSIDADE DO SUL DE SANTA CATARINA
ANDERSON ANTONIO DO NASCIMENTO DA SILVA
MARIANA BENEDETT SEVERINO
IMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE
UM SISTEMA DE GESTÃO DE TESTES.
Tubarão
2010
ANDERSON ANTONIO DO NASCIMENTO DA SILVA
MARIANA BENEDETT SEVERINO
IMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE
UM SISTEMA DE GESTÃO DE TESTES.
Trabalho de Conclusão de Curso apresentado ao Curso
de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina, como requisito
parcial à obtenção do título de Bacharel em Sistemas de
Informação.
Orientador: Prof. Edjandir Corrêa Costa.
Tubarão
2010
ANDERSON ANTONIO DO NASCIMENTO DA SILVA
MARIANA BENEDETT SEVERINO
IMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE
UM SISTEMA DE GESTÃO DE TESTES.
Este Trabalho de Conclusão de Curso foi julgado
adequado à obtenção do título de Bacharel em Sistemas
de Informação e aprovado em sua forma final pelo
Curso de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina.
Tubarão, 14 de junho de 2010.
______________________________________________________
Prof. Rafael Avila Faraco.
Universidade do Sul de Santa Catarina
______________________________________________________
Prof. Eder Cachoeira.
Universidade do Sul de Santa Catarina
______________________________________________________
Prof. Alessandro Zanini.
Universidade do Sul de Santa Catarina
Dedico este trabalho aos meus pais (José e
Ana) por sempre terem me apoiado e
incentivado não somente para a conclusão
deste projeto, mas como em toda minha vida.
(Anderson)
Dedico este trabalho aos meus pais e toda a
minha família pelo apoio, auxílio e educação,
que me fez chegar até aqui. (Mariana)
AGRADECIMENTOS
Em primeiro lugar a Deus por nos ter dado forças para percorrer esse longo e
dificultoso trajeto, muito importante em nossas vidas profissionais.
A nossos pais devemos gratidão eterna por nos guiarem no caminho certo, pelo
apoio e incentivo que nos ajudou a seguir em frente.
Aos nossos irmãos, familiares e amigos que nos auxiliaram nesse período.
Aos professores e colegas que compartilharam conosco seus conhecimentos e
experiências.
Ao nosso orientador Edjandir Corrêa Costa, que nos ajudou em momentos de
dúvidas, fornecendo ideias que somaram no projeto.
"Não temos em nossas mãos a solução para todos os problemas do mundo; mas,
diante dos problemas do mundo, temos nossas mãos.”(AUTOR DESCONHECIDO).
RESUMO
O propósito deste trabalho é fornecer uma ferramenta contendo um método simplificado que
possa auxiliar na implantação de um processo de Testes de software. A ferramenta dará ao
gerente segurança e capacidade de medir a qualidade do seu produto. Neste trabalho,
especificamente, a ferramenta elaborada pelos acadêmicos será um auxiliar no processo de
Testes de software. A referida ferramenta foi desenvolvida a partir de estudos bibliográficos e
eletrônicos, que serviram de base para a sua construção. A ferramenta em questão atua sob os
níveis G e F do modelo de maturidade de software MPS.BR. A qualidade do software se torna
hoje uma área de extrema importância para as organizações consumidoras que pretendem
garantir o seu espaço no mercado de desenvolvimento de software. Por conta disso, estas
organizações vêm procurando métodos e processos que possam avaliar a qualidade do seu
produto final. A área de Testes se mostra peça chave para a validação e a garantia de que o
produto está apto a ser entregue ao cliente da forma como foi solicitado. Observa-se hoje a
imaturidade que as empresas têm na área Testes. Grande parte delas realiza seus Testes
juntamente com o desenvolvimento de software e, até mesmo, utilizando o usuário final do
sistema, o que não é recomendado pelos conceituados processos de qualidade de software.
Nesse sentido, os autores dessa monografia acreditam na importância dessa ferramenta para o
desenvolvimento de softwares com qualidade.
Palavras-chave: Qualidade de software. Testes de software. Processo de Teste.
ABSTRACT
The purpose of this paper is to provide a tool containing a simplified method that can
assist in the implementation of a process of Testing Software. The tool will give the manager
security and ability to measure the quality of your product. In this work, specifically, the tool
developed by academiwill be a help in the process of Testing Software. This tool was
developed from studies of bibliographic and electronic, which formed the basis for its
construction. The tool in question operates under the G and F levels of maturity model for
software MPS.BR. The quality of the software now becomes an area of extreme importance
for organizations to consumers wanting to ensure their place in the market for software
development. Because of this, these organizations have been searching for methods and
processes that can assess the quality of your final product. The area of Testing proves is a key
piece for the validation and assurance that the product is suitable to be delivered to the
customer as it was requested. It is observed today immaturity that companies have in the field
Tests. Many of them realize their tests along with the development of software and even using
the end user of the system, which is not recommended by reputable software quality
processes. In this sense, the authors of this monograph believe in the importance of this tool
for the development of software quality.
Key words: software quality. Testing softwares. Testing process.
LISTA DE ILUSTRAÇÕES
Figura 1 - Pessoas envolvidas dentro da qualidade .................................................................. 23
Esquema 1 - Sincronismo entre desenvolvimento e Gerenciamento de Qualidade. ................ 24
Quadro 1 - Gerenciamento da Qualidade do Projeto segundo o PMI. ..................................... 25
Quadro 2 - Padrões de produto e de processo .......................................................................... 26
Fluxograma 1 - Fluxo do gerenciamento da qualidade do processo ........................................ 27
Figura 2 - Atributos de Qualidade do software ........................................................................ 28
Esquema 2 - Padrões de intercâmbio de documentos .............................................................. 29
Esquema 3 - Análise de Riscos ................................................................................................ 33
Gráfico 1 - Resultados da avaliação em abrangência - ameaças .............................................. 34
Figura 3 - Localização da qualidade dentro da engenharia. ..................................................... 37
Gráfico 2 - Custo de correções ................................................................................................. 38
Figura 4 - Defeito x Erro x Falha ............................................................................................. 39
Figura 5 - Diferentes interpretações ao longo do ciclo de desenvolvimento de um software. . 42
Quadro 3 - Exemplo de um Caso de Teste simples. ................................................................. 46
Figura 6 - Componentes existentes em Testes caixa preta. ...................................................... 47
Esquema 4 - Representação dos módulos de Teste .................................................................. 50
Esquema 5 - Testes de integração. ........................................................................................... 51
Figura 7 - Componentes existentes em Testes caixa branca. ................................................... 57
Figura 8 - Níveis de refinamento. ............................................................................................. 58
Figura 9 - Laços existentes nos Testes de ciclo. ....................................................................... 60
Esquema 6 - Componentes do modelo MPS. ........................................................................... 63
Diagrama 1 - Visão geral do Processo de Teste. ...................................................................... 73
Diagrama 2 - Visão detalhada do processo de inicialização .................................................... 74
Quadro 4 - Caso de Teste ......................................................................................................... 76
Quadro 5 - Plano de Teste ........................................................................................................ 77
Diagrama 3 - Visão detalhada do processo de Execução. ........................................................ 78
Diagrama 4 - Visão detalhada do processo de Finalização. ..................................................... 80
Figura 10 - Arquitetura de aplicações em padrão de projeto MVC.......................................... 83
Esquema 7 - Arquitetura da aplicação. ..................................................................................... 84
Diagrama 5 - Diagrama de Casos de Uso. ................................................................................ 85
Quadro 6 - Manter Plano de Teste. ........................................................................................... 86
Quadro 7 - Manter Plano de Teste. ........................................................................................... 86
Quadro 8 - Manter Plano de Teste. ........................................................................................... 87
Quadro 9 - Manter Caso de Teste ............................................................................................. 87
Quadro 10 - Executar Plano de Teste ....................................................................................... 88
Quadro 11 - Gerenciar processo. .............................................................................................. 88
Quadro 12 - Manter Usuário e Grupo. ...................................................................................... 89
Diagrama 6 - Diagrama de domínio de Classe. ........................................................................ 90
Quadro 13 - Descrição das classes ........................................................................................... 90
Diagrama 7 - Diagrama geral de pacotes.................................................................................. 92
Diagrama 8 - Diagrama de pacotes entitys. .............................................................................. 93
Diagrama 9 - Diagrama de pacotes repository. ........................................................................ 94
Diagrama 10 - Diagrama de pacotes service. ........................................................................... 95
Diagrama 11 - Diagrama de pacotes DAO. .............................................................................. 96
Diagrama 12 - Pacotes manager. .............................................................................................. 96
Diagrama 13 - Pacotes servlet. ................................................................................................. 97
Diagrama 14 - Diagrama de pacotes infrastructure. ................................................................ 97
Diagrama 15 - Diagrama de pacotes view. ............................................................................... 98
Diagrama 16 - Modelo de ER- Relacionamento entre tabelas. ................................................ 99
Figura 11 - Tela de login ........................................................................................................ 105
Figura 12 - Menu do usuário gerente de teste ........................................................................ 106
Figura 13 - Menu do usuário analista de teste ........................................................................ 106
Figura 14 - Menu do usuário Tester ....................................................................................... 107
Figura 15 - Lista de usuários .................................................................................................. 107
Figura 16 - Cadastro de usuário .............................................................................................. 108
Figura 17 - Lista de grupo de usuários ................................................................................... 108
Figura 18 - Cadastro de grupo de usuário............................................................................... 109
Figura 19 - Lista tipo de teste ................................................................................................. 110
Figura 20 - Cadastro de tipo de teste ...................................................................................... 110
Figura 21 - Lista de prioridade ............................................................................................... 111
Figura 22 - Cadastro de prioridade ......................................................................................... 111
Figura 23 - Lista de plano de teste .......................................................................................... 112
Figura 24 - Cadastro de plano de teste ................................................................................... 113
Figura 25 - Lista de caso de teste ........................................................................................... 114
Figura 26 - Cadastro de caso de teste ..................................................................................... 115
Figura 27 - Lista de ciclos de execução do plano de teste ...................................................... 115
Figura 28 - Execução do plano de teste .................................................................................. 116
Figura 29 - Notas da execução do plano de teste ................................................................... 117
Figura 30 - Filtros do relatório de log de Teste ...................................................................... 117
Figura 31 - Visualização do relatório de log de Teste ............................................................ 118
Figura 32 - Filtros do relatório de Incidentes ......................................................................... 118
Figura 33 - Visualização do relatório de incidentes ............................................................... 118
Figura 34 - Filtros do relatório de sumário ............................................................................. 119
Figura 35 – Visualização do relatório de sumário .................................................................. 119
LISTA DE TABELAS
Tabela 1 - Resultados da avaliação em abrangência por área de processo. .............................. 34
Tabela 2 - Refinamento utilizando Valores-Limites. ............................................................... 54
Tabela 3 - Exemplo de uma tabela de decisão.......................................................................... 55
Tabela 4 - Tabela dos representando níveis do MPS.BR. ........................................................ 64
Tabela 5 - Dicionário de dados entidade usuário. .................................................................. 100
Tabela 6 - Dicionário de dados entidade prioridade. .............................................................. 100
Tabela 7 - Dicionário de dados entidade tipos de Teste. ........................................................ 101
Tabela 8 - Dicionário de dados entidade grupo. ..................................................................... 101
Tabela 9 - Dicionário de dados entidade de ligação entre grupo e usuário. ........................... 101
Tabela 10 - Dicionário de dados entidade plano de Teste ...................................................... 102
Tabela 11 - Dicionário de dados entidade caso de Teste ........................................................ 103
Tabela 12 - Dicionário de dados entidade ciclo de Teste ....................................................... 104
Tabela 13 - Dicionário de dados entidade ciclo de Teste notas.............................................. 104
LISTA DE SIGLAS
BID - Banco Interamericano de Desenvolvimento.
CMMI - Capability Maturity Model Integration
ETM - Equipe Técnica do Modelo.
FCC - Fórum de Credenciamento e Controle.
FINEP - Financiadora de Estudos e Projetos.
IA - Instituições Avaliadoras.
IEE - Institute of Electrical and Electronics Engineers
II - Instituições Implementadoras.
MA-MPS - Modelo de Avaliação - Melhoria de Processo de Software.
MCT - Ministério da Ciência e Tecnologia.
MN-MPS - Modelo de Negocio - Melhoria de Processo de Software.
MPS.BR - Melhoria de Processo de Software Brasileiro.
MR-MPS - Modelo de Referencia - Melhoria de Processo de Software.
MVC – Model View Controler – Padrao de projeto
NIST - National Institute of Standards and Technology
RIA – Rich Internet Application
SOFTEX - Associação para Promoção da Excelência do Software Brasileiro.
SUMÁRIO
1 INTRODUÇÃO................................................................................................................. 16
1.1 OBJETIVOS .................................................................................................................... 17
1.1.2 Objetivo Geral ............................................................................................................. 17
1.1.3 Objetivos Específicos................................................................................................... 18
1.2 RESULTADOS ESPERADOS ........................................................................................ 18
1.3 JUSTIFICATIVA ............................................................................................................ 18
1.4 METODOLOGIA ............................................................................................................ 19
1.5 APRESENTAÇÃO DO DOCUMENTO ......................................................................... 20
2 QUALIDADE DE SOFTWARE....................................................................................... 22
2.1 GERENCIAMENTO DE QUALIDADE ........................................................................ 23
2.1.1 Padrões de Qualidade ................................................................................................. 25
2.1.2 Qualidade do Processo e do Produto. ........................................................................ 26
2.1.3 O planejamento de Qualidade .................................................................................... 27
2.1.4 Padrões de documentação .......................................................................................... 29
2.1.5 Medição e Métricas ..................................................................................................... 30
2.2 SOFTWARE QUALITY ASSURANCE .......................................................................... 31
2.3 ANÁLISE DE RISCOS ................................................................................................... 31
2.4 CONSIDERAÇÕES FINAIS ........................................................................................... 35
3 TESTES ............................................................................................................................. 36
3.1 VISÃO DE TESTES DE SOFTWARE ............................................................................ 36
3.1.1 Conceitos de Testes...................................................................................................... 38
3.1.2 Defeitos do desenvolvimento ...................................................................................... 41
3.1.3 Gerenciamento de Testes ............................................................................................ 43
3.2 REQUISITOS E CASOS DE TESTES ........................................................................... 43
3.2.1 Definindo os requisitos ................................................................................................ 44
3.2.2 Definindo casos de testes ............................................................................................. 44
3.3 TIPOS DE TESTES ......................................................................................................... 46
3.3.1 Teste Funcional ............................................................................................................ 47
3.3.2 Testes de Unidade ........................................................................................................ 48
3.3.3 Testes de Sistema ......................................................................................................... 48
3.3.4 Testes de Aceitação...................................................................................................... 49
3.3.5 Testes de Integração .................................................................................................... 49
3.3.5.1 Não Incremental ......................................................................................................... 49
3.3.5.2 Incremental ................................................................................................................. 50
3.3.5.3 Integração Top-down.................................................................................................. 51
3.3.5.4 Integração Bottom-up ................................................................................................. 52
3.3.6 Teste de Regressão ...................................................................................................... 52
3.3.7 Teste de Estresse .......................................................................................................... 53
3.3.8 Análise do Valor Limite ou Fronteira ....................................................................... 54
3.3.9 Tabela de decisão ......................................................................................................... 55
3.3.10 Testes de Semântica .................................................................................................... 56
3.3.11 Testes Estruturais ........................................................................................................ 56
3.3.11.1 Técnicas de Testes Estruturais .................................................................................... 57
3.3.11.1.1 Cobertura de Linha de Código ................................................................................ 58
3.3.11.1.2 Cobertura de Caminhos ........................................................................................... 58
3.3.11.1.3 Cobertura de Decisões ............................................................................................ 59
3.3.11.1.4 Cobertura de Condições .......................................................................................... 59
3.3.11.1.5 Testes de Ciclos ....................................................................................................... 59
3.4 CONSIDERAÇÕES FINAIS ........................................................................................... 60
4 METODOLOGIA UTILIZADA: MPS.BR .................................................................... 62
4.1 NIVEL G – PARCIALMENTE GERENCIADO ............................................................ 64
4.1.1 Gerência de Projetos (GPR) ....................................................................................... 65
4.1.2 Gerência de Requisitos (GRE) ................................................................................... 65
4.2 NÍVEL F – GERENCIADO ............................................................................................ 66
4.2.1 Aquisição (AQU) ......................................................................................................... 66
4.2.2 Gerência de Configuração (GCO) ............................................................................. 67
4.2.3 Garantia de Qualidade (GQA) ................................................................................... 68
4.2.4 Medição (MED) ........................................................................................................... 69
4.3 CONSIDERAÇÕES FINAIS ........................................................................................... 70
5 DEFINIÇÃO E ELABORAÇÃO DO PROCESSO DE TESTE .................................. 71
5.1 PROCESSO ..................................................................................................................... 71
5.2 FASES .............................................................................................................................. 71
5.2.1 Papéis do Processo ....................................................................................................... 72
5.2.2 Inicialização ................................................................................................................. 74
5.2.3 Execução ....................................................................................................................... 78
5.2.4 Finalização ................................................................................................................... 80
6 DESENVOLVIMENTO DO SISTEMA DE TESTES .................................................. 81
6.1 VISÃO GERAL ............................................................................................................... 82
6.1.1 Arquitetura .................................................................................................................. 82
6.2 MODELO CONCEITUAL .............................................................................................. 84
6.2.1 Diagrama de Caso de Uso ........................................................................................... 84
6.2.2 Descrição dos Casos de Uso ........................................................................................ 85
6.2.2.1 Manter Tipos de Teste ................................................................................................ 86
6.2.2.2 Manter Prioridade ....................................................................................................... 86
6.2.2.3 Manter Plano de Teste ................................................................................................ 87
6.2.2.4 Manter Caso de Teste ................................................................................................. 87
6.2.2.5 Executar Plano de Teste ............................................................................................. 88
6.2.2.6 Gerenciar Processos.................................................................................................... 88
6.2.2.7 Manter usuário e grupo ............................................................................................... 89
6.2.3 Modelo de Domínio de Classe .................................................................................... 90
6.3 PROJETO FÍSICO ........................................................................................................... 91
6.3.1 Diagrama de pacotes ................................................................................................... 91
6.3.2 Modelo E.R. ................................................................................................................. 99
6.3.3 Dicionário de Dados .................................................................................................. 100
7 VALIDAÇÃO DA FERRAMENTA ............................................................................. 105
8 CONCLUSÃO ................................................................................................................. 120
REFERÊNCIAS ................................................................................................................... 122
16
1 INTRODUÇÃO
Com a evolução tecnológica de hoje e a velocidade da comunicação imposta pela
modernização, o fator Qualidade está mais elevado na pirâmide estratégica, tornando-se
fundamental para assegurar a estabilidade de uma empresa. À medida que o acesso ao
conhecimento se torna mais ágil, há também uma preocupação maior com a qualidade de um
produto/serviço oferecido. Comprometimento este que faz com que as empresas busquem por
planos agregando maior qualidade possível em seus projetos, com objetivo de satisfazer as
expectativas do cliente.
Tratando de qualidade de software, pode-se dizer que está ligada diretamente ao
desenvolvimento. Sendo assim, o foco de qualidade de uma aplicação está necessariamente
vinculado à melhoria no processo de desenvolvimento do produto abrangendo conformidade
com padrões, definição de práticas consistentes, garantia de expectativas, Testes, revisões
técnicas, entre outros.
Um dos papéis extremamente importantes desempenhados durante o processo de
desenvolvimento ligado à qualidade do software é o processo de Testes de software. Ele
executa uma análise e verificação, assegurando que o software cumpra com o que foi
especificado durante o período de análise e atenda a necessidade do cliente.
Kruchten, em seu livro The rational unified process, mencionado em Bastos e
outros (2007), propõe que existem pelo menos três dimensões de qualidade que precisam ser
consideradas antes de se iniciar qualquer ciclo de Testes:
Confiança: o sistema é resistente a falhas durante a execução, isto é, não entra em
loop, não interrompe a execução por falta de recursos, etc.
Funcionalidade: o sistema se comporta conforme o esperado e definido em seus
requisitos.
Performance: o sistema tem um tempo de resposta adequado e aceitável, mesmo
quando submetido a um volume de processamento próximo de situações reais ou de
pico.
Entre as décadas de 1970 a 1990, os Testes eram executados pelos próprios
desenvolvedores, com um nível de cobertura bastante reduzido. Muitas vezes, os usuários
finais eram envolvidos nestes Testes. Isto gerava uma grande incidência de erros, que eram
corrigidos no momento em que o sistema já estava em produção, ou seja, no momento em que
esta correção se tornaria mais cara.
17
Os problemas se tornaram maiores a partir do momento em que surgiram as
aplicações para internet e sistemas mais complexos, devido a novas tecnologias. Estes fatores
fizeram com que as organizações começassem a busca pela melhoria na qualidade do software
desenvolvido por seus técnicos. Um dos caminhos seria um processo paralelo para
aprimoramento da atividade de Teste. (BASTOS et al., 2007).
Foi utilizado nesta monografia o conceito de Testes de Molinari (2008), que trata
da gerência, planejamento, controle e execução dos Testes em todos os níveis, de modo a
garantir a implementação (projeto, desenvolvimento e entrega).
Neste trabalho será desenvolvido uma ferramenta auxiliar no processo de Testes.
Aplicada a ela, um modelo de Testes aderente até o segundo nível da metodologia MPS.BR
(Melhoria de processo de Software Brasileiro).
1.1 OBJETIVOS
Serão apresentados neste momento os objetivos referentes ao trabalho
desenvolvido.
1.1.2 Objetivo Geral
Desenvolver, a partir de um estudo sobre processo de Testes, e após uma pesquisa
sobre as ferramentas de Testes já utilizadas, um software para apoio à gestão de Testes,
implementando um processo aderente ao modelo MPS.BR até o nível F.
18
1.1.3 Objetivos Específicos
Realizar um estudo em Testes de Software e na metodologia a ser utilizada,
verificando sua viabilidade;
Definir um processo de Testes de software que descreva as atividades a serem
executadas utilizando os conceitos de Testes de software e MPS.BR;
Realizar a análise e desenvolvimento do sistema a ser criado baseado no processo de
Testes já definido;
Realizar uma validação da ferramenta desenvolvida.
1.2 RESULTADOS ESPERADOS
Partindo-se das hipóteses de que as ferramentas existentes são poucas, ou seja,
insuficientes para atender à necessidade de gerenciamento do processo de Testes; e de que
elas não oferecem um processo simplificado capaz de auxiliar na implantação do processo de
Testes de software, os acadêmicos envolvidos nesta pesquisa optaram por desenvolver uma
nova ferramenta.
Espera-se que a solução consista em um método simplificado para implantação de
um processo de Testes, atendendo às áreas de Planejamento de Testes, Execução dos Testes e
Análise do Produto testado, assim como as demais figuras envolvidas no processo de Testes.
Por fim, a ferramenta permitirá o acompanhamento do processo por meio de
relatórios que devem auxiliar na tomada de decisão.
1.3 JUSTIFICATIVA
Testar um software hoje vai além de um modismo ou uma “simples prática”.
Afinal, não há outra forma de garantir a funcionalidade de um software sem antes testá-la.
19
Observa-se hoje que, para garantir a qualidade de um sistema, é necessário lidar com vários
fatores que convivem em um ambiente, tais como: client-serves, mainframe e agora a Web.
(MOLINARI, 2008).
Existem hoje, no mercado de trabalho, inúmeros profissionais com experiência em
uma determinada área, executando Testes funcionais em uma rotina que domina, e com isso,
passa a executá-la sempre. Estes são chamados os Testes viciados. É essa a realidade de
muitos analistas de softwares, mas que tende a mudar em breve à medida que se depara com
aplicativos cada vez maiores, em diversos ambientes e de alta complexibilidade.
Um dos principais objetivos na área de Testes é reduzir erros e agregar qualidade
ao software. Para isso, é necessário um processo de Testes que se adapte da melhor forma ao
processo de desenvolvimento e que, além da organização, possa enquadrar os diversos tipos
de Testes cabíveis a cada tipo de aplicação. Cabe aqui um software que englobe estes
requisitos e que possa auxiliar de forma precisa uma empresa que planeja melhorar a
qualidade do seu software, proporcionando um ganho real em seus produtos.
Baseando-se nas ideias acima mencionadas, acredita-se na importância da criação
dessa ferramenta para auxiliar o gerenciamento de Testes em nível empresarial.
1.4 METODOLOGIA
A monografia será desenvolvida basicamente em quatro etapas. Na primeira,
haverá uma reunião da equipe para estruturar a idéia inicial e garantir a sua viabilidade. Após
obter a aprovação da proposta entregue ao professor da disciplina Projetos I, é iniciada a
segunda etapa, que consiste em montar a primeira parte, o Pré-Projeto. Este acontecerá na
seguinte ordem:
a) Pesquisa sobre as metodologias de maturidade de software e gerenciamento de
projetos, conceitos e processos que envolvem o Teste de software;
b) Estudo sobre ferramentas existentes relacionadas à gestão de Testes; Testes
automatizados e planejamento;
c) Estudo sobre as tecnologias que poderão ser aplicadas no desenvolvimento do
software final;
d) Início o pré-projeto que deverá conter os tópicos Introdução e Revisão bibliográfica;
20
e) Entrega da parte inicial do pré-projeto para avaliação.
Na terceira etapa ocorrerão os ajustes:
a) Ajustar o documento conforme erros/sugestões apontadas pelos avaliadores;
b) Iniciar a modelagem nível conceitual do projeto, esta que representa a segunda parte
do Pré-Projeto;
c) Finalizar a modelagem nível conceitual do projeto;
d) Entregar para avaliação o pré-projeto finalizado;
Na quarta e última etapa, após a avaliação e aprovação do Projeto de Conclusão
de Curso I, dar-se-á início à construção da ferramenta.
a) Definição das tecnologias que serão aplicadas no desenvolvimento da ferramenta;
b) Construção do banco de dados, baseado no modelo relacional existente no projeto
conceitual;
c) Construção da aplicação;
d) Validação da ferramenta.
1.5 APRESENTAÇÃO DO DOCUMENTO
Este documento foi dividido e organizado em capítulos para que o leitor possa
compreender melhor o assunto que será abordado.
O capítulo em questão apresenta o problema, o objetivo do trabalho, sua
abrangência e o motivo da sua realização. No capítulo capitulo seguinte, será abordado o
conceito Qualidade de Software, abrangendo sua definição e importância dentro do processo
de desenvolvimento de software. O terceiro capítulo enfatiza os Testes, etapa que compõe o
item “qualidade de software” sendo uma das áreas mais importantes para garantia da
qualidade de um produto. Aborda ainda tipos de Testes, explicando a importância dos casos
de Testes no momento em que é realizado um Teste.
O capítulo quatro apresenta a metodologia utilizada como embasamento teórico
para a definição do processo e a definição do processo em si. Serão citadas as etapas do
processo de gestão de Testes definido, apontando as atividades e papéis que compõem cada
etapa.
21
O quinto capítulo aborda o processo criado, demonstrando todas as etapas
contidas, tais como Inicialização, Execução e Finalização. Cada etapa contém todas as
atividades a serem executadas.
O sexto capítulo apresenta o sistema construído conforme o processo
anteriormente criado e mencionado no capítulo anterior, sua arquitetura e modelagem. Após
isso, será demonstrada a validação do sistema, exemplificando cada etapa do sistema por meio
de suas telas.
Conforme orientação recebida, este trabalho apresentará breves considerações
finais para cada capitulo, pelo fato de cada um deles apresentar uma finalidade diferente.
Por fim, serão apresentadas as considerações finais relativas ao trabalho em sua
totalidade, capítulo no qual serão expostas ideias confirmando (ou não) as hipóteses e
objetivos levantados, bem como as prováveis contribuições deste trabalho na área de
desenvolvimento de software.
22
2 QUALIDADE DE SOFTWARE
De acordo com a NBR ISO 9000:2000 (2000), qualidade é o grau no qual um
conjunto de características inerentes satisfaz os requisitos mencionados. Ou seja, pode-se
dizer que, quando um produto e/ou serviço cumpre com os requisitos levantados atendendo a
necessidade para o qual foi projetado, este produto e/ou serviço possui qualidade.
Rocha acrescenta outras considerações sobre o conceito Qualidade:
No processo de desenvolvimento de software a comunicação da informação passa
por diversas fases e pessoas, e ela pode sofrer transformações o que propicia que
ocorram enganos, interpretações errôneas e outras faltas, que podem desencadear
falhas. Com isso é possível afirmar que ao longo de todo o processo de
desenvolvimento de software, defeitos podem ser inseridos, então se torna
necessário rastreá-los o quanto antes. (ROCHA, 2001, p. 66).
A qualidade de software pode ser definida ainda como a “Conformidade a
requisitos funcionais e de desempenho explicitamente declarados, a padrões de
desenvolvimento claramente documentados e a características implícitas que são esperadas de
todo software profissionalmente desenvolvido.” (PRESSMAN, 1995, p. 724).
Na opinião de Sommerville (2003), atingir um nível de qualidade é o objetivo da
maioria das organizações. Não é aceitável entregar produtos de baixa qualidade e que tenham
que ser reparados após a entrega ao cliente. Assim como qualquer outro produto
manufaturado como um Carro, eletrônicos, eletrodomésticos e computadores, o software é um
produto pelo qual o cliente exige um bom funcionamento. Entretanto, tratar de qualidade de
software não é uma tarefa simples, pois envolve uma série de conceitos complexos e questões
que devem ser avaliadas. Durante o desenvolvimento de um software, é comum encontrar
obstáculos que possam impedir que o software seja entregue conforme sua especificação.
A especificação deve ser orientada em direção às características do produto que o
cliente deseja. Contudo, a organização de desenvolvimento pede também requisitos (como os
requisitos de facilidade de manutenção) que não estão incluídos na especificação.
Não se sabe como especificar certas características de qualidade (por exemplo, a
facilidade de manutenção) de uma maneira que não seja ambígua.
“[...] é muito difícil escrever uma especificação completa de software. Portanto,
embora um produto de software possa atender à sua especificação, os usuários
podem não considerá-lo como um produto de alta qualidade.” Sommerville (2007, p.
458).
23
Com base nas dificuldades, o responsável pela gerência de qualidade do software
e os gerentes de cada área do desenvolvimento trabalham de forma a encontrar melhores
métodos para aplicar às especificações, buscando atender a todos.
Figura 1 - Pessoas envolvidas dentro da qualidade
Fonte: Falbo, 2008.
O Gerente de Qualidade exerce seu papel apoiando todos os envolvidos no projeto
e encorajando-os em sua atividade.
2.1 GERENCIAMENTO DE QUALIDADE
Como foi dito anteriormente, é de responsabilidade dos gerentes a garantia do
nível de qualidade do seu produto. Eles visam criar uma Cultura de Qualidade, aplicando
uma série de padrões e procedimentos que deverão ser utilizados durante a execução de um
projeto. Conforme Sommerville (2003), o gerenciamento de qualidade parte de três atividades
principais:
a) Garantia de Qualidade: O estabelecimento de uma estrutura de procedimentos e padrões
organizacionais.
a) Planejamento de qualidade: A seleção de procedimentos e de padrões organizacionais.
24
b) Controle de qualidade: A definição e a aprovação de processos que assegurem que os
procedimentos e os padrões de qualidade de projetos sejam seguidos pela equipe de
desenvolvimento de software.
O autor acima mencionado ainda afirma que o gerenciamento de qualidade
fornece uma verificação independente sobre o processo. Os projetos finalizados ou produtos
já entregues são posteriormente avaliados por uma equipe de qualidade que deve ser
independente do gerenciamento do projeto, pois desta forma se terá uma visão objetiva do
processo, podendo reportar problemas e dificuldades com mais facilidade à gerência sênior. A
ilustração abaixo apresenta a relação explicitada.
Esquema 2 - Sincronismo entre desenvolvimento e Gerenciamento de Qualidade.
Fonte: Sommerville, 2003.
O gerenciamento de qualidade inclui todas as atividades da organização executora
que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o
projeto atenda às necessidades que motivaram sua realização. É implementado o sistema de
gerenciamento da qualidade através da política, dos procedimentos e dos processos de
planejamento da qualidade, garantia da qualidade e controle da mesma, com atividades
de melhoria contínua dos processos, conduzidas do início ao fim, conforme adequado. (PMI,
2004, p.179). Os itens que compõem o gerenciamento de qualidade estão representados no
quadro abaixo.
25
Quadro 1 - Gerenciamento da Qualidade do Projeto segundo o PMI.
Fonte: PMI, 2004.
2.1.1 Padrões de Qualidade
As atividades e procedimentos que são definidos no gerenciamento da garantia de
qualidade exigem uma estrutura de padrões que devem ser aplicados durante todo o processo
de desenvolvimento. Os dois padrões principais que podem ser definidos são: Padrões de
Produto e Padrões de Processo. O primeiro trata de padrões que se aplicam ao produto,
incluindo estrutura de documento de requisitos, padrões de documentação (como cabeçalho,
itens, nomenclaturas), padrões de codificação, entre outros. Já o segundo define o fluxo do
processo a ser seguido durante o desenvolvimento e validação, incluindo definições de
especificação e uma série de documentos que devem ser gerados durante o fluxo.
(SOMMERVILLE, 2003). O quadro abaixo ilustra esta situação.
26
Quadro 2 - Padrões de produto e de processo
Fonte: Sommerville, 2003.
A definição de padrões deve ser analisada para que não ocorram problemas
relacionados a padrões não apropriados. É importante decidir quais os padrões que devem ser
utilizados sem alterações e quais podem ser alterados. (SOMMERVILLE, 2003).
2.1.2 Qualidade do Processo e do Produto.
O propósito da Garantia da Qualidade do Processo e Produto é munir a equipe e a
gerência com uma visão clara sobre os processos e seus produtos de trabalho associados.
(CMMI – DEV , 2003 apud JUNQUEIRA, 2009).
Existe aqui uma nítida ligação entre os dois itens. A qualidade do software é
largamente determinada pela qualidade do processo utilizado, que tem por finalidade a criação
de um produto. Um é diretamente afetado pelo outro. Então, quando um produto final não é
concluído com qualidade, certamente há um fator causador dentro do processo responsável
pelo insucesso no produto final. Nessa situação, é necessária a medição dos atributos de
software, tais como facilidade de manutenção, desempenho da aplicação, funcionalidade,
fatores internos e externos ao processo para que seja realizada a sua melhoria. Para isso, é
importante que sejam realizadas atividades como as revisões e monitoramento no processo.
(SOMMERVILLE, 2003). A seguir, apresenta-se um fluxograma ilustrativo.
27
Fluxograma 1 - Fluxo do gerenciamento da qualidade do processo
Fonte: Sommerville, 2003.
2.1.3 O planejamento de Qualidade
Planejamento de Qualidade: “Identificação dos padrões de qualidade relevantes
para o projeto e determinação de como satisfazê-los.” (PMI, 2004, p.179).
Para obter um processo e produto de qualidade, é necessário que se tenha um
planejamento dos objetivos claramente descritos e de fácil compreensão a toda equipe
envolvida no projeto. Ele serve também para avaliar o nível de qualidade que tem o produto.
O planejamento de qualidade inclui um conjunto de ações que fazem com que os
requisitos sejam cumpridos. Esta tarefa não é simples. Segundo o National Institute of
Standards and Technology (NIST), aludido por Sommerville (2003), 80% dos custos de
desenvolvimento de aplicativos se destinam à identificação e à correção de erro. Desta forma,
um projeto realizado com alto padrão de qualidade gera credibilidade com o cliente, bem
como exige menos retrabalho e recursos adicionais.
A elaboração de um Plano de Qualidade é uma atividade gerencial apoiada pela
administração fiel a um conjunto de atividades que compõem o projeto. Ela estabelece
métricas visando custos, prazos e funcionalidades do projeto e a satisfação do cliente com o
produto.
Humprey, referenciado por Sommerville (2003), em seu livro sobre
gerenciamento de software, sugere uma estrutura geral para um plano de qualidade, que
inclui:
28
1. Introdução sobre o Produto: Uma descrição sobre o produto, seu mercado pretendido e as
respectivas expectativas quanto à qualidade.
2. Planos para o produto: As datas importantes para a liberação e as respectivas
responsabilidades referentes ao produto, juntamente com os planos para a distribuição e a
prestação de serviços relacionados a ele.
3. Descrição de processo: Os processos de desenvolvimento e de serviço que devem ser
utilizados para o desenvolvimento e gerenciamento do produto.
4. Metas de qualidade: As metas e os planos de qualidade para o produto, incluindo
identificação e justificativa de importantes atributos da sua qualidade.
5. Riscos e Gerenciamento de Riscos: Os principais riscos que podem afetar a qualidade do
produto e as ações para evitar esses riscos.
Existe uma ampla gama de atributos de qualidade de software em potencial que
devem ser considerados durante o processo de planejamento de qualidade. Em geral, não é
possível para qualquer sistema ser otimizado em relação a todos os atributos, e, assim, uma
parte importante do planejamento de qualidade é selecionar os principais atributos de
qualidade e planejar como eles devem ser obtidos. (SOMMERVILLE, 2003). A figura a
seguir representa os atributos da qualidade de software.
Figura 2 - Atributos de Qualidade do software
Fonte: Desenvolvido pelo autor, 2010.
29
2.1.4 Padrões de documentação
Um documento é a única maneira tangível de representar o software a ser
desenvolvido o processo. desta forma é extremamente importante a definição de um padrão de
documentos de fácil entendimento e objetivo. Na padronização da documentação, deve-se
considerar o processo de documentação (definindo o processo a ser seguido na
documentação); padrões de documentos (os quais regem a estrutura e a apresentação dos
documentos) e os padrões que asseguram que todas as cópias eletrônicas sejam compatíveis.
Embora a documentação deva se adequar a necessidade de projetos específicos, é interessante
que se utilize o mesmo estilo para todos os documentos produzidos, como identificação,
estrutura, apresentação do documento, padrões de atualização de documento.
O esquema abaixo permite visualizar o processo de padrões de intercâmbio de
documentos. Esta prática possibilita a transferência de documentos eletronicamente recriados
em forma original. Podem também limitar as fontes e estilos de texto utilizados (devido a
diferentes recursos, impressoras e displays) e definir convenções do uso de ferramentas.
(SOMMERVILLE, 2003).
Esquema 1 - Padrões de intercâmbio de documentos
Fonte: Sommerville, 2003.
30
2.1.5 Medição e Métricas
De acordo com Martinho (2008), o objetivo das medições, métricas e análises é
direcionar a melhoria contínua em todos os parâmetros da qualidade por um sistema de
medição orientado a metas.
A medição visa obter valores numéricos para atributos de um produto e/ou
processo e compara com outros produtos/processos, buscando tirar conclusões sobre a
qualidade do processo, avaliando se os objetivos pré-definidos estão próximos de serem
alcançados. Já as métricas são as medições referentes ao processo ou produto. São geralmente
medidas características como a rastreabilidade, volatilidade, esforço, abrangência, qualidade e
tamanho.
Segundo o WThreeX (2010), para se atingir a medição e métricas de qualidade em
um processo, são necessários alguns elementos, mencionados abaixo.
Os pontos colocados abaixo compõem as medições:
a) Aceite do grau de cumprimento dos padrões do processo, diretrizes e implementação;
b) Atingir o nível de implementação conforme o planejado;
c) Conclusão dos artefatos utilizando as métricas de qualidade do produto descritas
acima.
Os pontos colocados abaixo compõem as métricas:
a) Ser de fácil entendimento, objetivas e fáceis de coletar;
b) Deve ser uma tarefa automatizada, de modo que não interfira nas atividades dos
desenvolvedores;
Tendências e valores absolutos de métricas devem ser usados ativamente pelas equipes
de gerenciamento e de engenharia para informar o andamento e a qualidade em um
formato consistente.
Quanto à seleção de um conjunto mínimo ou mais extenso de métricas, esta
dependerá das características e do contexto do projeto. Se ele for grande ou tiver requisitos
rigorosos de confiabilidade ou segurança e as equipes de desenvolvimento e avaliação tiverem
um ótimo conhecimento sobre métricas, talvez seja útil coletar e analisar as métricas técnicas.
O contrato pode exigir que determinadas métricas sejam coletadas ou a organização pode
estar tentando aperfeiçoar habilidades e processos em áreas específicas. Não há uma resposta
simples que se adapte a todas as circunstâncias. O gerente de projeto deve selecionar o que é
31
apropriado quando o plano de métricas for produzido. No entanto, quando se apresenta um
plano de métricas pela primeira vez, convém manter a simplicidade, em vez de se arriscar e
cometer erros. (WTHREEX, 2010).
2.2 SOFTWARE QUALITY ASSURANCE
A SQA (Software Quality Assurance ou Garantia de Qualidade de Software) está
envolvida em todo o processo de desenvolvimento de software, monitorando e melhorando os
processos e etapas. Ela faz com que os procedimentos e padrões sejam seguidos; identifica e
garante a correção das falhas dentro do projeto.
Segundo Pressman (1995, p. 725) a garantia de qualidade de software abrange:
[...] (1) métodos e ferramentas de análise, projeto, codificação e Teste; (2) revisões
técnicas formais que são aplicadas durante cada fase da engenharia de software; (3)
uma estratégia de Teste de múltiplas fases; (4) controle da documentação de
software e das mudanças feitas nela; (5) um procedimento para garantir a adequação
aos padrões de desenvolvimento de software (quando aplicáveis); e (6) mecanismos
de medição e divulgação.
O acompanhamento do processo de qualidade de software é feito baseando-se nas
métricas que são obtidas por meio de técnicas de verificação e validação como avaliações,
auditorias, inspeções e revisões. Já no produto, os métodos utilizados podem ser feitos por
meio de Testes de software, como Testes caixa preta, caixa branca, Testes funcionais, Testes
de regressão, entre outros.
2.3 ANÁLISE DE RISCOS
Com a crescente demanda por qualidade de software, um processo bem definido é
um fator extremamente importante. Se torna cada vez mais comum a busca por boas práticas e
modelos conceituados como CMMI e MPS.BR. Entretanto, a implantação de um destes
modelos não é tarefa simples, pois deve passar pela política de cada organização, desviando
sua cultura e crenças. A análise de riscos é uma necessidade encontrada hoje nessas empresas,
32
servindo de orientação na fase de adaptação de um processo. Na análise de riscos, são
considerados fatores como a não utilização de boas práticas de desenvolvimento,
considerando que a qualidade do software está diretamente associada à qualidade dos
processos utilizados em sua produção e ao conhecimento técnico que os usuários do processo
têm sobre as práticas definidas. (ESPINHA, 2007).
Segundo Espinha (2007, p. 11):
Risco é a “exposição à chance de perdas ou danos”. Embora exista também uma
chance de alguma coisa sair melhor do que o esperado, o risco geralmente costuma
ser associado a possíveis perdas ou danos. O conceito de risco resulta da incerteza
quanto a eventos futuros e é parte de todas as atividades do desenvolvimento.
A análise de riscos se baseia em uma estratégia de avaliação de todos os ativos do
processo, bem como suas características (itens relacionados ao ativo). Ela extrai de cada ativo,
informações de uma série de elementos que posteriormente auxiliam na tomada de decisão.
Cada componente possui uma um checklist1 associado, composto pelos itens que
deverão ser verificados. Isto para que facilite a identificação do controle e questionários que
serão utilizados para a coleta de dados.
Os elementos que compõem este controle são:
Nome do Controle: a característica do requisito;
Justificativa: conceitos necessários para explicar porque o controle deve ser implementado;
Ameaças: quais os elementos podem não aproveitar da implementação do controle para se
manifestar e causar danos;
Recomendação: fornece razões para implementação do controle;
Referências: referências bibliográficas da ação;
Probabilidade: representa a probabilidade de uma ameaça se manifestar caso o controle não
esteja implementado na organização;
Severidade: indica o grau do impacto negativo na organização, caso uma ou mais ameaças se
manifestem;
Agrupamento: indica a qual agrupamento o controle pertence.
A imagem abaixo a análise de riscos em sua forma geral.
1 Checklist pode ser definido como o conjunto de itens agrupados em uma lista de forma a facilitar a comparação
ou garantir que as ações associadas a eles sejam gerenciadas adequadamente e não sejam esquecidas.
33
Esquema 2 - Análise de Riscos
Fonte: Espinha, 2007.
Por fim, tem-se uma série de informações concatenadas que fornecem apoio ao
gestor do projeto. As ilustrações abaixo apresentam informações que foram extraídas através
do processo de análise de riscos.
34
Tabela 1 - Resultados da avaliação em abrangência por área de processo.
Fonte: Espinha, 2007.
Gráfico 1 - Resultados da avaliação em abrangência - ameaças
Fonte: Espinha, 2007.
35
2.4 CONSIDERAÇÕES FINAIS
A busca pela qualidade de software não está somente no início do projeto, onde é
feito o levantamento dos requisitos; nem apenas no final realizando Testes funcionais. A
qualidade está presente durante toda engenharia do software: processo de desenvolvimento
que é utilizado, bem como as pessoas que estão envolvidas no processo. Podemos considerá-
la como algo subjetivo que pode variar de acordo com as pessoas que estão envolvidas na
avaliação da qualidade.
36
3 TESTES
O presente capítulo aborda os conceitos de testes de software, bem como os tipos de
testes existentes. Além disso, mostra as dificuldades surgidas no processo de desenvolvimento
e meios de solucioná-las.
3.1 VISÃO DE TESTES DE SOFTWARE
Teste de software é o processo de execução de um produto para determinar se ele
atingiu suas especificações 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.
Por conta dessa característica das atividades de Teste, dizemos que sua natureza é destrutiva,
e não construtiva, pois visa o aumento da confiança de um produto através da exposição de
seus problemas, porém antes de sua entrega ao usuário final. (DIAS NETO, 2007).
O Teste, da maneira como é executado pela maioria das empresas – como uma
etapa do processo do desenvolvimento e, em geral, executado pelos próprios desenvolvedores
e pelos usuários do sistema – serve apenas para garantir que as especificações ou os requisitos
do negócio foram implementados. Como o processo de desenvolvimento cria produtos com
defeito, se faz necessário descobrir estes defeitos. Em um modelo de garantia de qualidade
isso é insuficiente. Quem poderia garantir que um software testado pelos próprios
desenvolvedores está corretamente testado? Com certeza, existem exceções, mas a melhor
forma de testar um software é ter um processo de Teste claramente definido. (BASTOS et al.,
2007).
O Teste é um processo que envolve vários outros processos da engenharia de
software, e ações que vão desde o levantamento de requisitos até a execução do Teste
propriamente dito. (MOLINARI, 2008). A imagem mostrada abaixo ajuda a localizar o
processo de Testes dentro da Engenharia de Software.
37
Figura 3 - Localização da qualidade dentro da engenharia.
Fonte: Molinari, 2008.
A engenharia de software mostra uma ciência, uma área de construção e gerência
do projeto. Quando se passa a enxergar mais fundo, percebemos que há nela uma área de
qualidade. Sabemos que “ir ao encontro das necessidades dos clientes” é a chave para a
garantia de um produto. Porém, isso só é possível mediante técnicas adequadas para garantir o
funcionamento do software. (MOLINARI, 2008).
O autor prossegue, afirmando que os Testes mostram uma visão das falhas na
qualidade externa, aquela que é visualizada, tal qual um sintoma de uma doença. As raízes
dessas doenças estão na garantia interna, no controle por meio de diversos atributos, tais
como: estrutura adequada de programação, usabilidade, padrões de codificação, etc.
Myers (1979), referenciado em BASTOS et al., (2007) criou conceitos sobre
Testes de Software – uma publicação que na época tornou-se uma das bíblias da qualidade de
software. Nesta obra, Myers afirmava que:
Os Testes unitários podem remover entre 30% e 50% dos defeitos dos programas;
Os Testes de sistema podem remover entre 30% e 50% dos defeitos remanescentes;
Desse modo, os sistemas podem ir para produção ainda com aproximadamente 49% de
defeitos;
Por último, as revisões de códigos podem reduzir entre 20% e 30% desses defeitos.
Abaixo é apresentado um gráfico, elaborado pelos acadêmicos autores dessa
monografia, com base nas ideias de Myers.
38
Gráfico 2 - Custo de correções
Fonte: Elaboração dos autores, 2010.
O gráfico 2 transmite a ideia de que, para garantir maior qualidade em um
produto, é importante levantar a necessidade de cada fase do desenvolvimento para serem
identificados os problemas de forma rápida. Tendo isso aplicado ao processo utilizado, pode-
se reduzir consideravelmente o custo do desenvolvimento, pois se torna fácil identificar uma
falha logo no seu surgimento.
3.1.1 Conceitos de Testes
Segundo Dias Neto (2007), Teste é uma ação que pode ser realizada em diferentes
estágios do desenvolvimento. Seus objetivos diferem de acordo com o estágio.
Etapas iniciais: expor defeitos para permitir correção;
Etapas finais: verificar se o sistema atende a especificações.
Para introduzir os conceitos de Testes de software, é importante esclarecer alguns
dos principais itens relacionados a esta atividade, tais como defeitos, erros e falhas. A
diferença entre estes três conceitos seguem abaixo. Elas estão definidas na terminologia
padrão para Engenharia de Software do IEE - Institute of Electrical and Electronics Engineers
– (IEEE 610, 1990 apud DIAS NETO, 2007).
39
Defeito é um ato inconsistente cometido por um indivíduo ao tentar entender uma
determinada informação, resolver um problema ou utilizar um método ou uma ferramenta.
Por exemplo, uma instrução ou comando incorreto.
Erro é uma manifestação concreta de um defeito num artefato de software.
Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário
incorreto ou resultado inesperado na execução de um programa constitui um erro.
Falha é o comportamento operacional do software diferente do esperado pelo
usuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca
causar uma falha.
A ilustração abaixo expressa a diferença entre esses conceitos. Defeitos fazem
parte do universo físico (a aplicação propriamente dita) e são causados por pessoas, por
exemplo, através do mal uso de uma tecnologia. Defeitos podem ocasionar a manifestação de
erros em um produto, ou seja, a construção de um software de forma diferente ao que foi
especificado (universo de informação). Por fim, os erros geram falhas, que são
comportamentos inesperados em um software que afetam diretamente o usuário final da
aplicação (universo do usuário) e pode inviabilizar a utilização de um software. (DIAS
NETO, 2007).
Figura 4 - Defeito x Erro x Falha
Fonte: Neto, 2007.
Ao longo de um processo de testes, são abordados elementos que seguem desde a
fase inicial até a entrega de um software, necessários para que se possa conhecer mais a fundo
a área de testes. Os elementos que seguem abaixo foram descritos com base no livro “Testes
Funcionais de Software”, de Leonardo Molinari (2008, p. 56)
40
a) Planejamento de Testes: é o processo de se planejar Testes. O
planejamento pode gerar um ou mais planos de Testes;
b) Plano de Testes: é o resultado do processo de planejamento de Testes. Ele
representa a composição dos requisitos, casos de Testes, cenários de
Testes a serem utilizados, e quaisquer outros documentos que sejam
pertinentes ao planejamento;
c) Requisitos de Testes: são requisitos dos Testes que representam o que deve
ser testado em termos de meta. Um requisito deve gerar um ou mais casos
de Testes;
d) Tipos de Testes: são os tipos de Testes a serem realizados em um
ambiente. Aqui, cada caso de Teste a ser realizado irá referenciar um tipo
de Teste, ou alguma técnica a ser utilizada. Exemplo: Teste de
performance, Teste funcional, Teste de segurança, etc;
e) Casos de Teste: representa o que deve ser testado em detalhes. É a menor
unidade de Teste, o desdobramento natural dos requisitos de Teste. Cada
caso de Teste é composto por um conjunto de passos de Teste;
f) Passo de Teste: é uma ação específica ou um passo para poder realizar um
Teste. Um passo pertence a apenas um conjunto de passos de Teste.
Exemplo: abrir a aplicação, clicar no botão X;
g) Script de Teste: é também conhecido como “script de automação”.
Conjuntos e passos que são executados em uma ferramenta de automação
de Teste. Representa uma ação ou um caso de Teste gerado através da
ferramenta de automação;
h) Cenário de Teste: é um conjunto de casos de Teste ou scripts a serem
executados em uma ordem com o objetivo de executar uma situação de
Teste;
i) Ambiente de Teste: é um conjunto de artefatos lógicos e físicos que
compõe o ambiente onde os Testes serão planejados e executados;
j) Relatório de Teste: é um relatório contendo informações dos Testes;
k) Metodologia de Testes: é um conjunto de técnicas, método e estratégias
que se volta para a criação e execução de um sistema qualquer;
l) Processo de Teste: é um processo qualquer que representa como os Testes
são gerenciados.
Rocha (2001), aponta outro elemento e sua subdivisão:
41
a) Critério de Teste: serve para selecionar e avaliar casos de Teste de forma a
aumentar as possibilidades de provocar falhas ou, quando isso não ocorre,
estabelecer um nível elevado de confiança na correção do produto.
O critério de cobertura dos Testes: permite a identificação de partes do
programa que devem ser executadas para garantir a qualidade do software e
indicar quando o mesmo foi suficientemente testado (RAPPS e
WEYUKER, 1982, apud ROCHA, 2007). Ou seja, determinar o percentual
de elementos necessários por um critério de Teste que foram executados
pelo conjunto de casos de Teste;
O critério de adequação de casos de Teste: quando, a partir de um conjunto
de casos de Teste “T” qualquer, ele é utilizado para verificar se “T” satisfaz
os requisitos de Teste estabelecidos pelo critério. Ou seja, este critério
avalia se os casos de Teste definidos são suficientes ou não para avaliação
de um produto ou uma função;
O critério de geração de casos de Teste: quando o critério é utilizado para
gerar um conjunto de casos de Teste “T” adequado para um produto ou
função, ou seja, este critério define as regras e diretrizes para geração dos
casos de Teste de um produto que esteja de acordo com o critério de
adequação definido anteriormente.
3.1.2 Defeitos do desenvolvimento
No processo de desenvolvimento de software ocorrem muitos defeitos. Embora as
empresas tenham grande preocupação com o uso dos melhores métodos de desenvolvimento,
ferramentas ou profissionais, os defeitos permanecem presentes nos produtos, o que torna a
atividade de Teste fundamental durante o desenvolvimento de um software. Já foi observado
que esta atividade corresponde ao último recurso para a avaliação do produto antes da sua
entrega ao usuário final. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas
envolvidas no processo são dois possíveis fatores que aumentam a complexidade dessa tarefa,
e por consequência, aumentam também a probabilidade de defeitos. Assim, a ocorrência de
falhas é inevitável. Mas o que significa dizer que um programa falhou? Basicamente significa
42
que o funcionamento do programa não está de acordo com o esperado pelo usuário. Por
exemplo, quando um usuário da linha de produção efetua consultas no sistema das quais só a
gerência deveria ter acesso. De acordo com Dias Neto (2007), esse tipo de falha pode ser
originado por diversos motivos, como por exemplo:
A especificação pode estar errada ou incompleta;
A especificação pode conter requisitos impossíveis de serem implementados devido a
limitações de hardware ou software;
A base de dados pode estar organizada de forma que não seja permitido distinguir os
tipos de usuário;
Pode ser que haja um defeito no algoritmo de controle dos usuários.
Os defeitos normalmente são introduzidos na transformação de informações entre
diferentes fases do ciclo de desenvolvimento de um software. O exemplo abaixo citado por
Dias Neto (2007), expressa de forma clara o ciclo de vida do desenvolvimento:
Os requisitos expressos pelo cliente são relatados textualmente em um documento
de especificação de requisitos. Esse documento é então transformado em casos de
uso, que por sua vez foi o artefato de entrada para o projeto do software e definição
de sua arquitetura utilizando diagramas de classes da UML. Em seguida, esses
modelos de projetos foram usados para a construção do software em uma linguagem
que não segue o paradigma orientado a objetos. Observe que durante esse período
uma série de transformações foi realizada até chegarmos ao produto final. Nesse
meio tempo, defeitos podem ter sido inseridos. (DIAS NETO, 2007, p.56).
A figura abaixo ilustra este exemplo:
Figura 5 - Diferentes interpretações ao longo do ciclo de desenvolvimento de um software.
Fonte: Dias Neto, 2007.
43
3.1.3 Gerenciamento de Testes
Molinari (2008) declara que a gestão da qualidade representa um dos pilares da
Qualidade de Software. Os outros pilares tratam dos elementos gestão de configuração, gestão
de requisitos e Testes.
Gestão de Configuração: trata de gerência, controle e registro dos artefatos que
compõem o software, incluindo aí todo o histórico da mudança do software em si;
Gestão de Requisitos: trata de gerência, controle e registro das necessidades do
sistema (requisitos) e dos usuários em todos os níveis, incluindo aí a rastreabilidade das
necessidades e da sua mudança;
Testes: trata de gerência, planejamento, controle e execução dos Testes em todos
os níveis, de modo a garantir a implementação (projeto, desenvolvimento e entrega) das
necessidades especificadas.
Como dito anteriormente, quanto antes os testes iniciarem, mais barato será a
correção dos defeitos encontrados. O gerente de testes deve trabalhar neste sentido, definindo
e acompanhando o processo para garantir a qualidade do sistema em desenvolvimento. De
modo geral, o processo de teste é representado por ciclos, que são as etapas a serem seguidas
em todo o processo. Para Bastos et al. (2007), o ciclo de testes é representado pelas seguintes
etapas:
Planejamento
Preparação
Especificação
Execução
Entrega
3.2 REQUISITOS E CASOS DE TESTES
Nesta seção serão abordados os requisitos e os casos de testes utilizados no
processo.
44
3.2.1 Definindo os requisitos
Para elaborar os casos de testes é necessário primeiramente levantar os requisitos
de testes. Não se deve confundir requisito de teste com caso de teste - este último será
explicado mais adiante. Para criar tais requisitos deve-se definir exatamente o que se deseja
testar em nível macro e em nível detalhado. (MOLINARI, 2008).
Para realizar o levantamento geralmente se tem como base os documentos,
especificações de usuários, necessidades do sistema e os casos de uso. Quanto mais detalhado
for o requisito, mais próximo do caso de testes ele vai ficar. Segundo Molinari (2008), os
requisitos devem possuir algumas características para que este seja bem elaborado, podemos
destacar as seguintes características:
a) Sua escrita deve ser de forma clara e objetiva, não deve de maneira nenhuma conter
ambiguidades em sua descrição;
b) Deve ser único, não pode existir ambiguidade entre requisitos;
c) A descrição deve ser adequada à realidade que ele propõe representar;
d) Seu detalhamento deve ser completo, lembrando que completude não significa texto
extenso, deve conter apenas o necessário.
Os requisitos geralmente estão organizados em uma estrutura hierárquica. Deve
conter um número de identificação único, descrição detalhada, seu status (posição atual no
ciclo de vida de um requisito. Ex.: criado, atualizado, finalizado, implementado, etc.) e suas
dependências para com outros requisitos de Testes. (MOLINARI, 2008).
3.2.2 Definindo casos de testes
Descreve uma condição particular a ser testada e é composto por valores de
entrada, restrições para a sua execução e um resultado ou comportamento esperado (CRAIG e
JASKIEL, 2002, apud OLIVEIRA e PEREIRA, 2007).
Conforme menciona Molinari (2008), os casos de Testes podem ser construídos,
partindo dos requisitos. Nesta forma, o Caso de Teste será dividido em três grupos, chamados
de Cenário de Teste. Isso não significa que cada cenário deverá ser totalmente preenchido em
45
amplitude e profundidade, mas devem ser vistos, pois sua importância pode variar entre os
cenários.
Cenário de Testes no caminho principal: são os casos de Testes envolvidos
no fluxo normal do sistema-alvo de Teste, ou seja, são os Testes que o
usuário normalmente utiliza;
Cenário de Testes no caminho alternativo: são os casos de testes que estão
envolvidos no fluxo alternativo da execução da aplicação, são considerados
Testes de menor importância;
Cenário de Testes de exceção: são os Testes em situações de possíveis
problemas ou exceções que impedem ou atrapalham o funcionamento da
aplicação.
Além das técnicas existentes, é importante também testar os acessos da aplicação
ao banco de dados, para verificar se a aplicação está trabalhando o dado de maneira correta,
ou seja, se o dado foi lido, atualizado, alterado e excluído do banco de dados, certificando
assim a integridade da informação. Para executar essa validação, pode-se criar um caso de
teste para essa função, ou mesmo acrescentar como um passo dentro dos casos de testes
respectivos.
Assim como os requisitos, os casos de testes também possuem algumas
características para que sejam bem elaborados, entre elas podemos destacar as seguintes:
a) Deve ser escrito de maneira objetiva e clara, sem ambiguidades no texto;
b) Assim como acontece nos requisitos, o caso de Teste é único;
c) Sua descrição deve estar adequada à realidade a qual propõe representar, contendo os
passos para realizar o Teste:
d) O caso de Teste deve estar completo;
e) Deve possuir referências de outros casos de Testes, se necessário.
Segundo Pontes (2009) um caso de teste simples deve possuir um objetivo, um
passo-a-passo de como executar o teste, suas pré-condições para iniciar o teste, caso seja
necessário, e o resultado esperado, como o exemplo que pode ser visualizado no quadro
abaixo.
46
Quadro 3 - Exemplo de um Caso de Teste simples.
Fonte: Pontes, 2009.
Entretanto, nada impede que sejam adicionadas mais informações ao caso de
teste, como: ambiente, dados de entrada, cronograma, dependências com outros casos de
testes, entre outras.
3.3 TIPOS DE TESTES
O planejamento do Teste deve prever os tipos e as técnicas que serão utilizadas ao
realizar um determinado Teste. Existem dois tipos básicos de Testes considerados os mais
genéricos: Testes Funcionais e Testes Estruturais. Nenhum destes é completo. Eles se
completam e devem ser aplicados em conjunto. Para cada um destes tipos podemos realizar
inúmeras técnicas criadas para complementar os Testes. (MOLINARI, 2008).
Para Rocha, aludido em Costa (2009), os principais níveis de Testes são:
Teste de Unidade
Teste de Integração
Teste de Sistema
Teste de Aceitação
Teste de Regressão.
47
A seguir, abordar-se-á o conceito destes e de outros tipos de Testes, bem como
técnicas de Testes Funcionais e Testes Estruturais.
3.3.1 Teste Funcional
Molinari (2008) define os Testes funcionais como:
[...] o tipo de Teste que tem por objetivo medir a qualidade funcional de
componentes de um sistema. Este tipo de Teste, conhecido também como o Teste
“caixa-preta”, propõe testar a funcionalidade do sistema – entrada e saída de dados -
com uma visão externa da aplicação, de modo a assegurar a funcionalidade do
sistema. Aqui não é considerada a verificação no interior da aplicação (código-fonte,
estrutura).
Os Testes são realizados executando a rotina ou sistema que pretende-se testar
comparando-o com o resultado previamente conhecido. No geral, o termo “Teste funcional”
tente a ficar limitado a Testes unitários. Porém, nada impede de ser aplicada certa
granularidade a um Teste funcional. Podemos testar um componente de um sistema ou
realizar verificações em um arquivo de banco. Abaixo, segue a representação do teste caixa-
preta.
Figura 6 - Componentes existentes em Testes caixa preta.
Fonte: Elaboração dos autores, 2009.
48
Como no teste estrutural, há diversas técnicas existentes que ajudam a executar
um bom teste funcional. Durante a execução de um checklist ou simplesmente o ato de
homologar uma tarefa, está se realizando técnicas de testes funcionais. Falta apenas o hábito
de estar enfatizando estas atividades para melhorar o processo.
Algumas técnicas existentes são Teste de Valor Limite ou Fronteiras (Boundary
Value Testing), Teste de Particionamento Equivalente (Equivalente Class Testing), Teste de
Regressão, entre outros. Abaixo serão apresentados detalhes de algumas técnicas utilizadas
nos Testes Funcionais. (MOLINARI, 2008).
3.3.2 Testes de Unidade
Este tipo de Teste, também conhecido como Testes unitários, tem por objetivo
explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por defeitos de
lógica e de implementação em cada módulo, separadamente. O universo alvo desse tipo de
Teste são os métodos dos objetos ou mesmo pequenos trechos de código. (ROCHA, 2001
apud DIAS NETO, 2007).
3.3.3 Testes de Sistema
Avalia o software em busca de falhas por meio da utilização do mesmo, como se
fosse um usuário final. Dessa maneira, os Testes são executados nos mesmos ambientes, com
as mesmas condições e com os mesmos dados de entrada que um usuário utilizaria no seu dia-
a-dia de manipulação do software. Verifica se o produto satisfaz seus requisitos. (ROCHA,
2001 apud DIAS NETO, 2007).
49
3.3.4 Testes de Aceitação
São realizados geralmente por um restrito grupo de usuários finais do sistema.
Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está
de acordo com o solicitado. (ROCHA 2001, apud DIAS NETO, 2007).
3.3.5 Testes de Integração
É uma técnica sistemática para construção da estrutura do programa. O Teste de
integração pode ser considerado como uma extensão lógica dos Testes unitários. Na sua
forma mais simples, duas unidades que foram testadas são combinadas em um componente e
testadas. Um componente neste caso, refere-se a um conjunto integrado de mais de uma
unidade. O objetivo desta técnica é montar estruturas de testes para descobrir erros
relacionados à interface, combinando peças e testando em pares. (Pressman, 1995).
3.3.5.1 Não Incremental
A abordagem chamada de big-bang, onde os módulos são testados isoladamente e
depois integrados de uma só vez. Os conjuntos de erros são difíceis de serem detectados, logo
difíceis de serem corrigidos, pois devido ao tamanho e complexidade do programa, é difícil
isolar as causas de tais erros. Testes não-incrementais são normalmente usados devido às
pressões do dia a dia e os Testes são aplicados para demonstrar uma operabilidade mínima do
sistema. (CAMPOS, 2009).
50
Esquema 3 - Representação dos módulos de Teste
Fonte: Campos, 2009.
3.3.5.2 Incremental
Um software é construído e testado em pequenos segmentos, tornando a correção
de erros mais fácil. A probabilidade de testar completamente a interface do sistema também
aumenta.
51
A figura abaixo representa componentes que foram estruturados de forma
incremental:
Esquema 4 - Testes de integração.
Fonte: Elaboração dos autores, 2010.
De acordo com Campos (2009), os pontos relevantes desta técnica são:
O Tester não precisa esperar até que todo o sistema esteja pronto, para iniciar os
Testes;
Há um menor risco de fracasso geral do projeto, já que cada módulo é verificado antes
e caso algo esteja errado a correção será implementada já no próximo ciclo de Teste;
A integração dos módulos só é realizada, após eles já terem sido verificados, ou seja,
se algum erro acontecer, a causa provavelmente será a comunicação entre esses
módulos.
3.3.5.3 Integração Top-down
É uma abordagem incremental. Como o nome já diz, a integração dos módulos
acontece de cima para baixo, o que facilita a verificação antecipada dos pontos de decisão e
controle no processo de Teste. (CAMPOS, 2009).
52
3.3.5.4 Integração Bottom-up
Na técnica Botton-up, a integração do sistema começa a partir do nível mais baixo
do software, ou seja, o módulo. O módulo é dito como o mais baixo nível se ele não depende
de outro módulo. A Bottom-Up assume que todos os módulos foram individualmente testados
antes. (CAMPOS, 2009).
3.3.6 Teste de Regressão
Esta técnica de Teste trabalha de modo a testar segmentos já testados após a
implementação de uma mudança na aplicação. Ela tem por objetivo determinar se a
documentação do sistema permanece atual; verificar se os dados e as condições de Teste
permanecem atuais; determinar se as funções previamente testadas continuam funcionando
corretamente após a introdução de mudanças no sistema.
Costa (2009) menciona que os Testes de regressão tratam de executar Testes da
versão anterior, na nova versão de um aplicativo, de modo a se certificar que o que está na
aplicação continue certo.
Um Teste de regressão deve ser executado sempre que o sistema sofre alguma
alteração. Significa aplicar todos os Testes realizados anteriormente para garantir que os
resultados não tenham sido afetados pelas mudanças realizadas, não só na parte alterada,
como os outros segmentos do sistema.
Um ponto negativo do Testes de regressão é o gasto excessivo de tempo e a
repetição das operações, o que muitas vezes contribui para que eles não sejam realizados de
forma completa. Como esses Testes são vitais para garantir a qualidade final do sistema, tem-
se uma excelente justificativa para introduzir a automação de Testes na organização.
53
3.3.7 Teste de Estresse
Neste Teste será avaliado o comportamento do sistema sob condições críticas.
Basicamente, este Teste tem o objetivo de avaliar os limites, ou seja, até quando o software
pode ser exigido e até quais as falhas (caso existam) decorrentes dele, levando em
consideração as restrições. Tais como a memória, número de transações e capacidade da
aplicação. Para Lourenço (2010), este tipo de Teste é indispensável quando se trata de Testes
em aplicações cuja eficiência seja uma característica importante. Exemplos:
Servidores de arquivos web, que devem atender a solicitação de um grande número de
clientes;
Aplicações industriais, tais como o controle de uma refinaria de petróleo;
Jogos de Computador, que precisam de um desempenho aceitável para serem viáveis
comercialmente.
Este Teste permite a capacidade de responder à questões como:
O sistema consegue atingir o objetivo?
Qual o número máximo de transações realmente possível?
Se a plataforma de execução se degradar (por exemplo, uma falha parcial de rede, falta
de espaço em disco, etc.), como o sistema se comportará?
A maior dificuldade que se pode ter ao realizar este Teste é preparar a plataforma
para executá-lo. Caso se queira saber a quantidade mínima de memória disponível para que o
sistema funcione, retirar a memória do computador seria uma solução trabalhosa. Para isso,
existem no mercado aplicações que permitem tal avaliação, como WinStress (permite reduzir
artificialmente a capacidade de desempenho do computador conforme configuração desejada.
Possibilita também a variação de parâmetros como carga de CPU, memória disponível,
espaço em disco e carga de rede). Ferramentas como DieselTest e OpenST, permitem testar
um programa simulando um número arbitrário de conexões. (LOURENÇO, 2010).
54
3.3.8 Análise do Valor Limite ou Fronteira
Este Teste utiliza uma seleção dos casos de testes que põem a prova os valores
fronteiriços. São utilizadas extremidades da classe, tendo como variáveis a faixa de valores o
tamanho da estrutura, valores específicos, entre outros extraídos. Ao aplicar um caso de Teste
utilizando esta técnica, é importante gerar entradas ou saídas que coincidem com ambos os
lados de cada fronteira, incluindo o valor da própria fronteira. Segundo Freitas (2009) para se
elaborar esta técnica, deve-se considerar as condições:
Se uma condição de entrada um intervalo, delimitado pelos valores A e B, os casos de
teste devem ser projetados com valores A e B logo acima e logo abaixo de A e B
respectivamente;
Se uma condição de entrada especificar uma série de valores, os casos de teste que
ponham à prova números máximos e mínimos devem ser desenvolvidos. Valores logo
acima e logo abaixo do mínimo e do máximo também são testados;
Aplicar as diretrizes 1 e 2 às condições de saída, por exemplo, supondo-se que uma
tabela de temperatura versus pressão seja exigida como saída de um programa de análise
de engenharia, os casos de teste devem ser projetados para criar um relatório de saída que
produza um número máximo (e mínimo) permissível de entradas na tabela;
Se estruturas internas de dados do programa tiverem prescritas fronteiras, certificar-se
de projetar um caso de teste para exercitar a estrutura de dados em sua fronteira.
Abaixo, é apresentado um exemplo da técnica.
Tabela 2 - Refinamento utilizando Valores-Limites.
Fonte: FREITAS, 2009.
Esta técnica é simples de trabalhar, e pode ser aplicada para realizar Testes
unitários, de integração ou Teste de aceitação de usuários.
55
3.3.9 Tabela de decisão
A técnica de decisão pode ser aplicada a todas as situações quando a execução do
software depende de muitas decisões lógicas. Ela baseia-se em uma combinação de situações
que devem ocorrer para que uma determinada ação seja tomada, expressa por um determinado
processamento ou por um cálculo. A tabela de decisão contém condições que disparam as
ações, muitas vezes combinações verdadeiras e falsas para todas as condições de entrada, e
ações resultantes para cada combinação de condição. (FREITAS, 2009).
Cada coluna da tabela corresponde a uma regra de negócio que define uma única
combinação de condições que resulta na execução de ações associada com aquela regra.
A cobertura padrão comumente usada em uma tabela de decisão é ter no mínimo
um Teste por coluna cobrindo todas as combinações de condições apresentadas. (FREITAS,
2009). A seguir, é mostrado um exemplo de tabela de decisão.
Tabela 3 - Exemplo de uma tabela de decisão.
.
Fonte: FREITAS, 2009.
No exemplo imaginário acima (Freitas, 2009) a decisão de se aceitar o seguro será
baseado no número de acidentes combinado com o sexo do motorista. Esta suposta
companhia de seguros entende que as pessoas do sexo feminino dirigem com mais cuidado,
como podemos ver na tabela de decisão acima.
56
3.3.10 Testes de Semântica
Segundo Freitas (2009), estes Testes devem ser usados para avaliar telas ou
relatórios têm defeitos de sintaxe e estão em conformidade com o modelo de dados do sistema
(tamanho dos atributos, etc.). Para este Teste deve, também, ser usado um padrão para criação
de telas e relatórios.
Procedimentos:
Criar uma lista de verificação para as telas e relatórios;
Definir as telas e relatórios que serão testados;
Montar os scripts de Teste.
É importante considerar que algumas empresas são bastante rígidas quando se
trata da criação de telas e/ou relatórios.
3.3.11 Testes Estruturais
Os Testes estruturais, ou também chamados de caixa-branca, têm por objetivo
avaliar o comportamento interno do sistema, simulando situações que exercitem todas as
estruturas utilizadas na codificação. Permite um Teste mais preciso em relação aos pontos
críticos do código-fonte. Freitas (2009), afirma que os Testes estruturais devem considerar os
seguintes aspectos:
Teste de condição;
Teste de ciclos;
Teste de fluxo de dados;
Teste de caminhos lógicos;
Códigos nunca executados.
A imagem a seguir é uma representação desta técnica.
57
Figura 7 - Componentes existentes em Testes caixa branca.
Fonte: Elaboração dos autores, 2009.
Testes estruturais são considerados mais complexos e muito diferentes do Teste
de caixa-preta. Ao aplicá-lo, deve-se avaliar a complexibilidade do software e a tecnologia
nele empregada.
Para a utilização deste tipo de Teste é necessário que se tenha um controlador de
Teste que dispare as rotinas na unidade de software, avalie os resultados gerados e compare
com o esperado. Os controladores produzem um log de execução, identificando quais casos
de testes obtiveram sucesso e quais falharam, permitindo a correção dos pontos de não-
conformidade da unidade de software. Esse mesmo processo será executado até que a unidade
não apresente falha na sua estrutura interna. (FREITAS, 2009).
Alguns exemplos de ferramentas já existentes:
Selenium IDE
JUnit
DBUnit
FitNesse
3.3.11.1 Técnicas de Testes Estruturais
São as seguintes:
58
3.3.11.1.1 Cobertura de Linha de Código
A cobertura de linha de código é considerada um método tradicional deste tipo de
Teste. Nesta técnica, pretende-se validar o número de linhas executadas em um caso de Teste.
Por exemplo: se o código de um cadastro tiver 100 linhas e durante os Testes
foram cobertas 90 linhas, quer dizer que 90% obtiveram cobertura no código-fonte.
(FREITAS, 2009).
3.3.11.1.2 Cobertura de Caminhos
Conforme Freitas (2009), essa técnica tem por objetivo detectar erros nas
condições lógicas aplicadas no código-fonte. Os casos de Testes são elaborados de forma a
permitir variação dos valores que determinam a execução dos diversos fluxos alternativos
existentes no código-fonte. O desenho interno do software é o principal elemento para a
modelagem dos casos de Testes. Pode-se aplicar três níveis diferentes de refinamentos para
cobrir o maior número de condições possíveis.
Figura 8 - Níveis de refinamento.
Fonte: FREITAS, 2009.
59
3.3.11.1.3 Cobertura de Decisões
Esse método de cobertura avalia se todas as decisões existentes no código-fonte
são exercitadas durante a execução dos Testes de caixa branca. Significa que cada IF...
THEN... ELSE... END IF, ou comando similar encontrado nos fontes terão casos de testes que
assumirão os valores verdadeiros ou falsos. Isso garante que toda decisão de processamento
existente tenha seus possíveis caminhos adequadamente exercitados. (FREITAS, 2009).
3.3.11.1.4 Cobertura de Condições
Segundo Freitas (2009), ao contrário da cobertura de decisões, que leva em
consideração apenas os comandos que executam desvios de processamento, esse modelo de
cobertura focaliza a expressão que representa a condição de desvio existente no código-fonte.
Em uma condição de desvio do tipo IF idade >= 18 AND sexo = “M”, os casos
de Testes deverão cobrir individualmente todas as condições possíveis:
idade<18;
idade=18;
idade>18
sexo=M;
sexo<>M.
Com apenas três casos de Testes, pode-se atender a todos os cenários de execução
possíveis:
CTI = [i=17, s = „M‟];
CT2 = [i=18; s=„F‟];
CT3= [i=19; s=„F‟]
3.3.11.1.5 Testes de Ciclos
60
Os ciclos concentram-se exclusivamente na validade das construções de laços.
São quatro os tipos de laços.
Figura 9 - Laços existentes nos Testes de ciclo.
Fonte: Elaboração dos autores, 2009.
3.4 CONSIDERAÇÕES FINAIS
O Teste tem por objetivo principal encontrar o maior número possível de defeitos
no software. Estes defeitos documentados e planejados proporcionam, ao final, indicadores
mensuráveis que servem de auxílio na construção de estratégias de teste.
Percebe-se ainda que, o teste contém um ciclo de vida que deve ser seguido, sendo
composto por etapas que realizam o processo. Para auxiliar na execução, existem diversas
técnicas que proporcionam ao profissional de teste realizar o seu trabalho com maior
qualidade e eficácia.
61
É importante ressaltar que, para que se tenha um ganho significativo, o teste deve
ser executado em paralelo ao processo de desenvolvimento.
62
4 METODOLOGIA UTILIZADA: MPS.BR
MPS.BR é a sigla que corresponde a Melhoria de Processo de Software Brasileiro.
Este modelo está em desenvolvimento desde dezembro de 2003 e é coordenado pela
Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com
apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos
(FINEP) e do Banco Interamericano de Desenvolvimento (BID).
A coordenação do projeto conta com duas estruturas, a primeira é o Fórum de
Credenciamento e Controle (FCC) e segunda é a Equipe Técnica do Modelo (ETM). O FCC
tem como objetivo assegurar que as Instituições Implementadoras (II) e Instituições
Avaliadoras (IA) sejam submetidas ao processo de credenciamento e que suas atuações não se
afastem dos limites éticos e de qualidade esperados. Já o ETM atua sobre os aspectos técnicos
relacionados ao Modelo de Referencia (MR-MPS) e Modelo de Avaliação (MA-MPS).
(SOFTEX, 2007).
O objetivo principal da MPS.BR é definir e aprimorar um modelo de melhoria de
avaliação de processo de software, visando atender às necessidades de negócio. O foco são
empresas de pequeno e médio porte, porém, como é um modelo adaptável, nada impede de
utilizá-lo em empresas de grande porte, independente da área - privada ou pública. (BRAUNS
et al., 2008).
Para construir o MPS.BR, utilizou-se como base técnica normas da NBR ISO-IEC
12207 e 15504 e no modelo Internacional CMMI-SE/SW. Este modelo está subdividido em
três componentes: Modelo de Referência (MR-MPS), Modelo de Avaliação (MA-MPS) e
Modelo de Negócio (MN-MPS), explicitados abaixo. (SOFTEX, 2007).
MR-MPS: contém os requisitos que os processos devem possuir para se enquadrar
dentro do modelo em questão. Nele estão contidas as definições dos níveis de
maturidade, processos e atributos dos processos;
MA-MPS: contém o processo de métodos de avaliações, os requisitos para os
avaliadores;
MN-MPS: contém as regras de negócio para a implementação do MPS.BR.
Representação do modelo MPS.BR.
63
Esquema 5 - Componentes do modelo MPS.
Fonte: SOFTEX, 2007.
Este modelo prevê o amadurecimento gradual dos processos envolvidos no
desenvolvimento de software através de níveis de maturidade que ele implementa. Segundo
Sodré (2010) os níveis de maturidade estabelecem uma forma de prever o desempenho futuro
de uma organização com relação a uma ou mais disciplinas. Um nível de maturidade é um
patamar definido de evolução de processo.
A divisão do modelo em níveis facilita sua implantação, pois não é necessário
implementar todas as etapas do modelo de uma vez apenas, ela é feita gradativamente e,
conforme o andamento, já se pode fazer as melhorias necessárias e corrigir possíveis erros
encontrados.
É necessário compreender a definição que o MPS.BR tem sobre maturidade, que
segundo Diniz (2009) “Um processo é maduro quando ele atinge os melhores resultados com
o menor custo”. Então para saber se um processo é maduro ou não, é necessário medir. O
MPS.BR vem de encontro a esta necessidade, possibilitando medir o processo.
Neste modelo são definidos sete níveis para o amadurecimento do processo:
Parcialmente Gerenciado, Gerenciado, Parcialmente Definido, Largamente Definido,
Definido, Gerenciado Quantitativamente, Em otimização, classificados do nível “G” ao nível
“A”, respectivamente. Os níveis são acumulativos, o que significa que se uma empresa está
classificada no nível F ela já possui o nível G e assim sucessivamente.
A escala de níveis foi baseada nos quatro níveis de maturidade que o
CMMISE/SWSM aplica, porém o MPS.BR possui mais níveis e em graduações diferentes
64
para possibilitar uma implementação e validação mais gradual e adequada à pequenas e
médias empresas. (BRAUNS et al., 2008).
Para melhor entender sobre o modelo de maturidade MPS.BR é necessário um
pouco mais de conhecimento sobre os processos envolvidos em cada nível, conforme mostra a
tabela abaixo.
Tabela 4 - Tabela dos representando níveis do MPS.BR.
Nível Processo
Nível A Todos os processos até o Nível B
Nível B Gerência de Projetos – GPR (evolução)
Nível C
Gerência de Riscos
Desenvolvimento para Reutilização – DRU
Gerência de Decisões – GDE
Nível D
Verificação – VER
Validação – VAL
Projeto e Construção do Produto – PCP
Integração do Produto – ITP
Desenvolvimento de Requisitos – DRE
Nível E
Gerência de Projetos – GPR (evolução)
Gerência de Reutilização – GRU
Gerência de Recursos Humanos – GRH
Definição do Processo Organizacional – DFP
Avaliação e Melhoria do Processo Organizacional – AMP
Nível F
Medição – MED
Garantia da Qualidade – GQA
Gerência de Portfólio de Projetos – GPP
Gerência de Configuração – GCO
Aquisição – AQU
Nível G Gerência de Requisitos – GRE
Gerência de Projetos – GPR Fonte: SOFTEX, 2007.
4.1 NIVEL G – PARCIALMENTE GERENCIADO
O nível G de maturidade é o nível mais baixo do modelo MPS.BR, sendo ele
composto pelos processo de Gerência de Projetos e Gerência de Requisitos. (SOFTEX, 2009).
65
4.1.1 Gerência de Projetos (GPR)
De acordo com a SOFTEX (2009), a gerência de projetos tem como propósito
estabelecer e manter planos que definem as atividades, recursos e responsabilidades do
projeto. Também é de sua responsabilidade fornecer informações sobre o andamento do
projeto que permitam corrigir desvios. À medida que a organização evolui em maturidade este
processo também evolui.
A gerência de projetos envolve atividades como: desenvolver um plano geral de
controle do projeto; obter o comprometimento e mantê-lo ao longo de toda a execução do
projeto; e conhecer o progresso do projeto, de maneira que ações corretivas possam ser
tomadas quando a execução do projeto desviar do planejado. (SOFTEX, 2007).
É interessante conhecer o conceito de projeto para obter uma melhor compreensão
sobre gerência de projetos. Segundo a fonte acima, projeto é um empreendimento realizado
para a criação de um produto. O projeto caracteriza-se por temporalidade e resultado, produto
único e elaboração progressiva.
Todos os projetos devem possuir início e fim bem definidos e estabelecidos. O
fim do projeto é atingido quando os objetivos do projeto tiverem sido alcançados, ou quando
se tornar claro que os objetivos não serão ou não poderão ser alcançados, ou ainda quando o
projeto for cancelado. (SOFTEX, 2007).
4.1.2 Gerência de Requisitos (GRE)
A SOFTEX (2009) define que, a gerência de requisitos tem como propósito
gerenciar os requisitos de produtos e componentes do projeto e identificar inconsistências
entre os requisitos e planos de projetos.
É de obrigação da gerência de requisitos controlar todos aqueles necessários
dentro do projeto, tanto os funcionais quanto os não-funcionais, bem como os requisitos
impostos ao projeto pela organização. Também é de sua responsabilidade documentar as
mudanças nos requisitos e manter a rastreabilidade bidirecional entre eles e os produtos de
trabalho em geral, além de identificar as inconsistências entre os requisitos. (SOFTEX, 2009).
66
Para elaborar esse processo, a SOFTEX (2009) buscou fundamentação teórica em
Dorfman e Thayer (1990), definindo requisito como sendo a representação da capacidade que
deve ser encontrada ou possuída por um determinado produto ou componente de produto para
satisfazer a um contrato, a um padrão, a uma especificação ou a outros documentos
formalmente impostos. Os requisitos indicam a capacidade do software requerida pelo usuário
para resolver um problema ou alcançar um objetivo.
4.2 NÍVEL F – GERENCIADO
Este nível do modelo de amadurecimento de processo tem como objetivo agregar
processos de apoio à gestão do projeto tais como: Garantia da Qualidade (GQA), Medição
(MED), Gerência de Configuração (GCO), Aquisição (AQU), Portfólio de Projetos (GPP),
ficando sobre responsabilidade dos processos GQA e MED a abordagem mais aprofundada
sobre o gerenciamento de Testes. (SOFTEX, 2009).
4.2.1 Aquisição (AQU)
O Guia de Implementação Nível F (SOFTEX, 2009), diz que o processo de
aquisição tem como propósito gerenciar a aquisição de produtos que satisfaçam às
necessidades expressas do adquirente, sendo que no contexto o termo produto pode incluir
também serviços, desde que estes sejam entregues como parte do produto final ao cliente.
Este processo tem como foco o planejamento ou preparação para a aquisição,
englobando a seleção do fornecedor e o monitoramento do contrato, com o objetivo de
garantir a qualidade do produto que está sendo contratado. (SOFTEX, 2009).
O PMBOK (2008) subdivide a área de gerência de aquisição do projeto em:
Planejamento da aquisição: determinação do que contratar e quando;
Preparação da aquisição: documentação dos requisitos do produto e identificação dos
fornecedores potenciais;
67
Obtenção de propostas: obtenção de propostas de fornecimento, conforme apropriado
a cada caso (cotações de preço, cartas-convite, licitação);
Seleção de fornecedores: escolha entre os possíveis fornecedores;
Administração de contratos: gerenciamento dos relacionamentos com os fornecedores;
Encerramento do contrato: conclusão e liquidação do contrato, incluindo a resolução
de qualquer item pendente.
4.2.2 Gerência de Configuração (GCO)
O propósito da gerência de configuração, segundo o SOFTEX (2009), é de
estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto
e disponibilizá-los a todos os envolvidos.
Segundo DART (1991), referido no SOFTEX (2009), gerência de configuração é
a disciplina responsável por controlar a evolução de sistemas de software.
A gerência de configuração geralmente se inicia na identificação das partes que
constituem o software. Cada uma dessas partes é considerada como um item de configuração,
que representa a agregação de hardware, software ou ambos, sendo tratados pela gerência de
configuração como um item único. (IEE, 1990, apud SOFTEX, 2009).
Em determinados momentos do ciclo de vida de desenvolvimento e manutenção
do software, esses itens de configuração são agrupados e verificados, constituindo
configurações do software voltadas para propósitos específicos, denominadas baselines. Desta
forma, com a utilização dos controles existentes dentro do processo de gerência de
configuração, é possível manter a integridade dos produtos de trabalho. Por fim, esses
produtos de trabalho são submetidos a um processo de liberação denominado release que
consiste em uma notificação formal e distribuição de uma versão aprovada do software.
(SOFTEX, 2009).
Na perspectiva gerencial a gerência de configuração segundo a fonte acima é
dividida em cinco funções:
Identificação da configuração;
Controle da configuração;
Contabilização da situação da configuração;
68
Avaliação e revisão da configuração;
Gerenciamento de liberação e entrega.
Na perspectiva de desenvolvimento a gerência de configuração é dividida em três
sistemas principais:
Controle de modificações;
Controle de versões;
Gerenciamento de construção.
4.2.3 Garantia de Qualidade (GQA)
Conforme o SOFTEX (2009), o propósito do processo garantia da qualidade é
assegurar que os produtos de trabalho e a execução dos processos estão em conformidade com
os planos e recursos pré-definidos. As atividades realizadas nesse processo fornecem
visibilidade do projeto, por meio de uma visão independente entre processo e produto.
Apoiando o gerente servindo como seus “olhos e ouvidos”, devendo contemplar tanto a
gerência quanto a construção dos produtos de trabalho.
É necessário fazer um bom planejamento da Garantia de Qualidade para
estabelecer padrões, procedimentos e processos aplicáveis ao projeto, bem como os artefatos e
fases que ela atuará. Este nível está presente em todos os níveis de maturidade enquadrados
dentro do modelo MPS.BR, pois ele não trabalha apenas em cima do produto, mas também
em cima dos processos, por isso é de suma importância um bom planejamento. (SOFTEX,
2009).
Ainda de acordo com a fonte acima mencionada, a garantia de qualidade tem os
seguintes objetivos:
Avaliar objetivamente os processos executados, produtos de trabalho e serviços em
relação à descrição de processos aplicáveis, padrões e procedimentos;
Identificar e documentar itens de não-conformidades;
Prover feedback2 para a equipe do projeto e gerentes como resultado das atividades de
garantia da qualidade;
2 Informação que o emissor recebe do receptor da mensagem, servindo para avaliar o resultado da transmissão.
69
Assegurar que as não-conformidades serão corrigidas.
A SOFTEX (2009) estabelece alguns resultados que podem ser obtidos através
deste processo, tais como:
Avaliar a aderência do produto de trabalho aos padrões, procedimentos e requisitos
aplicáveis. Essa avaliação deve ser realizada antes da entrega do produto ao cliente e
durante todo o ciclo de vida do projeto;
Avaliar a aderência dos processos às descrições e processo, padrões e procedimentos;
Identificar os problemas e não-conformidades, documentá-las e repassá-las aos
devidos responsáveis para que possam tomar as devidas providências;
Definir as ações para a correção dos problemas identificados e acompanhá-las até sua
conclusão.
4.2.4 Medição (MED)
O processo de medição tem como propósito coletar, armazenar, analisar e relatar
os dados relativos aos produtos desenvolvidos e aos processos implementados, tendo como
principal objetivo apoiar na tomada de decisão em relação aos projetos. Ele ocorre tanto nos
projetos quanto nos processos que são executados. As medições devem ser organizadas, sendo
que elas podem ser armazenadas em um repositório de medições do projeto, não necessitando
ainda ser em nível organizacional. Esse processo é realizado de maneira evolutiva, pois ele é
consequência da maturidade de outros processos. Ou seja, inicialmente as medições são
difíceis de serem realizadas, porque não se consegue quantificar as coisas corretamente, os
dados são difíceis de coletar, isso acontece como consequência de processos imaturos.
(SOFTEX, 2009).
São atribuições da medição:
O objetivo de realizar a medição é definido e mantido a partir dos objetivos de negócio
da organização e as necessidades de informação de processos técnicos e gerenciais;
É definido um conjunto de medidas, tendo como objetivo a necessidade de medição,
ou seja, a partir dos objetivos de medição (ou o que precisa ser medido) deve-se então
encontrar as medidas que possam satisfazê-lo;
70
São definidos os procedimentos que devem ser executados para coletar as medidas.
Também é definida e especificada a forma de armazenamento das mesmas;
São definidos os procedimentos que devem ser executados para a análise das medidas;
Define-se a coleta de dados necessários para realizar a análise;
São armazenados os dados recolhidos e as análises realizadas, para recuperá-los pelos
interessados e para uso futuro.
4.3 CONSIDERAÇÕES FINAIS
No intuito de motivar as empresas de desenvolvimento de software a colocarem
seus processos e produtos à prova da eficácia e eficiência para garantir sua qualidade,
tornando assim o software brasileiro competitivo nacionalmente e internacionalmente, surge
estão o modelo MPS.BR, compatível com as principais abordagens internacionais para
definição, avaliação e melhoria de processo de software, baseando-se em conceito de
maturidade.
Como hoje no Brasil a maioria das empresas desenvolvedoras de software são de
micro, pequeno e médio porte, este seria então o principal foco deste modelo, empresas estas
que possuem poucos recursos e necessitam melhorar seu processo de software. A idéia do
MPS.BR é que o modelo seja adaptável ao perfil da empresa de diferentes portes, ou seja, ele
pode ser implementado em empresas de grande porte.
O MPS.BR engloba todos os processo existentes dentro de uma empresa de
software. Porém, como o foco do projeto em questão não é gerenciar o processo de
desenvolvimento como um todo, e sim a gestão de Teste e qualidade, este capítulo apresentou
considerações a respeitos apenas dos níveis G e F, privilegiando o nível F (Gerenciado) por
ser o foco principal do projeto que será desenvolvido.
71
5 DEFINIÇÃO E ELABORAÇÃO DO PROCESSO DE TESTE
5.1 PROCESSO
Com o objetivo de facilitar a implantação de testes de software, foi definido um
modelo especificando todas as fases e atividades necessárias para que esta implantação seja
realizada de forma estruturada.
Este processo foi definido com base em estudos de processos de Testes em geral.
Ele busca atender aos requisitos do nível F do MPS.BR, focando na área de gerenciamento de
qualidade e medição.
5.2 FASES
O processo definido contém Etapas; Entradas e Saídas; Papéis e Produtos. Estes
itens são compostos pelas seguintes fases de execução do processo, sendo que cada etapa tem
seus objetivos específicos explicitados adiante neste trabalho. Seguem as fazes de execução:
Definição dos objetivos do Teste;
Análise de requerimentos de Teste;
Projeto de Caso de Teste;
Execução dos Testes;
Análise dos resultados dos Testes.
72
5.2.1 Papéis do Processo
O processo definido é composto por três papéis que participam ativamente no
processo, tais como Gerente de Testes, Analista de Testes e Tester, tendo também a
possibilidade de inserir o papel do gerente de qualidade no processo, porém este não participa
ativamente como os demais. Cada novo projeto de Teste criado serão descritas as pessoas
responsáveis por cada papel. Abaixo consta a definição de cada perfil:
Gerente de Testes: é de competência do Gerente de Testes gerenciar o processo de
Teste, bem como liderar um projeto de Teste novo ou em andamento. Ele irá elaborar o
documento do Projeto de Teste – Plano de Teste – e irá conduzir o projeto tomando as
providências necessárias para que seja executado de maneira adequada, ou seja, conforme os
itens pré-definidos no Plano de Teste;
Analista de Testes: este papel consiste em modelar a elaboração dos casos de
Testes e scripts de Testes;
Tester: é responsável pela execução dos casos de Testes e scripts de Teste;
Gerente de Qualidade: Este papel consiste em gerenciar, coordenar e revisar os
artefatos e atividades envolvidos no processo, para garantir a qualidade e eficácia dos Testes.
Ele terá os mesmos acessos que o gerente de Teste possui, porém apenas para visualizar.
A seguir, apresenta-se uma visão geral do processo:
74
5.2.2 Inicialização
Diagrama 2 - Visão detalhada do processo de inicialização
Fonte: Elaboração dos autores, 2009.
Objetivos: Elaboração de um Planejamento de Teste.
Descrição: Nesta etapa, deve-se realizar o levantamento de Requisitos, que são
documentos referentes a regra de negócio e documentação do desenvolvimento. Com
base nesta documentação será desenvolvido o Plano de Testes, que é um documento
básico para a gerência do projeto de Teste e a base para a sua monitoração e controle.
Tendo definido este documento, serão desenvolvidos os Casos de Teste.
Fases: a) Elaborar documento de Requisitos; b) Elaborar casos de testes; c) Elaborar
Plano de Testes.
75
a) Elaborar documento de Requisitos: A elaboração de um Documento de Requisitos tem
por objetivo coletar as informações necessárias para que o software seja validado e
entregue ao cliente conforme a sua real necessidade, dentro do prazo e orçamento
adequado. Tem-se aqui a base do negócio, portanto é necessário que seja elaborada uma
especificação de requisitos bem definida de forma clara e objetiva, para que possa ser
entendida por todos os stakeholders3.
A lista abaixo apresenta as atividades que deverão ser executadas para que esta
fase seja finalizada:
Estudar os requisitos funcionais e não funcionais solicitados pelo cliente (novos
requisitos);
Estudar as modificações de requisitos solicitados pelo cliente (mudanças de
requisitos);
Revisar os artefatos e identificar "inconsistências" dos requisitos;
Estabelecer o aceite dos documentos fornecidos e o feedback da qualidade dos
mesmos.
O responsável por este papel é o Analista de Testes.
b) Elaborar Casos de Teste: esta atividade é iniciada a partir do momento em que todos os
requisitos do projeto já estejam concluídos e aceitos pelo cliente, bem como os casos de
usos já identificados. Para elaboração dos casos de Teste são analisadas variáveis como
Configuração do ambiente ao qual o Teste deverá ser executado, o tipo de implementação
(manual: que corresponde aos Testes funcionais; automática: corresponde aos Testes
automatizados) e o momento em que o Teste deve ser executado.
As atividades que contemplam esta fase são:
Identificar cada solicitação de mudança requisitada pelo cliente;
Identificar todos os casos de uso envolvidos em cada solicitação;
Descrever os casos de Testes que garantam cada fluxo do caso de uso;
Identificar as modificações estruturais na organização do ambiente;
Especificar as adequações na automação da execução dos Testes (script de Teste);
Cada Analista de Testes apresenta seus casos de Testes por aplicativo;
Reunião para críticas, sugestões e avaliação do nível de cobertura.
3 Todas as pessoas envolvidas no processo: Clientes, desenvolvedores, líderes, analistas, Testers, gerentes, etc...
76
Os responsáveis por este papel são o Analista de Testes e o Tester.
Exemplo de um caso de Teste:
Quadro 4 - Caso de Teste
Fonte: Elaboração dos autores, 2010.
c) Elaborar o Plano de Teste: nesta atividade é elaborado o principal documento do Projeto
de Teste: o Plano de Teste, documento no qual o Gerente de Teste irá mapear todo o
Projeto de Teste em questão, identificando variáveis como: o objetivo do Teste; os
documentos de requisitos entregues; os casos de Testes que deverão ser executados; as
pessoas envolvidas; os prazos e as informações históricas do projeto.
As atividades que contemplam esta fase são:
Identificar todos os casos de Testes envolvidos no projeto;
Especificar as modificações estruturais na organização do ambiente;
Estabelecer um cronograma-detalhado, baseado no cronograma-macro já
elaborado;
Identificar os responsáveis pelo projeto (Testers e Analistas de Testes);
Identificar os riscos do Projeto;
Comunicar a finalização do Projeto.
77
O responsável por este papel é o Analista de Testes.
Abaixo é apresentado o plano de teste.
Quadro 5 - Plano de Teste
Fonte: Elaboração dos autores, 2010.
78
5.2.3 Execução
Diagrama 6 - Visão detalhada do processo de Execução.
Fonte: Elaboração dos autores, 2010.
Objetivos: realizar a execução dos Testes.
Descrição: nesta etapa serão executados os Testes previstos no Plano de Teste. Tem-se
o relatório de Log de Teste e de Incidente, que auxiliam no andamento dos Testes. O
Tester responsável irá executar cada caso de Teste previsto no cronograma conforme o
seu respectivo prazo estipulado. A cada Teste executado, cujo resultado seja negativo,
é gerado um relatório de incidente, o qual será reportado à equipe de desenvolvimento.
O acompanhamento dos Testes executados pode ser feito por meio do relatório de Log
de Teste.
79
Fase: Executar Casos de Testes.
Com base nas especificações persistentes nos documentos de Plano e Teste e Caso de
Teste, o Tester vai executar os Testes, verificando se as entradas e saídas
correspondem aos resultados esperados, especificados nos documentos.
As atividades que contemplam esta fase são:
Execução dos casos de Testes;
Comunicar o Gerente de Teste e o Gerente Projeto eventuais modificações em
relação à duração e prazo de execução do Teste e dificuldades encontradas;
Comunicar os envolvidos no Projeto de Teste o fim de cada ciclo, apresentando o
relatório de Log de Teste;
Realizar uma reunião de Lições Aprendidas.
O responsável por este papel é o Tester.
80
5.2.4 Finalização
Diagrama 7 - Visão detalhada do processo de Finalização.
Fonte: Elaboração dos autores, 2010.
Objetivos: analisar os resultados.
Descrição: na terceira e última etapa, tem-se o resultado dos Testes que foram ou estão
sendo realizados. Aqui é possível obter informações do grau de qualidade do sistema
através de relatórios de Incidentes, bem como o sumário que descreve toda a cobertura
do Teste executado – fornece um sumário das atividades de Testes realizadas durante
81
um determinado projeto e mostra de forma resumida as ocorrências durante todas as
atividades realizadas, finalizando o ciclo do Teste.
Fases: a) Reportar erros ao desenvolvimento; b) Gerenciar Resultados.
a) Reportar erros ao desenvolvimento: no processo de finalização será repassado ao setor
de desenvolvimento os incidentes para que possam ser corrigidos e novamente entrar
em Testes. Isso será feito através dos relatórios de incidentes.
b) Gerenciar Resultados: com os resultados dos Testes cabe então ao gerente de Testes
gerenciar esses resultados para melhorar a qualidade final do processo e
conseqüentemente da aplicação.
As atividades que contemplam esta fase são:
Identificar eventuais modificações em relação à duração e prazo de finalização do
Projeto de Teste;
Analisar dificuldades encontradas;
Reavaliar riscos do projeto em função de um maior detalhamento sobre os
requisitos;
Reavaliar as estimativas de esforço e duração do Processo de Teste; (tarefa
executada se necessário);
Avaliar e tomar medidas quanto à aplicação de mais recursos ou alteração no
cronograma-macro de entrega do projeto juntamente com o gerente de projeto.
(tarefa executada se necessário);
Reportar os incidentes ao desenvolvimento;
O responsável por este papel é o Gerente de Testes.
6 DESENVOLVIMENTO DO SISTEMA DE TESTES
Neste capítulo será apresentada a ferramenta desenvolvida, bem como as
tecnologias que foram utilizadas e a sua modelagem.
82
6.1 VISÃO GERAL
Com a necessidade de realizar Testes nas aplicações desenvolvidas por uma
empresa de software, surge também a necessidade de controlar e gerenciar tais Testes. De
nada adianta testar se não souber o que testar e quais resultados devem ser obtidos para que o
teste seja aprovado, assim como não adianta realizar os testes e não conseguir gerenciar as
informações obtidas através deles.
A aplicação desenvolvida vem no intuito de colaborar na execução e obtenção de
informações dos testes realizados, gerando agilidade dentro do processo de Testes. Nela será
informado tudo que é necessário para executar os Testes, tais como ambiente, condições de
entrada e saída e resultados esperados para cada operação do sistema, colaborando para que o
Tester tenha maior facilidade e eficácia em realizar seu trabalho.
Com a realização dos Testes e o armazenamento organizado dessas informações,
pode-se extrair dados de grande relevância para o gerenciamento da empresa desenvolvedora,
que terá noção do índice de erros do processo de desenvolvimento e poderá definir métricas
de qualidade para sua aplicação.
A aplicação foi projetada dentro do processo descrito acima. Como o processo
prevê quatro papéis para o gerenciamento de Testes, na aplicação será possível cadastrar os
quatro tipos de usuários, cada um com o acesso correspondente à atividade que ele realiza
dentro do processo.
6.1.1 Arquitetura
Para desenvolver a aplicação será utilizado o padrão de projeto MVC, que
consiste basicamente em separar a lógica de negócio (Model) da interface com o usuário
(View) e do fluxo da aplicação (Controller). Sendo assim, a camada de visão não tem acesso
direto ao banco de dados, e vice-versa. Para fazer essa comunicação a camada “View” deve
acessar a camada Controller para assim a camada “Model” acessar o banco de dados. A
83
comunicação entre as camadas é feito através de domínios ou entities, que são classes que
contém as informações referentes à tabela no banco de dados.
Model (DAO): essa camada é responsável por manter as informações no banco de
dados, executando os comandos de alteração, inserção, exclusão e buscas. Essa camada está
totalmente independente da quantidade de telas que o sistema vai ter. Ela somente deve
retornar e/ou executar a solicitação vinda para ela.
View (Interface): é através dela que o usuário vai se comunicar com a aplicação,
onde ficarão a entrada e a saída de informação da aplicação. Ela não deve ter acesso
diretamente ao banco de dados.
Controller (Service): é nessa camada que ficam as regras de negócio, realizando a
comunicação entre a camada model com a camada view, através das solicitações feitas pela
camada view e os retornos da camada model.
A relação entre as camadas é representada no esquema a seguir.
Figura 10 - Arquitetura de aplicações em padrão de projeto MVC.
Fonte: Elaboração dos autores, 2010.
A interface será desenvolvida para ambientes WEB utilizando o Adobe Flex 3,
essa ferramenta é um Framework Free e Open Source, utilizado para criar aplicações RIA
(Rich Internet Applications). O back-end4 da aplicação será desenvolvido em JAVA J2EE
utilizando o Framework Spring para deixar o código dentro do padrão de projeto MVC. A
persistência dos dados será feira através do framework Hibernate Annotations 3 e o banco de
4 Back-end é caracterizado como os componentes que fazem o processamento das informações vindas da
interação que o usuário possui com a aplicação.
84
dados utilizado será o MYSQL 5.1. Por último, a aplicação será hospedada no servidor
Apache TomCat 6.0.
A comunicação entre a interface será feita através do framework BlazeDS,
também um framework Open Source, desenvolvido e fornecido pela Adobe.
Abaixo é apresentada da arquitetura da aplicação.
Esquema 6 - Arquitetura da aplicação.
Fonte: Elaboração dos autores, 2010.
6.2 MODELO CONCEITUAL
Os tópicos seguintes discorrem a respeito do diagrama de casos de uso, sua
descrição , os modelos de domínio e outros.
6.2.1 Diagrama de Caso de Uso
De acordo com Bezerra (2006), o caso de uso tem como objetivo representar a
interação que os atores5 tem sobre o sistema, sem revelar a estrutura e os comportamentos
internos desse sistema. Cada caso de uso deve possuir uma narração sobre as interações que
ocorrem entre os atores e o sistema sua representação é feita por uma elipse com seu nome
posicionado abaixo ou dentro da elipse.
5 Ator é definido como qualquer elemento externo que possui receba ou envie informações com o sistema,
podendo ser pessoas, organizações, equipamentos ou mesmo outros sistemas.
85
Sendo assim o diagrama de caso de uso tem como objetivo representar
graficamente o relacionamento entre atores e os casos de uso.
Diagrama 3 - Diagrama de Casos de Uso.
Fonte: Elaboração dos autores, 2010.
6.2.2 Descrição dos Casos de Uso
Cada caso de uso do diagrama acima será descrito a seguir.
86
6.2.2.1 Manter Tipos de Teste
Atores: Analista de Teste
Pré-Condição: O acesso ao sistema deve ser por um usuário cujo tipo seja Analista de Teste.
Pós-Condições: Um novo tipo de teste deve ser criado.
Fluxo Principal
A1. O ator acessa o módulo Cadastros
S1. O sistema exibe a janela com um campo disponível para pesquisa ou inserção do tipo de
teste. Também lista todos os tipos de testes já cadastrados no sistema, classificando seu
código, e descrição.
A2. O ator inclui um novo tipo de teste, informando sua descrição e observação caso
necessário.
S2. O sistema grava as informações.
Fluxo Alternativo:
A2. O ator inclui um tipo de teste sem informar a descrição.
R2. O sistema exibe uma mensagem notificando o ator de que é obrigatório informar uma
descrição para que o cadastro seja efetuado. Quadro 8 - Manter Plano de Teste.
Fonte: Elaboração dos autores, 2010.
6.2.2.2 Manter Prioridade
Atores: Analista de Teste
Pré-Condição: O acesso ao sistema deve ser por um usuário cujo tipo seja Analista de Teste.
Pós-Condições: Uma nova prioridade deve ser criada.
Fluxo Principal
A1. O ator acessa o módulo Cadastros
S1. O sistema exibe a janela com um campo disponível para pesquisa ou inserção da
prioridade. Também lista todos as prioridades já cadastradas no sistema, classificando seu
código, descrição e nível de prioridade.
A2. O ator inclui uma nova prioridade, informando sua descrição e nível de prioridade.
S2. O sistema grava as informações.
Fluxo Alternativo:
A2. O ator inclui uma prioridade sem informar a descrição e nível de prioridade.
R2. O sistema exibe uma mensagem notificando o ator de que é obrigatório informar todas as
informações obrigatórias para que o cadastro seja efetuado. Quadro 9 - Manter Plano de Teste.
Fonte: Elaboração dos autores, 2010.
87
6.2.2.3 Manter Plano de Teste
Atores: Analista de Testes
Pré-Condição: Os casos de Testes que serão incluídos no Plano de Testes devem estar elaborados e
revisados.
Pós-Condições: O documento de Plano de Teste deve ser gerado e disponível para o Tester.
Fluxo Principal
A1. O ator acessa a janela de cadastro de plano de teste;
S1. O sistema é exibido contendo todos os campos em branco permitindo seu preenchimento;
A2. O ator informa os campos de identificação, descreve a introdução do plano de teste, os itens de
teste, a abordagem do teste, os critérios de liberação, suspensão e retomada, entrega do teste, tarefas
do teste, ambiente, responsáveis, necessidade de equipe, cronograma, riscos e aprovações e finaliza o
processo;
S2. O sistema grava as informações;
Fluxo Alternativo:
A2. O ator finaliza o processo sem informar todos os campos obrigatórios da janela.
R2. O sistema exibe uma mensagem notificando o ator de que é obrigatório informar todos os campos
para que o cadastro seja efetuado. Quadro 10 - Manter Plano de Teste.
Fonte: Elaboração dos autores, 2010.
6.2.2.4 Manter Caso de Teste
Atores: Analista de Testes
Pré-Condição: Não de aplica.
Pós-Condições: Não se aplica.
Fluxo Principal
A1. O ator acessa a janela de cadastro de casos de testes;
S1. O sistema exibe a janela contendo todos os campos em branco permitindo seu preenchimento;
A2. O ator informa todos os campos, tais como a identificação, pré-condições, pós-condições, caso de
teste, massa de entrada e saída, critérios especiais, ambiente, tipo de teste, cronograma e
interdependência e finaliza o processo;
S2. O sistema grava as informações;
Fluxo Alternativo:
A2. O ator finaliza o processo sem informar os campos obrigatórios
R2. O sistema exibe uma mensagem notificando o ator de que é obrigatório informar todos os campos
requeridos para que o cadastro seja efetuado. Quadro 11 - Manter Caso de Teste
Fonte: Elaboração dos autores, 2010.
88
6.2.2.5 Executar Plano de Teste
Atores: Tester
Pré-Condição: O plano de testes deve estar cadastrado no sistema contendo os seus respectivos casos
de Testes que serão executados.
Pós-Condições: Após a execução de todo o plano de teste, são será mais possível alterá-lo
Fluxo Principal
A1. O ator acessa a janela de novo ciclo de testes, no módulo execução;
S1. O sistema é exibido contendo os campos início (desabilitado e preenchido com a data atual),
campo término desabilitado, campo situação (com a situação “Não Executado” por
default) e o campo plano de teste (disponível para preenchimento);
A2. O ator informa o campo plano de teste;
S2. O sistema retorna todos os casos de teste para sua execução.
A3. O ator seleciona o caso de teste e informa o resultado do teste.
Fluxo Alternativo:
A1. Não se aplica.
Quadro 12 - Executar Plano de Teste
Fonte: Elaboração dos autores, 2010.
6.2.2.6 Gerenciar Processos
Atores: Gerente de Teste
Pré-Condição: A execução do plano de teste deve estar finalizada
Pós-Condições: Não se aplica.
Fluxo Principal
A1. O ator acessa o relatório desejado no menu de Finalização.
S1. O sistema é exibido contendo os período da finalização, data inicial e Data final disponíveis para
seu preenchimento.
A2. O ator informa os campos e visualiza o relatório.
S2. O sistema exibe o relatório contendo as informações dos testes executados no período informado.
Fluxo Alternativo:
A2. O ator emite o relatório sem o preenchimento dos campos requeridos.
R2. O sistema exibe uma mensagem notificando o ator de que é obrigatório informar todos os campos
requeridos para que o cadastro seja efetuado. Quadro 13 - Gerenciar processo.
Fonte: elaboração dos autores, 2010.
89
6.2.2.7 Manter usuário e grupo
Atores: Gerente de Teste
Pré-Condição: O acesso ao sistema deve ser por um usuário cujo tipo seja Gerente de Teste.
Pós-Condições: Um novo usuário deve ser criado.
Fluxo Principal
A1. O ator acessa o módulo cadastros
S1. O sistema exibe a janela com um campo disponível para pesquisa ou inserção do usuário.
Também lista todos os usuários já cadastrados no sistema, classificando seu código, login e tipo.
A2. O ator inclui um novo usuário, informando seu nome, senha e seu tipo de acesso.
S2. O sistema grava as informações.
Fluxo Alternativo:
A2. O ator inclui um usuário sem informar os campos requeridos, tais como nome, senha e tipo de
acesso.
R2. O sistema exibe uma mensagem notificando o ator de que é obrigatório informar todos os campos
requeridos para que o cadastro seja efetuado. Quadro 14 - Manter Usuário e Grupo.
Fonte: Elaboração dos autores, 2010.
90
6.2.3 Modelo de Domínio de Classe
Diagrama 4 - Diagrama de domínio de Classe.
Fonte: Elaboração dos autores, 2010.
CLASSE DESCRIÇÃO
Usuário A classe Usuário será responsável por manter as informações referente
ao usuário, como seu login e senha de entrada no sistema e seu tipo de
usuário definindo assim seu acesso.
Grupo Esta classe tem por objetivos manter os grupos de usuários para melhor
gerenciar a equipe de trabalho, agrupando assim os usuários em grupos
com diferentes responsabilidades.
Prioridade Objetivo de manter uma padronização das prioridades que será
utilizadas dentro do sistema, definindo um peso para cada prioridade.
Tipo de Teste Mantém os tipos de Testes que será utilizado nos Testes executados.
Caso de Teste Mantém o caso de Teste, sua descrição e especificação.
Plano de Teste Mantém o planejamento do Teste juntamente com os casos de Teste
agrupado a este plano.
Ciclo de Teste Mantém a informações de uma execução de Testes de um plano de
Teste, quando iniciou quando terminou, e a situação em que a execução
do Testes se encontra.
Notas do ciclo de
Teste
Mantém as observações dos resultados da execução do Teste em cada
caso de Teste, se o caso de Teste foi aprovado, reprovado, necessita de
melhoria. Quadro 15 - Descrição das classes
Fonte: Elaboração dos autores, 2010.
91
6.3 PROJETO FÍSICO
O modelo físico tem como objetivo desmembrar os processos e recursos que serão
utilizados dentro da aplicação, para assim ter uma visão ampla do funcionamento da
aplicação. Neste modelo também se tem a especificação do relacionamento existente entre
cada componente da aplicação.
6.3.1 Diagrama de pacotes
A figura abaixo ilustra o diagrama geral de pacotes mostrando os objetos e o
relacionamento existente em cada pacote.
92
Diagrama 5 - Diagrama geral de pacotes.
Fonte: Elaboração dos autores, 2010.
As representações a seguir relacionam-se respectivamente ao diagrama de pacotes
entitys, repository ou interfaces, services e DAO.
96
.
Diagrama 9 - Diagrama de pacotes DAO.
Fonte: Elaboração dos autores, 2010.
As classes responsáveis pela emissão dos relatórios serão apresentadas a seguir,
sendo que o diagrama de pacotes manager é responsável pela manipulação de qual relatório
será emitido, e a classe servlet, por receber a solicitação da visualização do relatório e
apresentá-la ao usuário.
Diagrama 10 - Pacotes manager.
Fonte: Elaboração dos autores, 2010.
97
Diagrama 11 - Pacotes servlet.
Fonte: Elaboração dos autores, 2010.
A seguir é ilustrado o pacote de infrastructure, responsável por manter as classes
contendo as configurações necessárias para que o framework Spring possa realizar a
instanciação dos objetos e as configurações para o Hibernate Annotations.
Diagrama 12 - Diagrama de pacotes infrastructure.
Fonte: Elaboração dos autores, 2010.
O diagrama apresenta os pacotes contendo as view, que são a interface do sistema,
onde existe a interação entre o usuário e a aplicação.
99
6.3.2 Modelo E.R.
Diagrama 14 - Modelo de ER- Relacionamento entre tabelas.
Fonte: Elaboração dos autores, 2010.
100
6.3.3 Dicionário de Dados
Para uma melhor compreensão do Modelo ER da aplicação faz-se necessário do
uso do diagrama de dados. Nele será descrito qual é o objetivo de cada tabela junto com seus
relacionamentos com as outras tabelas existentes, caso necessário. Informações como a
descrição do atributo, seu tipo, e também a obrigatoriedade estão presentes nessas
especificações.
Tabela 5 - Dicionário de dados entidade usuário.
Tabela: USUARIO
Objetivo Armazenar os usuários cadastrados para acessar o sistema, esta tabela
contém o parâmetro que defini os acessos que o usuário terá.
Relacionamento Esta tabela não possui relacionamento com outras tabelas.
Atributos
Nome Descrição Tipo Regra Obrigatório
id_usuario Código do usuário INTEGER PK Sim
nm_login Login do usuário VARCHAR(50) UQ Sim
ds_senha Senha do usuário VARCHAR(50) Sim
fl_tipousuario Tipo do usuário, definindo os acessos
que o usuário terá no sistema
VARCHAR(3) CK Sim
Fonte: Elaboração dos autores, 2010.
Tabela 6 - Dicionário de dados entidade prioridade.
Tabela: PRIORIDADE
Objetivo Armazenar o nível de prioridade para ser utilizado na execução dos
Testes.
Relacionamento Esta tabela não possui relacionamento com nenhuma tabela.
Atributos
Nome Descrição Tipo Regra Obrigatório
id_prioridade Código da prioridade INTEGER PK Sim
ds_prioridade Descrição da prioridade VARCHAR(50) UQ Sim
nr_pesoprioridade Definição do nível da prioridade,
quanto mais alto for o valor maior
prioridade ele terá.
VARCHAR(50) Sim
Fonte: Elaboração dos autores, 2010.
101
Tabela 7 - Dicionário de dados entidade tipos de Teste.
Tabela: TIPOTESTE
Objetivo Armazenar os tipos de Testes que podem ser efetuados.
Relacionamento Esta tabela não possui relacionamento com nenhuma tabela.
Atributos
Nome Descrição Tipo Regra Obrigatório
id_tipoTeste Código da prioridade INTEGER PK Sim
ds_tipoTeste Descrição da prioridade VARCHAR(50) UQ Sim
ds_observacaodetalhada Definição do nível da
prioridade, quanto mais alto
for o valor maior prioridade
ele terá.
VARCHAR(250) Não
Fonte: Elaboração dos autores, 2010.
Tabela 8 - Dicionário de dados entidade grupo.
Tabela: GRUPO
Objetivo Armazenar os grupos de usuário para definir os responsáveis por
determinados planos de Testes.
Relacionamento Esta tabela não possui relacionamento com nenhuma tabela.
Atributos
Nome Descrição Tipo Regra Obrigatório
id_grupo Código do grupo INTEGER PK Sim
ds_grupo Descrição do grupo VARCHAR(50) UQ Sim Fonte: Elaboração dos autores, 2010.
Tabela 9 - Dicionário de dados entidade de ligação entre grupo e usuário.
Tabela: GRUPOUSUARIO
Objetivo Armazenar os usuários e determinar seus respectivos grupos.
Relacionamento Esta tabela possui relacionamento com a tabela USUARIO e
GRUPO.
Atributos
Nome Descrição Tipo Regra Obrigatório
id_grupo Código do grupo INTEGER PK Sim
id_usuario Código do usuário INTEGER PK Sim Fonte: Elaboração dos autores, 2010.
102
Tabela 10 - Dicionário de dados entidade plano de Teste
Tabela: PLANODETESTE
Objetivo Armazenar os planos de Testes cadastrados.
Relacionamento Esta tabela possui relacionamento com as tabelas USUARIO,
PRIORIDADE e GRUPO.
Atributos
Nome Descrição Tipo Regra Obrigatório
id_planodeTeste Código do plano de Teste INTEGER PK Sim
id_usuariocadastro Usuário que cadastrou o plano
de Teste
INTEGER FK Sim
dt_cadastro Data de cadastro do plano de
Teste
DATETIME Sim
dt_ultimamodificacao Data da ultima alteração no
plano de Teste
DATETIME Não
id_grupo Grupo de usuários responsável
pelo plano de Teste
INTEGER FK Sim
ds_identificacao Identificação única do plano
de Teste informada pelo
usuário
VARCHAR(100) Sim
ds_introducao Introdução ao plano de Teste TEXT Não
ds_itensTeste Descrição dos itens de Teste TEXT Não
ds_abordagemTeste Descrição da abordagem do
Teste
TEXT Não
ds_criteriosliberacao Critérios para realizar a
liberação do plano de Teste
TEXT Não
ds_suspensaoretomada Descrição das condições de
suspensão e retomada de Teste
TEXT Não
ds_documentosentrega Descrição dos documentos
necessários para entregar após
termino dos Testes
TEXT Não
ds_tarefasTeste Descrição das tarefas do Teste TEXT Não
ds_ambientes Descrição dos ambientes que
devem ser testado
TEXT Não
ds_responsaveis Descrição dos responsáveis
por realizar os Testes
TEXT Não
ds_necessidadedaequipe Descrição das necessidade que
o Teste exige da equipe
TEXT Não
ds_riscos Descrição dos riscos TEXT Não
ds_aprovacoes Descrição das condições de
aprovação
TEXT Não
ds_cronograma Cronograma de realização dos
Testes
TEXT Não
id_prioridade Prioridade do plano de Teste INTEGER FK Sim Fonte: Elaboração dos autores, 2010.
103
Tabela 11 - Dicionário de dados entidade caso de Teste
Tabela: CASODETESTE
Objetivo Armazenar as informações referentes ao caso de Teste, e a qual plano
de Teste o mesmo pertence.
Relacionamento Esta tabela não possui relacionamento com as tabelas USUARIO,
PRIORIDADE, TIPOTESTE e PLANODETESTE.
Atributos
Nome Descrição Tipo Regra Obrigatório
id_casodeTeste Código da caso de Teste INTEGER PK Sim
id_usuariocadastro Código do usuário que fez o
cadastro do caso de Teste
INTEGER FK Sim
dt_cadastro Data de cadastro DATETIME Sim
dt_ultimamodificacao Data da ultima alteração DATETIME Não
ds_identificacao Identificação única do caso de
Teste que é informada pelo
usuário.
VARCHAR(100) Sim
ds_precondicoes Condições necessárias para
iniciar o Teste
TEXT Não
ds_poscondicoes Condições após terminar o
Teste
TEXT Não
ds_casodeTeste Descrição do caso de Teste TEXT Não
ds_entradasaida Entradas e saídas da execução
do caso de Teste
TEXT Não
ds_criteriosespeciais Critérios especiais do caso de
Teste
TEXT Não
ds_ambiente Ambiente em que o Teste deve
ser realizado
TEXT Não
ds_dependencias Dependências com outros caso
de Teste
TEXT Não
ds_cronograma Cronograma de execução dos
Testes.
TEXT Não
id_planodeTeste Plano de Testes deste caso de
Testes
INTEGER FK Não
id_prioridade Prioridade do caso de Teste INTEGER FK Sim
id_tipoTeste Tipo do Teste INTEGER FK Sim Fonte: Elaboração dos autores, 2010.
104
Tabela 12 - Dicionário de dados entidade ciclo de Teste
Tabela: CICLODETESTE
Objetivo Armazenar os ciclos de Testes efetuados no plano de Teste, cada plano
de Teste pode ter vários ciclos de execução.
Relacionamento Esta tabela possui relacionamento com as tabelas USUARIO,
PLANODETESTE.
Atributos
Nome Descrição Tipo Regra Obrigatório
id_ciclodeTeste Código da ciclo de Teste INTEGER PK Sim
id_planodeTeste Código do plano de Teste INTEGER FK Sim
dt_inicio Data em que o ciclo de Teste teve
inicio
DATETIME Sim
dt_termino Data em que o ciclo de Teste foi
finalizado
DATETIME Não
fl_status Situação atual do ciclo de Teste VARCHAR(2) Sim
id_usuario Código do usuário que esta
realizando o ciclo de Teste
INTEGER FK Sim
Fonte: Elaboração dos autores, 2010.
Tabela 13 - Dicionário de dados entidade ciclo de Teste notas.
Tabela: CICLODETESTE_NOTAS
Objetivo Armazenar as observações referentes ao ciclo de Teste, se o Teste
passou, não passou uma observação sobre a execução.
Relacionamento Esta tabela não possui relacionamento com as tabelas CICLODETESTE
e CASODETESTE.
Atributos
Nome Descrição Tipo Regra Obrigatório
id_ciclodeTeste Código do ciclo de Teste INTEGER PK Sim
id_ciclodeTeste_nota Código do item do ciclo de Teste INTEGER PK Sim
id_casodeTeste Código do caso de Teste da
execução
INTEGER FK Sim
dt_nota Data de anotação DATETIME Sim
fl_posicao Posição da execução VARCHAR(2) Sim
ds_observacao Observação sobre a execução VARCHAR(250) Sim
id_usuario Usuário que cadastrou a nota INTEGER FK Sim Fonte: Elaboração dos autores, 2010.
105
7 VALIDAÇÃO DA FERRAMENTA
É importante ressaltar algumas padronizações existentes dentro da aplicação. É
possível notar que, em todos os cadastros, existe um caractere “ * ” em vermelho ao lado dos
campos necessários no cadastro. Esse caractere significa que aquele campo é de
preenchimento obrigatório, ou seja, o cadastro não será gravado caso este não esteja
preenchido.
O sistema é controlado pelos tipos de usuários cadastrados nele, sendo que cada
tipo de usuário tem uma determinada permissão e conseqüentemente um acesso diferenciado
dentro do sistema. Quando é feito o login, o sistema carrega as permissões do usuário, e
configura o sistema de acordo com tais permissões. Sem efetuar o login, não é possível
acessar nenhuma informação dentro do sistema.
Figura 11 - Tela de login
Fonte: Elaboração dos autores, 2010.
Abaixo seguem imagens que mostram os acessos para cada tipo de usuário que
existe no sistema. Seguem respectivamente os usuários gerente de teste, analista de teste e
tester.
106
Figura 12 - Menu do usuário gerente de teste
Fonte: Elaboração dos autores, 2010.
Figura 13 - Menu do usuário analista de teste
Fonte: Elaboração dos autores, 2010.
107
Figura 14 - Menu do usuário Tester
Fonte: Elaboração dos autores, 2010.
Na figura abaixo, tem-se a lista de usuários. A janela possibilita alterar, excluir e
incluir um usuário no sistema. É possível filtrar pelo nome e buscar o usuário desejado. Esta
mesma tela é utilizada quando existe a necessidade de pesquisar um usuário para referenciar
em outro cadastro.
Figura 15 - Lista de usuários
Fonte: Elaboração dos autores, 2010.
108
Para cadastrar um usuário é necessário informar seu nome, senha e seu tipo
(gerente de teste, analista e tester). Este último define os acessos que ele terá no sistema. A
tela de inclusão é igual a tela de edição de um usuário, visto que na edição não é possível
visualizar a senha, apenas alterá-la. Nem mesmo o gerente de teste pode visualizar a senha de
um usuário, podendo apenas redefini-la em caso de perca. Abaixo consta a imagem do
cadastro de usuário.
Figura 16 - Cadastro de usuário
Fonte: Elaboração dos autores, 2010.
Dentro da lista de grupo de usuário, tem-se a possibilidade de alterar, excluir e
incluir um grupo no sistema. É possível realizar filtros para buscar o grupo. Esta mesma tela é
utilizada quando se deseja referenciar um determinado grupo em outro cadastro.
Figura 17 - Lista de grupo de usuários
Fonte: Elaboração dos autores, 2010.
109
Para cadastrar um grupo de usuários, é necessário preencher informações como
sua descrição e os usuários respectivos ao grupo, conforme a imagem abaixo. Dentro do
cadastro é possível incluir e adicionar um novo usuário ao grupo, pesquisar um usuário já
cadastrado e remover um usuário do grupo.
Figura 18 - Cadastro de grupo de usuário
Fonte: Elaboração dos autores, 2010.
Dentro da lista de tipos de testes, tem-se a possibilidade de alterar, excluir e
incluir um tipo de teste no sistema. Pode-se realizar filtros por descrição para buscar o tipo de
teste desejado. Esta mesma tela é utilizada quando existe a necessidade de pesquisar um tipo
de teste para referenciar em outro cadastro.
110
Figura 19 - Lista tipo de teste
Fonte: Elaboração dos autores, 2010.
Para cadastrar um tipo de teste é necessário obrigatoriamente informar sua
descrição, existindo a possibilidade de escrever uma observação referente ao tipo de teste caso
se faça necessário. A imagem abaixo apresenta a tela do cadastro do tipo de teste.
Figura 20 - Cadastro de tipo de teste
Fonte: Elaboração dos autores, 2010.
Dentro da lista de prioridades, é possível alterar, excluir e incluir uma prioridade
no sistema. Pode-se realizar filtros por descrição para buscar a prioridade desejada. Esta
111
mesma tela é utilizada quando existe a necessidade de pesquisar uma prioridade para
referenciar em outro cadastro – conforme imagem abaixo.
Figura 21 - Lista de prioridade
Fonte: Elaboração dos autores, 2010.
Para cadastrar uma prioridade é necessário informar a sua descrição e o nível de
prioridade - que identifica o grau de prioridade da mesma. Quanto mais alto for o nível, maior
prioridade ela terá.
Figura 22 - Cadastro de prioridade
Fonte: Elaboração dos autores, 2010.
Dentro da lista de plano de testes, é possível alterar, incluir e excluir um plano de
teste no sistema. Pode-se filtrar pela sua identificação, buscando o plano de teste desejado.
Esta mesma tela é utilizada para selecionar qual o plano de teste será testado.
112
Figura 23 - Lista de plano de teste
Fonte: Elaboração dos autores, 2010.
Para se cadastrar um plano de testes, é necessário informar uma descrição
contendo sua identificação que deve ser única, referenciar um grupo responsável e uma
prioridade ao plano de teste. Outras informações devem ser inseridas, tais como: Introdução
do Plano de Teste, os Itens de Teste, a Abordagem do Teste, os Critérios de Liberação,
Suspensão e Retomada, Entrega do Teste, Tarefas do Teste, Ambiente, Responsáveis,
Necessidade de Equipe,Cronograma e Riscos e Aprovações.
Após isso, pode-se referenciar ao plano de teste os casos de testes já cadastrados
no sistema, ou mesmo incluir novos casos de testes para este plano de teste e, ainda, remover
um caso de teste do plano de testes. Abaixo a imagem do cadastro de plano de teste.
113
Figura 24 - Cadastro de plano de teste
Fonte: Elaboração dos autores, 2010.
Dentro da lista de caso de teste, o sistema possibilidade alterar, excluir e incluir
um caso de teste. Pode-se realizar filtros por identificação para buscar o caso de teste
desejado. Esta mesma tela é utilizada ao realizar o relacionamento entre os casos de testes e o
plano de teste.
114
Figura 25 - Lista de caso de teste
Fonte: Elaboração dos autores, 2010.
Para se cadastrar um caso de testes é necessário informar uma descrição contendo
sua identificação que deve ser única, deve se referenciar uma prioridade e um tipo de teste.
Outras informações podem ser inseridas dentro do caso de teste, informações estas que não
são obrigatórias, tais como: Identificação, Pré-Condições, Pós-condições, Caso de Teste,
Massa de entrada e saída, Critérios especiais, Ambiente, Tipo de Teste, Cronograma e
Interdependência entre os casos de teste.
115
Figura 26 - Cadastro de caso de teste
Fonte: Elaboração dos autores, 2010.
Dentro da lista de ciclos de teste, você poderia visualizar quais testes estão sendo
executados no momento, quais foram executados, finalizados e não testado. Tem-se a
possibilidade alterar, excluir e incluir um ciclo de teste no sistema.
Figura 27 - Lista de ciclos de execução do plano de teste
Fonte: Elaboração dos autores, 2010.
116
A tela de ciclo de teste é responsável por fazer a execução do teste. Para iniciar
um novo ciclo, deve-se selecionar o plano de teste que será testado, então o sistema
automaticamente vai carregar os casos de testes que estão vinculados ao plano selecionado.
Nesta tela constam a opções que permitem consultar a observação descrita na
execução do caso de testes, aprovar ou reprovar o caso de teste. Também é possível consultar
a especificação do caso de teste selecionado. A imagem a seguir apresenta esta janela.
Figura 28 - Execução do plano de teste
Fonte: Elaboração dos autores, 2010.
A tela abaixo se refere às notas da execução do caso de testes. Ela serve para
informar a situação do caso de teste: se ele foi aprovado, reprovado, finalizado ou necessita de
melhoria. O campo de observação serve para descrever o motivo e sugestões para que o
problema possa ser resolvido.
117
Figura 29 - Notas da execução do plano de teste
Fonte: Elaboração dos autores, 2010.
A figura a seguir ilustra a tela para a emissão do relatório de log de Testes
seguindo o relatório já impresso. O período de finalização pode ser informado manualmente
ou utilizar a opção de períodos pré-definidos. Sendo obrigatório informar uma data inicial e
uma data final.
Figura 30 - Filtros do relatório de log de Teste
Fonte: Elaboração dos autores, 2010.
118
Figura 31 - Visualização do relatório de log de Teste
Fonte: Elaboração dos autores, 2010.
A imagem abaixo mostra a tela para a emissão do relatório de incidentes seguindo
o relatório já impresso. Pode-se informar o período de finalização manualmente ou utilizar a
opção de períodos pré-definidos.
Figura 32 - Filtros do relatório de Incidentes
Fonte: Elaboração dos autores, 2010.
Figura 33 - Visualização do relatório de incidentes
Fonte: Elaboração dos autores, 2010.
119
A figura a seguir ilustra a tela para a emissão do relatório de sumário seguindo o
relatório já impresso. O período de finalização pode ser informado manualmente ou pode-se
utilizar a opção de períodos pré-definidos. Sendo que é obrigatório informar uma data inicial e
uma data final.
Figura 34 - Filtros do relatório de sumário
Fonte: Elaboração dos autores, 2010.
Figura 35 – Visualização do relatório de sumário
Fonte: Elaboração dos autores, 2010.
120
8 CONCLUSÃO
Existe hoje uma necessidade de implementar Testes dentro do ciclo de
desenvolvimento de software de uma empresa, com o objetivo de agregar qualidade ao seu
produto. Esta necessidade vem surgindo com o alto grau de exigência dos clientes que
solicitam uma ferramenta segura, estável e confiável, vindo também ao encontro da
necessidade da própria empresa desenvolvedora em reduzir custos, visto que, com a execução
de Testes, muitos erros são identificados e corrigidos antes de ir para o cliente. Quando esses
erros são corrigidos dentro da própria empresa, o valor e o tempo para tal correção é reduzido.
Essa alta demanda de mão de obra especializada em gerenciamento de Testes
fez com que esses profissionais ficassem escassos no mercado, dificultando assim a
implantação desta atividade nas empresas, principalmente nas menores, já que seu capital e
potencial de investimento é limitado.
Sem o profissional capaz de implementar a atividade de Testes dentro da
empresa, surge a necessidade de uma ferramenta simples e estruturada em um processo já
definido, para que profissionais menos experientes em gerenciamento de Testes possam
utilizá-la, montando apenas as especificações do produto a ser testado, reduzindo assim os
investimentos com treinamentos específicos, consultorias, entre outras.
Para a definição do processo de Testes foi feito um estudo sobre as
metodologias para gerenciamento de processo com foco em Testes. Nessa análise optou-se
por utilizar o MPS.BR. Foi construída uma aplicação para ambiente WEB, fornecendo
flexibilidade a empresa que a utilizará, podendo acompanhar o processo de qualquer local que
possua uma conexão com a Internet.
No decorrer deste trabalho, surgiram algumas dificuldades. As dificuldades
começaram a aparecer no desenvolvimento do processo, visto que ele deveria ser objetivo,
claro e simples. Como a área de Testes é abrangente, abstrair essas informações para
simplificar o processo foi trabalhoso, exigiu muito tempo de pesquisa.
Foram encontrados alguns obstáculos durante a implementação da aplicação. A
ferramenta utilizada para criar a interface possui alguns bugs e em alguns momentos o seu
desempenho diminui. Outro fator que causou alguns transtornos foi o formato da interface.
Ela manipulava os campos do tipo texto, gravando os campos textos com as suas formatações
em HTML, dificultando a manipulação por parte dos desenvolvedores. Esse problema, porém,
121
foi superado. O desenvolvimento da nova ferramenta foi fundamental, pois a ferramenta de
relatório em sua versão atual não possui suporte para o tipo texto, causando uma má
visualização dos dados.
Com a finalização da ferramenta, tornou-se possível adicionar recursos que são
extremamente interessantes para auxiliar na tomada de decisão sobre o processo envolvido,
tais como: a) permitir reportar os erros ao desenvolvimento: esse link direto com o
desenvolvimento reduziria o tempo entre o repasse dos problemas ao desenvolvimento e o
retorno do mesmo para novos Testes; b) relatório de tempo gasto: construir um relatório onde
se possa visualizar o tempo gasto nos Testes por usuário, para verificar a produtividade do
funcionário. c) gráficos de incidentes: montar um gráfico onde possa se visualizar de forma
clara e rápida o funcionamento geral da aplicação, informando o que está funcionando e o que
não está funcionando.
Acredita-se ter alcançado todos os objetivos e requisitos propostos no início
deste trabalho. Em especial, adquiriu-se maior conhecimento na área de Testes, através do
embasamento teórico utilizado. O resultado foi a criação de uma ferramenta que pode ser
comercializada.
122
REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 9000:2000 : Sistemas
de gestão de qualidade : fundamentos e vocabulário. Rio de Janeiro, 2000.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO:
SOFTEX. MPS.BR . Guia Geral do MPS.BR - Guia de Implementação – Parte 1:
Fundamentação para Implementação do Nível G do MR-MPS. Set. 2009. Disponível em:
<www.softex.br>. Acesso em: out. 2009.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO:
SOFTEX. MPS.BR. Guia de Implementação – Parte 2: Fundamentação para Implementação
do Nível F do MR-MPS. Ago. 2009. Disponível em: <www.softex.br>. Acesso em: out.
2009.
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML 2. ed. Rio de
Janeiro: Campus, 2006.
BRAUNS, A. et al. Apoiando a Implementação do Modelo de Maturidade MPS Nivel G.
Engenharia de Software Magazine, São Paulo, ano 2, 7. ed. 2008.
CAMPOS, Fábio Ferrari. Técnicas de Integração de Sistema: Big Bang e Sandwich.
Disponível em: <http://qualidadebr.wordpress.com/tag/Teste-de-integracao/>. Acesso em: 11
jun. 2009.
CAMPOS, Fabio M. Qualidade, qualidade de software e garantia da qualidade de
software são as mesmas coisas?. Disponível em:
<http://www.testexpert.com.br/?q=node/669>. Acesso em: 12 out. 2009.
CASIMIRO, Samuel D. Desmistificando o MPS.BR. Disponível em:
<http://blogdosamueldiniz.blogspot.com/2009/02/desmistificando-o-mpsbr-introducao.html>.
Acesso em: 04 set. 2009.
DIAS NETO, Claudio Dias, Introdução a Testes de Software. Engenharia de Software
Magazine. ano 1, 1. ed. 2007.
ESPINHA, Rafael, Melhorando Processos Através de Análise de Risco e Conformidade.
Engenharia de Software Magazine. São Paulo, ano 1, 1. ed. 2007.
FALBO, Ricardo de Almeida. Introdução à Qualidade de Software. Disponível em:
<http://webcache.googleusercontent.com/search?q=cache:Y9F2NdOYBSQJ:www.inf.ufes.br/
~falbo/files/Aula%25201.ppt+Introdu%C3%A7%C3%A3o+%C3%A0+Qualidade+de+Softw
are,+Universidade+Federal+do+Esp%C3%ADrito+Sando,+2008&cd=1&hl=pt-
BR&ct=clnk&gl=br>. Acesso em: 01 jun. 2010.
JUNQUEIRA, Rafael. Análise sobre CMM, CMMI e MPS BR. Disponível em:
<http://blender3dcarioca.wordpress.com/2009/05/19/analise-sobre-cmm-cmmi-e-MPS.BR/>.
Acesso em: 04 set. 2009.
123
LOURENÇO, Marcelo. Qualidade de Software. Disponível em:
<http://qualidade-de-software.blogspot.com/2010/01/Teste-de-estresse.html>.
Acesso em: abr. 2010.
MOLINARI, Leonardo. Testes Funcionais de Software. Santa Maria (RS): Visual Books,
2008.
OLIVEIRA, R; PEREIRA, M. Qualidade de Software. Engenharia de Software Magazine.
ano 1, 1. ed. 2007.
PROJECT MANAGEMENT INSTITUTE - PMI. A Guide to the Project
Management Body of Knowledge - PMBOK™. Disponível em: <www.pmi.org>. Acesso
em: out. 2009.
PONTES, Melissa Barbosa et. al. Validação, verificação & teste. Engenharia de Software
Magazine. ano 2, 15. ed. 2009.
PRESSMAN, Roger S. Engenharia de Software. São Paulo: Makron Books, 1995.
SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003.
SODRÉ, Elisângela. Mps Br – Melhoria do Processo de Software Brasileiro. Disponível
em: <http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/245>. Acesso em: abr.
2010
WTHREEX/RUP. Rational Software Corporation. (Copyright(c) 1987 - 2001). Disponível
em: <http://www.wthreex.com/rup/process/workflow/manageme/co_meqlty.htm>. Acesso
em: abr. 2010.