Techly Journal has a mission to elevate the technical leadership
and excellence of all engineers in collaboration with the one
and only Patrick KWA. I am excited to share that I'm
organizing 2 workshops in Singapore in early November
2023, The Technical Leadership Master Class and the Engineering
Manager Essentials. You can find more information at
techly journal dot def slash courses slash TL and Techly
journal dot deaf slash courses EM register early while the
early but discount is available. See you there.
BDD is not about using UI automation tools to verify a
fully assembled system. It's about helping you
collaborate with different parties involved in software
delivery to understand what's actually required of your
system, why you need to deliver it, and then to help you find
the best possible way to automate your requirements.
Either As to the UI, fine, but typically you'll have other,
better ways to do it. Hey everyone, my name is Henry
Surya Virawan and you're listening to the Technical
Journal Podcast, the show where I'll be bringing you, the
greatest technical leaders, practitioners and thought
leaders in the industry to discuss about their journey,
ideas and practices that we all can learn and apply to build a
highly performing technical team and to make an impact in your
personal work. So let's dive into our journal.
Hello again to all of you, my listeners.
Welcome back to the Techly Journal Podcast, the podcast
where you can learn about technical leadership and
excellence from my conversations with great thought leaders in
the tech industry. If this is your first time
listening, please subscribe on your favorite podcast app.
You can also subscribe to Techly Journal contents on various
social media, on LinkedIn, Twitter and Instagram.
And for video contents subscribe on YouTube and TikTok.
And if you have been enjoying Technijunal, please support my
work by either buying me a coffee at technijunal dot deaf
slash tip or becoming a patron at technijunal dot deaf slash
patron. My guests for today's episode
are Jan Moloch and John Ferguson Smart.
They are the co-authors of BDD in Action second edition.
In this episode we discussed Indepth Behavior Driven
development of BDD and its essentials.
Jan and John first began by introducing what BDD is, the
benefits of using BDD and the Gherkin language with its Given,
When Then syntax. They gave advice on how to
introduce and apply BDD, especially for legacy software
and how to manage the BDD specifications effectively.
Jan and John then shared several BDD techniques such as feature
mapping, example mapping, impact mapping and went deep into the
Screenplay pattern and the Serenity projects they both
create to implement the screenplay pattern.
Towards the end, Jan and John shared the insights on which
testing layers we should apply BDD and some anti patterns we
should avoid. I hope you enjoy listening to
this episode and learn a lot about BDD and good practices for
managing user requirements and automated testing.
And if you know someone who will also benefit from this episode,
please help. Share it with your colleagues,
your friends and your communities and leave a 5 star
rating and review on Apple Podcasts and Spotify.
It will help me a lot in getting more people discover and listen
to this podcast and I really appreciate it.
Let's go to my conversation with Jan and John after quick words
from our sponsor. Are you looking for a new cool
swag? Technically, Juno now offers you
some swags that you can purchase online.
These swags are printed on demand based on your preference
and will be delivered safely to you all over the world.
Where shipping is available, check out all the cool swags
available by visiting Techlyjuno dot dev shop.
And don't forget to brag yourself once you receive any of
those swags. Hello everyone, Welcome back to
another exciting new episode of the Techlyjuno Podcast.
Today I have with me two guests in one time, right?
So they are the co-authors of a book titled BDD in Action.
So if you are into software testing and if you have heard
about Behavior Driven development today, we will be
discussing a lot about it. And this BDD in Action is
actually a second edition in extension to the 1st edition
which was published I think sometimes in 2014.
So John Smart was the first author of the book, and then in
the second edition he collaborated with Jan Moloch
here. To come up with the 2nd edition.
So really looking forward to this conversation and learn a
lot about BDD and software testing in general.
So thanks for being here guys. It's a pleasure.
Thank you for inviting. Thank you for having us.
So Yan and John, I always like to ask my guests to introduce
themselves a little bit, maybe telling about career highlights
or any turning points. So maybe I'll leave it to either
one of you to start first. Well, I can go first.
So I'm John Ferguson, Smart. I've been in software
development for more years than I can remember since the 90s.
So I've been doing Agile software development since the
late 90s, early 2000. I've done a bit of everything,
so development. I still do active development,
testing, project management, waterfall, agile, XP, the whole
whole range of things. In the 2000s, my role was very
technical and I always thought the requirements side of things
was a little bit intimidating. All this talking to people and
stuff as well. That was a little bit of a
challenge. So I gave myself the challenge
of actually getting into that and doing that a little bit
more. And that's where a lot of my
activity in the sort of BDD space emerged.
I started to get involved with people in these sort of Agile
and BDD communities in London. Quite a bit, The Dan N, Liz Keo,
people like that who were very active.
Chris Matts was another one, very active in that area.
And so that's where my big interest in behavior driven
development really came from. But if you're talking about
highlights, actually one of the interesting highlights was I've
actually been doing BDD for well over 20 years because one, there
was this one time I was working with an insurance company in
Paris, France. And their problem was they
wanted to put an insurance application online, and their
problem was reproducing their mainframe insurance algorithm in
Java. And they had like a gazillion
lots of rules that are all done in this really complicated Excel
spreadsheet. So I had the idea of taking that
Excel spreadsheet and actually saying, well, give me all the
examples that you use to test your Excel spreadsheet and we
use that to test the actual code we write.
And that was effectively, we just read it through J units and
produced a little report. And there was actually another
Excel spreadsheet, somewheres were green, somewheres were red.
And that was the first executable specification with
collaboration with the business that they ever wrote.
And I thought that was such a wonderful technique that works
really, really well. I've been trying to do it ever
since because I really do think it is by far the most effective
way of so collaborating and delivering software that makes a
difference that I've experienced.
Wow, that must be a very tremendous effort.
So I really congratulate you to have a success for that project.
How about you, young? Oh, so my career journey
actually didn't start in finance or banking, where I work right
now. It started in a complete
opposite of the spectrum. So it started in early 2000 in
the video games industry when I was back in Poland.
So I remember one of my first jobs I was actually working for
CD Project Thread, the studio behind the games like The
Witcher for example. I was the very first full time
web developer there and my job spec had one sentence and said,
well sort out everything around the Internet.
So, well, that's quite broad. Well, I asked my boss, well what
exactly do you need? And he told me, well, what do
you think we need? So I said, well, we would
probably need a place for people to exchange comments about the
game. We need to have a place to
publish the news about the game. I said all those things and he
was like, well that's awesome, let's do it.
How can I help you so? Remember that that's my first
job. I was like, you know, in my
early 20s I had absolutely no idea what I was doing.
But what it really helped me to do is to actually have this
business perspective on software.
So how can I create software, how can I work with my team to
create software to support a then small company.
So I've been used now the things I learned back there and try to
apply it to other industries. Now, later on, I moved from
Poland to the United Kingdom. And there was similar to John.
That's where I met many people who are no practitioners of
Extreme Programming, of Test Driven Development of BDD and so
on. And one of the problems I was
trying to solve, I was trying to find the ancestor was how do we
ultimate testing? Now I'm not sure.
If the audience knows about it. But one of the main problems in
one of the many challenges in video games development is how
do we actually test the games? If you have a like a real time
simulation, because that's really what a video game is, how
do you make sure it works? So I tried to find answers to
that, and typically the answer I would get as well.
It's not possible. That was just too hard.
And whenever I hear it's not possible, it's not too hard.
The first thing I do is I try to figure out why it's not
possible. Then the second thing I do is
try to figure out how to do it. So I tried to answer this
question now across different industries.
So I worked in publishing, I worked in media.
I worked in broadcasting, I worked in finance.
And the one thing I actually realized is that whatever
company I joined or whatever client I worked with is very
often here that the testing is impossible.
It's very hard to do well. Why is that?
So many of those companies, what they would do is they would hire
manual testers to click through the scenarios and basically
confirm whatever developers have already created.
Now what I realized is that, you know, testing is difficult
because it's actually very hard to understand what is that we
actually trying to test. Why try to test how to set the
priorities, how to understand what parts of the system are
actually important? And turn out is that just in
video games there was the same case in financing insurance, in
banking, in broadcasting, every was the same case.
So then I started looking at two ways actually.
Well, first automate my tests, then figure out how to gather
the requirements. Actually, how to understand what
bit are important. And that's how I came across
Jones work around behavior development.
That's how I got to meet guys like the North and Lee Skio and
the rest of the London BDD and TTD crowd.
So that's how I actually got to connect all those different
dots. And actually, if you got in
order to avoid issues with manual testing, in order to
automate testing, well, you actually need to understand what
is that you're trying to test, why you're trying to test it
now. To do that, you need to
understand your requirements. To understand your requirements,
you need to speak with the business stakeholders, you need
to speak with your customers, you need to have ways to
actually gather and analyze feedback in very fast and
efficient ways. So that's how all those
different pieces of my career journey came together here in
London. Thanks for sharing your story.
I think throughout both of your career journey and highlights, I
can tell that you guys deal a lot with software requirements
and testing, right? And the challenges how BDD later
on can help in terms of doing software testing and also
gathering requirements. So let's just go straight into
BDD, right? So in the 1st place, maybe if
you can summarize what were the challenges before BDD was around
right? What were the challenges that
probably was prominent in the software development world?
So from my perspective. BDD, I've heard it described by
one of the managers I've worked with us.
It's what makes you actually be agile, not just do agile.
And so BDD and Agile are very closely related.
That is all about solving that same problem.
It all comes down to the communication.
So we can code all we want, but coding is not really the aim of
the game. The aim of the game is to
deliver solutions that actually. Solve problems that the business
have. Enable them to do something that
they couldn't do previously. Enable them to do something that
they could do previously but better.
Prevent problems. Save money.
Or where. There are the four categories
that we know about how you can actually deliver value.
Chris Matt's 4 categories, if I recall correctly, how you can
actually deliver value and all of that.
The problem is it comes from understanding the requirements.
And what we've always found is that.
You can't just write down the requirements, or have someone
write down the requirements for you and expect to get value out
of them. There's always iterations,
there's always feedback cycles, and the aim of the game is to
actually reduce those feedback cycles.
And the waste that comes from that.
And before, well before the days are sort of BVD, you would
inevitably have really long cycles where.
You'd have siloed processes. And even in allegedly agile
projects, you still get that siloed processes of BA's or
analysts or product owners right?
Requirements hand them off to the development team to build,
they build something, they hand that off to testers to test, and
then they the testers. Or maybe they even also have a
UAT testing phase where users go through and test things in their
own way. And that's always a bit of a
surprise because they never told you what they were going to
actually test all of that. Every stage gives you the
opportunity to lose information, to make mistakes.
And so that's what the biggest challenges we're having before
BDD is getting that communication allied.
Yeah, I think that's quite a funny thing because now
typically when we think about software development, we focus
on things like the languages we use, the frameworks we use, or
the automation tools we use. But.
We kind of forget about the most important bit, which is the
social aspect of creating software.
So PDD is one of those tools, Behavior Driven Development.
It's one of those tools that helps you to focus on the actual
outcome that your software or your solution is supposed to
bring to the organization. Now, the interesting thing about
it is that bringing the outcome doesn't necessarily need to
require software. So that's again one of the
things that software developers very often forget about.
If you think about it, I'm a software developer before I have
to build software in order to exist, right?
And that's my job. That's my role in the system.
With BDD, what we can do is we can look at the outcomes that
our organization seeks to achieve and then perhaps we
could try and find solutions that don't require us to build
any software. Perhaps we can bring the same
outcome by improving the process, by speaking to another
person, by reusing the tools we already have.
Now, if we can accomplish the same outcome without building
additional software, well, then we won't have any additional
software to maintain and therefore we can further reduce
the costs. Thanks for the addition to that
important bit, right. So we don't always have to need
software to bring an outcome for the business or the
organization. It could come in many different
shapes and forms, right? It could be process
improvements, maybe some kind of prototypes, maybe some kind of a
cheaper solution than writing software.
So let's go to probably the definition of BDD, right?
So for people who are new to BDD, I also heard people
sometimes mistaken BDD with just the Gherkin, right?
The Given when then. Some people also refer to ATDD
Acceptance Test Driven Development.
Also people are saying a specification by example.
There are so many different terms.
Maybe if you can help to define first what is BDD and how does
it compare with all these different terms that are
available out there in the industry.
So Behavior Driven Development is a collaboration approach from
my perspective. It's not a particular tool set
or not a particular. Well, it is a methodology, but
it's not related to a particular language or tool set or.
Testing approach. It's definitely not about test
automation and it does encompass all of those other aspects
nowadays. I mean, it's a concept that's
been developed in different ways.
Back in the noughties we have fitness, we'd call that a TDD
because we'd try and define the acceptance tests first, just
like we're doing TDD and we'd try and write them in a business
readable format. Specification by example was
Guico and Six. Book which described that same
approach, Behavior Driven Development was originally
coined by Dan North as a way to explain Test Driven Development.
But with the work of Chris Matts and Liz Keo and other people in
that community, it fairly rapidly expanded into being
applied to analysis. So we often we see BVD extends
from TVD, now it does it. BVD is a totally much broader
concept now. It's the collaboration.
Process where we involve business, users, developers,
testers, everyone to have conversations around the
requirements in BDD. One of the concrete things that
we use, one of the really characteristic aspects of BDD,
is that we use examples a lot. So rather than just writing
general specifications, we describe everything in terms of
examples. And we use those examples to
drill into the details and challenge the assumptions and
challenge our mental model of what a requirement actually is
about. So that using examples and
counter examples and telling concrete stories is a much
better way of getting the team involved and engaged than
there's a more traditional requirements writing approaches
and even just the classic news stories which can very quickly
become just a proxy for requirements.
Now the automation aspect. BDD is not about automation.
Cucumber is not an automation tool.
We'll test automation tool. We're not in the business of
automating test cases. What we're trying to do is
define the requirements in a format that can give us fast
feedback on whether they've been implemented.
Now it turns out that a really effective way of getting that
fast feedback is to automate them.
So automate the requirements. It's using tools like Cucumber.
Now tomorrow, if we get a tool that's better than Cucumber, we
can use a different tool. We'll still be doing BVD.
It's not related to a particular tool.
So Gherkin is the Given, When Then language that's used in
tools like Cucumber and Spectlow and Behave and quite a few
others. And it's one of the more common
ways of doing BDD. But it's not the only way.
We can also do BDD, express our requirements and write them very
well just in plain JavaScript or Java or Python.
And if we write our scenarios, our examples in a business
readable language, and if we can produce reports that reflect
that business readable language, then that's BDD as well.
So I'll tell you that in a nutshell is sort of what BDD is
all about and it is a very broad definition, but there is a lot
to it. Maybe one thing I would like to
add is that what PD helps you with is helping to avoid things
like scope creep, so focusing your team on outcomes, so
focusing on the conversation around outcomes.
So what is that our software system?
What is that our solution is supposed to bring to the
organization? What does does several
interesting things. So firstly, we talked a lot
about our collaboration and conversations and so on what
many people might hear. Well, Oh my God, we're just
going to have more meetings. No, no, not at all.
What we mean is that what we're doing with BDD is we're helping
team to start having informed conversations on focused
conversations around specific outcomes they were trying to
accomplish and it was just not any random chit chat.
So we are trying to focus on the outcomes because focusing on the
outcomes helps us find more precise solutions to the
problems we're trying to solve. We are not just shipping
features for the sake of shipping features, we want to
solve a specific problem. Now this focus also helps us to
avoid scope creep, as I mentioned earlier.
Now the idea here is that you know, if you know that your goal
is to, I know, increase the number of conversions on your
homepage by what, about 20%? Nobody.
By some time, well then you are trying to focus on delivering
those features that help you to accomplish this specific goal.
Now this helps you to avoid having to ship any other
features that don't support this goal.
Now what this focus also gives you is also gives you an
opportunity to improve the overall quality of your
software. So again, not only we can turn
those requirements, those scalable specifications into
automated tests by reducing the scope and focusing only on those
things that matter, it's easier for us to ensure the quality of
the software we deliver simply because we have less of it to
deliver in the 1st place and what we deliver is of higher
value. So again, we're focusing on
delivering high value software and making sure that is actually
the software itself is of high quality as well, not just
sharing more and more features. There are many other interesting
outcomes of this approach by again focusing scope, improving
quality, improving the value of software we develop and deliver.
We also improve things like developer happiness.
Because suddenly now that you have conversations with your
business sponsors, you have conversations with your
customers, you understand what is that you're trying to solve
now, why you're trying to solve it.
You actually have a mental image of the person you're actually
delivering the solution to. It's much easier to see how your
work is worthwhile. It's easier to see why you're
actually trying to do it now. This again improves developer
morale, improves developer happiness, increases developer
productivity, and so on. So it's actually quite
interesting how many positive effects that team can see by
doing things like focusing your work on the outcomes that you
are supposed to bring to your organization.
Thanks for highlighting the important aspects of BDD.
I think the first thing I heard very clearly from John is that
BDD is not automation only, right?
It's not software testing only. The first is about collaborative
approach that focuses a lot on conversations, examples, right
and also outcomes like Yan also extended in the later part.
So I really love that explanation.
So for people who still think BDD is just another tools for
automation to make your software testing much better, I think it
is more than that which speaks to the next topic that I'd like
to ask you guys. What do you think are some of
the benefits? If you can summarize that BDD
offers for people to give it a try?
If they don't have the time yet to try BDD, why they should
consider applying BDD now in their software development
practices? From my perspective, and this is
what I see on the ground, it's a good question because you do
need to know why you're introducing any technique and
what you're going to measure it on and whether it gives you the
outcomes, because that will tell you whether you're actually
implementing it effectively or not.
And there are two levels of outcomes that I see.
There's what you might call the proxy outcomes, which are easier
to spot, easier to see straight away.
And then there are the longer term outcomes which was what
you're really trying to achieve, the sort of proxy or short term
outcomes because of the nature of the collaborative nature of
BDD and the fact that you really do build up a shared
understanding within the team of what you're trying to do, it
tends to reduce the number of defects dramatically.
So I see typically, and this is not talking about automation,
just the fact that you collaborate effectively reduces
a typical defect rate by seventy 8090%.
You just. Don't get defects into
production a lot of times because you get a much deeper
understanding and you've got the opportunity to ask questions and
people do ask questions. Now that assumes that you are
actually doing the collaboration correctly.
If you're just writing given when, Then statements in your
test cases and calling it DVD, you won't get those benefits and
you'll wonder why it doesn't work.
But if you do the collaboration and then think about how to
automate, you will get those benefits.
The automation BDD is a really effective way of doing
automation. So I find it when you do it well
and combine it with TDD you can do a really nuanced level of
automation and get a lot of bang for your buck for the amount of
automation effort that you do. So it really helps you get a
laser focus on what you should automate, why you should
automate, and where you should automate.
And so that's a good practical benefit.
I find there's also a longer term benefit.
Is that. Because you're having these
conversations and this applies, you want to be having
conversations not just at the story level, but also at your
features and epics and then coming up with examples of user
journeys and use cases at the epic level, so you can
understand what they're about and where the value is coming
from. And that helps you to be more
confident in delivering value, that actually delivering things
that make a difference to make an impact.
So that's a really important longer term benefit.
And the third big benefit that I see and which is a little bit
less tangible, but as what a lot of people report to me and what
I see in the teams that I work with is that you get the teams
which are much more engaged. So team members tend to be much
more engaged and creative because they know what they're
contributing to and they have a sense of mission and the sense
of ownership of the problems they're solving.
Much more so than the traditional siloed approach
where often development activity is basically implement this
JIRA. Without really understanding the
bigger picture, very much so. The teams do get much more
engaged and that leads to some better productivity and more
creative outcomes. Yeah, I think one of the things
that John mentioned, they really deserve to be highlighted even
more. I mean, if you think about it,
according to various scientific research done over the last
couple of decades, it turns out that between I think 40 to 80%
of all software defects actually come down to issues with
requirements, issues we've misunderstood or perhaps no
miscommunicated requirements. Now you asked about the
benefits, Henry. So if in your audience we have
listeners who are on teams that suffer from issues with
production defects, issues with defects in their software, if
there was one thing for you to improve, think about what can
you improve around your requirements, around how your
development team collaborates with the business, with testing,
if you have one, with OPS teams, and so on.
Think about improving how we collaborate around the
requirements, because issues with requirements cause most
issues with your software, most probably.
So by addressing issues with requirements, you are more
likely to improve the quality of your software than by focusing
issues with, let's say, coding errors, which are much less
frequent than issues with requirements.
Well, thanks for the plug. I think I remember this kind of
research as well. And I also know that rework is
also something due to the miscommunication or maybe the
requirements not captured properly.
So I think yeah, if software engineering team wants to
improve some parts of their productivity and effectiveness,
probably requirements is 1 big area where it will bring a lot
of impact. So thank you for explaining some
of these benefits. I really love that John
mentioned about this increased engagement from not just
engineers, probably it's the whole team, right, because they
are so collaborative and trying to come up with a better way of
approaching the problem and achieving the target outcomes.
So talking about BDD, I think we talked about it earlier just now
about Gherkin, right. I think talking about BDD, we
have to cover a little bit about Gherkin.
So what is this Gherkin? Why the name is so funny?
And. What is the essence of Gherkin
anyway? Gherkin is a small cucumber,
Pickled cucumber kind of. It's in that family of
vegetables. And so there's a relationship
between cucumber the tool and Gherkin the language.
So Gherkin is the given when then notation that we use.
So Dan N was originally at the origin of that where coming up
with that notation and then Chris Matt observed that it was
a good way of describing business expectations as well.
But a lot of people misinterpret it by a lot of people.
They don't know how to use it, basically use it incorrectly.
And it's what happens when we see test groups written in this
given, when then format given when.
That format that can be crystal clear, can be a really nice,
precise, readable way of writing your requirements, or it can be
a horrible mess. It's like anything it can be
depending on whether it's well written or not.
So well written it will have value or not.
So there is quite a skill to writing a clean, effective,
concise, given when then statement that really reflects a
business rule and really reflects a business
requirements. And so it does take some
practice and some effort to get that right to start with.
But when you do, what happens is you end up with this, what we
call a domain specific language, which is really the heart of the
collaboration for a team around a set of requirements.
And that's where I've had projects.
Where we've defined this sort of domain specific language for a
particular part of a project and it's allowed business to write
their business rules and express their business rules with such
clarity that there's no other automation that needs to be
done. They just need to express a new
business rule using their existing language and everyone
will understand what it needs to do or what needs to be done.
That doesn't happen in all projects or in all cases and
with all situations. But when you aim to do that, you
can come up with that language and use it as a really central
part of your requirements definition process.
If you just use it for test scripting, it's much less
valuable because a test script was given When then.
Generally people will mix up the Given When Then and it won't
make any sense. It'll be hard to read, and also
when people write test scripts with them, they tend to be much
more granular. Much more focused on clicking on
buttons or clicking on the fields, and that becomes brittle
and hard to maintain. And so people say Gherkin's no
good because it creates test scripts that are hard to
maintain. Absolutely it does.
But if you use it to write executable specifications in the
business language, it can be extremely effective.
Absolutely. I think one of the main things
that's character language is supposed to help you accomplish.
What aims to help you accomplish is a separation of
preconditions, actions, and outcomes.
So given when then it's actually very similar to what you see in
well written unit tests with the separation of three parts.
So Arrange, Act, Assert. Now we're doing something very
similar, but with the focus on business requirements.
Now the reason why we're expecting this in a human
readable language is so that now we can create an opportunity to
avoid some implementation specific details.
So again, we can focus on the business language.
We can focus on introducing this business domain language into
our executable specifications. Now an interesting thing about
Cucumber and Gherkin that you know many especially English
native speakers forget about is that what's Cucumber and Gherkin
allow you to do is they allow you to express those in scalable
specifications in a language other than English.
Now Cucumber, the last time I checked is supported over 70
different languages. So what you can do now as a
team, If your business sponsor or your audience speaks language
other than English, or they're more comfortable with other
language other than English, then you can express your
specification in Spanish, French, Arabic or whatever other
language you prefer. And then Cucumber under the hood
will translate those statements in the human readable language
to your actual automation calls. Now it's going to be very, very
useful again as a tool to improve collaboration with
different audiences of your automated specifications.
I wasn't aware that many languages are supported, so
thanks for adding that. So I think that's really
interesting. Yeah, even Pirates speak from
what I remember. So those are.
And also, I just knew from John what Gerkin means, right?
It's a small cucumber. So I think I learned these two
things really well today from you guys.
So talking about BDD, right, I think in order to introduce
that, I think it's not just a simple switch, right?
People need to learn and people need to understand how should
the flow be. And I think I believe many teams
these days practice Agile software development
methodology, whether good or bad, it's a separate discussion,
but I think in your book you outline several steps that
people can try in order to incorporate BDD in their
software development flow. Maybe if you can give us a
highlight, an outline. How should people introduce BDD
seamlessly in their software development methodology?
So we work with teams, John and myself, that's what we do.
We work with teams to introduce BDD into the.
So we've got a fair bit of experience with what works and
what doesn't. And what we've always found is
that you need to start with the requirements part.
You need to start with the conversation.
The automation comes later. You've got to start with the
conversation. So you've got to get people
communicating and collaborating and having those conversations.
And it might feel like, yeah, I was saying earlier, it might
feel like you're spending more time in meetings.
But actually what you get out of those meetings is multiplied
many times by the time you save actually delivering the code
that you meant, building and delivering the code and the
features that add the value. So the first step is to
understand what the BDD process is.
Understand that it's about conversations and collaboration
and then automation and start structuring that those making
time, carving out a time in your existing process to have those
conversations. You don't want to leave it at
Hock and you don't want to leave it to sort of just random
conversations. So the second thing is that BDD
proposes a number of practices, like example mapping, feature
mapping, a whole lot of others. But they're structured practices
which designed to help teams get the most out of those
conversations. And they are very intended.
A whole lot of psychology that goes into a lot of the things we
suggest in BDD. But those techniques are really
important, especially when we have teams where some people
might be more vocal, some people might be more reflective and
like to take time to get their answers.
When we can use collaboration tools, when we use tools like
mural and figma and mural and whatnot for online
collaboration, we can get the same effect.
We can use a structured approach to coming up with those examples
and then turning them into an executable format.
The third step we introduce is. The actual automation side of
things. So how do we find an automation
approach that will work for the technologies that the team's
using? And that obviously varies and
I'm very reluctant to say to a particular team you must use
this automation tool. I'd rather the team own the
automation technology and then we basically what we do is we'll
guide them and to choose. How they can actually implement
and I mean, we have our preferences, but I've worked
with teams who work with APL. I remember one team was working
on and also it's really obscure stuff.
So not everyone is using Java or JavaScript.
So Java, JavaScript and Python, they're the big ones that people
are using these days. And with them, Cucumber does
provide some nice options. But there are lots of options
out there and you want something that the teams embrace and adopt
themselves. And then the final stage is
actually getting the teams doing the automation themselves.
So automation is not just about the test or automating test
cases. It's about we want an outside in
approach. So we're as far much as
possible. You don't automate after the
fact, you automate before you actually start the work.
And that's what I was saying earlier on.
The ultimate end goal of that is that you don't need to automate
at all, that you express the requirements in your domain
language. And the automation is already
done for you. So that's sort of the ultimate
in ATDD. So they're typically the stages
that we go through that we see when we help teams introduce
BDD. Yeah, absolutely.
I think the collaboration aspect is again one of the most
important ones here. So like you mentioned earlier,
John, so one of the things that the teams very often try and do
when introducing BDD is to focus on the tool.
I mean, it's an actual inclination of any software
engineer. We focus on the tool first, so
we think, Okay. Well, I like BDD.
I like all the things it promises.
I'll just use Cucumber to write some automated scripts after
I've already done development. Well, that's kind of pointless,
right? What do you mean?
The development has already happened?
The collaboration has already hopefully happened.
So now it's way too late to actually write any automated
tests. Now what we do, this workshop
that John mentioned earlier is one of the core practices of
Behavior Driven Development is a Three Amigos workshop.
Now the idea of the Three Amigos workshop is to have people
representing different perspective involved in software
delivery. So the business perspective to
the development perspective and the verification perspective.
Someone to actually describe the word and why it's needed for the
organization, someone to figure out how we actually ship it, and
someone to critique the idea to find the house, find the things
that might possibly not work so that we can actually guard
against them. So that's one of the critical
workshop that we typically introduce.
Now, another thing that you need to do this workshop is you need
to make sure that the people who actually can add value to those
workshops are involved. So what a team would need to do
is to identify the dependencies not only in terms of software,
but again in terms of other teams.
So for example, if I need to accomplish a certain goal that
requires me to work with my Dbas or application security teams or
QA teams or whatever other teams I have in my organization, I
would try to establish those communication links first.
So again, we typically focus or we recommend teams to focus on
establishing those communication links because this then leads to
you understanding the requirements, but it doesn't
help you automate those requirements.
But then this helps you to deliver better quality software.
Right. I like the emphasis that you put
that we should not start with the automation first, right?
Like picking the tools do the automation, but actually the
development is done and maybe the story was already defined.
So I think, again, the emphasis is on the collaborative aspect.
What about if the teams already have a software in place?
There's a legacy code. There's a legacy requirements.
Maybe it written somewhere, maybe it doesn't get written
somewhere. Maybe it's in people's head.
Is there a way that you would advise people to incorporate BDD
into, you know, like legacy software?
Generally speaking, there are two approaches.
Either you only do it for incrementally for new features,
or you backfit executable specifications for your entire
application. I don't generally recommend the
second approach, but I have had teams who are really insistent
on wanting to do that approach because they wanted the value of
the living documentation. And they knew the legacy
application was mission critical and they had no understanding of
what it actually did. So they were in the case.
Particular case I'm thinking, which was a company in Sydney
who did this and it worked really well, is that they used
the BDD approach to retrofit. Executable specifications for
their existing functionality. And that was a way of them
understanding what the application did and documenting
what the application did. And that allowed them to
progress faster afterwards. But in most cases, what I find
is a path of lesser resistance is to apply it incrementally and
progressively. So you come with a new feature.
Your new feature is at a column to a particular search result.
You're not going to write a whole lot of BDD scenarios for
everything around it. You're going to write a BDD
scenario for that particular use case and use a journey.
So your use case might be well, a admin will add a product to a
catalog with a range of colors, and the search screen should
show those colors in the search results.
And so you might have a some scenarios around that, and that
will be your BDD scenarios. You won't explore every possible
way the admin can add products to the catalog or every possible
way you can search. But as you add new features,
you'll expand on what you've done and gradually you'll create
these little islands of executable specifications which
will eventually come together and form a bigger picture.
And that is a more pragmatic approach when you've got an
existing application and you don't want to burden the team
too much with having to do too much automation at the start.
Now that said, I do know teams who use that approach, but
simultaneously they have a tech debt approach where they
recognize that there is a technical debt related to the
lack of automation, lack of executable specifications.
So each Sprint they'll do a little bit of work to chip away
at that and add a little bit more than they need to, so that
they can gradually build up their executable specifications
more quickly. Now, one of the things that
could be helpful to teams that actually need to support
existing software while introducing new features is
something we described in the book as well, and that's a
technique called journey mapping.
Journey mapping is a BDD technique that we've developed
when working with teams who work on established software systems.
If you think about it, this is a very common case, especially in
finance, insurance, healthcare. Where you know you very rarely
have the luxury of starting with a Greenfield project.
You typically have something you have to maintain.
You need to add to that now techniques like journey mapping,
what they allow you to do is they allow you to focus
collaboration with other parts of your organization around the
important aspects of the system that your systems to support.
So it allows you to focus on the specific actors or the specific
external parties, your systems to support their main use cases,
the main scenarios and so on. So with this collaboration
technique helps you to do this, helps you to prioritize any of
your refactoring or re architecting work better.
Because now that you understand what the system is supposed to
do, you understand what the important parts are.
You understand what parts need to keep working whenever you add
new software or new features. Then you can make sure first
your manual testing or exploratory testing activities
around those important aspects. Then you can start creating your
automation with the focus on the important aspects of the system.
Because now any existing system will have functionalities that
are used on a daily basis frequently, but most of the
users and we have some features that have been added by two
decades ago for whatever reason that nobody remembers.
So it's important to be able to distinguish between those two.
Right, so start small, start gradually, right?
It's not like one Big Bang approach.
You can have all the requirements captured in one
goal, right? Absolutely start small and build
right. So both of you mentioned things
like features, scenarios, steps. I think.
Let's go a little bit more into the techniques, right?
For teams who implement BDD, how should they structure all these
different given, when then different scenarios?
Is it common to put it in their user stories or is there a
better way of structuring and managing those requirements?
Generally speaking, some teams will put the Given, When Then
statements directly in JIRA, some teams will put it in
version control. We used to.
Well, it was very common a while back to actually come up with
the Given When Then statements directly in Three Amigos, then
automate them later on. But we've found that that's a
rather inefficient process because it takes a lot of people
a lot of time to words with those given when then scenarios,
whereas what you're really after is getting the key examples and
counter examples. And so the given When then
really should be what we call an executable specification.
And if it's executable, it's part of the source code, so it
should be actually in the source code.
Now the problem that happens is product owners and business
analysts, they want visibility on those given when then.
So there are tools around Jira plugins for example, that allow
you to give you visibility on those given, when Then
statements that you've got in your source code.
Even edit them some of them so that you can get that visibility
from Jira in your user stories, but without compromising the
fact that the Given When ends are effectively source code and
they need to be in a place where they can be executed.
What is an anti pattern and I find is that when product owners
right the Given, when, Then statements directly in the user
stories before they have the conversations because that cut
short the whole conversation part of BVD.
That introduces a whole lot of cognitive biases and actually
makes the conversations a lot less efficient.
And also they're really hard to automate generally.
So that is generally speaking, there's maybe one team in 10,
one team in 20 who can pull that off that I've seen.
But generally speaking we don't advise that.
We advise having the conversations first, writing
lightweight acceptance criteria first, having the conversations
and then putting the Given When, then inversions from, then
figuring out how to get that visibility in JIRA or whatever
tool you're using. Plus, I think a very important
distinction to make is between features and user stories.
I remember for me to say very important switch in how I was
thinking about software delivery as a whole.
Features is what your software provides.
It's what the things that people can use.
User stories is how you deliver those features, how you
structure your software delivery process, in what sequence do you
deliver different pieces of functionality.
So what typically happens with those feature files?
If your team uses Cucumber, or with your test specification
classes, if you're using JUnit or Aspect or whatever.
What typically happens is as you deliver new user stories, you
will be expanding your feature, the executable specifications of
your feature, with every new user story you deliver.
Sometimes you'll be adding additional scenarios, sometimes
you'll be changing the existing scenarios.
Sometimes you'll be removing scenarios when you see certain
aspects of a feature. Don't gain as much traction as
you were hoping it's to gain. So again, every user story your
team delivers, you're basically affecting the current shape of
the feature your system has. Well I think I get a lot of
explanation and clarity on how teams should manage their given
when then right? I see some teams actually just
write it in the stories and then it gets lost once the story is
done. Maybe few sprints before right?
And the teams also couldn't figure out how to collect back
all these given when then. So I think all these
explanations make sense. Both of you have mentioned a few
techniques in addition to making BDD work more effectively,
right? Things like journey mapping, I
think impact mapping, private campuses, and all of these are
also mentioned in the book. Maybe if you can highlight one
or two of your favorites techniques that we can also
explore in order to make our BDD implementation much more
effective. Yeah, sure thing.
So maybe we could start with the screenplay pattern.
So the pattern itself caused a bit of a stir when we first
talked about it in the test automation community and the
ability community in general. So what is screenplay pattern?
So screenplay pattern is quite an innovative user centered
approach to writing high quality automated acceptance tests.
And what it does It tears you towards an effective use of
layers of obstruction and helps your test scenarios capture the
business vernacular of your domain.
It also encourages good testing and software engineering habits
on your team. Now, how does it do it?
You see, typically when we do automated testing, when we write
automated tests, we express those tests from the perspective
of an integration tool interacting.
With our system. So in the UI testing you would
write a test as a web driver. So go to a page, click on a
button, enter a value into a field and so on.
When we do API testing, we express it from the point of
view really of an HTTP client. So I send the request, I get the
response, I verify a status code.
But what we typically miss in those scenarios is we completely
miss the business vocabulary. We miss the business reason
behind those scenarios. We completely failed to capture
all this information in our test script.
So with the screenplay pattern, what we do is we flip this whole
thing on its head. Instead of expressing the
automated tests from the perspective of a low level tool,
we look at them as a way to express all the different tasks
that an external user of our system or of our interface would
perform in order to accomplish their goal.
So rather than talking about a Webdriver or playwright or
Cypress clicking on button and entering values into fields or
talking about rest assured we identify actors.
So those could be either people or external systems interacting
with our system. What we do next is we capture
the specific goals and tasks they need to perform in order to
accomplish their goals. So for example, we might focus
our scenario on a person or a persona of a shopper that goes
to an e-commerce website, tries to find a product added to the
basket, make sure that the tax is calculated correctly, and so
on. So what we do this pattern is we
actually capture the business vocabulary, we capture the
business intent behind given piece of functionality and we
use high quality code to express those things and capture them in
a form of an executable specification.
So the main thing in a user centered model is a model
representing a user or an external system interacting with
our system. Now the interesting thing about
the pattern itself is that it's actually, it might sound like
something really complicated, but in fact it really isn't.
It's made out of five main building.
So we have actors. Actors are the first building
block of the screenplay pattern. Now I already talked about the
tasks. So tasks are basically a way to
express those different things that an actor would do in order
to accomplish their goal. They're basically aggregates of
lower level SAP tasks or interactions with the system.
So we have actors and we have tasks.
Those tasks are typically made-up of interactions.
Now interactions are the lower level actions that the actor
would perform in order to interact with the system, hence
the name. So we have actors who perform
tasks and those tasks are made-up of other tasks and
interactions. Now how do those actors perform
the tasks? So the interesting thing about
the screenplay pattern is that we try to encapsulate all the
lower level API calls to our. API clients.
So you wouldn't see any web driver or playwright or Cypress
calls in your tests. All those would be encapsulated
in another class. So those class are called
Abilities, and abilities are basically thin wrappers around
those integration libraries. So we have actors who perform
tasks. Tasks are made-up of other
subtasks and interactions, and what enables those interactions
are abilities and abilities. Again, just the thin wrappers
around your integration library. So those are the four elements.
Now the fifth one are questions now similar to the CQRS model
for designing system architecture.
In the script play, we also separate the interactions that
the actor would perform from the information that would get out
of the system and the test. So an equivalent of a command
from your CQRS model are the interactions in screenplay
equivalent. Of a request in the screenplay
button. Questions.
So questions are a way to retrieve information from the
system, and questions could be things like get me that text
from that element on the screen, or get me the last response body
that you received from the API requests, or get me the position
of this button in my mobile app. So again, you've got those five
building blocks, so actors, tasks, interactions, abilities,
and questions. And out of those five building
blocks, you can. Develop pretty much any type of
automated tests you might dream of, really.
So we've used it for UI testing, for mobile testing, for API
testing, for performance testing, for visual regression
testing. You can do all sorts of things
by expressing your test scenarios using those five
building blocks, and also gives you a very nice way to introduce
code reusability patterns into your code base as well.
Thank you so much for such elaborate explanation about
screenplay pattern. I personally is the first time
for me to learn about this. I think the abstraction makes
sense, the five things that you mentioned.
Maybe if I can ask a little bit further why was it causing a lot
of stir in the testing community?
And then secondly, if I'm not mistaken, not just coming up
with this pattern right, you also contribute an open source
project called Serenity. Maybe if you can also give a
high level about this serenity library.
So I can chip in on this side of things because I've seen a lot
of conversation on the line when we first proposed or came out
with it started talking about screenplay.
A lot of people still think in terms of UI as a test automation
approach. So a lot of people are very
anchored on UI testing being the default way to test an
application and sort of goes back to the.
Very first implementations of test automation where it was
tools like Mercury and whatever it's called these days, and
where it was just record replay tools were so very clunky.
Basic Scripting. Literally Visual Basic Scripting
style scripting and tended to be.
Very ugly and unmaintainable from when you come in from this
perspective of an software engineering and you look trying
to make your code maintainable, you try to make it
understandable. You try to write code that when
you come back to it next week and you have to maintain it,
will change it. You can understand what it's
doing. I mean I have to be careful with
my own code because I I won't understand what I did this
afternoon. I'm not careful.
So looking at code later on, it's really important to make
sure that your code captures the intent.
And the traditional way that people tend to do these, even
one of the big things that people try to do is use the page
objects approach. The problem is most people that
we see, or I'd say most code that we see implementing the
page object approach becomes very heavyweight and convoluted
and complicated and hard to understand and hard to maintain.
So you have page objects that try and represent an entire web
page, which the name might. Indicate and that'll be 1000
lines long and have a gazillion selectors and then a whole lot
of logic and assertions inside it.
And do a whole lot of different stuff.
And that means that if a test changes for reason A and then
the test also needs to change for reason BA different test,
they'll both affect the same page object and you get churn
and instability. And you might have an
implementation for one test. And start in a particular way.
Then for another test you need to do something else and so it
can create code that's historically very hard to
maintain. And so basically the screenplay
approach really is a way of what happens when you apply OO and
functional programming principles.
Just clean coding principles to the problem of test automation.
And also you start to step away from the screen, step away from
the UI and think about. Hey, what is the business
actually trying to do here? What is the task?
And so I was talking to a team recently and using an approach
that recommended a while back. Basically having a very clean
separation of the description of your tests, the description of
what the business is trying to do, what the user is trying to
do and how you implement that. And so they had cucumber
scenarios where it was things like.
Given I want to purchase some books, when I add these books to
the shopping cart, then the tax should be calculated correctly
and then under the hood they had three different implementations
of that that they could hook in based on different tags and blue
code or whatnot. One implementation was through
the UI, another implementation was through the API, another
implementation was just with their pure domain logic, so
effectively unit tests. And those 3 implementations were
all driven by the same Cucumber scenarios and that under the
hood it was using actors but different tasks for those
actors. And so I think the domain model
was just a few unit tests, but the integration, the API calls
and the UI calls, the code read very similar, It was an actor
attempts to add these items to the shopping cart.
Except there are two slight variations.
One was going through the UI1 was going through the API.
And the cucumber layer never changed.
It was the same for both implementations under the hood
and the step definitions. The code was very similar,
slightly different because it uses different tasks, but very
relatable. You can read it and understand
what I was doing. The only real difference was in
the implementation of those tasks.
Now that sort of approach would be impossible to do.
If you start off with the mindset of I'm going to use Page
Objects, you can only have that, sort of.
Level of abstraction. When you think in terms of, I'm
going to model how my user interacts with the system in
business language. Then I'm going to decide what
the best way to implement that is.
What task do I need, does the business the user need to do?
And then how will those tasks actually be performed?
And the screenplay is not the only way of doing that, but it
is a very elegant way of doing that.
Wow, it sounds really powerful. So I think having a unified
cucumber feature test. And you can have a different
implementation details, so to speak, right.
I think that's really powerful. So yeah, going to the Serenity
part, right. So maybe if one of you can also
share what kind of cool project that you're doing with this
Serenity library. I can take the JavaScript part,
so I'm the maintainer of Serenity JS project.
So in terms of screenplay, just to maybe build on what John's
already said. But I think what's really,
really important about screenplay is that.
It helps you focus on the business language and business
domain and avoid the implementation details.
I mean, you think about it from the implementation perspective,
it's actually very, very important.
Your company, your business, the way your business processes
work, those tends to change much less frequently than the
software systems that we implement to support them,
right. Typically a bank would be doing
their business in a very similar way over the last 100 years,
right? Or an airline or an automotive
company, right? Unless you restart the pivot
step product every week or so, then typically the way the
vocabulary use the processes you use there, they tend to remain
fairly constant. It's just we constantly rebuild
the software systems that support them because new
technologies come along. So if you focus on expressing
those test scenarios from the perspective of the business, you
will see much less change in the overall flow of the scenarios,
probably a bit more change on the implementation side or the
integration side, so. Now going back to your question
Henry about 70 JS. There's a lot of interesting
things that the 70 JS team is doing right now with all the new
features. So recently we've introduced
Strengthy JS 3.0. Now one interesting feature.
Many of those, but the most interesting feature about Synt
JS is that introduces a universal web facade.
What it basically means is that you can create your automated
tests using strengthy JS, screenplay pattern, building
blocks, interactions and questions and you can then plug
any web integration tool it's going to be supported into your
tests. So you can run the exact same
scenario using Webdriver IO or playwright or Protractor or
puppeteer, which basically allows you to be completely
vendor agnostic. So should there be a better
integration tool in the future or you need to change from one
tool to another or you want to share your code across different
teams that use different tools? You can do it again thanks to
the abstraction and thanks for focusing on the business
vocabulary. One other interesting feature
that we've introduced recently is component testing.
So apart from doing N 20 web testing, I think we typically
use an acceptance testing framework for.
You can also do component testing now so you can test
individual react or view or spell or solid components using
string, JS and tray right? So you can design and develop
your low level interactions and questions.
Again scripting pattern, building blocks in a very
confined space of a single component and then plug them
into your end to end tests. Now what this allows you to do,
It allows you to share test automation code between
component teams and to end teams or product teams.
So for example if you have a component team building a design
system for a company building color and widgets and drop down
boxes and so on, they can provide you with test code that
interacts with those specific components.
And if you want to incorporate those components into a larger
system and write an end to end test and detect those
components, you can simply plug in this test alteration code
that's already been tested at the uni level into your end to
end tests. Now if you think about it, this
approach removes completely the problem of trying to figure out
what CSS selector should I use to interact with a specific
component or you don't care anymore.
You just take a library to interact with a date picker, you
don't care how the date picker is built.
This also allows your UI components team to have much
greater flexibility and freedom because they don't need to worry
about all the other teams. So if you think about it, the
great thing about being able to use the same patterns for
different kinds of testing, so end to end testing or acceptance
testing, performance testing, component testing, is that you
actually get to reuse test code across all those different test
suites so you don't have to do your work from scratch.
You don't have to start from scratch every single time.
Once you have a piece of code that works, you can just plug it
into another test suite and run it in a different context.
Now it's particularly interesting in the context of
component testing. So if you think about it, 1
popular pattern that's very often used across especially
large enterprises is that you would have component teams, UI
component teams that develop design systems or UI widgets for
other teams to use. So you might have a component
team that designs charts or dates because or drop down boxes
or buttons for all the other teams to use and other teams
would assemble those into your booking systems or trading
dashboards or other sorts of UI applications.
And this way by reusing the common UI components they ensure
a common look and feel of all those systems and they also
reduce the amount of rework that would be required.
Either wanted to build all this stuff from scratch themselves.
Now with the screenplay pattern and Serenity implementation of
the screenplay pattern, what you can do is you can share your
test codes the exact same way you can share your production
code. So again if we have our
components team that designs this, no date picker or a drop
down box or a button and so on. Apart from providing other teams
with this specific implementation of a component,
they can also provide those teams with test codes to
interact with those components. So if you have a date picker,
you might have a screenplay task to advance a month, or pick a
date or get the current date, enter a value and so on.
Another team using this specific widget could now incorporate the
widget into the application and incorporate the widget specific
test code into their N twin tests.
So again, if you have a trading dashboard for instance, where
you want to set a date of a trade, you don't have to think
about well how the date picker is structured, what are the HTML
tags I need to use, what are the CSS selectors?
Now you don't have to discover this whole thing from scratch
every single time. You don't have to handcraft it,
you can simply reuse the code that the team who developed the
widget has already provided you with.
If you think about it, this is a complete game changer in test
automation because it allows you to avoid rediscovery of basic
things like selectors and structures all over the
enterprise, something all over again, and then seeing all the
test suites break if someone changes even a slight thing in a
widget. It allows you to simply reuse
test code the same way you would reuse production code, and
completely addresses this whole class of problems around how do
I find the right selector for this widget?
Well, you don't care. You don't need to worry about
the selectors. You need to care about the
business scenario to be able to prove or verify that a trader
can book a trade, that a traveler can book a plane
ticket, that a shopper can now put a thing into their basket.
You don't need to care about the CSS selectors that you need to
use to interact the shopping basket.
Simply reuse the test code. So that's an absolutely amazing
thing and completely on game changer for many teams that have
been using particularly security JS.
And yeah, I'm actually looking forward to how it gets adopted
in the rest of the industry. Thank you so much for explaining
in depth about this Serenity JS, so I think I will put it in the
show notes for people who are interested in this screenplay
pattern. That's the first thing, right?
And especially if you have JavaScript project, feel free to
try to incorporate this Serenity JS.
I'm a big fan of Serenity JS. I'd use it for any sort of front
end project or even front end plus APIs.
If you've got a team who's familiar with TypeScript and
JavaScript, or if the testers are happy to learn that or
familiar with that, it really is a no brainer.
One of the things I find really cool about that and we'll talk
about Serenity BDD, but Serenity BDD is basically the Java.
Implementation of the screenplay pattern, and there's a lot of
other stuff that goes with it, but it's a similar concept in
the Java world. So often in teams that I coach,
what I'd try to suggest is if they're doing front end work or
UI work or if they come to with JavaScript and they should offer
Serenity JS because of just the reusable components and the way
it's fits nicely into the front end.
Build cycles and when they're working on either back end
components or sometimes end to end scenarios, if they're more
comfortable with the Java world, then that's where anything BDD
allows that as well. It integrates with API testing
and UI testing with Selenium and playwright and does all the nice
screenplay stuff so you can create those reusable business
components. But in both cases, what I really
find powerful sort of what? Yarn was alluding to is the idea
that what screenplay does it helps you step away from the
implementation, and we've actually used it.
One of the first big screenplay projects we did was with teams
where the testers were not particularly experienced with
either the domain or with even Java.
And so the way we got that team to sort of scale their
automation and to. Produce more automated tests
than anyone expected was by getting more experienced
developers or testers to write these tasks.
So write the task of place a trade or place a booking or
create a customer which actually interact with an API or a UI or
a screen or whatever they need to interact with and then other
testers who are maybe less experienced.
They can assemble those tasks just like Lego blocks, and reuse
those tasks without having to worry about what's selected to
use. And if they need to extend it or
add a new task, they can look at what's already been done and
start to learn how that works. But they've already got this set
of building blocks which is very focused not on how to click on a
button, but on how to interact with the business domain.
And that's something. You see a lot of the low code
tools these days. None of them go anywhere near
that. None of them are able to.
The best low code tool in my experience is when you create it
yourself and it maps to your domain.
All of the low code tools that we're seeing now there might be
exceptions, but I'm not sure how they could be, are very much
focused on just basically scripting out low level
interactions and. If you've got a good marketing
team, you might be able to sell that well because it makes it
feel easy to click on a button. But that's not where you get the
leverage. Where you get the leverage is
where you can reuse business components and model business
domains and actually understand that you are testing the
important stuff and scaling your tests.
So if you have an end to end flow where you're on board a
customer of a particular type and may.
Take them through a long Kyz process and get them out the
other side and make sure you've got heaps of systems that
interact together correctly and then you need to do another flow
with a different type of customer.
You can scale that really well because you have all these
reusable components. If you had to re script that,
even with low code tools that's still quite a headache.
When you actually start to do things at scale.
So I think that reusability, I mean, it does take some planning
and some thought and some design.
And that's where the BDD aspect tells, because it does make you
think about modeling the domain concepts.
That's where you get the scalability.
One more thing to add to that, so people often ask us so should
I choose Strengthy JS or should I choose Strengthy BDD?
Which one's better? I mean that's not really the
question that that's really important here.
So if you think about it now you can use either.
If your product is predominantly using a JVM language, now
certainty is a perfect choice. If it's not predominantly front
end or scripting languages, trying to just is great.
But it was interesting that both frameworks use the same
reporting engine. So in fact you would actually
use both Serenty JS and Serenty BD on the same project and many
teams do that. So now sometimes you might have
a huge mono repo and know some back end services using Serenty
BD. The front end was using Serenty
JS, but what you can do is you can actually make them produce
reports that get combined and the result in a unified leading
documentation of your entire system.
So we've come across cases like that, so we've made strength to
JS and strength to BD support this case as well.
Might have the favorite from working with more complex
requirements like finance, insurance and whatnot is feature
mapping, which I find a really nice way of mapping out.
User journeys, mapping out variations of what a user
actually does or how data gets transformed.
So it might be a user, it might also be a client record.
There are lots of different ways of looking at how a process
works, so feature mapping is very good at analyzing, walking
through, and visualizing how a process actually plays out and
what are the goals, what are the outcomes we're trying to
achieve. And a little bit more than say
story mapping which is much broader feature mapping is very
focused on a particular use case and how we look at the
variations around that. And the close second would be
example mapping, which is the sort of go to tool I find just
for getting clarity on what we're trying to do.
It's really very deceptively simple but very effective
technique for mapping out examples for identifying
examples and counter examples and hunting out new ones.
I think my other personal favorite is impact mapping.
And the reason why I would like the impact mapping is because it
helps you to create this very easy to see visual association
between the goal you're trying to accomplish, the actors that
can help you accomplish this goal or can hinder your
progress. It can help you understand the
behaviors you want to change, and form some hypothesis around
how you're going to change those behaviors.
What this allows us to do when using impact mapping tells us to
create a very good communication link between typically business
sponsors and the delivery team. Because business sponsors
understand the goals very well, they tend to have a very good
understanding of what is the audience they're trying to
address with whatever functionality they want to ship.
Now developers have a very good understanding of deliverables of
the features they can build. So what those two parties need
to figure out is how actually we can now create those
deliverables, how we can create software in order to change the
behavior of the groups that we want to affect in order to
accomplish our goal. So it's a really nice way to use
when you facilitate workshops between business and technical
people. Thanks for sharing some of these
techniques if people are interested to learn more.
I think the book covers some of these techniques in detail
right? Including examples and
fictitious stories how this can be applied.
And I think I would also suggest people reading a lot more about
these techniques because they can really make the
collaboration effort much more productive I would say and
effective. So one thing about BDD that I
always think people get confused where we should apply it right?
Because there is a unit test integration test.
API tests, UI tests and so many other tests, right?
Maybe a bit of wisdom here. Where should BDD be applied?
Can it be applied to all of them?
Or maybe yeah, based on your experience.
That's a really good question and I tend to answer it by
saying you want to use what I call the lowest responsible
level of automation. And what I mean by that is what
is the lowest possible level you can automate and still have
confidence that your feature has been implemented so BDD
transcends. End to end unit integration.
It can be any of those. Any test can be a BDD test.
A BDD test is simply a way of illustrating it that a
particular business requirement has been implemented and you
could do that with the unit test or you could do that with an end
to end test. If you take our example of for
the product catalog adding a new column, you might have a BDD
scenario where you say well. Given Sally is on the shopping
search page when she searches for some addresses and she
should see the following dresses with these color options and
that. Would that be a unit test?
Would it be a UI test? Would it be an end to end test?
An API test? It could be combinations of all
of those. Whatever, depending on your
architecture will be the most efficient way of testing that.
It could be any of those, so it's not a specific.
You don't implement BDD at a specific level, you implement at
the level which makes the most sense, and.
I think throughout that, one of the things I really like about
this BDD approach, so focusing on the observable behavior of
the piece of software we're actually interacting with, be
the system as a whole, being a component, being a unit or a
function and so on, is that you're focusing on the
observable outcome now. What you can also do with those
tests is you can now describe what should a given piece of
your software do. So what you're doing in those
tests you are not simply specifying what the system
already does, So what a component or a function already
does. You're specifying what it should
do. Now, why is this important?
This thing that we all suffer from, that's called confirmation
bias, which is basically the tendency to seek out and prefer
information that supports our preexisting beliefs.
One of the preexisting beliefs that all software developers
have is that now our software, the one we've just written, is
perfect, right? So if we write the software and
we write the test after that, what we tend to do is we tend to
confirm what we've already written.
In the test. So for example, I might have a
customer class. I create a test that now I can
set the address and I can get this sweet address from this
customer, which is great. So I have just now confirmed
that my code does what I told it to do.
Big achievements, right? Here's my gold medal.
But what is much more interesting was what are the
implications for the system of the customer changing their
address. What should happen in the system
when the customer changes the address?
Should their default settings change?
Where we make this change now with BDD, we're focusing on the
outcomes. So what we can do in our test
scenarios is rather than saying that my set address method
works, we're saying that when a customer changes their address,
their default tax rates should change to whatever state they
are in right now. Now this is much more useful
from the business perspective as well because now.
Know. Should this test fail you know
exactly what business functionality is affected.
You can know easily judge the impact on your business based on
the failure of the test. If you tell a business person
that, well, you know what? I have this unit test failing
that was testing just one method in a class that you've already
forgotten about. I mean, should we know?
Stop the release. The business person will be like
what? What are you talking about?
But now if you say, well actually with this those changes
we just introduced, we've affected the behavior of how we
calculate tax for our customers, well, this will get you a much
better answer from a business sponsor.
Around the risk readiness of the system.
Thanks for expanding all those, right.
So I think. I really like the confirmation
bias that you mentioned, right. So we developers, if we have to
incorporate new tests in our software, we always try to
confirm whatever that we have written right.
So not necessarily the quality would be much better.
So both of you are very experienced in BDD and software
testing in general. Even John mentioned in the
beginning you have worked with BDD for 20 years.
That's really a long time. Are there anti patterns, the
common anti patterns that you see maybe your favorite anti
patterns that you should advise us to avoid?
Maybe some of anti patterns here if you can mention there are so
many I'd say the biggest. One is what we said at the
start, treating BDD as a testing activity.
Because if BDD becomes considered as just another way
of writing tests, it short circuits the whole BDD
conversation process and drains a whole stack of most of its
value in fact, and also makes it actually harder to do what you
set out originally to do, which is write the test if all you
need to do is write is automate tests.
So you don't need a BDD tool. You can do that perfectly well
with any of the Java or JavaScript or Python testing
tools that already exist. You don't need BDD for that.
BDD is all about the collaboration.
So the biggest anti pattern is writing test scripts in Gherkin.
The second big anti pattern is at the other end of the scale
what we're saying earlier writing requirements in given,
when then. So using the given, when, then
notation as a way to write the requirements before you have the
conversation and not as a way to confirm the understanding after
the conversation. Because again that short
circuits the conversation that introduces the cognitive biases
that YA was talking about. But from the other direction,
that you assume that whoever wrote these wonderful given when
then statements knows what they're talking about.
So you don't question them, you assume that they're good.
Whereas if you come up with something you're much more
tentative and much more lightweight, you can have a much
more interesting conversation. So I'd say they're the two
biggest anti patterns to avoid from my perspective, yeah,
absolutely. I think the biggest one.
Just like John said, is using BDD tools to avoid
collaboration. That's kind of completely
missing the point. Now interestingly enough, this
typically happens out of good intentions actually.
So you're very often see people new to behavior, different
developments, like no product owners or business analysts.
They're trying to ease some of the burden put on the
development team, and they just try to write all the Cucumber
scenarios before giving them to the developers just so that they
can avoid all this additional work.
So they're trying to do the good thing, but the outcome is the
complete opposite. You might have testers write the
test scenarios in Cucumber so that they're easier to
understand to other. People involved in software
delivery, but then again they will write them typically from
the point of view of a tester. So the producer test scripts
full of implementation specific logic, talking about UI screens
and clicking on buttons and so on.
And what then typically happens is that now whoever reads this
scenario who is not a tester by profession, they'll just now get
bored halfway through if you're lucky and they just say, yeah,
okay fine, I trust you just go with the school.
So again, we're missing the whole collaboration aspect of
behavior driven. Development and I think the next
one is using UI to test everything.
I think that's one of the more common ones.
So very often people think of behavior driven development as
using Cucumber to drive CD numeral playwright or Cyprus or
whatever other web testing tool and uses that to verify your
system. And again, that's a
misconception, the whole idea of expressing your executable
specifications. In implementation agnostic
manner is so that you can automate them using the fastest,
most sensible interface that makes sense in this particular
context. That's what John was saying
earlier about the lowest responsible level.
If you can verify your business requirement at the unit level
just by interacting with classes and functions, awesome.
This way you can avoid incorporating all the
infrastructure in our databases, docker, containers, all the
other stuff just to verify. Something you can do at the unit
level, that's fine. BDD is not about using UI
automation tools to verify a fully assembled system.
It's about helping you collaborate with different
parties involved in software delivery to understand what's
actually required of your system, why you need to deliver
it, and then to help you find the best possible way to
automate your requirements. Either through the UI fine, but
typically you'll have other better ways to do it.
Thanks for sharing all these anti patterns I'm sure people.
Will be able to relate to most of them, if not all I would say.
And I think that's a really key learning to end this
conversation. So as we go to the end, I have
only one last question for each of you, which is what I call 3.
Technical leadership wisdom. So you can think of it like
advice that you want to give to us to learn from you.
So maybe one of you can share each your wisdom.
Yep, sure. So I did come up with three tips
that hopefully are useful. The first is that good practices
transcend languages and frameworks.
So the thing to remember is that whatever technology you choose,
it's less important than how you actually use it and how your
teams embrace it so you don't get too hung up on a particular
technology or tool. Focus on the outcomes you're
trying to achieve. The second one is think before
you code. The time that you invest in
understanding a problem and digging into the requirements
and challenging your own assumptions pays off multiple
times in preventing defects and waste.
And the third gem would be lead by example.
I find a lot of people will pontificate.
I think it's a word. I'll say what she should be
doing and tell people off because they're not doing the
best practices. Don't tell people what to do,
show them. And if you show that your own
commitment to quality and learning and collaboration, then
you've got a much better chance of getting your team to follow.
So maybe I'll just add one more to this list of.
Three, so that we have four. When trying to optimize software
delivery processes, I see many organizations, many teams look
at factors such as delivery speed.
So how quickly can we ship new feature to production?
However, what's much more important is whether those
features actually solve the business problems they've been
intended to solve. It's much more important to
focus on doing the right thing than doing the wrong thing
quickly. That's a perfect wisdom to end
our conversation so. Thank you so much, John and
Young for being here. If people want to connect with
you, learn more about all these great practices, right?
Is there a place where they can find both of you online?
LinkedIn is usually the best place to find me.
It's the easiest way to reach out and connect.
If you'd like to learn more about our work, just connect on
LinkedIn. That's probably.
Yeah, it's probably the easiest way.
Yeah, absolutely. Same here.
So if you'd like to connect with.
I'm Young Moloch. My colleague is John Ferguson
Smart. Should be easy to look up.
So yeah, hopefully we'll see you all online.
So thank you so much for your time.
I really learned a lot about BDD.
And generally good practice about software testing today.
Thank you. It's been a pleasure.
Thank you so much. Thank you for listening to this
episode and for staying. Right until the end.
If you highly enjoyed it, I would appreciate if you share it
with your friends and colleagues who you think would also benefit
from listening to this episode and if you're new to the
podcast. Make sure to subscribe and leave
me your valuable review and feedback.
It helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on
the episode page at Techly journal dot def website,
including the full transcript, interesting quotes, and links to
the resources mentioned from the conversation.
And lastly, make sure to subscribe to the show's mailing
list on Techly journal dot def to get notified for any future
episodes. Stay tuned for the next
Technically Juno episode, and until then, goodbye.