UNIVERSIDADE DO VALE DO RIO DOS SINOS - UNISINOS

UNIDADE ACADÊMICA DE GRADUAÇÃO

CURSO DE SISTEMAS DE INFORMAÇÃO

MARIANA STEIN DA SILVA

ATUS:
Um Método para Automação de Casos de
Teste Funcional a partir de User Stories

Canoas
2018
 MARIANA STEIN DA SILVA

ATUS:
Um Método para Automação de Casos de
Teste Funcional a partir de User Stories

Artigo 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
2018
 1

ATUS: UM MÉTODO PARA AUTOMAÇÃO DE CASOS DE TESTE FUNCIONAL A

PARTIR DE USER STORIES

Mariana Stein da Silva1*

Leandro Teodoro Costa2**

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 a sua especificação de
requisitos. Uma alternativa atualmente difundida para definição dos requisitos e
funcionalidades do sistema é o uso de User Stories. 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
demonstrar a melhoria no processo necessário para gerar scripts de teste funcional
a partir de User Stories quando comparado com a abordagem tradicional de geração
de casos de teste. Para atingir este objetivo, foi conduzido a execução de um estudo
de caso com profissionais de empresas de desenvolvimento de software.

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

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. Atualmente, com a difusão do uso de metodologias
ágeis para o controle de projetos de desenvolvimento de software, uma alternativa
comumente utilizada para especificação de requisitos são as User Stories. (COHN,
2004).

1
* Analista de Teste na empresa DBServer, CTFL, SFCTM. mariana.stein@hotmail.com
2**
Orientador, professor doutor em Ciência da Computação pela PUCRS. lteodoroc@unisinos.br
 2

User Stories são artefatos originários de metodologias ágeis, as quais

possibilitam um melhor aproveitamento do tempo no processo de desenvolvimento
de sistemas. Além disso, devido a capacidade das User Stories de descreverem os
requisitos em um formato 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 (QTP) (MALLEPALLY, 2009),
IBM Rational Functional Tester (RFT) (DAVIS, et al. 2009), Microsoft Test Manager
(MTM) (LEVINSON, 2011), Microsoft Visual Studio (VS) (LEVINSON, 2011) e
Selenium (AVASARALA, 2014).
No entanto, apesar dos benefícios advindos do uso de User Stories e de
ferramentas de teste, ainda é necessário executar várias atividades manuais ou
semiautomatizadas, e.g., a geração de casos de teste e scripts para tais
ferramentas, bem como a análise dos resultados e execução dos testes. Além disso,
a geração manual ou semiautomatizada de casos de teste a partir de user Stories
torna o processo de teste demorado e propenso à inserção de falhas, mesmo por
profissionais experientes.
Com o objetivo de contornar estas questões, neste trabalho é apresentado o
método ATUS (Automated Test case method from User Stories) o qual é capaz de
gerar scripts de teste funcional de forma automatizada para diferentes tecnologias
de teste. Para atingir tal objetivo, estes artefatos de teste são gerados a partir de
requisitos de sistema especificados em User Stories e, em seguida, uma estrutura
abstrata (pseudocódigo) é gerada. Esta estrutura abstrata possui um formato textual
e estruturado, o qual especifica os casos de teste em uma pseudo linguagem natural
independente de tecnologia. Ao final, scripts de teste são automaticamente gerados.
Uma das vantagens do método ATUS está relacionada à reutilização de
informações de teste, ou seja, as informações descritas na estrutura abstrata podem
ser reutilizadas para gerar scripts de teste para diversas ferramentas de teste
funcional, e.g., QTP, RFT, MTM, VS ou Selenium. Portanto, uma empresa que está
usando uma ferramenta de teste A pode, motivada por uma decisão técnica ou
gerencial, facilmente migrar para uma ferramenta de teste B sem ter que criar novos
casos de teste. Outra vantagem está relacionada ao uso de User Stories para gerar
casos de teste. As User Stories fornecem uma representação das informações de
teste em um alto nível, facilitando o entendimento pelo especialista em teste
 3

responsável pela implementação e execução dos casos de teste. Além disso,

diferentemente de outros estudos que descrevem apenas o processo para gerar
casos de teste por meio de User Stories, nossa abordagem é capaz de instanciá-los
para gerar scripts de teste que podem ser executados por diferentes ferramentas de
teste funcional.
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?
Ao final, foi conduzido a execução de um estudo de caso com profissionais de
empresas na área de desenvolvimento de software com o objetivo de avaliar a
eficiência e aplicabilidade do método proposto.

2 FUNDAMENTAÇÃO TEÓRICA

Nesta seção, são abordados os temas relacionados à área de pesquisa deste

trabalho, i.e., Metodologias Ágeis, Teste de Software e as metodologias de pesquisa
utilizadas. 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.
 4

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
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.
 5

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
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.
 6

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)

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.
 7

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.

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.
 8

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.

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;
 9

● 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

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.
 10

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).
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
 11

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)

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
 12

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
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).
 13

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,
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
 14

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).

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
 15

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.
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).
 16

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 para diversos
navegadores, e.g., Chrome,Internet Explorer e Firefox. Já o Selenium Webdriver é
uma biblioteca 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.

2.3 Metodologias de Pesquisa

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 foram 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,
 17

essas abordagens de pesquisas podem ser classificadas como: pesquisa

bibliográfica e estudo de caso.
A partir do estudo e levantamento do referencial teórico apresentado neste
trabalho, foi utilizado como metodologia de pesquisa um estudo de caso com
profissionais da área de teste de software cujos objetivos estivessem 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 atendeu aos objetivos desse trabalho, pois
foram analisadas as situações em que se encontravam os profissionais que
poderiam se beneficiar do objeto de estudo aqui apresentado. Partindo desta
análise, o método de teste definido neste trabalho poderá servir como uma
alternativa para suprir as dificuldades encontradas durante a etapa do estudo de
caso.

3 MÉTODO ATUS

Nesta seção, é apresentado o método ATUS, cujo objetivo é automatizar e,

portanto, acelerar o processo de geração de scripts de teste funcional gerados a
partir de requisitos de sistema descritos em User Stories. Conforme é possível
visualizar n Figura 4, o método Atus é composto por uma fase manual (Usuário) e
uma fase automatizada (Atus Tool).

Figura 4 – Fluxograma do método

 18

Fonte: Elaborado pelo autor

O fluxo do método proposto é iniciado a partir da User Story apresentada para

o profissional de qualidade de software (usuário). O profissional deverá importar as
informações de texto da User Story para a parte automatizada do método (Atus
Tool), a fim de iniciar o processo de geração de scripts de teste. Na etapa seguinte,
as informações descritas na User Story são convertidas automaticamente em uma
estrutura abstrata de teste, a qual consiste de um pseudocódigo, i.e., um código em
linguagem natural no formato texto. Esta estrutura descreve os casos de teste, a
partir dos quais são automaticamente gerados scripts para uma tecnologia de teste
funcional específica, e.g., Selenium. Na etapa seguinte, o script de teste é executado
e, em seguida, o usuário pode realizar a análise dos resultados do teste, bem como
elaborar relatórios de execução
A seguir, são descritas de forma detalhada cada uma das etapas que
compõem o método ATUS.
 19

Inserção de Informações da User Story

A primeira etapa do método consiste na inserção dos dados que serão

utilizados para o funcionamento de todo o fluxo do método. Esses dados se referem
às User Stories, i.e., os requisitos do sistema que está sendo desenvolvido com o
uso do método. A User Story deve respeitar os padrões de escrita apresentados
anteriormente, na seção 2, para garantir a correta interpretação dos dados pelo
conversor de User Story.

Conversão de User Story

Nesta etapa os dados descritos na User Story são interpretados e convertidos

em informações de teste. Tais informações correspondem aos cenários de teste que
normalmente são escritos manualmente pelo Analista de Teste, com o intuito de
garantir a cobertura de validação do sistema. Com base nessas informações, é
possível gerar de forma automática os casos de teste necessários para validar a
funcionalidade do sistema.

Gerador de Casos de Teste

Na etapa de geração dos casos de teste, as informações de teste são

convertidas em uma estrutura abstrata (pseudocódigo) independente de tecnologia.
Esta estrutura, por ser representada em um formato abstrato, pode ser utilizado para
gerar scripts para diversas tecnologias de teste. A seção 4 apresenta um exemplo
concreto de estrutura abstrata.

Gerador de Scripts de Teste

A partir da estrutura abstrata, o método gera um script de teste automatizado,

em um formato de código pronto para ser utilizado pela ferramenta de automação
desejada, e.g., Selenium, Visual Studio ou QTP. Este script é o resultado final da
fase automatizada do método (Atus Tool), i.e., a informação que é desenvolvida e
entregue para o testador a partir da User Story inserida.
 20

Considerando que o testador possua as ferramentas de automação

necessárias, a partir da conclusão desta etapa, estará apto para executar de forma
automatizada os scripts gerados pelo método. E, então extrair os resultados para
análise e elaboração de relatórios de teste.

4 ESTUDO DE CASO

Com o intuito de exemplificar o entendimento do método ATUS, foi

desenvolvida a ferramenta de geração automática de scripts de teste Atus Tool. Esta
ferramenta serviu para demonstrar a funcionalidade da aplicação do método em um
cenário de exemplo, de forma a permitir uma visualização para os profissionais que
participaram do estudo de caso.
O estudo de caso foi realizado através da demonstração da funcionalidade da
ferramenta e posterior aplicação de um questionário (Apêndice A) com o objetivo de
coletar as impressões dos profissionais sobre o método proposto.

4.1 Delineamento do Estudo de Caso

O cenário de exemplo utilizado para a aplicação do estudo de caso consistia

na inserção de uma User Story e posterior geração da estrutura abstrata e do script
de teste. Neste caso, a Figura 5 apresenta o conteúdo da User Story utilizada no
exemplo.

Figura 5 – User Story utilizada para Estudo de Caso

Fonte: Elaborado pelo autor

A User Story utilizada para o Estudo de Caso apresenta um requisito de login

de sistema, o qual, seguindo o padrão de escrita de User Story definido por Cohn
 21

(2004), determina que um estudante realizará login no sistema de forma a acessar o

Portal do Estudante. A partir deste requisito, a ferramenta Atus Tool foi utilizada para
gerar a estrutura abstrata (ver Figura 6).

Figura 6 – Pseudocódigo de exemplo gerado pela Atus Tool

Fonte: Elaborado pelo autor

A estrutura abstrata (pseudocódigo) gerada pela ferramenta consiste na

definição das variáveis e métodos que seriam necessários para gerar um script
funcional para alguma linguagem de automação de teste. Essas informações são
apresentadas de maneira genérica, em uma linguagem que seja compreensível ao
usuário.
Partindo deste pseudocódigo considerado, a ferramenta também gerou um
código em linguagem definida, neste caso Java, com os métodos necessários e
pronto para ser compilado e executado pelo framework Selenium integrado com
JUnit. Este código pode ser observado na Figura 7.

Figura 7 – Código de exemplo em Java gerado pela Atus Tool

 22

Fonte: Elaborado pelo autor

A partir deste exemplo de User Story e códigos gerados pela Atus Tool, foi
dado início a aplicação do estudo de caso com profissionais da área de qualidade de
empresas de desenvolvimento de software.

4.2 Aplicação do Questionário de Estudo de Caso

O critério para a seleção de profissionais aptos para analisar o método e

responder ao questionário do estudo de caso considerou os seguintes fatores:
trabalhar com qualidade de software, seja como Analista de Teste, Testador ou cargo
de gerência específica desta área; fazer parte de uma equipe de desenvolvimento
de software que utilize uma metodologia ágil como o Scrum e utilizar User Stories
como artefato de definição de requisitos.
 23

Partindo destas premissas, o profissional teria embasamento técnico para

responder aos questionamentos de maneira crítica e estaria apto para fornecer um
retorno sobre a utilidade do método apresentado.
Respeitadas as premissas mencionadas anteriormente, nove profissionais da
área responderam ao questionário. O Gráfico 1 apresenta os cargos na área de
qualidade que cada um dos participantes ocupa.

Gráfico 1 – Cargos Profissionais dos Participantes

Fonte: Elaborado pelo autor

Sendo assim, responderam ao questionário de estudo de caso dois Analistas

de Teste, seis SDETs (Software Developer Engineer in Test) e um profissional com
cargo de Liderança na Área de Qualidade. Estes profissionais estão divididos entre
duas empresas diferentes, uma empresa de porte médio e uma empresa de porte
grande, conforme apresentado no Gráfico 2.

Gráfico 2 – Porte das Empresas dos Participantes

 24

Fonte: Elaborado pelo autor

Desta forma, contribuíram com este estudo de caso, sete profissionais de uma
empresa de porte grande, com mais de 500 empregados; e dois profissionais de
uma empresa de porte médio, que possui de 100 até 499 empregados. Os valores
definidos no Gráfico 2 para diferenciar o porte das empresas consideram o critério
de definição de estabelecimentos segundo o número de empregados apresentado
pelo SEBRAE (2013).

4.3 Análise e Discussão dos Resultados

Partindo do esclarecimento sobre o perfil dos profissionais participantes a esta

pesquisa, o próximo passo era buscar entender a situação atual em que estes se
encontravam na sua rotina de trabalho. Para isso, o objetivo das perguntas de
número 3 até número 7 (Apêndice A) era compreender o fluxo de trabalho realizado,
considerando diferentes projetos e empresas, as linguagens, ferramentas e
metodologias utilizadas por cada profissional e as possíveis dificuldades
encontradas durante este fluxo.
Através destas perguntas iniciais foi observado que todos os profissionais
participantes do estudo de caso possuíam contato com automação de testes, sendo
que cinco destes ainda realizavam execução manual de teste, concomitantemente à
realização de execução automatizada. Ao passo que os outros quatro participantes
testavam seus projetos de aplicações somente de forma automática.
Considerando que todos os participantes incluem automação de teste no seu
dia-a-dia de trabalho, é importante ter conhecimento de quais linguagens e
 25

ferramentas de automação estes estão utilizando no seu contexto atual. Neste

sentido, sete dos profissionais fazem uso da linguagem C# e do framework
Selenium. Este ponto foi considerado positivo a nível de pesquisa, pois a Atus Tool
entrega ao usuário um código de automação pronto para ser utilizado com o
framework Selenium. E apesar de ser em uma linguagem diferente, i.e., Java, essas
duas linguagens podem ser utilizadas com o framework e possuem similaridades por
utilizarem orientação a objetos. (FURGERI, 2015).
Tratando ainda sobre as ferramentas utilizadas no processo de teste, a
pergunta 6 questionava sobre a usabilidade de alguma ferramenta que facilitasse a
escrita de código de automação. Essa pergunta tinha o intuito de compreender sobre
a necessidade de inclusão de uma nova ferramenta no fluxo de trabalho dos
profissionais, i.e., Atus Tool. Dentre os nove participantes, apenas um afirmou fazer
uso de um facilitador. Neste caso, o uso de padrão de escrita para os cenários de
teste através do método Given/When/Then. Este método auxilia na padronização de
escrita e pode servir como um aliado para garantir maior cobertura de teste.
(SMART, 2014). No entanto, este método não auxilia diretamente na escrita de
código de automação, pois diferentemente da Atus Tool, ele não disponibiliza ao
usuário de maneira automática um código pronto para uso.
Desta forma, tanto para este profissional que já possui uma ferramenta
facilitadora de escrita de código, quanto para todos os outros participantes do
Estudo de Caso, o ATUS poderia servir como uma alternativa para suprir uma
necessidade ainda não coberta no seu cenário atual de trabalho.
Considerando o fluxo de trabalho de cada profissional, as perguntas de
número 9 a 11 buscavam finalmente obter a opinião dos participantes sobre o
método ATUS, e como este poderia auxiliar ou não na sua rotina. Neste contexto, foi
unanime a afirmação de que o método poderia proporcionar melhoria no processo
de teste dos projetos dos participantes. Entretanto, para cada profissional o método
serviria de uma maneira diferente.
Ainda assim, para a maioria dos participantes os ganhos mais significativos
seriam os relacionados ao tempo de criação dos scripts e a padronização de código.
Considerando a constante necessidade de melhoria nos processos de uma
empresa, essas melhorias podem ser atingidas, por exemplo, através da redução no
tempo de desenvolvimento de um sistema, possibilitando o correto cumprimento de
 26

prazos estabelecidos com os clientes. Neste sentido, o método ATUS auxiliaria a

equipe de teste de um projeto de desenvolvimento de software acelerando e
automatizando o processo de geração de scripts de automação. De maneira
semelhante, a padronização do código gerado permite ganho de tempo, pois um
código padronizado é de fácil entendimento, o que facilita a futura manutenção do
mesmo, quando necessário. (MARTIN, 2008).
Além destes dois ganhos que foram citados pela maioria dos participantes,
outros pontos foram levantados referente ao método. Neste contexto, um
participante citou que o uso da estrutura abstrata (pseudocódigo) “ajudaria a ter a
lógica para projetos que não utilizem nem Selenium nem JUnit”. Sendo esta
exatamente a intenção da geração de um código para automação de teste
independente de tecnologia.
De maneira semelhante, um ponto levantado por outro participante, foi
referente a possibilidade de aumentar a cobertura de teste, considerando cenários
“que talvez o usuário pode não captar”. Este ganho com o uso da ferramenta pode
ser observado pois semelhante a execução de qualquer tarefa de maneira repetitiva,
este processo pode estar sujeito a falhas humanas, por falta de atenção. (PEZZÈ;
YOUNG, 2008). Desta forma, a automação da geração de scripts de teste garante
um nível de cobertura consistente.
A automação de processos também foi citada pelos participantes como sendo
um incentivo para que o método fosse implantado em seus projetos. Neste caso, o
questionamento se referia para a situação hipotética de que em seu projeto não
houvesse um processo de automação de teste já definido. E supondo este contexto,
os participantes avaliaram o quesito automação de processos como sendo útil para
o incentivo da implantação.
Além deste ponto, também foi citado por um profissional a padronização de
processos, pois mantendo o uso de uma ferramenta como o Atus Tool por toda a
equipe “teríamos um padrão de código, User Stories, enfim, envolveria um trabalho
de todo o time”. Sendo assim, essa padronização representaria um ponto inicial no
caminho da adoção de um processo de automação de teste.
 27

5 CONSIDERAÇÕES FINAIS

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 automatizada de scripts de teste funcional para
diversas ferramentas de automação de teste a partir de requisitos inseridos em User
Stories. Portanto, o objetivo foi demonstrar que o método ATUS, proposto neste
trabalho, seria capaz de auxiliar Testadores e Analistas de Teste em suas atividades
de forma mais eficiente, 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 fosse alcançado de maneira satisfatória, uma série de
etapas foi definida para a pesquisa deste trabalho. 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 Seção 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.
Logo após, foram apresentados o tipo de pesquisa e os métodos que foram
utilizados durante a elaboração deste trabalho. Neste contexto, a pesquisa foi
classificada como uma pesquisa exploratória, uma vez que neste trabalho foi
apresentado um conceito novo ou pouco explorado na literatura.
 28

Na Seção 3, foi esclarecido o funcionamento do método ATUS, proposto

nesta pesquisa como uma alternativa para melhoria no processo de teste. Nesta
seção, foram detalhadas todas as etapas integrantes do fluxo de funcionamento do
método.
Por fim, na Seção 4, foi apresentado o delineamento e resultado da aplicação
de um estudo de caso com profissionais de empresas de desenvolvimento de
software. Este estudo de caso foi aplicado com o intuito de avaliar a funcionalidade
do método proposto e estabelecer de que forma este seria útil em um cenário real.
Neste contexto, os profissionais das empresas que participaram deste estudo
de caso avaliaram o ATUS como um método que proporcionaria uma melhoria no
processo de teste de seus projetos. Esta melhoria pôde ser observada de maneiras
diferentes por cada profissional participante da pesquisa. Entretanto, em grande
maioria, os benefícios apontados foram a diminuição no tempo de geração de scripts
de teste e a padronização do código gerado.
Durante a aplicação do estudo de caso surgiram, por parte dos participantes,
algumas possibilidades de melhoria para o método proposto. Estas sugestões
tinham o intuito de aprimorar as funcionalidades apresentadas, de maneira a deixar
o método cada vez mais adequado às necessidades de cada projeto. Desta forma,
as sugestões são listadas a seguir como propostas para trabalhos futuros:
a) adicionar à ferramenta o uso de algoritmos de Inteligência Artificial e
Machine Learning. Esta adição tem o intuito de aprimorar a geração
automática dos scripts de teste, permitindo adaptação e robustez do
código gerado para cada projeto que vier a utilizar o método;
b) possibilitar a inclusão de mais dados de entradas, cobrindo por exemplo,
critérios de aceitação de User Stories. Esta inclusão permitiria a geração
de um código mais consistente com as funcionalidades do sistema;
c) incluir uma etapa adicional ao método, permitindo a revisão e possível
ajuste do código que será gerado. Esta etapa possibilitaria ao Analista de
Teste revisar e escolher a melhor estratégia de teste para cada User Story,
modificando métodos e variáveis, conforme a necessidade.
 29

ATUS: A FUNCTIONAL TEST CASE AUTOMATION METHOD FROM USER STORIES

Abstract: Planning and execution of tests aims to guarantee the quality of the
system to be developed. This quality refers to the correct behavior of the software
when compared to its requirements specification. An alternative currently used to
define the requirements and functionalities of the system is the use of User Stories.
User Stories are artifacts used to document a customer’s need in a clear and
objective manner, as well as contributing to the best use of time, due to its simplicity
of elaboration. In this context, the present work aims to demonstrate the
improvement in the process needed to generate functional test scripts from User
Stories when compared to the traditional test case generation approach. In order to
achieve this objective, a case study was conducted with professionals from two
software development companies.

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

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.
 30

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.

FURGERI, Sérgio. Programação Orientada a Objetos. Conceitos e Técnicas. São

José dos Campos: Érica, 2015.

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
<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.

MARTIN, Robert C. Clean Code: A Handbook of Agile Software Craftsmanship. New

Jersey: Prentice Hall, 2008.

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.
 31

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.

SEBRAE, Serviço Brasileiro de Apoio às Micro e Pequenas Empresas. Anuário do

trabalho na micro e pequena empresa. 6. ed. Brasília: DIEESE, 2013.

SMART, John F. BDD in Action: Behavior-Driven Development for the Whole

Software Lifecycle. New York: Manning Publications, 2014.

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.
 32

APÊNDICE A – QUESTIONÁRIO DE ESTUDO DE CASO

33
34