(1) O documento discute o uso de TDD (Desenvolvimento Orientado por Testes) e BDD (Desenvolvimento Orientado por Comportamento) no ensino de Engenharia de Software. (2) Os autores realizaram um experimento com alunos divididos em grupos, onde um grupo não usou práticas ágeis, outro usou TDD e outro usou BDD. (3) Os resultados mostraram que o grupo que usou BDD teve menor absenteísmo, maior satisfação dos alunos e melhores notas, além de entregar o produto

1. See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/335957086
Agile Teaching Practices: Using TDD and BDD in Software Development
Teaching
Conference Paper · September 2019
DOI: 10.1145/3350768.3351799
CITATIONS
2
READS
737
4 authors:
Some of the authors of this publication are also working on these related projects:
Segurança em redes de computadores uma visão sobre o processo de Pentest View project
Tecnologia e educação View project
Fabio Rocha
Institute of Technology and Research
55 PUBLICATIONS 96 CITATIONS
SEE PROFILE
Layse Santos Souza
Universidade Federal de Sergipe
16 PUBLICATIONS 9 CITATIONS
SEE PROFILE
Thiciane Silva
Pontifícia Universidade Católica do Rio Grande do Sul
3 PUBLICATIONS 2 CITATIONS
SEE PROFILE
Guillermo Horacio Rodríguez
National Scientific and Technical Research Council
50 PUBLICATIONS 337 CITATIONS
SEE PROFILE
All content following this page was uploaded by Guillermo Horacio Rodríguez on 05 February 2020.
The user has requested enhancement of the downloaded file.

2. Agile Teaching Practices: Using TDD and BDD in Software
Development Teaching
Fabio G. Rocha
Universidade Tiradentes; ITP
Aracaju, SE
gomesrocha@gmail.com
Layse Santos Souza
Universidade Federal de Sergipe; GPITIC
Aracaju, SE
santoslay3@gmail.com
Thiciane Suely C. Silva
Universidade Tiradentes; GPITIC
Aracaju, SE
thicianecouto@gmail.com
Guillermo Rodríguez
ISISTAN (UNICEN-CONICET) Research Institute
Tandil, Argentina
guillermo.rodriguez@isistan.unicen.edu.ar
ABSTRACT
In this paper, we aimed to analyze the application and contribu-
tion of the use of Test-Driven Development (TDD) and Behavior-
Oriented Development (BDD) in Software Engineering teaching. As
empirical research, we presented an experiment conducted in the
Software Engineering Laboratory (LES) course of a Private Univer-
sity (Tiradentes University) in the Bachelor of Computer Science
and Information Systems courses. This experiment demonstrated
the fundamentals in verifying the learning difficulties of students.
Collected data were subjected not only to quantitative analysis but
also to appropriate statistical analysis. The results showed a reduc-
tion in student absences, higher student satisfaction rate and higher
grades in the courses. Furthermore, our approach allowed students
to deliver a product in a short period, representing a possibility of
adoption of BDD due to their successful learning experience.
CCS CONCEPTS
• Software and its engineering; • Software creation and man-
agement; • Software development techniques; • Object ori-
ented development;
KEYWORDS
BDD, TDD, Software Engineering Education, Learning Experience,
Agile Software Developlment
ACM Reference Format:
Fabio G. Rocha, Layse Santos Souza, Thiciane Suely C. Silva, and Guillermo
Rodríguez. 2019. Agile Teaching Practices: Using TDD and BDD in Software
Development Teaching. In XXXIII Brazilian Symposium on Software Engi-
neering (SBES 2019), September 23–27, 2019, Salvador, Brazil. ACM, Bahia,
BA, Brazil, 10 pages. https://doi.org/10.1145/3350768.3351799
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from permissions@acm.org.
SBES 2019, September 23–27, 2019, Salvador, Brazil
© 2019 Association for Computing Machinery.
ACM ISBN 978-1-4503-7651-8/19/09...$15.00
https://doi.org/10.1145/3350768.3351799
1 INTRODUÇÃO
O ensino de Engenharia de Software tem sido um tema amplamente
debatido, Dawson [1] e Regev et al. [2] afirmam que os projetos
utilizados no ensino se afastam da realidade, formando assim, alunos
com pouco preparo para o mercado de trabalho.
Conforme Lethbridge et al. [3] as empresas tem, por vezes, que
complementar os conhecimentos dos alunos com treinamentos
para prover as habilidades necessárias para o desenvolvimento de
software. De acordo com Yamaguti et al. [4] na atualidade há um
grande desafio no ensino de Engenharia de Software no Brasil, em
razão de uma demanda por profissionais que sejam habilitados e
capacitados ao desenvolvimento de software de forma eficiente.
Ainda conforme Yamaguti et al. [4] abordagens inovadoras de-
vem ser adotadas para permitir a integração de conteúdos por meio
da interdisciplinaridade. Assim, este estudo teve como objetivo
analisar a aplicação e a contribuição do uso do Desenvolvimento
Orientado por Testes (TDD) e Desenvolvimento Orientado por
Comportamento (BDD) no processo de ensino de Engenharia de
Software nos cursos de Bacharelado em Sistemas de Informação e
Ciências da Computação na disciplina de Laboratório de Engenharia
de Software (LES) no quarto período (segundo ano) para uma tarefa
de desenvolvimento de software, a fim de atender às mudanças de
requisitos durante o desenvolvimento do projeto.
Este experimento evidenciou os princípios necessários para a
verificação das dificuldades dos alunos na aprendizagem. Assim, as
abordagens realizadas nas análises foram quantitativa e qualitativa
empregando e relacionando os dados obtidos. Com esse experi-
mento foi perceptível que houve uma redução no número de faltas
dos alunos, maior taxa de satisfação dos alunos e maiores notas no
curso, além da entrega de um produto em um curto espaço de tempo
comprovado através do sucesso da aprendizagem destes alunos com
a adoção do BDD.
Apesar do trabalho ter sido feito de modo colaborativo, as avali-
ações foram feitas tanto individualmente quanto em grupo, per-
mitindo que o aluno aprendesse todos os aspectos do processo de
desenvolvimento do currículo. As questões de pesquisa adotadas
foram:
(1) O que é preciso ensinar aos alunos para lidar de forma rápida
e eficaz com mudanças de requisitos durante o desenvolvi-
mento do projeto?

3. SBES 2019, September 23–27, 2019, Salvador, Brazil Rocha et al.
(2) Como avaliar o desempenho individual ao ensinar um curso
respaldado em projeto baseado no TDD e no BDD?
Para realizar o experimento, 18 alunos dos cursos de Bachare-
lado em Sistemas de Informação e Ciências da Computação foram
divididos em 3 grupos de 6 alunos. Cada grupo tinha como tarefa o
desenvolvimento de um produto, o qual deveria ser desenvolvido
em um período de oito semanas. A fim de averiguar nosso objetivo,
um grupo não utilizou nenhuma das práticas ágeis, o segundo grupo
utilizou TDD e o terceiro grupo utilizou BDD.
Os resultados apresentam indícios de que o uso do BDD melhora
a capacidade de desenvolvimento de software do discente, bem
como resulta em um melhor aprendizado no processo de software,
e depois de praticá-los de forma efetiva em curto tempo, seguiu-se
em entregas com um menor número de falhas.
O restante do artigo está organizado da seguinte forma: a Seção 2
apresenta a fundamentação teórica sobre as práticas ágeis adotadas
no experimento. A Seção 3 expõe os trabalhos relacionados. A Seção
4 exibe a proposta da disciplina. A Seção 5 apresenta a metodologia
aplicada para a condução do estudo, o planejamento e os resultados
obtidos. A Seção 6 expressa o relato da experiência. A Seção 7
apresenta a discussão sobre os resultados. A Seção 8 manifesta as
lições aprendidas e, por fim, a Seção 9 expõe as considerações finais.
2 PRÁTICAS ÁGEIS
As práticas ágeis, conforme Cohn [5], são essenciais para a entrega
de produtos de forma sistemática e incremental. Assim, equipes
ágeis, vem utilizando, com sucesso, práticas consolidadas como o
Test Driven Development (TDD), refatoração, posse coletiva, inte-
gração continua, entrega continua, programação em pares e também
o Behavior Driven Development (BDD) [6].
2.1 TDD
O Desenvolvimento Orientado por Testes (TDD) é uma técnica de
programação que visa entregar um produto de qualidade em um
curto período de tempo. Dessa forma, apresenta como metas agir de
forma preventiva, prevenir possíveis erros e facilitar o entendimento
dos requisitos do sistema [7]. Idealizado por Kent Beck como parte
da Metodologia XP, inicialmente, era descrito como uma prática do
XP necessária para análises e testes que permitiam a refatoração e
a integração contínua.
Conforme Bissi et al. [8] o TDD vem ganhando popularidade
para além do XP, além disso, os autores apontam para um aumento
significativo da qualidade ao se utilizar esta prática no desenvolvi-
mento de software. O TDD é a prática ágil mais utilizada no setor
de desenvolvimento de software, em partes pela simplicidade do
seu ciclo de vida [8], Figura 1, que também traz praticidade para
o desenvolvimento, iniciando pela criação de um teste de unidade
falho, visando garantir que o teste funciona e captura o erro, assim,
o foco é que o desenvolvedor conheça o erro/problema para que
possa implementar uma solução funcional que faça a correção, e
posteriormente, esta solução evolui por meio da refatoração.
Além disso, de acordo com Jazen e Saiedian [9], o TDD é uma
estratégia que requer a escrita de testes automatizados antes do
desenvolvimento do código funcional e suas iterações com a in-
tenção de verificar se estes estão corretos, completos e qual o seu
nível de qualidade. Apesar de surgir como parte do método XP, o
Figure 1: Ciclo do TDD
TDD tem recebido atenção como uma prática independente, sendo
adotado por outros métodos e possuindo diversas ferramentas para
o suporte ao TDD em várias linguagens de programação. Também
foram escritos inúmeros livros que definem seu conceito. Além
disso, pesquisadores e educadores começaram a analisar os efeitos
do TDD na redução de defeitos e melhorias na qualidade dos ambi-
entes acadêmicos e profissionais, e na integração desta estratégia
nos cursos de Bacharelado em Sistemas de Informação, Ciências da
Computação e Engenharia de Software. De acordo com D. North
[10] a utilização do TDD gerou alguns questionamentos, como:
Quais seriam os testes iniciais? O que deve ser testado? Como en-
tender a falha de um teste? Tais questionamentos acabam levando
ao surgimento de dúvidas e, consequentemente, impactando no
desenvolvimento. Para solucionar esse problema North apresenta
o Desenvolvimento Orientado por Comportamento (BDD), que
tem como base o TDD e o Desenvolvimento Orientado a Testes de
Aceitação (ATDD).
2.2 BDD
O BDD foi idealizado por D. North [10] como uma resposta aos
problemas no TDD. Com o BDD é possível extrair as especificações
fornecidas pelo cliente durante o levantamento dos requisitos. Em
vista disso, é possível afirmar que o TDD progrediu para o BDD com
os seguintes questionamentos: Por onde começar? O que testar? O
que não testar? Quando testar? Como nomear os testes? Por que
um teste falha?
O BDD difere de outras abordagens ao descrever um compor-
tamento do sistema na perspectiva de seus stakeholders, em todos
os níveis de granularidade [10], por assegurar que o foco em tal
descrição do comportamento do sistema proporciona uma melhor
comunicação.
A Figura 2 descreve como deve ser o ciclo do BDD. Primeira-
mente, é indispensável escrever um teste para descrever o com-
portamento esperado, logo o teste deve falhar porque o código
ainda não existe. Depois é necessário escrever o código para criar
o comportamento esperado descrito pelo teste. E, sucessivamente,
é fundamental reescrever (refatorar) o código para que este tenha

4. Teaching Agile with TDD and BDD SBES 2019, September 23–27, 2019, Salvador, Brazil
Figure 2: Ciclo do BDD
maior qualidade uma vez que o teste vai garantir que o comporta-
mento continue de acordo com o esperado.
Smart [11] destaca que o BDD possui benefícios como redução
do desperdício, comunicação, redução de custo, mudança mais fá-
cil e segura, e releases mais rápidas. Moraes [12] desaponta algu-
mas vantagens do BDD, por exemplo, comunicação entre equipes,
visão do todo, compartilhamento de conhecimento e documentação
dinâmica. Portanto, o BDD é uma técnica de especificação que vin-
cula os requisitos funcionais ao código fonte através da conexão
da representação textual dos requisitos aos testes automatizados.
Deste modo, pode-se confirmar que o BDD estende o TDD, Figura
3, visto que o TDD tem como objetivo obter a solução correta que
corresponda exatamente ao problema de negócio nos níveis de
unidade e integração, enquanto o BDD cuida do nível de aceitação,
onde os requisitos residem.
Figure 3: Integração do BDD e TDD
3 TRABALHOS RELACIONADOS
Segundo Koskela [13] o TDD é uma importante prática de teste que
visa aumentar a produtividade no desenvolvimento de produtos,
pois envolve parcialmente a escrita de testes e é uma técnica para
melhorar a qualidade interna do software, isto é, é uma forma de
encorajar o bom design e um processo disciplinado na qual ajuda a
evitar erros no momento da programação. O TDD oferece atenção
a qualidade do código e design, além de ter um significativo efeito
sobre quanto do tempo de desenvolvimento é gasto para corrigir de-
feitos ao invés de, por exemplo, implementar novas funcionalidades
ou melhorar o código base do projeto existente.
George e Williams [14] realizaram um estudo de caso com progra-
madores profissionais no qual afirma que o uso do TDD com ciclo
de vida iterativo e incremental, assistida com detecção de falhas,
o tempo de programação aumentou em 16% quando comparada
com os desenvolvimentos tradicionais, por exemplo, cascata. Os
estudos de caso apresentados nos trabalhos de Nagappan et al. [15]
e Canfora et al. [16] também apresentaram conclusões semelhantes
com os desenvolvedores de empresas como Soluziona Software
Factory, IBM e Microsoft.
O trabalho de Edwards [17] aponta a necessidade de ensinar
habilidades de teste de software para alunos de computação, que,
conforme os autores, são, em geral, despreparados para esta tarefa.
Assim, os autores propuseram o uso do TDD como forma de exigir
que os alunos testem seus códigos, e apontam que os estudantes
produziram códigos com 45% menos defeitos por mil linhas de
códigos ao utilizarem o TDD. O trabalho de Eierman e Iversen
[18] compara o TDD com a programação em par, analisando, pela
percepção dos alunos, qual destas mais contribuiu para o apren-
dizado de programação, logo os resultados dos autores apontam
que ambas as técnicas são consideradas úteis, mas o TDD é visto
como uma prática importante.
Santos et al. [19] apresentaram TesterDS, um jogo voltado ao
ensino de Estruturas de Dados que utiliza técnicas de TDD e Teste
Estrutural de Software. O jogo tem foco em estudantes de disciplinas
de programação mais avançadas, e tem como objetivo facilitar e
estimular o aprendizado de Estruturas de Dados.
Seroa et al. [20] propuseram um processo de desenvolvimento
de software para implementação de demandas de uma fábrica de
software em ambiente acadêmico. A metodologia proposta tem
como base um modelo iterativo-incremental e inclui métodos tais
como Scrum, XP, RUP, BDD, e entre outros. O processo foi aplicado
como metodologia prática de ensino em um curso de nível técnico
de Engenheira de Software.
Como diferencial, este trabalho apresenta um relato de experiên-
cia em uma disciplina dos cursos de Bacharelado em Sistemas de
Informação e Ciências da Computação, no desenvolvimento de um
produto, comparando grupos de alunos que empregaram TDD e
BDD com um grupo que não utilizou práticas ágeis.
4 PROPOSTA DA DISCIPLINA
A disciplina Laboratórios de Engenharia de Software (LES) foi uma
proposta elaborada durante a modificação dos currículos dos cur-
sos de Bacharelado em computação (Ciências da Computação e
Sistemas de Informação) da Universidade Tiradentes com foco na
integração de conteúdos das disciplinas de modelagem, Engenharia
de Software, e programação de forma prática e aplicada. Esta disci-
plina está posicionada no quarto período em ambos os cursos e tem
com objetivo seguir a base nos estágios de Piaget [21], considerando
o estágio operacional formal ocorrido a partir dos 11 ou 12 anos
até a vida adulta do indivíduo. Aplicando-se os pressupostos desse

5. SBES 2019, September 23–27, 2019, Salvador, Brazil Rocha et al.
estágio de desenvolvimento humano, na medida em que o aluno
decompõe o problema em etapas, partindo dos problemas gerais,
em uma visão concreta, aos complexos, desenvolve uma visão mais
abstrata, e estabelece o pensamento dedutivo-indutivo necessário
ao desenvolvimento de software ágil.
Ao posicionar os alunos como participantes ativos do processo
de solução de problemas, diante do concreto, das suas experiências
mais próximas, em um processo de interação pessoa-meio, conforme
descrito por Bigge [22], sobre a realidade percebida, o professor e
os colegas ficam, na dinâmica proposta, também envolvidos nessa
interação com vistas ao conhecimento, esse movimento “[...] implica
uma relação sujeito-sujeito-objeto” [22].
Esta atividade ocorreu em sala de aula, esse espaço “[...] pode
assumir para si a perspectiva de interação com o conhecimento e
com os atores do ato educativo, assim, assume também a função de
ser o principal lugar em que se desenvolva a inteligência coletiva”
[23]. O ato de desenvolver software resulta na criação de um objeto
com significância aos alunos, que vê a concretização da aplicação de
seus conhecimentos, além de integrar os conhecimentos adquiridos
ao conhecimento anterior. Para tal criação, os alunos são estimula-
dos a perceber o problema de forma individual, mas sendo levado a
considerar a participação colaborativa dos demais na elaboração
da solução. Desta forma, os alunos passam a ter uma participação
ativa e interativa, a qual é mais positiva que a recepção passiva
sendo incentivada por meio da prontidão e da aprendizagem [22].
Na prática investigada, a participação do professor é especial-
mente relevante nos momentos da passagem da abordagem teórica
para a explicação detalhada sobre a forma da busca de solução ao
problema proposto. Além disso, é fundamental que o professor es-
clareça sobre a possibilidade da solução proposta ser revista pelos
alunos, constituindo um ciclo contínuo de melhoria da solução ini-
cial. O processo de ensino e aprendizagem torna-se, assim, contínuo
na própria reconstrução da experiência [24].
5 METODOLOGIA
Como investigação empírica, a pesquisa constitui um relato de
experiência, tornando-se exploratória, sobre a verificação das di-
ficuldades de aprendizagem dos alunos, e descritiva, quanto à ex-
perimentação do uso do TDD e BDD como metodologia para o
ensino.
As análises sobre os resultados foram feitas sob abordagem
qualitativa e quantitativa, associando-se os dados obtidos na ativi-
dade pedagógica e os referenciais adotados no estudo. Assim, esta
pesquisa foi estruturada em forma de relato de experiência visando
expressar a aplicação de práticas ágeis, TDD e BDD, como uma
alternativa para o ensino de práticas de Engenharia de Software.
O relato apresentado abrange edições do componente curricular
Laboratório de Engenharia de Software (LES), o qual possui 80
horas aula nos cursos de Bacharelado em Sistemas de Informação
e Ciências da Computação de uma Universidade Tiradentes, no
período de janeiro a abril de 2019.
A turma, composta de 18 alunos, foi dividida em 3 grupos de 6
alunos, um grupo não utilizou práticas ágeis, outro grupo utilizou
TDD e o outro grupo utilizou BDD. Cada grupo tinha como tarefa o
desenvolvimento de um produto, este deveria ser desenvolvido em
um período de oito semanas. A cada semana os alunos deveriam
apresentar o progresso de desenvolvimento do produto.
Desta forma, para a avaliação e validação dos resultados indi-
viduais dos alunos por grupo através da distribuição das notas de
produto por aluno foram definidas as seguintes hipóteses:
H0: Existe diferença entre a distribuição das notas relacionadas
aos alunos, por grupo.
H1: Não há diferença entre as notas relacionadas aos alunos, por
grupo.
A coleta de dados foi realizada por meio do Github, utilizado
no projeto pelos grupos, mediante as tarefas desenvolvidas pelos
alunos e informações inseridas no Trello através das entregas se-
manais e avaliações dos alunos. Para aplicar o TDD foi utilizado o
JUnit e para o BDD foi utilizado o JBehave durante o desenvolvi-
mento do projeto. Além dessas ferramentas, também foi utilizado o
Slack para a comunicação entre os membros dos grupos, no entanto
alguns destes grupos utilizaram o Slack para realização das reuniões
diárias.
5.1 Trello
O Trello [25] é uma ferramenta web gratuita de gerenciamento
de projetos em quadros que pode ser ajustada de acordo com as
necessidades do usuário, isto é, moldada de acordo com os objetivos.
Pode ser usado tanto por um só indivíduo quanto em trabalhos
em equipe. Sua interface permite a rápida identificação do que está
sendo feito, quem está fazendo e em qual estado se encontra cada
tarefa.
Apesar de seu foco ser o gerenciamento de projetos, o Trello
também pode ser utilizado para organizar tarefas do trabalho, planos
de estudos, e entre outros. Neste estudo, o Trello foi utilizado para
acompanhar as tarefas desenvolvidas por cada grupo cruzando com
as informações de commit do Github.
5.2 Github
O Github [26] é uma ferramenta web de gerenciamento de projetos
e versões de códigos com controle de versão. O Git [27], sistema
por traz do Github, é open source e tem como função o controle de
versão. Com ele é possível criar todo o histórico das alterações no
código do projeto, e facilmente voltar para qualquer ponto caso
pretenda saber como o código estava em determinada data. Ou seja,
o Git ajuda a controlar o fluxo das novas funcionalidades.
Permite que programadores contribuam em projetos privados
e/ou open source. Oferece suporte ao recurso de organização que
é amplamente utilizado por aqueles que querem uma divulgação
maior dos trabalhos e promover uma fácil comunicação através de
recursos que relatam problemas ou mesclam repositórios remotos.
5.3 JUnit
O JUnit [28] é um framework open source que facilita o desenvolvi-
mento e a execução de testes unitários em código Java, orientado a
objeto, exibindo os possíveis erros que estão ocorrendo nos méto-
dos. Este framework é amplamente utilizado na metodologia TDD,
pois permite verificar se cada unidade de código funciona da forma
esperada. Como também, facilita a criação, a execução automática
de testes e a apresentação dos resultados.

6. Teaching Agile with TDD and BDD SBES 2019, September 23–27, 2019, Salvador, Brazil
5.4 JBehave
O JBehave [29] é um framework Java de Desenvolvimento Orientado
por Comportamento, isto é, BDD. Sua ideia principal é escrever um
arquivo-texto que será executado linha a linha, relacionado a um
método que é a materialização em código do objetivo de negócio
da respectiva linha textual.
Os usuários podem especificar e executar as histórias que são
compostas por um ou mais cenários, e um cenário é composto de
uma ou mais etapas (Given, When e Then - Dado, Quando e Então).
É utilizado para facilitar a comunicação entre os stakeholders e
verificar o comportamento através da integração contínua. Além
disso, os resultados dos testes podem ser vistos em formatos HTML,
TXT e XML, por exemplo, e permite a integração com as principais
IDEs, como: Eclipse e NetBeans.
5.5 Slack
O Slack [30] é uma ferramenta criada para ajudar empresas na
colaboração das equipes melhorando sua comunicação interna, ou
seja, com o Slack é possível reduzir a necessidade da troca de e-mails
e da participação em diversas reuniões para tomada de decisão.
Transparente com os dados no compartilhamento de projetos e
processos decisórios. Nele é possível criar times para gerenciar a
comunicação, criar canais com os mesmos assuntos de interesse,
trocar mensagens diretamente com uma pessoa ou um grupo, citar
pessoas ou notificar um canal quando necessário e compartilhar
arquivos.
6 RELATO DE EXPERIÊNCIA
Esta seção apresenta os relatos das experiências em ensino realizadas
em uma edição do componente curricular Laboratório de Engenharia
de Software. O público alvo foi composto por 18 alunos entre 18
e 24 anos de idade, tendo entre os 18 alunos um total de 4 alunas,
representando aproximadamente 22.3%.
Estes alunos possuíam conceitos básicos, pois o pré-requisito
para LES é a disciplina de Engenharia de Software (ES) e conclusão
das disciplinas de Introdução à Programação e Programação Orien-
tada a Objetos (POO). Vale ressaltar que esses alunos não possuíam
experiência prática ou avançada em desenvolvimento ágil de soft-
ware. Além disso, houve o acompanhamento, na forma de coaching
por parte do professor, durante as mudanças de requisito realizados
após a terceira iteração. Logo, observou-se que compreender o prob-
lema e conseguir separar os requisitos estáveis dos não estáveis foi
essencial pela prática de BDD que traz a história de usuários e o
cenário como parte da prática, permitindo que os alunos obtivessem
um melhor conhecimento das partes do sistema.
O experimento foi realizado da seguinte forma, Figura 4, na
primeira semana foi realizada uma palestra sobre as técnicas ágeis e
como estas impactam no desenvolvimento de software, discutindo
as ferramentas - Trello, Github, Slack, JUnit e JBehave. Na segunda
semana foi desenvolvido uma prática utilizando as técnicas TDD e
BDD, e as ferramentas que foram discutidas na palestra. Na terceira
semana teve início o desenvolvimento da solução, sendo realizada
uma apresentação, e em seguida, iniciou-se o desenvolvimento que
foi seguido até a décima semana, oito sendo para a parte prática e
duas para parte conceitual.
Figure 4: Ciclo de trabalho dos alunos
Os grupos criaram um projeto no Trello, Figura 5, e adicionaram
o professor para acompanhar a execução das tarefas. Cada grupo
se auto organizou de forma a dispor no time de um Scrum Master
e um Product Owner, o professor atuou como Cliente, ou seja, o
responsável por passar ao Product Owner e ao grupo de alunos
o que é o produto, quais são as funcionalidades desejadas, e por
conseguinte, quem avalia as entregas realizadas pelos grupos. O
professor, além de funcionar como o Cliente, auxilia como Coach
durante as iterações [31] permitindo que os alunos tomassem as
decisões, todavia, auxiliando-os durante o processo.
Figure 5: Quadro Trello utilizado pelos grupos
A atuação do professor como Coach foi apresentada no tra-
balho de Rodriguez et al. [31] e empregada de forma que os alunos
tivessem alguém para dirimir dúvidas, porém, sem resolver os
problemas. Dessa forma, o professor atuaria como um guia da

7. SBES 2019, September 23–27, 2019, Salvador, Brazil Rocha et al.
prática proposta. Com isso, foi observado que os alunos, após a
primeira iteração, sentiram-se confortáveis para procurar o pro-
fessor em relação as suas dúvidas. Por fim, na entrega final, os
alunos apresentam o produto no repositório Github a um grupo de
professores, para uma avaliação final.
Durante as aulas, os alunos deveriam, em todos os grupos, en-
tregar o que foi planejado na aula anterior, debater sobre o que foi
aprendido e os erros cometidos, e por fim realizar o planejamento
para a entrega da próxima aula, seguindo o ciclo de reuniões Scrum,
com exceção da reunião diária. O domínio do problema escolhido
foi Software para gestão de clínica médica. Para a avaliação
foram realizadas análises individuais e em grupos, empregando os
dados a seguir:
• Commits realizados individualmente;
• Tarefas desenvolvidas individualmente;
• Quantidade de retrabalho individual;
• Entrega produzida pelo grupo;
• Apresentação do produto;
• Resolução dos problemas pelo grupo;
• Avaliação teórica sobre a prática desenvolvida.
Desta forma, cada grupo teve a liberdade de escolher a linguagem
de programação, o Sistema Gerenciador de Banco de Dados (desde
que fosse open source) e como seria a divisão de tarefas entre os
membros do grupo. Foi apenas definido que semanalmente deveria
ser apresentado a entrega e a definição do que seria feito na próxima
iteração para o professor. Após isso, o professor deveria avaliar se
as tarefas atenderam as necessidades, senão, deveria ser inserido
como retrabalho.
Por conseguinte, os grupos se organizaram escolhendo a lin-
guagem de programação e as técnicas ágeis a serem adotadas, con-
forme Tabela 1.
Table 1: Distribuição dos grupos de trabalho
Grupo 1 Grupo 2 Grupo 3
Técnica ágil Não utilizou TDD BDD
Número de alunos 6 6 6
Sexo masculino 6 4 4
Sexo feminino 0 2 2
Linguagem Java Java Java
IDE Netbeans Netbeans Netbeans
Framework Não utilizou JUnit5 JBehave
Desta forma, o primeiro ciclo foi composto de uma reunião de
planejamento, na qual os alunos compreenderam o problema, discu-
tiram e definiram as tarefas. Essa reunião foi de 1h e 30 min seguido
pela etapa de desenvolvimento. As demais iterações começaram
por uma reunião para discutir a entrega e apresentar ao Cliente.
Depois foi realizada uma revisão da iteração, para ver o que eles
aprenderam e como resolveram os problemas, em seguida plane-
javam a próxima iteração e iniciavam o desenvolvimento. Esta série
de ações foram realizadas em todas as demais iterações, na iter-
ação final os alunos revisaram o que foi produzido, se reuniram
para verificar a entrega final e apresentaram ao Cliente (professor),
fazendo um relato das lições aprendidas. Durante todo o ciclo teve
o acompanhamento do Coach (professor), Figura 6.
Figure 6: Ciclo de iterações
Os grupos, na primeira iteração (semana de trabalho), não ob-
tiveram grandes resultados, visto que, pela falta de experiência
prática, entregaram poucas tarefas e com muitos erros. Os grupos
que optaram por utilizar as técnicas ágeis, durante o primeiro ciclo,
entregaram menos do que o grupo que não utilizou técnicas ágeis,
segundo os alunos o motivo foi à falta de prática com a ferramenta
escolhida, assim, apenas o Grupo 1 obteve bons resultados iniciais,
a Figura 7 apresenta estes resultados.
Figure 7: Entregas por grupo

8. Teaching Agile with TDD and BDD SBES 2019, September 23–27, 2019, Salvador, Brazil
Durante a segunda iteração, o Grupo 2 realizou um maior número
de entregas, seguido pelo Grupo 1 e por fim Grupo 3. Neste ponto,
o Grupo 2 relatou que tinha compreendido o framework e a IDE que
auxiliou no processo de uso. O Grupo 3 afirmou que as entregas de
tarefas foram menores, porém entregaram documentações como
as histórias de usuários e os cenários. No ciclo seguinte, o Grupo
3 realizou um maior número de entregas, seguido pelo Grupo 2.
O Grupo 1 teve maior número de retrabalho relativo às tarefas
entregue por falta de integração com as novas tarefas.
A partir da terceira iteração houve mudanças para todos os gru-
pos pela pouca experiência prática dos alunos. Como o projeto era
único e iniciado do zero (software para gestão de clínica médica,
com controle de agenda dos médicos; cadastro de pacientes, médicos
e atendimento; controle dos atendimentos), todos teriam o mesmo
ponto de partida e as mesmas mudanças solicitadas pelo cliente. O
uso de práticas ágeis e o uso do JUnit pelo grupo que adotou o TDD,
e o uso do JBehave + JUnit pelo grupo que adotou o BDD, reduziu
consideravelmente o retrabalho.
Assim, o Grupo 3 passou a realizar um maior número de entregas,
com um menor número de retrabalho, seguido pelo Grupo 2. Con-
forme os alunos do Grupo 3, o trabalho inicial relacionado a escrever
as histórias de usuários e cenários, obrigou que eles obtivessem um
entendimento prévio sobre as funcionalidades, o que demorou a ser
compreendido no início de como fazer, porém reduzindo o trabalho
nas fases seguintes. O Product Owner do grupo, ficou responsável
por escrever as histórias dos usuários, e relatou ainda ser mais fácil
se comunicar com o time e com o Cliente (professor) por meio das
histórias. O Grupo 2 relatou que a tarefa de criar os testes, ape-
sar de parecer lento, fez com que o grupo conseguisse reduzir o
retrabalho pois tiveram que pensar nas entradas e saídas de cada
funcionalidade, antes de sua construção.
O Grupo 3 relatou que achou inicialmente que a utilização do
BDD atrapalharia, mesmo tendo selecionado, e que durante a primeira
iteração eles acharam que poderia ter perdido muito tempo, mas no-
taram que durante as iterações o BDD fez com que eles reduzissem
retrabalhos, além disso, os cenários auxiliaram na validação das
funcionalidades, antes mesmo de rodar o teste, pois eles tinham um
caminho para validação, que facilitava o trabalho de desenvolvi-
mento.
Na penúltima iteração, o Grupo 3 tinha concluído as tarefas e
ficou apenas trabalhando em melhorias, o Grupo 2 fez um grupo
de entregas, e na última iteração apenas o Grupo 1 ainda tinha
entregas a serem feitas. Após a execução dos ciclos foram analisados
os resultados através do Trello e Github.
Vale ressaltar que as falhas foram acompanhadas durante as
entregas, e medidas em nível de funcionalidade entregue, sendo
que cada falha foi comunicada de duas formas: a) Como cliente, o
professor dizia o que ele esperava; b) Como consultor, o professor
explicava caminhos para solucionar os problemas. Para mensurar as
falhas pretendemos utilizar uma ferramenta de gestão de defeitos,
por exemplo, Mantis. Na seção a seguir foram representados os
resultados encontrados durante a execução deste trabalho.
7 RESULTADOS E DISCUSSÃO
As práticas adotadas na aula tiveram como objetivo aproximar a
vida acadêmica da vida profissional do estudante, tal ação é essencial
para formação conforme apontado no Relatório Delors [32], assim,
observa-se que as práticas pedagógicas realizam a convergência
entre a teoria e a prática. Neste estudo, o modelo adotado traz o
princípio da autonomia, onde os grupos tiveram que decidir quais
práticas iriam adotar e como elas seriam utilizadas.
Como apontado por Gadelha e Castro [33], ao final da execução
deste trabalho, observou-se que na apresentação teórica do con-
teúdo, os alunos apresentaram pouco interesse, tanto que o Grupo
1 foi o primeiro a definir que não utilizaria as práticas ágeis durante
o desenvolvimento, os outros dois grupos definiram as práticas
somente durante a aula prática. Também foi tarefa dos alunos a
busca da melhor solução para o problema apresentado.
Ao final da execução das tarefas realizadas pelos grupos, pode-se
verificar que a utilização do BDD mostrou-se eficiente, do ponto de
vista de entrega com menos falhas, o Grupo 3 que adotou o BDD
obteve um maior rendimento, seguido do Grupo 2 que adotou o
TDD e por fim o Grupo 1 que não adotou as práticas ágeis.
Dessa forma, nota-se que as entregas de funcionalidades tam-
bém são diferentes por grupo, neste caso, não foi contabilizado o
retrabalho. O Grupo 3 iniciou mais lentamente nas entregas, porém
a partir da terceira iteração os alunos mantiveram uma quantidade
alta de entregas, melhorando sua performance. O Grupo 2 iniciou
com melhor tempo nas entregas, porém durante as iterações não
ocorreu grande evolução. O Grupo 1 obteve o melhor resultado
no tempo das entregas iniciais, mas nas iterações seguintes não
manteve a estabilidade devido a grande quantidade de erros, re-
duzindo assim, a performance geral do grupo, como pode ser visto
anteriormente na Figura 7.
Quando comparado os resultados individuais dos alunos por
Grupo de 0 a 4, é possível notar que a prática do BDD permitiu ao
Grupo 3 manter uma pontuação maior, seguido do Grupo 2, esses
dados podem ser observados na Tabela 2.
No processo de validação quanto à distribuição das notas de pro-
duto por aluno, Tabela 2, usa-se a análise de variância com o teste de
Kruskal-Wallis [34], também conhecido como Test H, que compara
três ou mais grupos em amostras independentes analisando a ex-
istência de diferenças significativas nas médias entre os valores obti-
dos. Este foi adotado devido ao fato de que o tamanho da amostra é
pequeno.
Table 2: Distribuição das notas de produto por aluno
Grupo 1 Grupo 2 Grupo 3
Aluno 1 3 4 4
Aluno 2 2 4 4
Aluno 3 1.5 2.5 4
Aluno 4 1.5 2.5 4
Aluno 5 1.5 2.5 4
Aluno 6 1.5 3 3.5
Conforme a observação da Tabela 3 é possível observar que o
resultado do teste H foi de 0.6926 do p-value, df de 5 e qui-quadrado
de 3.0479. Vale ressaltar que para esse teste foram adotados o nível
de significância de 0.05 e o intervalo de confiança de 95%. O chi-
squared ou qui-quadrado ou X2 é uma medida de divergência entre
a distribuição dos dados e uma distribuição esperada. Nesse relato

9. SBES 2019, September 23–27, 2019, Salvador, Brazil Rocha et al.
de experiência foi escolhido para determinar se o modelo estatístico
ajusta os dados de forma adequada. Os graus de liberdade (df) são
iguais ao número da amostra menos 1, isto é, seis alunos por grupo
avaliados por nota menos um igual a cinco.
Table 3: Resultados do teste Kruskal-Wallis
x2 df p-value
3.0479 5 0.6926
O p-value é a probabilidade de se obter uma estatística de teste
igual ou mais extrema que aquela observada em uma amostra, sob a
hipótese nula (H0). Um intervalo de confiança é uma amplitude de
valores, derivados de estatísticas de amostras, que têm a probabili-
dade de conter o valor de um parâmetro populacional desconhecido.
O nível de significância é a probabilidade de se rejeitar incorreta-
mente a hipótese nula (H0) quando ela é verdadeira.
Assim, nesse caso, é possível concluir que se o p-value associado
à sua estatística qui-quadrado for menor do que a seu nível de
significância selecionado, o teste rejeita a hipótese nula de que o
modelo ajusta os dados. Portanto, a H0 - Existe diferença entre
a distribuição das notas relacionadas aos alunos, por grupo
não será rejeitada visto que o p-value foi de 0.6926, isto é, existe uma
probabilidade de 69% de se obter esse resultado por acaso quando o
tratamento não tem nenhum efeito real.
Desta forma, ao se analisar o boxplot, Figura 8, é possível visualizar
as diferenças de notas dos grupos de alunos, nota-se que o Grupo
1, possui um ponto de outlier, ou seja, um aluno teve um maior
destaque comparado aos demais. No Grupo 3, que utilizou o BDD,
nota-se que há pouca discrepância entre as notas dos alunos, além
de estas serem mais altas do que dos demais grupos.
Figure 8: Boxplot comparativo de notas por grupo
Quando analisado os commits dos grupos, o Grupo 1 apesar de
possuir mais commits, parte deles foram retrabalho, ou seja, tarefas
que tiveram de ser refeitas diversas vezes. No Grupo 2, o Aluno
1 optou por efetuar commit por cada funcionalidade e mudança
efetuada, e no Grupo 3 ocorreu um balanceamento na realização
dos commits, onde os Alunos 1 e 5 realizaram a mesma quantidade
de commits e o Aluno 4 realizou a maior quantidade de commits,
esses dados podem ser observados na Tabela 4.
Table 4: Commits por grupo de alunos
Grupo 1 Grupo 2 Grupo 3
Aluno 1 20 32 16
Aluno 2 32 8 17
Aluno 3 40 16 8
Aluno 4 22 16 24
Aluno 5 30 8 16
Aluno 6 18 16 8
Todos os grupos tiveram um comportamento colaborativo entre
os membros, porém os Grupos 2 e 3 obtinham melhores feedbacks
durante o desenvolvimento, conforme os próprios alunos, como
resultado da adoção das práticas ágeis. Os conflitos gerados durante
as iterações foram sanados com apoio do Coach (professor), não
prejudicando o andamento geral dos grupos. O Grupo 3 afirmou que
os cenários possibilitaram uma comunicação rápida e eficiente com
os membros do time e com o Cliente (professor), além de facilitar na
apresentação final, pois tinham uma ideia de aceitação do produto.
Assim, foi possível responder as duas questões de pesquisa:
Q1: O que é preciso ensinar aos alunos para lidar de forma
rápida e eficaz com mudanças de requisitos durante o desen-
volvimento do projeto?
O modelo adotado obteve um bom resultado prático, porém
carece de melhorias no contexto teórico. Apesar dos alunos obterem
as teorias em outras disciplinas, foi relatado pelos alunos que a
ideia da palestra no início auxiliou e foi proposto que poderia
ter mais algumas palestras, porém, os alunos apontaram que tais
palestras seriam melhores aproveitadas se fossem conduzidas por
um profissional de mercado e não pelo próprio professor, falando
a respeito do uso das técnicas na indústria de software. Assim,
passa a ser necessário, conforme relatado, ao menos duas palestras
separadas sobre as técnicas ágeis.
Foi possível notar que, grupos que adoraram as práticas ágeis
tiveram menos problemas em relação as mudanças de requisitos,
conseguindo fazer as adaptações de forma mais ágil. Outro ponto
indicado pelos alunos como positivo foi o fato do professor além
de ser o Cliente, também atuou como Coach durante as iterações, o
que auxiliou na prática ágil durante as tarefas. Além disso, como
relatado pelos alunos, há dificuldades de lidar com as mudanças de
requisitos quando se trabalha em conjunto por causa da falta de
comunicação, sendo melhorado por meio das ferramentas, assim
os grupos adotaram o Slack como forma de manter as informações
relativas as dúvidas que surgiam durante o desenvolvimento, fun-
cionando como uma reunião diária.
Assim, em resposta a pergunta, é necessário que os alunos com-
preendam os requisitos e como eles impactam no produto, tal com-
preensão foi adquirida por meio das práticas ágeis. Também é pre-
ciso que os discentes aprendam que a comunicação entre os mem-
bros do time é essencial. Assim, o professor, atuando como Coach,
foi essencial para explicar aos times que, apesar deles se encon-
trarem em sala apenas uma vez por semana, a comunicação deveria
ser continua.

10. Teaching Agile with TDD and BDD SBES 2019, September 23–27, 2019, Salvador, Brazil
Q2: Como avaliar o desempenho individual ao ensinar um
curso respaldado em projeto baseado no TDD e no BDD?
O modelo de avaliação utilizado nas entregas do grupo, inte-
grando o Trello com o Github para acompanhar, facilitou tanto
o trabalho do docente como o acompanhamento dos alunos, per-
mitindo que o professor, atuando como Coach, auxiliasse os alunos
que tinham baixa produtividade. O Slack, que não foi utilizado para
avaliação, poderia ser um complemento, permitindo entender as
interações entre os alunos. Porém, o quadro de acompanhamento
de commits do Github, ao ser integrado com o Trello, facilitou o
trabalho de análise de produtividade individual e do grupo. Assim,
pode-se afirmar que a integração destas ferramentas pode ser uti-
lizada como método de avaliação do desempenho individual dos
alunos.
8 LIÇÕES APRENDIDAS
Este trabalho apresentou a experiência de aplicação do TDD e BDD
na prática de ensino de Engenharia de Software, não apenas no
contexto teórico, mas também prático. Os alunos tiveram assim, a
possibilidade de aplicar os conhecimentos nas demais disciplinas
na criação de projeto real. Porém, como lição aprendida, pode-se
afirmar que ao liberar os alunos, que possuem pouca experiência
prática, para escolher técnicas não é a melhor opção, o mais ade-
quado seria que tivesse sido determinado a utilização do BDD pelos
alunos durante a execução dos projetos. Outro ponto a ser obser-
vado foi a primeira iteração dos alunos, normalmente se obtém
um baixo rendimento, o que se mostra normal, devido a falta de
experiência dos alunos, assim, isso deve ser contabilizado para a
execução em sala de aula.
Além disso, as divergências nas escolhas das ferramentas e meto-
dologias utilizadas entre os grupos acarretou em diferentes resul-
tados desde o início do projeto até sua conclusão. Isso pode ser
comprovado aos observar os resultados apresentados da Figura 7,
onde inicialmente o Grupo 1 iniciou com maior quantidade de tare-
fas práticas e o Grupo 3 com a menor quantidade (os alunos tiveram
foco no planejamento), porém ao final do tempo estimado o Grupo
3 finalizou o projeto antes mesmo da última iteração enquanto o
mesmo não ocorreu com o Grupo 1. Dessa forma, pode-se ressaltar
que a etapa de planejamento é de extrema importância para evitar o
retrabalho, entregar dentro do prazo, e principalmente para manter
a qualidade do produto.
Por fim, o desempenho dos alunos está relacionado na compreen-
são dos problemas, o BDD auxiliou neste processo, mas carece de
uma forma de validar os cenários, pois, devido a falta de experiência
dos alunos, há possibilidade de se criar cenários que não tenham
utilidades reais para o projeto.
9 CONSIDERAÇÕES FINAIS
Neste trabalho foi apresentado um relato de experiência através
da adoção de práticas ágeis na prática de ensino de Engenharia de
Software. O relato cobre a edição de 2019 do componente curricular
Laboratório de Engenharia de Software dos cursos de Bachare-
lado em Ciências da Computação e Sistemas de Informação de
uma Universidade particular no nordeste brasileiro (Universidade
Tiradentes). Em LES são integrados diversos conteúdos como de-
sign de software, desenvolvimento, teste e validação, empregando
metodologias ágeis, demanda apontada como necessária pelo mer-
cado.
Com base nos resultados apresentados no relato, pode-se afirmar
que o BDD tem melhor aderência para a integração dos diversos
conteúdos, além de possibilitar um melhor entendimento sobre o
problema a ser solucionado, proporcionando, assim, benefícios a
aprendizagem dos alunos. Os resultados demonstram que a adoção
de práticas ágeis auxilia o aluno no processo de desenvolvimento,
reduzindo os ruídos relacionados ao entendimento do sistema, bem
como diminuindo o retrabalho em relação às funcionalidades.
Porém, cabe ressaltar que, as práticas ágeis são apenas uma parte
do processo, visto que a adoção de um modelo de entrega continua
e de reuniões também se fez necessário. Ferramentas como Trello e
Github apoiaram os alunos em relação ao que fazer e o professor em
relação à avaliação, tanto individual quanto do grupo, permitindo
uma auditoria das entregas de artefatos. Além disso, a atuação do
professor como Coach facilitou o trabalho dos alunos.
Como trabalhos futuros, pretende-se aplicar técnicas de análise
de cenário para melhorar a qualidade dos trabalhos, utilizar uma
ferramenta de gestão de defeitos, por exemplo Mantis, além de
utilizar palestras com profissionais de mercado durante as fases de
desenvolvimento, visando melhorar o entendimento dos alunos nas
técnicas ágeis.
10 AGRADECIMENTOS
Agradecemos o apoio da Universidade Tiradentes ao conceder bol-
sas que possibilitaram a execução desta pesquisa e ao Instituto de
Tecnologia e Pesquisa (ITP) pelo apoio.
REFERENCES
[1] Ray Dawson. Twenty dirty tricks to train software engineers. In Proceedings of
the 22nd international conference on Software engineering, pages 209–218. ACM,
2000.
[2] Gil Regev, Donald C Gause, and Alain Wegmann. Experiential learning approach
for requirements engineering education. Requirements engineering, 14(4):269,
2009.
[3] Timothy C Lethbridge, Jorge Diaz-Herrera, J Richard Jr, J Barrie Thompson, et al.
Improving software practice through education: Challenges and future trends.
In Future of Software Engineering (FOSE’07), pages 12–28. IEEE, 2007.
[4] Marcelo H Yamaguti, Flávio M de Oliveira, Cássio AW Trindade, and Alessandra
Dutra. Ages: An interdisciplinary space based on projects for software engi-
neering learning. In Proceedings of the 31st Brazilian Symposium on Software
Engineering, pages 368–373. ACM, 2017.
[5] Mike Cohn. Desenvolvimento de software com Scrum: aplicando métodos ágeis
com sucesso. Bookman, 2000.
[6] Susan Hammond and David Umphress. Test driven development: the state of the
practice. In Proceedings of the 50th Annual Southeast Regional Conference, pages
158–163. ACM, 2012.
[7] Steven Fraser, Dave Astels, Kent Beck, Barry Boehm, John McGregor, James
Newkirk, and Charlie Poole. Discipline and practices of tdd:(test driven de-
velopment). In Companion of the 18th annual ACM SIGPLAN conference on
Object-oriented programming, systems, languages, and applications, pages 268–270.
ACM, 2003.
[8] Wilson Bissi, Adolfo Gustavo Serra Seca Neto, and Maria Claudia
Figueiredo Pereira Emer. The effects of test driven development on internal
quality, external quality and productivity: A systematic review. Information and
Software Technology, 74:45–54, 2016.
[9] David Janzen and Hossein Saiedian. Does test-driven development really improve
software design quality? Ieee Software, 25(2):77–84, 2008.
[10] Dan North. Introducing bdd (2006). Verfügbar unter: http://dannorth.
net/introducingbdd, 2019.
[11] John Ferguson Smart. BDD in Action. Manning Publications, 2014.
[12] Lauriane Corrêa Pereira Moraes et al. Um estudo empírico sobre o uso do bdd e
seu apoio a engenharia de requisitos. 2016.
[13] L Koskela. Test Driven Practical TDD and Acceptance TDD for Java Developers.
Manning, 2007.

11. SBES 2019, September 23–27, 2019, Salvador, Brazil Rocha et al.
[14] Boby George and Laurie Williams. A structured experiment of test-driven devel-
opment. Information and Software Technology, 46:337–342, 04 2004.
[15] Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, and Laurie
Williams. Realizing quality improvement through test driven development:
Results and experiences of four industrial teams. Empir Software Eng, pages 289
– 302, June 2008.
[16] Gerardo Canfora, Aniello Cimitile, Felix Garcia, Mario Piattini, and Cor-
rado Aaron Visaggio. Evaluating advantages of test driven development: A
controlled experiment with professionals. In Proceedings of the 2006 ACM/IEEE
International Symposium on Empirical Software Engineering, ISESE’06, pages
364–371. ACM, New York, NY, USA, 2006.
[17] Stephen H Edwards. Using test-driven development in the classroom: Providing
students with automatic, concrete feedback on performance. In Proceedings of
the international conference on education and information systems: technologies
and applications EISTA, volume 3. Citeseer, 2003.
[18] Michael A Eierman and Jakob Iversen. Comparing test-driven development and
pair programming to improve the learning of programming languages. Journal
of the Midwest Association for Information Systems| Vol, 2018(1):23, 2018.
[19] Giovanna Lorena Rodrigues dos Santos and Edmilson Campos Neto. Um processo
de desenvolvimento de software para o ensino técnico baseado em uma fábrica
de software escola. In Brazilian Symposium on Computers in Education (Simpósio
Brasileiro de Informática na Educação-SBIE), volume 29, page 1741, 2018.
[20] Iago Seroa, Helder Bertoldo, and Vânia Neves. Testerds: uma maneira fácil
e estimulante para aprender estruturas de dados. In Brazilian Symposium on
Computers in Education (Simpósio Brasileiro de Informática na Educação-SBIE),
volume 29, page 864, 2018.
[21] Jean Piaget and David Elkind. Six psychological studies, volume 462. Vintage
Books, 1968.
[22] Morris L Bigge. Learning theories for teachers. Harper & Row, 1982.
[23] Vani Moreira Kenski. Educação e tecnologias. Papirus editora, 2007.
[24] John Dewey. Experience and education: The kappa delta pi lecture series. Touch-
stone, 1997.
[25] Trello. https://trello.com/, 2019. [Online; accessed 19-may-2019].
[26] Github. https://github.com/, 2019. [Online; accessed 03-april-2019].
[27] Fabio Gomes Rocha, Pablo Marques Menezes, Methanias Colaço Rodrigues Junior,
Rogério Patrício Chagas do Nascimento, and Adicinéia Aparecida de Oliveira.
Integração contínua e controle de versão: Uma revisão sistemática. In 14th
CONTECSI-International Conference on Information Systems and Technology Man-
agement, 2017.
[28] Junit. https://junit.org/junit5/, 2019. [Online; accessed 20-april-2019].
[29] JBehave. https://jbehave.org/, 2019. [Online; accessed 15-may-2019].
[30] Slack. https://slack.com/intl/pt-br/, 2019. [Online; accessed 15-april-2019].
[31] Guillermo Rodríguez, Álvaro Soria, and Marcelo Campo. Measuring the impact
of agile coaching on students’ performance. IEEE Transactions on Education,
59(3):202–209, 2016.
[32] Jacques Delors and Zhou Nanzhao. Educação um tesouro a descobrir. 1998.
[33] Bruno Gadelha and Alberto Castro. A reference model for teaching collaborative
mobile systems. In Proceedings of the 31st Brazilian Symposium on Software
Engineering, pages 374–383. ACM, 2017.
[34] Changhee Kim and Won Sug Shin. Does information from the higher education
and rd institutes improve the innovation efficiency of logistic firms? 35(1):70–76,
2019.
View publication stats
View publication stats