UNIVERSIDADE DO VALE DO RIO DOS SINOS - UNISINOS

UNIDADE ACADÊMICA DE GRADUAÇÃO

CURSO DE SISTEMAS DE INFORMAÇÃO

MARIANA STEIN DA SILVA

Um Método para Automação de Casos de

Teste Funcional a partir de User Stories

Canoas
2017
 MARIANA STEIN DA SILVA

Um Método para Automação de Casos de

Teste Funcional a partir de User Stories

Trabalho de Conclusão de Curso

apresentado como requisito parcial para
obtenção do título de Bacharel em
Sistemas de Informação, pelo Curso de
Sistemas de Informação da Universidade
do Vale do Rio dos Sinos - UNISINOS

Orientador: Prof. Dr. Leandro Teodoro Costa

Canoas
2017
 RESUMO

O processo de planejamento e execução de testes tem como objetivo garantir

a qualidade do sistema a ser desenvolvido. Esta qualidade se refere ao correto
funcionamento do software quando comparado ao seu documento de especificação
de requisitos. Os requisitos de um sistema são em grande parte dos projetos
tradicionais apresentados através de um documento de especificação, o qual
descreve detalhadamente todas as funcionalidades em formato de texto extenso.
Este tipo de documentação revelou uma dificuldade por parte dos testadores no
momento da elaboração de seus artefatos de trabalho devido a extensão deste
documento, a complexidade de entendimento, ambiguidade e difícil manutenção e
controle. Uma alternativa atualmente difundida para solucionar esse problema é a
utilização de User Stories para definição dos requisitos e funcionalidades do
sistema. User Stories são artefatos utilizados para documentar uma necessidade do
cliente de forma clara e objetiva, além de contribuir para o melhor aproveitamento de
tempo, devido a sua simplicidade de elaboração. Neste contexto, o presente
trabalho tem como objetivo de demonstrar a melhoria no tempo necessário para
gerar scripts de teste funcional a partir do uso de User Stories quando comparado
com a abordagem tradicional de geração de casos de teste. Para atingir este
objetivo, será conduzida a execução de um estudo de caso com profissionais de
uma empresa de desenvolvimento de software.

Palavras-chave: Teste funcional. User Story. Automação de teste. Scripts de teste.

 ABSTRACT

Planning and execution of tests aims to guarantee the quality of a software

system. This quality refers to the correct behavior of the software when compared to
its requirements specification. In most of traditional projects, the system requirements
are described in a document with an extensive text format. This type of document
has brought several problems for testers when creating their test artifacts since this
document could contributes to misinterpretation, present ambiguity and difficult of
maintenance and control. An alternative to overcome this issue is the use of User
Stories for documenting system functionalities. User Stories are artifacts used to
document a customer's need in a clear and objective manner, as well as contribute to
the best use of time, due to its simplicity. In this context, this work aims to
demonstrate how to reduce the time to generate functional test cases from User
Stories when compared to the traditional way to generate test cases. In order to
achieve this objective, a case study will be performed with employees of a software
development company.

Keywords: Functional testing. User Story. Test automation. Test scripts.

 4

LISTA DE FIGURAS

Figura 1 - O ciclo completo do Scrum 12

Figura 2 - Estrutura de uma User Story 15
Figura 3 - Modelo em V de Engenharia de Sistemas 17
 LISTA DE SIGLAS

IDE Integrated Development Environment

ISTQB International Software Testing Qualifications Board
MTM Microsoft Test Manager
QTP HP Quick Test Professional
RFT IBM Rational Functional Tester
UML Unified Modeling Language
VS Microsoft Visual Studio
 SUMÁRIO

1 INTRODUÇÃO.......................................................................................................... 7
1.1 PROPOSTA DE SOLUÇÃO................................................................................................7
1.2 OBJETIVOS................................................................................................................ 9
1.2.1 Objetivo Geral....................................................................................................9
1.2.2 Objetivos Específicos....................................................................................... 9
2 FUNDAMENTAÇÃO TEÓRICA.............................................................................. 10
2.1 METODOLOGIAS ÁGEIS............................................................................................... 10
2.1.1 Manifesto para Desenvolvimento Ágil de Software..................................... 10
2.1.2 Scrum............................................................................................................... 11
2.1.3 User Stories..................................................................................................... 15
2.2 TESTE DE SOFTWARE.......................................................................................16
2.2.1 Níveis de Teste................................................................................................ 17
2.2.1.1 Teste Unitário................................................................................................. 17
2.2.1.2 Teste de Integração........................................................................................18
2.2.1.3 Teste de Sistema............................................................................................18
2.2.1.4 Teste de Aceitação......................................................................................... 19
2.2.2 Tipos de Teste................................................................................................. 19
2.2.2.1 Teste Funcional.............................................................................................. 19
2.2.2.2 Teste Não Funcional.......................................................................................20
2.2.2.3 Teste Estrutural.............................................................................................. 20
2.2.2.4 Teste de Regressão....................................................................................... 20
2.2.3 Automação de Teste....................................................................................... 21
2.2.3.1 HP Quick Test Professional............................................................................21
2.2.3.2 IBM Rational Functional Tester...................................................................... 22
2.2.3.3 Selenium........................................................................................................ 22
3 METODOLOGIA..................................................................................................... 23
4 CONCLUSÃO................................................................................................................ 25
REFERÊNCIAS..........................................................................................................27
 7

1 INTRODUÇÃO

Parte do processo de desenvolvimento de um software se refere a etapa de

qualidade. Nesta etapa é realizada uma das principais atividades deste processo,
i.e., a execução de testes no sistema. Esta atividade tem como objetivo verificar se o
sistema se comporta de acordo com o esperado. (PEZZÈ; YOUNG, 2008). Neste
contexto, existem diversos tipos de teste que visam garantir a qualidade do sistema,
e.g., Teste Estrutural, Teste de Regressão, Teste Não Funcional e Teste Funcional.
(PEZZÈ; YOUNG, 2008).
O Teste Funcional, como parte do processo de teste, tem por objetivo validar
as funcionalidades do sistema. O objetivo deste tipo de teste é garantir que estas
funcionalidades estejam de acordo com o que foi descrito no documento de
especificação dos requisitos. No entanto, durante a execução do Teste Funcional, é
comum encontrar defeitos em determinada funcionalidade do sistema devido a
ocorrência de falhas e inconsistências no documento de requisitos. (KOSCIANSKI;
SOARES, 2007).
O problema é que estes requisitos são, majoritariamente, descritos em
documentos no formato texto. Por este motivo, implicam em uma maior dificuldade
no que se refere à sua compreensão, tanto por parte dos desenvolvedores quanto
testadores, pois o documento de requisitos é utilizado como referência para a
geração de código e artefatos de teste.
Neste contexto, o documento de requisitos no formato de texto, por se tratar
de um arquivo normalmente extenso e pouco intuitivo, pode representar uma
dificuldade no trabalho do analista de teste e do testador. Por exemplo, dificuldades
de entendimento, ambiguidade de sentido, duplicidade de informação são alguns
dos problemas que podem ser encontrados em uma especificação de requisitos.
(FILHO, 2003). Desta forma, percebe-se a necessidade de melhoria na
representação dos requisitos do sistema, de forma a contribuir também na definição
de uma abordagem de teste mais rápida e consistente.

1.1 PROPOSTA DE SOLUÇÃO

Com o objetivo de tornar a atividade de teste menos onerosa e prover

automação no processo de geração de casos de teste funcional e scripts, é possível
 8

especificar os requisitos do sistema utilizando uma abordagem alternativa de

especificação, i.e., User Stories (COHN, 2004). User Stories são artefatos originários
de metodologias ágeis, as quais possibilitam um melhor aproveitamento do tempo
no processo de desenvolvimento e recursos humanos (desenvolvedores, analista de
teste ou testadores). Além disso, devido a capacidade das User Stories de
descreverem os requisitos em um formato mais simples, intuitivo e de fácil
compreensão é possível automatizar a geração de casos de teste funcional e scripts
para diversas tecnologias de teste, e.g., HP Quick Test Professional (MALLEPALLY,
2009), IBM Rational Functional Tester (DAVIS, et al. 2009), Microsoft Test Manager
(LEVINSON, 2011), Microsoft Visual Studio (LEVINSON, 2011) e Selenium
(AVASARALA, 2014).
De maneira semelhante às User Stories, a automação de testes funcionais
melhora o aproveitamento de tempo disponível para qualidade de software. Unindo e
trazendo essas duas conhecidas vantagens para um ambiente de projeto, são
verificadas, através dessa pesquisa, as melhorias a serem atingidas no processo de
teste. Esta verificação é feita com base na análise de contextos do cenário atual e
comparação com o método proposto neste trabalho.
Desta forma, este trabalho tem como objetivo elaborar um método capaz de
gerar casos de teste funcional e scripts de forma automatizada para diferentes
tecnologias, e.g., QTP, RFT, MTM, VS ou Selenium. Para tal objetivo, estes casos de
teste e scripts serão gerados a partir de requisitos de sistema especificados em User
Stories para a geração de uma estrutura intermediária. Esta estrutura intermediária
se trata de um documento no formato texto, o qual especifica os casos de teste em
uma pseudo liguagem natural independente de tecnologia. Ao final, scripts de teste
funcional podem ser gerados para diferentes tecnologias de teste.
Em poucas palavras, o presente trabalho busca responder a seguinte questão
de pesquisa: Como obter uma melhoria no processo de teste por meio da
automação de casos teste funcional e scripts a partir de requisitos descritos
em User Stories?
 9

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Aprimorar o processo de teste de software através da geração automatizada

de casos de teste funcional e scripts a partir de requisitos especificados em User
Stories.

1.2.2 Objetivos Específicos

A seguir são apresentadas as etapas necessárias para atingir o objetivo geral

deste trabalho:
a) conhecer e definir conceitos pertinentes a área de pesquisa por meio de
uma revisão de literatura;
b) apresentar as soluções mais recentes da comunidade científica com o
objetivo de guiar esta pesquisa;
c) desenvolver uma ferramenta a partir do método proposto neste trabalho;
d) utilizar a ferramenta desenvolvida para testar duas aplicações: uma real,
utilizada na indústria, e outra de uso acadêmico;
e) conduzir e realizar um estudo de caso com profissionais de uma empresa
de desenvolvimento de software;
f) extrair os resultados obtidos com o uso da ferramenta desenvolvida;
g) demonstrar as melhorias atingidas.
 10

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo, são abordados os temas relacionados à área de pesquisa

deste trabalho, i.e., Metodologias Ágeis e Teste de Software. O objetivo é elucidar os
conceitos a serem abordados, dando embasamento teórico aos temas deste
trabalho.

2.1 METODOLOGIAS ÁGEIS

Com o objetivo de padronizar suas atividades, o processo de desenvolvimento

de software, para ser feito de maneira efetiva, conta com técnicas e metodologias,
e.g., Modelo Cascata (ROYCE, 1970) e Modelo Espiral (BOEHM, 1988).
(KOSCIANSKI; SOARES, 2007). No entanto, com o dinamismo das organizações
atuais, estas técnicas também necessitam ser aprimoradas/adaptadas para atender
às mudanças que ocorrem nestas organizações. Neste contexto, uma possível
solução a este problema seriam as metodologias ágeis.
Metodologias ágeis são métodos de desenvolvimento para projetos que
permitem a adaptação a diferentes tamanhos e formatos de equipe. (CRUZ, 2014).
Estes métodos também permitem que o trabalho seja desenvolvido de maneira mais
dinâmica e eficiente, promovendo a agilidade dos processos necessários para atingir
os objetivos do projeto.
Apesar de algumas destas metodologias terem sido criadas anteriormente, o
termo “ágil” começou a ser utilizado no contexto de desenvolvimento de software a
partir do Manifesto para o Desenvolvimento Ágil de Software.

2.1.1 Manifesto para Desenvolvimento Ágil de Software

Em 2001 um grupo de dezessete pessoas se reuniu, em um resort de esqui

nos montes Wasatch em Utah - EUA, para uma integração informal com o objetivo
de discutir aspectos importantes no processo de desenvolvimento de software.
(AGILE MANIFESTO, 2001). Entre essas pessoas, estavam representantes de
metodologias como Extreme Programming (BECK; ANDRES, 2004), Scrum
(SUTHERLAND, 2014), Feature-Driven Development (PALMER; FELSING, 2002) e
 11

outros simpatizantes de alternativas para processos de desenvolvimento de software

já conhecidos, guiados a documentação abrangente.
A partir deste encontro, surgiu o Manifesto para Desenvolvimento Ágil de
Software, um guia de princípios a serem seguidos por diferentes metodologias.
Segundo Apke (2015), no texto a seguir são definidos os objetivos que os autores
almejavam, i.e., um conjunto de ideias simples, porém significativas para o princípio
do desenvolvimento ágil de software:

“Estamos descobrindo maneiras melhores de desenvolver software,

fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através
deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens
à esquerda.”

A partir da definição destes princípios, o manifesto ágil se tornou um guia para

seus criadores e defensores. Além disso, ele passou a ser seguido por diversos
apoiadores, e.g., representantes da IBM (AM1, 2016), Dell Inc (AM2, 2008) e
Microsoft (AM3, 2006), e também serve como referência para enfatizar a agilidade
presente nas metodologias de desenvolvimento de software como o Scrum.

2.1.2 Scrum

A definição de Scrum, que foi desenvolvida em 1993 por Jeff Sutherland e

formalizada em 1995 por Ken Schwaber, trata de uma estrutura que apresenta uma
maneira mais rápida e eficiente de desenvolver softwares. (SCHWABER; BEEDLE,
2002).
Segundo seu criador, Sutherland (2014), o nome Scrum é originário de uma
jogada de reposição de bola no rúgbi. Nesta jogada, onde os dois times disputam a
bola, é necessária a participação de todos os jogadores da equipe, atuando em
conjunto com o mesmo objetivo. Sendo este, exatamente, o comportamento
esperado pelo autor na atuação das equipes que utilizam o Scrum.
Criado originalmente como uma solução para o desenvolvimento de software
na indústria da tecnologia, o Scrum provou seus benefícios quando aplicado em
 12

diversos outros segmentos, como finanças, saúde e telecomunicação.

(SUTHERLAND, 2014).
Com o objetivo de obter estes benefícios, a metodologia Scrum define uma
equipe, a qual é composta por três papéis: Scrum Master, Product Owner e o Scrum
Team. (CRUZ, 2014).
● Scrum Master: o papel do Scrum Master no projeto é servir de facilitador
para a equipe. Assume a responsabilidade de auxiliar nas dificuldades dos
membros do time e também atua na garantia da aplicabilidade das práticas
do Scrum. Assim, a equipe se mantém sempre em sintonia;
● Product Owner: este profissional é responsável pela definição do produto.
O Product Owner deve ter entendimento sobre o produto, pois sua
responsabilidade é de elaborar os requisitos do projeto, mantendo contato
com o cliente. Além disso, também fazem parte de suas atribuições as
tarefas de planejamento e encerramento do que está sendo desenvolvido;
● Scrum Team: são todos os demais membros da equipe, e.g.,
desenvolvedores, analistas e testadores. Estes profissionais são
responsáveis por executar as tarefas pertinentes ao projeto, tais como,
análise de requisitos, codificação e execução de testes.
Segundo Cruz (2014), estes membros da equipe desenvolvem em conjunto o
ciclo completo de vida do Scrum. Este ciclo é composto por 7 artefatos e cerimônias
principais (ver Figura 1):

Figura 1 - O ciclo completo do Scrum

Fonte: Schwaber & Beedle (2002).

 13

Product Backlog

O Product Backlog é composto por uma lista de tarefas com prioridade que se
referem às necessidades do projeto. Os itens do Product Backlog propõem o que
será produzido ao longo do projeto, i.e., os requisitos do sistema. Cada um destes
itens é ordenado em uma lista de acordo com sua prioridade. Os itens mais
prioritários são àqueles que ficam no topo desta lista e consequentemente devem
ser desenvolvidos primeiro.

Sprint

Um Sprint é um período de tempo, normalmente definido entre 2 e 4

semanas, no qual será desenvolvido um conjunto de atividades do projeto. Durante
o Sprint são implementados determinados requisitos do sistema, os quais são
previamente definidos no planejamento do Sprint. A saída de um Sprint é um
incremento do produto que está em desenvolvimento, i.e., novas funcionalidades
que são incorporadas ao produto.

Sprint Planning

Trata da reunião de planejamento que deve ocorrer sempre ao início de um

novo Sprint. Nesta reunião o Scrum Team juntamente com o Product Owner
selecionam os requisitos que serão desenvolvidos durante o Sprint com base na
prioridade de cada item.

Sprint Backlog

A partir da Sprint Planning é apresentado o Sprint Backlog. Este é definido

como a meta do Sprint, i.e., uma porcentagem de itens que serão desenvolvidos
nesse período. Os itens que compõem o Sprint backlog normalmente são escolhidos
com base nas suas prioridades.
 14

Daily Scrum

Após o início efetivo das atividades do Sprint, os membros do Scrum Team

devem se reunir diariamente para uma reunião chamada Daily Scrum. Alguns dos
objetivos desta reunião são: dar visibilidade ao trabalho que cada membro da equipe
está realizando, planejar os próximos dias de trabalho e comunicar os possíveis
problemas que estão enfrentando. Desta forma, a colaboração entre o time ocorre
de forma natural, de maneira que nenhum membro da equipe fique com suas
atividades bloqueadas.

Sprint Review

Ao final de cada Sprint, são realizadas duas reuniões consecutivas com o

objetivo de avaliar o andamento do projeto, i.e, Sprint Review e Sprint Retrospective,
respectivamente. Na Sprint Review são realizadas avaliações e possíveis
adaptações no produto. Os participantes desta reunião são o Product Owner e o
Scrum Team, os quais apresentam aos clientes do projeto o que foi produzido
durante o Sprint com o objetivo de obter informações úteis a serem acrescentadas
no produto. Estas informações servirão como artefatos para incrementar o Product
Backlog, a partir do qual novos requisitos podem ser acrescentados.

Sprint Retrospective

Na sequência da Sprint Review é realizada a Sprint Retrospective. O foco

desta reunião é avaliar o desempenho do time de Scrum, onde alguns fatores são
quantificados, e.g., o que ocorreu bem durante o Sprint e o que poderia ser
aprimorado. Nos casos em que o desempenho do time foi positivo, as ações
realizadas devem ser mantidas para o Sprint seguinte. Ao passo que nos pontos de
melhoria, o time pode rever as boas práticas, a fim de obter maior qualidade do
trabalho, tornando o desempenho do time mais ágil e efetivo.
Além dos artefatos apresentados anteriormente, as equipes que utilizam o
Scrum podem contar com um outro artefato para o desenvolvimento de suas tarefas,
i.e., User Stories.
 15

2.1.3 User Stories

Com base no objetivo “Software em funcionamento mais que documentação

abrangente” do Manifesto Ágil, os criadores do Extreme Programming
desenvolveram uma abordagem simples para documentar requisitos de software,
i.e., as User Stories. (BECK; ANDRES, 2004). User Stories são definidas como um
tipo de documentação cujo objetivo é apresentar uma necessidade do cliente de
forma clara e objetiva, servindo de base para desenvolvedores e testadores
implementarem seus artefatos de trabalho.
De acordo com Jeffries (2001), as User Stories possuem três características,
conhecidas como os 3 C’s, que as definem e diferenciam de outros métodos de
documentação:
● Cartão: a ideia de se utilizar um cartão é a de pensar em um texto para
apresentar uma necessidade do cliente. É importante que este texto seja
pequeno e objetivo o suficiente para ser escrito em um cartão. Este texto
servirá como convite para uma conversa;
● Conversas: a partir do cartão, surgirão as conversas entre os membros da
equipe e clientes. Estas conversas têm o objetivo de refinar o texto inicial
descrito anteriormente no cartão;
● Confirmação: após a etapa de conversas, os objetivos de uma User Story
estão definidos e são documentados no cartão de forma que se mantenha
um registro do que foi acordado durante as conversas.
Segundo Cohn (2004), com base na ideia da utilização de um cartão para a
escrita da User Story, a estrutura básica desta se assemelha ao exemplo
apresentado na Figura 2.

Figura 2 - Estrutura de uma User Story

 16

Fonte: Adaptado de Cohn (2004)

O objetivo de um cartão é apresentar uma frase compacta que defina a

intenção do usuário dentro do sistema. Desta forma, o padrão mais utilizado para se
escrever uma User Story estabelece três parâmetros: “Quem”, “O Quê” e “Por Quê”.
● Quem: define quem é o usuário que vai se beneficiar desta User Story;
● O Quê: define a necessidade/objetivo deste usuário dentro do sistema;
● Por Quê: define o benefício que este usuário irá usufruir a partir da
implementação da User Story.
Em Cohn (2004), é apresentado um conjunto de critérios para auxiliar na
criação de User Stories, destacando os indicadores que definem uma User Story
bem elaborada. Estes critérios são sintetizados no acrônimo INVEST, o qual define
os padrões que devem ser seguidos para a criação de uma story:
● Independent – Independente das demais User Stories;
● Negotiable – Negociável, relativo às Conversas dos 3 C’s;
● Valuable – Valiosa, deve agregar valor de negócio para os clientes;
● Estimable – Estimável;
● Small – Pequena;
● Testable – Testável.
No caso de algum destes padrões falhar, a reescrita da User Story deve ser
considerada.
Por se tratar de uma abordagem para documentação de requisitos de um
sistema, as User Stories, no contexto de desenvolvimento ágil de software, vêm
sendo utilizadas por analistas de teste como artefato de referência para análise e
teste de software.

2.2 TESTE DE SOFTWARE

Com o advento de novos softwares e aplicativos para solução de diversos

problemas, é comum se deparar com uma situação de insatisfação por parte do
cliente na utilização destas aplicações. Neste contexto, sistemas que não funcionam
da maneira esperada causam desconforto ao usuário, geram desperdício de tempo
e também de recursos por parte das empresas (ISTQB, 2011).
 17

Um software para ser considerado de alta qualidade deve atender aos

requisitos definidos pelo usuário de maneira satisfatória e não apresentar falhas
durante sua execução. (ISTQB, 2011). Desta forma, partindo do processo de
desenvolvimento destes softwares, é possível observar que estes são feitos por
pessoas, as quais estão sujeitas a cometer falhas, independentemente do nível de
conhecimento e experiência na área de desenvolvimento.
Com o objetivo de encontrar e corrigir estas falhas, o processo de teste de
software visa também medir a qualidade de um software, seja com base no número
de defeitos encontrados ou na ausência deles. (KOSCIANSKI; SOARES, 2007).
De acordo com Myers e Sandler (2004), o teste durante o ciclo de vida do
software, pode ser dividido em quatro níveis ou fases, i.e., Teste Unitário, Teste de
Integração, Teste de Sistema e Teste de Aceitação.

2.2.1 Níveis de Teste

De acordo com o modelo tradicional em V de Engenharia de Sistemas

definido por Pèzze e Young (2008) e apresentado na Figura 3, o processo de teste
de software possui quatro níveis: Unitário, Integração, Sistema e Aceitação. Desta
forma, para cada nível de teste, alguns aspectos podem ser identificados, e.g., seus
objetivos, os responsáveis por executar cada nível de teste e em que ferramentas e
abordagens os responsáveis podem se referenciar para atingir os objetivos dos
testes.

Figura 3 - Modelo em V de Engenharia de Sistemas

Fonte: Adaptado de Pezzè e Young (2008)

 18

2.2.1.1 Teste Unitário

O Teste Unitário, também conhecido como Teste de Unidade ou Componente,

tem o objetivo de verificar o funcionamento do software em módulos menores que
são testáveis separadamente, e.g., objetos, funções e classes do sistema. (ISTQB,
2011). Este tipo de teste é, normalmente, realizado pela equipe de desenvolvedores
do software, pois pode ser testado juntamente com o acesso ao código do
componente que está sendo verificado.
Dentre as estratégias de teste que podem ser utilizadas para testar as
unidades do software, é possível citar o Teste Funcional e de Teste Estrutural (ver
seções 2.2.2.1 e 2.2.2.3). Através destas estratégias, o Teste Unitário possibilita a
identificação de falhas nas fases iniciais do processo de desenvolvimento, o que
contribui para o aumento da qualidade do sistema que está sendo desenvolvido.
(PEZZÈ; YOUNG, 2008).

2.2.1.2 Teste de Integração

Um dos objetivos do Teste de Integração é verificar a compatibilidade dos

módulos testados individualmente durante o Teste Unitário. Entretanto, o Teste de
Integração também pode ser feito a nível de sistemas, visando testar a interação
entre diferentes sistemas. (PEZZÈ; YOUNG, 2008).
Em ambos os casos, quanto maior for o escopo de integração, maior será a
dificuldade em isolar as falhas e detectar a origem do problema. Sendo assim,
assume-se que, durante o Teste de Integração, os módulos e unidades que estão
sendo verificados foram testados de maneira efetiva na fase de Teste de Unidade.
(ISTQB, 2011).

2.2.1.3 Teste de Sistema

Partindo do princípio que todos os módulos de um software foram testados

individualmente e integrados com sucesso, o Teste de Sistema é executado sob o
software que está sendo desenvolvido. O objetivo deste teste é realizar uma
verificação para garantir que as funcionalidades do sistema estejam de acordo com
a sua especificação. (PEZZÈ; YOUNG, 2008). Esta especificação pode ser
 19

apresentada em forma de documento descrevendo riscos e/ou requisitos, processos

de negócios e casos de uso e diagramas do sistema.
A partir da especificação, o time de testadores irá aplicar o Teste de Sistema
com o objetivo de garantir a correção de todos os defeitos encontrados e a
completude do produto.

2.2.1.4 Teste de Aceitação

O Teste de Aceitação tem por objetivo garantir que o sistema está em acordo
com as expectativas do cliente. Desta forma, os principais responsáveis pela
execução deste tipo de teste são os próprios clientes, usuários e interessados no
sistema. (ISTQB, 2011).
Além disso, é importante destacar que nesta fase o software já foi testado nos
níveis de Unidade, Integração e Sistema por equipes capacitadas. Portanto, o Teste
de Aceitação não tem como objetivo principal identificar novos defeitos, mas sim
orientar sobre a possibilidade de o software ser liberado para o ambiente de
produção. Esta decisão pode ser definida com base nos julgamentos dos usuários
do sistema sobre sua utilidade e satisfação com o produto. (PEZZÈ; YOUNG, 2008).
Em cada uma destas fase/níveis de teste, alguns tipos de teste podem ser
aplicados, i.e., Teste Funcional, Teste Não Funcional, Teste Estrutural e Teste de
Regressão.

2.2.2 Tipos de Teste

Com o objetivo de verificar cada parte do sistema, os testes podem ser

divididos em diferentes tipos, i.e., Teste Funcional, Teste Não Funcional, Teste
Estrutural e Teste de Regressão. De acordo com Pezzè e Young (2008), cada tipo de
teste é direcionado para um objetivo em particular, sendo estes detalhados a seguir.

2.2.2.1 Teste Funcional

A especificação funcional de um sistema é a descrição do comportamento

esperado para este sistema e pode ser documentada em diversos formatos, e.g.,
documento de especificação de requisitos, casos de uso e diagramas UML. (ISTQB,
 20

2011). Esta especificação serve de referência para a geração de casos de teste

funcional.
O teste funcional, também conhecido por teste caixa-preta, baseia-se no teste
das funcionalidades de um sistema a partir da sua especificação. Ele tem como
objetivo encontrar discrepâncias entre o que um programa faz e o que deveria fazer.
Além disso, por ter grande enfoque na especificação do sistema, este tipo de teste
também permite revelar defeitos e falhas no próprio documento de especificação
funcional. (PEZZÈ; YOUNG, 2008).

2.2.2.2 Teste Não Funcional

Os testes não funcionais têm por objetivo verificar como o sistema funciona
por meio do teste dos atributos de determinado componente do sistema que não se
relacionam com suas funcionalidades, e.g., confiabilidade, usabilidade, eficiência e
portabilidade. (PEZZÈ; YOUNG, 2008).
Com a finalidade de atingir este objetivo, os seguintes testes podem ser
executados sob o sistema: teste de desempenho, teste de estresse, teste de
usabilidade, teste de carga, teste de confiabilidade, teste de portabilidade e teste de
interoperabilidade. (ISTQB, 2011). Além disso, é importante ressaltar que muitos
destes tipos de teste podem ser aplicados em todos os níveis de teste.

2.2.2.3 Teste Estrutural

A estrutura do software é uma valiosa fonte de informação para determinar se

um conjunto de casos de teste é suficientemente rigoroso, pois por meio dessa
estrutura é possível verificar quais outros testes são necessários para revelar falhas
não descobertas no teste funcional. (PEZZÈ; YOUNG, 2008).
O Teste Estrutural, também conhecido como teste caixa-branca, é feito com
base na estrutura do código fonte do sistema e tem como objetivo garantir que a
cobertura de teste seja aplicada a todas as partes do código. (ISTQB, 2011).
 21

2.2.2.4 Teste de Regressão

No momento do desenvolvimento de uma nova versão do sistema, seja para

remoção de falhas ou adição de novos requisitos, podem ser alteradas
funcionalidades já existentes de maneira não intencional. Estas alterações podem
gerar um comportamento não esperado para o sistema e, portanto, novos defeitos
podem ser detectados. Desta forma, estas falhas geram uma regressão no sistema,
pois uma parte do sistema que estava funcionando, parou de funcionar. (PEZZÈ;
YOUNG, 2008).
Com o objetivo de evitar que este tipo de falha ocorra, o Teste de Regressão,
quando executado após uma alteração no código, garante a integridade das
funcionalidades já existentes no sistema. O teste de regressão pode ser realizado
em todos os níveis de teste, e se aplica aos demais tipos de testes, i.e., Funcional,
Não Funcional e Estrutural. (ISTQB, 2011). Além disso, testes de regressão são
executados repetidas vezes durante todo o desenvolvimento do software, o que faz
com que seja um forte candidato à automação.

2.2.3 Automação de Teste

Independentemente do nível de conhecimento técnico do testador, o teste

manual apresenta limitações referentes ao tempo de execução e está propenso a
falhas humanas. Estas falhas ocorrem, normalmente, devido a execução de tarefas
repetitivas, as quais geram exaustão às pessoas, podendo assim ocasionar em falta
de atenção na execução de suas atividades. Por outro lado, tarefas repetitivas, são
mais facilmente automatizáveis. (PEZZÈ; YOUNG, 2008).
Com o objetivo de aprimorar as tarefas relacionadas a etapa de qualidade do
desenvolvimento de software, a automação de teste auxilia os testadores na
obtenção de resultados de forma mais rápida e eficiente.
A automação é um fator importante na melhoria do processo de teste. No
entanto, para que isso ocorra de maneira satisfatória, é necessário ter conhecimento
das ferramentas mais adequadas, levando em consideração informações referentes
ao projeto, e.g., as tecnologias, processos e tipos de teste que se deseja
automatizar.
 22

A seguir, são apresentadas algumas das ferramentas disponíveis no mercado

e a descrição de suas principais características e funcionalidades.

2.2.3.1 HP Quick Test Professional

O HP Quick Test Professional (QTP) foi originalmente desenvolvido pela

Mercury Interactive sendo adquirido posteriormente pela HP. Esta ferramenta
possibilita a execução de testes funcionais de forma automatizada utilizando Visual
Basic Script (BRENNER, 2005) para a automação de aplicações.
A ferramenta possui uma interface simples e de fácil entendimento, além de
permitir integração com aplicações de gerenciamento de teste como o HP Quality
Center. (MALLEPALLY, 2009). Além disso, através da ferramenta é possível gerar
relatórios de resultados da execução dos casos de teste.

2.2.3.2 IBM Rational Functional Tester

O IBM Rational Functional Tester (RFT), é uma ferramenta que provê a

automação de testes funcionais fazendo uso da técnica Record & Playback para a
geração de seus scripts. Esta técnica consiste na gravação de todas as interações
do usuário com a aplicação a ser testada, para que sejam posteriormente
reproduzidas conforme a necessidade do testador. (DAVIS, et al. 2009).
Após a execução dos casos de teste gerados pelo RFT, a ferramenta
disponibiliza a visualização de relatórios desta execução, dando ao testador
visibilidade sobre os resultados obtidos. Esta ferramenta é bastante utilizada para
teste em aplicativos baseados na Web, #Net e Java.

2.2.3.3 Selenium

O Selenium é um framework que provê a automação de teste funcional para

aplicações web. O Selenium possui duas ferramentas para automatizar ações em
um browser, i.e., o Selenium IDE e o Selenium Webdriver. (AVASARALA, 2014).
O Selenium IDE utiliza uma interface para gravar e reproduzir as ações no
navegador, i.e., Record & Playback. Esta ferramenta está disponível apenas para o
navegador Firefox através de um plugin. Já o Selenium Webdriver é uma biblioteca
 23

que suporta diversas linguagens de programação e através dele é possível gerar

scripts de teste para diferentes navegadores, oferecendo recursos adicionais ao
Selenium IDE.
 24

3 METODOLOGIA

A pesquisa é um procedimento sistemático cujo objetivo é obter respostas aos

problemas propostos. Para solucionar tais problemas, várias fases constituem esse
procedimento, partindo da formulação do problema (questão de pesquisa) até a
discussão dos resultados. (GIL, 2007). Desta forma, tendo sido definido o problema
dessa pesquisa, ela foi classificada como exploratória, a qual tem por finalidade
explorar conceitos recentes ou inéditos, apresentando hipóteses que poderão servir
como base a pesquisas complementares.
A pesquisa exploratória tem por objetivo proporcionar familiaridade com o
problema encontrado, fazendo com que este seja mais explícito, possibilitando a
construção de hipóteses. Para auxiliar na construção dessas hipóteses, esse
trabalho, semelhantemente a grande maioria desse tipo de pesquisa, apresenta um
levantamento bibliográfico, a definição de um estudo de caso onde serão realizadas
entrevistas com profissionais que tiveram experiências práticas com o problema
pesquisado e a análise de exemplos que estimulem a compreensão. Sendo assim,
essas abordagens de pesquisas podem ser classificadas como: pesquisa
bibliográfica e estudo de caso.
Conforme apresentado no Capítulo 2, a revisão de literatura sobre os temas
que cercam o presente trabalho auxilia no esclarecimento dos conceitos pertinentes
a este estudo. Segundo Lakatos e Marconi (2010), os temas e tópicos abordados em
uma revisão de literatura podem ser obtidos por meio de uma pesquisa estruturada
em diversas bases de dados. Além disso, descrever tais temas é útil para adquirir e
apresentar conhecimentos que servem de apoio à área de interesse, evitar
duplicações de estudos ou esforços desnecessários, bem como sugerir novos
problemas e hipóteses.
Os temas e tópicos descritos na fundamentação teórica deste trabalho são
embasados nas literaturas conhecidas sobre os temas relativos à essa pesquisa.
Entre essas literaturas, além dos livros podemos citar as teses, dissertações,
relatórios de pesquisa e artigos de outros pesquisadores da área. De acordo com
Lakatos e Marconi (2010), a leitura destes materiais, permite o entendimento e
interpretação dos assuntos. Essa interpretação é necessária para poder realizar a
distinção dos elementos mais significativos para que o pesquisador possa construir e
apresentar seu entendimento sobre o tema.
 25

A partir do estudo e levantamento do referencial teórico apresentado neste

trabalho, será utilizado como metodologia de pesquisa um estudo de caso em uma
empresa cujos objetivos estejam de acordo com o tema proposto neste trabalho. O
estudo de caso, segundo Yin (2010, p. 39), “é uma investigação empírica que estuda
um fenômeno contemporâneo dentro de seu contexto da vida real, especialmente
quando os limites entre o fenômeno e o contexto não estão claramente definidos”.
O estudo de caso, segundo Gil (2008) serve de apoio às pesquisas para os
seguintes propósitos:
a) explorar situações da vida real cujos limites não estão claramente
definidos;
b) descrever a situação do contexto em que está sendo feita determinada
investigação;
c) explicar as variáveis causais de determinado fenômeno em situações muito
complexas que não possibilitam a utilização de levantamentos e
experimentos.
Desta forma, o estudo de caso consegue atender aos objetivos desse
trabalho, pois serão analisadas as situações em que se encontram os profissionais
da empresa analisada que poderão se beneficiar do objeto de estudo aqui
apresentado. Partindo desta análise, o método de teste a ser definido neste trabalho
poderá servir como uma alternativa para suprir as dificuldades encontradas durante
a etapa do estudo de caso.
 26

4 CONCLUSÃO

Este trabalho apresentou uma proposta de solução para o problema

relacionado à geração manual de casos de teste a partir de User Stories. Esta
solução consiste na geração e execução automatizada de casos de teste funcional e
scripts para diversas ferramentas de automação de teste a partir de informações
(dados de entrada e resultado esperado) de teste inseridas em User Stories.
Portanto, o objetivo é demonstrar que o método proposto neste trabalho é capaz de
auxiliar testadores e analistas de teste em suas atividades de forma mais eficiente
(menor tempo) quando comparado com a abordagem tradicional de testes a partir de
User Stories, i.e., onde os casos de teste são gerados de forma manual.
Para que esse objetivo possa ser alcançado de maneira satisfatória, uma
série de etapas foi definida para a pesquisa deste trabalho. Dentre estas etapas,
algumas já foram concluídas até o momento e uma breve descrição sobre cada uma
delas é apresentada a seguir.
Inicialmente, para esclarecer os conceitos relacionados ao objetivo do
trabalho, foi realizado um estudo da arte sobre metodologias ágeis e teste de
software, como partes integrantes do referencial teórico. Neste contexto, as
metodologias ágeis foram definidas como importantes aliadas aos desenvolvedores
e testadores por apresentarem abordagens de desenvolvimento de projeto de
software mais rápidas e eficientes. De maneira semelhante, as User Stories foram
apresentadas como uma alternativa de documento para especificação de requisitos.
Esta alternativa se apresentou como uma solução de mais fácil compreensão e
melhor manutenibilidade quando comparada aos documentos de especificação
tradicionais.
Em seguida, foram apresentados os diferentes tipos e níveis de teste de
software (ver Capítulo 2), os quais auxiliam no aumento da qualidade de um sistema
de software. Para cada um destes tipos e níveis de teste, foram apresentados seus
objetivos, bem como em quais fases do ciclo de desenvolvimento de software cada
um deles é aplicado. Posteriormente, os conceitos relacionados a automação de
teste foram apresentados, bem como a sua importância para a melhoria na
qualidade do processo de teste. Além disso, as funcionalidades de algumas das
ferramentas de automação mais utilizadas no mercado foram detalhadas.
 27

Logo após, no Capítulo 3, foram definidos o tipo de pesquisa e os métodos

que foram e serão utilizados durante a elaboração deste trabalho. Neste contexto, a
pesquisa foi classificada como uma pesquisa exploratória, uma vez que neste
trabalho será apresentado um conceito novo ou pouco explorado na literatura. Além
disso, um levantamento bibliográfico foi realizado com o objetivo de verificar os
principais temas relacionados a esta pesquisa. Por fim, um estudo de caso será
aplicado com o intuito de analisar o uso do método proposto em um contexto real,
i.e., em uma empresa de desenvolvimento de software.
Uma vez apresentados os objetivos para o método proposto neste trabalho,
as próximas etapas para atingir tais objetivos são:
a) elaborar o método proposto;
b) desenvolver uma ferramenta a partir dos conceitos definidos para o
método;
c) estruturar o estudo de caso (geração de questionários, seleção dos
profissionais);
d) executar o estudo de caso;
e) coletar e analisar os resultados obtidos;
f) propor trabalhos futuros e pontos que podem ser melhorados.
 28

REFERÊNCIAS

AGILE MANIFESTO, Manifesto para Desenvolvimento Ágil de Software, 2001.

Disponível em: <http://agilemanifesto.org/iso/ptbr/manifesto.html>. Acesso em: 15
nov. 2017.

AM1 AGILE MANIFESTO, Agile Manifesto Signatories, 2016. Disponível em:

<http://agilemanifesto.org/display/000000390.html>. Acesso em: 15 nov. 2017.

AM2 AGILE MANIFESTO, Agile Manifesto Signatories, 2008. Disponível em:

<http://agilemanifesto.org/display/000000125.html>. Acesso em: 15 nov. 2017.

AM3 AGILE MANIFESTO, Agile Manifesto Signatories, 2006. Disponível em:

<http://agilemanifesto.org/display/000000061.html>. Acesso em: 15 nov. 2017.

APKE, Larry. Understanding the Agile Manifesto. Morrisville: Lulu.com, 2015.

AVASARALA, Satya. Selenium WebDriver Practical Guide. Birmingham: Packt

Publishing Ltd, 2014.

BECK, Kent; ANDRES, Cynthia. Extreme Programming Explained: Embrace

Change. 2. ed. Boston: Addison-Wesley, 2004.

BOEHM, Barry W. A spiral model of software development and enhancement.

Computer, Vol. 21 no. 5, 1988. p. 61-72.

BRENNER, Norman. Visual Basic .NET: one Teacher’s Experience. Journal of

Computing Sciences in Colleges, vol. 21, no. 2, 2005. p. 89–94.

COHN, Mike. User Stories Applied: For Agile Software Development. Boston:
Pearson Education, 2004.

CRUZ, Fábio. Scrum e PMBOK. Unidos no Gerenciamento de Projetos. Rio de

Janeiro: Brasport, 2014.

DAVIS, Chip et al. Software Test Engineering with IBM Rational Functional
Tester: The Definitive Resource. Indiana: IBM Press, 2009.

FILHO, Wilson P. Engenharia de software – Fundamentos, Métodos e Padrões.

Rio de Janeiro: LTC, 2003.

GIL, Antonio C. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas,
2007.

______. Métodos e técnicas de pesquisa social. 6. ed. São Paulo: Atlas, 2008.

ISTQB. Certified Tester Foundation Level Syllabus, 2011. Disponível em

<https://www.istqb.org/downloads/send/2-foundation-level-documents/3-foundation-le
vel-syllabus-2011.html4>. Acesso em: 15 nov. 2017.

JEFFRIES, Ronald. Essential XP: Card, Conversation, Confirmation, 2001.

Disponível em
 29

<http://xprogramming.com/articles/expcardconversationconfirmation/>. Acesso em:

15 nov. 2017.

KOSCIANSKI, André; SOARES, Michel S. Qualidade de Software. 2. ed. São

Paulo: Novatec, 2007.

LAKATOS, Eva M.; MARCONI, Marina A. Fundamentos de metodologia científica.

7. ed. São Paulo: Atlas, 2010.

LEVINSON, Jeff. Software Testing with Visual Studio 2010. Boston:

Addison-Wesley Professional, 2011.

MALLEPALLY, Sridhar R. QuickTest Professional (QTP) Interview Questions and

Guidelines. Manchester: Parishta Incorporated, 2009.

MYERS, Glenford J.; SANDLER, Corey. The Art of Software Testing. New Jersey:
John Wiley & Sons, 2004.

PALMER, Stephen R.; FELSING, John M. A Practical Guide to Feature-Driven

Development. New Jersey: Prentice Hall, 2002.

PEZZÈ, Mauro; YOUNG, Michael. Teste e Análise de Software. Porto Alegre:

Bookman, 2008.

PRESSMAN, Roger S. Engenharia de Software. 7. ed. São Paulo: McGraw Hill

Brasil, 2009.

ROYCE, Winston W. Managing the Development of Large Software Systems.

Proceedings of IEEE WESCON, 26, 1970. p 328-388.

SCHWABER, Ken; BEEDLE, Mike. Agile Software Development with Scrum. New
Jersey: Prentice Hall, 2002.

SUTHERLAND, Jeff. Scrum: The Art of Doing Twice the Work in Half the Time. New
York: Crown Business, 2014.

YIN, Robert K. Estudo de caso: planejamento e métodos. 4. ed. Porto Alegre:

Bookman, 2010.