modelo de tese - home - softplan · 2.1.2 modelo de processos de desenvolvimento de software ......
TRANSCRIPT
UNIVERSIDADE DO SUL DE SANTA CATARINA
EDUARDO FINOTTI
GUSTAVO ROBERTO NITO
PRIORIZAÇÃO DE TESTES DE SOFTWARE: UM ESTUDO DE CASO
FLORIANÓPOLIS
2015
EDUARDO FINOTTI
GUSTAVO ROBERTO NITO
PRIORIZAÇÃO DE TESTES DE SOFTWARE: UM ESTUDO DE CASO
Trabalho de Conclusão de Curso apresentado ao Curso
de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina, como requisito
parcial à obtenção do título de Bacharel em Sistemas de
Informação
ORIENTADOR: PROF. MARIA INÉS CASTIÑEIRA, DRA.
FLORIANÓPOLIS
2015
EDUARDO FINOTTI
GUSTAVO ROBERTO NITO
PRIORIZAÇÃO DE TESTES DE SOFTWARE: UM ESTUDO DE CASO
Este Trabalho de Conclusão de Curso foi julgado
adequado à obtenção do título de Bacharel em Sistemas
de Informação e aprovado em sua forma final pelo
Curso de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina.
FLORIANÓPOLIS, 16 DE JUNHO DE 2015.
_____________________________________________________________
Professora e orientadora Maria Iñes Castineira, D.ra
Universidade do Sul de Santa Catarina
_____________________________________________________________
Prof. Richard Henrique de Souza, Msc.
Universidade do Sul de Santa Catarina
_____________________________________________________________
Leandro da Cunha, Bel.
Universidade do Sul de Santa Catarina
Agradecemos a Deus primeiramente e
dedicamos este trabalho a nossas famílias que
sempre nos deram muito apoio em todos os
momentos. Principalmente o apoio recebido
nessa etapa tão importante em nossas vidas.
AGRADECIMENTOS
Agradecemos, a Maria Iñes, nossa orientadora, pelo imenso apoio, e a
coordenadora do curso, Vera Schumacher.
Eduardo Finotti agradece a:
Deus primeiramente
A minha família pelo grande apoio, principalmente a Valdir Luiz Finotti.
Agradeço também pela paciência dos amigos e namorada, Fabíola Cardoso.
Ao colega Gustavo Nito pela parceria não só no desenvolvimento deste trabalho,
mas durante todo o curso.
Aos professores do curso, que contribuirão com seu conhecimento e experiência
ao longo dos anos.
Aos convidados da banca que aceitaram o convite e dispuseram seu tempo para
colaborar com o trabalho.
Gustavo Roberto Nito agradece a:
A orientadora Maria Iñes Castineira por toda dedicação, paciência, força e auxilio
que nos foi fornecido.
A coordenadora Vera Schuhmacher, que sempre apoiou e nos forneceu toda a
estrutura necessária para o andamento da graduação.
Ao Cristiano Caetano e Leandro Cunha por todos os ensinamentos na área de
Qualidade de Software.
Aos professores do curso, que contribuirão com seu conhecimento e experiência
ao longo dos anos.
Aos convidados da banca que aceitaram o convite e dispuseram seu tempo para
colaborar com o trabalho.
Ao meu colega Eduardo Finotti, por todo esforço e parceria para realização deste
trabalho.
Aos meus Pais por toda a dedicação, apoio, incentivo e amor durante toda a minha
vida.
A minha esposa Eliza Geraldo Rodrigues, pela paciência, por todo apoio,
companheirismo e amor durante o desenvolvimento do trabalho.
"Para uma tecnologia de sucesso, a realidade deve ter prioridade sobre as relações públicas,
pois a Natureza não pode ser enganada." (Richard Feynman).
RESUMO
Um software é desenvolvido para que este possa resolver algum problema ou facilitar o dia-
dia a execução de uma determinada atividade. Ele é desenvolvido de acordo com os desejos e
as necessidades do cliente, para que, de alguma maneira agregue valor as suas tarefas ou
negócio.
Desenvolver um software, sempre, é algo complicado, independendo da necessidade que ele
irá atender. O software é desenvolvido por seres humanos que são passíveis de erros durante a
execução de suas atividades, podendo gerar falhas no software durante sua codificação.
Para que esses erros sejam descobertos e resolvidos, antes de ser entregue ao cliente, entra o
processo de testes de software. Porém, ainda, não existe uma cultura explícita de testes de
software dentro das empresas, onde, muitas vezes, este processo é menosprezado pelas
mesmas.
Isso acontece de diversas formas, como, por exemplo, não dando tempo hábil para que os
testes sejam realizados de maneira correta pelas equipes. Por isso, uma saída para esse
problema é fazer a priorização dos testes a serem executados, de forma que uns são
executados primeiro e outros depois.
Palavras-chave: Teste de software, priorização de testes.
ABSTRACT
A software is developed so that it can solve some problem or facilitate the day to day running
of a particular activity. It is developed according to the wishes, needs, the customer, that
somehow their aggregate value their jobs or business.
Developing a software is always a tricky thing, regardless of need he will meet. The software
is developed by humans, that are prone to errors during the execution of their activities, which
may cause failures in the software during its codification.
The software testing process so that these errors are discovered and resolved, before being
delivered to the customer, enters. However, there is still no explicit culture of software testing
within companies, where this process is often overlooked by companies.
This happens in several ways. For example, not giving enough time for the tests are
performed correctly by the teams. Therefore, a solution to this problem is to make the
prioritization of tests to run, so that some are first and another later executed.
Keywords: Software Testing, Test prioritization.
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................................. 12
1.1 PROBLEMA .................................................................................................................................14 1.2 OBJETIVOS .................................................................................................................................16 1.2.1 Objetivo Geral ..........................................................................................................................16 1.2.2 Objetivos Específicos ...............................................................................................................16 1.3 JUSTIFICATIVA .........................................................................................................................17 1.4 ESTRUTURA DA MONOGRAFIA ............................................................................................18
2 REVISÃO DA BIBLIOGRÁFICA .............................................................................................. 19
2.1 ENGENHARIA DE SOFTWARE ...............................................................................................19 2.1.1 Processo de Desenvolvimento de Software ............................................................................20 2.1.2 Modelo de Processos de desenvolvimento de software .........................................................20 2.2 QUALIDADE DE SOFTWARE ..................................................................................................24 2.3 TESTES DE SOFTWARE .............................................................................................................25 2.3.1 Validação e Verificação ...........................................................................................................26 2.4 PROCESSO DE TESTE DE SOFTWARE ..................................................................................27 2.4.1 Procedimentos iniciais .............................................................................................................28 2.4.2 Planejamento ............................................................................................................................29 2.4.3 Preparação ................................................................................................................................30 2.4.4 Especificação ............................................................................................................................30 2.4.5 Execução ...................................................................................................................................31 2.4.6 Entrega ......................................................................................................................................32 2.5 EQUIPE DE TESTES ...................................................................................................................32 2.5.1 Cargos e funções .......................................................................................................................33 2.6 TIPOS DE TESTE DE SOFTWARE ...........................................................................................34 2.6.1 Testes unitários ........................................................................................................................34 2.6.2 Testes de integração .................................................................................................................35 2.6.3 Testes de sistema ......................................................................................................................36 2.6.4 Testes de aceitação ...................................................................................................................36 2.7 TÉCNICAS DE TESTES .............................................................................................................37 2.7.1 Testes funcionais ou caixa-preta .............................................................................................37 2.7.1.1 Testes de requisitos ................................................................................................................ 38 2.7.1.2 Testes de regressão ................................................................................................................. 39 2.7.1.3 Teste tratamento de erros ....................................................................................................... 40 2.7.1.4 Testes de interconexão ........................................................................................................... 40 2.7.2 Teste estrutural ou caixa-branca ............................................................................................41 2.7.2.2 Testes de estresse ................................................................................................................... 41 2.7.2.3 Teste de performance ............................................................................................................. 42 2.7.2.4 Teste de recuperação .............................................................................................................. 43 2.7.2.5 Teste de segurança ................................................................................................................. 43 2.7.3 Testes não-funcionais ...............................................................................................................44 2.7.3.1 Testes de usabilidade .............................................................................................................. 44 2.7.3.2 Testes de instalação ................................................................................................................ 45 2.8 CONSIDERAÇÕES FINAIS .......................................................................................................45 2.9 GERENCIAMENTO DE RISCOS ...............................................................................................47 2.9.1 Definição de Risco ....................................................................................................................47 2.9.2 Gerenciamento de Riscos ........................................................................................................48 2.9.3 Riscos e Testes ..........................................................................................................................49 2.9.4 Importância e Benefícios .........................................................................................................50
2.9.5 Cálculo de riscos .......................................................................................................................51 2.9.6 Lei de Brooks ............................................................................................................................52
3 MÉTODO....................................................................................................................................... 53
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA .......................................................................53 3.2 ETAPAS PARA DESENVOLVIMENTO DO PROJETO ..........................................................55 3.3 DELIMITAÇÕES .........................................................................................................................57
4 APLICAÇÃO DA PRIORIZAÇÃO DE CASOS DE TESTES - ESTUDO DE CASO .......... 57
4.1 A EMPRESA (SOFTPLAN). .......................................................................................................58 4.2 PROCESSO DE TESTES DA EMPRESA ...................................................................................59 4.2.1 Estimativas ...............................................................................................................................59 4.2.1.1 Estimar a Revisão da Especificação de Negócio .................................................................... 59 4.2.1.2 Estimar o projeto dos Casos de Testes ................................................................................... 60 4.2.1.3 Estimar a execução dos Casos de Testes ................................................................................ 61 4.2.2 Revisar Especificação de Software ..........................................................................................62 4.2.2.1 Registrar as não-conformidades ............................................................................................. 63 4.2.3 Projetar casos de testes ............................................................................................................65 4.2.3.1 Mapeamento dos itens de testes ............................................................................................. 65 4.2.3.2 Elaborar casos de testes .......................................................................................................... 66 4.2.3.2.1 Listas de Verificação............................................................................................................67 4.2.3.3 Abordagens para execução de testes ...................................................................................... 68 4.3 ESTUDO DE CASO ...................................................................................................................71 4.3.1 Casos de Uso .............................................................................................................................71 4.4 ESTIMATIVA ..............................................................................................................................73 4.4.1 Aplicação da estimativa ............................................................................................................... 75 4.5 REVISÃO DE ESPECIFICAÇÃO ...............................................................................................76 4.6 ESPECIFICAÇÃO DOS CASOS DE TESTES ...........................................................................78 4.6.1 Exemplo de caso de documento de teste.................................................................................79 4.6.1.1 Aplicando o documento de testes ........................................................................................... 82 4.1 PRIORIZAÇÃO DOS TESTES ...................................................................................................87 4.1.1.1 Como é realizada a priorização .............................................................................................. 88 4.1.1.2 Aplicação da Priorização ........................................................................................................ 91 4.1.1.3 Estimativa com a priorização de testes................................................................................... 93 4.1.1.4 Considerações finais ............................................................................................................... 94
5 CONCLUSÕES E TRABALHOS FUTUROS............................................................................ 95
REFERÊNCIAS .................................................................................................................................. 97
ANEXO .............................................................................................................................................. 100
ANEXO A – CRONOGRAMA DAS ESTAPAS PARA DESENVOLVIMENTO DO PROJETO
100
............................................................................................................................................................. 100
ANEXO B – CRONOGRAMA DAS ESTAPAS PARA DESENVOLVIMENTO DO PROJETO
101
12
1 INTRODUÇÃO
Muitas das empresas e organizações que constituem o setor produtivo são baseadas em
dados. Esses dados são processados, gerando informações de diversas naturezas para a
organização, assim, auxiliando na tomada de decisões da corporação, auxiliando a mesma de
diversas formas.
Segundo Laudon e Laudon (1999, p. 10), “conhecimento é o conjunto de ferramentas
conceituais e categorias usadas pelos seres humanos para criar, colecionar, armazenar e
compartilhar a informação”. Essas informações são resultado da manipulação desses dados,
através de um “sistema de informação”, porém relacionados e baseados no conhecimento
humano.
Para que esses dados possam ser analisados e armazenados, são desenvolvidos
softwares, que auxiliam no processamento desses dados e que geram informações para a
organização. Sem esses sistemas informatizados, seria impossível, ou muito difícil, fazer
essas análises ou armazenar os dados da organização.
Um fator prezado pelas empresas é a satisfação dos clientes em relação ao produto que
está sendo entregue. Para atingir essa satisfação, é preciso que o software tenha boa qualidade,
em todos os sentidos, como possuir boa usabilidade, atingir os objetivos propostos e atender
as necessidades do cliente, por exemplo.
Segundo Bartié (2002, p. 16), “qualidade de software é um processo sistemático que
focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de
processos e produtos, prevenindo e eliminando defeitos. ” Alguns desses defeitos ou
problemas identificados no software ainda podem ser devidos a requisitos do cliente não
atendidos durante o desenvolvimento. Com isso, entende-se que, para existir um software
com uma boa qualidade, é necessário que este contemple o que foi decidido e levantado junto
ao cliente, não exibindo falhas que interfiram em seu uso correto.
Para que esses erros ou falhas nos softwares sejam identificados, é feito o uso dos
métodos de testes. Segundo Hetzel (1983, apud HETZEL, 1987p. 6), "teste é qualquer
atividade que vise a avaliar uma característica ou recurso de um programa ou sistema. Teste é
a medida da qualidade do software."
Além dos testes realizados nos softwares, alguns outros fatores também podem
influenciar na qualidade do mesmo, como requisitos que não foram bem especificados pela
empresa, na hora de solicitar um sistema para gerir seus dados, não se obtendo uma boa
13
definição do que é necessário implementar. Segundo Koscianski e Soares (2007, p. 172),
“sem uma definição precisa daquilo que se pretende construir, perde-se tempo, mais erros são
cometidos e a qualidade do produto final é incerta. ”.
Porém, em muitos projetos, ainda existe um grande problema na hora de executar
esses testes no software desenvolvido. Como a cultura de testes não está bem consolidada em
todas as organizações de software, muitas vezes, os testes são deixados de lado ou são
executados pela própria equipe de desenvolvimento, ou seja, os programadores. Geralmente,
esses testes somente garantem que os requisitos do cliente foram atendidos, deixando de lado
outros testes que deveriam ser executados.
Diversos autores afirmam que, quando existe a execução dos testes, feita de forma
sistemática, dentro de um processo, o custo de correção de defeitos na produção cai
drasticamente (Regra 10 de Myers). Além disso, o custo do software tende a ser relativamente
menor quando o software é bem testado (BASTOS, 2007, p. 22).
O custo de uma correção é muito mais caro quando descoberto mais tarde, ou seja,
quanto mais adiante no processo de desenvolvimento de software o defeito é descoberto, mais
caro ele se torna para ser corrigido.
Para que o teste seja executado de forma que possa contemplar todas as condições
possíveis de serem executadas em um sistema, são criados os casos de teste. Estes são
desenvolvidos a partir dos casos de uso, ou seja, dos caminhos que englobam os requisitos do
sistema, como regras de negócio, regras de tela, requisitos funcionais, entre outros. Conforme
Heumann (2001), um caso de teste é um conjunto de entradas de teste, condições de execução
e resultados esperados para um objetivo particular: exercer um caminho particular do
programa ou verificar o cumprimento de um requisito específico, por exemplo.
Assim, dentro de um caso de teste, tem-se uma pré-condição, um processamento e um
resultado esperado, e, como citado, este resultado esperado tem como base os requisitos do
sistema.
Por isso, uma boa tática é fazer a revisão da especificação. Quem realiza essa tarefa é
o analista de testes. Ela tem por objetivo encontrar dúvidas ou artefatos que impedem o
entendimento da criação do caso de teste e da própria execução destes.
14
Segundo Bastos (2007, p.22),
A correção de defeitos encontrados na fase de desenho custa menos que a de
defeitos encontrados na fase de produção. Alguns especialistas, como Rex Black
(1999), afirmam que existe uma progressão do tipo “dez, cem, mil” se compararmos
os custos dos defeitos encontrados na fase de desenho, da codificação e da produção.
Quando os testes são executados por uma equipe de testes, geralmente são executados
a partir dos casos de testes, desenvolvidos, considerando a documentação do sistema.
Porém o tempo disponibilizado para a equipe de testes desenvolver o seu trabalho
pode ser muito reduzido. Isso pode acontecer por diversos fatores, dentre eles, equipe de
testes reduzida, datas de entrega mal definidas ou a fraca cultura de testes. Muitas pessoas
pensam que o teste detalhado não é tão relevante, contudo, qualquer erro, falha ou defeito,
tem certo grau de “importância” dentro do sistema, ou seja, um erro, falha ou defeito pode ser
mais ou menos prejudicial ao sistema.
Por isso, tendo como base esse tempo reduzido e o risco que o defeito ou o não
atendimento do requisito pedido pelo cliente pode causar no sistema, seria interessante criar
uma priorização da execução desses testes.
Segundo Bastos (2007, p. 23), uma das maneiras de priorizar os testes de um software
é analisar os principais riscos para o negócio que uma determinada falha poderia causar. A
partir desses esclarecimentos sobre a temática do trabalho, é apresentada a problemática do
mesmo.
1.1 PROBLEMA
O teste é fundamental para garantir a qualidade de um software. Porém, quando o
tempo para a execução de testes não é suficiente para que todos os testes sejam executados de
maneira correta, alguns testes devem ser priorizados, de forma que, talvez, alguns outros
fiquem fora da execução.
Muitas vezes, os testes são realizados somente na última fase do projeto de software.
Por isso, o tempo para testes é determinado, de forma errada, pela diferença entre o número de
dias até o prazo de entrega e o número de dias utilizado no desenvolvimento. Com isso, o
tempo acaba não sendo suficiente para executar os testes de forma adequada. Algumas
15
atividades, como documentação, são deixadas de lado, assim, o risco de não executar um teste
importante pode ser alto.
Além disso, a falta de definição de padrões pode causar problemas para o
desenvolvimento do projeto.
Os resultados de uma atividade podem não ser adequados quando existe uma
dependência do entendimento e interpretação das pessoas, a partir de documentação
incompleta ou inexistente. Para ampliar as chances de sucesso de uma atividade, é necessário
deixar claro o que precisa ser feito e quais são os resultados esperados.
Assim, diante da impossibilidade de desenvolver e aplicar todos os possíveis casos de
teste, é necessário definir de alguma maneira quais são os testes mais relevantes, que devem
ser realizados para garantir os requisitos mínimos de qualidade, e quais testes são menos
relevantes, aqueles cuja ausência compromete em menor medida os resultados do
desenvolvimento de software.
Dessa forma, as perguntas de pesquisa propostas neste trabalho são: Como realizar a
priorização da execução desses testes? No que se basear para criar técnicas de priorização de
teste? Quais os critérios para a escolha de uma técnica a ser usada em uma situação
específica?
16
1.2 OBJETIVOS
Os objetivos desta monografia são divididos em objetivo geral e específicos.
1.2.1 Objetivo Geral
O objetivo desta monografia é pesquisar, escolher ou desenvolver técnicas para
realizar a priorização dos testes de software e aplicar esse processo em um estudo de caso.
1.2.2 Objetivos Específicos
Os objetivos específicos deste trabalho são:
• Realizar um levantamento da literatura sobre qualidade e testes de software;
• Pesquisar sobre métodos de testes de software;
• Criar métodos e técnicas de priorização na execução do projeto de testes;
• Aplicar a priorização de testes em um projeto da empresa do estudo de caso, visando
diminuir a quantidade de horas necessárias para que o projeto de testes seja realizado.
17
1.3 JUSTIFICATIVA
Um estudo conduzido pela NIST (National Institute of Standards and Technology), em
2002, informou que defeitos em software custam para a economia dos Estados Unidos da
América $59.5 bilhões de dólares anualmente, mais de um terço deste custo poderia ser
evitado com melhores testes de software executados.
Segundo Pressman (1995, p. 23), “A qualidade de software frequentemente é suspeita.
Só recentemente começamos a entender a importância dos testes de software sistemáticos e
tecnicamente completos. Somente agora estão começando a surgir conceitos quantitativos
sólidos de confiabilidade e garantia de qualidade de software. ”
A entrega de um software de qualidade é de extrema importância para mantermos a
satisfação e confiança do cliente. Para garantir a entrega, é necessário manter uma equipe de
testes para que os defeitos sejam descobertos ainda em produção, visando à qualidade do
produto.
Conforme Caetano (2009) relata em seu artigo, se considerarmos o tamanho dos
softwares atuais e sua complexidade, dificilmente conseguiremos executar todos os testes
envolvidos para uma cobertura de 100%. Dificultando ainda mais esta situação, temos os
prazos curtos e orçamentos limitados.
Desta forma, este trabalho se propõe pesquisar técnicas e metodologias para
priorização dos testes, de forma que acobertem uma maior porcentagem possível, garantindo
uma entrega de maior qualidade e evitando gastos no tempo de produção e gastos futuros de
manutenção.
18
1.4 ESTRUTURA DA MONOGRAFIA
Esta monografia está dividida em 5 capítulos. A seguir, será apresentada estrutura do
trabalho:
Capítulo 1 – Introdução: este capítulo apresenta a introdução, problema, os
objetivos e a justificativa do trabalho.
Capítulo 2 – Revisão bibliográfica: este capítulo apresenta temas relacionados
à Qualidade, Processos e Testes de software.
Capítulo 3 – Metodologia: Neste capitulo, é descrita qual a metodologia de
pesquisa utilizada para desenvolver esta monografia.
Capitulo 4 – Aplicação da Priorização de casos de testes - estudo de caso
Capitulo 5 – Conclusão e trabalhos futuros
19
2 REVISÃO DA BIBLIOGRÁFICA
Neste capítulo, apresentaremos a fundamentação teórica sobre os temas de Engenharia
de Software, Qualidade de Software e Testes.
2.1 ENGENHARIA DE SOFTWARE
Segundo Pressman (2011), nos dias atuais, os softwares se incorporaram em sistemas
de todas as áreas, fabricas, transportes, medicina, telecomunicações, indústrias, máquinas, isto
é, uma lista quase infindável. Ninguém poderia prever que estes milhares de softwares
precisariam ser corrigidos, adaptados e ampliados com o passar do tempo.
Conforme aumenta a importância do software, isso também é acompanhado pela
evolução das ferramentas que facilitam o seu desenvolvimento com uma melhor qualidade.
Porém os softwares não conseguem garantir uma total e perfeita funcionalidade do produto
desenvolvido, o surgimento de uma tecnologia que garanta isso, ainda, é incerta, pois os
softwares não só facilitam a distribuição da informação, como também, em muitos casos, eles
são responsáveis diretos e indiretos pela vida de muitas pessoas. Para um software resultar em
um produto de qualidade, surge a engenharia de software.
“A engenharia de software é uma disciplina de engenharia relacionada a todos os
aspectos da produção de software, desde os estágios iniciais de especificação do sistema até
sua manutenção, depois que este entrar em operação”. (Sommerville,2007, p.15).
Segundo Finkelstein (1996), a Institute of Electrical and Electronics Engineers define
a Engenharia de software como: A aplicação de uma abordagem sistemática, disciplinada e
quantificável no desenvolvimento, na operação e manutenção de software; isto é, a aplicação
de engenharia ao software.
Esta engenharia visa ao desenvolvimento do software de uma forma, segura, com
qualidade e sustentabilidade financeira, oferecendo a forma mais apropriada para garantir
estes quesitos.
20
2.1.1 Processo de Desenvolvimento de Software
Segundo Sommerville (2007, p. 6), o processo de software é um conjunto de
atividades e resultados associados que produzem um produto de software. Este autor afirma
que em todo processo de software existem basicamente quatro atividades fundamentais que
são comuns a todo processo:
1. Especificação de software: engenheiros juntamente com os clientes definem o
software que será produzido e as restrições para sua operação.
2. Desenvolvimento de software: o software é projetado e programado.
3. Validação de software: atividade na qual o software é verificado para garantir
se é o que o cliente deseja.
4. Evolução de software: são feitas modificações no software para se adaptar às
mudanças dos requisitos tanto do cliente quanto do mercado.
Diferentes autores podem agrupar ou nomear essas atividades de forma um pouco
diferente, mas todos eles concordam no desenvolvimento dessas atividades básicas. Também,
de acordo com o tipo de software, podem existir mais ou menos fases, algumas podem ser
feitas em conjunto ou com diferente ordenação, para isto existem diferentes modelos de
processo de desenvolvimento.
2.1.2 Modelo de Processos de desenvolvimento de software
Conforme Sommerville (2007, p. 6), o modelo de processo de software é uma
descrição simplificada do processo de software que apresenta uma visão do mesmo. Os
modelos de processo incluem as atividades, que fazem parte do processo de software, os
produtos de software e os papéis das pessoas envolvidas na engenharia de software.
21
Segundo Pressman (2011, p. 53), todos os modelos de software podem acomodar
atividades metodológicas genéricas, porém cada um deles dá uma ênfase diferente a essas
atividades e define um fluxo de processos que invoca cada atividade metodológica, tarefas e
ações de engenharia de software de forma diversa.
Os seguintes modelos são alguns dos mais conhecidos:
1. Modelo Cascata:
Algumas vezes chamado de ciclo de vida clássico, sugere uma abordagem sequencial
e sistemática para o desenvolvimento de software, iniciando com o levantamento de requisitos
das necessidades do cliente, posteriormente a fase de planejamento, modelagem, construção,
emprego e, por fim, o suporte contínuo do software concluído. (PRESSMAN, 2011, p. 59).
2. Modelo em V:
Descreve a relação entre ações de garantia de qualidade e as ações associadas à
comunicação, modelagem e atividades de construção iniciais. Conforme a equipe de software
desce no lado esquerdo do V, os requisitos básicos dos problemas são refinados em
representações mais detalhadas de forma progressiva e técnicas do problema e sua solução.
Após o código ser gerado, a equipe se desloca para o lado direito do V, realizando uma série
de testes com a finalidade de validar cada um dos modelos criados à medida que a equipe se
move para baixo no lado esquerdo do V. A grande diferença com relação ao modelo clássico
seria que este modelo fornece uma melhor forma para visualizar a verificação e as validações
aplicadas ao trabalho de engenharia anterior. (PRESSMAN, 2011, p. 60).
3. Modelo Evolucionário
Modelos evolucionários são iterativos, pois apresentam características que
possibilitam desenvolver versões cada vez mais completas de software. (PRESSMAN, 2011,
p. 62).
22
4. Modelo Incremental
Este modelo combina elementos do fluxo de processos lineares e paralelos. Aplica
sequencias lineares de forma escalonada, à medida que o tempo avança. Cada sequência linear
gera “incrementais”, entregáveis, aprovados e liberados de software, de maneira similar aos
incrementais gerados por um fluxo de processos evolucionário.
5. Modelo Concorrente
Possibilita à equipe representar elementos concorrentes e iterativos de qualquer um
dos modelos descritos anteriormente. Define uma série de eventos que irão disparar transições
de estado para estado para cada uma das atividades, ações ou tarefas da engenharia de
software. (PRESSMAN, 2011, p. 67).
6. O Processo Unificado
Enfatiza o papel da arquitetura de software e ajuda ao arquiteto a manter o foco nas
metas corretas. Sugere um fluxo de processos interativo e incremental, fornecendo uma
sensação evolucionária, essencial no desenvolvimento de software moderno. (PRESSMAN,
2011, p. 71).
7. Desenvolvimento Ágil.
A engenharia de software ágil une filosofia com um conjunto de princípios de
desenvolvimento. A filosofia defende a satisfação do cliente e a entrega de incremental
prévio, equipes pequenas e motivadas, métodos informais, artefato de engenharia de software
mínimos e acima de tudo simplicidade no desenvolvimento geral. Os princípios de
desenvolvimento priorizam as entregas mais que a análise e o projeto, também priorizam a
comunicação ativa e continua entre clientes e desenvolvedores. (PRESSMAN, 2011, p. 81).
8. Extreme Programming – XP (Programação Extrema)
Para ilustrar um processo ágil, surge a Extreme Programming – XP (Programação
Extrema), que emprega uma abordagem orientada a objetos como seu paradigma de
23
desenvolvimento preferido e envolve regras e práticas constantes no contexto de quatro
atividades metodológicas: planejamento, projeto, codificação e testes. Um projeto XP segue
de forma rigorosa os princípios KIS (keep it simple, ou seja, preserve a simplicidade). É
preferível um projeto simples do que uma representação mais complexa. (PRESSMAN, 2011,
p. 88).
9. Scrum
Os seus princípios são constantes com o manifesto ágil e utilizados para orientar as
atividades de desenvolvimento dentro de um processo que incorpora as atividades estruturais:
requisitos, análise, projeto, evolução e entrega. Em cada atividade, ocorrem tarefas a realizar
dentro de um padrão de processo. O trabalho realizado dentro de uma Sprint é adaptado ao
problema em questão e definido, e, muitas vezes, modificado em tempo real pela equipe
Scrum. Este método enfatiza o uso de um conjunto de padrões de processos de software que
provaram ser eficazes para projetos com prazos e entrega apertados, requisitos mutáveis e
críticos de negócio. (PRESSMAN, 2011, p. 95).
10. Atividades Guarda-Chuva
Pressman (2006, 2011) complementa que as atividades genéricas são complementadas
por uma série de atividades guarda-chuva, entre as quais podem ser citadas:
Acompanhamento e controle do projeto de software: permite à equipe de
software avaliar o processo com base no plano de projeto e realizar as ações
necessárias para manter o cronograma;
Gestão de risco: avalia os riscos que podem afetar o resultado do projeto ou a
qualidade do produto;
Garantia de qualidade de software: define e conduz as atividades necessárias
para garantir a qualidade do software;
Revisões técnicas formais: avaliar os produtos de trabalho da Engenharia de
Software, num esforço para descobrir e remover erros, antes que eles sejam
propagados para a próxima atividade;
24
Medição: define e reúne medidas de processo, projeto e produto que ajudam a
equipe a entender um software que satisfaça às necessidades do usuário;
Gestão de configuração de software: gerência dos efeitos das modificações
ao longo de todo o processo de software.
Gestão de usabilidade: define os critérios para a reutilização dos produtos de
trabalho, inclusive componentes de software;
Preparação e produção do produto de trabalho: tratam sobre os
documentos, modelos, registros, formulários e listas.
2.2 QUALIDADE DE SOFTWARE
Segundo Pressman (2011), no desenvolvimento de software, a qualidade de um
projeto engloba o grau de atendimento às funções e características especificadas no modelo de
requisitos.
Um bom software, assim como os serviços que ele fornece, possuem atributos
associados que demonstram a qualidade do software. Estes atributos refletem o
comportamento do software e estão ligados diretamente a sua aplicação, por exemplo, um
software bancário deve ser seguro, um jogo interativo deve ser ágil. Um software de
qualidade deve ter um conjunto de atributos. Os seguintes são alguns exemplos de atributos
de um software de qualidade. (SOMMERVILLE, 2007, p. 9).
Facilidade de Manutenção: deve ser escrito de forma que possa evoluir e
atender as necessidades do cliente. É um atributo fundamental, pois a mudança
do software é inevitável em um ambiente de negócios de constante evolução.
Confiança: este nível pode conter confiabilidade, proteção e segurança. Não
pode causar danos físicos ou econômicos no caso de falhas.
Eficiência: não deve desperdiçar recursos do sistema. Eficiência inclui tempo
de resposta, tempo de processamento, utilização de memória, entre outros.
25
Usabilidade: O software deve ser usável, sem muito esforço pelo tipo de
usuário para o qual ele foi planejado. Deve apresentar interface amigável e
documentação adequada.
Para um software possuir qualidade em todos estes itens, ele deve ser muito bem
testado antes de ser colocado em uso.
2.3 TESTES DE SOFTWARE
Desenvolver um software com todos os seus processos está longe de ser uma tarefa
simples.
De acordo com Delamaro, Maldonado e Jino (2007, p.1), a atividade de
desenvolvimento “[...] pode se tornar bastante complexa, dependendo das características e
dimensões do sistema a ser criado.” Desenvolver um software que atenda às necessidades dos
clientes depende principalmente da habilidade e interpretação das pessoas que o constroem.
Segundo Koscianski e Soares (2007, p. 337), “o objetivo do teste é encontrar defeitos,
revelando que o funcionamento do software em uma determinada situação não está de acordo
com o esperado.” Inthurn (2001, p.51) afirma que o teste tem como objetivo “[...] aprimorar a
produtividade e fornecer evidências da confiabilidade e da qualidade do software em
complemento a outras atividades de garantia de qualidade ao longo do processo de
desenvolvimento de software. ”
As finalidades do teste são: adquirir confiança no fato de que um sistema pode ser
usado com uma margem de risco aceitável; fornecer informações que impeçam o
aparecimento de erros; fornecer informações que ajudem a detectar erros antes do momento
em que eles normalmente se manifestariam; descobrir erros e deficiências de um sistema;
determinar quais são os recursos de um sistema; fornece informações sobre a qualidade de um
software. (HETZEL, 1987, p. 17).
Molinari (2003, p. 22 e 23) diz que “o custo total efetivo do gerenciamento de
qualidade é a soma dos quatro fatores: prevenção + inspeção + falha interna + falha externa.”
26
O objetivo da prevenção é identificar os erros antes que eles apareçam, ou seja, buscar ações
que previnam o aparecimento de defeitos. Já o custo de inspeção tem como foco a medição,
avaliação e auditoria dos produtos conforme os padrões e especificações. O custo para corrigir
uma falha identificada antes da entrega do software para o cliente, falhas identificadas nos
testes, é chamado de custo de falhas internas. Por fim, custos de falhas externas são os custos
para corrigir uma falha identificada pelo cliente. “Quanto mais falhas externas forem
encontradas, mais desastroso será para a reputação da organização ou resultará em perda de
faturamento futuro.”
Falhas humanas são responsáveis por grande parte dos problemas identificados. Por
isso, mesmo utilizando ferramentas e métodos, os erros acabam surgindo. (DELAMARO;
MALDONADO; JINO, 2007).
Bug (do inglês inseto) é um “defeito no software que, caso mantido, pode provocar
falhas no sistema.” (HETZEL, 1987, p. 15). Por isso, “A meta de um testador de software é
achar bugs, achando-os o mais cedo possível, para que possam ser consertados o quanto antes.
” Por outro lado, as pessoas que trabalham na área de garantia de qualidade têm como meta
“criar e reforçar padrões e métodos de melhoria de desenvolvimento do processo e prevenir a
ocorrência de “bugs”.
2.3.1 Validação e Verificação
Delamaro, Maldonado e Jino (2007) afirmam que as atividades de validação,
verificação e teste têm como principal objetivo garantir que o produto está sendo
desenvolvido conforme o definido e que apresenta o menor número de falhas possível.
A verificação tem como objetivo verificar se o que foi desenvolvido está de acordo
com as necessidades definidas. “Em termos gerais, a verificação diz respeito à atividade
global de avaliação de software, englobando a revisão, inspeção, teste, análise de desempenho
e auditoria. ” (HETZEL, 1987, 31 p. 14).
27
Para Pressman (2006, p.289), verificação é o “[...] conjunto de atividades que garante
que o software implementa corretamente uma função específica. ” Por outro lado, validação é
“o conjunto de atividades diferentes que garante que o software construído corresponde aos
requisitos do cliente. ” (PRESSMAN, 2006, p. 206). Segundo Hetzel (1987, p.14), validação é
o “processo de avaliação do software no final do processo de desenvolvimento para ratificar o
atendimento das necessidades previamente estabelecidas. ”.
Tradicionalmente teste de software é considerado um processo de validação, isto é,
uma fase do ciclo de desenvolvimento do produto. Depois que o programa é
terminado, o sistema é validado ou testado para determinar sua funcional e
operacional performance. Quando a verificação é incorporada ao teste, o teste corre
durante o desenvolvimento também. É uma prática combinar verificação com
validação no processo de testes. (MOLINARI, 2003, p. 23).
No mesmo contexto, Sommerville afirma que:
Os testes de software, que envolvem executar uma implementação do software com
os dados de teste e examinar as saídas dele e seu comportamento operacional, a fim
de verificar se ele está sendo executado conforme o esperado. Os testes são uma
técnica dinâmica de verificação e validação porque trabalham com uma
representação executável do sistema. (SOMMERVILLE, 2003, p. 358).
“Teste de software é a mais popular estratégia de gerenciamento de risco. São usados
para verificar o encontro dos requisitos com o produto.” (MOLINARI, 2003, p. 28).
Molinari (2003, p. 97) explica que os testes e garantia de qualidade, também chamada
de QA (Quality Assurance), “são usados para descrever um grupo de processos de verificação
e validação de software.”.
2.4 PROCESSO DE TESTE DE SOFTWARE
Assim como a atividade de desenvolvimento, a atividade de testes de software precisa
ter um processo definido. Conforme abordado anteriormente, existem diversos modelos de
28
desenvolvimento de software, entretanto algumas atividades são comuns a todos, e dentro
desse contexto de desenvolver um sistema, existe a atividade de teste de software.
O ciclo de vida de testes pressupõe que sejam realizados testes ao longo de todo o
processo de desenvolvimento. Em determinados pontos, os produtos intermediários
do ciclo de desenvolvimento devem ser revisados com objetivo de criar as condições
necessárias para uma correta implementação, procurando-se identificar defeitos o
mais cedo possível. Os ciclos de vida de testes e de desenvolvimento são totalmente
interdependentes, mas o ciclo de testes é dependente da conclusão dos produtos das
atividades do ciclo de desenvolvimento. (BASTOS et al., 2007, p. 40).
Apesar disso, Myers (1979) nos mostra que aparentemente o conhecimento sobre teste
de software é muito menor em relação a outros aspectos e/ou atividades do desenvolvimento
de software.
O teste de produtos de software evolui basicamente pelas seis etapas apresentadas a
seguir:
Procedimentos iniciais;
Planejamento;
Preparação;
Especificação;
Execução;
Entrega.
2.4.1 Procedimentos iniciais
O plano de teste inicia nessa etapa. O plano de testes é utilizado para documentar o
planejamento da atividade de testes. No plano deve ser observada a base, os requisitos da
aplicação e os requisitos de teste. As principais atividades e os recursos necessários, pessoal e
de ambiente, são descritos no plano de teste. (BASTOS et al., 2007).
Uma boa forma de garantir uma boa especificação de testes é ter requisitos de sistema
bem definidos.
29
Por isso, nos procedimentos iniciais, é feito um “[...] estudo dos requisitos de negócio
que dará origem ao sistema de informação a ser desenvolvido, de modo a garantir que o
mesmo esteja completo e sem nenhuma ambiguidade. ” (BASTOS et al., 2007, p. 45).
Para que o teste seja executado da maneira mais eficaz, “O plano de teste deve incluir
todos os elementos necessários para que os testes sejam executados corretamente. Como
elementos, pode-se considerar os procedimentos a serem cumpridos, o ambiente necessário e
as ferramentas. ” (BASTOS et al., 2007, p. 170).
2.4.2 Planejamento
Antes de executar qualquer atividade, relacionada a testes, desenvolvimento de
software, ou qualquer outra área, deve-se ter um bom planejamento.
Por isso, segundo o International Software Testing Qualifications Board (2007, p. 15),
“planejamento de teste é a atividade que consiste em verificar a missão do teste, definindo os
seus objetivos e especificando as atividades de forma a alcançá-los. ”
Bastos (2007) diz que o planejamento dos testes deve permanecer “ativo” durante todo
o projeto, pois constantemente é necessário avaliar os rumos que o projeto está seguindo.
Na etapa de planejamento, é definida a estratégia de teste e continua-se a elaboração
do plano de teste com a finalidade de “[...] minimizar os principais riscos do negócio e
fornecer os caminhos para as próximas etapas. ” (BASTOS et al., 2007, p. 46).
Segundo o conhecimento prático dos autores, existe um certo receio com o
planejamento, muito se fala de planejamento de testes, e pouco se faz, alguns gerentes
colocam testes em segundo plano, mesmo sabendo das possíveis consequências (quase
sempre) negativas.
A esse respeito Molinari (2003, p. 125) afirma que “planejamento de teste é um
processo. [...]”.
30
2.4.3 Preparação
Para que o teste seja executado de forma correta e precisa, é importante que o
ambiente de teste seja configurado corretamente, e esta fase tem como principal objetivo
organizar o ambiente que será utilizado para realização dos testes. Essa configuração abrange
desde os equipamentos até os softwares e ferramentas que serão utilizados para automação.
“A garantia da integridade do ambiente de teste está diretamente relacionada à garantia
de qualidade do produto. ” (BASTOS et al., 2007, p. 85).
Além disso, nessa etapa, é avaliada a necessidade de treinamentos para a equipe.
(BASTOS et al., 2007).
A criação do ambiente de testes “[...] isolado, organizado, representativo e mensurável
garante a descoberta de erros reais, ou seja, aqueles que realmente ocorreriam na produção e
que porventura não foram descobertos em tempo de desenvolvimento. ” (BASTOS et al.,
2007, p. 83).
E, não menos importante, o ambiente de testes reduz a influência externa (BASTOS et
al., 2007). Isso é importante porque as alterações no ambiente podem influenciar
completamente o resultado dos testes, por exemplo, um módulo que estava funcionando em
um ambiente pode não funcionar em outro ambiente.
2.4.4 Especificação
Na fase de especificação, o foco é a documentação de testes, ou seja, a elaboração e
criação dos casos e roteiros de teste.
Dentro desta documentação, podemos citar o Roteiro de Testes que contém os casos
de testes, nele serão incorporados todos os casos de testes de um Caso de Uso.
Portanto, um caso de teste “descreve uma condição particular a ser testada e é
composto por valores de entrada, restrições para a sua execução e um resultado ou
comportamento esperado”. (CRAIG e JASKIEL, 2002).
31
Segundo Inthurn (2001, p.78), “um caso de teste é um documento que descreve uma
entrada, ação ou evento e uma resposta esperada, a fim de determinar se uma característica da
aplicação está sendo executada corretamente ou não. ”
Os casos de teste contêm uma identificação, a descrição dos objetivos, condições de
entrada, os passos e resultados esperados ao executar os passos. Os casos de teste “[...]
refletem os requisitos que serão verificados durante o teste do software. ” (INTHURN, 2001,
p. 78).
Ou seja, para cada Caso de Uso, haverá pelo menos um documento de Especificação
ou Roteiro de testes. O documento de Especificação de testes terá as ações necessárias para
testar determinada função do sistema.
Os casos de teste e os roteiros de teste devem ser elaboradas dinamicamente durante
o decorrer do projeto de teste. Isso equivale a dizer que eles serão elaborados à
medida que a equipe de desenvolvimento liberar alguns módulos ou parte do sistema
para testes. (BASTOS et al., 2007, p. 47).
2.4.5 Execução
Na fase de execução, os testes são executados seguindo os casos e roteiros de testes.
“Os testes deverão ser executados integralmente, por regressão ou parcialmente, sempre que
surgir alguma mudança de versão dos programas em teste e nos ambientes de teste
preparados, conforme previsto na estratégia e nos planos de teste.” (BASTOS et al., 2007, p.
47).
A execução dos casos de teste pode ser feita de forma manual ou automatizada. Os
resultados obtidos em cada teste devem ser anotados. Os erros ou problemas devem ser
relatados. Após a correção dos erros, é necessário executar novamente alguns testes para
confirmar se realmente o problema foi solucionado. (INTERNATIONAL SOFTWARE
TESTING QUALIFICATIONS BOARD, 2007).
32
2.4.6 Entrega
A entrega é o marco final do processo de testes. A documentação utilizada é
armazenada em repositórios para futuras execuções e consultas.
Depois disso, é realizada a documentação das lições aprendidas e melhorias
encontradas durante todo o processo de testes, além de ser elaborado um relatório com a
descrição das conformidades e não conformidades identificadas.
Nessa fase, é feita a verificação do que foi entregue e do que havia sido planejado.
Além disso, como já foi relatado, são avaliadas as lições aprendidas com objetivo de buscar
aprimorar a maturidade dos testes. (INTERNATIONAL SOFTWARE TESTING
QUALIFICATIONS BOARD, 2007).
2.5 EQUIPE DE TESTES
Segundo Bastos e outros (2007, p. 17), em grande parte das empresas, os testes são
executados pelos desenvolvedores ou até mesmo pelos clientes. Esse cenário está longe de ser
o ideal, isso porque “quem poderia garantir que um software testado pelos próprios
desenvolvedores está corretamente testado”?
Com toda a certeza, existem exceções, mas a melhor maneira de testar um software é
ter um processo de teste claramente definido. ” Nesse processo de testes, os profissionais
desenvolvem diferentes tarefas as quais podem requerer diversas habilidades. Por isso, a
seguir, serão apresentados os principais cargos e funções da área de testes.
33
2.5.1 Cargos e funções
O gestor de qualidade é responsável por verificar se o produto atende as necessidades
do cliente e se foi desenvolvido conforme os requisitos. A principal função do gestor de
qualidade é controlar a qualidade dos produtos. (BASTOS et al.,2007).
O líder do projeto de testes é a pessoa responsável pela liderança de um ou mais
projetos de teste. (BASTOS et al.,2007). Segundo o International Software Testing
Qualifications Board (2007), as atividades típicas de um líder de teste são: coordenar a
estratégia de testes, planejar os testes, considerando os riscos do projeto, montar o relatório ao
término dos testes, dentre outras.
O arquiteto de testes é a pessoa responsável por montar os ambientes de teste, escolher
as ferramentas de teste e capacitar a equipe para utilizar o ambiente de testes. (BASTOS et
al.,2007).
O analista de teste é o técnico responsável pela criação dos casos de teste. Já o testador
executa os casos de teste criados pelo analista de testes. Em alguns casos, o próprio testador
cria os casos de teste. Além disso, o testador pode auxiliar na configuração do ambiente e
automação dos testes. (INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS
BOARD, 2007).
O Analista de Teste geralmente tem experiência em programação, e deve ter o
conhecimento do sistema e/ou da aplicação em teste, e tem experiência em vários tipos e
técnicas de testes, tem um entendimento no que é uma falha ou defeito. Ele tem como papel
monitorar detalhadamente o processo de testes e o resultado de cada ciclo, se for necessário,
além de elaborar os artefatos de testes.
Já o testador tem experiência em diversos tipos de testes, conhece as técnicas e alguns
deles têm o conhecimento sobre automação de testes. Seu papel é executar os testes, reportar
os defeitos e, dependendo do caso, automatizar os testes.
34
2.6 TIPOS DE TESTE DE SOFTWARE
A atividade de teste consiste de uma análise dinâmica do produto, ela é uma atividade
importante para a identificação e correção de erros que existem no sistema.
Segundo Peters e Pedrycz (2001, p. 383), “o teste de software é executado em níveis
diferentes por todo o ciclo de vida do software.” O teste dos componentes individuais é o
primeiro a ser feito. Mas testar componentes isolados não é o bastante para garantir que o
software esteja funcionando. Para isso, existe a necessidade de realizar os testes de integração.
Para completar a atividade de testes, existem os testes de sistema e de aceitação.
A seguir são detalhadas as fases e técnicas de testes de software.
2.6.1 Testes unitários
Os primeiros testes que o desenvolvedor deve executar são os testes unitários. Eles são
elaborados durante a fase de desenvolvimento. Tem como principal objetivo testar a menor
funcionalidade existente do software, isto é, isolar funcionalidades do sistema, e verificar se
essas funcionalidades têm como retorno o esperado, em relação à entrada informada.
Os testes unitários, também chamados de testes de componentes, são o “estágio mais
baixo da escala de testes e são aplicados, nos menores componentes de código criados,
visando garantir a que estes atendam as especificações, em termos de características e
funcionalidade. ” (RIOS; TRAYAHÚ FILHO, 2006, p. 13).
Segundo Molinari (2003), os testes unitários são feitos no nível de um componente ou
uma classe, ou seja, o seu objetivo é testar somente um “pedaço de código”.
O objetivo dos testes unitários é “garantir que a lógica do programa esteja completa e
correta. Garantir que o componente trabalhe conforme projetado.” (PETERS; PEDRYCZ,
2001, p. 383).
O teste unitário deve verificar a integridade dos dados armazenados durante a
execução do código, se todos os caminhos estão sendo executados pelo menos uma vez e os
35
caminhos de tratamentos de erros, ou seja, o teste deve verificar o comportamento do software
quando são inseridos valores não verdadeiros. (INTHURN, 2001).
Geralmente, quem executa esse tipo de testes é o próprio desenvolvedor, pois é
importante conhecer o código fonte do sistema em questão. Então, logo que desenvolvido, o
programador executa este tipo de teste, garantindo que o que ele acabou de programar está
funcionando como o especificado.
Os testes unitários podem ser considerados como teste da caixa preta, citados mais
adiante.
2.6.2 Testes de integração
Durante o Teste de integração, os módulos são testados em grupo, ele é realizado
depois dos testes unitários e antes do teste de sistema.
Testar o software dividido por partes garante que cada parte funciona, mas não garante
que as parte integradas funcionam. Os testes de integração são realizados para “garantir que
um ou mais componentes combinados (ou unidades) funcionam corretamente. ” (MOLINARI,
2003, p. 160).
Portanto, esse teste é alimentado pelos módulos que já foram testados
individualmente.
Segundo Rios e Trayahú Filho (2006, p. 13 e 14), o objetivo do teste de integração é
“[...] assegurar que as interfaces funcionem corretamente e que os dados são processados de
forma correta, conforme as especificações.”.
Os testes de integração podem ser realizados de forma incremental, ou seja, os testes
são executados à medida que os módulos são acrescentados até que todos os casos de teste
sejam executados. (RIOS; TRAYAHÚ FILHO, 2006).
36
2.6.3 Testes de sistema
Esse tipo de teste é executado para avaliar o software com objetivo de buscar defeitos
por meio da utilização do sistema, como se fosse o usuário final no comando dos testes.
Os testes de sistema são executados pela equipe de testes e têm como foco a execução
do sistema como um todo. Esse teste simula a utilização normal do sistema, “[...] sendo
testadas todas as suas funções de forma mais próxima possível do que irá ocorrer no ambiente
de produção.” (RIOS; TRAYAHÚ FILHO, 2006, p.14).
2.6.4 Testes de aceitação
Esses testes são realizados geralmente por um restrito grupo de usuários finais do
sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu
comportamento está de acordo com o solicitado.
Os testes de aceitação são “[...] realizados pelos usuários, visando a verificar se a
solução atende aos objetivos do negócio e a seus requisitos, no que diz respeito à
funcionalidade e à usabilidade, antes da utilização no ambiente de produção. ” (RIOS;
TRAYAHÚ FILHO, 2006, p. 15).
Segundo Peters e Pedrycz (2001, p. 383), os testes de aceitação servem para
“determinar se os resultados do teste satisfazem aos critérios de aceitação dos participantes do
sistema de software. ”
O teste de aceitação não deve ser executado somente no final do processo de
desenvolvimento. O correto é executar testes nos produtos intermediários, isso porque quanto
antes o problema for identificado, menor será o custo de correção. (BASTOS et al., 2007).
37
2.7 TÉCNICAS DE TESTES
Com o aprimoramento na execução de testes surgiram diversas maneiras de se testar
um software. Segundo as experiências profissionais dos autores, existem algumas técnicas
que foram muito aplicadas em sistemas desenvolvidos em linguagens estruturadas e que até
hoje têm grande importância nos sistemas orientados a objeto.
Apesar de os tipos de desenvolvimento serem diferentes, o principal objetivo dessas
técnicas ainda continua a ser o mesmo: encontrar falhas e defeitos no software. As principais
técnicas existentes são: técnica funcional e estrutural.
As duas estratégias, ou técnicas, são “[...] complementares e não exclusivas, o que
significa que teremos um produto de maior qualidade se ambos os processos foram aplicados
nas etapas de validação do software. ” (BARTIÉ, 2002, p. 104).
2.7.1 Testes funcionais ou caixa-preta
Segundo Myers (2004), também chamada de teste funcional, teste comportamental,
orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avalia o
comportamento externo do componente de software, sem se considerar o comportamento
interno do mesmo.
Nessa técnica de teste, o componente de software a ser testado é manuseado como
uma caixa-preta, isto é, não é considerado o código do sistema, conforme ilustrado na Figura
1.
São informados os dados de entrada, o teste é executado e o resultado da saída é
comparado a um resultado já esperado, assim, avaliando se o comportamento está correto ou
se existe um defeito. Há sucesso no teste se o resultado gerado pelo sistema for o que se
esperava.
Figura 1 - Técnica de Teste Funcional.
38
Fonte: os autores.
Testes funcionais podem ser considerados os: testes dos requisitos, testes de regressão,
testes de tratamento de erros e testes de interconexão.
A técnica de teste funcional é aplicável a todos os níveis de teste (PRESSMAN,
2006).
Os testes funcionais são utilizados para verificar se as funcionalidades estão de acordo
com os requisitos especificados. Esse tipo de teste é realizado sem qualquer conhecimento do
código. (RIOS; TRAYAHÚ FILHO, 2006).
Os testes caixa-preta procuram identificar erros nas interfaces, na estrutura de dados
ou acesso a banco de dados externos, funções ausentes ou incorretas ou problemas de
desempenho. (MOLINARI, 2003).
2.7.1.1 Testes de requisitos
Como o próprio nome já explica, os testes de requisitos têm como objetivo validar se
os requisitos foram implementados corretamente.
“Os testes de requisitos devem ser considerados formalmente realizados após os
programas se tornarem operacionais, embora os requisitos possam ser testados
individualmente durante as fases anteriores do ciclo de vida. ” (BASTOS et al., 2007).
Portanto, uma boa prática de testes é avaliar os requisitos descritos pelo Analista de
sistemas e apontar falhas nos requisitos, principalmente no que se diz respeito a interferência
ou mal entendimento desses requisitos para a criação dos casos de testes.
Ou seja, se um requisito está mal escrito, com uma dupla interpretação, por exemplo,
isso pode interferir na criação dos casos de testes. Por isso, esses testes são executados antes
39
mesmos do ciclo de vida, para que o analista de sistemas corrija os requisitos, e a criação dos
casos de testes seja desenvolvida de maneira correta.
2.7.1.2 Testes de regressão
Os testes de regressão não correspondem literalmente a um nível de teste, contudo é
uma atividade muito importante para garantir que, quando é alterada alguma funcionalidade
no sistema o que já estava funcionando, continue funcionando corretamente, ou seja, impede
“efeitos colaterais”. Tem como objetivo aplicar, a cada nova versão do software, os testes que
já foram executados nas versões ou ciclos de testes anteriores.
O software é modificado cada vez que um novo módulo ou uma nova funcionalidade é
adicionado. Essa modificação pode gerar problemas no software que não existiam. Por isso,
existe a necessidade de executar testes novamente após a realização de modificações no
software, para garantir que não existem efeitos colaterais indesejáveis. Esse tipo de teste é
chamado de teste de regressão. (PRESSMAN, 2006).
Testes de regressão são particularmente importantes durante a manutenção, pois
nessa fase é mais frequente que alterações realizadas afetem outras porções de
código. São usados também durante a integração, para confirmar a estabilidade dos
módulos já integrados anteriormente. (PAULA FILHO, 2001, p. 172).
Segundo Pressman (2006, p. 300), “o teste de regressão pode ser conduzido
manualmente, reexecutando um subconjunto de todos os casos de teste ou usando ferramentas
automatizadas de captação/re-execução. ”
Este teste pode ser aplicado em qualquer nível de teste.
40
2.7.1.3 Teste tratamento de erros
Nesse teste, é tratado principalmente o cenário em que acontece algum erro inesperado
ou que não faça parte da execução normal do software, como, por exemplo, um Web Service
não estar disponível, assim, verificando se o sistema está tratando corretamente essa situação.
“Os testes de tratamento de erros determinam a capacidade do sistema de tratar
apropriadamente transações incorretas. ” (BASTOS et al., 2007). Durante a construção,
devem ser feitos tratamentos no código para resolver erros que possam aparecer durante a
execução do software.
2.7.1.4 Testes de interconexão
Esse tipo de teste é realizado, porque softwares de aplicação costumam estar
conectados com outros softwares de mesmo tipo, ou não, comunicando-se o tempo todo entre
si.
Os testes de interconexão têm como objetivo validar a conexão entre softwares. O
objetivo é verificar se os dados são transferidos corretamente. “Os testes de interconexão
devem ser conduzidos sempre que existir uma mudança nos parâmetros entre softwares de
aplicações. ” (BASTOS et al., 2007, p.64).
Um bom exemplo é o caixa eletrônico de um banco, pois a interface é um sistema
(geralmente desenvolvida em uma linguagem orientada a objeto, com uma interface
“amigável”), e a parte de processamento de dados é totalmente diferente (muitas vezes
desenvolvida uma linguagem estrutural, completamente separada da interface). Nesse caso,
são fornecidas entradas por um sistema, o processamento dos dados recebe esses dados,
processa e retorna uma saída.
41
2.7.2 Teste estrutural ou caixa-branca
Essa técnica trabalha diretamente sobre o código fonte do componente de software
para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos e
teste de caminhos lógicos. (PRESSMAN, 2005).
Para realizar os testes de caixa-branca, é necessário que o profissional de testes
conheça a tecnologia empregada pelo software, bem como possua um adequado
conhecimento da arquitetura interna da solução, ou seja, esse profissional deverá ter
acesso a fontes, estruturas dos bancos de dados e realizar todos os testes previstos no
processo de validação de componentes de software. (BARTIÉ, 2002, p. 104 e 105).
O objetivo do teste de caixa-branca é garantir que as linhas de código estão corretas e
serão executadas pelo menos uma vez. (MOLINARI, 2003). Assim, pode se dizer que essa
técnica avalia o comportamento interno do software, conforme ilustrado na Figura 2.
Figura 2 - Técnica de Teste Estrutural.
Fonte: os autores.
Os seguintes testes são estruturais: teste de estresse, teste de performance, teste de
recuperação, teste de operação, teste de conformidade e testes de segurança.
2.7.2.2 Testes de estresse
Alguns autores chegam a definir como uma técnica de teste caixa cinza, que seria um
mesclado do uso das técnicas de caixa preta e caixa branca.
42
Segundo Finkelstein (1996), a partir dos testes de estresse, torna-se possível observar o
comportamento do sistema durante situações críticas, identificando falhas não toleráveis e
potencialmente difíceis de serem encontradas em situações normais de funcionamento.
O teste de estresse é realizado para confrontar os programas com situações
anormais, dessa forma, o sistema é carregado com volumes não usuais com a
intenção de pará-lo. Nesse momento, é monitorada a perda de desempenho do
sistema e a sua suscetibilidade de falhas durante estas cargas. Se ele para como
resultado de uma alta carga, este deverá passar por mais alguns testes de
recuperação. (INTHURN, 2001, p.64).
2.7.2.3 Teste de performance
Também, considerados testes de caixa cinza, os testes de performance, os testes de
performance ou de desempenho, têm como objetivo verificar se o software atende os
requisitos de desempenho definidos. É fundamental que os requisitos estejam claros e bem
definidos, pois esses testes são realizados em cima dos requisitos não funcionais do sistema, e
os cenários de teste também são fundamentais para este teste.
Os testes de performance podem ser executados simulando o acesso de n usuários à
mesma informação ao mesmo tempo, simulando o trafego intenso na rede ou simular que n
usuários estão executando a mesma transação. (BARTIÉ, 2002).
“O teste de desempenho preocupa-se com o rendimento, tempo de resposta e
capacidade – especialmente a capacidade do banco de dados. ” (INTHURN, 2001, p. 65).
43
2.7.2.4 Teste de recuperação
Os testes de recuperação “validam a capacidade e qualidade da recuperação do
software após ‘crashes’, falhas de hardware ou outros problemas catastróficos. ” (RIOS;
TRAYAHÚ FILHO, 2006, p. 16).
Ou seja, é a capacidade de reiniciar operações após a perda da comunicação de uma
aplicação. Por exemplo: Ao desligar o computador, queda de energia elétrica, entre outros,
garantindo a continuidade das operações após um desastre.
Segundo Bastos e outros (2007, p. 52), “a recuperação é a capacidade de reiniciar
operações após a perda da integridade de uma aplicação. ” O processo de recuperação inicia
com a volta da aplicação ao ponto anterior ao problema. O próximo passo é o
reprocessamento de todas as transações até o ponto de falha.
Algumas aplicações suportam soluções de missão crítica, exigindo alto índice de
disponibilidade do software. Nesse caso, a arquitetura da aplicação deve ser
tolerante às falhas, ou seja, no caso de erros de qualquer natureza, o software deve
ter a capacidade de se manter em execução até que a condição de impedimento
desapareça. Os testes de recuperação devem também contemplar os procedimentos
de recuperação do estado inicial da transação interrompida, impedindo que
determinados processamentos sejam realizados pela metade e sejam futuramente
interpretados como completos. (BARTIÉ, 2002, P. 118 e 119).
2.7.2.5 Teste de segurança
Este teste é importante, pois: “Algumas informações, se reveladas ou adulteradas,
podem comprometer o negócio ou aumentar a vantagem competitiva dos concorrentes. ”
(BASTOS et al., 2007, p. 56). Assim, tendo como principal objetivo garantir que os dados do
sistema não são roubados, testando a vulnerabilidade do sistema.
“Testes de segurança existem para identificar as vulnerabilidades e repará-las em
seguida. ” (MOLINARI, 2003, p. 189). Rios e Trayahú Filho (2006, p.16) afirmam que esse
tipo de teste valida a “proteção do software contra acesso interno ou externo não autorizado. ”
44
Segundo Bartié (2002), o objetivo do teste de segurança é identificar as falhas que
possam comprometer a fidelidade e sigilo das informações ou até mesmo perda de dados.
Molinari (2002) explica que os testes de segurança simulam a quebra de protocolos de
segurança com objetivo de avaliar o nível de segurança de toda a infraestrutura. Tentar invadir
ou derrubar servidores de dados, descobrir senhas, tentar acessar funcionalidades que
necessitam de perfil avançado, tentar obter informações sigilosas por meio da extração de
backups são exemplos de testes de segurança.
2.7.3 Testes não-funcionais
Além dos testes funcionais e estruturais existem os testes não-funcionais. Segundo
Myers (2004), entre verificações cabíveis, estão a relação da interface com conhecimento do
usuário, a compreensibilidade das mensagens de erro e a integridade visual entre diferentes
componentes.
“O termo não funcional descreve que o teste é executado para medir as características
que podem ser quantificadas em uma escala variável, como o tempo de 45 respostas em um
teste de performance. ” (INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS
BOARD, 2007, p, 27).
Segundo o International Software Testing Qualifications Board (2007, p, 26), o teste
não funcional valida o ‘como’ o sistema trabalha.
Podemos citar como testes não-funcionais os testes de usabilidade e instalação.
2.7.3.1 Testes de usabilidade
O teste de usabilidade tem como principal objetivo verificar a facilidade de uso do
sistema.
45
Esse tipo de teste é importante principalmente para aplicações web porque a
navegação entre as páginas deve ser fácil. (RIOS; TRAYAHÚ FILHO, 2006). Por exemplo,
um sistema com uma ótima usabilidade facilita muito a vida de quem tem algum tipo de
deficiência visual.
Além disso, os testes de usabilidade avaliam a clareza das mensagens e os mecanismos
de ajuda ao usuário, por exemplo, mensagens que avisam o usuário, quando as ações
executadas irão causar danos irreversíveis. (BARTIÉ, 2002).
2.7.3.2 Testes de instalação
Os testes de instalação têm como foco a validação dos procedimentos de instalação do
software.
“A ideia é aplicar as muitas variações de instalação (normal e as alternativas) e avaliar
seu comportamento durante esses procedimentos. Recomenda-se que o próprio usuário realize
essas instalações. ” (BARTIÉ, 2002, p. 117).
2.8 CONSIDERAÇÕES FINAIS
Neste capitulo, abordou os seguintes assuntos:
Qualidade de software;
Engenharia de software;
Processo de desenvolvimento de software;
Modelo de processos de desenvolvimento de software;
Qualidade de software;
Testes de software;
Processo de teste de software;
46
Equipe de testes;
Tipos de testes de software;
Técnicas de testes;
Gerenciamento de Riscos.
Cada tópico abordado é de extrema importância para-se ter o entendimento do que
trata um teste de software. E que é uma fase do desenvolvimento muito importante, pois um
sistema mal testado pode gerar retrabalho, e esse retrabalho é muito mais caro para a
organização do que o próprio desenvolvimento do sistema.
Porém, mesmo sendo uma atividade comprovadamente importante para o
desenvolvimento de software, não é dado a devida importância para essa atividade, tendo
como principal efeito colateral a falta de tempo para executá-los. Com o amadurecimento da
cultura de testes na organização, imagina-se que a verdadeira importância deva-se dar para
essa fase do processo de desenvolvimento.
47
2.9 GERENCIAMENTO DE RISCOS
Este capítulo apresenta o que é um risco para o desenvolvimento de um software e
qual a sua importância, para que futuramente seja possível realizar a priorização do que ser
testado em relação com os maiores riscos principalmente para o software e para a
organização.
2.9.1 Definição de Risco
O Software Engineering Institute (2002) define risco como a possibilidade de sofrer
perda.
Para Bastos (2007), ao avaliar os riscos de um projeto, estamos buscando aqueles fatos
cujas ocorrências poderão acarretar perdas para a empresa (BASTOS, 2007, p. 22).
Ou seja, a perda pode ser para a empresa em geral, ou para o projeto em si, pois, em
desenvolvimento de projeto, a perda representa o impacto sobre o projeto em termos de
diminuição da qualidade do produto final, aumento de custos, atraso na conclusão, ou fracasso
do projeto.
Projetos de software possuem inúmeros fatores de riscos, como requisitos incertos,
tecnologia desconhecida pela equipe, dependência de outros projetos, falta de documentação,
cronograma irreal, ou seja, pouco tempo para execução das atividades, e até mesmo a baixa
moral da equipe.
Para Cooper (2005), risco é a exposição à incerteza, à probabilidade de algo que
poderá acontecer e que terá impacto nos objetivos do projeto. Risco envolve dois fatores: a
probabilidade de ocorrência e as suas consequências. (KENDRICK, 2003).
48
2.9.2 Gerenciamento de Riscos
O gerenciamento de riscos é muito importante, pois este pode impactar diretamente na
qualidade do projeto e na imagem da empresa que desenvolve o software.
Segundo Sommerville (2007), o gerenciamento de riscos está sendo considerado, cada
vez mais, como uma das principais atividades dos gerentes de projeto. Pois, ainda segundo
Sommerville (2007), ele consiste em prever os riscos que podem afetar o cronograma do
projeto ou a qualidade do software que está sendo desenvolvido e tomar providências para
evitar esses riscos Sommerville. (2007 p.15).
Segundo o PMBOK (PMI, 2004), o gerenciamento de riscos visa à identificação de
problemas potenciais e de oportunidades antes que ocorram, com o objetivo de eliminar ou
reduzir a probabilidade de ocorrência e o impacto de eventos negativos para os objetivos do
projeto, além de potencializar os efeitos da ocorrência de eventos positivos.
Segundo Verzuh (2000), a gerência de risco começou a ser largamente utilizada no
século XX, principalmente, nas áreas de saúde, finanças e seguros de vida. Todos os projetos
tratam riscos, pois o lucro depende do balanceamento entre as oportunidades e os riscos bem
calculados.
A ideia principal da gerência de risco é não aguardar passivamente até que um risco se
materialize e se torne um problema, ou acabe com o projeto, mas antecipar o quefazer com
isso, ou seja, a equipe do projeto precisa possuir um comportamento proativo. (ALENCAR,
2005).
Cooper (2005) enfatiza que um bom gerenciamento de risco envolve:
A participação efetiva dos stakeholders (Termo em inglês que se refere a todos
os interessados ou envolvidos no projeto) nos processos;
Ser integrada às outras áreas do gerenciamento do projeto;
Iniciar no início do projeto;
Ser contínua durante todo o ciclo de vida do projeto;
Possuir planejamento.
49
2.9.3 Riscos e Testes
Segundo Sommerville (2007), existem três categorias de riscos relacionadas ao
processo de desenvolvimento de software:
1. Riscos de projeto são aqueles que afetam o cronograma ou os recursos do
projeto. Um exemplo pode ser a perda de um projetista experiente;
2. Riscos do produto são aqueles que afetam a qualidade ou desempenho do
software está sendo desenvolvido. Um exemplo pode ser um componente
comprado não funcionar conforme o esperado;
3. Riscos de negócio são aqueles que afetam a organização que desenvolve ou
adquire o software. Por exemplo, um concorrente que lança um produto é um
risco de negócio, afirma Sommerville (2007 p.15).
Esta ligação acorre porque um teste mal feito em um software pode ser um risco para
diversos fatores, entre eles os mais notórios são para o produto e para o negócio. Para o
produto, pois um defeito pode aparecer para o cliente se o teste não foi realizado
adequadamente, com mais frequência. Para o negócio, pois afeta negativamente a imagem da
empresa.
Para Bastos (2007), a atividade de testar o software está bastante ligada ao risco:
Todos sabemos que os testes custam dinheiro e que, quanto maior a cobertura dos
testes, maior o investimento para garantir que nenhum defeito acorrerá quando o
software estiver em produção. Mas as empresas só vão concordar em gastar recursos
com testes caso a ocorrência de um defeito seja um risco para o negócio. (BASTOS,
2007, p. 22).
Bastos (2007) diz que o risco é um dos elementos mais importantes a ser trabalhado no
momento de se elaborar o projeto de teste de uma aplicação. (BASTOS, 2007, p. 22).
50
Ou seja, os testes devem ser priorizados para o que tem maior risco, seja para o
negócio, para o produto ou para o projeto em si, porém, como as empresas buscam o lucro, o
que causa maior risco para o negócio é o que é mais levado em consideração.
Bastos (2007) diz que, em geral, os testadores tentam cobrir as partes mais importantes
do software, aquelas nas quais se concentrarão maiores riscos para o negócio. Durante a
elaboração do Plano de Testes, é a esses riscos que serão dados os maiores níveis de
prioridade. (BASTOS, 2007, p. 22).
Como qualquer outra equipe, a equipe de testes deve entregar o projeto e garantir que
o sistema tenha o maior nível de confiabilidade possível. Para Bastos (2007), ao fazer a
análise de riscos, devemos levar em conta o seguinte:
A probabilidade de ocorrência do risco;
O impacto e a perda associados a esse risco (BASTOS, 2007, p. 22).
Tendo isso em vista, podemos citar o exemplo de um site de vendas, em que uma
esquipe de testes deveria priorizar mais a funcionalidade de vendas de produtos, pois, se
alguém desistir de uma compra, ela não funciona, tem muito maior risco do que uma consulta,
por exemplo.
2.9.4 Importância e Benefícios
A ideia de que a gerência de riscos é importante e deve ser integrada à gerência de
projetos é consenso na literatura (DINSMORE, 2005; KEELLING, 2002; KERZNER, 2006;
PMI, 2004; VARGAS, 2002; VERZUH, 2000).
Segundo Dinsmore (2005), o gerenciamento de riscos é a melhor forma para antecipar
ações, reduzir efeitos negativos e finalizar os projetos com sucesso. Executar projetos sem sua
utilização é viver “apagando incêndio”, atrasando projetos e extrapolando custos.
51
Para Vargas (2002), o que faz a gerência de projetos tão importante são fatores
diversos, como o aumento da competitividade, o avanço da tecnologia e as condições
econômicas, que fazem com que os riscos assumam proporções muitas vezes incontroláveis.
Os benefícios da gerência de risco são claros, segundo Boehm (1997):
Á gerência de risco é importante principalmente porque ajuda as pessoas a evitar
desastres, evitar retrabalho, evitar cancelamento de projetos e estimular uma
situação de sucesso nos projetos de software.
2.9.5 Cálculo de riscos
Para calcular os riscos, ou seja, representar em números o tamanho do risco, vários
métodos já foram implementados para realizar essa gestão, dentre os quais se destacam:
ISRAM (KARABACAK, SOGUKPINAR, 2005 apud AMARAL, 2010), AURUM
(EKELHART et al. 2009 apud AMARAL, 2010), ARIMA (LEITNER, SCHAUMULLER-
BICHL 2009 apud AMARAL, 2010) e FMEA (ROTONDARO et al. 2006 apud AMARAL,
2010). Cada método apresenta características específicas e fórmulas distintas para realizar o
cálculo do risco. A seguir, é apresentado o referencial do método ISRAM, pois, foi o método
considerado o mais apropriado para o cálculo do risco na empresa do estudo de caso.
Segundo Karabacak e Sogukpinar (2005 apud AMARAL, 2010) o ISRAM
(Information Security Risk Analysis Method) é um método de análise de riscos, utilizado para
avaliar o risco causado por problemas de segurança da informação. O método propõe a
determinação do risco com base em questionários relacionados com os problemas de
segurança e recorre a uma fórmula específica para o cálculo do índice do risco. Este método
adota uma fórmula simples, frequentemente usada por muitos autores, em que o risco é o
produto da probabilidade de ocorrer uma quebra de segurança pelo valor das consequências a
ela associadas, e é expresso como segue (Fórmula 1).
52
Fórmula 1 – Calculo de riscos de ISRAM
Fonte: AMARAL, 2010.
O ISRAM consiste em sete etapas principais:
1. Identificar os problemas de segurança que envolve a organização em estudo;
2. Listar todos os fatores que podem influenciar a ocorrência de uma quebra de
segurança;
3. Elaborar um questionário com base nos fatores identificados na fase anterior;
4. Elaborar a tabela de conversão das respostas obtidas em função de valores
quantitativos e qualitativos para a probabilidade de ocorrer uma quebra de
segurança e para as consequências de uma quebra de segurança;
5. Aplicação dos questionários aos utilizadores;
6. Cálculo do índice do risco;
7. Análise dos resultados com o intuito de tentar apontar medidas que corrijam o
problema de segurança.
O fator de risco do ISRAM é um valor numérico entre 1 e 25, que corresponde a um
valor qualitativo (alto, médio ou baixo). O valor qualitativo é então utilizado como fator de
decisão. (AMARAL, 2010).
2.9.6 Lei de Brooks
Segundo Brooks (2002), quando um projeto está atrasado, adicionar pessoas ao projeto
servirá apenas para atrasá-lo mais ainda.
Brooks também cita que devemos considerar o tempo gasto em gestão e comunicação
com um número maior de pessoas demais trabalhando em determinado projeto e calcular o
53
tempo de desenvolvimento de qualquer coisa, pois o programador precisa de tempo para
pensar, além do tempo para programar.
3 MÉTODO
A metodologia científica nos traz uma aproximação com o mundo real, com a
realidade, a partir da perspectiva da ciência.
“A metodologia científica possui uma grande função: propor métodos, técnicas e
orientações que possibilitem coletas, pesquisar, organizar, classificar, registrar, interpretar
dados e fatos, favorecendo a maior aproximação possível com a realidade. ” (HEERDT;
LEONEL, 2007).
Segundo Magalhães (2005), método vem da palavra grega methodos e significa
“através ou ao longo do caminho”. Já metodologia é o estudo dos caminhos que podem ser
seguidos para resolver um determinado problema. “Quando se usa a expressão’ método
científico’ o que se quer designar é, geralmente, a estrutura da parte do processo de
conhecimento em que são elaboradas e testadas hipóteses que dizem respeito à ciência. ”
(MAGALHÃES, 2005, p. 226).
Este capítulo apresenta como será e o que será aplicado em relação à pesquisa
realizada. O cronograma para o desenvolvimento do trabalho encontra-se no Anexo A e
Anexo B.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
Conforme Silva e Menezes (2005, p. 20), “pesquisa é um conjunto de ações, propostas
para encontrar a solução para um problema, que tem por base procedimentos racionais e
sistemáticos. ”
54
Sendo assim, uma pesquisa é feita com o principal objetivo de responder uma pergunta
para a qual ainda não se conhece a resposta, ou seja, encontrar uma solução para um
determinado problema para o que, até o momento, não se conhece solução.
O problema deste trabalho é o pouco tempo que a equipe de testes tem para trabalhar
em cima dos testes do sistema. Ou, quando fornecem uma estimativa, o tempo estimado
nunca é aceito.
Demo (1996 apud SILVA E MENEZES, 2005, p. 19) afirma que pesquisa é “um
questionamento sistemático crítico e criativo, mais a intervenção competente na realidade, ou
o diálogo crítico permanente com a realidade em sentido teórico e prático. ”
Para Silva e Menezes (2005, p. 20), a pesquisa se divide em básica e aplicada em sua
natureza. Segundo os autores, a pesquisa aplicada “objetiva gerar conhecimentos para
aplicação prática e dirigidos à solução de problemas específicos. Envolve verdades e
interesses locais. ” Para a elaboração deste trabalho, foi utilizada a pesquisa aplicada, pois na
empresa, em questão, o tempo hábil para realizar os testes de um software é insuficiente e, por
isso, viu-se a necessidade de realizar uma priorização na execução dos testes, para melhorar
os resultados da equipe de desenvolvimento.
Do ponto de vista da forma de abordagem, uma pesquisa pode ser quantitativa ou
qualitativa. O projeto apresenta uma abordagem qualitativa.
Pesquisa Qualitativa considera que há uma relação dinâmica entre o mundo real e o
sujeito, isto é, um vínculo indissociável entre o mundo objetivo e a subjetividade do
sujeito que não pode ser traduzido em números. A interpretação dos fenômenos e a
atribuição de significados são básicas no processo de pesquisa qualitativa. Não
requer o uso de métodos e técnicas estatísticas. O ambiente natural é a fonte direta
para coleta de dados e o pesquisador é o instrumento-chave. É descritiva. Os
pesquisadores tendem a analisar seus dados indutivamente. O processo e seu
significado são os focos principais de abordagem. (SILVA; MENEZES, 2005, p.
20).
Conforme Silva e Menezes (2005), os objetivos de uma pesquisa podem ser
exploratórios, descritivos ou explicativos. Este projeto é classificado como pesquisa
exploratória, pois tem como foco a familiaridade com um determinado problema de forma a
possibilitar a construção de hipóteses. Além disso, a pesquisa exploratória envolve “[...]
levantamento bibliográfico; entrevistas com pessoas que tiveram experiências práticas com o
problema pesquisado; análise de exemplos que estimulem a compreensão. ” (SILVA;
MENEZES, 2005, p. 21).
55
Dessa maneira, Silva e Menezes (2005) afirmam que uma pesquisa pode ser
classificada conforme o ponto de vista dos procedimentos técnicos. Seguindo esse ponto de
vista, uma pesquisa pode ser bibliográfica, documental, experimental, levantamento, estudo
de caso, pesquisa expost-facto, pesquisa-ação e participante. O presente projeto utiliza a
pesquisa bibliográfica e estudo de caso. Segundo Menezes e Silva (2005, p. 21), a pesquisa
bibliográfica é “[...] elaborada a partir de material já publicado, constituído principalmente de
livros, artigos de periódicos e, atualmente, com material disponibilizado na Internet. ” Os
mesmos autores afirmam que a pesquisa, estudo de caso, “[...] envolve o estudo profundo e
exaustivo de um ou poucos objetos de maneira que se permita o seu amplo e detalhado
conhecimento”.
Assim, o presente trabalho também é um estudo de caso, pois ele se constitui em um
estudo aprofundado para uma equipe de desenvolvimento de software escolher a melhor
maneira de priorizar seus testes.
3.2 ETAPAS PARA DESENVOLVIMENTO DO PROJETO
O processo de desenvolvimento deste trabalho foi subdividido em etapas, são elas:
Definição do tema e autorização da empresa para desenvolvimento do estudo.
Fundamentação teórica: revisão bibliográfica sobre testes e técnicas de
priorização.
Escolher ou definir técnicas e processo de priorização de testes.
Escolher um projeto de desenvolvimento para estudo de caso.
Aplicar as técnicas de priorização de testes nesse projeto de software.
Elaborar um relatório com as observações sobre a experiência e as
recomendações.
56
Definição do tema e autorização da empresa para desenvolvimento do estudo.
O tema foi escolhido em parceria com a empresa em questão, assim como a
autorização para a realização da pesquisa. Trata-se de um tema, que está em ascensão na
empresa, e é uma área de interesse dos autores da pesquisa. Os diversos autores na literatura
descrevem a relevância dos testes e aplicação das atividades de qualidade de software, e
concordam que é algo de extrema importância para o desenvolvimento de um produto de
software que atenda às necessidades do cliente.
Fundamentação teórica.
A fundamentação teórica tem como objetivo fornecer subsídios para entender o que é
um teste e porque realizar a priorização dos mesmos, objeto de estudo neste trabalho. Os
seguintes assuntos foram abordados na fundamentação teórica: Engenharia de Software,
qualidade, testes de software, técnicas de teste de software e a análise de riscos.
Escolher ou definir técnicas de priorização de testes.
Essa etapa tem uma importância muito grande, pois nela que será definida a técnica
para priorizar os testes.
Escolher um projeto de desenvolvimento para o estudo de caso.
Nesta etapa, será escolhido um projeto da empresa em questão para que sejam
aplicadas as técnicas de priorização de testes. Será apresentado um projeto com os casos de
testes de um sistema, para assim realizar a priorização.
Aplicar a priorização em um projeto real da empresa estudo de caso
Nessa etapa, será mostrado em um projeto real da empresa, o que priorizar e o porquê
de priorizarmos a execução de um teste ou outro.
57
Relatório com recomendações.
Desenvolver um relatório com o processo e os resultados de priorizar os testes.
Mostrar as novas horas do projeto, ou seja, mostrar que a priorização dos testes realmente
obteve resultados em diminuir o tempo aplicado aos testes.
3.3 DELIMITAÇÕES
O objetivo deste trabalho é mostrar a teoria e os critérios na prática da priorização da
execução do projeto de testes de software.
Entre as delimitações do trabalho podem destacar-se as seguintes:
Não foi alterado o modelo de especificação de testes da empresa.
Não foi feita implementação / codificação de nenhum sistema.
Não foi aplicado os testes nos casos de uso apresentados.
4 APLICAÇÃO DA PRIORIZAÇÃO DE CASOS DE TESTES - ESTUDO DE CASO
Neste capitulo é apresentado o estudo de caso, um caso de testes real no qual são
aplicadas as técnicas pesquisadas para priorizar os testes. Os dados apresentados foram
retirados da documentação da empresa apresentada, assim os padrões adotados pela empresa
foram mantidos. Inicialmente é apresentada a empresa, a seguir.
58
4.1 A EMPRESA (SOFTPLAN).
A empresa em que foi aplicado o estudo de caso é a Softplan, uma das maiores
empresas do Brasil no desenvolvimento de software de gestão (SOFTPLAN, 2014). Seus
produtos e soluções estão presentes em todos os estados brasileiros, em alguns países da
América Latina e Estados Unidos.
A referida empresa está no mercado desde 1990, desenvolvendo soluções corporativas
para segmentos específicos de negócios, com foco em três áreas de atuação:
Indústria da construção.
Gestão pública.
Justiça.
Atualmente, a empresa possui mais de 2300 clientes no Brasil e no exterior, também
mantém alianças com os mais respeitados fornecedores mundiais de tecnologia e convênios
com instituições de ensino, mantendo uma política de capacitação constante de sua equipe e
desenvolvendo projetos de pesquisa e inovação.
Como resultado, produz soluções de alta qualidade e tecnologia focados nos clientes,
prestando agilidade aos processos de negócio, otimizando o tempo e economizando recursos
por meio da automação, integração e padronização das rotinas de trabalho.
Dentre todas as áreas de atuação da empresa, o estudo de caso será feito na unidade de
Gestão Pública.
A unidade de Gestão Pública (UNGP) desenvolveu e mantem a solução SIDER, que é
uma ferramenta completa e integrada às demandas de informatização para gestão de
departamentos de infraestrutura, transporte e obras. A solução está em uso em treze estados
do país, facilitando as tomadas de decisões baseadas em informações seguras, promovendo
inteligência para a gestão do órgão, otimização dos recursos e melhorando os serviços
prestados à sociedade.
59
4.2 PROCESSO DE TESTES DA EMPRESA
O processo de testes da empresa em questão possui diversas atividades muito
importantes. Entre aquelas que podemos citar como principais estão: estimativa de testes,
revisar especificação de software, projetar casos de testes e executar os testes.
Como o foco deste trabalho é a priorização dos testes, os quais serão executados como
usualmente, a seguir serão abordadas as três principais atividades, mas não a etapa de
execução dos testes. Isso não significa que essa atividade não seja essencial ao processo e
muito menos que ela não será realizada.
4.2.1 Estimativas
A fase de estimativa consiste em calcular previamente qual o esforço (horas)
necessário para desenvolver as atividades consideradas. As atividades de testes a serem
estimadas consistem em:
Revisar Especificação de Negócio.
Projetar Testes.
Executar Casos de Testes.
4.2.1.1 Estimar a Revisão da Especificação de Negócio
Consiste em realizar uma revisão detalhada da documentação de negócio gerada pelos
analistas de sistemas e de negócios. O esforço necessário para realizar a revisão está
diretamente ligado à qualidade do documento recebido. Ao receber um documento muito
60
incompleto ou inconsistente, a tendência de investimento de tempo nesta atividade é alta,
enquanto documentos mais detalhados e concisos tendem a requerer pouco tempo de revisão.
Existem três formas indicadas para estimar a revisão da especificação:
Método 1 (menor assertividade): multiplica-se o tempo gasto ou estimado para
documentação de requisitos por 10%. Exemplo: Para uma documentação gerada em 100
horas, estimam-se 10 horas de revisão.
Método 2 (especialista): um analista de testes que conhece o produto e já realizou
alguma revisão de especificação faz uma análise rápida do documento e estima o tempo
necessário para realizar a revisão.
Método 3 (paramétrica): multiplica-se o número de artefatos a serem revisados
(regras de negócio e tela, mensagens, protótipos, casos de uso e requisitos) por 5, sendo este o
tempo em minutos destinado a revisão dos artefatos. Exemplo: em uma especificação que
possui 10 artefatos, são estimados 50 minutos para realização da revisão.
4.2.1.2 Estimar o projeto dos Casos de Testes
Para estimar o tempo necessário para projetar testes, considera-se que existe
documentação de negócio já revisada. A estimativa pode sofrer variações de acordo com a
experiência do analista de testes que irá executar a atividade.
Existem três formas indicadas para estimar o projeto de testes, apresentadas a seguir.
Método 1: utiliza-se a planilha de estimativas oficial de projetos, na qual são
calculadas as horas necessárias para realização dessa atividade de acordo com a complexidade
dos artefatos de negócio, a experiência do analista de testes e a base histórica registrada no
processo.
61
Método 2 (especialista): um analista de testes que conhece o produto e já fez algum
projeto de testes faz uma análise rápida da documentação dos casos de uso e estima o tempo
necessário para a execução da atividade.
Método 3 (menor assertividade): multiplica-se o tempo gasto ou estimado para
documentação de requisitos por 50%. Exemplo: Para uma documentação gerada em 100
horas, estimam-se 50 horas de projeto de testes.
4.2.1.3 Estimar a execução dos Casos de Testes
A estimativa de execução dos casos de testes não considera aspectos como montagem,
configuração ou atualização do ambiente de testes, bem como a execução posterior às
correções.
Existem três formas indicadas para estimar a execução dos casos de testes, descritas a
seguir.
Método 1: utiliza-se a planilha de estimativas oficial de projetos, em que são
calculadas as horas necessárias para realização dessa atividade de acordo com a complexidade
dos artefatos de negócio, a experiência do analista de testes e a base histórica registrada no
processo.
Método 2 (especialista): um analista de testes que conhece o produto e já executou
testes faz uma análise rápida do documento e estima o tempo necessário para a execução de
cada teste. Exemplo: o analista lê o documento e indica que são necessários 10 minutos para
cada caso de teste. Se o documento possui 30 casos de testes, são necessários 300 minutos
para a execução completa.
Método 3 (menor assertividade): multiplica-se o tempo gasto ou estimado para
projeto técnico + codificação por 25%. Exemplo: Em uma demanda que gastou 30 horas em
projeto técnico e 150 horas em codificação, estimam-se 45 horas de execução de testes.
Após finalizada as estimativas passa-se para a seguinte etapa.
62
4.2.2 Revisar Especificação de Software
Nessa fase serão apresentados procedimentos e diretrizes para a realizar a revisão da
especificação de requisitos. Entende-se como especificação de requisitos toda a modelagem
de negócio do produto: RN - Regra de Negócio, RNA - Regra de Negócio Agrupada, RF -
Requisito Funcional, UC - Caso de Uso, RT - Regra de Tela, Protótipos de tela e Diagramas.
Nesta atividade é realizado a revisão da especificação em busca de não-conformidades
com base na lista de verificação abaixo. O tempo destinado à revisão deve ser de no máximo
10% do tempo utilizado na especificação propriamente dita. O principal objetivo da revisão é
encontrar defeitos antes que eles se tornem falhas.
63
Figura 3 - Tipos de não-conformidades na revisão de requisitos:
Fonte: Empresa apresentada na pesquisa.
4.2.2.1 Registrar as não-conformidades
Todas as não-conformidades deverão ser registradas no “Relatório de revisão de
requisitos”. O registro da não-conformidade deve obedecer às seguintes diretrizes quanto a:
Artefato: Registrar o nome ou código do artefato da especificação onde foi
detectada a não-conformidade.
Tipo da não-conformidade: Registrar o tipo da não-conformidade de acordo
com as seguintes categorias:
1. Erro
Informação contraditória ou inconsistente.
Inconformidade com legislação.
Regra descrita de forma incorreta.
2. Omissão
Informação necessária omitida.
Falta de definição da forma de tratamento de alguma situação.
64
3. Inconsistência
Informação repetida e escrita de forma diferente.
4. Ambiguidade
Informação que leva a diversas interpretações diferentes.
Informação desnecessária.
5. Testabilidade
Item não testável ou sem informações importantes para tal.
6. Digitação/Ortografia
Erros de sintaxe, semântica ou de digitação.
7. Inconformidade com os padrões
Regras escritas fora do padrão estabelecido pela organização.
8. Sugestão de melhoria
Sugestão de alteração no artefato para melhor entendimento.
9. Dúvida
Solicitação de esclarecimento sobre algum elemento do artefato.
Ao finalizar essa etapa, é iniciada a etapa de projeção (confecção) dos casos de testes.
65
4.2.3 Projetar casos de testes
Quem realiza esta atividade é o analista de testes.
A seguir serão apresentados os procedimentos para a construção de casos de testes,
bem como o preenchimento dos documentos padrão.
Para a empresa, um “Caso de teste” é um conjunto de entradas de teste, condições de
execução e resultados esperados desenvolvidos para um objetivo específico, como, por
exemplo, testar o caminho de determinado programa ou verificar o cumprimento de um
requisito específico.
O caso de teste deve especificar a saída esperada e os resultados esperados do
processamento. Numa situação ideal, no desenvolvimento de casos de teste, espera se
encontrar o subconjunto dos casos de teste possíveis com a maior probabilidade de encontrar
a maioria dos erros.
Para confecção dos casos de testes, a primeira atividade é mapear os artefatos (itens a
serem testados), como regras de negócio, regras de telas, etc.
4.2.3.1 Mapeamento dos itens de testes
O mapeamento dos itens de testes deve ser a primeira tarefa realizada, antes de iniciar
a construção do caso de teste. Este mapeamento tem como objetivo clarificar e organizar o
escopo de trabalho. Esta atividade deve ser realizada em conjunto com a revisão da
especificação. O quadro a seguir apresenta os itens de teste.
66
Figura 4 - Mapeamento dos itens de teste.
Itens de teste – artefatos
1 – Requisitos funcionais
2 – Regras de negócio
3 – Regras de tela
4 - Mensagens
(...)
Fonte: Autores.
Cada item de teste deve ser relacionado e numerado no documento de caso de teste, de
modo que seja possível referenciá-lo nos casos de testes, durante a modelagem.
4.2.3.2 Elaborar casos de testes
Depois do mapeamento dos artefatos, começa-se a fazer os casos de teste.
A elaboração de casos de testes deve ser realizada, utilizando o modelo de testes
padrão usado pela empresa. Neste documento, cada cenário ou ideia de teste deve ser disposto
em um tópico, explodindo-o para os seus respectivos casos de testes.
A construção de casos de testes se dá por meio do preenchimento de listas de
verificação, montagem de checklist, roteiros e tabelas de decisão, sendo o uso de cada um
destes modelos facultativos. O analista de testes deve selecionar a forma de representação
mais adequada para a situação que pretende atacar.
A seguir são apresentados alguns desses artefatos e procedimentos.
67
4.2.3.2.1 Listas de Verificação
A lista de verificação é uma tabela na qual cada item ou linha é composto por um ID,
uma pré-condição, uma ação a ser realizada, uma verificação e a rastreabilidade para os itens
de teste correspondentes. Um exemplo pode ser visualizado na figura a seguir.
Figura 5 - Exemplo de caso de teste.
Fonte: Empresa apresentada na pesquisa.
A pré-condição é de preenchimento opcional, ficando a cargo do analista de testes
identificar se é necessário satisfazer alguma situação prévia antes de realizar o teste.
A ação e a verificação devem ser escritas no imperativo e de modo direto. Se deve
assumir que o teste será executado por um profissional que já conhece o sistema e está
habituado com ele, logo, não são necessários muitos detalhes nestas descrições.
Figura 6 - Exemplo de ação e verificação no caso de teste.
Exemplo:
Ação: Excluir um item de contrato que possua termo de supressão vinculado.
Verificação: Deve ser exibida a mensagem "Não é possível excluir item com aditivo vinculado".
Fonte: Autores.
A coluna rastreabilidade deve ser preenchida com os números que referenciam os itens
de testes, de modo que cada número esteja dentro de colchetes (conforme no quadro anterior).
Esta rastreabilidade permitirá maior agilidade na manutenção dos casos de testes, bem como
68
na identificação de qual artefato da modelagem não está sendo atendido pelo produto, quando
alguma verificação não for satisfeita.
4.2.3.3 Abordagens para execução de testes
As abordagens que os analistas de testes podem usar para cada cenário são inúmeras,
cabendo a ele decidir qual a melhor (ou o conjunto das melhores) para cada situação.
Alguns exemplos de abordagens são:
Não testar.
Realizar Testes Exploratórios.
Realização de testes de acordo com a experiência do testador, sem seguir nenhum
documento de testes.
Construção de casos de testes.
Ações e verificações descritas pelo analista de testes para que o testador possa
executar os testes.
Aplicar checklist
O checklist é um modelo muito semelhante à lista de verificação. A diferença básica é
o fato de não existir a indicação de uma ação a ser executada no sistema para que a
verificação seja realizada. Um checklist é composto apenas por verificações que o testador
precisará de alguma forma realizar.
69
Tabela de Decisão
As Tabelas de Decisões devem ser utilizadas quando o teste a ser realizado depender
de uma série de dados de entrada, que quando relacionados produzem uma saída específica e
que precisa ser validada. Este modelo traz maior facilidade na execução de testes que realizam
diversas vezes a mesma operação (ou com pouca variação) com alteração de dados de entrada
e saída.
Os modelos de tabela de decisão inseridos no modelo de caso de teste são apenas
exemplos e podem ser customizados da forma que for necessário para que atendam a
necessidade do teste que está sendo construído.
Vale lembrar que os testes devem ser construídos, assumindo que o testador que o
executará posteriormente já tem conhecimento suficiente para utilizar apenas a tabela de
decisão como roteiro, sem a necessidade de nenhuma informação adicional.
Roteiros de Testes
Os roteiros devem ser utilizados nos casos que a sequência de passos executada pelo
testador para realizar determinado teste é importante para a verificação final. Ao se deparar
com este tipo de situação, o roteiro deve ser utilizado, a fim de garantir a correta execução do
caso de teste.
No roteiro, cada passo deve ser acompanhado por uma verificação, e cada verificação
deve ser acompanhada por pelo menos um item na coluna rastreabilidade.
Os passos e as verificações devem ser escritos no imperativo e com detalhes suficientes para
que o objetivo do teste seja alcançado.
Automação de testes
Esta é a abordagem na qual são utilizadas ferramentas de software para a execução dos
testes.
Estes abaixo podem ser realizados com o uso da ferramenta Eclipse ou uma
ferramenta de automação de testes.
70
Automação de testes unitários.
Automação de testes de serviços.
Automação de testes de interface.
A abordagem para cada cenário é livre e pode ser usada a combinação de várias delas,
o analista de testes deve defini-la, de acordo com as suas restrições dentro do projeto, tais,
como prazo, custo, equipe disponível, etc.
Depois de finalizado o projeto dos testes passa-se para a etapa de execução. Essa fase
não será abordada nesta seção.
Na continuação serão apresentados os casos de uso nos quais foram aplicadas as
técnicas de priorização de testes.
71
4.3 ESTUDO DE CASO
Nesta seção será apresentado o estudo de caso. Ele consiste em dois casos de uso de
um determinado sistema da empresa, nos quais serão aplicadas as principais atividades do
processo de testes da empresa em questão. Para cada caso de uso será verificado o tempo
estimado e os resultados sem a priorização de testes e com a priorização de testes.
4.3.1 Casos de Uso
Para efeitos de exemplificar as técnicas definidas foram selecionados dois casos de uso
de um dos projetos da empresa. Os casos de uso apresentados são:
UC0.001 - Manter Movimentação
Esse caso de uso tem a seguinte função:
Dentro de um órgão público, existem processos administrativos tramitando. Para
tramitar esse processo dentro de diversos setores do órgão, existe a movimentação do
determinado processo. Ou seja, a movimentação é feita para que outras pessoas de diversos
setores do órgão possam realizar alterações dentro do processo.
Então, para que outras pessoas possam alterar o processo, é feita uma movimentação,
dando assim autorização para que um usuário ou um setor inteiro tenha acesso aos dados do
processo.
Dentro dessa movimentação é escolhido o tipo da movimentação, ou seja, a ação a ser
realizada dentro do processo.
Depois de realizar a ação mencionada na movimentação, a mesma é finalizada. Essa
movimentação tem um prazo para ser realizada.
72
Figura 7 - Protótipo UC.001 – Manter Movimentação
Fonte: A empresa citada no trabalho.
UC.002- Manter Tipo de movimentação
Esse caso de uso tem a seguinte função:
Para realizar a movimentação citada no caso de uso anterior, é necessário selecionar
um tipo de movimentação, ou seja, a ação a ser realizada no processo.
Exemplo: Se é necessário adicionar um documento no processo, pode ser criada um
tipo de movimentação: “Adicionar documentos”, e ao enviar esse documento para um
determinado setor adicionar um documento no processo, esse tipo de movimentação será
selecionada.
73
Figura 8 - Protótipo UC.002 – Manter Tipo de Movimentação
Fonte: A empresa citada no trabalho.
4.4 ESTIMATIVA
A estimativa é realizada para que se possa projetar uma data de entrega do projeto.
Nessa atividade é fornecido a quantidade de tempo, geralmente informada em horas, para que
as tarefas sejam executadas.
Para realizar essa atividade, temos o auxílio de uma planilha que calcula o tempo
automaticamente, tendo como parâmetro a quantidade de artefatos (regras de tela, regras de
negócio, etc.) dentro de um caso de uso.
Assim podemos ver a relação na tabela de parâmetros abaixo:
74
Figura 9 - Valor dos parâmetros para estimativas
Fonte: Empresa apresentada na pesquisa.
O tempo está em minutos, sendo que:
A cada regra de negócio é adicionado 12 minutos a revisão de requisitos, 25
minutos na projeção e 40 na execução.
A cada regra de tela é adicionado 7 minutos na revisão de requisitos, 15 na
projeção e 25 na execução.
Quando os casos de teste já estão prontos (por exemplo, o caso de um reteste,
quando um sistema é vendido para outro cliente,), não é necessário fazer a
revisão, nem a confecção dos casos de testes, e a estimativa de execução é
calculada pela quantidade de casos de testes já existentes. Nesse caso são
considerados 15 minutos para cada caso de teste, desconsiderando a quantidade
de regras.
Abaixo pode-se observar o layout da planilha:
Figura 10 - Layout da planilha de estimativas
Fonte: Empresa apresentada na pesquisa.
75
Esta planilha é composta pelas colunas:
Item – Caso de uso: Nome do caso de uso.
RN: Quantidade de regras de negócio.
RT: Quantidade de regras de tela.
Complexidade: Complexidade do caso de uso, em relação à experiência do
analista (informativo).
Pré-condições: Pode ser simples, uma massa de dados ou baseada em
workflow (informativo).
CTs: Quantidade de casos de teste (quando não existem artefatos, ou os casos
de testes já estão prontos).
Revisão: Tempo, em minutos, para realizar a revisão de especificação.
Projeto: Tempo, em minutos, para criação dos casos de testes.
Execução: Tempo, em minutos, para execução dos testes.
Na planilha, logo acima, no canto superior direito, é apresentado o total da estimativa,
que é o somatório de todas as etapas (revisão, projeto e execução).
4.4.1 Aplicação da estimativa
A quantidade de artefatos deve ser inserida na tabela, para que o cálculo possa ser
realizado. A seguir faremos a estima considerando os dois casos de uso citados:
Figura 11 - Planilha de estimativas aplicada
Fonte: Empresa apresentada na pesquisa.
Estimativa com base na documentação do produto. 10:36 26:10 37:40
636 1570 2260
Item - Caso de Uso RN RT Fluxos Complexidade Precondições CTs Revisão Projeto ExecuçãoUC.001 – Manter Movimentação 16 21 5 Simples Simples 0 414 1015 1465
UC.002- Manter Tipo de movimentação 6 15 3 Simples Simples 0 222 555 795
74:26
76
Observa-se que aplicando os parâmetros nas quantidades de artefatos, temos a
estimativa do projeto, em minutos. Transformando esses números em horas, tem-se:
UC.001 – Manter Movimentação:
Revisão: 414 / 60 = 6,9.
Projeto: 1015 / 60 = 16,9.
Execução: 1465 / 60 = 24,4.
UC.002 – Manter Tipo de Movimentação:
Revisão: 222 / 60 = 3,7.
Projeto: 555 / 60 = 9,2.
Execução: 795 / 60 = 13,2.
TOTAL: 74:26 h
Revisão: 636 / 60 = 10:06 h.
Projeto: 1570 / 60 = 26:16 h.
Execução: 2270 / 60 = 37:08 h.
Após finalizada e atividade de estimativa dos testes passa-se para a fase de revisão de
especificação, para verificar os artefatos e para ter um maior entendimento do sistema e do
negócio.
4.5 REVISÃO DE ESPECIFICAÇÃO
A revisão de especificação é realizada logo depois que a estimativa é entregue, e tem
como principal objetivo, sanar as dúvidas do analista de testes em relação à documentação do
sistema para que o projeto de testes seja feito. Muitas das vezes essas dúvidas estão
relacionadas com a falta de informação nos requisitos.
77
Outra finalidade muito importante da revisão, é que o analista que irá desenvolver essa
etapa, começa a ter um bom conhecimento do negócio, já que será feita a validação, leitura e
entendimento de cada regra associada ao caso de uso.
As dúvidas geralmente devem ser identificadas quando impedem o completo
entendimento para que os casos de testes sejam feitos, os seja, é o que impede a realização
dos casos de testes.
Para realizar a revisão de requisitos, é utilizada uma planilha, que se pode observar na
figura a seguir.
Figura 12 - Layout da planilha de revisão de requisitos
Fonte: Empresa do estudo de caso
Nessa planilha são informados:
Artefato: regra de negócio, regra de tela, ou algum componente no qual o analista de
testes identificou um problema, dúvida ou uma não conformidade.
Tipo de NC: É o tipo de não conformidade, que pode ser:
Erro.
Omissão.
Inconsistência.
Ambiguidade.
Testabilidade.
78
Digitação / Ortografia.
Inconformidade com os padrões.
Sugestão de melhoria.
Dúvida.
Descrição da não conformidade: Nessa coluna é descrito a dúvida ou o problema
que foi encontrado no artefato citado.
Impeditivo: Se esse problema está impedindo a continuidade do trabalho.
Resposta do Analista: A planilha é enviada para o analista de sistemas poder validar
as informações e arrumar a documentação do sistema se for preciso. Quando ele retorna a
planilha ao analista de testes, é preenchida a coluna resposta do Analista, com o que foi
alterado, ou com a resposta da dúvida enviada.
Observações finais: Muitas vezes nesse campo vai à resolução final do problema,
indicando se foi sanada a dúvida e se foi alterada a documentação. A planilha “vai e volta”
quantas vezes forem necessárias, até que a documentação esteja correta.
Logo após a realização da revisão de especificação, onde todas as dúvidas, e
problemas na especificação devem ser sanadas, é realizado a confecção dos casos de testes.
4.6 ESPECIFICAÇÃO DOS CASOS DE TESTES
Nesta etapa serão criados os casos de testes, onde será descrito o que deve ser testado
em relação a cada artefato associado ao caso de uso. Também serão mapeados os artefatos
que fazem parte da funcionalidade a ser testada. Além disso é descrito o resultado do teste,
onde será descrito se o mesmo passou com sucesso ou se foi encontrado algum erro no
sistema, ao executar o determinado caso de teste.
79
4.6.1 Exemplo de caso de documento de teste
Primeiramente, deve-se copiar para o documento os artefatos dos casos de uso a serem
testados (regras de negócio, regras de tela, mensagens...).
Pode-se observar na figura a seguir como ficará o documento.
Figura 13 - Layout do documento de casos de testes
Fonte: Empresa do estudo de caso
Na figura podemos observar que citamos os artefatos do caso de uso, bem como sua
numeração do lado esquerdo de cada artefato, para que quando o caso de testes seja criado,
possa ser feita a rastreabilidade de cada artefato. Ou seja, assim, pode-se identificar a qual
artefato cada caso de testes representa.
Pode-se iniciar a descrição dos testes de diversas maneiras. Uma abordagem que é
muito usada, principalmente para regras de tela, é a criação de um checklist, contendo uma
80
explicação rápida da regra de tela. Essa é abordagem para este tipo de artefato pois
geralmente esses possuem uma complexidade muito menor que uma regra de negócio.
Porém, se a regra de tela, também envolve um negócio do sistema, este artefato deve
ser testado nos casos de testes, principalmente porque eles possuem muitos comportamentos.
Ou seja, é importante que as regras que possuem comportamentos múltiplos no sistema, sejam
testadas nos casos de testes, assim cada caso de teste contempla um comportamento do
artefato.
A seguir podemos observar um exemplo de checklist.
Figura 14 - Layout do documento de casos de testes – Checklist
Fonte: Empresa estudo de caso
Para as regras mais complexas, com vários comportamentos, dependo da situação,
criam-se os casos de testes, com maior nível de detalhamento.
Podemos observar abaixo um exemplo de caso de teste.
81
Figura 15 - Layout do documento de casos de teste – casos de teste
Fonte: Empresa do estudo de caso
Na primeira coluna (“#”), aparece o número do caso de testes, apenas para
identificação.
Na coluna “Objetivo”, é descrito de maneira resumida, qual o objetivo do teste em
questão.
Na coluna “Pré-condição”, é descrito as pré-condições necessárias para acessar a
funcionalidade a ser testada. No exemplo, dependendo da pré-condição apresentada, o sistema
se comporta de uma maneira, podendo mudar também da ação a ser executada pelo usuário.
Na coluna “Verificação”, é exibida a validação que deve ser feita pelo testador. Ou
seja, é o resultado da execução do teste, a maneira como o sistema deve se comportar.
Na coluna “Rast”, a rastreabilidade da regra, aqui é inserido o número da regra que
está sendo testada. Número este, que deve ser visualizado no mapeamento dos artefatos.
Caso o sistema se comporte de maneira incorreta, ou seja, caso um erro seja
encontrado, é na coluna “TESTE” que deve ser descrito o ocorrido. Se o teste foi com
sucesso, é nessa coluna que deve ser informado também.
82
4.6.1.1 Aplicando o documento de testes
Nesta seção, será apresentado, o documento de testes para os dois casos de uso
selecionados. Os casos de uso apresentados são:
UC.002- Manter Tipo de movimentação
Aplicando o documento de testes, citado na seção anterior, no caso de uso pode-se
obter alguns resultados como os das figuras a seguir, onde serão apresentados somente alguns
exemplos.
Na próxima figura são visualizadas algumas regras de tela:
Figura 16 - Documento de testes aplicado
Fonte: Empresa do estudo de caso
83
A figura a seguir apresenta algumas regras de negócio.
Figura 17 - Documento de testes aplicado
Fonte: Empresa do estudo de caso
84
Assim, os casos de testes gerados são apresentados a seguir:
Figura 18 - Documento de testes aplicado – casos de testes
Fonte: Empresa do estudo de caso
UC0.001 - Manter Movimentação
Aplicando o documento de testes, citado na seção anterior, no outro caso de uso,
obtém-se documentos como os descritos na sequência, onde serão apresentados alguns
exemplos.
Algumas regras de tela podem ser observadas na figura a seguir.
85
Figura 19 - Documento de testes aplicado
Fonte: Empresa do estudo de caso
Algumas regras de negócio são descritas na próxima figura.
86
Figura 20 - Documento de testes aplicado
Fonte: Empresa do estudo de caso
Os casos de testes gerados podem ficar como os descritos na seguinte figura.
87
Figura 21 - Documento de testes aplicado – casos de testes
Fonte: Empresa do estudo de caso
Na próxima etapa será realizada a priorização dos testes, com o intuito de diminuir o
tempo do projeto de testes.
4.1 PRIORIZAÇÃO DOS TESTES
Nesta etapa será descrito como é realizada a priorização dos testes, isto é, será
selecionado os artefatos “mais importantes” para a realização do projeto de testes (desde a
estimativa até a execução).
88
4.1.1.1 Como é realizada a priorização
Com base na lei de Brooks, citado no capítulo 2, que nos diz que adicionar mais
pessoas em um projeto pode atrasa-lo ainda mais, vamos priorizar os testes, para obter a
diminuição do tempo da etapa de testes. Mesmo, que a solução fosse adicionar mais pessoas,
muitas vezes optar por essa opção se torna inviável, tendo em vista que o custo do projeto iria
aumentar bastante.
Para realizar essa priorização, é preciso inicialmente fazer uma validação de cada
artefato, para que assim possa ser escolhido os que causam maior impacto no sistema, caso
encontrado algum erro relacionado ao artefato.
Essa validação envolve algumas atividades. Dentre elas, a análise de risco, pois a
mesma, nos mostra o quanto um erro causa de prejuízos para o negócio da empresa. Mas,
como saber o que causa problema para o negócio da organização?
Esse conhecimento se dá através da experiência do analista de testes, ou de quem for
fazer a priorização dos artefatos dentro da organização. Para auxílio ao entendimento do
negócio da empresa, ou do sistema a ser priorizado, é que deve ser feita a revisão de
especificação, pois nessa etapa o analista de testes entra em contato com toda a documentação
do sistema, podendo ter um entendimento maior do negócio.
Além disso, essa etapa, de saber o que é mais importante para o cliente, pode ser
realizada antes mesmo da documentação do sistema, em entrevista com o cliente, na hora do
levantamento de requisitos. Ou seja, essa etapa pode ser realizada, de maneira sucinta, na hora
do levantamento de requisitos, pelo analista de sistemas.
Na realização desta etapa, temos o auxílio de uma planilha, para que possa ser feita a
priorização. A seguir vemos o layout dessa planilha.
89
Figura 22 - Layout da planilha de priorização de testes
Fonte: Empresa do estudo de caso
A planilha é composta pelas seguintes colunas:
Identificador: como diz o nome, serva para identificar o artefato a ser priorizado.
Artefatos de Teste: título do artefato a ser priorizado.
Prioridade: essa coluna deve ser preenchida com os números: 1, 2, 3, 4 ou 5 (sendo 1
a menor prioridade e 5 a maior). Como saber qual número colocar? Para isso deve ser
respondida a pergunta:
Qual a importância desta condição de uso para o Usuário?
1 - Dispensável
2 - Desejável
3 - Pouco Importante
4 - Importante
5 - Imprescindível
Severidade: essa coluna deve ser preenchida com os números: 1, 2, 3, 4 ou 5
(dependendo do grau de severidade). Como saber qual número colocar? Deve ser respondida
a seguinte pergunta:
Se falhar esta condição de uso qual será o impacto para o sistema?
1 - Muito Baixa
2 - Baixa
3 - Média
90
4 - Alta
5 - Muito Alta
Podemos observar que esta pergunta, tem alto impacto na análise de risco, pois quanto
mais alta a severidade, maior o risco para o sistema caso aconteça algum erro relacionado ao
artefato em questão.
Probabilidade: essa coluna deve ser preenchida com os números: 1, 2, 3, 4 ou 5
(dependendo da probabilidade de ocorrer erro em determinado artefato). Como saber qual
número colocar? Deve ser respondida a pergunta:
Qual a probabilidade de ocorrer uma falha?
1 - Muito Baixa
2 - Baixa
3 - Média
4 - Alta
5 - Muito Alta
Para responder essa pergunta, o analista deve ter um bom conhecimento do sistema, e
principalmente experiência na área de testes, pois só assim pode saber qual a probabilidade de
acontecer cada incidente.
Outro ponto importante, é que determinadas regras, como regras de tela, por exemplo,
são validadas no teste unitário, ou seja, é testada pela equipe de desenvolvimento, chegando
para equipe de testes já com uma certa segurança de funcionamento.
Com base no cálculo de ISRAM, apresentado no capítulo 2, vamos então verificar o
total do risco. No cálculo de ISRAM o risco é a probabilidade de ocorrer uma falha,
multiplicado pela consequência caso ocorra a falha. Em nossa proposta, como temos mais um
indicador, que é prioridade, o cálculo proposto é o seguinte:
Risco Total: essa coluna é uma média das colunas: prioridade, severidade e
probabilidade. É a partir dela que vamos saber quais as regras que serão priorizadas. As
médias que ficarem igual ou maior a 2.5, entende-se que tem maior importância e risco para o
negócio, e por isso devem ser priorizadas.
Na próxima seção, vamos aplicar a priorização, nos artefatos dos dois casos de uso
selecionados.
91
4.1.1.2 Aplicação da Priorização
Nessa seção iremos aplicar a priorização dos testes nos artefatos dos casos de uso que
foram apresentados. Segue a planilha de priorização aplicada em cada um dos casos de uso
apresentados.
UC.002- Manter Tipo de movimentação
Figura 23 - Aplicação da planilha de priorização de testes
Fonte: Empresa do estudo de caso 1
Quantidade de artefatos que ficaram com média acima de 2.5:
Regras de tela: 8 de 15.
Ide
nti
fic
ad
or
Artefatos de Teste
Pri
ori
da
de
Se
ve
rid
ad
e
Pro
ba
bilid
ad
e
Ris
co
To
tal
1 RT13.009 - Expandir/Retrair sessão 2 1 1 1,33
2 RT10.01.023 - Desabilitar campos ao editar movimentação do CNJ 4 4 1 3,00
3 RT10.01.024 - Desabilitar campo código CNJ ao cadastrar uma movimentação externa 4 3 1 2,67
4 RT10.01.026 - Campo código SPJ 2 3 2 2,335 RT13.010 - Buscar 3 3 2 2,676 RT13.007 - Validar operação 3 3 2 2,677 RT13.004 - Adicionar linha de registro 4 3 2 3,008 RT10.01.012 - Exibir mensagem ao realizar operações do tipo de movimentação 3 3 2 2,679 RT13.005 - Editar linha de registro 2 3 2 2,33
10 RT13.006 - Excluir linha de registro 2 3 2 2,3311 RT13.008 - Campos obrigatórios 2 2 1 1,6712 RT13.014 - Manter paginação 3 2 2 2,3313 RT10.01.025 - Exibir origem do código da movimentação 4 4 3 3,6714 RT13.003 - Botão Cancelar 2 3 2 2,3315 RT13.001 - Botão Salvar 4 5 3 4,0016 RN10.01.03.002 - Não permitir cadastrar e editar dois tipos de movimentação iguais. 4 5 2 3,6717 RN10.01.03.005 - Não permitir editar os dados de movimentações do CNJ 4 5 3 4,0018 RN10.01.03.003 - Não permitir excluir tipo de movimentação já cadastrada para um Processo Jurídico 4 5 3 4,0019 RN10.01.03.001 - Não permitir excluir um tipo de movimentação importado do CNJ 4 5 2 3,6720 RN10.01.001 - Validar se foram encontrados registros na busca 4 3 2 3,0021 RN10.01.03.004 - Possíveis dados para consultar tipo de movimentação 3 2 2 2,33
Priorização dos Artefatos de Teste
Lista de artefatos priorizados Risco
92
Regras de negócio: 5 de 6.
Na sequência a priorização no outro caso de uso.
UC0.001 - Manter Movimentação
Figura 24 - Aplicação da planilha de priorização de testes
Fonte: Empresa do estudo de caso
Ide
nti
fic
ad
or
Artefatos de Teste
Pri
ori
da
de
Se
ve
rid
ad
e
Pro
ba
bilid
ad
e
Ris
co
To
tal
1 RT06.01.01.001 - Ícone favorito com destaque 2 2 2 2,00
2 RT13.006 - Excluir linha de registro 2 2 2 2,00
3 RT13.004 - Adicionar linha de registro 2 2 2 2,00
4 RT07.02.01.011 - Destacar prazo de movimentação 2 4 2 2,675 RT13.014 - Manter paginação 1 3 2 2,006 RT03.01.002 - Adicionar dias ao prazo 3 3 2 2,677 RT13.008 - Campos obrigatórios 2 2 1 1,678 RT03.01.001 - Exibir movimentações em ordem decrescente de cadastro 2 3 2 2,339 RT13.005 - Editar linha de registro 3 3 3 3,00
10 RT13.007 - Validar operação 2 3 2 2,3311 RT13.009 - Expandir/Retrair sessão 1 2 1 1,3312 RT13.010 - Buscar 1 3 2 2,0013 RT13.013 - Link para visualizar Processo Jurídico 2 2 3 2,3314 RT03.02.001 - Paginação 2 3 3 2,6715 RT03.01.003 - Limitar em 500 caracteres 1 3 2 2,0016 RT13.001 - Botão Salvar 4 3 3 3,3317 RT13.003 - Botão Cancelar 3 2 3 2,6718 RT13.016 - Dados Duplicados 4 3 3 3,3319 RT03.02.01.001 - Movimentações em lote 3 3 4 3,3320 RT03.02.002 - Destacar ícone Movimentação Finalizada 2 3 2 2,3321 RT03.02.01.002 - Desabilitar campos de movimentação 2 3 2 2,3322 RN13.001 - O processo jurídico deve estar em andamento 3 4 4 3,6723 RN13.009 - Atribuição do processo jurídico 5 4 3 4,0024 RN03.02.001 - Movimentação em lote 3 3 3 3,0025 RN03.02.002 - Montar texto do histórico para cadastrar movimentação 4 3 3 3,3326 RN03.01.004 - Atribuição duplicada na mesma movimentação 2 3 3 2,6727 RN03.01.001 - Permitir que uma movimentação possua várias atribuições 3 4 4 3,6728 RN03.01.002 - Montar texto do histórico para manter atribuição 4 3 2 3,0029 RN03.02.003 - Finalizar/Excluir a movimentação se e somente se a movimentação não estiver finalizada 4 4 3 3,6730 RN03.02.008 - Não é possível excluir movimentações de sistema 5 4 3 4,0031 RN03.02.006 - Excluir todas as atribuições ao excluir uma movimentação 5 3 3 3,6732 RN03.02.007 - Montar texto do histórico para excluir movimentação 3 3 2 2,6733 RN03.02.005 - Retirar movimentação da fila de trabalho 2 3 3 2,6734 RN13.010 - Atribuição a uma movimentação ativa do processo jurídico 4 3 2 3,0035 RN03.02.004 - Montar texto do histórico para finalizar movimentação 3 3 2 2,6736 RN03.02.009 - Possíveis dados para consultar movimentação 2 2 2 2,0037 RN10.01.001 - Validar se foram encontrados registros na busca 2 2 2 2,00
Priorização dos Artefatos de Teste
Lista de artefatos priorizados Risco
93
Quantidade de artefatos que ficaram com média acima de 2.5:
Regras de tela: 8 de 21.
Regras de negócio: 14 de 16.
Com a aplicação da priorização, podemos observar que muitos artefatos ficaram com a
média abaixo de 2.5, pois, pela priorização, existem outros artefatos que são considerados
mais importantes, sempre levando em consideração os riscos para o negócio.
Na próxima etapa podemos visualizar como fica a nova estimativa, com os artefatos já
priorizados.
4.1.1.3 Estimativa com a priorização de testes
A quantidade de artefatos deve ser inserida na tabela, para que o cálculo possa ser
realizado. A seguir faremos a estima considerando os dois casos de uso citados, com os novos
números, ou seja, depois da realização da priorização.
Figura 25 - Aplicação da planilha de estimativas
Fonte: Empresa do estudo de caso
Observa-se que aplicando os parâmetros nas quantidades de artefatos, temos a
estimativa do projeto, em minutos. Transformando esses números em horas, temos:
UC.001 – Manter Movimentação:
Revisão: 299 / 60 = 4,9.
Projeto: 770 / 60 = 12,8.
Estimativa com base na documentação do produto. 7:40 19:55 27:20
460 1195 1640
Item - Caso de Uso RN RT Fluxos Complexidade Precondições CTs Revisão Projeto ExecuçãoUC.001 – Manter Movimentação 14 8 5 Simples Simples 0 299 770 1060
UC.002- Manter Tipo de movimentação 5 8 3 Simples Simples 0 161 425 580
54:55
94
Execução: 1060 / 60 = 17,6.
UC.002 – Manter Tipo de Movimentação:
Revisão: 161 / 60 = 2,6.
Projeto: 425 / 60 = 7,0.
Execução: 580/ 60 = 9,6.
TOTAL: 54:55 h
Revisão: 460 / 60 = 07:06 h.
Projeto: 1195 / 60 = 19:09 h.
Execução: 1640 / 60 = 27:33 h.
4.1.1.4 Considerações finais
Pode se destacar que na estimativa inicial para os dois casos de uso, chegou-se ao
resultado de 74:36 horas para realizar as atividades de revisão, projeção e execução dos testes.
Após a aplicação da priorização que foi aplicada para os casos de uso apresentados, obteve-se
uma estimativa de 54:55 horas, para realização das atividades de testes nos artefatos
priorizados.
Com isso, percebe-se que foi obtida uma redução de 19:19 horas, sendo quase 30%
das horas reduzidas.
Lembrando que aplicamos apenas para 2 casos de uso, e que dependendo do projeto,
esse número pode variar.
Também pode se destacar que o valor de corte (no exemplo 2,5) para seleção dos
artefatos a serem priorizados pode ser incrementado, com isso a margem de erros ficaria
menor e o tempo para desenvolvimento dos testes maior, ou pode ser diminuído, consumindo
menos tempo mais aumentando a margem de erros.
95
5 CONCLUSÕES E TRABALHOS FUTUROS
Os objetivos deste trabalho eram desenvolver métodos para a realização da prioridade
de testes, buscando a diminuição da quantidade de horas para a realização de todo o projeto de
testes de um sistema.
Observando os resultados atingidos percebe-se que as horas do projeto diminuíram
bastante. Com isso, acreditamos que foi alcançada a meta definida, pois o objetivo do
trabalho, que era a priorização de testes, em todo o projeto, visando à diminuição do tempo de
execução, foi alcançado.
Essa diminuição permite que a equipe de testes, que ainda não tem seu devido valor,
aplique da melhor forma possível seu trabalho, nas horas que lhe foram disponibilizadas.
Muitas empresas, por falta de maturidade e cultura, ainda não valorizam devidamente
os testes, e a redução das horas para a realização de todo o projeto de testes é diminuída. Com
isso, a equipe de qualidade deve executar todos os testes em menos tempo, assim tendo uma
chance maior de chegar um produto com erros até o cliente, sendo que esses erros, na maioria
das vezes, podem fazer o sistema parar e gerar prejuízos para quem contrata o serviço.
Desta forma, com a priorização, são diminuídas as horas da realização da atividade de
testes, porém, todo o esforço disponível, será concentrado em regras e funcionalidades que
são mais importantes para o cliente. Dessa forma, os erros que poderão acontecer, não serão
mais em funcionalidades tão importantes para o cliente, assim não “parando” o sistema, e não
trazendo prejuízos para o cliente que compra a aplicação.
Este método de aplicação de priorização de testes já está sendo aplicado na empresa
citada no trabalho, com uma grande aceitação dos que já participaram deste processo.
Contudo, as métricas e parâmetros de tempo, ainda estão sendo discutidas para que sejam
melhor padronizadas, buscando utilizar estas em todos os projetos, independente do seu
tamanho ou complexidade.
Os autores deste trabalho, ficam muito satisfeitos com os resultados atingidos.
Para trabalhos futuros, sugere-se que a parte de estimativas não aconteça mais de
forma manual. Ou seja, a sugestão é a criação de um sistema, ou um plug-in para alguma
ferramenta de especificação de requisitos, para que esta ferramenta possa fazer a estimativa
96
automaticamente, contando a quantidade de regras de negócio, regras de telas e quantidade de
fluxos de um caso de uso.
Outra sugestão, um pouco mais complexa, é o desenvolvimento de uma aplicação, que
por inteligência artificial, possa interpretar a regra de negócio e assim indicar se é algo de
muita importância para o sistema. Ou seja, se gera muito ou pouco impacto para o cliente que
usa o sistema.
Ainda podemos sugerir que os casos de testes sejam aplicados em um projeto, visando
o resultado da quantidade de erros encontrados, sem e com a priorização dos testes. Ou seja,
ter dois ambientes com um determinado sistema, onde os dois ambientes são iguais, contendo
exatamente o mesmo projeto, e assim realizar a execução dos testes nesses ambientes, sendo
um com a priorização e no outro sem, e assim obter a quantidade de erros obtidos.
97
REFERÊNCIAS
ALENCAR, A.; SCHMITZ, E. Análise de risco em gerência de projetos. Rio de
Janeiro: Brasport, 2005.
AMARAL, Érico Hoff do. Metodologia para Cálculo do Risco por Composição de
Métodos. Rio Grande do Sul, 2010. Disponível em:
<http://www.lbd.dcc.ufmg.br/colecoes/sbseg/2010/0028.pdf> Acessado em 20 de maio de
2015.
BARTIÉ, Alexandre. Garantia da qualidade de software: As melhores práticas de
Engenharia de Software aplicadas à sua empresa. Rio de Janeiro: Campus, 2002.
BASTOS, Anderson.Base de conhecimento em teste de software. 2a ed. São Paulo:
Martins, 2007.
BOEHM, B. W.; DEMARCO, T., Software Risk Management. IEEE Software,
v.14, p 17-19, Maio/Junho de 1997.
BORDA, Eliseu. As carreiras universitárias. Veja, São Paulo, v. 24, n. 25, p. 42-43, jun.
1991.
BROOKS, Frederick P. Jr.,The Mythical Man-Month. Addison-Wesley. Boston. 2002.
COOPER, D; GREY.S; RAYMOND,G; WALKER, P. Project risk management
guidelines: managing risk in large projects and complex procurements. New York
– USA : John Wiley & Sons Ltd, 2005.
CRAIG, R.D., JASKIEL, S. P., Systematic Software Testing, Artech House Publishers,
Boston, 2002.
DELAMARO, Márcio Eduardo; MALDONADO, Carlos José. JINO, Mario. Introdução do
Teste de Software. Rio de Janeiro: Elsevier, 2007.
DINSMORE, Paul C.,Como se tornar um profissional em gerenciamento de projetos:
livro base de “Preparação para Certificação PMP – Project Management Professional.
Rio de Janeiro: Qualitymark, 2005.
FINKELSTEIN, A. e Dowell, J. A comedy of errors: the London ambulance servisse case
study. In IWSSD’96: Proceedings of the 8th International Workshop on Software
Specification and Design, page 2, Washington, DC, USA. IEEE Computer Society, 1996
HEERDT, Mauri Luiz; LEONEL, Vilson. Metodologia científica e da pesquisa. 5a ed.
Palhoça: UnisulVirtual, 2007.
HETZEL, Willian. Guia completo ao teste de software. Rio de Janeiro: Campus, 1987.
98
HEUMANN, J. Generating Test Cases from Use Cases. The Rational Edge e-zine. New
York: International Business Machines, 2001.
INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD. Base de
conhecimento para certificação em teste. Versão 2007br. 2007.
INTHURN, Cândida. Qualidade & teste de software. Florianópolis: Visual Books, 2001.
KEELLING, Ralph. Gestão de Projetos: uma abordagem global. São Paulo:Saraiva, 2002.
KENDRICK, Tom. Identifying and Managing Project Risk: Essential Tools for Failure-
Proofing Your Project. New York: AMACOM, 2003.
KERZNER, Harold. Gestão de projetos: as melhores práticas. Porto Alegre:Bookman,
2006.
KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software: Aprenda as
metodologias e técnicas mais modernas para o desenvolvimento de software. São Paulo:
Novatec Editora, 2007.
LAUDON, Kenneth C.; LAUDON, Jane Price. Sistemas de informação. 4. ed. LTC: Rio de
Janeiro,1999.
MAGALHÃES, Gildo. Introdução à metodologia científica: caminhos da ciência e
tecnologia. São Paulo: Ática, 2005.
MOLINARI, Leonardo. Testes de Software: Produzindo Sistemas Melhores e Mais
Confiáveis. São Paulo: Érica, 2003.
MYERS, GlenfordJ..The Art of Software Testing. 2 ed. Nova Jérsei: John Wiley & Sons,
2004.
National Institute of Standards & Technology. The Economic Impacts of Inadequate
Infrastructure for Software Testing. p.15. 2002. Disponível em:
< http://www.nist.gov/director/planning/upload/report02-3.pdf> Acesso em 1 de agosto de
2014.
G. J. Myers. The Art of Software Testing. Wiley, New York, 1979.
PETERS, James F; PEDRYCZ, Witold. Engenharia de Software: Teoria e prática. Rio de
Janeiro: Campus, 2001.
PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, métodos e
Padrões. Rio de Janeiro: Livros Técnicos e Científicos Editora S.A., 2001.
PROJECT MANAGEMENT INSTITUTE - PMI. Um Guia do Conjunto de Conhecimentos
em Gerenciamento de Projetos – Guia PMBOK. Pennsylvania,USA, 2004.
99
PRESSMAN, R. S. Engenharia de Software. São Paulo: Makron Books, 1995.
__________________. Engenharia de Software, McGrawHill, 6ª Edição, 2006
__________________. Engenharia de Software. 7a ed. São Paulo: AMGH, 2011.
RIOS, Emerson; TRAYAHÚ FILHO, Moreira. Teste de software. 2a ed. Rio de Janeiro: Alta
Books, 2006.
SILVA, Edna Lúcia da; MENEZES, Estera Muszkat. Metodologia da pesquisa e elaboração
de dissertação. 4 a ed. Florianópolis: UFSC: 2005.
SOFTPLAN, site oficial da empresa 2014. Sobre a empresa. Disponível em:
< https://www.softplan.com.br/a-softplan/quem-somos/> Acesso em 10 de novembro de
2014.
SOFTWARE ENGINEERING INSTITUTE - SEI. Capability Maturity Model Integration
(CMMI) Version 1.1. Software Engineering Institute – CarnegieMellon University, 2002.
Disponívelem: <http://www.sei.cmu.edu/>.
SOMMERVILLE, Ian. Engenharia de Software. 8a ed. São Paulo: Addison Wesley, 2007.
VARGAS, Ricardo Viana. Gerenciamento de projetos: Estabelecendo diferenciais
competitivos. 3.ed. Rio de Janeiro: Brasport, 2002.
VERZUH, Eric. MBA Compacto: Gestão de projetos. Rio de Janeiro: Campus,
2000.
10
0
ANEXO
5.1 ANEXO A – CRONOGRAMA DAS ESTAPAS PARA DESENVOLVIMENTO DO
PROJETO
10
1
5.2 ANEXO B – CRONOGRAMA DAS ESTAPAS PARA DESENVOLVIMENTO DO
PROJETO
Atividades:
Apresentação (Defesa): 15-18/06.
Preparar Apresentação: 10/06.
Capítulo de Conclusões e Trabalhos Futuros: 27/05.
Cronograma
Projeto
Março Abril Maio Junho
Semana
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Atividade 1
X
Atividade 2 X
10
2
Redação Capítulo Desenvolvimento/Proposta
Desenvolver capítulo 5.
Atividade 5: Entrega do capítulo de Desenvolvimento.
Entrega da Ficha de Frequência: 20/05.
Atividade 4: Controle e verificação do desenvolvimento: 06/05.
Atividade 3: Entrega impressa do capítulo de modelagem: 15/04.
Atividade 2: Correções do avaliador: 01/04.
Atividade 1: Entrega do cronograma: 18/03.
Atividade 3 X
Atividade 4 X
Atividade 5 X
Cap.
Conclusões
X
Resumo
X
Entrega
Monografia
X
Apresentação X
Defesa X