Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
TESTE-PLAN: FERRAMENTA DE APOIO AO
PLANEJAMENTO E CONTROLE DAS ATIVIDADES DO
PROCESSO DE TESTES
CAMILA LABES
BLUMENAU
2010
2010/1-04
CAMILA LABES
TESTE-PLAN: FERRAMENTA DE APOIO AO
PLANEJAMENTO E CONTROLE DAS ATIVIDADES DO
PROCESSO DE TESTES
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso II do curso de Sistemas
de Informação— Bacharelado.
Profª. Fabiane Barreto Vavassori Benitti, Dra - Orientadora
BLUMENAU
2010
2010/1-04
TESTE-PLAN: FERRAMENTA DE APOIO AO
PLANEJAMENTO E CONTROLE DAS ATIVIDADES DO
PROCESSO DE TESTES
Por
CAMILA LABES
Trabalho aprovado para obtenção dos créditos
na disciplina de Trabalho de Conclusão de
Curso II, pela banca examinadora formada
por:
______________________________________________________
Presidente: Profª. Fabiane Barreto Vavassori Benitti, Dra. – Orientadora– FURB
______________________________________________________
Membro: Profº. Everaldo Artur Grahl, Mestre – FURB
______________________________________________________
Membro: Profº. Wilson Pedro Carli, Mestre – FURB
Blumenau, 02 de julho de 2010.
Dedico este trabalho á Cláudia e Rui, exemplos de garra,
coragem e esperança, pessoas que tenho orgulho de
chamar de pais! São meus dois alicerces, pessoas que me
educaram, guiaram pelos melhores caminhos, ensinaram
a optar pelas escolhas mais convenientes, me mostraram
que na vida é essencial o caráter, a honestidade e o
respeito, mostraram que devemos sempre lutar pelo o
que queremos e nunca, nunca mediram esforços para
ajudar a realizar meus sonhos.
AGRADECIMENTOS
À Deus que me iluminou e deu forças, que me ajudou a não desistir diante das
dificuldades.
Ao meu irmão Marcelo, que fez parte de toda trajetória, obrigada pelo amor e amizade.
Obrigada meu melhor amigo e amor Tiago, ah se não fosse tu! Obrigada por confiar
em mim, por toda a dedicação e companheirismo, obrigada pela força e motivação, por ter
participado comigo de todas as dificuldades e vitórias na confecção deste trabalho. Obrigada
por ter me entendido e compreendido a ausência e os momentos tristes, sempre me acalmando
e ajudando quando o desespero e o nervosismo falaram mais alto.
À Fabiane, pela orientação e pelo ―banho‖ de conhecimento que me dava a cada
encontro, por me aceitar, pela prontidão, que mesmo de longe esteve sempre disponível,
obrigada por acreditar no meu potencial e capacidade, és a pessoa em quem eu me espelho!
Ao Professor Wilson, meu querido! Que muitas vezes foi além do que precisava fazer
para me ajudar e apoiar. Obrigada pela prontidão, por me ouvir, me tirar dúvidas, por
compartilhar experiências e toda a bagagem de conhecimento que possuis.
À todos os professores, quanta sabedoria! Espero que se orgulhem de nós formandos.
À HBSIS Informática, meus líderes e equipe por compreenderem minha ausência
quando se fez necessário. Obrigada especial para os colaboradores da área de testes, que
entraram comigo neste trabalho, que participaram e em momento algum se negaram a me
ajudar.
Amigos meus! Que dádiva estarem presentes em minha vida (mesmo que de longe),
vocês tantas vezes me fizeram rir, quando o que eu mais queria era chorar. Obrigada pela
paciência, por tolerar minha impaciência, por terem me motivado e entendido a ausência neste
último ano. Vocês são os ingredientes mais importantes de todas as receitas da minha vida!
Construí amigos, enfrentei derrotas, venci
obstáculos, bati na porta da vida e disse-lhe:
Não tenho medo de vivê-la.
Augusto Cury
RESUMO
O processo de teste de software envolve muitos recursos e riscos. Geralmente está associado a
limitações nas atividades de gerenciamento e controle, gerando problemas para a organização
e tornando o teste de software uma das atividades mais caras de todo o processo de
desenvolvimento. Utilizar ferramentas de apoio neste processo é tão interessante quanto
aplicar ferramentas de apoio no processo de construção de software por exemplo. Este
trabalho apresenta uma solução WEB aplicada a uma empresa de Blumenau, visando a
obtenção do Capability Maturity Model Integration (CMMI). O objetivo é apoiar as
atividades gerenciais da área de testes, como por exemplo, planejamento e controle. Propõe
controlar a sequência de atividades do processo de testes e os envolvidos, mostrando uma
forma de manter a documentação e o resultado de execuções.
Palavras-chave: Sistemas de informação. Teste. Casos de teste.
ABSTRACT
The process of software testing involves many resources and risks. Generally these are
associated with limitations of the management and control activities, which creates problems
to the organization and makes the software testing activities sometimes more expensive then
the whole process of development. To use tools to support this process is as appealing as to
use tools to support the process of developing software, for example. This paper presents a
WEB solution applied to a company in Blumenau, in order to obtain Capability Maturity
Model Integration (CMMI). The goal is to support the management activities of the testing
area, such as planning and controlling and to control the sequence of the process of testing
and the people involved in those activities, showing a way to keep the documentation and
outcome of plays up to date.
Key-words: Information systems. Test. Test case.
LISTA DE ILUSTRAÇÕES
Figura 1– Processo de testes ................................................................................................. 19
Figura 2– Ciclo entre processo de desenvolvimento e de testes............................................. 21
Figura 3 – Representação do processo em duas dimensões ................................................... 25
Figura 4– Atividades do processo ......................................................................................... 32
Figura 5 – Template da planilha de dados ............................................................................. 33
Figura 6– Diagrama de transição de estados ......................................................................... 39
Figura 7– Fluxo da elaboração de casos de teste ................................................................... 41
Figura 8 – Fluxo da execução de casos de teste .................................................................... 42
Figura 9– Diagrama de casos de uso..................................................................................... 43
Figura 10– Diagrama de classes conceitual .......................................................................... 45
Figura 11 – Diagrama Entidade Relacionamento .................................................................. 46
Figura 12 – Montagem da tela de pesquisa de pessoas, filtros da tela.................................... 47
Figura 13 – Montagem da tela de pesquisa de pessoas, listagem da tela ................................ 48
Figura 14 – Método que popula a listagem de pessoas .......................................................... 49
Figura 15 – Relatório gerado em HTML e exportado para Excel .......................................... 50
Figura 16 – Dataset do relatório ........................................................................................... 50
Figura 17 – Arquivo de relatório .......................................................................................... 51
Figura 18 – Montagem da tela do relatório de inspeção ........................................................ 51
Figura 19 – Codificação do relatório .................................................................................... 52
Figura 20 – Exemplo do HierardGrid com pais e filhos ........................................................ 53
Figura 21 – Cenários com passos ......................................................................................... 54
Figura 22 – Diagrama de sequência para abertura da tela com HierardGrid .......................... 55
Figura 23 – Método MontarGridCenarios ............................................................................. 56
Figura 24 – Método CarregarDataset .................................................................................... 56
Figura 25 – Método RelacionarTabelas ................................................................................ 57
Figura 26 – Solução da implementação ................................................................................ 58
Figura 27 – Manipulação de coleção genérica ...................................................................... 59
Figura 28 – Diagrama de classes da biblioteca de acesso à dados ......................................... 60
Figura 29 – Classe ObjetoAcessoDados ............................................................................... 61
Figura 30 – Diagrama de classes especializadas de acesso á dados ....................................... 62
Figura 31 – Diagrama de sequência para montagem da tela de Sistemas ............................... 63
Figura 32 – Exemplo de relacionamento da classe Seguranca com uma página .................... 64
Figura 33 – Criação da Master Page .................................................................................... 65
Figura 34 – Criação da tela de Desenhos de teste, utilizando Master Page ........................... 65
Figura 35 – Tela de Login .................................................................................................... 66
Figura 36 – Tela de início .................................................................................................... 67
Figura 37 – Navegabilidade menus ...................................................................................... 68
Figura 38 – Navegabilidade páginas de pesquisa .................................................................. 69
Figura 39 – Navegabilidade detalhes .................................................................................... 69
Figura 40 – Tela de pesquisa de casos de uso ....................................................................... 70
Figura 41 – Importar casos de uso ........................................................................................ 71
Figura 42 - Mensagem de confirmação de importação de casos de uso ................................. 71
Figura 43 – Casos de uso no EA e importados na ferramenta ............................................... 72
Figura 44 – Novo caso de uso no EA e importado na ferramenta .......................................... 73
Figura 45 – Casos de uso importados exibidos na tela de caso de teste ................................. 74
Figura 46 – Pesquisa de desenhos de teste na visão de um analista de teste .......................... 75
Figura 47 – Pesquisa de desenhos de testes na visão de um testador ..................................... 75
Figura 48 – Pesquisa de desenhos de teste filtrando por sistema na visão de um analista ...... 76
Figura 49 – Tentativa de exclusão de desenho de testes que possui casos de teste ................. 76
Figura 50 – Criação de desenho de teste ............................................................................... 77
Figura 51 – Campo obrigatório cadastro de desenho de testes .............................................. 78
Figura 52 – Mensagem desenho de teste salvo com sucesso ................................................. 78
Figura 53 – Pesquisa de casos de teste, filtrando por desenho de teste .................................. 79
Figura 54 – Criação de caso de teste ..................................................................................... 79
Figura 55 – Caso de teste com cenário default ...................................................................... 80
Figura 56 – Detalhe cenário com passos ............................................................................... 81
Figura 57 – Detalhe do passo selecionado ............................................................................ 82
Figura 58 – Novo cenário ..................................................................................................... 83
Figura 59 – Cenário salvo .................................................................................................... 83
Figura 60 – Caso de teste em elaboração – visão do testador ................................................ 84
Figura 61 – Cenários e passos em elaboração – visão testador .............................................. 84
Figura 62 – Controle de inspeção ......................................................................................... 85
Figura 63 – Relatório de inspeção ........................................................................................ 85
Figura 64 – Aval analista de teste ......................................................................................... 86
Figura 65 – Execução de casos testes – visão testador .......................................................... 87
Figura 66 – Invalidando passo .............................................................................................. 87
Figura 67 – Relatório de erros .............................................................................................. 88
Figura 68 – Resultado do questionário ................................................................................. 91
Figura 69 – Pesquisa de sistemas........................................................................................ 102
Figura 70 – Tela de criação de novo sistema ...................................................................... 103
Figura 71 – Tela de criação de novo sistema, requisitando campos obrigatórios ................. 103
Figura 72 – Pesquisa de módulos ....................................................................................... 104
Figura 73 – Tela de criação de novo módulo ...................................................................... 104
Figura 74 – Pesquisa de pessoas ......................................................................................... 105
Figura 75 –Tela de criação de nova pessoa ......................................................................... 105
Figura 76 - Questionário .................................................................................................... 106
LISTA DE QUADROS
Quadro 1 – Estrutura do modelo CMMI ............................................................................... 27
Quadro 2 – Resumo de metas e práticas do CMMI ............................................................... 28
Quadro 3 – Resumo de metas e práticas do CMMI - VAL .................................................... 29
Quadro 4 - Requisitos funcionais ......................................................................................... 36
Quadro 5 - Requisitos não funcionais ................................................................................... 37
Quadro 6 – Quadro comparativo. ......................................................................................... 89
Quadro 7 – Aderência da ferramenta ao processo ................................................................. 89
Quadro 8 – Aderência ao CMMI .......................................................................................... 90
Quadro 9– Sugestões de melhorias ....................................................................................... 95
Quadro 10 – Descrição do caso de uso UC07 - Manter Desenho de Teste ............................ 98
Quadro 11 – Descrição do caso de uso UC08 - Manter Caso de Teste .................................. 99
Quadro 12 – Descrição do caso de uso UC09 - Importar Casos de Uso............................... 100
Quadro 13 – Descrição do caso de uso UC10 – Manter resultados da execução .................. 101
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................. 14
1.1 OBJETIVOS DO TRABALHO..................................................................................... 15
1.2 ESTRUTURA DO TRABALHO .................................................................................. 16
2 FUNDAMENTAÇÃO TEÓRICA................................................................................. 17
2.1 TESTE DE SOFTWARE .............................................................................................. 17
2.1.1 DEFINIÇÃO DA TAXONOMIA DE TERMOS RELACIONADOS A TESTE DE
SOFTWARE............................................................................................................... 17
2.1.2 PROCESSO DE TESTE ............................................................................................. 18
2.1.3 PLANEJAMENTO E CONTROLE DE TESTES ....................................................... 21
2.1.3.1 Ferramentas de apoio ao processo de testes ............................................................... 23
2.2 CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ................................. 25
2.2.1.1 Verificação ............................................................................................................... 28
2.2.1.2 Validação ................................................................................................................. 28
2.3 TRABALHOS CORRELATOS .................................................................................... 29
2.3.1 FERRAMENTA DE SUPORTE AO PLANEJAMENTO DE TESTE FUNCIONAL DE
SOFTWARE A PARTIR DE DIAGRAMAS DE CASOS DE USO ............................ 29
2.3.2 FERRAMENTA WEB DE APOIO AO PLANEJAMENTO E CONTROLE DE TESTE
DE SOFTWARE ........................................................................................................ 30
2.3.3 MARAKÁ: INFRA-ESTRUTURA COMPUTACIONAL PARA APOIAR O
PLANEJAMENTO E CONTROLE DOS TESTES DE SOFTWARE ......................... 30
3 DESENVOLVIMENTO DA FERRAMENTA ............................................................. 31
3.1 LEVANTAMENTO DE INFORMAÇÕES ................................................................... 31
3.1.1 PROBLEMAS RELATADOS .................................................................................... 34
3.1.2 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ................... 35
3.2 ESPECIFICAÇÃO ........................................................................................................ 37
3.2.1 VISÃO GERAL DA FERRAMENTA TESTE-PLAN ................................................ 37
3.2.2 FUNCIONAMENTO DA FERRAMENTA ................................................................ 38
3.2.3 DIAGRAMA DE CASO DE USO .............................................................................. 42
3.2.4 DIAGRAMA DE CLASSE ......................................................................................... 44
3.2.5 MODELO ENTIDADE RELACIONAMENTO.......................................................... 46
3.3 IMPLEMENTAÇÃO .................................................................................................... 46
3.3.1 TÉCNICAS E FERRAMENTAS UTILIZADAS ........................................................ 47
3.3.2 OPERACIONALIDADE DA IMPLEMENTAÇÃO ................................................... 66
3.3.2.1 Login ........................................................................................................................ 66
3.3.2.2 Navegabilidade ......................................................................................................... 67
3.3.2.3 Cadastros básicos ..................................................................................................... 70
3.3.2.4 Importação de casos de uso ....................................................................................... 70
3.3.2.5 Fluxo de testes .......................................................................................................... 74
3.4 RESULTADOS E DISCUSSÃO ................................................................................... 88
4 CONCLUSÕES ............................................................................................................. 93
4.1 EXTENSÕES ............................................................................................................... 94
REFERÊNCIAS BIBLIOGRÁFICAS .............................................................................. 96
14
1 INTRODUÇÃO
A atividade de testes é uma das atividades de Verificação e Validação (V&V)1.
Consiste na execução do produto com o objetivo de verificar a presença de defeitos e,
aumentar a confiança de que o produto esteja correto. Uma vez conduzida uma atividade de
testes que não foram detectados defeitos, pode-se concluir que o produto em testes é de boa
qualidade, ou, que a atividade de testes empregada é de baixa qualidade ou que foi conduzida
sem planejamento e controle, sem critérios e sem uma sistemática (ROCHA; MALDONADO;
WEBER, 2001).
Pfleeger (2004) afirma que o processo de testes tem vida própria no ciclo de
desenvolvimento e pode ser realizado em paralelo com muitas outras atividades. Cada etapa
do processo de testes deve ser planejada cuidadosamente, para ajudar a projetar e organizar os
testes, de forma a dar segurança de que os testes estão sendo adequados.
Segundo Mats (2001 apud DIAS NETO; TRAVASSOS, 2006), os cinco principais
problemas nas atividades de teste de software são:
a) atrasos no cronograma do projeto, deixando a equipe de teste impossibilitada de
completar os testes planejados devido à redução de recursos e tempo;
b) carência na rastreabilidade de casos de teste entre diferentes versões do sistema,
dificultando o reuso e repetição dos testes após modificações nos requisitos;
c) teste manual ou não-padronizado, resultando em um grande esforço a cada início de
uma nova atividade de teste.
d) incerteza sobre o que está sendo testado, devido à falta de definição dos objetivos e
escopo para as atividades de teste;
e) ausência de critérios para seleção dos casos de teste, definição da sua completude e
estabelecimento de um ponto de parada, dentre outros, dificultando a revelação de
falhas no produto.
Com relação aos problemas de teste de software, Sommerville (2003) afirma que este é
um processo dispendioso, pode tomar até metade do orçamento do desenvolvimento do
sistema, necessitando assim de um bom planejamento e controle, para não haver perda de
recursos e tempo, visando minimizar ou acabar com os problemas.
1 É o nome dado aos processos de verificação e análise que asseguram que o software cumpra com suas
especificações e atenda as necessidades dos clientes que estão pagando por ele (SOMMERVILLE, 2003).
15
Koscianski e Soares (2006) afirmam que na área de testes, ferramentas para
planejamento e base de testes são necessárias, e que, atualmente as empresas buscam em
planilhas de dados a organização para o grande volume de informações geradas pelas
atividades de teste. Afirmam ainda que, as planilhas de dados são alternativas para quando
não se tem uma ferramenta automatizada e aderente ao processo da empresa, e que, a longo
prazo, é provável que o uso de planilhas se torne confuso.
Pressman (2006) relaciona o teste de software à garantia de qualidade. A fase de testes
é o último reduto no qual a qualidade pode ser avaliada. A qualidade é incorporada ao
software durante todo o processo de desenvolvimento, não se pode testá-la, se ela não estiver
lá antes que comecem os testes, certamente não estará quanto terminarem. Existem
certificações relativas à qualidade do processo, como por exemplo, a Capability Maturity
Model Integration2 (CMMI) que para atingir determinado nível, exige que a área de testes seja
gerenciada. (ROCHA; MALDONADO; WEBER, 2001).
Observando todas estas evidências, este trabalho propõe a elaboração de uma
ferramenta para auxílio no planejamento e controle de casos de testes, a fim de automatizar o
processo de testes de uma empresa de informática que visa alcançar certificação CMMI.
11..11 OOBBJJEETTIIVVOOSS DDOO TTRRAABBAALLHHOO
O objetivo deste trabalho foi automatizar o processo de testes da empresa HBSIS
Informática.
Os objetivos específicos do trabalho são:
a) desenvolver uma ferramenta que permita auxiliar na etapa de planejamento do
processo de testes;
b) permitir o acompanhamento e controle das atividades planejadas no processo.
Verificação vem de: ―Estamos construindo corretamente o produto?‖ e Validação de: ―Estamos construindo o produto certo?‖ (PRESSMAN, 2006).
2 Capability Maturity Model Integration(CMMI) é um metamodelo de processo abrangente que descreve as
metas, práticas e capacidades específicas que devem estar presentes em um processo de software
maduro.(SOFTWARE ENGINEERING INSTITUTE, 2010)
16
11..22 EESSTTRRUUTTUURRAA DDOO TTRRAABBAALLHHOO
No capítulo um é apresentada uma introdução ao assunto abordado e os objetivos a
serem alcançados pelo trabalho.
No segundo capítulo é feita uma revisão bibliográfica para o entendimento do trabalho,
incluindo temas como teste de software, processos de teste de software, planejamento e
ferramentas de apoio, CMMI e por fim trabalhos correlatos.
O terceiro capítulo apresenta um levantamento de informações com a descrição do
sistema atual e problemas relatados. Apresenta ainda os requisitos principais do problema
tratado neste trabalho, assim como a especificação da ferramenta, a implementação, a
operacionalidade demonstrando o seu uso prático e os resultados e discussões tendo em vista
o resultado da pesquisa de aderência realizada com os usuários.
O quarto capítulo apresenta as conclusões e sugestões de extensão e melhorias deste
trabalho para trabalhos futuros.
17
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo inicia abordando o tema teste de software e suas fases, apresenta a
definição e taxonomia de termos de teste, posteriormente apresenta o tema processo de teste
de software, planejamento e controle, CMMI e por fim, alguns trabalhos correlatos com
objetivos semelhantes aos deste trabalho.
22..11 TTEESSTTEE DDEE SSOOFFTTWWAARREE
Em um livro clássico sobre testes, Myers (1979) fornece uma definição de testes: é um
processo de execução de um programa com a finalidade de encontrar um erro. Myers (1979)
afirma ainda que executar um processo de testes é uma das maneiras de se prevenir ou
detectar erros cometidos ao longo do processo de desenvolvimento.
O teste não é uma atividade que deve ser executada somente a partir da codificação,
dentro do processo de desenvolvimento de software, o teste pode e deve ser aplicado desde as
atividades iniciais, pois, o teste é uma das atividades de garantia de qualidade (ROCHA;
MALDONADO; WEBER, 2001).
Miller (1977 apud PRESSMAN, 2006) relaciona o teste de software à garantia de
qualidade, afirmando que ―a motivação subjacente ao teste de programa é afirmar a qualidade
do software com métodos que podem ser aplicados econômica e efetivamente tanto a sistemas
de grande porte quanto de pequeno porte‖.
A aplicação adequada de métodos e ferramentas, revisões técnicas formais efetivas,
gerência e medição sólida, levam a qualidade que é confirmada durante o teste (PRESSMAN,
2006).
2.1.1 DEFINIÇÃO DA TAXONOMIA DE TERMOS RELACIONADOS A TESTE DE
SOFTWARE
No decorrer deste trabalho, alguns termos são utilizados e precisam estar claros, para
18
facilitar a leitura e o entendimento, evitando assim, interpretações ambíguas. Assim, esta
seção apresenta a definição adotada neste trabalho para estes termos:
a) desenho de teste: apresenta o planejamento para execução dos testes, incluindo o
objetivo, escopo, abordagem de teste a ser seguida, recursos físicos humanos e
cronograma das atividades de teste. Identifica os itens e funcionalidades a serem
testadas, as características dos itens que deverão ser testados, tarefas a serem
realizadas e os riscos associados às atividades de teste (DIAS NETO, 2006);
b) caso de teste: é um documento que estabelece o que será testado, deve conter
cenários, o maior número possível de variações de um requisito. É categorizado no
negócio do software, ou seja, o que ele deve executar (BARTIÉ, 2002);
c) cenários e passos: visualiza um caminho a ser seguido, é uma situação real a ser
testada, descrita passo-a-passo (BARTIÉ, 2002).
Para as atividades de teste apresentadas neste trabalho, foram considerados três papéis
relacionados, são eles (BARTIÉ, 2002):
a) gerente/coordenador de teste: responsável pelo planejamento das atividades,
gerenciamento e validação do ciclo de teste;
b) analista de teste: responsável pela análise e especificação dos testes, incluindo a
elaboração do plano de teste, identificação e especificação dos casos de teste;
c) testador: responsável pela execução dos procedimentos de teste especificados,
registrando as execuções, os resultados encontrados e os incidentes ocorridos.
Outro termo importante no contexto deste trabalho é ―Processo de teste‖, que está
relacionado a um conjunto sistematizado de passos, atividades, papéis e artefatos. Devido a
relevância deste aspecto no escopo deste projeto, a próxima seção aborda este tema em mais
detalhes.
2.1.2 PROCESSO DE TESTE
Ao desenvolver um grande sistema, o teste geralmente envolve vários estágios
(PFLEEGER, 2004). A literatura é ampla a respeito dos estágios do teste, neste trabalho é
adotada a nomenclatura definida por Sommerville (2003) que trata a realização dos testes
incrementalmente, em conjunto com a implementação do sistema.
19
Exceto para pequenos programas, os sistemas não devem ser testados como uma
unidade isolada. Os grandes sistemas são constituídos a partir de subsistemas, que são
construídos a partir de módulos, que são compostos por procedimentos e funções. O processo
de teste deve por conseguinte evoluir em estágios (SOMMERVILLE, 2003). A Figura 1
mostra um processo de testes composto de 5 estágios.
Figura 1– Processo de testes
Abaixo cada estágio é brevemente explicado:
a) teste de unidade: são testados os componentes individuais;
b) teste de módulo: é testado um conjunto mais amplo de procedimentos e funções,
como por exemplo, uma coleção de componentes dependentes relacionados;
c) teste de subsistema: são testados conjuntos de módulos que foram integrados em
subsistemas;
d) teste de sistema: os subsistemas são integrados para constituírem o sistema. este
processo se dedica a testar as interações, verificar se os requisitos funcionais e não
funcionais se cumprem e as propriedades emergentes do sistema;
e) teste de aceitação: estágio final do processo, antes que o sistema seja aceito para
uso operacional. O sistema é testado com dados fornecidos pelo cliente.
A qualidade do produto é relacionada à qualidade do processo de desenvolvimento.
Um processo define, por exemplo, um modelo a ser utilizado durante a construção de um
produto, envolvendo um ciclo de vida, métodos de desenvolvimento e ferramentas que
apóiam a execução do processo (INTHURN, 2001).
Para examinar, entender, controlar e melhorar as atividades, sejam de qualquer área, é
necessário um processo. A utilização de um processo impõem consistência e estrutura a um
conjunto de atividades que norteiam ações. Assim, as principais características de um
processo, no contexto de Engenharia de Software, segundo Pfleeger (2004), são:
20
a) utilização de recursos previamente estabelecidos e sujeitos a um conjunto de
restrições (como cronograma ou orçamento);
b) desenvolvimento, ao longo de suas atividades, de produtos intermediários e
finais, que são os artefatos;
c) podem ser compostos por sub-processos;
d) cada atividade do processo possui um critério de entrada (início) e saída (fim).
O processo de testes busca responder questões sobre o produto, incluindo a análise de
se o produto atende às necessidades para as quais foi idealizado.
Os objetivos do processo de testes de software são diferenciados em relação aos
objetivos do processo de desenvolvimento, principalmente por possuírem medidas
de sucesso diferentes. Enquanto o processo de desenvolvimento busca a construção
de um produto com qualidade, o processo de testes almeja expor as falhas existentes
nesse produto. No entanto, esses processos possuem algo em comum: o desejo de,
ao final, obter um produto com qualidade. (DIAS NETO, 2006).
Segundo Mcgregor e Sykes (2001, apud DIAS NETO, 2006), o processo de testes
possui características próprias. Algumas destas características são:
a) natureza destrutiva: o sucesso do processo de testes indica, de certa forma, o
fracasso do processo de desenvolvimento. Um processo de testes está sempre
―questionando‖ a qualidade do produto, tentando provocar falhas, e não é uma
atividade de construção, por isso é chamado de ―destrutivo‖;
b) papéis e responsabilidades específicos: papéis definidos para os processos de testes
são associados a diferentes perfis de profissionais, devem se preocupar em
selecionar técnicas de teste e desenvolver casos de teste para fazer com que o
sistema falhe. No entanto, os profissionais em computação são, normalmente,
ensinados em cursos ou ensino superior a ―construir‖ programas, e não a ―destruí-
los‖, o que torna necessário um treinamento específico para os profissionais que
atuam na área de teste de software;
c) dependência do processo de desenvolvimento: o processo de testes está sempre
associado a um processo de desenvolvimento, o que consiste em uma dependência.
Cada etapa do processo de desenvolvimento pode ter uma atividade do processo de
testes associada; e
d) ciclos de interação com o processo de desenvolvimento: os processos de testes e de
desenvolvimento devem estar separados, porém estão interligados em um ciclo de
realimentação constante (Figura 2). O processo de testes é responsável pela
geração de um conjunto de casos e procedimentos de teste a partir dos documentos
de análise e projeto gerado no processo de desenvolvimento. E ao final, tenta
21
provocar falhas no software originadas no processo de desenvolvimento. A partir
das falhas reveladas, os desenvolvedores tentam identificar a localização exata do
defeito. Com isso, novamente serão seguidas atividades do processo de
desenvolvimento para tentar corrigir este defeito identificado, e este ciclo é
seguido até a conclusão do produto.
Fonte: DIAS NETO (2006).
Figura 2– Ciclo entre processo de desenvolvimento e de testes
2.1.3 PLANEJAMENTO E CONTROLE DE TESTES
Uma atividade de testes bem organizada pressupõe planejamento. Quando a atividade
de testes é planejada de maneira sistemática e rigorosa, pode ser utilizada como um dos
parâmetros para estimar a confiabilidade e qualidade do software construído (KOSCIANSKI;
SOARES, 2006).
Pfleeger (2004) afirma que, cada etapa do processo de teste deve ser planejada. O
planejamento cuidadoso ajuda a projetar e organizar os testes, de forma a dar segurança de
que os testes estão sendo realizados adequadamente.
Especificamente, deve-se planejar cada uma das etapas de teste (PFLEEGER, 2004):
a) estabelecendo os objetivos do teste: consiste em definir um plano de testes que
determine os critérios a serem avaliados no produto a ser testado, os recursos
necessários e o cronograma para execução dos testes e que tipos de casos de testes
gerar;
b) projetando os casos de teste: consiste em selecionar as técnicas de testes que serão
usadas. Organizar as atividades dos testes, definir objetivos e estratégias, é a chave
para um teste bem sucedido;
22
c) escrevendo os casos de teste: consiste em especificar os casos de teste e definir os
procedimentos de teste. Se não forem representativos e não envolverem todas as
possibilidades de exercícios das funções que demonstram a correção e a validade do
sistema, então, todo o restante do processo de testes é inútil;
d) testando os casos de teste: começa com a revisão dos casos de teste, afim de
verificar se são corretos, viáveis, grau desejado de cobertura e, se demonstram a
funcionalidade pretendida;
e) executando os testes: consiste em executar os casos de teste especificados seguindo
os procedimentos definidos. Somente depois de todas as verificações da etapa
anterior;
f) avaliando os resultados dos testes: consiste em analisar os resultados dos testes
confrontando-os com os resultados esperados.
As atividades de testes devem ser planejadas para suportar a verificação e validação
dos produtos gerados no processo de desenvolvimento, necessitando então, uma infra-
estrutura de trabalho, construída para tal fim (INTHURN, 2001).
O levantamento dos recursos necessários para a execução do processo de teste deve
ser levantado no planejamento. Pode ser executado em conjunto com a fase de levantamento
de requisitos, de acordo ao modelo do ciclo de vida do software. Além disso, é preciso
identificar os indicadores de desempenho e definir a infra-estrutura do sistema de acordo a
arquitetura do software a ser construído. As principais atividades envolvem elaborar um plano
de teste e um cronograma de atividades do processo. Testes bem planejados são capazes de
remover em média 60% dos defeitos de um sistema (INTHURN, 2001).
Dias Neto (2006) afirma que o planejamento dos testes deve fazer parte do
planejamento global do software, sendo o responsável pelo planejamento do processo de
testes (por meio da descrição de prazos, recursos e custos estimados) e pela definição de
estratégias, critérios e técnicas de teste a serem adotados para definição do conjunto de casos
e procedimentos de teste necessários para avaliar o software. Além do planejamento, é preciso
ter controle. Trata-se de um processo contínuo e sistemático de acompanhamento da
eficiência do desenvolvimento em diversos pontos de controle (BARTIÉ, 2002).
O controle das atividades auxilia o monitoramento do progresso do ciclo de teste e o
acesso às informações geradas durante o ciclo. Métricas podem ser usadas para avaliar o progresso em relação ao cronograma planejado e aos objetivos definidos.
Este controle possibilita o acompanhamento do processo, permitindo uma
visibilidade sobre as atividades e com isso, a tomada de ações diante do resultado
das informações e métricas obtidas. No gerenciamento do ciclo de teste, temos ainda
23
as atividades de controle de defeitos. Por meio do controle de defeitos é possível
acompanhar erros e correções, avaliando a qualidade do software com base nos
defeitos cadastrados ao longo do processo. (BASTOS, 2006).
O controle dos testes é responsável por garantir que as informações e atividades
descritas durante o planejamento sejam realizadas conforme o planejado, e em caso de
mudanças, que elas sejam relatadas às pessoas envolvidas nas atividades de teste. O controle
dos testes também é responsável pelo registro dos eventos e incidentes ocorridos durante os
testes e, com isso, possibilita a re-execução dos testes após modificações no produto (DIAS
NETO, 2006).
A realização do planejamento e controle dos testes apresenta diversos benefícios para
uma organização. Entre eles, pode-se citar (DIAS NETO, 2006):
a) papéis e responsabilidades claramente definidos, facilitando o gerenciamento dessa
atividade e conseqüentemente as estimativas de custo, prazo e esforço;
b) objetivos dos testes explícitos, simplificando o entendimento sobre os diferentes
tipos de teste que podem ocorrer em um sistema e suas razões, além de auxiliar a
identificação de possíveis riscos para a atividade;
c) documentação dos testes bem definida, permitindo uma padronização entre os
documentos e facilitando a leitura desses documentos em diferentes projetos, e;
d) facilidade de comunicação entre a equipe de testes e de desenvolvimento, criando
um meio de comunicação formal entre essas equipes, definindo assim uma
linguagem comum entre elas.
Os principais problemas associados aos testes identificados na literatura estão
relacionados a limitações nas atividades de planejamento e controle. No entanto, o sucesso
desta atividade está completamente associado ao seu planejamento e controle. Segundo Dias
Neto (2006) a atividade de controle assegura que os testes planejados sejam monitorados
constantemente e seus resultados sejam registrados.
A indisponibilidade de ferramentas adequadas para a gestão das atividades de teste é
um dos principais problemas enfrentados pelas equipes de teste de software (WEBER, 2001).
Na próxima seção é discutida a importância das ferramentas de apoio no processo de teste.
2.1.3.1 Ferramentas de apoio ao processo de testes
O gerenciamento das informações e das atividades é essencial no ciclo de teste de
24
software. Um gerenciamento eficiente das atividades de teste oferece diversos benefícios para
o processo, dentre eles podem ser citados:
a) definição de papéis e responsabilidades;
b) objetivos e escopo explicitados;
c) tarefas definidas;
d) documentação de teste especificada; e
e) definições e monitoramento para o cumprimento dos objetivos e prazos (DIAS
NETO, 2006).
A gestão do ciclo de teste pode ser auxiliada com a utilização de ferramentas
automatizadas. As ferramentas de teste são o apoio utilizado pelos profissionais da área, elas
cobrem grande parte das atividades e são aplicáveis em todas as etapas do processo de teste,
auxiliando a geração e controle das informações (BASTOS, 2006).
Para um gerenciamento e controle eficiente das atividades de teste, devido à grande
quantidade de informações e atividades que precisam ser gerenciadas, o uso de uma
ferramenta de apoio é essencial (SARTORI, 2005).
As ferramentas que apóiam o processo de planejamento e controle de testes definem
escopo, abordagens, recursos, agendam reuniões e programam atividades. Geralmente estão
apoiadas na coleta inicial de requisitos de software (BARTIÉ, 2002).
Bartié (2002) acrescenta ainda que estas ferramentas auxiliam no processo de
documentação inicial, possibilitando gerar planejamentos padronizados e na elaboração de
estimativas de tempo e custos, além de dimensionar as equipes de acordo com o tempo
disponível. Facilitam o processo de documentação através da utilização de parametrizações e
modelos de documentos. Gerenciam as versões de modelos e possibilitam organizar um
workflow de preparação, elaboração, inspeção e aceite dos documentos.
Para apoiar as atividades de planejamento e controle no processo de testes de software
e em diversos processos, um modelo de referência de processo, como é o caso do CMMI,
surge como mecanismo (DIAS NETO, 2006). Na próxima seção, é apresentada uma descrição
de como o modelo de processo CMMI aborda questões relacionadas às atividades de teste de
software.
25
22..22 CCAAPPAABBIILLIITTYY MMAATTUURRIITTYY MMOODDEELL IINNTTEEGGRRAATTIIOONN ((CCMMMMII))
O mercado de software está cada vez mais competitivo, as organizações que forem
mais preparadas e eficientes no processo de desenvolvimento de software terão mais chances
de sobreviver (COUTO, 2007).
O CMMI é uma abordagem de melhoria de processo (SOFTWARE ENGINEERING
INSTITUTE, 2010). Fornece às organizações orientação para processos de qualidade e um
ponto de referência para avaliar processos atuais. É o modelo de qualidade mais conhecido,
usado e respeitado pela comunidade de Engenharia de Software, afirma Couto (2007).
No CMMI uma organização pode optar por dois enfoques para melhorar seus
processos: capacitação de uma determinada área de processo ou maturidade da organização
como um todo. O suporte para tais enfoques é feitos através da representação por estágio e da
apresentação contínua (COUTO, 2007).
O modelo contínuo descreve um processo em duas dimensões, como ilustrado na
Figura 3.
Fonte: PRESSMAN (2006).
Figura 3 – Representação do processo em duas dimensões
Cada área de processo é avaliada formalmente com base em metas e práticas
específicas, e é classificada com os seguintes níveis de capacitação de acordo com o CMMI
(2006):
26
a) nível 0: Incompleto. A área de processo não é realizada ou não atinge todas as
metas e objetivos estabelecidos pelo CMMI para o nível 1 de capacitação;
b) nível 1: Realizado. Todas as metas específicas da área de processo são satisfeitas.
As tarefas de trabalho necessárias para produzir os produtos de trabalho definidos
estão sendo conduzidas;
c) nível 2: Gerenciado. Todos os critérios do nível 1 foram satisfeitos. Além disso,
todo o trabalho associado à área de processo está de acordo com a política definida
pela organização; todo o pessoal que está fazendo o trabalho tem acesso aos
recursos adequados para fazer o serviço. Os interessados estão ativamente
envolvidos nas áreas de processo, conforme necessário; todas as tarefas e produtos
de trabalho são monitorados, controlados e revisados e são avaliados quanto à
aderência a descrição do processo;
d) nível 3: Definido. Todos os critérios no nível 2 foram alcançados. Além disso, o
processo é feito sob medida para conjunto-padrão de processos da organização, de
acordo com as suas diretrizes quando a fazer coisas sob medida e contribui com
produtos de trabalho, mediações e outras informações de aperfeiçoamento de
processo para o patrimônio de processo da organização;
e) nível 4: Quantitativamente gerido. Todos os critérios do nível 3 foram alcançados.
Além disso, a área de processo é controlada e aperfeiçoada usando medições e
avaliação quantitativa. Objetivos quantitativos para qualidade e desempenho de
processo são estabelecidos e usados como critério na gestão do processo;
f) nível 5: Em Otimização. Todas as capacidades do nível 4 foram alcançadas. Além
disso, a área de processo é adaptada e otimizada usando meios quantitativos
(estatísticos) para satisfazer as alterações de necessidades do cliente e
continuamente aperfeiçoar a eficácia da área de processo em consideração.
O Quadro 1 apresenta as áreas de processo que compõem o modelo CMMI de acordo
com cada nível de maturidade.
27
NÍVEIS DE MATURIDADE ÁREAS DE PROCESSO
CMMI
5 Inovação e Implantação na Organização
Análise e Resolução de Causas
4 Desempenho do Processo Organizacional
Gerência Quantitativa do Processo
3 Analise de Decisão e Resolução
Gerência de Risco
Desenvolvimento de Requisitos
Solução Técnica
Integração do Produto
Instalação do Produto
Liberação do Produto
Verificação
Validação
Definição do Processo Organizacional
Avaliação e Melhoria do Processo Organizacional
Adaptação do Processo para Gerência de Projeto
Treinamento
2 Gerencia de Configuração
Mediação
Garantia de Qualidade
Aquisição
Gerência de Projeto
Gerência de Requisitos Quadro 1 – Estrutura do modelo CMMI
O CMMI define cada área de processo em termos de ―metas específicas‖ e das
―práticas específicas‖ necessárias para atingir tais metas. As metas específicas estabelecem as
características que devem existir se as atividades determinadas por uma área de processo
tiverem de ser efetivadas. As práticas específicas refinam uma meta num conjunto de
atividades relacionadas ao processo (PRESSMAN, 2006).
As atividades de teste de software não possuem um processo (ou área de processo)
específico, ou seja, estão fortemente presentes em outros processos que compõem o modelo.
Uma preocupação mais formal com testes de software é descrita somente a partir do Nível 3
CMMI, por meio dos seguintes processos Verificação e a Validação (DIAS NETO, 2006).
28
2.2.1.1 Verificação
O propósito da Verificação (VER) é assegurar que os produtos de trabalho3
selecionados atendem aos seus requisitos especificados (CMMI, 2006), ou seja, que o artefato
foi produzido da forma ―correta‖ ou especificada.
A área de processo Verificação (VER) envolve o seguinte:
a) preparação da verificação;
b) execução da verificação; e
c) identificação de ação corretiva (CMMI, 2006).
Segundo esta área de processo, um dos métodos para realizar Verificação é por meio
de Testes, e esta área de processo define práticas desde a definição até execução das
atividades de verificação, conforme segue resumo no Quadro 2.
Objetivo Específico 1 Preparar para a Verificação
Prática Específica 1.1 Selecionar os Produtos de Trabalho para Verificação
Prática Específica 1.2 Estabelecer o Ambiente de Verificação
Prática Específica 1.3 Estabelecer Procedimentos e Critérios de Verificação.
Objetivo Específico 2 Realizar Revisão por pares
Prática Específica 2.1 Preparar para Revisão por Pares
Prática Específica 2.2 Realizar Revisão por Pares
Prática Específica 2.3 Analisar Dados de Revisão por Pares
Objetivo Específico 3 Verificar os Produtos de Trabalhos Selecionados
Prática Específica 3.1 Realizar Verificação
Prática Específica 3.2 Analisar Resultados de Verificação e Identificar Ações Corretivas
Quadro 2 – Resumo de metas e práticas do CMMI
2.2.1.2 Validação
O propósito da Validação (VAL) é demonstrar que um produto ou componente de
produto atende ao seu uso pretendido quando colocado em seu ambiente alvo (CMMI, 2006).
3 Do inglês ―work product‖, segundo o CMMI (2006), produto de trabalho é um resultado útil de um processo.
Pode ser arquivo, documento, produto, serviço, descrições de processos, especificações e faturas.
29
Uma das formas de realizar Validação é por meio da realização de tipos específicos de testes.
O objetivo desta Área de Processo está de acordo com os objetivos almejados por Teste de
Aceitação e Teste Beta (realizado no ambiente do usuário).
As atividades de validação utilizam abordagens similares às da verificação (ex: testes,
análises, inspeções, demonstrações ou simulações). No Quadro 3 encontra-se o resumo das
metas e práticas específicas (CMMI, 2006).
Objetivo Específico 1 Preparar para a Verificação
Prática Específica 1.1 Selecionar os Produtos para Validação
Prática Específica 1.2 Estabelecer o Ambiente de Validação
Prática Específica 1.3 Estabelecer Procedimentos e Critérios de Validação
Objetivo Específico 2 Validar o Produto ou os Componentes de Produto
Prática Específica 2.1 Realizar Validação
Prática Específica 2.2 Analisar Resultados de Validação
Objetivo Específico 3 Verificar os Produtos de Trabalhos Selecionados
Prática Específica 3.1 Realizar Verificação
Prática Específica 3.2 Analisar Resultados de Verificação e Identificar Ações Corretivas
Quadro 3 – Resumo de metas e práticas do CMMI - VAL
22..33 TTRRAABBAALLHHOOSS CCOORRRREELLAATTOOSS
Nesta sessão alguns trabalhos com características semelhantes ao da ferramenta são
apresentados.
2.3.1 FERRAMENTA DE SUPORTE AO PLANEJAMENTO DE TESTE FUNCIONAL
DE SOFTWARE A PARTIR DE DIAGRAMAS DE CASOS DE USO
Bianchini (2004) desenvolveu como Trabalho de conclusão de curso uma ferramenta
que tem o objetivo de suporte ao planejamento do teste funcional de software, apartir da
utilização de diagramas de casos de uso da Unified Modeling Language (UML). Possui uma
adaptação de uma ferramenta CASE de código aberto (ArgoUML) para suportar extensões
30
aplicáveis a casos de testes funcionais. Incorpora padrões de documentação da IEEE 829. A
ferramenta foi desenvolvida utilizando a linguagem Object Pascal e componentes do Delphi.
2.3.2 FERRAMENTA WEB DE APOIO AO PLANEJAMENTO E CONTROLE DE
TESTE DE SOFTWARE
O Trabalho de conclusão de curso de Bonecher (2008) é uma ferramenta aplicada à
empresa Dynamix Software. A ferramenta desenvolvida visa auxiliar no planejamento e
controle dos testes de integração, sistema e regressão.
Foi proposto também um novo processo para a empresa, baseado no OpenUP4, a
ferramenta contempla as etapas de planejamento e controle, automatizando as atividades e
artefatos do processo. A ferramenta incorpora padrões da IEEE 829 em seus documentos.
Na implementação utilizou-se a ferramenta Codecharge Studio 3.0, que é a tecnologia
adotada na empresa que usufruirá da ferramenta.
2.3.3 MARAKÁ: INFRA-ESTRUTURA COMPUTACIONAL PARA APOIAR O
PLANEJAMENTO E CONTROLE DOS TESTES DE SOFTWARE
É uma ferramenta apresentada por Dias Neto e Travassos (2006) a qual consiste em
uma infra-estrutura computacional que apóia o planejamento e controle dos testes. Permite o
controle das atividades de testes através de artefatos gerados também no padrão IEEE 829,
são cronogramas, gráficos de acompanhamento e outras informações. Os requisitos da
ferramenta vieram através dos resultados obtidos em um survey5 e da literatura.
Utilizou-se do framework Mambo, tendo assim, todos seus componentes
desenvolvidos na plataforma PHP + MySQL.
4 Segundo Pedri (2008, p. 27 apud BONECHER, 2009) é um processo de desenvolvimento de software open
source que tem como objetivo cobrir um grande conjunto de necessidades de desenvolvimento. Contém o
conjunto mínimo de práticas que ajudam as equipes a serem mais eficazes no desenvolvimento de software.
5 Palavra da língua inglesa que tem por significado coletar dados, análise, pesquisa.
31
3 DESENVOLVIMENTO DA FERRAMENTA
Neste capítulo a ferramenta desenvolvida é descrita, desde o levantamento de
requisitos até a descrição de um exemplo de utilização do ponto de vista do usuário,
apresentando a descrição e relatando os problemas do sistema atual. Mostra as
particularidades técnicas da ferramenta, diagrama de casos de uso, de atividades e classes. Por
fim, são apresentados os resultados obtidos com este trabalho.
33..11 LLEEVVAANNTTAAMMEENNTTOO DDEE IINNFFOORRMMAAÇÇÕÕEESS
Para o desenvolvimento de uma ferramenta que apóie as principais atividades da
equipe de testes da empresa HBSIS Informática, foi preciso coletar informações sobre o
processo atual, suas atividades, principais dificuldades e sugestões.
A HBSIS completa 20 anos de existência, contando atualmente com aproximadamente
200 colaboradores. Possui um software líder no gerenciamento de distribuição de bebidas, e
desenvolve novos produtos, resultados da fábrica de software que tem seu processo de
desenvolvimento bem definido e modelado, por isso, a empresa busca a certificação CMMI
nível 3.
Na qualidade de processo, o teste é uma atividade fundamental para a ascensão ao
nível 3 do modelo, para provar aos novos clientes a qualidade do processo de
desenvolvimento, garantindo assim, fidelidade CMMI (ROCHA; MALDONADO; WEBER,
2001).
Pensando nisso, a HBSIS vem investindo na área de testes. Possui envolvidos no
desenvolvimento dos novos produtos uma equipe com 40 colaboradores, sendo 5 pertencentes
a área de testes, destes, analistas de teste e testadores, em sua grande maioria certificados.
Resumidamente, a área de testes possui as atividades organizadas conforme o processo
ilustrado na Figura 4.
32
Figura 4– Atividades do processo
Embora não descrito no diagrama de atividades, o trabalho da equipe de testes inicia
nas inspeções dos documentos de especificação funcional, que são gerados a partir da
ferramenta Enterprise Architect (EA) e, adaptados para o template6 da empresa em
documentos com extensão .doc (atividade do Desenvolvimento de software). As informações
dos projetos especificados no EA ficam armazenadas em um banco de dados, em uma base do
próprio EA. Cada sistema a ser desenvolvido tem uma base de dados diferente.
O objetivo das inspeções é encontrar problemas e sugerir melhorias. Em paralelo à
isso, a área de testes desenvolve um plano de testes, definindo como atuará nos testes daquele
item funcional que está sendo desenvolvido. O plano de testes, que posteriormente fica anexo
ao documento de desenho de testes possui um escopo sobre os testes do item, definindo
recursos de software e hardware, no geral, possui o fluxo de trabalho desejado para o teste.
Quando o documento de especificação funcional fica pronto, sem precisar de mais inspeções,
o analista de teste começa a criar os casos de testes, atividade denominada ―desenho de
testes‖.
Na atividade desenho de testes, o analista de teste cria cenários para os casos de testes
levantados a partir da especificação funcional, em uma planilha de dados Excel, que deve
seguir um template (em síntese na Figura 5). Cada planilha representa um Caso de Teste.
O documento é formado por 3 planilhas. A primeira contém dados gerais do projeto. A
segunda contém a descrição dos casos de teste, a descrição dos cenários e passos, servindo
também de checklist para a execução. A terceira contém um resumo dos cenários, sem as
descrições, para servir de consulta rápida dos cenários já descritos.
6 Palavra do idioma inglês que significa modelo padrão.
33
Figura 5 – Template da planilha de dados
O template exige atenção dos analistas de teste nos seguintes critérios:
a) cenários e passos enumerados de forma crescente (1, 2, 3, ..., 10, n...);
b) cenários diferenciados por cores para não causar confusão;
c) toda célula deve estar legível, sem cortes ou sobreposições;
d) a planilha de resumo de cenários deve estar sempre atualizada de acordo com a
planilha de descrição de cenários;
e) o documento deve identificar qual caso de uso está sendo testado .
Após a conclusão de toda a especificação dos casos de testes, uma inspeção é
realizada, a fim de encontrar falhas nos cenários, falta de passos ou qualquer incoerência.
Desta inspeção participam: o analista responsável pelo Caso de Teste, outro analista de teste
como inspetor, o testador e o coordenador do produto. Se forem encontrados muitos
problemas na planilha de dados, o analista de teste corrige-os e então é marcada uma nova
inspeção. Se não houver necessidade de atualização, a planilha de dados é armazenada em um
diretório público de um dos servidores da empresa.
O Caso de Teste passa a ser utilizado pelo testador quando a funcionalidade retorna do
desenvolvimento (implementação de software). O testador recebe verbalmente do analista de
teste a localização do documento. Executa os casos de testes e anota no checklist os
34
problemas encontrados. Para cada problema encontrado é criado uma tarefa em um sistema de
controle de atividades, informando o erro e enviada para o responsável pela funcionalidade.
A planilha de dados volta a ser utilizada quando, por algum motivo, é alterado algo no
documento de especificação funcional. O analista de sistemas avisa verbalmente o analista de
teste, e este procura as alterações no novo documento para poder atualizar a planilha de dados,
alterando o caso de teste para ser aderente a nova documentação. Para encontrar o documento
de especificação funcional atualizado, o analista de teste deve solicitar o novo documento de
alguma forma, via e-mail, perguntar onde se encontra o documento atualizado, ou, procurar
por conta própria nos diretórios públicos. Depois de encontrado o documento, o analista de
teste busca na nova especificação os pontos alterados e altera os casos de testes, avisa o
testador verbalmente que houve documentação alterada, e o testador executa os testes
novamente.
3.1.1 PROBLEMAS RELATADOS
Muitas são as reclamações relatadas pela equipe de testes, principalmente em relação à
planilha de dados, que é o instrumento principal no dia-dia da equipe.
O template da planilha exige que o analista de teste perca muito tempo com
formatação, as células devem estar sempre alinhadas, sem cortes ou sobreposições. Os
cenários devem estar com cores padrão alternadas, lembrando que, um cenário pode ter 1 ou n
passos, dificultando assim a escolha de um template pronto de cores da ferramenta Excel. Os
cenários de testes devem ficar enumerados em ordem crescente, por exemplo, se o analista de
teste está descrevendo o cenário número 50 e precisa por algum motivo incluir um cenário
após o cenário de número 20, todos os cenários após o de número 20 terão que ter seus
números refatorados, e isso é feito manualmente. Para evitar o trabalho de renumerar os
cenários quando ocorre uma situação destas, o analista de teste inclui os cenários sempre após
o último já criado, impossibilitando assim a organização do documento por funcionalidade
por exemplo. A desorganização da ordem dos cenários dificulta bastante a execução dos testes
para o testador.
As planilhas de dados, com os casos de testes já descritos, ficam armazenadas em um
diretório público de um servidor da empresa, sem controle algum. Ali ficam os casos de testes
não testados ainda e os já testados também, com o checklist preenchido, possibilitando
35
qualquer pessoa mal intencionada alterar as informações, um banco de dados seguro e
consistente mudaria este cenário.
Os casos de testes surgem a partir de um documento de especificação funcional, com
casos de uso, requisitos, cenários e passos. Não há rastreabilidade entre estes itens, se um
requisito muda, é preciso alterar o Caso de Teste, como saber qual cão de uso mudou? A
ferramenta propõe a rastreabilidade dos casos de testes com casos e uso, facilitando na
manutenção dos casos de testes. Se a rastreabilidade for rápida, acarretará em menos tempo
para documentação e mais tempo para a execução. Facilita o gerenciamento de atualização
dos documentos de testes em relação às mudanças feitas nos requisitos.
O controle dos documentos é feito manualmente pelo envolvido da área de testes, o
que gera situações não confiáveis, visto que, alguém pode alterar o documento de caso de
teste, e até mesmo o resultado da execução, já que a execução é no mesmo documento. Fica
impossível identificar mudanças e atualizações. Mais um ponto importante para a construção
da ferramenta automatizada, a confiabilidade dos dados.
A equipe relata também que não há gerenciamento da fase, as atividades não são
monitoradas, e fica difícil saber quais as responsabilidades de cada profissional. As atividades
da área de testes são dependentes, e como não há controle, às vezes, um Caso de Teste que
está sendo inspecionado ou executado recebe alterações depois destas atividades já terem sido
encaminhadas, os envolvidos não percebem, e acabam utilizando o documento
errado/desatualizado.
A importância de uma ferramenta automatizada de planejamento e controle do
processo de testes está tanto no lado da documentação (Caso de Teste), com a facilidade para
documentar e controlar, quanto no lado do gerenciamento, controlando as atividades,
garantindo o processo seguido corretamente e disponibilizando informações gerenciais.
3.1.2 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
Para chegar à solução desejada, foi feito um estudo sobre as características de algumas
ferramentas, citadas na sessão 2.3, estudado o processo atual da empresa, descrito na sessão
anterior e por fim, entrevista com as pessoas envolvidas no processo de testes da empresa
HBSIS Informática para levantar informações necessárias para o desenvolvimento de casos de
teste.
36
O Quadro 4 apresenta os principais requisitos funcionais (RF) e sua vinculação com o
caso de uso associado.
Requisitos Funcionais Caso de Uso
RF01: A ferramenta deverá permitir ao coordenador e ao analista de teste
manter usuários.
UC01
RF02: A ferramenta deverá permitir ao coordenador e ao analista de teste
manter os sistemas que serão testados.
UC02
RF03: A ferramenta deverá permitir ao coordenador e ao analista de teste
manter os módulos de um sistema.
UC03
RF04: A ferramenta deverá permitir ao analista de teste manter os desenhos de
testes abaixo de um módulo.
UC07
RF05: A ferramenta deverá permitir ao analista de teste manter os casos de
testes.
UC08
RF06: A ferramenta deverá permitir ao testador manter informações e
resultados da execução dos casos de teste.
UC10
RF07: A ferramenta deverá permitir ao coordenador, ao analista de teste e ao
testador emitir um relatório com o Caso de Teste para a inspeção.
UC06
RF08: A ferramenta deverá permitir ao coordenador, ao analista de teste e ao
testador emitir um relatório com os erros encontrados na execução de casos de
teste.
UC04
Quadro 4 - Requisitos funcionais
O Quadro 5 lista os principais requisitos não funcionais (RNF).
37
Requisitos Não Funcionais
RNF01: Deve-se ter controle de acesso.
RNF02: A ferramenta deverá permitir a importação de casos de uso a partir de uma base de
dados do EA.
RNF03: A ferramenta deve disponibilizar uma lista com casos de uso do sistema em teste para
seleção quando é criado um novo Caso de Teste.
RNF04: A ferramenta deve ser desenvolvida na plataforma .Net, utilizando a linguagem C# /
ASP.NET, consequentemente o servidor WEB ―IIS‖.
RNF05: A ferramenta deverá utilizar o banco de dados SQLServer 2005.
RNF06: A ferramenta deve ser acessível via browser IE versão 7 ou superior.
Quadro 5 - Requisitos não funcionais
33..22 EESSPPEECCIIFFIICCAAÇÇÃÃOO
Na sequência é apresentada a especificação da ferramenta Teste-Plan. Os diagramas
foram desenvolvidos na ferramenta EA e na ferramenta DBDesigner, utilizando conceitos da
orientação à objetos e a notação UML.
3.2.1 VISÃO GERAL DA FERRAMENTA TESTE-PLAN
Tendo em vista os problemas relatados na sessão anterior deste trabalho e a
importância dos testes dentro do processo de desenvolvimento de software, este trabalho
propõe uma ferramenta para fornecer apoio automatizado ao planejamento, gerenciamento e
controle do processo de testes da empresa HBSIS Informática, em substituição a planilha de
dados Excel.
É importante ressaltar que a ferramenta não será de automação de testes, mas sim uma
ferramenta que abrange questões relacionadas à definição, organização, controle e
acompanhamento do processo de testes. As execuções manuais, práticas, continuarão sendo
realizadas fora do sistema, de acordo com o processo da empresa, só ocorrerá dentro da
ferramenta a execução dos casos de teste como check-list do testador.
38
A documentação de casos de testes de um sistema é, e continuará sendo a partir de
casos de uso importados do documento de especificação gerado pelo EA, porém, a ferramenta
automatizada facilitará a geração do artefato ―Caso de Teste‖, para execução manual de testes,
no padrão adotado pela empresa, otimizando o tempo investido nesta tarefa, que demanda
grande esforço manual. Ainda em questão de facilidade, para obter a rastreabilidade com estes
casos de uso, a ferramenta se propõe a importá-los de uma base de dados do EA.
Os artefatos envolvidos no processo atual continuam os mesmos, ou seja, o relatório de
caso de teste e relatório de erros.
Com a automatização do processo, a ferramenta deve proporcionar continuamente
meios de suportar cada vez mais volume de testes, sem comprometer os prazos e custos dos
projetos de desenvolvimento, ampliando os benefícios que o processo de testes pode trazer
para a empresa.
3.2.2 FUNCIONAMENTO DA FERRAMENTA
O ciclo começa com o cadastramento do sistema a ser testado e posteriormente de seus
módulos. No cadastro do sistema deve ser informado além de outros dados, o local onde se
encontra a base de dados do EA que a equipe de desenvolvimento mantém as especificações
funcionais.
Para cada demanda a ser testada, é criado um ciclo de testes, que deve ser iniciado por
um analista de teste, esta etapa é denominada ―desenho de testes‖. Sua principal função é o
planejamento do resto do ciclo de testes. A partir dele, os Casos de testes podem ser definidos.
O caso de teste, tem seu ciclo de vida definido por 4 estados diferentes (como mostra a
Figura 6), no desenho de testes deve ser atribuído o profissional que atuará em cada atividade.
39
Figura 6– Diagrama de transição de estados
A partir da criação do Caso de Teste a sequência de atividades tem início, mas, por
enquanto somente a fase de inspeção é habilitada. Com a conclusão da primeira atividade, a
próxima fase é habilitada, as demais serão habilitadas uma por vez, em sequência, sempre
após a conclusão da fase anterior, em cascata.
Cada fase tem um usuário responsável, que só poderá atuar no Caso de Teste quando o
mesmo se encontrar na fase de sua responsabilidade.
Na fase de elaboração, o responsável pode selecionar um dos casos de uso importados
do EA na ferramenta (a ferramenta buscará os casos de uso da base de dados do EA),
especificando os cenários para os testes. Após isso, o Desenho de Teste passa para a fase de
inspeção. Se na fase de inspeção forem encontrados erros por outro profissional, o
responsável pela fase de elaboração altera o caso de teste, corrigindo-os e o fluxo segue.
Quando a especificação passar pela inspeção sem necessidade de alteração, o caso de teste é
encaminhado para o testador designado para a execução. O testador segue os passos do
cenário, documentando quando houver erros e o fluxo segue fora da ferramenta com a criação
de tarefas para o desenvolvimento (como processo atual).
40
As principais atividades da área de testes da HBSIS estão concentradas no
desenvolvimento de casos de teste, que se divide em duas grandes fases, elaboração e
execução. A seguir são apresentados dois diagramas de atividades com os dois grandes fluxos
principais, numa visão geral. A Figura 7 apresenta o fluxo das atividades na ferramenta para a
elaboração do caso de teste, desde os cadastros básicos até a última atividade desta etapa. A
Figura 8 apresenta o fluxo das atividades na ferramenta para a execução dos casos de teste.
41
Figura 7– Fluxo da elaboração de casos de teste
42
Figura 8 – Fluxo da execução de casos de teste
Com isso, a ferramenta armazena, organiza e disponibiliza os principais dados sobre o
andamento do processo de testes, possibilitando acompanhar todas as informações gerenciais,
além das informações específicas da demanda em teste.
3.2.3 DIAGRAMA DE CASO DE USO
Esta seção apresenta na Figura 9 o diagrama de casos de uso da ferramenta. Para o
melhor entendimento do projeto, o detalhamento dos principais casos de uso (UC07, UC08,
UC09, UC10), encontra-se no Apêndice A.
43
uc Diagrama de casos de uso
Analista de
testes
Testador
UC01 - Manter
usuários
UC02 - Manter
sistemas
UC03 - Manter
módulos
UC07 - Manter
Desenho de Testes
UC08 - Manter Caso
de Testes
UC10 - Manter
resultados da
execução
UC06 - Gerar
relatório para
inspeção
UC05 - Efetuar login
UC09 - Importar
Casos de Uso
UC04 - Gerar
relatórios de erros
Coordenador
«extend»
Figura 9– Diagrama de casos de uso
A seguir são apresentados breves comentários sobre cada caso de uso:
a) UC01 – Manter usuários: permite o cadastro e manutenção dos usuários e seus
perfis de acesso à ferramenta;
b) UC02 – Manter sistemas: permite o cadastro e manutenção dos sistemas a serem
testados;
c) UC03 – Manter módulos: permite o cadastro e manutenção de módulos abaixo de
um sistema;
d) UC04: Gerar relatórios de erro: permite gerar um relatório com os erros
44
encontrados após a execução de um caso de teste;
e) UC05: Efetuar login: permite o acesso à ferramenta, adequando as páginas de
acordo com o usuário logado;
f) UC06: Gerar relatório para inspeção: permite gerar um relatório com o caso de
teste;
g) UC07: Manter desenho de testes: permite o cadastro e manutenção de desenhos de
teste abaixo de módulos;
h) UC08: Manter caso de teste: permite o cadastro e manutenção de casos de teste
abaixo de desenhos de teste;
i) UC09: Importar casos de uso: permite buscar de uma base de dados do EA os casos
de uso do sistema;
j) UC10: Manter resultados da execução: permite executar o caso de teste registrando
o sucesso ou falha de passos do cenário.
3.2.4 DIAGRAMA DE CLASSE
Na Figura 10 é apresentado o diagrama de classes na perspectiva conceitual,
descrevendo abstrações em uma situação do mundo real ou do domínio de interesse (CRAIG,
2005).
As classes possuem seu nome e atributos no padrão de codificação adotado na HBSIS.
45
Figura 10– Diagrama de classes conceitual
A função de cada classe de entidade é descrita a seguir:
a) classe Sistema - possui os atributos referentes aos sistemas que serão testados;
b) classe Módulo - possui os atributos referentes aos módulos de um sistema;
c) classe DesenhoTestes - possui os atributos referentes á um Desenho de Teste;
d) classe CasoTeste - possui os atributos referentes aos casos de teste;
e) classe CasoUso - possui os atributos referentes aos casos de uso importados;
f) enumerador SituacaoEnum – tipo definido (enumeração, constantes do tipo inteiros
nomeadas), com valores pré-estabelecidos para as situações de um Caso de Teste;
g) classe Pessoa - classe que possui os atributos referentes aos usuários do sistema;
h) enumerador PapelEnum: tipo definido (enumeração, constantes do tipo inteiros
nomeadas), com valores pré-estabelecidos para o papel de um usuário;
i) classe Cenario: possui os atributos referentes aos cenários de casos de testes;
j) classe Passos: possui os atributos referentes aos passos de um cenário de testes.
46
3.2.5 MODELO ENTIDADE RELACIONAMENTO
Para representar os objetos no banco de dados, foi utilizada a ferramenta Microsoft
SQL Server Management Studio. Esta ferramenta permite que alterações realizadas no
diagrama sejam em tempo real aplicadas nas entidades da base de dados, assim, não é
necessário criar ou executar scripts para manutenção dos artefatos.
A seguir, na Figura 11 é apresentado o diagrama de entidade relacionamento. Pode-se
observar as ligações entre as entidades a partir das chaves estrangeiras, que aparece nas
ligações e, verificar a cardinalidade.
Figura 11 – Diagrama Entidade Relacionamento
33..33 IIMMPPLLEEMMEENNTTAAÇÇÃÃOO
Nesta sessão é apresentado o detalhamento da implementação da ferramenta. O tópico
47
inicial identifica técnicas e ferramentas utilizadas. O tópico seguinte apresenta um estudo de
caso do ponto de vista do usuário, destacando a operacionalidade da ferramenta. O último
tópico mostra os resultados obtidos.
3.3.1 TÉCNICAS E FERRAMENTAS UTILIZADAS
A ferramenta foi desenvolvida em linguagem C# / ASP.NET, sobre a plataforma
Microsoft .Net, com a versão 3.5 do framework. Para codificação foi utilizada a IDE
Microsoft Visual Studio 2008.
Para o desenho das páginas, utilizou-se a tecnologia ASP.NET, da Microsoft para
aplicações WEB. É um componente do IIS que permite através de uma linguagem de
programação integrada ao framework .Net criar páginas dinâmicas para a WEB
(MICROSOFT, 2010). A Figura 12 e a Figura 13 mostram a construção de uma página
ASPX, desenvolvida com ASP.NET, para montar a tela de pesquisa de pessoas.
Figura 12 – Montagem da tela de pesquisa de pessoas, filtros da tela
48
Figura 13 – Montagem da tela de pesquisa de pessoas, listagem da tela
A codificação da ferramenta foi feita em C# (C Sharp), que é uma linguagem de
programação orientada a objetos. Foi desenvolvida pela Microsoft como parte da plataforma
.Net. Sua sintaxe foi baseada na linguagem C++, mas possui influência em outras linguagens
de programação, como por exemplo Delphi e Java (MICROSOFT, 2010).
A Figura 14 mostra a codificação para preencher a listagem de pessoas na tela de
pesquisa de pessoas, mostrada acima. A mesma lógica é utilizada para todas as telas de
pesquisas que contém listagens e filtros.
49
Figura 14 – Método que popula a listagem de pessoas
Para o desenvolvimento dos relatórios, foi utilizada a ferramenta ReportViewer, que
trabalha com Report Definition Language (RDL), um padrão proposto pela Microsoft para
definição de relatórios. A ferramenta permite a geração dos relatórios no formato HTML,
PDF, Excel e impressão direta (MICROSOFT, 2010). Para seu uso na ferramenta, gerar no
formato HTML e possibilitar a exportação para PDF e Excel satisfaz a necessidade.
A Figura 15 ilustra o relatório em HTML e mostra a exportação para Excel.
50
Figura 15 – Relatório gerado em HTML e exportado para Excel
O relatório é formado por um dataset7 e um rdlc (arquivo de relatório), como mostram
as Figuras 16 e 17 para a montagem do relatório de inspeção na ferramenta.
Figura 16 – Dataset do relatório
7 É uma tabela de dados em memória, são várias tabelas relacionadas, uma dentro da outra (MICROSOFT,
2010).
51
Figura 17 – Arquivo de relatório
Utilizando o dataset e o arquivo de relatório, foi montada uma página ASPX para
exibição do relatório, onde foi utilizado o controle ReportViewer. A Figura 18 mostra a
montagem da tela e a Figura 19 mostra a codificação do relatório.
Figura 18 – Montagem da tela do relatório de inspeção
52
Figura 19 – Codificação do relatório
Uma das principais preocupações no desenvolvimento desta ferramenta foi a
interatividade da tela de Caso de Teste, onde estão concentradas as principais atividades da
área de testes.
A tela precisa disponibilizar ao usuário um grid com cenários e passos, aninhados.
Onde, a partir de um cenário, é possível ver seu detalhamento, e abaixo dele, uma lista com
passos, botões para criar passos, alterar, excluir e executar. O framework utilizado não
disponibiliza nenhum componente que suporte esta arquitetura de tela, o mais próximo e
popular é o DataGrid, que é um controle que exibe dados em forma de lista, com paginação e
possível classificação, porém, é adequado apenas para mostrar tabelas únicas, sem relação pai
e filho. Foi então investido tempo para a pesquisa de componentes fora o framework, mas que
executem na plataforma .NET.
No website de um Consultor da Microsoft da Alemanha, que trabalha em grandes
projetos .NET foi encontrado um componente sem licença para uso, que suporta a arquitetura
de tela desejada. Seu nome é Denis Bauer e ele criou um componente personalizado chamado
HierardGrid que herda do DataGrid padrão e ao mesmo tempo possibilita mostrar relações
pais e filhos (BAUER, 2010).
Bauer (2010) explica que o HierardGrid recebe um dataset que contém as relações
entre as tabelas pai e filho. Enquanto ocorre a interação na tabela pai são verificadas as tabelas
53
relacionadas para incluir linhas como filhos para este pai, se for encontrado, carrega
dinamicamente um modelo para as linhas filhos.
O modelo é processado de forma invisível para o HierarColumn, que é um tipo de
coluna personalizada, e quando o usuário clica no ícone do plus, o modelo de conteúdo é
copiado através de Java Script em uma linha de tabela recém-criada
A Figura 20 mostra um exemplo encontrado em seu site do HierarGrid, mostando pais,
filhos e o ícone plus que exibe/esconde filhos.
Fonte: BAUER (2010)
Figura 20 – Exemplo do HierardGrid com pais e filhos
A seguir, a Figura 21 apresenta o resultado do uso do HierarGrid na ferramenta.
Mostra cenários, como pais, seu detalhamento e abaixo os passos, como filhos.
54
Figura 21 – Cenários com passos
A seguir, na Figura 22 é apresentado o diagrama de sequência da abertura da tela de
casos de teste, onde é montado o HierarGrid. Os nomes dos métodos seguem o padrão de
desenvolvimento de ferramentas internas da HBSIS Informática.
55
Figura 22 – Diagrama de sequência para abertura da tela com HierardGrid
Na sequência são resumidamente explicados os métodos envolvidos na montagem do
grid e apresentados trechos de código fonte.
O método denominado MontarGrid é o método que entra em contato com os demais e
recebe por fim um dataset com dados, mandando para o grid na tela, e informando para o
componente qual das tabelas relacionadas no dataset é a tabela pai (Figura 23).
56
Figura 23 – Método MontarGridCenarios
O método CarregarDataset que manda um dataset para o método citado anteriormente
é quem busca os dados e popula as tabelas dentro do dataset, informando os campos do grid.
A Figura 24 mostra trechos do método, a mesma lógica utilizada para buscar os cenários
aplica-se para a busca dos passos. Ao final do método, as duas tabelas de dados são inseridas
no dataset e é chamado o método que cria o relacionamento entre as duas.
Figura 24 – Método CarregarDataset
57
A Figura 25 apresenta o método RelacionarTabelas que cria o relacionamento entre as
tabelas de cenários e passos, através da chave estrangeira que se encontra na tabela de passos
que aponta para a tabela de cenários.
Figura 25 – Método RelacionarTabelas
Na tela de casos de teste é disponibilizado um combo com os casos de uso do sistema
em teste, e para isso, a ferramenta disponibiliza uma tela para importação de casos de uso do
EA (Enterprise Architect). O EA é a ferramenta utilizada pela HBSIS Informática para
projetar sistemas, então toda a especificação é feita através desta ferramenta. A empresa
utiliza-se de uma versão corporativa do EA, centralizando todas as informações através do
banco de dados do EA.
Com as informações centralizadas, a ferramenta Teste-Plan acessa o banco de dados do
EA e busca na tabela ―t_object‖ os casos de uso, trazendo para a tabela ―casouso‖ da
ferramenta Teste-Plan as informações.
As classes codificadas para desenvolver a ferramenta foram divididas em 3 grandes
grupos, o das classes modelos, que contém as classes das entidades, o das classes de acesso à
dados, que fazem o acesso a dados a partir de uma biblioteca desenvolvida em generics para
padronizar as classes de acesso à dados especiliazadas, e por fim, as classes das interfaces que
é a codificação das páginas ASPX, dentro de um WebSite. Com a ferramenta Visual Studio
2008 é possível identificar estas bibliotecas e o WebSite a partir da ―solução‖, que é um
pacote com todos os fontes envolvidos. A Figura 26 mostra esta solução.
58
Figura 26 – Solução da implementação
Generics são coleções fortemente tipadas, de modo que somente um tipo de dado
pertença á coleção. Coleções generics auxiliam na programação, pois fica fácil identificar o
que há na coleção e não é preciso converter tipo ao retirar um item da coleção. Trabalha-se
com objetos, trafegam objetos, não mais datatables8ou datasets (MICROSOFT, 2010).
As principais coleções genéricas são (MACORATTI, 2010):
a) List(Of T) - Representa uma lista fortemente tipada de objetos que podem ser
acessados através de um índice. Fornece os métodos Search, Sort e efetua a
manipulação da lista;
b) LinkdeList(Of T) - Organiza os itens na forma de uma lista duplamente ligada;
c) Stack(Of T) - Organiza os itens na forma de um pilha.(LIFO - last-in first-out);
d) SortedList(Of TKey, TValue) - Representa uma coleção de pares representados por
chave/valor que são ordenados pela chave com base na implementação de
59
System.Collections.Generic.IComparable associada;
e) SortedDictionary(Of TKey, TValue) - Representa uma coleção de pares
representados por chave/valor que são ordenados pela chave;
f) Queue(Of T) - Organiza os itens na forma de uma fila.(FIFO - first-in firs-out).
No desenvolvimento da ferramenta utilizou-se a coleção genérica ―List(Of T)‖, onde T
é cada tipo de classe modelo, ou seja, representa cada entidade. Na Figura 27 é apresentado na
um exemplo de manipulação de coleção genérica. A coleção é da classe ModuloModel, que é a
classe modelo que representa a entidade Módulo na ferramenta.
Figura 27 – Manipulação de coleção genérica
Além das coleções, o Generics foi utilizado também para montar uma biblioteca de
acesso à dados para facilitar e padronizar as classes de acesso a dados especializadas. A
seguir, na Figura 28 é apresentado o diagrama das classes de acesso à dados. O diagrama foi
gerado na ferramenta Visual Studio 2008 e reflete a realidade da implementação.
8 Conjunto de linhas e colunas (MICROSOFT, 2010).
60
Figura 28 – Diagrama de classes da biblioteca de acesso à dados
Abaixo uma breve explicação sobre as classes e suas funções:
a) AcessoDadosUtilitario: classe responsável por buscar a string de conexão
definida para a classe informada;
b) Conexoes: Classe que mantém as conexões e transações ativas;
c) AcessoDadosBase: Cria comandos, conexões, parâmetros, valida números de
parâmetros em um comando;
d) AcessoDadosExecucao: Classe que herda da classe AcessoDadosBase
manipulando e executando comandos SQL com o banco de dados. Nesta classe
pode-se executar um comando em forma de texto SQL, executar uma
StoredProcedure, o retorno vem de várias formas diferentes para facilitar, como
por exemplo, um datatable, uma lista ou um sinal;
e) AcessoDados: classe abstrata que em seu construtor configura a string de conexão
de acordo com o tipo da classe, instanciando a classe de execução
AcessoDadosExecucao;
f) ObjetoAcessoDados: Classe abstrata que herda da classe AcessoDados, para
garantir a string de conexão de acordo com o tipo de classe. Esta classe possui as
assinaturas dos métodos base para cada classe de acesso à dados, como por
exemplo, o método Insert, Update, Delete e Select. A classe recebe um tipo
genérico, como mostra a Figura 29 abaixo. É desta classe que as classes de acesso
61
à dados especializadas herdam.
Figura 29 – Classe ObjetoAcessoDados
A seguir, na Figura 30, pode-se observar no diagrama de classes de objetos de acesso à
dados, algumas classes especializadas de acesso à dados herdando da classe
ObjetoAcessoDados, mostrando também, seus métodos, os referentes à classe herdada e os
demais conforme necessidade. O diagrama foi gerado na ferramenta Visual Studio 2008.
62
Figura 30 – Diagrama de classes especializadas de acesso á dados
Para melhor entendimento da relação entre as classes, a seguir é apresentado um
diagrama de sequência (Figura 31), mostrando a montagem da tela de Sistemas.
63
Figura 31 – Diagrama de sequência para montagem da tela de Sistemas
O diagrama da Figura 31 apresenta a classe Seguranca.cs, que, como mostra a
Figura 32, é uma classe que herda da Classe Page (classe que representa uma página WEB na
tecnologia). A classe Page é a classe que os fontes das páginas ASPX devem herdar. No
desenvolvimento da ferramenta criou-se uma classe de segurança que trata questões de
autenticação e tratamento de perfil, para que todas as outras páginas do sistema herdem desta
e possam utilizar seus métodos de segurança, a classe Seguranca herda da classe Page. A
Figura 32 mostra uma página da ferramenta, no caso a página Sistema e sua relação com a
página de Segurança.
64
Figura 32 – Exemplo de relacionamento da classe Seguranca com uma página
A ferramenta foi desenvolvida utilizando o conceito de herança visual, chamada no
ASP.NET de Master Page.
Com uma Master Page é possível desenvolver uma página padrão que será utilizada
em todo o site, ou seja, é como se fosse uma página default contendo menus, cabeçalhos e
rodapés. Qualquer outra página criada pode herdar a Master Page, nela é possível apenas
utilizar a área que não seja a da Master Page e sim da página que está sendo criada, e em
tempo de execução o .NET monta as duas páginas em apenas uma.
A grande vantagem de utilizar este recurso é que não será preciso dar manutenção em
diversas páginas, caso precise mudar, basta alterar em um único ponto e todas as mudanças
são enxergadas imediatamente nas demais páginas que utilizam a Master Page alterada
(MICROSOFT, 2010).
Na ferramenta, utilizou-se Master Page para criar o layout padrão, com cores e logo da
HBSIS Informática, o cabeçalho e os menus, laterais e superiores. A Figura 33 mostra a
Master Page criada e a Figura 34 mostra a Master Page sendo utilizada em outra página, no
caso, na página de desenho de teste.
65
Figura 33 – Criação da Master Page
Figura 34 – Criação da tela de Desenhos de teste, utilizando Master Page
66
Na seção a seguir, pode-se observar o resultado da implementação.
3.3.2 OPERACIONALIDADE DA IMPLEMENTAÇÃO
Esta seção apresenta a funcionalidade e operacionalidade da ferramenta. É apresentado
um estudo de caso, do ponto de vista dos usuários (equipe de teste), com o objetivo de
exemplificar as funções básicas da ferramenta.
Para demonstrar, é utilizado um contexto semelhante ao real, criando um caso de teste
para uma determinada especificação funcional.
3.3.2.1 Login
Para acessar a ferramenta, é preciso possuir um usuário e uma senha cadastrados no
banco de dados com um perfil. A Figura 35 apresenta a tela de Login da ferramenta.
Figura 35 – Tela de Login
Caso o usuário ou a senha sejam inválidos, é exibida a seguinte mensagem: ―Usuário
inválido.‖
Após efetuar o Login no sistema, o usuário é direcionado à página de início da
67
ferramenta, que apresenta os menus disponíveis, como mostra a Figura 36.
Figura 36 – Tela de início
3.3.2.2 Navegabilidade
A navegabilidade da ferramenta segue o padrão de outras ferramentas da HBSIS
Informática, sendo:
a) Menu lateral com cabeçalho (Figura 37 fragmento A);
b) Menu superior (Figura 37 fragmento B);
c) Identificação do usuário logado no canto superior direito da tela junto com logout
(Figura 37 fragmento C);
d) Em telas de pesquisa, existe um filtro superior, botão limpar filtro e botão
pesquisar logo abaixo (Figura 38 fragmento A);
e) Em telas de pesquisa existe um grid paginado, onde a primeira coluna contém o
botão alterar, que seleciona o item e redirecionada para a tela de detalhes do item
selecionado (Figura 38 fragmento B);
f) Em telas de pesquisa, o grid possui como última coluna um botão excluir, sendo
visível somente para usuários com papel diferente de testador (Figura 38
68
fragmento C);
g) Em telas de pesquisa, possui abaixo do grid, um botão de Novo, que redirecionada
para a página de criação do item, visível somente para usuários com perfil
diferente de testador (Figura 38 fragmento D);
h) Em telas de detalhes, sendo criação ou alteração (vindas do botão de alterar de
algum grid ou botão Novo de tela de pesquisa) mostra o detalhe do item
selecionado/criado, com todos os campos pertencentes à entidade (Figura 39
fragmento A);
i) Em telas de detalhes existe o botão Salvar, que salva o item que está sendo
alterado ou criado, o botão Voltar, que volta para a tela anterior de pesquisa e,
quando pertinente, um botão que leva aos filhos, como por exemplo, de um detalhe
de sistema, apresenta o botão Módulos em alterações, que redirecionada para a
página de pesquisa de módulos, mostrando os módulos do sistema (Figura 39
fragmento B);
j) Em telas de detalhe, existe controle de campos obrigatórios, sendo impossível
prosseguir sem ter todos os campos obrigatórios preenchidos (Figura 39 fragmento
C).
Figura 37 – Navegabilidade menus
69
Figura 38 – Navegabilidade páginas de pesquisa
Figura 39 – Navegabilidade detalhes
70
3.3.2.3 Cadastros básicos
Considera-se cadastro básico para utilizar a ferramenta o cadastro de pessoas, sistemas
e módulos. O Apêndice B apresenta as telas de cadastros básicos. Para continuar a
demonstração deste estudo de caso, pressupõe-se que os cadastros básicos já estejam
efetuados.
3.3.2.4 Importação de casos de uso
A ferramenta disponibiliza no link Casos de Uso no menu lateral a opção de importar
casos de uso e suas descrições, a partir de uma base de dados do EA.
Ao clicar no link mencionado, a tela a seguir é apresentada (Figura 40), mostrando os
casos de uso já importando na ferramenta, podendo filtrar por nome do caso de uso ou pelo
sistema ao qual o mesmo pertence.
Figura 40 – Tela de pesquisa de casos de uso
Para importar novos casos de uso na ferramenta, basta clicar no botão Importar, o
sistema redirecionará para a tela de importação de casos de uso, como mostra a Figura 41.
71
Figura 41 – Importar casos de uso
Selecionando o sistema desejado e clicando no botão Importar, a ferramenta irá até a
base de dados do EA cadastrada para o sistema selecionado e buscará os casos de uso,
mostrando a mensagem conforme a Figura 42, e somente após a confirmação os casos de uso
serão importados para o banco de dados da ferramenta.
Figura 42 - Mensagem de confirmação de importação de casos de uso
Após a confirmação, a ferramenta mostra os casos de uso importados, da mesma forma
que mostra a Figura 40.
72
Ao criar novos casos de uso no EA ou alterá-los, basta importar novamente que a
ferramenta atualiza-os, como mostra a Figura 43 e 44.
Figura 43 – Casos de uso no EA e importados na ferramenta
73
Figura 44 – Novo caso de uso no EA e importado na ferramenta
Agora, os casos de uso já estão disponíveis para serem utilizados nos casos de teste.
No cadastro de casos de teste, os casos de uso que foram importados são apresentados em um
combo para seleção de acordo com o sistema selecionado (Figura 45).
74
Figura 45 – Casos de uso importados exibidos na tela de caso de teste
3.3.2.5 Fluxo de testes
O fluxo de testes inicia a partir do planejamento descrito em um desenho de testes, que
está ligado a um módulo de um sistema em testes. Abaixo de um desenho de testes são
desenvolvidos seus Casos de teste, que possuem cenários e passos, e posteriormente são
inspecionados e executados.
As visões das telas da ferramenta são alteradas de acordo com o papel do usuário
logado. Se o usuário logado é um analista de testes, ou um coordenador, em telas de pesquisa
sempre estará visível a coluna de exclusão e o botão Novo. Em telas de detalhamentos, o
usuário com o papel de analista de testes ou coordenador poderá alterar o item pois, o botão
Salvar será visível, diferente da visão do testador, que não tem acesso a coluna de exclusão
dos grids nem aos botões Novo e Salvar em telas de pesquisa e detalhamento.
No menu lateral encontra-se o link Desenhos de teste, que redirecionada para a tela de
desenhos de testes. Ao logar na ferramenta com um usuário que tenha o papel de Analista, a
visão da tela de desenho de testes é a seguinte (Figura 46).
75
Figura 46 – Pesquisa de desenhos de teste na visão de um analista de teste
A visão da tela para um usuário logado que tenha o papel de testador é apresentada na
Figura 47.
Figura 47 – Pesquisa de desenhos de testes na visão de um testador
Na tela de desenhos de teste (Figura 46) há a possibilidade de filtrar as informações
apresentadas no grid. Pode-se filtrar por Nome do desenho, Sistema que o desenho pertence,
Módulo que o desenho pertence e pela Situação que o desenho se encontra (concluído ou
não).
Filtrando por sistema, por exemplo, pelo sistema de nome ―HBPrever‖ o resultado é
76
mostrado na Figura 48, na visão de um analista de testes.
Figura 48 – Pesquisa de desenhos de teste filtrando por sistema na visão de um analista
Com um analista de testes logado, ao clicar em excluir um dos itens exibidos na grid,
sendo um item que possui casos de testes abaixo dele, será exibida a mensagem conforme
mostra Figura 49. O desenho não pode ser excluído.
Figura 49 – Tentativa de exclusão de desenho de testes que possui casos de teste
Ainda com um usuário de papel analista de testes logado, ao clicar no botão Novo, a
ferramenta irá redirecionar para a página de criação de um novo desenho de teste (Figura 50).
A tela apresenta todos os campos pertinentes a um caso de teste, sendo alguns
obrigatórios. Os campos obrigatórios são identificados com um ―*‖ antes da legenda do
77
campo.
Figura 50 – Criação de desenho de teste
Após preencher os campos e clicar em Salvar, se algum dos campos obrigatórios não
foram preenchidos, a ferramenta solicitará o preenchimento do campo obrigatório e não será
permitido prosseguir (Figura 51).
78
Figura 51 – Campo obrigatório cadastro de desenho de testes
Após preencher o campo obrigatório faltante, a seguinte mensagem será apresentada
(Figura 52):
Figura 52 – Mensagem desenho de teste salvo com sucesso
79
Após salvar o novo desenho de testes, um novo botão ganha visibilidade na tela: Casos
de teste. Este botão redireciona para a tela de casos de teste, trazendo o grid de casos de teste
já filtrado por desenho de teste. Como o desenho de testes foi criado anteriormente, ainda não
há casos de testes atrelado à ele, como mostra a Figura 53.
Figura 53 – Pesquisa de casos de teste, filtrando por desenho de teste
Para criar um novo caso de teste, deve-se acionar o botão Novo. Este botão levará a
tela de criação de caso de teste (Figura 54).
Figura 54 – Criação de caso de teste
Após preencher os campos obrigatórios e clicar em Salvar, o novo caso de teste foi
criado, a ferramenta apresentará na tela dois novos botões na parte superior:
a) enviar para inspeção; e
b) enviar para execução.
Será habilitado um grid na tela, o grid de cenários e passos. A última coluna do grid
80
representa em cores se todos os passos daquele cenário foram executados ou não, mostrando
verde se sim e amarelo se não, conforme informação.
É criado automaticamente, com o intuito de auxiliar o usuário, cenário default e um
passo default para este cenário, com instruções de como proceder para criar os cenários e
passos. Abaixo do novo grid, um botão denominado Novo cenário (Figura 55). A situação do
caso de teste no momento é Em Elaboração, pois, ainda está sendo alterado, sendo sua
primeira situação.
Figura 55 – Caso de teste com cenário default
Ao expandir o grid de cenários e passos, pode-se verificar o seu detalhamento e um
botão para salvar as alterações no cenário. Abaixo, tem-se um grid com os passos
pertencentes ao cenário, o grid possui um passo default, com a opção de alterar ou excluir, e
um botão para criar novos passos, denominado Novo Passo (Figura 56).
O botão Enviar para inspeção ―congela‖ o caso de teste para ir para inspeção, não será
mais possível alterá-lo, e sua situação mudará para Em Inspeção.
O botão Enviar para execução altera a situação do caso de teste para Em Execução, e
só pode acontecer se o caso de teste já foi inspecionado. Quando o caso de teste está Em
Execução somente o testador poderá alterá-lo, podendo alterar somente o resultado dos
passos.
81
Figura 56 – Detalhe cenário com passos
O grid de passos apresenta as informações pertinentes à um passo, na primeira coluna
um botão de alterar, na antepenúltima um botão de excluir e na última uma indicação do
sucesso do passo (se na execução passou ou não). Como o passo não foi executado pelo
testador ainda, a última coluna fica com um ponto de interrogação simbolizando que o passo
ainda está aguardando ser executado.
Ao clicar no botão de alterar do grid de passos, a ferramenta apresenta o detalhe do
passo (Figura 57). O detalhe do passo oferece dois botões para alterar facilmente a ordem do
passo, a flecha para cima aumenta a ordem e a flecha para baixo diminui a ordem do
passo.
82
Figura 57 – Detalhe do passo selecionado
Após alterar o passo, para salvar a alteração deve-se acionar o botão ―Salvar passo‖,
ou, para ignorar a alteração, acionar o ―Cancelar‖. Para criar um novo passo, basta clicar em
―Novo Passo‖. Será habilitada a área para criar novo passo, que é igual a da alteração, porém,
a ferramenta sugere a ordem do novo passo.
Para criar um novo cenário, deve-se acionar o botão ―Novo cenário‖ abaixo do grid de
cenários e passos. O botão habilita uma área para criação de um novo cenário (Figura 58),
após preencher os campos e clicar em Salvar, o novo cenário vai para o grid de cenários e
passos (Figura 59).
83
Figura 58 – Novo cenário
Figura 59 – Cenário salvo
O caso de teste ainda está em elaboração, se um testador acessar este caso de teste, a
visão que ele terá será a seguinte (Figura 58 e Figura 59):
84
Figura 60 – Caso de teste em elaboração – visão do testador
Figura 61 – Cenários e passos em elaboração – visão testador
Após o término da confecção do caso de teste, isto é, ter incluído todos os passos e
cenários do caso de teste, o analista de teste deve enviar o caso de teste para inspeção.
Como citado anteriormente, o caso de teste que está em elaboração e vai para inspeção
fica inacessível a qualquer usuário, não é mais possível alterar o caso de teste enquanto o
mesmo estiver em inspeção.
Se o caso de teste ainda não passou por inspeção, e o analista de teste responsável
tentar enviar o caso de teste para execução (Figura 62 fragmento A), ou seja, passar de ―Em
Elaboração‖ direto para ―Em Execução‖, a ferramenta não permitirá, exibindo uma nova
85
mensagem logo em seguida (Figura 62 fragmento B).
Figura 62 – Controle de inspeção
Agora que o caso de teste está ―Em Inspeção‖, a ferramenta disponibiliza o relatório
com o caso de teste para a reunião de inspeção, podendo ser exportado para Excel ou PDF,
conforme Figura 63.
O link para geração de relatórios se encontra no menu lateral, denominado ―Inspeção‖,
abaixo de Relatórios. O relatório deve ser filtrado por caso de teste.
Figura 63 – Relatório de inspeção
86
Quando o caso de uso é inspecionado, o analista de testes tem a possibilidade de voltar
o caso de teste para ―Em Elaboração‖ (Figura 63 fragmento A), para fazer alterações
necessárias solicitadas pela inspeção, ou então, liberar o caso de teste para a execução (Figura
63 fragmento B), sem possibilidade de alterações, em ambos os casos o analista precisa dar
seu aval confirmando as mensagens.
Figura 64 – Aval analista de teste
Após enviar o caso de teste para execução, o analista responsável não consegue mais
alterar as informações, ficando o caso de teste em situação de ―Em Execução‖ e sob a
responsabilidade do testador cadastrado no desenho de teste.
Em casos de teste com situação ―Em Execução‖ só podem atuar os testadores, porém,
podendo alterar somente a informação de sucesso ou fracasso dos passos do cenário,
conforme Figura 65.
87
Figura 65 – Execução de casos testes – visão testador
Ao invalidar um passo, o testador tem a opção de descrever o motivo do fracasso do
teste (Figura 66). Esta mensagem pode ser recuperada quando tentar invalidar novamente.
Figura 66 – Invalidando passo
As mensagens descritas nas invalidações dos passos são as mesmas que aparecerão no
relatório de erros conforme mostra a Figura 67. O relatório de erros foi filtrado pelo caso de
teste CT_0001, conforme exemplo.
88
Figura 67 – Relatório de erros
33..44 RREESSUULLTTAADDOOSS EE DDIISSCCUUSSSSÃÃOO
A ferramenta Teste-Plan foi desenvolvida visando atender as necessidades da empresa
HBSIS Informática em relação ao planejamento e controle do processo de teste, porém, o
estudo realizado sobre CMMI, bem como o processo proposto pela empresa para atender ao
CMMI e os trabalhos correlatos significaram muito para seu desenvolvimento. Com o estudo
foi possível verificar pontos fortes e fracos de cada trabalho e itens indispensáveis para a
ferramenta.
Comparando com os trabalhos correlatos apresentados, a ferramenta pode ser
diretamente comparada com a estrutura Maraká, salvo no quesito processo. A seguir é
apresentada uma breve comparação técnica (Quadro 6).
89
BIANCHINI
(2004)
BONECHER
(2008)
DIAS NETO
(2006) TESTE-PLAN
Plataforma Winforms WEB WEB WEB
Linguagem Object Pascal JSP PHP C# ASP.NET
Baseado em
ISO/IEC
12207
OPENUP +
Processo
Dynamix
IEEE/ CMMI
/PMBOK
Processo HBSIS
+ CMMI
Gera casos de teste Não Sim Não Sim
Relatório de erros Sim Sim Sim Sim
Integração com
outras ferramentas ArgoUML Não Não
Enterprise
Architect Quadro 6 – Quadro comparativo.
O objetivo da ferramenta é ser aderente e automatizar o processo proposto pela
empresa HBSIS Informática, sendo importante observar que a aderência do processo da
empresa ao CMMI não é o foco deste trabalho. O Quadro 7 mostra a aderência da ferramenta
ao processo atual, focando nos artefatos produzidos.
Plano de testes
Como atualmente é um documento anexo ao Desenho de teste, o
planejamento na ferramenta fica no próprio Desenho de teste, que é criado
antes do caso de teste, ou seja, todo o planejamento, quando criado um
caso de teste já está descrito. Aqui são designados os envolvidos no ciclo
de testes para este Desenho, a ferramenta atuará designando as
responsabilidades para estes envolvidos planejados, conforme o
andamento do Caso de teste. Tela de desenho de teste, Figura 48.
Desenho de teste
Onde os casos de teste são criados, contendo cenários e passos. Na
ferramenta, após criar um Desenho de teste e descrever o planejamento,
pode-se então criar o chamado "Caso de Teste" que possui cenários e
passos, dando origem ao artefato levado para inspeções e para execução
denominado "Caso de Teste". Há a opção de gerar um relatório com o
Caso de teste para a Inspeção. O Caso de teste é controlado por status e
perfil do usuário logado, alterando seu status automaticamente conforme a
atualização do analista e do testador, designando automaticamente
conforme o status para as pessoas informadas no planejamento descrito no
Desenho de teste. Tela de caso de teste, conforme Figura 53 e Figura 54.
Inspeções
A inspeção existe na ferramenta de forma controlada, não deixando evoluir
as etapas se não houve inspeção ainda. Após a inspeção é possível evoluir
ou voltar o status, conforme solicitações da reunião de inspeção que ocorre
fora da ferramenta. A Figura 60 apresenta o controle.
Execução
A execução dos passos está dentro do Caso de teste, onde é possível
registrar o sucesso ou a falha de passos, informando o motivo. Após a
execução é possível gerar um relatório de erros. Tela de caso de teste,
Figura 63 e Figura 64 e o relatório de erros, na Figura 65. Quadro 7 – Aderência da ferramenta ao processo
Ainda buscando demonstrar a aderência da ferramenta ao processo e deste ao CMMI, o
Quadro 8 tece algumas relações do processo e da ferramenta com os objetivos na área de
90
Verificação e Validação do CMMI.
Objetivos específicos de
verificação e validação
do CMMI
Atividades do processo e ferramenta
Preparar verificação e
validação
Conduzir a preparação da verificação e da validação. O processo é
iniciado com o planejamento dos testes, gerando o artefato plano
de testes, que possui um escopo sobre os testes do item,
mostrando o fluxo de trabalho desejado para o teste. A ferramenta
disponibiliza na tela de desenho de testes uma opção de
planejamento, podendo dar continuidade aos testes somente após
a conclusão do planejamento.
Realizar revisões
técnicas na verificação
O processo prevê a realização de revisões técnicas aos produtos
de trabalho selecionados. Na ferramenta há um controle de
inspeções na ferramenta, o caso de teste deve ser inspecionado e
aceito, se não for, não é possível dar continuidade ao processo de
testes.
Verificar os produtos de
trabalhos selecionados
na verificação
O processo prevê que os produtos de trabalho sejam verificados
face aos seus requisitos especificados, não se pode iniciar os
testes sem ter o projeto/especificação do item a ser testador, por
tanto, o processo de desenvolvimento gera artefatos para a área de
testes consumir. Na ferramenta é possível importar os casos de
uso e desenvolver os casos de teste a partir dos casos de uso
desenvolvidos no EA.
Verificar os produtos de
trabalho selecionados na
validação
O processo prevê que os produtos de trabalho sejam verificados
face aos seus requisitos especificados. É possível com a
ferramenta verificar os casos de uso do sistema em testes e os
casos de testes desenvolvidos para o mesmo. É disponibilizado na
ferramenta relatórios e consultas de casos de uso e casos de teste.
Os casos de teste podem ser verificados e comparados com outros
documentos fora da ferramenta pois é possível imprimir relatórios
de casos de teste, a partir de um caso de uso.
Validar produto ou
componentes do produto
na validação
O processo prevê a execução de todos os componentes do
produto, com a finalidade de assegurar que estes são apropriados
para utilização no ambiente de operação pretendido, sendo assim,
a ferramenta disponibiliza a parte de execução de testes, onde é
simulado o uso, e executado os casos de testes desenvolvidos nas
etapas anteriores do processo, possibilitando o registro dos
incidentes e erros encontrados. Quadro 8 – Aderência ao CMMI
Para avaliar o apoio provido pela ferramenta, suas funcionalidades foram analisadas
por profissionais da área de testes da HBSIS Informática. O objetivo da avaliação foi avaliar a
aplicação da ferramenta e verificar se a estratégia apresentada por este trabalho apresenta
benefícios.
Foi montado um ambiente dentro da rede da HBSIS Informática para a avaliação
preliminar. Utilizou-se a demanda e as atividades normais da área, sendo solicitado aos
91
usuários utilizar a ferramenta para contemplar o atual artefato Caso de Teste referente a um
caso de uso dos sistemas atuais em testes. A utilização e avaliação da ferramenta foram
realizadas por cinco usuários, que no decorrer do processo e conforme alocação nos projetos
assumem papéis distintos: analista de teste e testador, ou seja, responderam o questionários
sob duas visões diferentes.
Encerrada a utilização da ferramenta, os usuários foram convidados a participar de
uma pesquisa informal e intencional, na qual poderiam comentar, sugerir e responder sobre
aspectos gerais da ferramenta. A pesquisa foi realizada através de um questionário (Apêndice
C), a fim de coletar a percepção dos usuários em relação aos benefícios trazidos pela
automação do planejamento e controle do processo de testes.
A Figura 68 apresenta gráficos com os resultados para as principais perguntas do
questionário.
Figura 68 – Resultado do questionário
O resultado da pesquisa apresentado na Figura 66 demonstra a satisfação dos usuários
em relação aos principais aspectos envolvidos no uso da ferramenta em suas atividades de
teste.
92
A pesquisa revelou que 90% dos avaliadores possuem uma ou mais certificações na
área de testes, o que dá credibilidade à pesquisa, e que 100% deles acreditam que o as
atividades atuais serão facilitadas com o uso da ferramenta (pergunta 2.4 do questionário,
Apêndice C). Ainda com 100% de aprovação, a pergunta 2.2 do questionário (Apêndice C)
confirma a boa avaliação da usabilidade da ferramenta no todo.
Além da pesquisa foram recebidos comentários, sugestões e impressões gerais sobre a
ferramenta. Os usuários consideraram a utilização da ferramenta como uma boa alternativa
para a melhoria do processo de testes, impactando diretamente na produtividade e eficiência
das suas atividades, conforme demonstram os relatos abaixo.
“A confecção do artefato Caso de Teste fica mais
rápida com a utlização [sic] da ferramenta, não
haverá perda de tempo com formatação de células...
como temos no Excel atualmente...”
Analista de teste 1 HBSIS
“...E facilitará a impressão dos CT's para as
inspeções....”
Analista de teste 2 HBSIS
“...Teremos a segurança de que outra pessoa não
mexedrá [sic] no CT se não for designado á ela.”
Testador 1 HBSIS
“...Fica mais claro e fácil visualizar os passos para
serem executados e a forma de re-testar com as
opções de Sucesso ou Falha nos testes.”
Testador 2 HBSIS
Ainda analisando os comentários dos avaliadores, destacam-se como principais pontos
fortes observados pelos avaliadores: a utilização do processo atual, sem a necessidade de
utilizar o Excel; facilidade da geração do artefato Caso de teste, tanto na confecção como na
impressão; registro dos erros encontrados durante a execução dos testes e segurança.
93
4 CONCLUSÕES
Neste trabalho é apresentada uma ferramenta que apóia o planejamento e controle da
área de testes da empresa HBSIS Informática. A ferramenta auxilia na organização e no
controle das atividades realizadas em um ciclo de teste e armazena o conjunto de informações
geradas durante o ciclo. Auxilia no desenvolvimento das atividades envolvidas no processo de
testes. A ferramenta sugere a extinção da planilha Excel utilizada atualmente para geração dos
artefatos envolvidos, amenizando problemas como:
a) formatação do caso de teste;
b) padronização dos artefatos;
c) falta de segurança na geração de documentos em servidores públicos da empresa;
d) falta de rastreabilidade com casos de uso;
e) execução de casos de teste somente quando deve;
f) controle de inspeções;
g) planejamento dos testes;
h) controle de envolvidos e status das atividades.
Como resultado é possível monitorar, de forma sistematizada, o progresso das
atividades durante todo o processo, permitindo aos envolvidos organizar e acompanhar suas
tarefas e informações. Desta forma, o projeto oferece uma alternativa de melhoria ao processo
de teste, possibilitando maior eficiência e agilidade na sua administração. A agilidade gerada
ao atual processo vem da diminuição de ações manuais, automatizando as atividades da área
de teste para confecção, impressão e execução de casos de teste.
Desta maneira, é apresenta uma opção de sistema para gestão de testes de software
voltado para a HBSIS Informática, que já possui um processo de testes definido e almeja o
nível 3 do CMMI. A implantação e utilização da ferramenta pretendem contribuir para a
melhoria dos resultados, aumentando a maturidade da área de teste e obtendo agilidade na
administração e execução das atividades, controlando o caso de teste, seus estados e seus
envolvidos. Ainda que o processo não seja o alvo deste trabalho, é possível afirmar que o
processo da empresa HBSIS Informática ganha maturidade na área de testes, pois garante que
as atividades e o processo sejam cumpridos sem burlo, facilitando a auditoria em relação à
obtenção do CMMI nível 3.
Este trabalho alcançou a etapa de avaliação com usuários, sendo utilizada a própria
demanda de atividades da HBSIS Informática e seus envolvidos da área de teste, mostrando
94
um resultado positivo em relação à utilização e a aderência da ferramenta ao processo atual.
A ferramenta foi desenvolvida na linguagem de programação C# / ASP.NET e banco
de dados SQL Server 2005, como outras ferramentas internas desenvolvidas pela HBSIS
Informática. Utilizou-se do framework .NET para desenvolvimento e nos aspectos não
atendidos pelo framework, buscou-se alternativas fora do framework, porém, voltadas à ele,
como é o caso de um componente envolvido em uma das principais telas da ferramenta, o
HierarGrid.
A divisão da arquitetura facilitou o projeto e o desenvolvimento do trabalho. Já a
especificação através do uso da UML, auxiliou na definição do escopo e na codificação da
ferramenta.
Assim, pelos resultados obtidos, o estudo de caso avalia positivamente a proposta da
ferramenta e demonstra que a sua aplicação oferece benefícios para a gestão e controle do
processo de teste de software, cumprindo os objetivos abordados neste trabalho.
44..11 EEXXTTEENNSSÕÕEESS
Para trabalhos futuros, surgem possibilidades de novas funcionalidades que apoiarão
as demais práticas relacionadas.
Como sugestão, pode-se implementar medições de tempo de execução das atividades e
controle de prazos. Isto pode ser feito através de definições de tempos e prazos de início e
término das atividades, como planejamento no Desenho de teste. Ainda nesta idéia de
atividades e prazos, poderia ser desenvolvida integração com o JIRA9, que é a ferramenta
atual utilizada pela HBSIS para controle das atividades do projeto.
Outra sugestão seria a disponibilização de geração de métricas, estatísticas e
identificação de riscos, também realizada vinculado ao Desenho de Teste.
O versionamento de casos de teste é algo bem interessante também, para poder
reaproveitar o Caso de teste e controlar suas versões. O controle de versões é extremamente
útil e importante, por isso no CMMI é uma prática, no processo deve-se ter itens de trabalho
sob níveis apropriados de controle (CMMI, 2006).
Há também sugestões expostas pelos avaliadores, o Quadro 9 apresenta alguns itens
95
sugeridos na pesquisa, na pergunta 3.1 do questionário (Apêndice C).
Item Sugestões
1
―Incluir no DT [sic desenho de teste] as pessoas que serão convocadas para as
inspeções, bem como disparar e-mail para os mesmos com o CT [sic caso de teste] a
ser inspecionado em anexo.‖ - Testador HBSIS.
2 ―Deveria disponibilizar a comparação entre UCs [sic casos de uso], para verificar o
que foi alterado no UC [sic caso de uso].‖ - Analista de teste HBSIS
3 ―A ferramenta também deveria possuir mecanismos de formatação pra destacar
palavras.‖ - Analista de teste HBSIS.
4 ‗Também definir o plano de testes, com o escopo do teste e não escopo.‖ - Analista de
teste HBSIS.
5
―Permitir que eu coloque um passo como passou e se os anteriores eu não ter definido
o sistema assuma como passou. Exemplo, fiz a leitura do passo 1, 2 e 3, executei esses
passos, na ferramenta eu coloco que o 3º passo 'passou', nesse momento o sistema
atribui 'passou' para os dois anteriores 1 e 2.‖ - Testador HBSIS.
6
―Quando o Caso de Teste vai para inspeção poderia ser enviado um e-mail para os
envolvidos avisando que o caso de teste está disponível para impressão.‖ - Analista de
teste HBSIS.
7 ―Incluir espécie de "comissão de inspeção" ao invés de 1 só inspetor, que são as
pessoas que participam das reuniões de inspeção.‖ - Analista de teste HBSIS.
8 ―Controle de versões, para poder fazer cópias de Casos de Teste.‖ - Analista de teste
HBSIS.
Quadro 9– Sugestões de melhorias
9 JIRA é uma aplicação J2EE de acompanhamento e gestão dos problemas desenvolvida para gestão de projetos
e acompanhamento de tarefas e erros (JIRA, 2010).
96
REFERÊNCIAS BIBLIOGRÁFICAS
BARTIÉ, Alexandre. Garantia da qualidade de software: adquirindo maturidade
organizacional. Rio de Janeiro: Campus, 2002.
BASTOS, Anderson. Base de Conhecimento de Teste de Software. Niterói: Traço & Photo,
2006.
BAUER,Denis. HierardGrid. Alemanha, 2007. Disponível em:
<http://www.denisbauer.com/> Acesso em: 05 jun. 2010.
BIANCHINI, Juliano. Ferramenta de apoio ao planejamento de teste funcional de
software a partir de diagrama de caso de uso. 2004. 75 f. Trabalho de Conclusão de Curso
(Bacharel em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade
Regional de Blumenau, Blumenau.
BONECHER, Bruna T. Ferramenta WEB de apoio ao planejamento e controle de testes.
2008. 84 f. Trabalho de Conclusão de Curso (Bacharel em Ciências da Computação) – Centro
de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
CMMI, CMMI-DEV, V1.2. Tradução: André Villas Boas e José Marcos Gonçalves.
Campinas, 2006.
COUTO, Ana Brasil.Integração dos modelos de capacitação e maturidade de sistemas.
Rio de Janeiro: Ciência Moderna, 2007.
CRAIG, Larman. Utilizando UML e padrões. São Paulo: Artime, 2005.
DIAS NETO, Arilo C.; TRAVASSOS, Guilherme H. Maraká: Infra-estrutura
computacional para apoiar o planejamento e controle dos testes de software. In:
SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE, 5., 2006, Rio de Janeiro.
Anais eletrônicos... Rio de Janeiro: UFRJ, 2006. p. 250-264. Disponível em:
<http://www.sbc.org.br/bibliotecadigital/download.php?paper=981/>. Acesso em: 18 mai.
2010.
DIAS NETO, Arilo Claudio. Uma Infra-Estrutura Computacional para Apoiar o
Planejamento e Controle de Teste de Software. Rio de Janeiro, 2006. Disponível em:
<http://lens-
ese.cos.ufrj.br/ese/index.php?option=com_docman&task=doc_download&gid=2&Itemid=74
&lang=pt_br />. Acesso em: 19 jun. 2010.
INTHURN, Cândida. Qualidade & Teste de Software. Florianópolis: Visual Books, 2001.
97
JIRA. Issue and project tracking. Atlasian, 2010. Disponível em: < www.atlassian.com/>.
Acesso em: 15 jun. 2010
KOSCIANSKI, André; SOARES, Michel S. Qualidade de software: Aprenda as
metodologias mais modernas para o desenvolvimento de software. São Paulo: Novatec,
2006.
MACORATTI, José Carlos. [S.I], 2010. Disponível em:
<http://imasters.uol.com.br/artigo/14146/dotnet/net_usando_generics/>. Acesso em: 31 mai.
2010
MICROSOFT. Desenvolvimento DOTNET. [S.I], 2010. Disponível em:
<http://msdn.microsoft.com/pt-br/default.aspx/>. Acesso em: 31 mai. 2010
MYERS, Glenford J. The art of software testing. New York: John Wiley & Sons, 1979.
PFLEEGER, Shari L. Engenharia de software: teoria e prática. Tradução Dino Franklin.
Revisão Ana Regina Cavalcanti da Rocha. 2. ed. São Paulo: Prentice Hall, 2004.
PRESSMAN, Roger S. Engenharia de software. Tradução Rosângela Delloso Penteado.
Revisão Fernão Stella R. Germano. 6. ed. São Paulo: McGraw-Hill, 2006.
ROCHA, Ana R.; MALDONADO, José C.; WEBER, Kival C. Qualidade de software:
teoria e prática. São Paulo: Prentice Hall, 2001.
SARTORI, Lucia Emi Shiraisi. Melhoria do Processo de Teste para Pequenas Empresas.
Marília: Dissertação de Mestrado. Departamento de Ciência da Computação, Centro
Universitário Eurípides de Marília, Fundação de Ensino Eurípides Soares da Rocha. 2005.
SOFTWARE ENGINEERING INSTITUTE. Capability Maturity Model Integration
Pittsburgh, 2010. Disponível em: <http://www.sei.cmu.edu/cmmi/>. Acesso em: 31 mai. 2010
SOMMERVILLE, Ian. Engenharia de software. Tradução Maurício de Andrade. Revisão
Prof. Dr Kechi Hirama. 6. ed. São Paulo: Addison Wesley, 2003.
WEBER, Kiva. Qualidade de Software: Teoria e Prática. São Paulo: Prentice Hall, 2001.
98
APÊNDICE A – Detalhamento dos casos de uso
É apresentado o detalhamento dos principais casos de uso (UC07, UC08, UC09,
UC10) previstos no diagrama apresentado na seção 3.3.1.
No Quadro 10 apresenta-se o caso de uso ―UC07 - Manter Desenho de Teste‖.
Nome do Caso de Uso Manter Desenho de Teste
Descrição Usuário acessa Desenho de Teste, para manter os dados.
Ator Analista de teste
Pré-condição Usuário deve fazer login no sistema;
Pelo menos um módulo deve estar cadastrado.
Fluxo principal 1. Sistema apresenta os Desenhos de Teste cadastrados;
2. Usuário opta por editar, excluir ou cadastrar um Desenho de Teste;
Cenário – Visualização 1. Sistema apresenta os Desenhos de Teste cadastrados para um módulo;
2. Usuário seleciona um Desenho de Teste;
3. Sistema mostra detalhes do Desenho de Teste selecionado.
Cenário – Edição 1. Sistema apresenta Desenhos de Teste cadastrados;
2. Usuário seleciona um Desenho de Teste para edição;
3. Sistema mostra todos campos;
4. Usuário altera Desenho de Teste e seleciona opção para atualizar os dados
5. Sistema apresenta o Desenho de Teste atualizado.
Cenário – Inclusão 1. Sistema apresenta Desenhos de Teste cadastrados;
2. Usuário inclui um novo Desenho de Teste;
3. Sistema permanece na tela, apresenta o Desenho de Teste alterado e habilita aba
para inclusão de Casos de Teste.
Cenário – Exclusão 1. Sistema mostra Desenhos de Teste cadastrados;
2. Usuário seleciona um Desenho de Teste para exclusão;
3. Sistema exclui o Desenho de Teste e mostra os Desenhos de Teste restantes.
Fluxo alternativo No passo 4 do Cenário – Edição, se o usuário seleciona opção para atualizar
dados e fechar, sistema apresenta os Desenhos de Testes cadastrados com o
Desenho de Teste atualizado.
No passo 3 do Cenário – Inclusão, se o usuário seleciona opção para atualizar
dados e fechar, sistema apresenta os Desenhos de Testes cadastrados com o
novo Desenho de Teste.
No passo 3 do Cenário - Exclusão, caso o Desenho de Teste já tenha um Caso
de Teste cadastrado, então não é possível excluir. Sistema apresenta mensagem.
Pós-condição Usuário visualizou, editou, excluiu ou cadastrou um Desenho de Teste.
Quadro 10 – Descrição do caso de uso UC07 - Manter Desenho de Teste
99
No Quadro 11 apresenta-se o caso de uso ―UC08 - Manter Caso de Teste‖.
Nome do Caso de Uso Manter Caso de Teste
Descrição Usuário acessa um Caso de Teste.
Ator Analista de Teste
Pré-condição Usuário deve fazer login no sistema.
Pelo menos um Desenho de Teste deve estar cadastrado.
Fluxo principal 1. Sistema apresenta Casos de Teste cadastrados;
2. Usuário opta por editar, excluir ou cadastrar um Caso de Teste.
Cenário – Visualização 1. Sistema apresenta Casos de Teste cadastrados.
2. Usuário seleciona um Caso de Teste;
3. Sistema apresenta detalhes do Caso de Teste selecionado.
Cenário – Edição 1. Sistema apresenta Casos de testes cadastrados;
2. Usuário seleciona um Caso de Teste para edição;
3. Sistema mostra todos os campos, uma aba com Casos de Uso e uma aba com
cenários.
4. Usuário altera Caso de Teste e seleciona opção para atualizar os dados;
5. Sistema permanece na tela com o Caso de Teste atualizado.
Cenário – Inclusão 1. Sistema apresenta Casos de Teste cadastrados;
2. Usuário inclui um novo Caso de Teste;
3. Sistema permanece na tela, habilita abas para inclusão dos Casos de Uso e outra
para inclusão de cenários;
Cenário – Exclusão 1. Sistema apresenta Casos de Teste cadastrados;
2. Usuário seleciona um Caso de Teste para exclusão;
3. Sistema exclui o Caso de Teste e mostra os registros restantes.
Fluxo alternativo No passo 3 do Cenário – Edição, se o usuário logado não for o Responsável
atual pelo Caso de Teste, não é possível alterar nenhum campo.
No passo 3 do Cenário – Edição, se a situação do Caso de Teste for diferente de
―Em elaboração‖, não é possível alterar nenhum campo. Usuário pode optar por
criar nova versão do Caso de Teste.
No passo 4 do Cenário – Edição, se o usuário seleciona opção para atualizar dados e
fechar, sistema apresenta os Casos de Teste cadastrados com o Caso de Teste
atualizado.
No passo 3 do Cenário – Exclusão, se a situação do Caso de Teste for diferente
de ―Em elaboração‖, não é possível excluir. Sistema apresenta mensagem.
Se no passo 3 do Cenário – Edição, o usuário optar por criar nova versão do
Caso de Teste, sistema copia o Caso de Teste, criando um novo registro com
uma nova versão, na situação ―Em elaboração‖.
Pós-condição Usuário visualizou, editou, excluiu ou cadastrou um Caso de Teste.
Quadro 11 – Descrição do caso de uso UC08 - Manter Caso de Teste
100
No Quadro 12 apresenta-se o caso de uso ―UC09 - Importar Casos de Uso‖.
Nome do Caso de Uso Importar Casos de Uso
Descrição Usuário acessa um Caso de Teste.
Ator Analista de Teste
Pré-condição Usuário deve fazer login no sistema.
Pelo menos 1 sistema cadastrado, com a base de dados do EA cadastrada.
Fluxo principal 1. Sistema apresenta lista de Casos de Uso importados;
2. Usuário opta por importar Casos de Uso para um novo sistema;
3. Sistema apresenta sistemas disponíveis para importação de casos de uso;
4. Usuário opta pelo sistema;
5. Sistema busca do banco cadastrado no sistema os casos de uso novos e atualiza
os já existentes;
6. Sistema mostra lista de casos de uso importados.
Cenário – Exclusão 1. Sistema apresenta o Casos de Uso importados;
2. Usuário seleciona o Caso de Uso para exclusão;
3. Sistema exclui o Caso de Uso.
Pós-condição Usuário visualizou, importou, ou excluiu um Caso de Uso.
Quadro 12 – Descrição do caso de uso UC09 - Importar Casos de Uso
No Quadro 13 apresenta-se o caso de uso ―UC10 - Manter resultados da execução‖.
Nome do Caso de Uso Manter resultados da execução
Descrição Usuário acessa um Caso de Teste.
Ator Testador
Pré-condição Usuário deve fazer login no sistema.
Pelo menos um Caso de Teste deve estar cadastrado.
Caso de Teste com situação igual a ―Executando‖.
Fluxo principal 1. Sistema apresenta os cenários do Caso de Teste;
2. Usuário preenche aceite do cenário.
Cenário – Visualização 1. Sistema apresenta o Caso de Teste;
2. Usuário seleciona o Caso de Teste;
3. Sistema apresenta detalhes do Caso de Teste selecionado;
4. Usuário seleciona cenários;
5. Sistema apresenta cenários cadastrados para o Caso de Teste;
6. Usuário seleciona um cenário;
7. Sistema apresenta os passos do cenário;
Cenário – Edição 1. Sistema apresenta o Caso de Teste;
2. Usuário seleciona o Caso de Teste;
3. Sistema apresenta detalhes do Caso de Teste selecionado;
4. Usuário seleciona cenários;
101
5. Sistema apresenta cenários cadastrados para o Caso de Teste;
6. Usuário seleciona um cenário;
7. Sistema apresenta os passos do cenário;
8. Usuário preenche os campos: ―Passou‖ e ―Considerações‖ (opcional) para cada
passo e opta por salvar;
9. Sistema preenche campo ―Teste OK‖ do cenário, de acordo com o resultado de
todos os passos;
10. Usuário opta por fechar o registro;
11. Sistema apresenta cenários do Caso de Teste;
Pós-condição Usuário visualizou ou incluiu resultados da execução.
Quadro 13 – Descrição do caso de uso UC10 – Manter resultados da execução
102
APÊNDICE B – Cadastros básicos
É apresentado o detalhamento dos cadastros básicos da ferramenta.
A Figura 69 apresenta a tela de pesquisa de sistemas, onde pode-se cadastrar um novo
sistema. Esta tela é chamada a partir do link lateral ―Sistemas‖.
A tela de sistemas é composta por um filtro de pesquisa, onde é possível pesquisar pelo
nome do sistema e por um grid, que apresenta os sistemas cadastrados. Abaixo do grid possui
um botão Novo, que leva a página de criação de um novo sistema.
Figura 69 – Pesquisa de sistemas
A seguir, na Figura 70 é apresentada a tela de criação de um sistema, simulando o
clique no botão ―Novo‖ da tela apresentada na Figura 69.
103
Figura 70 – Tela de criação de novo sistema
Se os campos obrigatórios não forem preenchidos, não é possível seguir com a criação,
sendo exibida a mensagem como mostra a Figura 71. A implementação de campos
obrigatórios é a mesma para todas as telas do sistema.
Após ter os campos preenchidos, para efetivamente criar um sistema, é preciso clicar
no botão Salvar.
Figura 71 – Tela de criação de novo sistema, requisitando campos obrigatórios
A Figura 72 apresenta a tela de pesquisa de módulos, a tela possui um botão Novo que
redirecionada para a página de criação de um novo módulo (Figura 73), seguindo o mesmo
padrão da tela de criação de sistema.
Nesta tela pode-se pesquisar pelo nome do módulo ou pelo sistema ao qual o módulo
104
pertence. A tela é chamada pelo link Módulos do menu lateral.
Figura 72 – Pesquisa de módulos
Figura 73 – Tela de criação de novo módulo
A Figura 74 apresenta a tela de pesquisa de pessoas, podendo filtrar pelo nome da
pessoa ou por seu papel. Ao clicar no botão Novo, redireciona para a página de criação de
nova pessoa, como mostra a Figura 75. A tela é chamada a partir do link Pessoas do menu
superior.
105
Figura 74 – Pesquisa de pessoas
Figura 75 –Tela de criação de nova pessoa
106
APÊNDICE C – Questionário
Na Figura 76 é apresentado o questionário da pesquisa realizada.
1
1.1
( ) Analista de Teste ( ) Coordenador ( ) Testador
1.2
( ) Menos de 1 ano ( ) Entre 1 e 2 anos ( )Entre 2 e 5 anos ( ) Mais de 5 anos
1.3
2
2.1
( )Fracamente aderente ( )Parcialmente aderente ( )Fortemente aderente ( )Totalmente aderente
2.2
( )Péssima ( )Ruim ( )Razoável ( )Boa ( )Muito boa
2.3
( )Péssima ( )Ruim ( )Razoável ( )Boa ( )Muito boa
2.4
( ) Não facilitará (pelo contrário ficou mais difícil) ( ) Permanece igual
( ) Facilitará um pouco ( )Facilitará muito
2.5
( ) Tornou muito mais rápido ( ) Tornou rápido ( ) Tornou lento
( ) Tornou muito mais lento ( ) Não alterou
3
3.1
O uso da ferramenta alterou o tempo de execução de suas atividades?
Sugestões de melhoria
Como você acha que a ferramenta pode ser melhorada?
Avaliação da ferramenta
Como você avalia a aderência da ferramenta ao processo da HBSis?
Como você avalia a usabilidade da ferramenta no todo?
Como você avalia a usabilidade da tela de casos de teste?
Em que medida você acredita que seu trabalho será facilitado com o uso da ferramenta?
Por que?
O objetivo deste questionário é coletar a percepção dos usuários em relação aos benefícios trazidos pela
automação do planejamento e controle do processo de testes.
Perfil do avaliador
Cargo que ocupa
Tempo de Experiência em testes de software
Formação
Insira sua formação acadêmica e certificações.
FURB - FUNDAÇÃO UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO
CAMILA LABES
QUESTIONÁRIO PARA MEDIR A ADERÊNCIA DA FERRAMENTA TESTE-PLAN AO PROCESSO DA HBSIS
Figura 76 - Questionário
![TCC2010-1-14-AP-JoanaSimon [Modo de Compatibilidade]campeche.inf.furb.br/tccs/2010-I/TCC2010-1-14-AP-JoanaSimon.pdf · Realizou-se atividade com a turma de TIGN do primeiro semestre](https://img.document.onl/doc/110x75/5c13537909d3f2e3218c60e8/tcc2010-1-14-ap-joanasimon-modo-de-compatibilidade-realizou-se-atividade-com.jpg)
