projeto de conclusão de curso - anderson nascimento / mariana benedett

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





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





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.


______________________________________________________

Prof. Alessandro Zanini.


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


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


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


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


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


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.


Gráfico 1 - Resultados da avaliação em abrangência - ameaças


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.


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.


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.

.


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.


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.


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.



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.


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:

73

Diagrama 1 - Visão geral do Processo de Teste.


74

5.2.2 Inicialização

Diagrama 2 - Visão detalhada do processo de inicialização


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


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.


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


78

5.2.3 Execução

Diagrama 6 - Visão detalhada do processo de Execução.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


requeridos para que o cadastro seja efetuado. Quadro 11 - Manter Caso de Teste


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


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.


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.


Fluxo Alternativo:

A2. O ator inclui um usuário sem informar os campos requeridos, tais como nome, senha e tipo de

acesso.


requeridos para que o cadastro seja efetuado. Quadro 14 - Manter Usuário e Grupo.


90

6.2.3 Modelo de Domínio de Classe

Diagrama 4 - Diagrama de domínio de Classe.


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


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.


As representações a seguir relacionam-se respectivamente ao diagrama de pacotes

entitys, repository ou interfaces, services e DAO.

93

Diagrama 6 - Diagrama de pacotes entitys.


94

Diagrama 7 - Diagrama de pacotes repository.


95

Diagrama 8 - Diagrama de pacotes service.


96

.

Diagrama 9 - Diagrama de pacotes DAO.


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.


97

Diagrama 11 - Pacotes servlet.


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.


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.

98

Diagrama 13 - Diagrama de pacotes view.


99

6.3.2 Modelo E.R.

Diagrama 14 - Modelo de ER- Relacionamento entre tabelas.


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


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


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


101

Tabela 7 - Dicionário de dados entidade tipos de Teste.

Tabela: TIPOTESTE

Objetivo Armazenar os tipos de Testes que podem ser efetuados.


Atributos


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


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.


Atributos


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


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


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


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


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


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


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


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


Figura 13 - Menu do usuário analista de teste


107

Figura 14 - Menu do usuário Tester


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


118

Figura 31 - Visualização do relatório de log de Teste


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


Figura 33 - Visualização do relatório de incidentes


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


Figura 35 – Visualização do relatório de sumário


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.