Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Upcoming SlideShare
Loading in...5
×
 

Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett

on

  • 5,813 views

IMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE UM SISTEMA DE GESTÃO DE TESTES.

IMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE UM SISTEMA DE GESTÃO DE TESTES.

Statistics

Views

Total Views
5,813
Slideshare-icon Views on SlideShare
5,813
Embed Views
0

Actions

Likes
1
Downloads
51
Comments
2

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Obrigado Evandro.
    Are you sure you want to
    Your message goes here
    Processing…
  • Muito bom, parabéns !!!!
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett Document Transcript

    • UNIVERSIDADE DO SUL DE SANTA CATARINA ANDERSON ANTONIO DO NASCIMENTO DA SILVA MARIANA BENEDETT SEVERINOIMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE UM SISTEMA DE GESTÃO DE TESTES. Tubarão 2010
    • ANDERSON ANTONIO DO NASCIMENTO DA SILVA MARIANA BENEDETT SEVERINOIMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE UM SISTEMA DE GESTÃO DE TESTES. Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação. Orientador: Prof. Edjandir Corrêa Costa. Tubarão 2010
    • ANDERSON ANTONIO DO NASCIMENTO DA SILVA MARIANA BENEDETT SEVERINOIMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE UM SISTEMA DE GESTÃO DE TESTES. Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina. Tubarão, 14 de junho de 2010. ______________________________________________________ Prof. Rafael Avila Faraco. Universidade do Sul de Santa Catarina ______________________________________________________ Prof. Eder Cachoeira. Universidade do Sul de Santa Catarina ______________________________________________________ Prof. Alessandro Zanini. Universidade do Sul de Santa Catarina
    • Dedico este trabalho aos meus pais (José eAna) por sempre terem me apoiado eincentivado não somente para a conclusãodeste projeto, mas como em toda minha vida.(Anderson)Dedico este trabalho aos meus pais e toda aminha 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 edificultoso trajeto, muito importante em nossas vidas profissionais. A nossos pais devemos gratidão eterna por nos guiarem no caminho certo, peloapoio 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 eexperiências. Ao nosso orientador Edjandir Corrêa Costa, que nos ajudou em momentos dedú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).
    • RESUMOO propósito deste trabalho é fornecer uma ferramenta contendo um método simplificado quepossa auxiliar na implantação de um processo de Testes de software. A ferramenta dará aogerente 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 deTestes de software. A referida ferramenta foi desenvolvida a partir de estudos bibliográficos eeletrônicos, que serviram de base para a sua construção. A ferramenta em questão atua sob osníveis G e F do modelo de maturidade de software MPS.BR. A qualidade do software se tornahoje uma área de extrema importância para as organizações consumidoras que pretendemgarantir o seu espaço no mercado de desenvolvimento de software. Por conta disso, estasorganizações vêm procurando métodos e processos que possam avaliar a qualidade do seuproduto final. A área de Testes se mostra peça chave para a validação e a garantia de que oproduto está apto a ser entregue ao cliente da forma como foi solicitado. Observa-se hoje aimaturidade que as empresas têm na área Testes. Grande parte delas realiza seus Testesjuntamente com o desenvolvimento de software e, até mesmo, utilizando o usuário final dosistema, 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 odesenvolvimento 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 canassist in the implementation of a process of Testing Software. The tool will give the managersecurity and ability to measure the quality of your product. In this work, specifically, the tooldeveloped by academiwill be a help in the process of Testing Software. This tool wasdeveloped from studies of bibliographic and electronic, which formed the basis for itsconstruction. The tool in question operates under the G and F levels of maturity model forsoftware MPS.BR. The quality of the software now becomes an area of extreme importancefor organizations to consumers wanting to ensure their place in the market for softwaredevelopment. Because of this, these organizations have been searching for methods andprocesses that can assess the quality of your final product. The area of Testing proves is a keypiece for the validation and assurance that the product is suitable to be delivered to thecustomer as it was requested. It is observed today immaturity that companies have in the fieldTests. Many of them realize their tests along with the development of software and even usingthe end user of the system, which is not recommended by reputable software qualityprocesses. In this sense, the authors of this monograph believe in the importance of this toolfor the development of software quality.Key words: software quality. Testing softwares. Testing process.
    • LISTA DE ILUSTRAÇÕESFigura 1 - Pessoas envolvidas dentro da qualidade .................................................................. 23Esquema 1 - Sincronismo entre desenvolvimento e Gerenciamento de Qualidade. ................ 24Quadro 1 - Gerenciamento da Qualidade do Projeto segundo o PMI. ..................................... 25Quadro 2 - Padrões de produto e de processo .......................................................................... 26Fluxograma 1 - Fluxo do gerenciamento da qualidade do processo ........................................ 27Figura 2 - Atributos de Qualidade do software ........................................................................ 28Esquema 2 - Padrões de intercâmbio de documentos .............................................................. 29Esquema 3 - Análise de Riscos ................................................................................................ 33Gráfico 1 - Resultados da avaliação em abrangência - ameaças .............................................. 34Figura 3 - Localização da qualidade dentro da engenharia. ..................................................... 37Gráfico 2 - Custo de correções ................................................................................................. 38Figura 4 - Defeito x Erro x Falha ............................................................................................. 39Figura 5 - Diferentes interpretações ao longo do ciclo de desenvolvimento de um software. . 42Quadro 3 - Exemplo de um Caso de Teste simples. ................................................................. 46Figura 6 - Componentes existentes em Testes caixa preta. ...................................................... 47Esquema 4 - Representação dos módulos de Teste .................................................................. 50Esquema 5 - Testes de integração. ........................................................................................... 51Figura 7 - Componentes existentes em Testes caixa branca. ................................................... 57Figura 8 - Níveis de refinamento. ............................................................................................. 58Figura 9 - Laços existentes nos Testes de ciclo. ....................................................................... 60Esquema 6 - Componentes do modelo MPS. ........................................................................... 63Diagrama 1 - Visão geral do Processo de Teste. ...................................................................... 73Diagrama 2 - Visão detalhada do processo de inicialização .................................................... 74Quadro 4 - Caso de Teste ......................................................................................................... 76Quadro 5 - Plano de Teste ........................................................................................................ 77Diagrama 3 - Visão detalhada do processo de Execução. ........................................................ 78Diagrama 4 - Visão detalhada do processo de Finalização. ..................................................... 80Figura 10 - Arquitetura de aplicações em padrão de projeto MVC.......................................... 83Esquema 7 - Arquitetura da aplicação. ..................................................................................... 84Diagrama 5 - Diagrama de Casos de Uso. ................................................................................ 85
    • Quadro 6 - Manter Plano de Teste. ........................................................................................... 86Quadro 7 - Manter Plano de Teste. ........................................................................................... 86Quadro 8 - Manter Plano de Teste. ........................................................................................... 87Quadro 9 - Manter Caso de Teste ............................................................................................. 87Quadro 10 - Executar Plano de Teste ....................................................................................... 88Quadro 11 - Gerenciar processo. .............................................................................................. 88Quadro 12 - Manter Usuário e Grupo. ...................................................................................... 89Diagrama 6 - Diagrama de domínio de Classe. ........................................................................ 90Quadro 13 - Descrição das classes ........................................................................................... 90Diagrama 7 - Diagrama geral de pacotes.................................................................................. 92Diagrama 8 - Diagrama de pacotes entitys. .............................................................................. 93Diagrama 9 - Diagrama de pacotes repository. ........................................................................ 94Diagrama 10 - Diagrama de pacotes service. ........................................................................... 95Diagrama 11 - Diagrama de pacotes DAO. .............................................................................. 96Diagrama 12 - Pacotes manager. .............................................................................................. 96Diagrama 13 - Pacotes servlet. ................................................................................................. 97Diagrama 14 - Diagrama de pacotes infrastructure. ................................................................ 97Diagrama 15 - Diagrama de pacotes view. ............................................................................... 98Diagrama 16 - Modelo de ER- Relacionamento entre tabelas. ................................................ 99Figura 11 - Tela de login ........................................................................................................ 105Figura 12 - Menu do usuário gerente de teste ........................................................................ 106Figura 13 - Menu do usuário analista de teste ........................................................................ 106Figura 14 - Menu do usuário Tester ....................................................................................... 107Figura 15 - Lista de usuários .................................................................................................. 107Figura 16 - Cadastro de usuário.............................................................................................. 108Figura 17 - Lista de grupo de usuários ................................................................................... 108Figura 18 - Cadastro de grupo de usuário............................................................................... 109Figura 19 - Lista tipo de teste ................................................................................................. 110Figura 20 - Cadastro de tipo de teste ...................................................................................... 110Figura 21 - Lista de prioridade ............................................................................................... 111Figura 22 - Cadastro de prioridade ......................................................................................... 111Figura 23 - Lista de plano de teste .......................................................................................... 112Figura 24 - Cadastro de plano de teste ................................................................................... 113Figura 25 - Lista de caso de teste ........................................................................................... 114
    • Figura 26 - Cadastro de caso de teste ..................................................................................... 115Figura 27 - Lista de ciclos de execução do plano de teste ...................................................... 115Figura 28 - Execução do plano de teste .................................................................................. 116Figura 29 - Notas da execução do plano de teste ................................................................... 117Figura 30 - Filtros do relatório de log de Teste ...................................................................... 117Figura 31 - Visualização do relatório de log de Teste ............................................................ 118Figura 32 - Filtros do relatório de Incidentes ......................................................................... 118Figura 33 - Visualização do relatório de incidentes ............................................................... 118Figura 34 - Filtros do relatório de sumário ............................................................................. 119Figura 35 – Visualização do relatório de sumário .................................................................. 119
    • LISTA DE TABELASTabela 1 - Resultados da avaliação em abrangência por área de processo. .............................. 34Tabela 2 - Refinamento utilizando Valores-Limites. ............................................................... 54Tabela 3 - Exemplo de uma tabela de decisão.......................................................................... 55Tabela 4 - Tabela dos representando níveis do MPS.BR. ........................................................ 64Tabela 5 - Dicionário de dados entidade usuário. .................................................................. 100Tabela 6 - Dicionário de dados entidade prioridade. .............................................................. 100Tabela 7 - Dicionário de dados entidade tipos de Teste. ........................................................ 101Tabela 8 - Dicionário de dados entidade grupo. ..................................................................... 101Tabela 9 - Dicionário de dados entidade de ligação entre grupo e usuário. ........................... 101Tabela 10 - Dicionário de dados entidade plano de Teste ...................................................... 102Tabela 11 - Dicionário de dados entidade caso de Teste ........................................................ 103Tabela 12 - Dicionário de dados entidade ciclo de Teste ....................................................... 104Tabela 13 - Dicionário de dados entidade ciclo de Teste notas.............................................. 104
    • LISTA DE SIGLASBID - Banco Interamericano de Desenvolvimento.CMMI - Capability Maturity Model IntegrationETM - 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 EngineersII - 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 projetoNIST - National Institute of Standards and TechnologyRIA – Rich Internet ApplicationSOFTEX - Associação para Promoção da Excelência do Software Brasileiro.
    • SUMÁRIO1 INTRODUÇÃO................................................................................................................. 161.1 OBJETIVOS .................................................................................................................... 171.1.2 Objetivo Geral ............................................................................................................. 171.1.3 Objetivos Específicos................................................................................................... 181.2 RESULTADOS ESPERADOS ........................................................................................ 181.3 JUSTIFICATIVA ............................................................................................................ 181.4 METODOLOGIA ............................................................................................................ 191.5 APRESENTAÇÃO DO DOCUMENTO ......................................................................... 202 QUALIDADE DE SOFTWARE....................................................................................... 222.1 GERENCIAMENTO DE QUALIDADE ........................................................................ 232.1.1 Padrões de Qualidade ................................................................................................. 252.1.2 Qualidade do Processo e do Produto. ........................................................................ 262.1.3 O planejamento de Qualidade.................................................................................... 272.1.4 Padrões de documentação .......................................................................................... 292.1.5 Medição e Métricas ..................................................................................................... 302.2 SOFTWARE QUALITY ASSURANCE .......................................................................... 312.3 ANÁLISE DE RISCOS ................................................................................................... 312.4 CONSIDERAÇÕES FINAIS ........................................................................................... 353 TESTES ............................................................................................................................. 363.1 VISÃO DE TESTES DE SOFTWARE ............................................................................ 363.1.1 Conceitos de Testes...................................................................................................... 383.1.2 Defeitos do desenvolvimento ...................................................................................... 413.1.3 Gerenciamento de Testes ............................................................................................ 433.2 REQUISITOS E CASOS DE TESTES ........................................................................... 433.2.1 Definindo os requisitos ................................................................................................ 443.2.2 Definindo casos de testes ............................................................................................. 443.3 TIPOS DE TESTES ......................................................................................................... 463.3.1 Teste Funcional............................................................................................................ 473.3.2 Testes de Unidade ........................................................................................................ 483.3.3 Testes de Sistema ......................................................................................................... 48
    • 3.3.4 Testes de Aceitação...................................................................................................... 493.3.5 Testes de Integração .................................................................................................... 493.3.5.1 Não Incremental ......................................................................................................... 493.3.5.2 Incremental ................................................................................................................. 503.3.5.3 Integração Top-down.................................................................................................. 513.3.5.4 Integração Bottom-up ................................................................................................. 523.3.6 Teste de Regressão ...................................................................................................... 523.3.7 Teste de Estresse .......................................................................................................... 533.3.8 Análise do Valor Limite ou Fronteira ....................................................................... 543.3.9 Tabela de decisão......................................................................................................... 553.3.10 Testes de Semântica .................................................................................................... 563.3.11 Testes Estruturais ........................................................................................................ 563.3.11.1 Técnicas de Testes Estruturais.................................................................................... 573.3.11.1.1 Cobertura de Linha de Código ................................................................................ 583.3.11.1.2 Cobertura de Caminhos ........................................................................................... 583.3.11.1.3 Cobertura de Decisões ............................................................................................ 593.3.11.1.4 Cobertura de Condições .......................................................................................... 593.3.11.1.5 Testes de Ciclos ....................................................................................................... 593.4 CONSIDERAÇÕES FINAIS ........................................................................................... 604 METODOLOGIA UTILIZADA: MPS.BR .................................................................... 624.1 NIVEL G – PARCIALMENTE GERENCIADO ............................................................ 644.1.1 Gerência de Projetos (GPR) ....................................................................................... 654.1.2 Gerência de Requisitos (GRE) ................................................................................... 654.2 NÍVEL F – GERENCIADO ............................................................................................ 664.2.1 Aquisição (AQU) ......................................................................................................... 664.2.2 Gerência de Configuração (GCO) ............................................................................. 674.2.3 Garantia de Qualidade (GQA) ................................................................................... 684.2.4 Medição (MED) ........................................................................................................... 694.3 CONSIDERAÇÕES FINAIS ........................................................................................... 705 DEFINIÇÃO E ELABORAÇÃO DO PROCESSO DE TESTE .................................. 715.1 PROCESSO ..................................................................................................................... 715.2 FASES.............................................................................................................................. 715.2.1 Papéis do Processo ....................................................................................................... 725.2.2 Inicialização ................................................................................................................. 74
    • 5.2.3 Execução ....................................................................................................................... 785.2.4 Finalização ................................................................................................................... 806 DESENVOLVIMENTO DO SISTEMA DE TESTES .................................................. 816.1 VISÃO GERAL ............................................................................................................... 826.1.1 Arquitetura .................................................................................................................. 826.2 MODELO CONCEITUAL .............................................................................................. 846.2.1 Diagrama de Caso de Uso ........................................................................................... 846.2.2 Descrição dos Casos de Uso ........................................................................................ 856.2.2.1 Manter Tipos de Teste ................................................................................................ 866.2.2.2 Manter Prioridade ....................................................................................................... 866.2.2.3 Manter Plano de Teste ................................................................................................ 876.2.2.4 Manter Caso de Teste ................................................................................................. 876.2.2.5 Executar Plano de Teste ............................................................................................. 886.2.2.6 Gerenciar Processos.................................................................................................... 886.2.2.7 Manter usuário e grupo ............................................................................................... 896.2.3 Modelo de Domínio de Classe .................................................................................... 906.3 PROJETO FÍSICO ........................................................................................................... 916.3.1 Diagrama de pacotes ................................................................................................... 916.3.2 Modelo E.R. ................................................................................................................. 996.3.3 Dicionário de Dados .................................................................................................. 1007 VALIDAÇÃO DA FERRAMENTA ............................................................................. 1058 CONCLUSÃO ................................................................................................................. 120REFERÊNCIAS ................................................................................................................... 122
    • 161 INTRODUÇÃO Com a evolução tecnológica de hoje e a velocidade da comunicação imposta pelamodernização, o fator Qualidade está mais elevado na pirâmide estratégica, tornando-sefundamental para assegurar a estabilidade de uma empresa. À medida que o acesso aoconhecimento se torna mais ágil, há também uma preocupação maior com a qualidade de umproduto/serviço oferecido. Comprometimento este que faz com que as empresas busquem porplanos agregando maior qualidade possível em seus projetos, com objetivo de satisfazer asexpectativas do cliente. Tratando de qualidade de software, pode-se dizer que está ligada diretamente aodesenvolvimento. Sendo assim, o foco de qualidade de uma aplicação está necessariamentevinculado à melhoria no processo de desenvolvimento do produto abrangendo conformidadecom padrões, definição de práticas consistentes, garantia de expectativas, Testes, revisõestécnicas, entre outros. Um dos papéis extremamente importantes desempenhados durante o processo dedesenvolvimento ligado à qualidade do software é o processo de Testes de software. Eleexecuta uma análise e verificação, assegurando que o software cumpra com o que foiespecificado durante o período de análise e atenda a necessidade do cliente. Kruchten, em seu livro The rational unified process, mencionado em Bastos eoutros (2007), propõe que existem pelo menos três dimensões de qualidade que precisam serconsideradas 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ópriosdesenvolvedores, com um nível de cobertura bastante reduzido. Muitas vezes, os usuáriosfinais eram envolvidos nestes Testes. Isto gerava uma grande incidência de erros, que eramcorrigidos no momento em que o sistema já estava em produção, ou seja, no momento em queesta correção se tornaria mais cara.
    • 17 Os problemas se tornaram maiores a partir do momento em que surgiram asaplicações para internet e sistemas mais complexos, devido a novas tecnologias. Estes fatoresfizeram com que as organizações começassem a busca pela melhoria na qualidade do softwaredesenvolvido por seus técnicos. Um dos caminhos seria um processo paralelo paraaprimoramento da atividade de Teste. (BASTOS et al., 2007). Foi utilizado nesta monografia o conceito de Testes de Molinari (2008), que tratada gerência, planejamento, controle e execução dos Testes em todos os níveis, de modo agarantir 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 trabalhodesenvolvido.1.1.2 Objetivo Geral Desenvolver, a partir de um estudo sobre processo de Testes, e após uma pesquisasobre 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.
    • 181.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 queelas não oferecem um processo simplificado capaz de auxiliar na implantação do processo deTestes de software, os acadêmicos envolvidos nesta pesquisa optaram por desenvolver umanova ferramenta. Espera-se que a solução consista em um método simplificado para implantação deum processo de Testes, atendendo às áreas de Planejamento de Testes, Execução dos Testes eAná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 derelató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.
    • 19Observa-se hoje que, para garantir a qualidade de um sistema, é necessário lidar com váriosfatores 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 emuma 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 demuitos analistas de softwares, mas que tende a mudar em breve à medida que se depara comaplicativos cada vez maiores, em diversos ambientes e de alta complexibilidade. Um dos principais objetivos na área de Testes é reduzir erros e agregar qualidadeao software. Para isso, é necessário um processo de Testes que se adapte da melhor forma aoprocesso de desenvolvimento e que, além da organização, possa enquadrar os diversos tiposde Testes cabíveis a cada tipo de aplicação. Cabe aqui um software que englobe estesrequisitos e que possa auxiliar de forma precisa uma empresa que planeja melhorar aqualidade do seu software, proporcionando um ganho real em seus produtos. Baseando-se nas ideias acima mencionadas, acredita-se na importância da criaçãodessa 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ósobter a aprovação da proposta entregue ao professor da disciplina Projetos I, é iniciada asegunda etapa, que consiste em montar a primeira parte, o Pré-Projeto. Este acontecerá naseguinte 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; Testesautomatizados e planejamento; c) Estudo sobre as tecnologias que poderão ser aplicadas no desenvolvimento dosoftware 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ãode 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 possacompreender melhor o assunto que será abordado. O capítulo em questão apresenta o problema, o objetivo do trabalho, suaabrangência e o motivo da sua realização. No capítulo capitulo seguinte, será abordado oconceito Qualidade de Software, abrangendo sua definição e importância dentro do processode desenvolvimento de software. O terceiro capítulo enfatiza os Testes, etapa que compõe oitem “qualidade de software” sendo uma das áreas mais importantes para garantia daqualidade de um produto. Aborda ainda tipos de Testes, explicando a importância dos casosde Testes no momento em que é realizado um Teste. O capítulo quatro apresenta a metodologia utilizada como embasamento teóricopara a definição do processo e a definição do processo em si. Serão citadas as etapas doprocesso de gestão de Testes definido, apontando as atividades e papéis que compõem cadaetapa.
    • 21 O quinto capítulo aborda o processo criado, demonstrando todas as etapascontidas, tais como Inicialização, Execução e Finalização. Cada etapa contém todas asatividades a serem executadas. O sexto capítulo apresenta o sistema construído conforme o processoanteriormente criado e mencionado no capítulo anterior, sua arquitetura e modelagem. Apósisso, será demonstrada a validação do sistema, exemplificando cada etapa do sistema por meiode suas telas. Conforme orientação recebida, este trabalho apresentará breves consideraçõesfinais 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 suatotalidade, capítulo no qual serão expostas ideias confirmando (ou não) as hipóteses eobjetivos levantados, bem como as prováveis contribuições deste trabalho na área dedesenvolvimento de software.
    • 222 QUALIDADE DE SOFTWARE De acordo com a NBR ISO 9000:2000 (2000), qualidade é o grau no qual umconjunto de características inerentes satisfaz os requisitos mencionados. Ou seja, pode-sedizer que, quando um produto e/ou serviço cumpre com os requisitos levantados atendendo anecessidade 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 arequisitos funcionais e de desempenho explicitamente declarados, a padrões dedesenvolvimento claramente documentados e a características implícitas que são esperadas detodo software profissionalmente desenvolvido.” (PRESSMAN, 1995, p. 724). Na opinião de Sommerville (2003), atingir um nível de qualidade é o objetivo damaioria das organizações. Não é aceitável entregar produtos de baixa qualidade e que tenhamque ser reparados após a entrega ao cliente. Assim como qualquer outro produtomanufaturado como um Carro, eletrônicos, eletrodomésticos e computadores, o software é umproduto pelo qual o cliente exige um bom funcionamento. Entretanto, tratar de qualidade desoftware não é uma tarefa simples, pois envolve uma série de conceitos complexos e questõesque devem ser avaliadas. Durante o desenvolvimento de um software, é comum encontrarobstá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 ocliente deseja. Contudo, a organização de desenvolvimento pede também requisitos (como osrequisitos 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, afacilidade 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 softwaree os gerentes de cada área do desenvolvimento trabalham de forma a encontrar melhoresmétodos para aplicar às especificações, buscando atender a todos.Figura 1 - Pessoas envolvidas dentro da qualidadeFonte: Falbo, 2008. O Gerente de Qualidade exerce seu papel apoiando todos os envolvidos no projetoe encorajando-os em sua atividade.2.1 GERENCIAMENTO DE QUALIDADE Como foi dito anteriormente, é de responsabilidade dos gerentes a garantia donível de qualidade do seu produto. Eles visam criar uma Cultura de Qualidade, aplicandouma série de padrões e procedimentos que deverão ser utilizados durante a execução de umprojeto. Conforme Sommerville (2003), o gerenciamento de qualidade parte de três atividadesprincipais:a) Garantia de Qualidade: O estabelecimento de uma estrutura de procedimentos e padrõesorganizacionais.a) Planejamento de qualidade: A seleção de procedimentos e de padrões organizacionais.
    • 24b) 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 qualidadefornece uma verificação independente sobre o processo. Os projetos finalizados ou produtosjá entregues são posteriormente avaliados por uma equipe de qualidade que deve serindependente do gerenciamento do projeto, pois desta forma se terá uma visão objetiva doprocesso, podendo reportar problemas e dificuldades com mais facilidade à gerência sênior. Ailustraçã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 executoraque determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que oprojeto atenda às necessidades que motivaram sua realização. É implementado o sistema degerenciamento da qualidade através da política, dos procedimentos e dos processos deplanejamento da qualidade, garantia da qualidade e controle da mesma, com atividadesde 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 noquadro abaixo.
    • 25Quadro 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 dequalidade exigem uma estrutura de padrões que devem ser aplicados durante todo o processode desenvolvimento. Os dois padrões principais que podem ser definidos são: Padrões deProduto 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 doprocesso a ser seguido durante o desenvolvimento e validação, incluindo definições deespecificação e uma série de documentos que devem ser gerados durante o fluxo.(SOMMERVILLE, 2003). O quadro abaixo ilustra esta situação.
    • 26Quadro 2 - Padrões de produto e de processoFonte: Sommerville, 2003. A definição de padrões deve ser analisada para que não ocorram problemasrelacionados a padrões não apropriados. É importante decidir quais os padrões que devem serutilizados 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 agerê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çãode 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ávelpelo insucesso no produto final. Nessa situação, é necessária a medição dos atributos desoftware, 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.
    • 27Fluxograma 1 - Fluxo do gerenciamento da qualidade do processoFonte: Sommerville, 2003.2.1.3 O planejamento de Qualidade Planejamento de Qualidade: “Identificação dos padrões de qualidade relevantespara 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 umplanejamento dos objetivos claramente descritos e de fácil compreensão a toda equipeenvolvida 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 osrequisitos sejam cumpridos. Esta tarefa não é simples. Segundo o National Institute ofStandards and Technology (NIST), aludido por Sommerville (2003), 80% dos custos dedesenvolvimento 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, bemcomo exige menos retrabalho e recursos adicionais. A elaboração de um Plano de Qualidade é uma atividade gerencial apoiada pelaadministração fiel a um conjunto de atividades que compõem o projeto. Ela estabelecemétricas visando custos, prazos e funcionalidades do projeto e a satisfação do cliente com oproduto. Humprey, referenciado por Sommerville (2003), em seu livro sobregerenciamento de software, sugere uma estrutura geral para um plano de qualidade, queinclui:
    • 281. 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 quedevem 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, umaparte importante do planejamento de qualidade é selecionar os principais atributos dequalidade e planejar como eles devem ser obtidos. (SOMMERVILLE, 2003). A figura aseguir representa os atributos da qualidade de software.Figura 2 - Atributos de Qualidade do softwareFonte: Desenvolvido pelo autor, 2010.
    • 292.1.4 Padrões de documentação Um documento é a única maneira tangível de representar o software a serdesenvolvido o processo. desta forma é extremamente importante a definição de um padrão dedocumentos de fácil entendimento e objetivo. Na padronização da documentação, deve-seconsiderar o processo de documentação (definindo o processo a ser seguido nadocumentação); padrões de documentos (os quais regem a estrutura e a apresentação dosdocumentos) 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, é interessanteque 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 dedocumentos. Esta prática possibilita a transferência de documentos eletronicamente recriadosem forma original. Podem também limitar as fontes e estilos de texto utilizados (devido adiferentes recursos, impressoras e displays) e definir convenções do uso de ferramentas.(SOMMERVILLE, 2003).Esquema 1 - Padrões de intercâmbio de documentosFonte: Sommerville, 2003.
    • 302.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 demedição orientado a metas. A medição visa obter valores numéricos para atributos de um produto e/ouprocesso e compara com outros produtos/processos, buscando tirar conclusões sobre aqualidade do processo, avaliando se os objetivos pré-definidos estão próximos de seremalcançados. Já as métricas são as medições referentes ao processo ou produto. São geralmentemedidas características como a rastreabilidade, volatilidade, esforço, abrangência, qualidade etamanho. Segundo o WThreeX (2010), para se atingir a medição e métricas de qualidade emum 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, estadependerá das características e do contexto do projeto. Se ele for grande ou tiver requisitosrigorosos de confiabilidade ou segurança e as equipes de desenvolvimento e avaliação tiveremum ó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 podeestar tentando aperfeiçoar habilidades e processos em áreas específicas. Não há uma respostasimples que se adapte a todas as circunstâncias. O gerente de projeto deve selecionar o que é
    • 31apropriado quando o plano de métricas for produzido. No entanto, quando se apresenta umplano de métricas pela primeira vez, convém manter a simplicidade, em vez de se arriscar ecometer 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 osprocessos e etapas. Ela faz com que os procedimentos e padrões sejam seguidos; identifica egarante 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 nasmé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 pormeio de Testes de software, como Testes caixa preta, caixa branca, Testes funcionais, Testesde 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 emodelos conceituados como CMMI e MPS.BR. Entretanto, a implantação de um destesmodelos não é tarefa simples, pois deve passar pela política de cada organização, desviandosua cultura e crenças. A análise de riscos é uma necessidade encontrada hoje nessas empresas,
    • 32servindo de orientação na fase de adaptação de um processo. Na análise de riscos, sãoconsiderados fatores como a não utilização de boas práticas de desenvolvimento,considerando que a qualidade do software está diretamente associada à qualidade dosprocessos utilizados em sua produção e ao conhecimento técnico que os usuários do processotê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 doprocesso, 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 quedeverão ser verificados. Isto para que facilite a identificação do controle e questionários queserã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 semanifestar 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ãoesteja implementado na organização;Severidade: indica o grau do impacto negativo na organização, caso uma ou mais ameaças semanifestem;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çãoou garantir que as ações associadas a eles sejam gerenciadas adequadamente e não sejam esquecidas.
    • 33Esquema 2 - Análise de RiscosFonte: Espinha, 2007. Por fim, tem-se uma série de informações concatenadas que fornecem apoio aogestor do projeto. As ilustrações abaixo apresentam informações que foram extraídas atravésdo processo de análise de riscos.
    • 34Tabela 1 - Resultados da avaliação em abrangência por área de processo.Fonte: Espinha, 2007.Gráfico 1 - Resultados da avaliação em abrangência - ameaçasFonte: Espinha, 2007.
    • 352.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. Aqualidade está presente durante toda engenharia do software: processo de desenvolvimentoque é 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 naavaliação da qualidade.
    • 363 TESTES O presente capítulo aborda os conceitos de testes de software, bem como os tipos detestes existentes. Além disso, mostra as dificuldades surgidas no processo de desenvolvimentoe 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 eleatingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado. Oseu objetivo é revelar falhas em um produto, para que as causas dessas falhas sejamidentificadas 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 deseus 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 umaetapa do processo do desenvolvimento e, em geral, executado pelos próprios desenvolvedorese pelos usuários do sistema – serve apenas para garantir que as especificações ou os requisitosdo negócio foram implementados. Como o processo de desenvolvimento cria produtos comdefeito, se faz necessário descobrir estes defeitos. Em um modelo de garantia de qualidadeisso é insuficiente. Quem poderia garantir que um software testado pelos própriosdesenvolvedores está corretamente testado? Com certeza, existem exceções, mas a melhorforma 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 desoftware, e ações que vão desde o levantamento de requisitos até a execução do Testepropriamente dito. (MOLINARI, 2008). A imagem mostrada abaixo ajuda a localizar oprocesso de Testes dentro da Engenharia de Software.
    • 37Figura 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ênciado projeto. Quando se passa a enxergar mais fundo, percebemos que há nela uma área dequalidade. Sabemos que “ir ao encontro das necessidades dos clientes” é a chave para agarantia de um produto. Porém, isso só é possível mediante técnicas adequadas para garantir ofuncionamento do software. (MOLINARI, 2008). O autor prossegue, afirmando que os Testes mostram uma visão das falhas naqualidade externa, aquela que é visualizada, tal qual um sintoma de uma doença. As raízesdessas doenças estão na garantia interna, no controle por meio de diversos atributos, taiscomo: estrutura adequada de programação, usabilidade, padrões de codificação, etc. Myers (1979), referenciado em BASTOS et al., (2007) criou conceitos sobreTestes de Software – uma publicação que na época tornou-se uma das bíblias da qualidade desoftware. 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 dessamonografia, com base nas ideias de Myers.
    • 38Gráfico 2 - Custo de correçõesFonte: Elaboração dos autores, 2010. O gráfico 2 transmite a ideia de que, para garantir maior qualidade em umproduto, é importante levantar a necessidade de cada fase do desenvolvimento para seremidentificados 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 umafalha logo no seu surgimento.3.1.1 Conceitos de Testes Segundo Dias Neto (2007), Teste é uma ação que pode ser realizada em diferentesestá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 algunsdos principais itens relacionados a esta atividade, tais como defeitos, erros e falhas. Adiferença entre estes três conceitos seguem abaixo. Elas estão definidas na terminologiapadrã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 umadeterminada 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árioincorreto ou resultado inesperado na execução de um programa constitui um erro. Falha é o comportamento operacional do software diferente do esperado pelousuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem nuncacausar uma falha. A ilustração abaixo expressa a diferença entre esses conceitos. Defeitos fazemparte do universo físico (a aplicação propriamente dita) e são causados por pessoas, porexemplo, através do mal uso de uma tecnologia. Defeitos podem ocasionar a manifestação deerros em um produto, ou seja, a construção de um software de forma diferente ao que foiespecificado (universo de informação). Por fim, os erros geram falhas, que sãocomportamentos inesperados em um software que afetam diretamente o usuário final daaplicação (universo do usuário) e pode inviabilizar a utilização de um software. (DIASNETO, 2007).Figura 4 - Defeito x Erro x FalhaFonte: Neto, 2007. Ao longo de um processo de testes, são abordados elementos que seguem desde afase inicial até a entrega de um software, necessários para que se possa conhecer mais a fundoa área de testes. Os elementos que seguem abaixo foram descritos com base no livro “TestesFuncionais 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 asempresas 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 aatividade de Teste fundamental durante o desenvolvimento de um software. Já foi observadoque esta atividade corresponde ao último recurso para a avaliação do produto antes da suaentrega ao usuário final. O tamanho do projeto a ser desenvolvido e a quantidade de pessoasenvolvidas 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 defalhas é inevitável. Mas o que significa dizer que um programa falhou? Basicamente significa
    • 42que o funcionamento do programa não está de acordo com o esperado pelo usuário. Porexemplo, quando um usuário da linha de produção efetua consultas no sistema das quais só agerência deveria ter acesso. De acordo com Dias Neto (2007), esse tipo de falha pode seroriginado 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 entrediferentes fases do ciclo de desenvolvimento de um software. O exemplo abaixo citado porDias 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.
    • 433.1.3 Gerenciamento de Testes Molinari (2008) declara que a gestão da qualidade representa um dos pilares daQualidade de Software. Os outros pilares tratam dos elementos gestão de configuração, gestãode requisitos e Testes. Gestão de Configuração: trata de gerência, controle e registro dos artefatos quecompõ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 dosistema (requisitos) e dos usuários em todos os níveis, incluindo aí a rastreabilidade dasnecessidades e da sua mudança; Testes: trata de gerência, planejamento, controle e execução dos Testes em todosos níveis, de modo a garantir a implementação (projeto, desenvolvimento e entrega) dasnecessidades especificadas. Como dito anteriormente, quanto antes os testes iniciarem, mais barato será acorreção dos defeitos encontrados. O gerente de testes deve trabalhar neste sentido, definindoe acompanhando o processo para garantir a qualidade do sistema em desenvolvimento. Demodo geral, o processo de teste é representado por ciclos, que são as etapas a serem seguidasem todo o processo. Para Bastos et al. (2007), o ciclo de testes é representado pelas seguintesetapas:  Planejamento  Preparação  Especificação  Execução  Entrega3.2 REQUISITOS E CASOS DE TESTES Nesta seção serão abordados os requisitos e os casos de testes utilizados noprocesso.
    • 443.2.1 Definindo os requisitos Para elaborar os casos de testes é necessário primeiramente levantar os requisitosde 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 desejatestar 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 detalhadofor o requisito, mais próximo do caso de testes ele vai ficar. Segundo Molinari (2008), osrequisitos devem possuir algumas características para que este seja bem elaborado, podemosdestacar 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. Deveconter um número de identificação único, descrição detalhada, seu status (posição atual nociclo de vida de um requisito. Ex.: criado, atualizado, finalizado, implementado, etc.) e suasdependê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 deentrada, restrições para a sua execução e um resultado ou comportamento esperado (CRAIG eJASKIEL, 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, chamadosde Cenário de Teste. Isso não significa que cada cenário deverá ser totalmente preenchido em
    • 45amplitude e profundidade, mas devem ser vistos, pois sua importância pode variar entre oscená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çãoao 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, certificandoassim a integridade da informação. Para executar essa validação, pode-se criar um caso deteste para essa função, ou mesmo acrescentar como um passo dentro dos casos de testesrespectivos. Assim como os requisitos, os casos de testes também possuem algumascaracterí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, umpasso-a-passo de como executar o teste, suas pré-condições para iniciar o teste, caso sejanecessário, e o resultado esperado, como o exemplo que pode ser visualizado no quadroabaixo.
    • 46Quadro 3 - Exemplo de um Caso de Teste simples.Fonte: Pontes, 2009. Entretanto, nada impede que sejam adicionadas mais informações ao caso deteste, como: ambiente, dados de entrada, cronograma, dependências com outros casos detestes, entre outras.3.3 TIPOS DE TESTES O planejamento do Teste deve prever os tipos e as técnicas que serão utilizadas aorealizar um determinado Teste. Existem dois tipos básicos de Testes considerados os maisgenéricos: Testes Funcionais e Testes Estruturais. Nenhum destes é completo. Eles secompletam e devem ser aplicados em conjunto. Para cada um destes tipos podemos realizarinú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 comoté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 testarcomparando-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 certagranularidade a um Teste funcional. Podemos testar um componente de um sistema ourealizar verificações em um arquivo de banco. Abaixo, segue a representação do teste caixa-preta.Figura 6 - Componentes existentes em Testes caixa preta.Fonte: Elaboração dos autores, 2009.
    • 48 Como no teste estrutural, há diversas técnicas existentes que ajudam a executarum bom teste funcional. Durante a execução de um checklist ou simplesmente o ato dehomologar uma tarefa, está se realizando técnicas de testes funcionais. Falta apenas o hábitode estar enfatizando estas atividades para melhorar o processo. Algumas técnicas existentes são Teste de Valor Limite ou Fronteiras (BoundaryValue Testing), Teste de Particionamento Equivalente (Equivalente Class Testing), Teste deRegressão, entre outros. Abaixo serão apresentados detalhes de algumas técnicas utilizadasnos Testes Funcionais. (MOLINARI, 2008).3.3.2 Testes de Unidade Este tipo de Teste, também conhecido como Testes unitários, tem por objetivoexplorar a menor unidade do projeto, procurando provocar falhas ocasionadas por defeitos delógica e de implementação em cada módulo, separadamente. O universo alvo desse tipo deTeste são os métodos dos objetos ou mesmo pequenos trechos de código. (ROCHA, 2001apud DIAS NETO, 2007).3.3.3 Testes de Sistema Avalia o software em busca de falhas por meio da utilização do mesmo, como sefosse um usuário final. Dessa maneira, os Testes são executados nos mesmos ambientes, comas 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).
    • 493.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 deintegração pode ser considerado como uma extensão lógica dos Testes unitários. Na suaforma mais simples, duas unidades que foram testadas são combinadas em um componente etestadas. Um componente neste caso, refere-se a um conjunto integrado de mais de umaunidade. O objetivo desta técnica é montar estruturas de testes para descobrir errosrelacionados à 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 edepois integrados de uma só vez. Os conjuntos de erros são difíceis de serem detectados, logodifíceis de serem corrigidos, pois devido ao tamanho e complexidade do programa, é difícilisolar as causas de tais erros. Testes não-incrementais são normalmente usados devido àspressões do dia a dia e os Testes são aplicados para demonstrar uma operabilidade mínima dosistema. (CAMPOS, 2009).
    • 50Esquema 3 - Representação dos módulos de TesteFonte: Campos, 2009.3.3.5.2 Incremental Um software é construído e testado em pequenos segmentos, tornando a correçãode erros mais fácil. A probabilidade de testar completamente a interface do sistema tambémaumenta.
    • 51 A figura abaixo representa componentes que foram estruturados de formaincremental:Esquema 4 - Testes de integração.Fonte: Elaboração dos autores, 2010. De acordo com Campos (2009), os pontos relevantes desta técnica são:  O Tester não precisa esperar até que todo o sistema esteja pronto, para iniciar os Testes;  Há um menor risco de fracasso geral do projeto, já que cada módulo é verificado antes e caso algo esteja errado a correção será implementada já no próximo ciclo de Teste;  A integração dos módulos só é realizada, após eles já terem sido verificados, ou seja, se algum erro acontecer, a causa provavelmente será a comunicação entre esses módulos.3.3.5.3 Integração Top-down É uma abordagem incremental. Como o nome já diz, a integração dos módulosacontece de cima para baixo, o que facilita a verificação antecipada dos pontos de decisão econtrole no processo de Teste. (CAMPOS, 2009).
    • 523.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 baixodo software, ou seja, o módulo. O módulo é dito como o mais baixo nível se ele não dependede outro módulo. A Bottom-Up assume que todos os módulos foram individualmente testadosantes. (CAMPOS, 2009).3.3.6 Teste de Regressão Esta técnica de Teste trabalha de modo a testar segmentos já testados após aimplementação de uma mudança na aplicação. Ela tem por objetivo determinar se adocumentação do sistema permanece atual; verificar se os dados e as condições de Testepermanecem atuais; determinar se as funções previamente testadas continuam funcionandocorretamente após a introdução de mudanças no sistema. Costa (2009) menciona que os Testes de regressão tratam de executar Testes daversão anterior, na nova versão de um aplicativo, de modo a se certificar que o que está naaplicação continue certo. Um Teste de regressão deve ser executado sempre que o sistema sofre algumaalteração. Significa aplicar todos os Testes realizados anteriormente para garantir que osresultados 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 arepetição das operações, o que muitas vezes contribui para que eles não sejam realizados deforma 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.
    • 533.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 softwarepode ser exigido e até quais as falhas (caso existam) decorrentes dele, levando emconsideração as restrições. Tais como a memória, número de transações e capacidade daaplicação. Para Lourenço (2010), este tipo de Teste é indispensável quando se trata de Testesem 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 plataformapara executá-lo. Caso se queira saber a quantidade mínima de memória disponível para que osistema 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 reduzirartificialmente 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 testarum programa simulando um número arbitrário de conexões. (LOURENÇO, 2010).
    • 543.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 valoresfronteiriços. São utilizadas extremidades da classe, tendo como variáveis a faixa de valores otamanho da estrutura, valores específicos, entre outros extraídos. Ao aplicar um caso de Testeutilizando esta técnica, é importante gerar entradas ou saídas que coincidem com ambos oslados de cada fronteira, incluindo o valor da própria fronteira. Segundo Freitas (2009) para seelaborar 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 Testesunitários, de integração ou Teste de aceitação de usuários.
    • 553.3.9 Tabela de decisão A técnica de decisão pode ser aplicada a todas as situações quando a execução dosoftware depende de muitas decisões lógicas. Ela baseia-se em uma combinação de situaçõesque devem ocorrer para que uma determinada ação seja tomada, expressa por um determinadoprocessamento ou por um cálculo. A tabela de decisão contém condições que disparam asações, muitas vezes combinações verdadeiras e falsas para todas as condições de entrada, eaçõ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 únicacombinaçã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ínimoum Teste por coluna cobrindo todas as combinações de condições apresentadas. (FREITAS,2009). A seguir, é mostrado um exemplo de tabela de decisão.Tabela 3 - Exemplo de uma tabela de decisão. .Fonte: FREITAS, 2009. No exemplo imaginário acima (Freitas, 2009) a decisão de se aceitar o seguro serábaseado no número de acidentes combinado com o sexo do motorista. Esta supostacompanhia de seguros entende que as pessoas do sexo feminino dirigem com mais cuidado,como podemos ver na tabela de decisão acima.
    • 563.3.10 Testes de Semântica Segundo Freitas (2009), estes Testes devem ser usados para avaliar telas ourelató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çãode 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 setrata 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 objetivoavaliar o comportamento interno do sistema, simulando situações que exercitem todas asestruturas utilizadas na codificação. Permite um Teste mais preciso em relação aos pontoscríticos do código-fonte. Freitas (2009), afirma que os Testes estruturais devem considerar osseguintes 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.
    • 57Figura 7 - Componentes existentes em Testes caixa branca.Fonte: Elaboração dos autores, 2009. Testes estruturais são considerados mais complexos e muito diferentes do Testede caixa-preta. Ao aplicá-lo, deve-se avaliar a complexibilidade do software e a tecnologianele empregada. Para a utilização deste tipo de Teste é necessário que se tenha um controlador deTeste que dispare as rotinas na unidade de software, avalie os resultados gerados e comparecom o esperado. Os controladores produzem um log de execução, identificando quais casosde 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 unidadenão apresente falha na sua estrutura interna. (FREITAS, 2009). Alguns exemplos de ferramentas já existentes:  Selenium IDE  JUnit  DBUnit  FitNesse3.3.11.1 Técnicas de Testes Estruturais São as seguintes:
    • 583.3.11.1.1 Cobertura de Linha de Código A cobertura de linha de código é considerada um método tradicional deste tipo deTeste. 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 Testesforam 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 nascondições lógicas aplicadas no código-fonte. Os casos de Testes são elaborados de forma apermitir variação dos valores que determinam a execução dos diversos fluxos alternativosexistentes no código-fonte. O desenho interno do software é o principal elemento para amodelagem dos casos de Testes. Pode-se aplicar três níveis diferentes de refinamentos paracobrir o maior número de condições possíveis.Figura 8 - Níveis de refinamento.Fonte: FREITAS, 2009.
    • 593.3.11.1.3 Cobertura de Decisões Esse método de cobertura avalia se todas as decisões existentes no código-fontesã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 queassumirão os valores verdadeiros ou falsos. Isso garante que toda decisão de processamentoexistente 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 emconsideração apenas os comandos que executam desvios de processamento, esse modelo decobertura 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 casosde 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çãopossíveis:  CTI = [i=17, s = „M‟];  CT2 = [i=18; s=„F‟];  CT3= [i=19; s=„F‟]3.3.11.1.5 Testes de Ciclos
    • 60 Os ciclos concentram-se exclusivamente na validade das construções de laços.São quatro os tipos de laços.Figura 9 - Laços existentes nos Testes de ciclo.Fonte: Elaboração dos autores, 2009.3.4 CONSIDERAÇÕES FINAIS O Teste tem por objetivo principal encontrar o maior número possível de defeitosno software. Estes defeitos documentados e planejados proporcionam, ao final, indicadoresmensurá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, sendocomposto por etapas que realizam o processo. Para auxiliar na execução, existem diversastécnicas que proporcionam ao profissional de teste realizar o seu trabalho com maiorqualidade e eficácia.
    • 61 É importante ressaltar que, para que se tenha um ganho significativo, o teste deveser executado em paralelo ao processo de desenvolvimento.
    • 624 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 pelaAssociação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando comapoio 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 deCredenciamento e Controle (FCC) e segunda é a Equipe Técnica do Modelo (ETM). O FCCtem como objetivo assegurar que as Instituições Implementadoras (II) e InstituiçõesAvaliadoras (IA) sejam submetidas ao processo de credenciamento e que suas atuações não seafastem dos limites éticos e de qualidade esperados. Já o ETM atua sobre os aspectos técnicosrelacionados 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 deavaliação de processo de software, visando atender às necessidades de negócio. O foco sãoempresas de pequeno e médio porte, porém, como é um modelo adaptável, nada impede deutilizá-lo em empresas de grande porte, independente da área - privada ou pública. (BRAUNSet al., 2008). Para construir o MPS.BR, utilizou-se como base técnica normas da NBR ISO-IEC12207 e 15504 e no modelo Internacional CMMI-SE/SW. Este modelo está subdividido emtrês componentes: Modelo de Referência (MR-MPS), Modelo de Avaliação (MA-MPS) eModelo 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.
    • 63Esquema 5 - Componentes do modelo MPS.Fonte: SOFTEX, 2007. Este modelo prevê o amadurecimento gradual dos processos envolvidos nodesenvolvimento de software através de níveis de maturidade que ele implementa. SegundoSodré (2010) os níveis de maturidade estabelecem uma forma de prever o desempenho futurode uma organização com relação a uma ou mais disciplinas. Um nível de maturidade é umpatamar definido de evolução de processo. A divisão do modelo em níveis facilita sua implantação, pois não é necessárioimplementar 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 errosencontrados. É necessário compreender a definição que o MPS.BR tem sobre maturidade, quesegundo Diniz (2009) “Um processo é maduro quando ele atinge os melhores resultados como menor custo”. Então para saber se um processo é maduro ou não, é necessário medir. OMPS.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 oCMMISE/SWSM aplica, porém o MPS.BR possui mais níveis e em graduações diferentes
    • 64para possibilitar uma implementação e validação mais gradual e adequada à pequenas emédias empresas. (BRAUNS et al., 2008). Para melhor entender sobre o modelo de maturidade MPS.BR é necessário umpouco mais de conhecimento sobre os processos envolvidos em cada nível, conforme mostra atabela 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) Gerência de Riscos Nível C Desenvolvimento para Reutilização – DRU Gerência de Decisões – GDE Verificação – VER Validação – VAL Nível D Projeto e Construção do Produto – PCP Integração do Produto – ITP Desenvolvimento de Requisitos – DRE Gerência de Projetos – GPR (evolução) Gerência de Reutilização – GRU Nível E Gerência de Recursos Humanos – GRH Definição do Processo Organizacional – DFP Avaliação e Melhoria do Processo Organizacional – AMP Medição – MED Garantia da Qualidade – GQA Nível F Gerência de Portfólio de Projetos – GPP Gerência de Configuração – GCO Aquisição – AQU Gerência de Requisitos – GRE Nível G Gerência de Projetos – GPRFonte: SOFTEX, 2007.4.1 NIVEL G – PARCIALMENTE GERENCIADO O nível G de maturidade é o nível mais baixo do modelo MPS.BR, sendo elecomposto pelos processo de Gerência de Projetos e Gerência de Requisitos. (SOFTEX, 2009).
    • 654.1.1 Gerência de Projetos (GPR) De acordo com a SOFTEX (2009), a gerência de projetos tem como propósitoestabelecer e manter planos que definem as atividades, recursos e responsabilidades doprojeto. Também é de sua responsabilidade fornecer informações sobre o andamento doprojeto que permitam corrigir desvios. À medida que a organização evolui em maturidade esteprocesso também evolui. A gerência de projetos envolve atividades como: desenvolver um plano geral decontrole do projeto; obter o comprometimento e mantê-lo ao longo de toda a execução doprojeto; e conhecer o progresso do projeto, de maneira que ações corretivas possam sertomadas quando a execução do projeto desviar do planejado. (SOFTEX, 2007). É interessante conhecer o conceito de projeto para obter uma melhor compreensãosobre gerência de projetos. Segundo a fonte acima, projeto é um empreendimento realizadopara 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. Ofim do projeto é atingido quando os objetivos do projeto tiverem sido alcançados, ou quandose tornar claro que os objetivos não serão ou não poderão ser alcançados, ou ainda quando oprojeto 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ósitogerenciar os requisitos de produtos e componentes do projeto e identificar inconsistênciasentre os requisitos e planos de projetos. É de obrigação da gerência de requisitos controlar todos aqueles necessáriosdentro do projeto, tanto os funcionais quanto os não-funcionais, bem como os requisitosimpostos ao projeto pela organização. Também é de sua responsabilidade documentar asmudanças nos requisitos e manter a rastreabilidade bidirecional entre eles e os produtos detrabalho 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 emDorfman e Thayer (1990), definindo requisito como sendo a representação da capacidade quedeve ser encontrada ou possuída por um determinado produto ou componente de produto parasatisfazer a um contrato, a um padrão, a uma especificação ou a outros documentosformalmente impostos. Os requisitos indicam a capacidade do software requerida pelo usuáriopara 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 agregarprocessos 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 aprofundadasobre 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 deaquisição tem como propósito gerenciar a aquisição de produtos que satisfaçam àsnecessidades expressas do adquirente, sendo que no contexto o termo produto pode incluirtambé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 degarantir 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), é deestabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projetoe 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 queconstituem 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 deconfiguração como um item único. (IEE, 1990, apud SOFTEX, 2009). Em determinados momentos do ciclo de vida de desenvolvimento e manutençãodo software, esses itens de configuração são agrupados e verificados, constituindoconfigurações do software voltadas para propósitos específicos, denominadas baselines. Destaforma, com a utilização dos controles existentes dentro do processo de gerência deconfiguração, é possível manter a integridade dos produtos de trabalho. Por fim, essesprodutos de trabalho são submetidos a um processo de liberação denominado release queconsiste 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êssistemas 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 comos planos e recursos pré-definidos. As atividades realizadas nesse processo fornecemvisibilidade 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 agerência quanto a construção dos produtos de trabalho. É necessário fazer um bom planejamento da Garantia de Qualidade paraestabelecer padrões, procedimentos e processos aplicáveis ao projeto, bem como os artefatos efases que ela atuará. Este nível está presente em todos os níveis de maturidade enquadradosdentro do modelo MPS.BR, pois ele não trabalha apenas em cima do produto, mas tambémem 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 osseguintes 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ésdeste 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 relataros dados relativos aos produtos desenvolvidos e aos processos implementados, tendo comoprincipal objetivo apoiar na tomada de decisão em relação aos projetos. Ele ocorre tanto nosprojetos quanto nos processos que são executados. As medições devem ser organizadas, sendoque elas podem ser armazenadas em um repositório de medições do projeto, não necessitandoainda 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ãodifíceis de serem realizadas, porque não se consegue quantificar as coisas corretamente, osdados são difíceis de coletar, isso acontece como consequência de processos imaturos.(SOFTEX, 2009). São atribuições da medição:  O objetivo de realizar a medição é definido e mantido a partir dos objetivos de negócio da organização e as necessidades de informação de processos técnicos e gerenciais;  É definido um conjunto de medidas, tendo como objetivo a necessidade de medição, ou seja, a partir dos objetivos de medição (ou o que precisa ser medido) deve-se então encontrar as medidas que possam satisfazê-lo;
    • 70  São definidos os procedimentos que devem ser executados para coletar as medidas. Também é definida e especificada a forma de armazenamento das mesmas;  São definidos os procedimentos que devem ser executados para a análise das medidas;  Define-se a coleta de dados necessários para realizar a análise;  São armazenados os dados recolhidos e as análises realizadas, para recuperá-los pelos interessados e para uso futuro.4.3 CONSIDERAÇÕES FINAIS No intuito de motivar as empresas de desenvolvimento de software a colocaremseus processos e produtos à prova da eficácia e eficiência para garantir sua qualidade,tornando assim o software brasileiro competitivo nacionalmente e internacionalmente, surgeestão o modelo MPS.BR, compatível com as principais abordagens internacionais paradefinição, avaliação e melhoria de processo de software, baseando-se em conceito dematuridade. Como hoje no Brasil a maioria das empresas desenvolvedoras de software são demicro, pequeno e médio porte, este seria então o principal foco deste modelo, empresas estasque possuem poucos recursos e necessitam melhorar seu processo de software. A idéia doMPS.BR é que o modelo seja adaptável ao perfil da empresa de diferentes portes, ou seja, elepode ser implementado em empresas de grande porte. O MPS.BR engloba todos os processo existentes dentro de uma empresa desoftware. Porém, como o foco do projeto em questão não é gerenciar o processo dedesenvolvimento como um todo, e sim a gestão de Teste e qualidade, este capítulo apresentouconsiderações a respeitos apenas dos níveis G e F, privilegiando o nível F (Gerenciado) porser o foco principal do projeto que será desenvolvido.
    • 715 DEFINIÇÃO E ELABORAÇÃO DO PROCESSO DE TESTE5.1 PROCESSO Com o objetivo de facilitar a implantação de testes de software, foi definido ummodelo especificando todas as fases e atividades necessárias para que esta implantação sejarealizada 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 dequalidade e medição.5.2 FASES O processo definido contém Etapas; Entradas e Saídas; Papéis e Produtos. Estesitens são compostos pelas seguintes fases de execução do processo, sendo que cada etapa temseus 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.
    • 725.2.1 Papéis do Processo O processo definido é composto por três papéis que participam ativamente noprocesso, tais como Gerente de Testes, Analista de Testes e Tester, tendo também apossibilidade de inserir o papel do gerente de qualidade no processo, porém este não participaativamente como os demais. Cada novo projeto de Teste criado serão descritas as pessoasresponsá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 deTeste, bem como liderar um projeto de Teste novo ou em andamento. Ele irá elaborar odocumento do Projeto de Teste – Plano de Teste – e irá conduzir o projeto tomando asprovidências necessárias para que seja executado de maneira adequada, ou seja, conforme ositens pré-definidos no Plano de Teste; Analista de Testes: este papel consiste em modelar a elaboração dos casos deTestes 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 osartefatos 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:
    • 73Diagrama 1 - Visão geral do Processo de Teste.Fonte: Elaboração dos autores, 2009.
    • 745.2.2 InicializaçãoDiagrama 2 - Visão detalhada do processo de inicializaçãoFonte: Elaboração dos autores, 2009.  Objetivos: Elaboração de um Planejamento de Teste.  Descrição: Nesta etapa, deve-se realizar o levantamento de Requisitos, que são documentos referentes a regra de negócio e documentação do desenvolvimento. Com base nesta documentação será desenvolvido o Plano de Testes, que é um documento básico para a gerência do projeto de Teste e a base para a sua monitoração e controle. Tendo definido este documento, serão desenvolvidos os Casos de Teste.  Fases: a) Elaborar documento de Requisitos; b) Elaborar casos de testes; c) Elaborar Plano de Testes.
    • 75 a) Elaborar documento de Requisitos: A elaboração de um Documento de Requisitos tem por objetivo coletar as informações necessárias para que o software seja validado e entregue ao cliente conforme a sua real necessidade, dentro do prazo e orçamento adequado. Tem-se aqui a base do negócio, portanto é necessário que seja elaborada uma especificação de requisitos bem definida de forma clara e objetiva, para que possa ser entendida por todos os stakeholders3. A lista abaixo apresenta as atividades que deverão ser executadas para que estafase 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 TesteFonte: Elaboração dos autores, 2010.c) Elaborar o Plano de Teste: nesta atividade é elaborado o principal documento do Projeto de Teste: o Plano de Teste, documento no qual o Gerente de Teste irá mapear todo o Projeto de Teste em questão, identificando variáveis como: o objetivo do Teste; os documentos de requisitos entregues; os casos de Testes que deverão ser executados; as pessoas envolvidas; os prazos e as informações históricas do projeto. As atividades que contemplam esta fase são:  Identificar todos os casos de Testes envolvidos no projeto;  Especificar as modificações estruturais na organização do ambiente;  Estabelecer um cronograma-detalhado, baseado no cronograma-macro já elaborado;  Identificar os responsáveis pelo projeto (Testers e Analistas de Testes);  Identificar os riscos do Projeto;  Comunicar a finalização do Projeto.
    • 77 O responsável por este papel é o Analista de Testes. Abaixo é apresentado o plano de teste.Quadro 5 - Plano de TesteFonte: Elaboração dos autores, 2010.
    • 785.2.3 ExecuçãoDiagrama 6 - Visão detalhada do processo de Execução.Fonte: Elaboração dos autores, 2010.  Objetivos: realizar a execução dos Testes.  Descrição: nesta etapa serão executados os Testes previstos no Plano de Teste. Tem-se o relatório de Log de Teste e de Incidente, que auxiliam no andamento dos Testes. O Tester responsável irá executar cada caso de Teste previsto no cronograma conforme o seu respectivo prazo estipulado. A cada Teste executado, cujo resultado seja negativo, é gerado um relatório de incidente, o qual será reportado à equipe de desenvolvimento. O acompanhamento dos Testes executados pode ser feito por meio do relatório de Log de Teste.
    • 79 Fase: Executar Casos de Testes. Com base nas especificações persistentes nos documentos de Plano e Teste e Caso de Teste, o Tester vai executar os Testes, verificando se as entradas e saídas correspondem aos resultados esperados, especificados nos documentos. As atividades que contemplam esta fase são:  Execução dos casos de Testes;  Comunicar o Gerente de Teste e o Gerente Projeto eventuais modificações em relação à duração e prazo de execução do Teste e dificuldades encontradas;  Comunicar os envolvidos no Projeto de Teste o fim de cada ciclo, apresentando o relatório de Log de Teste;  Realizar uma reunião de Lições Aprendidas. O responsável por este papel é o Tester.
    • 805.2.4 FinalizaçãoDiagrama 7 - Visão detalhada do processo de Finalização.Fonte: Elaboração dos autores, 2010.  Objetivos: analisar os resultados.  Descrição: na terceira e última etapa, tem-se o resultado dos Testes que foram ou estão sendo realizados. Aqui é possível obter informações do grau de qualidade do sistema através de relatórios de Incidentes, bem como o sumário que descreve toda a cobertura do Teste executado – fornece um sumário das atividades de Testes realizadas durante
    • 81 um determinado projeto e mostra de forma resumida as ocorrências durante todas as atividades realizadas, finalizando o ciclo do Teste.  Fases: a) Reportar erros ao desenvolvimento; b) Gerenciar Resultados. a) Reportar erros ao desenvolvimento: no processo de finalização será repassado ao setor de desenvolvimento os incidentes para que possam ser corrigidos e novamente entrar em Testes. Isso será feito através dos relatórios de incidentes. b) Gerenciar Resultados: com os resultados dos Testes cabe então ao gerente de Testes gerenciar esses resultados para melhorar a qualidade final do processo e conseqüentemente da aplicação. As atividades que contemplam esta fase são:  Identificar eventuais modificações em relação à duração e prazo de finalização do Projeto de Teste;  Analisar dificuldades encontradas;  Reavaliar riscos do projeto em função de um maior detalhamento sobre os requisitos;  Reavaliar as estimativas de esforço e duração do Processo de Teste; (tarefa executada se necessário);  Avaliar e tomar medidas quanto à aplicação de mais recursos ou alteração no cronograma-macro de entrega do projeto juntamente com o gerente de projeto. (tarefa executada se necessário);  Reportar os incidentes ao desenvolvimento; O responsável por este papel é o Gerente de Testes.6 DESENVOLVIMENTO DO SISTEMA DE TESTES Neste capítulo será apresentada a ferramenta desenvolvida, bem como astecnologias que foram utilizadas e a sua modelagem.
    • 826.1 VISÃO GERAL Com a necessidade de realizar Testes nas aplicações desenvolvidas por umaempresa de software, surge também a necessidade de controlar e gerenciar tais Testes. Denada adianta testar se não souber o que testar e quais resultados devem ser obtidos para que oteste seja aprovado, assim como não adianta realizar os testes e não conseguir gerenciar asinformações obtidas através deles. A aplicação desenvolvida vem no intuito de colaborar na execução e obtenção deinformaçõ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 deentrada e saída e resultados esperados para cada operação do sistema, colaborando para que oTester 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étricasde qualidade para sua aplicação. A aplicação foi projetada dentro do processo descrito acima. Como o processoprevê quatro papéis para o gerenciamento de Testes, na aplicação será possível cadastrar osquatro tipos de usuários, cada um com o acesso correspondente à atividade que ele realizadentro do processo.6.1.1 Arquitetura Para desenvolver a aplicação será utilizado o padrão de projeto MVC, queconsiste 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 acessodireto ao banco de dados, e vice-versa. Para fazer essa comunicação a camada “View” deveacessar a camada Controller para assim a camada “Model” acessar o banco de dados. A
    • 83comunicação entre as camadas é feito através de domínios ou entities, que são classes quecontém as informações referentes à tabela no banco de dados. Model (DAO): essa camada é responsável por manter as informações no banco dedados, 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 deveretornar 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 acessodiretamente ao banco de dados. Controller (Service): é nessa camada que ficam as regras de negócio, realizando acomunicação entre a camada model com a camada view, através das solicitações feitas pelacamada view e os retornos da camada model. A relação entre as camadas é representada no esquema a seguir.Figura 10 - Arquitetura de aplicações em padrão de projeto MVC.Fonte: Elaboração dos autores, 2010. A interface será desenvolvida para ambientes WEB utilizando o Adobe Flex 3,essa ferramenta é um Framework Free e Open Source, utilizado para criar aplicações RIA(Rich Internet Applications). O back-end4 da aplicação será desenvolvido em JAVA J2EEutilizando o Framework Spring para deixar o código dentro do padrão de projeto MVC. Apersistência dos dados será feira através do framework Hibernate Annotations 3 e o banco de4 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.
    • 84dados utilizado será o MYSQL 5.1. Por último, a aplicação será hospedada no servidorApache TomCat 6.0. A comunicação entre a interface será feita através do framework BlazeDS,também um framework Open Source, desenvolvido e fornecido pela Adobe. Abaixo é apresentada da arquitetura da aplicação.Esquema 6 - Arquitetura da aplicação.Fonte: Elaboração dos autores, 2010.6.2 MODELO CONCEITUAL Os tópicos seguintes discorrem a respeito do diagrama de casos de uso, suadescriçã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 ainteração que os atores5 tem sobre o sistema, sem revelar a estrutura e os comportamentosinternos desse sistema. Cada caso de uso deve possuir uma narração sobre as interações queocorrem entre os atores e o sistema sua representação é feita por uma elipse com seu nomeposicionado 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 representargraficamente o relacionamento entre atores e os casos de uso.Diagrama 3 - Diagrama de Casos de Uso.Fonte: Elaboração dos autores, 2010.6.2.2 Descrição dos Casos de Uso Cada caso de uso do diagrama acima será descrito a seguir.
    • 866.2.2.1 Manter Tipos de TesteAtores: Analista de TestePré-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 PrincipalA1. O ator acessa o módulo CadastrosS1. O sistema exibe a janela com um campo disponível para pesquisa ou inserção do tipo deteste. Também lista todos os tipos de testes já cadastrados no sistema, classificando seucódigo, e descrição.A2. O ator inclui um novo tipo de teste, informando sua descrição e observação casonecessá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 umadescrição para que o cadastro seja efetuado.Quadro 8 - Manter Plano de Teste.Fonte: Elaboração dos autores, 2010.6.2.2.2 Manter PrioridadeAtores: Analista de TestePré-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 PrincipalA1. O ator acessa o módulo CadastrosS1. O sistema exibe a janela com um campo disponível para pesquisa ou inserção daprioridade. Também lista todos as prioridades já cadastradas no sistema, classificando seucódigo, descrição e nível de prioridade.A2. O ator inclui uma nova prioridade, informando sua descrição e nível de prioridade.S2. O sistema grava as informações.Fluxo Alternativo:A2. O ator inclui uma prioridade sem informar a descrição e nível de prioridade.R2. O sistema exibe uma mensagem notificando o ator de que é obrigatório informar todas asinformações obrigatórias para que o cadastro seja efetuado.Quadro 9 - Manter Plano de Teste.Fonte: Elaboração dos autores, 2010.
    • 876.2.2.3 Manter Plano de TesteAtores: Analista de TestesPré-Condição: Os casos de Testes que serão incluídos no Plano de Testes devem estar elaborados erevisados.Pós-Condições: O documento de Plano de Teste deve ser gerado e disponível para o Tester.Fluxo PrincipalA1. 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 deteste, a abordagem do teste, os critérios de liberação, suspensão e retomada, entrega do teste, tarefasdo teste, ambiente, responsáveis, necessidade de equipe, cronograma, riscos e aprovações e finaliza oprocesso;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 campospara que o cadastro seja efetuado.Quadro 10 - Manter Plano de Teste.Fonte: Elaboração dos autores, 2010.6.2.2.4 Manter Caso de TesteAtores: Analista de TestesPré-Condição: Não de aplica.Pós-Condições: Não se aplica.Fluxo PrincipalA1. 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 deteste, massa de entrada e saída, critérios especiais, ambiente, tipo de teste, cronograma einterdependê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óriosR2. O sistema exibe uma mensagem notificando o ator de que é obrigatório informar todos os camposrequeridos para que o cadastro seja efetuado.Quadro 11 - Manter Caso de TesteFonte: Elaboração dos autores, 2010.
    • 886.2.2.5 Executar Plano de TesteAtores: TesterPré-Condição: O plano de testes deve estar cadastrado no sistema contendo os seus respectivos casosde 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á-loFluxo PrincipalA1. 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” pordefault) 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 TesteFonte: Elaboração dos autores, 2010.6.2.2.6 Gerenciar ProcessosAtores: Gerente de TestePré-Condição: A execução do plano de teste deve estar finalizadaPós-Condições: Não se aplica.Fluxo PrincipalA1. 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 paraseu preenchimento.A2. O ator informa os campos e visualiza o relatório.S2. O sistema exibe o relatório contendo as informações dos testes executados no período informado.Fluxo Alternativo:A2. O ator emite o relatório sem o preenchimento dos campos requeridos.R2. O sistema exibe uma mensagem notificando o ator de que é obrigatório informar todos os camposrequeridos para que o cadastro seja efetuado.Quadro 13 - Gerenciar processo.Fonte: elaboração dos autores, 2010.
    • 896.2.2.7 Manter usuário e grupoAtores: Gerente de TestePré-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 PrincipalA1. O ator acessa o módulo cadastrosS1. O sistema exibe a janela com um campo disponível para pesquisa ou inserção do usuário.Também lista todos os usuários já cadastrados no sistema, classificando seu código, login e tipo.A2. O ator inclui um novo usuário, informando seu nome, senha e seu tipo de acesso.S2. O sistema grava as informações.Fluxo Alternativo:A2. O ator inclui um usuário sem informar os campos requeridos, tais como nome, senha e tipo deacesso.R2. O sistema exibe uma mensagem notificando o ator de que é obrigatório informar todos os camposrequeridos para que o cadastro seja efetuado.Quadro 14 - Manter Usuário e Grupo.Fonte: Elaboração dos autores, 2010.
    • 906.2.3 Modelo de Domínio de ClasseDiagrama 4 - Diagrama de domínio de Classe.Fonte: Elaboração dos autores, 2010. CLASSE DESCRIÇÃOUsuá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 Mantém as observações dos resultados da execução do Teste em cadaTeste caso de Teste, se o caso de Teste foi aprovado, reprovado, necessita de melhoria.Quadro 15 - Descrição das classesFonte: Elaboração dos autores, 2010.
    • 916.3 PROJETO FÍSICO O modelo físico tem como objetivo desmembrar os processos e recursos que serãoutilizados dentro da aplicação, para assim ter uma visão ampla do funcionamento daaplicação. Neste modelo também se tem a especificação do relacionamento existente entrecada componente da aplicação.6.3.1 Diagrama de pacotes A figura abaixo ilustra o diagrama geral de pacotes mostrando os objetos e orelacionamento existente em cada pacote.
    • 92Diagrama 5 - Diagrama geral de pacotes.Fonte: Elaboração dos autores, 2010. As representações a seguir relacionam-se respectivamente ao diagrama de pacotesentitys, repository ou interfaces, services e DAO.
    • 93Diagrama 6 - Diagrama de pacotes entitys.Fonte: Elaboração dos autores, 2010.
    • 94Diagrama 7 - Diagrama de pacotes repository.Fonte: Elaboração dos autores, 2010.
    • 95Diagrama 8 - Diagrama de pacotes service.Fonte: Elaboração dos autores, 2010.
    • 96.Diagrama 9 - Diagrama de pacotes DAO.Fonte: Elaboração dos autores, 2010. As classes responsáveis pela emissão dos relatórios serão apresentadas a seguir,sendo que o diagrama de pacotes manager é responsável pela manipulação de qual relatórioserá emitido, e a classe servlet, por receber a solicitação da visualização do relatório eapresentá-la ao usuário.Diagrama 10 - Pacotes manager.Fonte: Elaboração dos autores, 2010.
    • 97Diagrama 11 - Pacotes servlet.Fonte: Elaboração dos autores, 2010. A seguir é ilustrado o pacote de infrastructure, responsável por manter as classescontendo as configurações necessárias para que o framework Spring possa realizar ainstanciação dos objetos e as configurações para o Hibernate Annotations.Diagrama 12 - Diagrama de pacotes infrastructure.Fonte: Elaboração dos autores, 2010. O diagrama apresenta os pacotes contendo as view, que são a interface do sistema,onde existe a interação entre o usuário e a aplicação.
    • 98Diagrama 13 - Diagrama de pacotes view.Fonte: Elaboração dos autores, 2010.
    • 996.3.2 Modelo E.R.Diagrama 14 - Modelo de ER- Relacionamento entre tabelas.Fonte: Elaboração dos autores, 2010.
    • 1006.3.3 Dicionário de Dados Para uma melhor compreensão do Modelo ER da aplicação faz-se necessário douso do diagrama de dados. Nele será descrito qual é o objetivo de cada tabela junto com seusrelacionamentos com as outras tabelas existentes, caso necessário. Informações como adescrição do atributo, seu tipo, e também a obrigatoriedade estão presentes nessasespecificações.Tabela 5 - Dicionário de dados entidade usuário. Tabela: USUARIOObjetivo 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.AtributosNome Descrição Tipo Regra Obrigatórioid_usuario Código do usuário INTEGER PK Simnm_login Login do usuário VARCHAR(50) UQ Simds_senha Senha do usuário VARCHAR(50) Simfl_tipousuario Tipo do usuário, definindo os acessos VARCHAR(3) CK Sim que o usuário terá no sistemaFonte: Elaboração dos autores, 2010.Tabela 6 - Dicionário de dados entidade prioridade. Tabela: PRIORIDADEObjetivo Armazenar o nível de prioridade para ser utilizado na execução dos Testes.Relacionamento Esta tabela não possui relacionamento com nenhuma tabela.AtributosNome Descrição Tipo Regra Obrigatórioid_prioridade Código da prioridade INTEGER PK Simds_prioridade Descrição da prioridade VARCHAR(50) UQ Simnr_pesoprioridade Definição do nível da prioridade, VARCHAR(50) Sim quanto mais alto for o valor maior prioridade ele terá.Fonte: Elaboração dos autores, 2010.
    • 101Tabela 7 - Dicionário de dados entidade tipos de Teste. Tabela: TIPOTESTEObjetivo Armazenar os tipos de Testes que podem ser efetuados.Relacionamento Esta tabela não possui relacionamento com nenhuma tabela.AtributosNome Descrição Tipo Regra Obrigatórioid_tipoTeste Código da prioridade INTEGER PK Simds_tipoTeste Descrição da prioridade VARCHAR(50) UQ Simds_observacaodetalhada Definição do nível da VARCHAR(250) Não prioridade, quanto mais alto for o valor maior prioridade ele terá.Fonte: Elaboração dos autores, 2010.Tabela 8 - Dicionário de dados entidade grupo. Tabela: GRUPOObjetivo Armazenar os grupos de usuário para definir os responsáveis por determinados planos de Testes.Relacionamento Esta tabela não possui relacionamento com nenhuma tabela.AtributosNome Descrição Tipo Regra Obrigatórioid_grupo Código do grupo INTEGER PK Simds_grupo Descrição do grupo VARCHAR(50) UQ SimFonte: Elaboração dos autores, 2010.Tabela 9 - Dicionário de dados entidade de ligação entre grupo e usuário. Tabela: GRUPOUSUARIOObjetivo Armazenar os usuários e determinar seus respectivos grupos.Relacionamento Esta tabela possui relacionamento com a tabela USUARIO e GRUPO.AtributosNome Descrição Tipo Regra Obrigatórioid_grupo Código do grupo INTEGER PK Simid_usuario Código do usuário INTEGER PK SimFonte: Elaboração dos autores, 2010.
    • 102Tabela 10 - Dicionário de dados entidade plano de Teste Tabela: PLANODETESTEObjetivo Armazenar os planos de Testes cadastrados.Relacionamento Esta tabela possui relacionamento com as tabelas USUARIO, PRIORIDADE e GRUPO.AtributosNome Descrição Tipo Regra Obrigatórioid_planodeTeste Código do plano de Teste INTEGER PK Simid_usuariocadastro Usuário que cadastrou o plano INTEGER FK Sim de Testedt_cadastro Data de cadastro do plano de DATETIME Sim Testedt_ultimamodificacao Data da ultima alteração no DATETIME Não plano de Testeid_grupo Grupo de usuários responsável INTEGER FK Sim pelo plano de Testeds_identificacao Identificação única do plano VARCHAR(100) Sim de Teste informada pelo usuáriods_introducao Introdução ao plano de Teste TEXT Nãods_itensTeste Descrição dos itens de Teste TEXT Nãods_abordagemTeste Descrição da abordagem do TEXT Não Testeds_criteriosliberacao Critérios para realizar a TEXT Não liberação do plano de Testeds_suspensaoretomada Descrição das condições de TEXT Não suspensão e retomada de Testeds_documentosentrega Descrição dos documentos TEXT Não necessários para entregar após termino dos Testesds_tarefasTeste Descrição das tarefas do Teste TEXT Nãods_ambientes Descrição dos ambientes que TEXT Não devem ser testadods_responsaveis Descrição dos responsáveis TEXT Não por realizar os Testesds_necessidadedaequipe Descrição das necessidade que TEXT Não o Teste exige da equipeds_riscos Descrição dos riscos TEXT Nãods_aprovacoes Descrição das condições de TEXT Não aprovaçãods_cronograma Cronograma de realização dos TEXT Não Testesid_prioridade Prioridade do plano de Teste INTEGER FK SimFonte: Elaboração dos autores, 2010.
    • 103Tabela 11 - Dicionário de dados entidade caso de Teste Tabela: CASODETESTEObjetivo 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.AtributosNome Descrição Tipo Regra Obrigatórioid_casodeTeste Código da caso de Teste INTEGER PK Simid_usuariocadastro Código do usuário que fez o INTEGER FK Sim cadastro do caso de Testedt_cadastro Data de cadastro DATETIME Simdt_ultimamodificacao Data da ultima alteração DATETIME Nãods_identificacao Identificação única do caso de VARCHAR(100) Sim Teste que é informada pelo usuário.ds_precondicoes Condições necessárias para TEXT Não iniciar o Testeds_poscondicoes Condições após terminar o TEXT Não Testeds_casodeTeste Descrição do caso de Teste TEXT Nãods_entradasaida Entradas e saídas da execução TEXT Não do caso de Testeds_criteriosespeciais Critérios especiais do caso de TEXT Não Testeds_ambiente Ambiente em que o Teste deve TEXT Não ser realizadods_dependencias Dependências com outros caso TEXT Não de Testeds_cronograma Cronograma de execução dos TEXT Não Testes.id_planodeTeste Plano de Testes deste caso de INTEGER FK Não Testesid_prioridade Prioridade do caso de Teste INTEGER FK Simid_tipoTeste Tipo do Teste INTEGER FK SimFonte: Elaboração dos autores, 2010.
    • 104Tabela 12 - Dicionário de dados entidade ciclo de Teste Tabela: CICLODETESTEObjetivo 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.AtributosNome Descrição Tipo Regra Obrigatórioid_ciclodeTeste Código da ciclo de Teste INTEGER PK Simid_planodeTeste Código do plano de Teste INTEGER FK Simdt_inicio Data em que o ciclo de Teste teve DATETIME Sim iniciodt_termino Data em que o ciclo de Teste foi DATETIME Não finalizadofl_status Situação atual do ciclo de Teste VARCHAR(2) Simid_usuario Código do usuário que esta INTEGER FK Sim realizando o ciclo de TesteFonte: Elaboração dos autores, 2010.Tabela 13 - Dicionário de dados entidade ciclo de Teste notas. Tabela: CICLODETESTE_NOTASObjetivo 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.AtributosNome Descrição Tipo Regra Obrigatórioid_ciclodeTeste Código do ciclo de Teste INTEGER PK Simid_ciclodeTeste_nota Código do item do ciclo de Teste INTEGER PK Simid_casodeTeste Código do caso de Teste da INTEGER FK Sim execuçãodt_nota Data de anotação DATETIME Simfl_posicao Posição da execução VARCHAR(2) Simds_observacao Observação sobre a execução VARCHAR(250) Simid_usuario Usuário que cadastrou a nota INTEGER FK SimFonte: Elaboração dos autores, 2010.
    • 1057 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 doscampos necessários no cadastro. Esse caractere significa que aquele campo é depreenchimento obrigatório, ou seja, o cadastro não será gravado caso este não estejapreenchido. O sistema é controlado pelos tipos de usuários cadastrados nele, sendo que cadatipo de usuário tem uma determinada permissão e conseqüentemente um acesso diferenciadodentro do sistema. Quando é feito o login, o sistema carrega as permissões do usuário, econfigura o sistema de acordo com tais permissões. Sem efetuar o login, não é possívelacessar nenhuma informação dentro do sistema.Figura 11 - Tela de loginFonte: Elaboração dos autores, 2010. Abaixo seguem imagens que mostram os acessos para cada tipo de usuário queexiste no sistema. Seguem respectivamente os usuários gerente de teste, analista de teste etester.
    • 106Figura 12 - Menu do usuário gerente de testeFonte: Elaboração dos autores, 2010.Figura 13 - Menu do usuário analista de testeFonte: Elaboração dos autores, 2010.
    • 107Figura 14 - Menu do usuário TesterFonte: Elaboração dos autores, 2010. Na figura abaixo, tem-se a lista de usuários. A janela possibilita alterar, excluir eincluir um usuário no sistema. É possível filtrar pelo nome e buscar o usuário desejado. Estamesma tela é utilizada quando existe a necessidade de pesquisar um usuário para referenciarem outro cadastro.Figura 15 - Lista de usuáriosFonte: Elaboração dos autores, 2010.
    • 108 Para cadastrar um usuário é necessário informar seu nome, senha e seu tipo(gerente de teste, analista e tester). Este último define os acessos que ele terá no sistema. Atela de inclusão é igual a tela de edição de um usuário, visto que na edição não é possívelvisualizar a senha, apenas alterá-la. Nem mesmo o gerente de teste pode visualizar a senha deum usuário, podendo apenas redefini-la em caso de perca. Abaixo consta a imagem docadastro de usuário.Figura 16 - Cadastro de usuárioFonte: Elaboração dos autores, 2010. Dentro da lista de grupo de usuário, tem-se a possibilidade de alterar, excluir eincluir 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áriosFonte: Elaboração dos autores, 2010.
    • 109 Para cadastrar um grupo de usuários, é necessário preencher informações comosua descrição e os usuários respectivos ao grupo, conforme a imagem abaixo. Dentro docadastro é 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árioFonte: Elaboração dos autores, 2010. Dentro da lista de tipos de testes, tem-se a possibilidade de alterar, excluir eincluir um tipo de teste no sistema. Pode-se realizar filtros por descrição para buscar o tipo deteste desejado. Esta mesma tela é utilizada quando existe a necessidade de pesquisar um tipode teste para referenciar em outro cadastro.
    • 110Figura 19 - Lista tipo de testeFonte: Elaboração dos autores, 2010. Para cadastrar um tipo de teste é necessário obrigatoriamente informar suadescrição, existindo a possibilidade de escrever uma observação referente ao tipo de teste casose faça necessário. A imagem abaixo apresenta a tela do cadastro do tipo de teste.Figura 20 - Cadastro de tipo de testeFonte: Elaboração dos autores, 2010. Dentro da lista de prioridades, é possível alterar, excluir e incluir uma prioridadeno sistema. Pode-se realizar filtros por descrição para buscar a prioridade desejada. Esta
    • 111mesma tela é utilizada quando existe a necessidade de pesquisar uma prioridade parareferenciar em outro cadastro – conforme imagem abaixo.Figura 21 - Lista de prioridadeFonte: Elaboração dos autores, 2010. Para cadastrar uma prioridade é necessário informar a sua descrição e o nível deprioridade - que identifica o grau de prioridade da mesma. Quanto mais alto for o nível, maiorprioridade ela terá.Figura 22 - Cadastro de prioridadeFonte: Elaboração dos autores, 2010. Dentro da lista de plano de testes, é possível alterar, incluir e excluir um plano deteste 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.
    • 112Figura 23 - Lista de plano de testeFonte: Elaboração dos autores, 2010. Para se cadastrar um plano de testes, é necessário informar uma descriçãocontendo sua identificação que deve ser única, referenciar um grupo responsável e umaprioridade ao plano de teste. Outras informações devem ser inseridas, tais como: Introduçãodo 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á cadastradosno sistema, ou mesmo incluir novos casos de testes para este plano de teste e, ainda, removerum caso de teste do plano de testes. Abaixo a imagem do cadastro de plano de teste.
    • 113Figura 24 - Cadastro de plano de testeFonte: Elaboração dos autores, 2010. Dentro da lista de caso de teste, o sistema possibilidade alterar, excluir e incluirum caso de teste. Pode-se realizar filtros por identificação para buscar o caso de testedesejado. Esta mesma tela é utilizada ao realizar o relacionamento entre os casos de testes e oplano de teste.
    • 114Figura 25 - Lista de caso de testeFonte: Elaboração dos autores, 2010. Para se cadastrar um caso de testes é necessário informar uma descrição contendosua 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ãosã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 eInterdependência entre os casos de teste.
    • 115Figura 26 - Cadastro de caso de testeFonte: Elaboração dos autores, 2010. Dentro da lista de ciclos de teste, você poderia visualizar quais testes estão sendoexecutados no momento, quais foram executados, finalizados e não testado. Tem-se apossibilidade alterar, excluir e incluir um ciclo de teste no sistema.Figura 27 - Lista de ciclos de execução do plano de testeFonte: Elaboração dos autores, 2010.
    • 116 A tela de ciclo de teste é responsável por fazer a execução do teste. Para iniciarum novo ciclo, deve-se selecionar o plano de teste que será testado, então o sistemaautomaticamente 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 naexecução do caso de testes, aprovar ou reprovar o caso de teste. Também é possível consultara especificação do caso de teste selecionado. A imagem a seguir apresenta esta janela.Figura 28 - Execução do plano de testeFonte: Elaboração dos autores, 2010. A tela abaixo se refere às notas da execução do caso de testes. Ela serve parainformar a situação do caso de teste: se ele foi aprovado, reprovado, finalizado ou necessita demelhoria. O campo de observação serve para descrever o motivo e sugestões para que oproblema possa ser resolvido.
    • 117Figura 29 - Notas da execução do plano de testeFonte: Elaboração dos autores, 2010. A figura a seguir ilustra a tela para a emissão do relatório de log de Testesseguindo o relatório já impresso. O período de finalização pode ser informado manualmenteou utilizar a opção de períodos pré-definidos. Sendo obrigatório informar uma data inicial euma data final.Figura 30 - Filtros do relatório de log de TesteFonte: Elaboração dos autores, 2010.
    • 118Figura 31 - Visualização do relatório de log de TesteFonte: Elaboração dos autores, 2010. A imagem abaixo mostra a tela para a emissão do relatório de incidentes seguindoo relatório já impresso. Pode-se informar o período de finalização manualmente ou utilizar aopção de períodos pré-definidos.Figura 32 - Filtros do relatório de IncidentesFonte: Elaboração dos autores, 2010.Figura 33 - Visualização do relatório de incidentesFonte: Elaboração dos autores, 2010.
    • 119 A figura a seguir ilustra a tela para a emissão do relatório de sumário seguindo orelatório já impresso. O período de finalização pode ser informado manualmente ou pode-seutilizar a opção de períodos pré-definidos. Sendo que é obrigatório informar uma data inicial euma data final.Figura 34 - Filtros do relatório de sumárioFonte: Elaboração dos autores, 2010.Figura 35 – Visualização do relatório de sumárioFonte: Elaboração dos autores, 2010.
    • 1208 CONCLUSÃO Existe hoje uma necessidade de implementar Testes dentro do ciclo dedesenvolvimento de software de uma empresa, com o objetivo de agregar qualidade ao seuproduto. Esta necessidade vem surgindo com o alto grau de exigência dos clientes quesolicitam uma ferramenta segura, estável e confiável, vindo também ao encontro danecessidade da própria empresa desenvolvedora em reduzir custos, visto que, com a execuçãode Testes, muitos erros são identificados e corrigidos antes de ir para o cliente. Quando esseserros 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 Testesfez com que esses profissionais ficassem escassos no mercado, dificultando assim aimplantação desta atividade nas empresas, principalmente nas menores, já que seu capital epotencial de investimento é limitado. Sem o profissional capaz de implementar a atividade de Testes dentro daempresa, surge a necessidade de uma ferramenta simples e estruturada em um processo jádefinido, para que profissionais menos experientes em gerenciamento de Testes possamutilizá-la, montando apenas as especificações do produto a ser testado, reduzindo assim osinvestimentos com treinamentos específicos, consultorias, entre outras. Para a definição do processo de Testes foi feito um estudo sobre asmetodologias para gerenciamento de processo com foco em Testes. Nessa análise optou-sepor utilizar o MPS.BR. Foi construída uma aplicação para ambiente WEB, fornecendoflexibilidade a empresa que a utilizará, podendo acompanhar o processo de qualquer local quepossua uma conexão com a Internet. No decorrer deste trabalho, surgiram algumas dificuldades. As dificuldadescomeç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 parasimplificar o processo foi trabalhoso, exigiu muito tempo de pesquisa. Foram encontrados alguns obstáculos durante a implementação da aplicação. Aferramenta utilizada para criar a interface possui alguns bugs e em alguns momentos o seudesempenho 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çõesem HTML, dificultando a manipulação por parte dos desenvolvedores. Esse problema, porém,
    • 121foi superado. O desenvolvimento da nova ferramenta foi fundamental, pois a ferramenta derelató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ãoextremamente 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 odesenvolvimento reduziria o tempo entre o repasse dos problemas ao desenvolvimento e oretorno do mesmo para novos Testes; b) relatório de tempo gasto: construir um relatório ondese possa visualizar o tempo gasto nos Testes por usuário, para verificar a produtividade dofuncionário. c) gráficos de incidentes: montar um gráfico onde possa se visualizar de formaclara e rápida o funcionamento geral da aplicação, informando o que está funcionando e o quenão está funcionando. Acredita-se ter alcançado todos os objetivos e requisitos propostos no iníciodeste trabalho. Em especial, adquiriu-se maior conhecimento na área de Testes, através doembasamento teórico utilizado. O resultado foi a criação de uma ferramenta que pode sercomercializada.
    • 122 REFERÊNCIASASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 9000:2000 : Sistemasde 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çãodo 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 deJaneiro: 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: 11jun. 2009.CAMPOS, Fabio M. Qualidade, qualidade de software e garantia da qualidade desoftware 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 SoftwareMagazine. 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+Software,+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.
    • 123LOURENÇ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 ProjectManagement Body of Knowledge - PMBOK™. Disponível em: <www.pmi.org>. Acessoem: out. 2009.PONTES, Melissa Barbosa et. al. Validação, verificação & teste. Engenharia de SoftwareMagazine. 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ívelem: <http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/245>. Acesso em: abr.2010WTHREEX/RUP. Rational Software Corporation. (Copyright(c) 1987 - 2001). Disponívelem: <http://www.wthreex.com/rup/process/workflow/manageme/co_meqlty.htm>. Acessoem: abr. 2010.