UNIVERSIDADE DO SUL DE SANTA CATARINA
FERNANDO SANTIAGO
INTEGRAÇÃO DA AUTOMAÇÃO DE TESTES DE INTERFACE NO CICLO DE
DESENVOLVIMENTO CORRETIVO
Florianópolis
2015
FERNANDO SANTIAGO
INTEGRAÇÃO DA AUTOMAÇÃO DE TESTES DE INTERFACE NO CICLO DE
DESENVOLVIMENTO CORRETIVO
Trabalho de conclusão de curso apresentado ao
curso de Especialização em Engenharia de
Projetos de Software da Universidade do Sul
de Santa Catarina, como requisito parcial para
a obtenção do título de Especialista.
Orientador: Prof. Vera Rejane Niedersberg Schuhmacher, Dr.
Co-orientador: Prof. Jan Charles Gross
Florianópolis
2015
FERNANDO SANTIAGO
INTEGRAÇÃO DA AUTOMAÇÃO DE TESTES DE INTERFACE NO CICLO DE
DESENVOLVIMENTO CORRETIVO
Este Trabalho de Conclusão de Curso foi
julgado adequado à obtenção do título de
Especialista e aprovado em sua forma final
pelo Curso de Especialização em Engenharia
de Projetos de Software da Universidade do
Sul de Santa Catarina.
Florianópolis,____ de_______________ de______
_____________________________________________________
Prof. e orientador Vera Rejane Niedersberg Schuhmacher, Dr.
Universidade do Sul de Santa Catarina
_____________________________________________________
Prof. e co-orientador Jan Charles Gross
Universidade do Sul de Santa Catarina
_____________________________________________________
Prof. Maria Inés Castiñeira, Dr.
Universidade do Sul de Santa Catarina
Dedico este trabalho aos meus queridos
amigos que muito me incentivaram e apoiaram
na realização deste curso.
AGRADECIMENTOS
A empresa Softplan pelo incentivo de aprendizagem oferecido ao colaborador.
A Prof. Dr. Vera Rejane Niedersberg Schuhmacher e ao Prof. Jan Charles Gross,
por toda confiança que depositaram em mim, pelas diversas oportunidades profissionais e
acadêmicas proporcionadas, pela paciência e pelo incentivo durante os momentos difíceis,
alem de serem grandes exemplos de competência e disciplina.
Aos amigos do GUTS-RS - Grupo de Usuários de Testes de Software do Rio
Grande do Sul - pelos anos de amizade, compartilhamento de materiais didáticos, palestras,
processos e ferramentas de testes de software.
De modo geral, a todos que direta ou indiretamente contribuíram e apoiaram para
a realização deste trabalho.
"A definição de insanidade é fazer a mesma coisa repetidamente e esperar
resultados diferentes." (RITA M. BROW, 1983)
RESUMO
Este trabalho de conclusão de curso aborda um estudo sobre testes de software, seus
paradigmas e a aplicação da automação de testes em um sistema legado. Para a aplicação da
metodologia de testes apresentada, foi utilizado como estudo de caso o sistema Sienge,
sistema de gestão voltado a Indústria da Construção, desenvolvido em ambiente web. Este
estudo apresenta e aplica técnicas de testes relacionadas a sistemas isentos de padrões que
impedem a garantia da qualidade do sistema ao todo. Entretanto, o trabalho visa compreender
como inserir as práticas de testes automatizados no ciclo de vida de desenvolvimento de um
software utilizando uma abordagem pragmática.
Palavras-chave: Testes de software. Sistema legado.
LISTA DE ABREVIATURAS
API
Application Programming Interface (Interface de Programação de Aplicativos)
CLI
Command Line Interface (Interface da Linha de Comando)
ERP
Enterprise Resource Planning (Planejamento de Recurso Corporativo)
IEEE
Institute of Electrical and Electronics Engineers (Instituto de Engenheiros
Eletricistas e Eletrônicos)
QA
Quality Assurance (Analistas de Qualidade)
RUP
Rational Unified Process (Processo Unificado Rational)
TI
Tecnologia da Informação
UCP
Unidade Central de Processamento
XP
EXtreme Programming (Programação Extrema)
LISTA DE TABELAS
Tabela 1 – Erros por funcionalidade.................................................................................... 32
LISTA DE ILUSTRAÇÕES
Figura 1 – Formulário eletrônico de entrada de dados........................................................ 34
Figura 2 – Relatório Extrato de Cliente............................................................................... 35
Figura 3 – Evidência de falha.............................................................................................. 36
Figura 4 – Relatório de execução de testes.......................................................................... 37
LISTA DE GRÁFICOS
Gráfico 1 – Defeitos prevenidos........................................................................................... 38
Gráfico 2 – Porcentagem dos defeitos detectados pela automação de testes........................ 39
Gráfico 3 – Estoque de erros................................................................................................. 40
SUMÁRIO
1
INTRODUÇÃO ................................................................................................................ 12
1.1
PROPOSTA ................................................................................................................... 12
1.2
OBJETIVO .................................................................................................................... 12
1.3
METODOLOGIA .......................................................................................................... 12
2
SISTEMAS LEGADOS .................................................................................................... 14
2.1
QUALIDADE DE SISTEMAS LEGADOS ................................................................. 14
2.2
O PROCESSO DE AUTOMAÇÃO DE TESTES ........................................................ 15
2.2.1
Definições da automação de testes ............................................................................ 15
2.2.3
Ferramentas para automação de testes ....................................................................... 16
2.2.4
Automação de testes no processo de desenvolvimento ............................................. 17
2.2.5
Acompanhamento e analise dos resultados ............................................................... 18
3
TESTES AUTOMATIZADOS DE SOFTWARE ............................................................ 20
3.1
PARADIGMAS DE TESTES DE SOFTWARES ........................................................ 21
3.2
TIPOS DE TESTES AUTOMATIZADOS ................................................................... 22
3.2.1
Testes de unidade ....................................................................................................... 23
3.2.2
Testes de integração ................................................................................................... 23
3.2.3
Testes de interface ..................................................................................................... 24
3.2.4
Testes de leiaute ......................................................................................................... 24
3.2.5
Testes de aceitação ..................................................................................................... 24
3.2.6
Testes de desempenho ............................................................................................... 25
3.2.7
Testes de carga ........................................................................................................... 25
3.2.8
Testes de estresse ....................................................................................................... 26
4
TÉCNICAS DE TESTES DE SOFTWARE ..................................................................... 27
4.1
TESTES ALEATÓRIOS ............................................................................................... 27
4.2
TESTES DE FUMAÇA ................................................................................................ 28
4.3
TESTES DE SANIDADE ............................................................................................. 28
5
MÉTODOS AGEIS DE DESENVOLVIMENTO DE SOFTWARE ............................... 30
5.1 CENÁRIOS DE DESENVOLVIMENTO COM TESTES ................................................ 30
6
6.1
CENÁRIOS ....................................................................................................................... 32
PLANEJAMENTO DE TESTES .................................................................................. 32
6.2
FORMULÁRIO DE ENTRADA DE DADOS ............................................................. 34
6.3
TESTE PARA COMPARAÇÃO DE RELATÓRIOS .................................................. 35
6.4
EVIDÊNCIA DE FALHAS .......................................................................................... 35
6.5
RELATÓRIO DE EXECUÇÃO DE TESTES .............................................................. 36
6.6
RESULTADOS ............................................................................................................. 37
7
CONCLUSÃO .................................................................................................................. 41
REFERÊNCIAS ....................................................................................................................... 42
12
1
INTRODUÇÃO
Sistemas legados são aplicativos computacionais que, mesmo fabricados no passado,
continuam em produção e se mantém funcionais. Estes sistemas podem apresentar problemas
de qualidade por diversos fatores, dentre eles, a fraca experiência do profissional que o
desenvolveu, o uso de uma metodologia antiquada e fora do padrão e outros problemas que
possam impedir sua evolução ou até gerar graves falhas após uma simples alteração. Por
diversas razões os sistemas legados não podem ser substituídos, tornando-os caros quanto à
manutenção e com grandes riscos no momento de sua evolução. Devido estes problemas
torna-se necessário melhorar a qualidade desses sistemas, podendo ser uma forma interessante
de mantê-los ativos, tornando-os mais produtivos e permitindo que melhorias e evoluções
sejam implementadas com menos riscos. Consequentemente é obtida uma maior
confiabilidade e segurança a cada manutenção que se faça necessária. O incremento de novas
funcionalidades nos sistemas legados com maior qualidade permite que o fabricante tenha
vantagens competitivas sem grandes investimentos de novos desenvolvimentos, gerando
lucros e permitindo a integração com novos sistemas (CRISPIN, 2009).
1.1
PROPOSTA
Trata-se de um estudo de caso, onde, em um ambiente corporativo será implantada
uma metodologia de testes de software para ajudar na garantia da qualidade de entrega de
versões de um sistema de gestão especializado na Indústria da Construção, gerando assim,
maior confiabilidade e versões livre de falhas.
1.2
OBJETIVO
Aplicar uma metodologia de testes de software que possa ser vinculado a qualquer
processo de manutenção em sistemas legados, visando melhorar a qualidade do ambiente de
desenvolvimento corretivo, garantindo maior segurança no processo de implementação e
evitando prejuízos consideráveis a empresa.
1.3
METODOLOGIA
Para a elaboração deste trabalho, foram realizadas pesquisas bibliográficas em
diversos materiais, livros e os materiais distribuídos ao longo da disciplina referente testes de
13
software e a partir desse referencial teórico foi desenvolvida a proposta tema desta
monografia.
14
2
SISTEMAS LEGADOS
Sistemas legados são definidos como sistemas de TI (Tecnologia da Informação)
ativos e que tiveram seu desenvolvimento inicializado no passado. Softwares legados e
demais aplicativos são muitas vezes considerados os destaques da organização, geralmente
gerando altos lucros por excederem o valor necessário para a manutenção, e o excedente,
muitas vezes, mantido pela empresa com o objetivo de financiar outros projetos estratégicos
(HORCH, 2003).
Outra definição para software legado diz que sistemas legados foram desenvolvidos
décadas atrás e constantemente são modificados para satisfazer as mudanças nos requisitos de
negócio e nas plataformas de computação. O aumento da distribuição destes sistemas causa
inúmeros problemas para grandes organizações que os consideram dispendiosos de manter e
arriscados de evoluir (PRESSMAN, 2010). Entretanto, Pressman aponta outra citação que
complementa a anterior alegando que muitos sistemas legados permanecem dando suporte a
funções importantes e indispensáveis do negócio.
Podemos concluir que um sistema legado é qualquer sistema que tenha sido
implantado e está em uso atualmente. É possível deduzir também que se estes sistemas ainda
estão em uso, significa que são operações vitais para a empresa no qual o custo da migração
para metodologias e tecnologias atuais seria muito alto.
2.1
QUALIDADE DE SISTEMAS LEGADOS
Infelizmente existe uma característica adicional que pode estar presente no software
legado, a má qualidade. Sistemas legados, algumas vezes, são projetos não extensíveis, com
códigos complicados, documentação pobre ou inexistente, com casos de teste e resultados que
nunca foram executados e um histórico de modificações mal gerido. Essa lista de problemas
pode ser maior do que se espera (PRESSMAN, 2010). É possível acreditar que existam
muitos sistemas que em sua época de criação utilizaram métodos, hoje considerados
inadequados para o desenvolvimento de software, desta forma estes métodos são considerados
ruins na atualidade gerando a fama de que software legado não tem qualidade.
Independentemente da metodologia utilizada na criação de softwares legados serem
ultrapassadas, existem os softwares desenvolvidos com uma qualidade inferior devido a pouca
experiência e conhecimento de padrões de programação das equipes de desenvolvimento. Este
quadro se agrava quando o sistema evolui sendo alterado por muitos desenvolvedores e cada
um efetuando as modificações da forma que achar melhor (KOSCIANSKI, 2007).
15
2.2
O PROCESSO DE AUTOMAÇÃO DE TESTES
A automação de testes pode parecer simples, o que não podemos esquecer é que
alguns dos problemas dos testes automatizados são intrínsecos de cada tipo de teste.
Entretanto, outras dificuldades podem ser causadas pelo desconhecimento de boas práticas de
organização de um projeto com automação de testes. Por isso, essa seção discute e recomenda
formas de se trabalhar para aumentar a produtividade.
2.2.1 Definições da automação de testes
A automação de testes esta aplicada diretamente a boa qualidade dos sistemas de
software, sendo assim, agregam valor ao produto finalizado, mesmo contendo alterações e
melhorias que não sejam visíveis aos usuários finais do sistema. Mas, como qualquer artefato,
o código fonte dos testes automatizados e os documentos e relatórios gerados requerem
qualidade e capricho para que a evolução e manutenção sejam viáveis, com custo de trabalho
linear ou mesmo constante, ou seja, que não aumente radicalmente sua complexidade à
medida que o projeto evolua.
Torna-se primordial a existência da preocupação de testes com código-fonte de
qualidade, pois eles também estão sujeitos a problemas similares que podem ocorrer com o
software em teste. Consequentemente, diversas tarefas de manutenção de código do sistema
também são aplicadas ao dos testes, tais como evolução, refatoração e otimização. Tudo isso
para obter e manter a correção, legibilidade e desempenho, que são algumas das
características básicas para uma boa bateria de testes automatizados. Entretanto, o principal
aspecto que traz coerência para a prática de testes automatizados é a simplicidade: testes
automatizados devem possuir um código fonte trivial, que seja fácil de implementar e de
entender. Dessa forma, a chance de introduzir erros é relativamente pequena. Outro aspecto
complementar é que um erro introduzido nos testes geralmente é fácil de ser identificado em
tempo de implementação, pois a execução do teste tende a falhar, se ele não falhar é porque
houve uma replicação do erro no código do sistema. Essa redundância de trabalho entre
código do sistema e código dos testes cria duas frentes de busca de erros e traz mais segurança
para escrita do sistema e dos testes (GRAHAM, 2012).
16
2.2.3 Ferramentas para automação de testes
A escolha do aplicativo de testes é de grande importância, mas apenas conhecer uma
variedade de ferramentas disponíveis para a execução de testes não é o suficiente para manter
a qualidade de testes automatizados. É necessário atrelar à escolha da ferramenta as condições
do ambiente computacional, aos processos de desenvolvimento utilizado, as condições das
equipes de desenvolvimento e testes e a empresa. Se a única ferramenta encontrada foi uma
aplicação com um custo inacessível não pode ser considerada uma boa solução, desta forma é
necessário o vinculo entre a expectativa da empresa, os recursos disponíveis para a automação
e uma ferramenta que atenda esta realidade.
Algumas sugestões podem ser interessantes para auxiliar na avaliação de uma
ferramenta:
Um sistema que apresente uma CLI (Command Line Interface) ou uma API
(Application Program Interface) apresenta um ambiente simples para serem testados a partir
de ferramentas xUnit. As xUnit são ferramentas interessantes para se fazer testes unitários e
de integração, mas podem ser utilizadas para testes de sistema se o sistema possuir uma destas
interfaces.
Testes de estresse, carga e outros testes não funcionais do sistema são testes
específicos e que normalmente necessitam de um ambiente similar ao de produção, desta
forma estes testes são normalmente gerados utilizando um sistema de record&playback
somado a alguns scripts que recebem dados de uma listagem separada, simulando o mais
próximo possível uma situação real (MYERS, 2011).
Sistemas antigos, que possuem uma interface bem definida e que provavelmente não
terão uma modificação na interface são fortes candidatos a terem testes de sistema
desenvolvidos a partir de ferramentas de record&playback devido à facilidade de criação e
reprodução dos testes.
A escolha da ferramenta de automação de teste depende muito a situação da empresa e
dos recursos disponíveis para que os testes sejam efetuados, desta forma, uma pesquisa entre
as ferramentas avaliadas no mercado é interessante para chegar a uma ferramenta adequada as
possibilidades da empresa. Neste caso, a escolha de ferramentas para automação dos testes em
um sistema legado é muito parecida com a escolha de ferramentas para automação de testes
em um sistema que está em fase inicial de desenvolvimento, a diferença está na avaliação, que
deve ser efetuada com base no sistema existente. Esta posição apresenta mais uma vez a
importância do conhecimento do sistema legado. É interessante que ao escolher a ferramenta
17
para automação dos testes, que o responsável já tenha em mente uma periodicidade para a
execução automática dos testes. É muito comum as empresas executarem os testes
automatizados semanalmente ou até diariamente, isto varia dependendo da estratégia de teste
que foi adotada e da quantidade de testes que estão sendo executados (MOLINARI, 2011).
2.2.4 Automação de testes no processo de desenvolvimento
Quando o item de trabalho já foi planejado, e a escolha da ferramenta de automação já
foi efetuada, é o momento de implementar o projeto de automação e depois definir como a
automação de testes é disponibilizada para integração com o processo de desenvolvimento.O
item trabalhado é registrado e incluído como um projeto em qualquer processo de
desenvolvimento, desta forma, este item ganha um escopo e um prazo bem definidos gerando
um trabalho planejado que pode ter seu resultado avaliado no final do projeto. Este projeto
deve ser regido pelas regras de projetos do sistema legado utilizado na empresa. Após a
conclusão do projeto, se a automação dos testes do sistema legado ficar limitada aos projetos
de automação desenvolvidos, o sistema continuará a evoluir e após algum tempo, mesmo que
sejam gerados sempre mais projetos para automação de testes, o sistema legado não
conseguirá manter seu conteúdo de testes automatizados atualizado, tornando os esforços de
automação menos eficientes e provavelmente perdendo a sua credibilidade.
Para evitar este tipo de problema, é necessário que as regras e padrões de automação
de testes gerados a partir deste projeto, sejam inclusos nos passos do processo de
desenvolvimento utilizado pela empresa, garantindo que as modificações geradas no sistema
legado avaliem a possibilidade de automação dos testes desta melhoria. Por exemplo, um
primeiro projeto abrange uma parte crítica do sistema e teve seus casos de teste automatizado
através de uma ferramenta de record&playback, no momento da conclusão do projeto, a
empresa passa a ter um conhecimento específico sobre esta estratégia e técnica de teste
utilizada, conhecimento este que pode ser replicado para o processo de desenvolvimento.
Desta forma, a empresa pode incluir em seu processo de desenvolvimento um passo de análise
que avalia se um determinado projeto do sistema legado tem condições de ser testado de
forma automatizada através da técnica conhecida. Se houver a possibilidade, este próximo
projeto deve conter também o passo que irá criar os casos de teste a serem automatizados para
este projeto (ENGEBRETSON, 2011).
Outro caso onde a empresa pode incluir este passo é no processo de correção de
erros, onde cada erro encontrado e corrigido deve ser avaliado quanto a possibilidade de
18
automação do teste. Este processo possibilita que o erro sempre seja verificado e impede um
retorno deste mesmo erro num momento futuro. A inclusão destes passos no processo de
desenvolvimento garante a evolução dos testes automáticos de forma que com o passar do
tempo o sistema garante uma maior cobertura dos testes. Ao trabalhar com projetos de
automação de teste ao invés de implantá-los diretamente no processo de desenvolvimento, a
empresa emprega um esforço calculado para uma iniciativa que irá afetar todo o processo de
desenvolvimento, desta forma a empresa acumula experiência em relação a automação de
teste antes de arriscar uma modificação no processo de desenvolvimento.
Os outros projetos de automação de teste são necessários para definir as melhores
estratégias e técnicas de teste a serem utilizadas em cada parte do sistema, gerando de forma
gradual todos os testes necessários para a segurança do sistema legado. Há a possibilidade de
que o projeto de automação de teste falhe, neste momento é importante avaliar o que ocorreu
com o projeto para validar em que passo do processo houve uma falha, se foi no levantamento
inicial das prioridades, se foi na análise dos testes a serem efetuados, se foi na escolha da
ferramenta de automação ou se foi um erro na implementação do projeto. Descobrir este erro
e aprender com ele fará com que outros projetos de automação não falhem, gerando uma
maior confiabilidade no processo, o fato de um projeto de automação ter falhado também
significa que a empresa investiu menos recursos do que se tivesse tentado implementar esta
automação diretamente no processo de desenvolvimento de sistemas, poupando assim
desenvolvedores, testadores e todos aqueles que teriam de conviver com a mudança referente
a automação de testes no seu dia a dia. Isto também faz com que a equipe envolvida no
projeto ganhe experiência em relação ao processo de automação de testes, podendo auxiliar
no aprendizado de outras equipes que serão envolvidas nas automações de teste dos próximos
projetos (CRISPIN, 2009).
2.2.5 Acompanhamento e analise dos resultados
Após implementado o primeiro projeto de automação de testes, é necessário haver um
acompanhamento da execução destes testes automatizados de acordo com a periodicidade
com que eles ocorrem. Este acompanhamento permite saber se alguma modificação no
sistema gerou falha em parte do sistema que foi testada, desta forma é possível encontrar e
solucionar a causa do problema antes que este seja entregue numa versão ou pacote de
atualização, além de permitir um acompanhamento da evolução da automação dos testes que
estão sendo gerados.
19
As métricas de qualidade são uma boa forma de acompanhar e analisar se os testes
automatizados estão gerando resultado, melhorando assim a qualidade geral do produto. A
análise e divulgação destes indicadores são importantes para gerar credibilidade ao processo
de automação dos testes e para validar se as estratégias adotadas estão sendo realmente
efetivas. Sistemas que possuem um build automatizado e/ou processo de Integração contínua
automatizada auxiliam e favorecem o acompanhamento e divulgação dos testes entre os
desenvolvedores e equipes de teste (BINDER, 1999).
20
3
TESTES AUTOMATIZADOS DE SOFTWARE
A implementação de testes automatizados é a prática de tornar os testes de software
independentes da intervenção humana, ou seja, não é preciso disponibilizar de pessoas para
realizar os roteiros de testes. Testar é uma prática essencial ao desenvolvimento de sistemas,
mas os testes de software só começaram a se tornar uma área de estudo da engenharia de
software a partir da década de 70 e, desde então, têm ganhado cada vez mais importância
(MOLINARI, 2011).
Atualmente, existem grandes comunidades de profissionais especializados, conhecidos
como testadores, analistas de testes ou QA (Quality Assurance), e diversos estudos e cursos
com ênfase nessa prática. Muitas empresas possuem grandes setores dedicados
exclusivamente ao controle e garantia de qualidade. Assim como os testes manuais, os testes
automatizados têm como objetivo melhorar a qualidade de sistemas através da verificação e
validação de atributos processados a partir de regras. Essa automação dos testes expande a
área de estudo de testes de software e muda os paradigmas de implementação, manutenção e
execução dos testes. A automação de testes requer do uso de ferramentas específicas e de
linguagens de programação de alto nível, portanto, é necessário um sólido conhecimento de
técnicas de testes e ciência da computação para a elaboração de roteiros de testes com
qualidade. Como veremos no Capítulo 4, existem técnicas de escrita de testes automatizados
que mudam completamente a maneira que programadores programam um software.
Os testes automatizados também podem ser aproveitados para outros fins. Por
exemplo, é possível utilizá-los para conhecer os impactos de ferramentas externas e a
estrutura das funcionalidades do sistema. Já os testes de interface de usuário e de aceitação
podem ser utilizados para demonstrações do software ou mesmo como um manual de aceite
do usuário final (GRAHAM, 2012).
Ainda, relatórios gerados a partir dos casos de testes podem ser utilizados como
documentação dos requisitos e do sistema. Molinari salienta que este tipo de documentação é
dinâmica, pois pode ser gerada automaticamente e sem esforço sempre que os roteiros de
testes forem executados. Um benefício desse tipo de documentação é que ela dificilmente se
tornará obsoleta, já que ela se autoverifica toda vez que os testes são executados, isto é, se
algum teste falhar, o relatório indica que aquele requisito não é mais satisfeito.
O principal objetivo dos testes automatizados é melhorar a qualidade do software, mas
qualidade é um termo muito amplo, podendo indicar uma infinidade de aspectos em um
contexto específico, como, por exemplo, desempenho, segurança, flexibilidade, estruturação
21
interna do código, usabilidade, entre outros. Apesar de a qualidade ser um conceito elusivo e
difícil de ser medido, os testes automatizados podem contribuir para melhoria dos sistemas
(KOSCIANSKI, 2007).
3.1
PARADIGMAS DE TESTES DE SOFTWARES
Inúmeras metodologias de desenvolvimento recomendam que todas as pessoas
envolvidas em um projeto atuem controlando a qualidade do produto, pois sabemos que
prevenir defeitos é mais fácil e barato que identificá-los e corrigi-los em fases próximas a
entrega ao cliente (PRESSMAN, 2010).
Os testes automatizados são ou roteiros de scripts escritos a partir critérios de aceite
que exercitam as funcionalidades do sistema em teste e fazem verificações automáticas nos
resultados obtidos. A independência da intervenção humana na execução dos roteiros de testes
permite o uso dos benefícios de um computador, como a velocidade de execução dos testes, a
possibilidade de execução paralela de testes, flexibilidade na quantidade e momento das
execuções dos testes e a facilidade da criação de casos de testes.
Uma das grandes vantagens dessa abordagem é que os casos de teste podem ser
facilmente e rapidamente repetidos a qualquer momento e com pouco esforço. A
reprodutibilidade dos testes permite simular identicamente e inúmeras vezes situações
específicas, garantindo que passos importantes não serão ignorados por falha humana e
facilitando a identificação de um possível comportamento não desejado (MOLINARI, 2011).
Além disso, como os casos de testes são descritos através de um código interpretado
por um computador, é possível criar situações de testes mais complexas do que as realizadas
no processo manual, possibilitando várias combinações de comandos e operações. Ainda, o
objetivo dos testes pode também facilmente ser alterado. Por exemplo, é fácil simular
centenas de usuários acessando um sistema ou inserir milhares de registros em uma base de
dados, o que o tornaria custoso e demorado se este teste fosse realizado manualmente.
Todas essas características ajudam a solucionar os problemas encontrados nos testes
manuais, contribuindo para diminuir a quantidade de erros e aumentar a qualidade do
software. Como se torna fácil executar todos os testes, alterações no sistema podem ser feitas
com segurança, o que ajuda a aumentar a vida útil do produto, afirma Molinari.
Muitos dos testes automatizados são escritos por linhas de código, por isso é
necessário conhecimento básico de programação. Existem também diversas ferramentas
gráficas que escondem os detalhes de programação e possibilitam que usuários do sistema e
22
outros profissionais sem conhecimento em programação consigam criar seus próprios testes.
Ainda existem as ferramentas que separam a descrição do cenário de teste da sua
implementação. Dessa forma, os clientes podem descrever o que se espera da funcionalidade
do sistema enquanto os desenvolvedores implementam trechos de código que ligam os
critérios de aceite do cliente ao sistema em teste (GOUCHER, 2009).
3.2
TIPOS DE TESTES AUTOMATIZADOS
Devido a popularização dos computadores e do fácil acesso a dados pela Internet, o
número de sistemas de softwares vem crescendo cada vez mais, incluindo o número de
usuários. As empresas estão cada vez mais dependentes destes sistemas, utilizados cada vez
mais para gerenciar processos, dentre eles, gerenciais com larga escala de dados e
indicadores. Por isso, a exigência de qualidade é de suma importância, entretanto, algumas
falhas de software estão cada vez mais em evidência, como problemas de usabilidade,
segurança e desempenho, além de diversos outros que podem ser desde enganos por
desatenção do desenvolvedor até mau entendimento dos requisitos da funcionalidade
solicitada pelo cliente (MYERS, 2011).
Para muitos tipos de erros existem testes específicos, que verificam premissas e
padrões. Por isso, é fundamental organizar os casos de teste por tipo relativo a várias razões:

Facilitar a manutenção e a adição de novos cenários para a cobertura de testes para
todas as funcionalidades do sistema;

Utilizar ferramentas próprias e seguir metodologias de testes;

O tempo de execução pode ser variado, então a execução de testes lentos não afetarão
o feedback rápido que as baterias de testes velozes proporcionam;

Facilitar a coleta das métricas por execução de teste, esse indicadores são úteis para
identificar pontos de verificação que precisam ser melhorados.
Existem ferramentas especializadas para cada tipo de teste, elas facilitam a escrita e
tornar o código mais enxuto e legível, logo, mais fácil de manter. Um erro comum é exercitar
ou utilizar uma ferramenta de um tipo de teste específico para objetivos que não são de sua
responsabilidade natural, o que pode levar à criação de testes de baixa qualidade. Portanto, é
necessário conhecer as ferramentas para optar pelas mais apropriadas para o que se está
querendo verificar.
23
Também é importante notar que alguns tipos de testes só fazem sentido com o auxílio
da automação, devido principalmente a sua complexidade de implementar ou de executar os
testes, tais como os de desempenho, carga e longevidade. Os testes de unidade também são
mais interessantes quando automatizados, apesar da fácil implementação e execução, eles
geralmente não possuem interface de usuário intuitiva para possibilitar os testes manuais
(MYERS, 2011).
3.2.1 Testes de unidade
Originalmente o termo Teste Unitário é definido como um teste capaz de analisar uma
unidade de trabalho, que a IEEE (Institute of Electrical and Electronics Engineers) define
como: "Atividade capaz de testar unidades de hardware ou software ou grupo de unidades
relacionadas". Este tipo de teste esta associado a funções para linguagens procedimentais e
métodos em linguagens orientadas a objetos. O Teste Unitário é o teste responsável por testar
os menores trechos de código de um sistema que possui um comportamento definido e
nomeado (BINDER, 1999).
3.2.2 Testes de integração
O Teste de Integração representa a busca de erros de relacionamento entre quaisquer
módulos de um software, incluindo integração de pequenas unidades até a integração de
bibliotecas das quais um sistema depende, servidores e gerenciadores de banco de dados. Uma
funcionalidade ou módulo do sistema pode estar correto, mas não há garantias de que outros
módulos, que fazem chamadas a essa funcionalidade, estão implementadas corretamente
(FOWLER, 1999).
Os erros de integração são frequentes, principalmente quando não existe uma
documentação apresentando pontos de impactos relevantes a funcionalidade alterada. Além
disso, quanto mais complexa for a arquitetura do sistema, maior a chance de existirem erros
de integração, já que aumenta a quantidade de troca de mensagens entre os módulos. Em
sistemas pobres de documentação e mal modelados, a situação fica ainda mais crítica. Falhas
de design entre objetos e o excesso de itens em um único módulo do sistema tornam o
software difícil de entender e manter, portanto ele fica muito suscetível a presença de erros de
integração (GRAHAM, 2012).
24
3.2.3 Testes de interface
Testar a interface de um sistema tem um foco bem diferente de testar classes e
métodos, a interface é o que mantém contato direto com os usuários finais e é a partir dela que
o usuário normalmente conclui se o software atende seus requisitos com qualidade. Por isso,
qualquer não conformidade dessa camada pode ofuscar todo interior do sistema, podendo ser
de boa qualidade (MYERS, 2011).
Os testes automatizados de interface verificam a funcionalidade por meio da
simulação de eventos de usuários, como se uma pessoa estivesse controlando dispositivos de
entrada do computador e adicionando valores a serem processados. A partir dos efeitos
colaterais dos eventos, são feitas verificações na interface e em outras camadas para se
certificar que a interface está funcionando apropriadamente, salienta Myers.
Como a interface de usuário é a parte visual do programa, não basta apenas ela estar
correta, é necessário que ela seja organizada, atraente e que permita que diferentes grupos de
usuários consigam utilizá-la, por isso é importante os testes de leiaute, usabilidade e
acessibilidade.
3.2.4 Testes de leiaute
Os Testes de Leiaute buscam validar a integridade da interface, assim como verificar a
presença de falhas, que são erros difíceis de identificar com testes comuns de interface. Por
exemplo, um Teste de Interface básico pode facilmente verificar que um módulo da interface
foi carregado corretamente, mas não é garantido que o módulo está bem desenhado ou mesmo
visível para o usuário final.
O leiaute do sistema pode variar significativamente entre diversas plataformas, tais
como em diferentes gerenciadores de janelas e navegadores web. Cada plataforma possui suas
particularidades, já que as funcionalidades e algoritmos de renderização variam
consideravelmente, por isso uma bateria de testes de leiaute também é importante para
verificar a portabilidade do sistema (KOSCIANSKI, 2007).
3.2.5 Testes de aceitação
Conhecidos como Teste Funcional, são testes de correção e validação facilmente
conectados ao código do sistema para que os comandos e verificações sejam executados no
sistema em teste. Eles são especificados por clientes ou usuários finais do sistema para
25
verificar se um módulo funciona como foi especificado. Por isso o termo “aceitação”, pois ele
verifica se o cliente aceita as funcionalidades que foram implementadas. Os testes de
aceitação devem utilizar uma linguagem próxima da natural para evitar problemas de
interpretação e de ambiguidades.
Uma história do cliente não é finalizada enquanto os testes de aceitação não
certificarem que o sistema atende aos requisitos especificados. Sendo assim, os Testes de
Aceitação não só são utilizados para identificar defeitos de programação e interpretação dos
requisitos como também para identificar quando uma história foi finalizada (MOLINARI,
2011).
3.2.6 Testes de desempenho
O Teste de Desempenho é projetado para testar o desempenho do software durante a
execução de um sistema, visando descobrir situações que levem a uma possível falha do
software. Ou seja, visa tornar a aplicação estável de modo que o processo de teste definido
possa prosseguir sem maiores problemas. Alem disso, ajudam a identificar os gargalos que
precisam ser otimizados para diminuir o tempo de resposta para o usuário (MOLINARI,
2011).
Testes de Desempenho executam trechos do sistema em teste e armazenam os tempos
de duração de cada execução. Os Testes de Desempenho não avaliam a complexidade
computacional dos algoritmos, por isso os tempos obtidos estão intimamente relacionados à
infraestrutura sobre a qual o teste está sendo executado, podendo variar drasticamente
dependendo do hardware, da rede e demais componentes físicos. (MYERS, 2011).
3.2.7 Testes de carga
O Teste de Carga exercita o sistema sob condições de uso intenso para avaliar se a
infraestrutura é adequada para a expectativa de uso real do sistema. Os casos de testes
simulam o acesso de muitos usuários e requisições ao sistema que são executadas
simultaneamente ou dentro de um intervalo de tempo para medição de informações de
desempenho. Dependendo do sistema e do que o teste irá avaliar, pode ser verificado o tempo
de resposta de cada requisição ou informações relativas ao uso de recursos, como uso da UCP
(Unidade Central de Processamento), cache, memória física, espaço em disco e banda de rede.
Também podem ser observados os programas que se relacionam com o sistema, como
gerenciadores de banco de dados, máquinas virtuais e servidores de aplicação.
26
Após o término da execução dos testes, é realizada a tarefa de interpretação subjetiva
das informações coletadas, que pode ser feita manualmente ou através de scripts que seguem
alguma heurística especializada para um contexto. Essas informações são úteis para
identificar módulos do sistema que apresentem mau desempenho sob uso intenso, como, por
exemplo, queries que são executadas repetidamente e que poderiam ser inseridas em um
sistema de cache. As informações também podem indicar partes do hardware e da
infraestrutura que são mais utilizadas pelo software, portanto quais são as mais importantes
para a execução satisfatória do sistema (ENGEBRETSON, 2011).
Outra conclusão que pode ser obtida com os Testes de Carga é se o sistema e suas
dependências são escaláveis. Se a vazão das requisições apresentarem aumento linear com o
tempo, significa que o sistema é escalável, portanto, é possível melhorar o desempenho do
sistema com o upgrade da infraestrutura. Se a vazão tiver um crescimento exponencial, ou
seja, um crescimento relativamente rápido para poucos usuários e requisições, então é uma
indicação que alguma configuração ou algoritmo precisa ser melhorado (MOLINARI, 2011).
3.2.8 Testes de estresse
Enquanto o Teste de Carga é responsável por avaliar se a infraestrutura é adequada
para a utilização do sistema, o Teste de Estresse visa descobrir os limites de uso da
infraestrutura, isto é, qual será o maior número de usuários e requisições que o sistema
consegue atender corretamente junto ao tempo de execução estimado. A análise dos
resultados pode ser feita através de asserções, os valores limites obtidos da simulação de
estresse são importantes para o gerenciamento e configuração do hardware e do software.
Essa simulação aponta quais são os gargalos de hardware que precisam de upgrade e também
orienta a configuração do hardware e do software para melhorar o desempenho ou mesmo
para criar barreiras que impeçam que a quantidade máxima de requisições extrapole um limite
seguro (ENGEBRETSON, 2011).
27
4
TÉCNICAS DE TESTES DE SOFTWARE
Muitas das vezes os testes automatizados em sistemas legados não conseguem provar
que todas as funcionalidades estejam livres de falhas, isso porque os testes não conseguem
cobrir a grande quantidade de possibilidades de entrada e combinações de resultados a que um
software pode estar sujeito. Sendo assim, os testes são realizados até que os membros da
equipe, incluindo desenvolvedores e clientes, estejam satisfeitos quanto à qualidade do
sistema.
Após a execução dos testes e liberação do sistema para o cliente, podem ser
executadas outras tarefas para certificar que o software atende às necessidades satisfatórias de
aceite, como análises formais e matemáticas ou mesmo a liberação do sistema em versões de
testes para testes em ambiente real com usuários reais.
Durante a criação dos testes automatizados, a regra utilizada é relacionar blocos de
classes de equivalência e dependência de um algoritmo com o objetivo de identificar tanto os
casos rotineiros, como as situações excepcionais, e então, elaborar um roteiro de teste para
cada uma delas. Entretanto, em alguns roteiros de testes, isso não basta e não garante que esta
tudo implementado corretamente, por isso existem outras técnicas de testes que são utilizadas
para complementar e reforçar a qualidade do sistema, aumentando as chances de encontrar
erros durante a implementação do código, como através de testes aleatórios, fumaça e de
sanidade.
Esses tipos de testes, também definidos como técnicas de testes, não necessitam prover
roteiros exclusivos de casos de testes. Ou seja, não é preciso planejar uma execução com
apenas casos de testes de sanidade. De acordo com o histórico de execução de testes e falhas
encontradas, podemos seguir outros padrões de execução, tais como desempenho e outras
ferramentas específicas de testes. Dessa maneira, podemos complementar as baterias de testes
existentes, como a de testes de serviço e unitários (KOSCIANSKI, 2007).
4.1
TESTES ALEATÓRIOS
Software legado, pelo tempo de existência, pode não ter suas especificações e regras
documentadas, este quadro não permite avaliar todas as combinações de entrada e saída de
dados, dessa maneira, fica difícil manter testes que garanta sua total execução. Neste caso, são
realizados testes com dados aleatórios para garantir cenários que não foram previamente
identificados. Os Testes Aleatórios dependem de geradores de dados de entrada e também um
entendimento da lógica de verificação de resultados a partir do oráculo, papel de
28
responsabilidade do analista ou desenvolvedor do sistema com maior experiência do software,
que pode repassar comparações flexíveis para garantir a consistência dos testes, ou seja, a
aleatoriedade dos dados não deve tornar os testes intermitentes.
Testes Aleatórios não precisam ser revisados e na maioria das vezes possuem
comportamento alternado dependendo do histórico de falhas da funcionalidade testada. Esta é
uma característica fora do padrão de automação e execução de testes rotineiros, dessa
maneira, é primordial que exista uma documentação contendo todas as regras de negócio,
variáveis e métodos da funcionalidade a ser testada, isso facilita a identificação das falhas,
evitando o desperdício com tempo de depuração de falhas (KOSCIANSKI, 2007).
4.2
TESTES DE FUMAÇA
Testes de Fumaça ou Smoke Test são pequenos roteiros executados para encontrar
possíveis falhas rotineiras que independem de grandes verificações. Os testes de fumaça
tendem a ser executados antes de outros roteiros, estes, providos com maior número de
verificações, pois se uma falha é encontrada em determinada funcionalidade, todos os outros
roteiros também terão problemas em sua execução. Isso pode economizar tempo com a
execução de todos os roteiros de testes e tempo com a investigação e causa do problema.
Os testes de fumaça, por mais que não sejam de grande complexidade e verificação de
dados, apresentam uma cobertura mais abrangente. Alem da rápida programação e execução,
são úteis para encontrar erros de configuração e de ambiente que costumam ser identificados
após a instalação ou atualização do software para o cliente (KOSCIANSKI 2007).
4.3
TESTES DE SANIDADE
Os Testes de Sanidade mantém características similares aos Testes de Fumaça, ou seja,
são de rápida execução e menos complexos. Por outro lado, são implementados para testes de
cobertura de uma funcionalidade ou módulo específico. Esse tipo de teste esta relacionado a
cobertura de regras de negócio que envolvem algoritmos matemáticos, onde podemos
relacionar dados de entrada e dados processados de saída.
Testes de Sanidade podem sobre escrever Testes Aleatórios, pois executam testes que
verificam regras presentes dentro de uma funcionalidade. Basta alterar a utilização de dados
aleatórios por dados definidos a partir da especificação de requisitos. A vantagem do Teste de
Sanidade em comparação ao Teste Aleatório, é que o roteiro de teste se mantém
29
constantemente em produção, impossibilitando que se torne intermitente, pois existe um
melhor controle de dados de entrada e saída (ENGEBRETSON, 2011).
30
5
MÉTODOS AGEIS DE DESENVOLVIMENTO DE SOFTWARE
A evolução da engenharia de software deu-se a partir do modelo de cascata que
propunha fases e processos para o desenvolvimento de software. Do aprimoramento do
modelo de cascata surgiram novos processos, tais como o modelo em espiral e o RUP
(Rational Unified Process), todos com grande ênfase na documentação do processo.
Devido à grande quantidade de fracassos em projetos de software, nas últimas décadas
alguns líderes de projetos adotaram modos de trabalho que se opunham a este modelo
tradicional, e tiveram grandes sucessos. Até que em 2001, alguns desses líderes, que possuíam
formas de trabalho semelhantes, juntaram-se para debater metodologias de desenvolvimento
na tentativa de criar um novo método que agregasse as melhores ideias. No entanto, essa
discussão levou à conclusão de que era difícil definir um método perfeito para todas as
situações, chegou-se a um consenso de princípios, que foram sintetizados em premissas ágeis.
Dentre os métodos ágeis que satisfazem essas premissas, existem os que focam em
aspectos mais gerenciais, como Lean e Scrum, e outros que também dão ênfase a práticas de
desenvolvimento de software tal como a programação XP (eXtreme Programming). Todos
preconizam o controle de qualidade disseminado por toda a equipe e durante todo o
desenvolvimento (CRISPIN, 2009).
O controle de qualidade no desenvolvimento com métodos ágeis normalmente é
associado à automação de testes, já que essa prática surgiu da mesma comunidade. A
automação de testes é uma das práticas primárias de XP. As baterias de testes podem ser
executadas sem esforço a todo momento, o que possibilita a verificação contínua da qualidade
do sistema durante e após a implementação.
No entanto, a automação de testes não é exclusiva dos métodos ágeis e nem depende
significativamente de outras práticas, por isso é uma técnica de desenvolvimento
independente que pode ser empregada por qualquer equipe utilizando qualquer metodologia,
mesmo as mais tradicionais. Também é importante ressaltar que os métodos ágeis não se
opõem a quaisquer revisões adicionais que sejam feitas para aumentar a qualidade, apenas não
é uma prática primária da filosofia (HORCH, 2003).
5.1 CENÁRIOS DE DESENVOLVIMENTO COM TESTES
A maneira padrão de implementação de uma funcionalidade é rever o conteúdo
especificado e aplicar a solução no defeito existente. Desenvolvida a solução, o programador
executa testes manuais para validar o aceite proposto. Neste processo, existe o risco de existir
31
falhas, essas detectadas ao logo do processo de desenvolvimento. Encontrada a falha, o
defeito causador deve ser encontrado com técnicas de depuração e, após a correção do erro, os
testes manuais devem ser executados novamente. Este processo deve ser repetido até que
todos os critérios de aceite sejam executados com resultados positivos e sem falhas de
execução.
A fim de identificar falhas remanescentes, é comum aplicar o software a um ciclo de
testes automatizados para manter a sua qualidade. Este controle é executado com o auxilio de
testes de interface automatizados ou testes manuais, de acordo com o método utilizado em
produção.
Este método é utilizado por empresas que executam cenários de testes mais rígidos,
entretanto, sem a total confiança no que esta prestes a ser entregue ao cliente, dessa maneira, o
software deve possuir etapas bem definidas, derivadas do modelo de desenvolvimento em
cascata. Esta metodologia tende a aparição de falhas recorrentes no desenvolvimento de
software, gerando atrasos de entregas ao cliente, erros em escala e dificuldade de manutenção
e evolução devido às limitações da execução de testes manuais (CRISPIN, 2009).
Um teste manual é rápido e efetivo, mas a execução manual de um grande conjunto
de testes torna-se uma tarefa trabalhosa, cansativa e com grande impacto de tempo de
execução. Um processo comum e compreensivo é a execução de roteiros de testes mais
críticos, sejam eles, executados por desenvolvedores ou testadores, e que esse mesmo caso de
teste não seja executado novamente a cada alteração significativa do código, é nesse processo
que surgem as principais falhas em sistemas. Falhas estas, responsáveis por prejuízos para as
equipes de desenvolvimento, para a empresa e também para o cliente que se depara com
constantes atrasos em prazos definidos para a entrega do software.
32
6
CENÁRIOS
O desenvolvimento de testes automatizados de interface foi utilizado para a melhoria
da qualidade do sistema Sienge, não só para o processo de manutenção, mas para todas as
atividades que resultassem em intervenção ao sistema físico em produção. A escolha da
metodologia foi absoluta referente a um sistema repleto de não conformidades, tais como:
classes e métodos não extensíveis, código-fonte complicado, documentação pobre e um
histórico de modificações mal gerido.
O Sienge é um sistema de gestão, também chamado de ERP (Enterprise Resource
Planning), que permite gerenciar e integrar todas as áreas de uma empresa da Indústria da
Construção.
Para a elaboração dos cenários de testes automatizados no Sienge, foi desenvolvido
um software de execução de testes de interface, o Suricato. O Suricato é um framework
desenvolvido em Java que encapsula as bibliotecas da API (Application Programming
Interface) Selenium para facilitar a automação de testes. Sendo assim, qualquer pessoa com o
mínimo de conhecimento de programação pode criar seus casos de testes a partir de uma
especificação com roteiros de testes.
6.1
PLANEJAMENTO DE TESTES
O planejamento de testes foi desenvolvido levando em consideração indicadores
extraídos de mapas de calor referente falhas reportadas pelo cliente. O Mapa de Calor é uma
ferramenta de visualização de dados de densidade de pontos. São utilizados para identificar
facilmente aglomerados e encontrar onde existe uma elevada concentração de uma
determinada atividade, no caso, a falha reportada pelo cliente em uma determinada
funcionalidade do sistema. A Tabela 1 apresenta a quantidade de falhas, separadas por
módulos e funcionalidades ordenadas pela posição de item de menu do sistema Sienge.
Tabela 1 - Erros por funcionalidade
Funcionalidade
Módulo - Financeiro
Ocorrência de Falhas
% de Ocorrências
Títulos
30
4,3
Baixa
61
8,7
Entrega de Chaves
11
1,6
33
Repactuação
54
7,7
Geração de arquivo remessa
54
7,7
Leitura de Cobrança Escritural
57
8,2
Relatório de Contas a Receber
25
3,6
Relatório de Contas Recebidas
54
7,7
Relatório Extrato de Cliente
9
1,3
Mala Direta
18
2,6
DIMOB
11
1,6
Relatório de Imposto de Renda
11
1,6
Outros
56
8,0
Atendimentos
Módulo - Pró-Vendas
9
1,3
Propostas
29
4,2
Outros
10
1,4
Solicitação de Contratos
Módulo - Vendas
18
2,6
Emissão de Contratos
12
1,7
Cancelamento de Contratos
36
5,2
Impressão de Contratos
24
3,4
Relatório de Unidades
16
2,3
Outros
34
4,9
Caixa e Bancos
Módulo - Apoio
3
0,4
Notas Fiscais
10
1,4
Locações
10
1,4
Apoio
17
2,4
Apoio (CAD)
19
2,7
Total de Ocorrências
698
Fonte: Documentação interna de testes da empresa Softplan (2014).
A prioridade para planejar a ordem de automação de testes para cada funcionalidade
foi levantada a partir da porcentagem de ocorrências em relação ao montante de falhas
existentes. Visualizando a tabela, podemos constatar que as funcionalidades "Baixa" e
34
"Leitura de Cobrança Escritural" obtiveram grande quantidade de problemas reportados pelos
clientes e por esse motivo, a automação de testes teve inicio a partir destas funcionalidades.
6.2
FORMULÁRIO DE ENTRADA DE DADOS
O Sienge é um sistema 100% web e sua interface é construída de forma dinâmica,
onde regras de tela também são desenvolvidas para clientes diferentes. Nem sempre a mesma
funcionalidade é liberada para todos os clientes. Isso obriga a cada teste ter sua estrutura de
tela, validando e preenchendo campos a espera do retorno de dados processados.
A Figura 1 ilustra o formulário eletrônico de entrada de dados utilizado pelos usuários
com a finalidade da consulta de Relatório de Extrato de Cliente do módulo Financeiro.
Figura 1 - Formulário eletrônico de entrada de dados
Fonte: Documentação interna de testes da empresa Softplan (2014).
Após o inicio da execução do testes de interface, o teste acessa o sistema com o login e
senha do usuário, percorre o menu a esquerda, acessa a tela com a funcionalidade desejada e
preenche os campos de consulta. Realizado o processo, podemos notar que o teste validou o
acesso do sistema pelo tipo de usuário, verificou a existência do item de menu desejado e
validou a presença dos campos da tela antes da consulta que gerou um relatório contendo
dados de um Título pré cadastrado na base de dados, validando todos os valores presentes no
relatório referente ao Título.
35
6.3
TESTE PARA COMPARAÇÃO DE RELATÓRIOS
Com a finalidade de executar uma validação completa referente os dados existentes
nos Títulos dos clientes do Sienge, o Suricato apresenta métodos para a geração e validação
de relatórios. Este processo minimiza o tempo de criação de testes para verificar campo a
campo de certas funcionalidades. A Figura 2 apresenta o relatório gerado referente os dados
de entrada solicitados pelo cliente.
Figura 2 - Relatório Extrato de Cliente
Fonte: Documentação interna de testes da empresa Softplan (2014).
6.4
EVIDÊNCIA DE FALHAS
Quando um teste automatizado, em execução, não consegue dar continuidade ao seu
objetivo, significa que uma inconsistência no sistema foi responsável pela parada do teste.
Neste momento, a ferramenta tira uma cópia da tela, ainda com a falha, e armazena em um
diretório pré estabelecido pelo testador responsável da execução dos testes. Este processo
favorece a investigação da falha apresentando o instante que o teste teve sua execução parada,
evitando que o roteiro de teste tenha que ser executado manualmente até o momento da falha.
36
Figura 3 - Evidência de falha
Fonte: Documentação interna de testes da empresa Softplan (2014).
A Figura 3 apresenta um exemplo de evidencia de falha ao cadastrar uma Previsão de
Comissão para um Credor do sistema. Onde, era esperada uma mensagem de sucesso no
cadastramento da Previsão de Comissão, e como podemos visualizar, uma exceção foi
apresentada sem que a Previsão tenha sido cadastrada.
6.5
RELATÓRIO DE EXECUÇÃO DE TESTES
Outro ponto referente ao controle e execução dos testes automatizados de interface
esta relacionado a ferramenta adotada para o controle de testes. O TestNG é um framework
muito simples de implementar e integrar em projetos. Ele propõe um plugin para criar a
interface no ambiente de desenvolvimento de acordo com a necessidade dos casos de testes,
oferecendo flexibilidade de gravação, organização aberta de testes e funcionalidades
avançadas, tal como a generalização, ordenação, dependência e agrupamento dos testes.
37
Figura 4 - Relatório de execução de testes
Fonte: Documentação interna de testes da empresa Softplan (2014).
A Figura 4 apresenta o relatório da execução de uma bateria de testes executadas em
conjunto. O TestNG permite a configuração de uma Suíte de Testes adicionando quais
métodos serão executados. No relatório podemos notar que foram executados 41 testes e que
apenas 1 obteve falha em sua execução. Logo abaixo, podemos visualizar que a
funcionalidade com problemas esta relacionada com a execução do método de teste
"fluxoContratoPermissaoDistratoTest" da Classe "FluxoContratoPermissaoDistratoTest".
Logo, existe uma falha na funcionalidade de permissão de usuário para o Distrato de um
Contrato de cliente.
6.6
RESULTADOS
Com a implantação desta metodologia em setembro de 2013, alguns resultados foram
observados através da evolução dos indicadores de eficiência, eficácia e efetividade de testes,
nas diferentes funcionalidades do sistema. O Gráfico 1 ilustra os indicadores obtidos a partir
de falhas encontradas durante a execução de testes automatizados de interface para todas as
funcionalidades mencionadas no planejamento dos testes.
38
Gráfico 1 - Defeitos prevenidos
250
Falhas acumuladas
Falhas
200
150
100
50
0
set-13 out-13 nov-13 dez-13 jan-14 fev-14 mar-14 abr-14 mai-14 jun-14
jul-14 ago-14 set-14 out-14 nov-14
Fonte: Documentação interna de testes da empresa Softplan (2014).
A implantação do processo de testes automatizados de interface provocou uma
imediata redução no nível de reclamações e de intervenção por parte dos clientes, provocada
pelos grandes níveis observados em todos os indicadores, em especial, no de acumulo das
falhas encontradas na execução de testes automatizados. O aprimoramento progressivo do
processo de testes nesta equipe resultou no crescimento gradativo de todos os indicadores, no
restante do ano.
39
Gráfico 2 - Porcentagem dos defeitos detectados pela automação de testes
45
40
35
30
25
20
15
10
5
0
set-13 out-13 nov-13 dez-13 jan-14 fev-14 mar-14 abr-14 mai-14 jun-14
jul-14 ago-14 set-14 out-14 nov-14
Fonte: Documentação interna de testes da empresa Softplan (2014).
O Gráfico 2 apresenta indicadores que comparam a porcentagem das falhas
encontradas durante a execução de testes automatizados de interface em relação à quantidade
de falhas reportadas pelos clientes do Sienge. Entretanto, podemos concluir que sem a
existência dos testes, o numero de falhas reportadas por clientes duplicaria na quantidade.
Outro fator positivo são os indicadores mantidos como histórico de erros. Como uma das
metas da equipe de desenvolvimento é estipulada a partir da média semanal de falhas
reportadas por clientes, obtivemos uma melhoria de 58% em relação ao quadro de falhas
existente em setembro de 2013. Em paralelo, o Gráfico 3 apresenta o número de erros em
estoque, erros que ainda não foram corrigidos, que baixou 96% dentro do período de 15
meses.
O que parecia ser um grande desafio foi sendo minimizado com o passar do tempo, e
a uma velocidade extremamente rápida, mesmo a equipe de desenvolvimento não recebendo o
reforço de novos desenvolvedores.
40
Gráfico 3 - Estoque de erros
160
140
120
100
80
60
40
20
0
set/13 out/13 nov/13 dez/13 jan/14 fev/14 mar/14 abr/14 mai/14 jun/14 jul/14 ago/14 set/14 out/14 nov/14
Fonte: Documentação interna de testes da empresa Softplan (2014).
41
7
CONCLUSÃO
A existência de testes automatizados se tornou uma pratica efetiva pra melhorar a
qualidade dos sistemas de software, mas desde que estes testes sejam também de qualidade. O
código fonte dos testes precisa ser legível, organizado de acordo com o padrão de código
utilizado no projeto e ter um excelente desempenho. Para isso, o teste necessita ser
implementado com a mesma atenção e cuidado do sistema principal.
A utilização dos testes deve ser prioritária durante o desenvolvimento do sistema.
Devem ser implementados o mais breve possível, pois quanto mais rápido for o feedback da
execução dos testes, mais rápida e barata será a tarefa de correção.
Um projeto para ser de qualidade não deve ser de responsabilidade apenas de alguns
desenvolvedores da equipe. A qualidade deve ser disseminada entre todos os indivíduos
envolvidos, todos devem ser responsáveis por ajudar no que estiver ao seu alcance para a
elaboração de um software de alto nível. Com essa cultura, coordenadores, analistas,
programadores, testadores e usuários finais devem contribuir para a elaboração de testes
efetivos que validem as regras do negócio do sistema.
Quando trabalhamos com a manutenção corretiva de sistemas legados, temos
consciência que estamos em ciclos mais curtos para a entrega da versão, e a automação de
testes torna-se primordial pra a garantia da qualidade do software.
Finalizando, o fato da automação de testes só pode ser obtido a partir de critérios da
necessidade do sistema, pois os fatores de funcionalidades influenciam na decisão do tipo de
testes a ser utilizado. A intenção deste trabalho foi apresentar os desafios e características
voltadas à automação de testes durante o ciclo de manutenção corretiva de sistemas legados,
que aponta ser uma das principais tendências na área de testes de software.
42
REFERÊNCIAS
BINDER, Robert. Testing Object-Oriented Systems: Models, Patterns, and Tools. Boston:
Paperback, 1999.
CRISPIN, Lisa, GREGORY, Janet. Agile Testing: A Practical Guide for Testers and Agile
Teams. Boston: Addison-Wesley Professional, 2009.
ENGEBRETSON, Patrick. The Basics of Hacking and Penetration Testing: Ethical
Hacking and Penetration Testing Made Easy. Texas: Syngress, 2011.
FOWLER, Martin. et al. Refactoring: Improving the Design of Existing Code. Boston:
Addison-Wesley Professional, 1999.
GOUCHER, Adam, RILEY Tim. Beautiful Testing: Leading Professionals Reveal How
They Improve Software. New York: O'Reilly Media, 2009
GRAHAM, Dorothy, FEWSTER, Mark. Experiences of Test Automation: Case Studies of
Software Test Automation. Boston: Addison-Wesley Professional, 2012.
HORCH, John W. Practical Guide to Software Quality Management. Massachusetts:
Paperback, 2003.
KOSCIANSKI, Andre. Qualidade de Software: Aprenda as Metodologias e Técnicas mais
Modernas para o Desenvolvimento de Software. 2. ed. São Paulo: Novatec, 2007.
MOLINARI, Leonardo. Inovação e automação de testes de software. 2. ed. São Paulo:
Érica Ltda., 2011.
MYERS, Glenford J. The Art of Software Testing. 3. ed. New Jersey: John Wiley & Sons,
Inc., 2011.
PRESSMAN, R. S. Software engineering: a practitioner's approach. 7. ed. New York:
McGraw-Hill, 2010.