1
00:00:00,160 --> 00:00:03,200
Techly Journal has a mission to 
elevate the technical leadership

2
00:00:03,200 --> 00:00:06,920
and excellence of all engineers 
in collaboration with the one 

3
00:00:06,920 --> 00:00:10,040
and only Patrick KWA. 
I am excited to share that I'm 

4
00:00:10,040 --> 00:00:12,960
organizing 2 workshops in 
Singapore in early November 

5
00:00:12,960 --> 00:00:17,120
2023, The Technical Leadership 
Master Class and the Engineering

6
00:00:17,120 --> 00:00:20,240
Manager Essentials. 
You can find more information at

7
00:00:20,240 --> 00:00:24,120
techly journal dot def slash 
courses slash TL and Techly 

8
00:00:24,120 --> 00:00:28,510
journal dot deaf slash courses 
EM register early while the 

9
00:00:28,510 --> 00:00:31,310
early but discount is available.
See you there. 

10
00:00:31,670 --> 00:00:34,830
BDD is not about using UI 
automation tools to verify a 

11
00:00:34,830 --> 00:00:37,390
fully assembled system. 
It's about helping you 

12
00:00:37,390 --> 00:00:39,670
collaborate with different 
parties involved in software 

13
00:00:39,670 --> 00:00:42,430
delivery to understand what's 
actually required of your 

14
00:00:42,430 --> 00:00:45,870
system, why you need to deliver 
it, and then to help you find 

15
00:00:45,870 --> 00:00:48,590
the best possible way to 
automate your requirements. 

16
00:00:49,190 --> 00:00:51,870
Either As to the UI, fine, but 
typically you'll have other, 

17
00:00:51,910 --> 00:01:00,050
better ways to do it. 
Hey everyone, my name is Henry 

18
00:01:00,050 --> 00:01:04,209
Surya Virawan and you're 
listening to the Technical 

19
00:01:04,209 --> 00:01:07,370
Journal Podcast, the show where 
I'll be bringing you, the 

20
00:01:07,370 --> 00:01:10,490
greatest technical leaders, 
practitioners and thought 

21
00:01:10,490 --> 00:01:13,890
leaders in the industry to 
discuss about their journey, 

22
00:01:14,170 --> 00:01:18,650
ideas and practices that we all 
can learn and apply to build a 

23
00:01:18,650 --> 00:01:22,210
highly performing technical team
and to make an impact in your 

24
00:01:22,210 --> 00:01:25,410
personal work. 
So let's dive into our journal. 

25
00:01:30,520 --> 00:01:32,440
Hello again to all of you, my 
listeners. 

26
00:01:32,480 --> 00:01:35,360
Welcome back to the Techly 
Journal Podcast, the podcast 

27
00:01:35,360 --> 00:01:37,240
where you can learn about 
technical leadership and 

28
00:01:37,240 --> 00:01:40,520
excellence from my conversations
with great thought leaders in 

29
00:01:40,520 --> 00:01:43,000
the tech industry. 
If this is your first time 

30
00:01:43,000 --> 00:01:45,920
listening, please subscribe on 
your favorite podcast app. 

31
00:01:46,240 --> 00:01:48,880
You can also subscribe to Techly
Journal contents on various 

32
00:01:48,880 --> 00:01:51,480
social media, on LinkedIn, 
Twitter and Instagram. 

33
00:01:51,880 --> 00:01:55,160
And for video contents subscribe
on YouTube and TikTok. 

34
00:01:55,750 --> 00:01:58,630
And if you have been enjoying 
Technijunal, please support my 

35
00:01:58,630 --> 00:02:01,870
work by either buying me a 
coffee at technijunal dot deaf 

36
00:02:01,870 --> 00:02:05,910
slash tip or becoming a patron 
at technijunal dot deaf slash 

37
00:02:05,950 --> 00:02:10,590
patron. 
My guests for today's episode 

38
00:02:10,669 --> 00:02:13,150
are Jan Moloch and John Ferguson
Smart. 

39
00:02:13,590 --> 00:02:16,750
They are the co-authors of BDD 
in Action second edition. 

40
00:02:17,150 --> 00:02:20,030
In this episode we discussed 
Indepth Behavior Driven 

41
00:02:20,030 --> 00:02:22,590
development of BDD and its 
essentials. 

42
00:02:23,320 --> 00:02:27,040
Jan and John first began by 
introducing what BDD is, the 

43
00:02:27,040 --> 00:02:31,280
benefits of using BDD and the 
Gherkin language with its Given,

44
00:02:31,280 --> 00:02:34,520
When Then syntax. 
They gave advice on how to 

45
00:02:34,520 --> 00:02:38,160
introduce and apply BDD, 
especially for legacy software 

46
00:02:38,520 --> 00:02:41,760
and how to manage the BDD 
specifications effectively. 

47
00:02:42,600 --> 00:02:46,120
Jan and John then shared several
BDD techniques such as feature 

48
00:02:46,120 --> 00:02:50,350
mapping, example mapping, impact
mapping and went deep into the 

49
00:02:50,350 --> 00:02:53,310
Screenplay pattern and the 
Serenity projects they both 

50
00:02:53,310 --> 00:02:55,350
create to implement the 
screenplay pattern. 

51
00:02:56,110 --> 00:02:59,430
Towards the end, Jan and John 
shared the insights on which 

52
00:02:59,430 --> 00:03:03,030
testing layers we should apply 
BDD and some anti patterns we 

53
00:03:03,030 --> 00:03:05,670
should avoid. 
I hope you enjoy listening to 

54
00:03:05,670 --> 00:03:09,070
this episode and learn a lot 
about BDD and good practices for

55
00:03:09,070 --> 00:03:11,670
managing user requirements and 
automated testing. 

56
00:03:12,030 --> 00:03:14,790
And if you know someone who will
also benefit from this episode, 

57
00:03:15,150 --> 00:03:16,710
please help. 
Share it with your colleagues, 

58
00:03:16,710 --> 00:03:19,450
your friends and your 
communities and leave a 5 star 

59
00:03:19,450 --> 00:03:22,290
rating and review on Apple 
Podcasts and Spotify. 

60
00:03:22,850 --> 00:03:26,290
It will help me a lot in getting
more people discover and listen 

61
00:03:26,290 --> 00:03:28,770
to this podcast and I really 
appreciate it. 

62
00:03:29,490 --> 00:03:32,770
Let's go to my conversation with
Jan and John after quick words 

63
00:03:32,810 --> 00:03:35,770
from our sponsor. 
Are you looking for a new cool 

64
00:03:35,770 --> 00:03:38,410
swag? 
Technically, Juno now offers you

65
00:03:38,410 --> 00:03:40,570
some swags that you can purchase
online. 

66
00:03:41,010 --> 00:03:44,450
These swags are printed on 
demand based on your preference 

67
00:03:44,830 --> 00:03:47,390
and will be delivered safely to 
you all over the world. 

68
00:03:47,390 --> 00:03:50,750
Where shipping is available, 
check out all the cool swags 

69
00:03:50,750 --> 00:03:53,990
available by visiting Techlyjuno
dot dev shop. 

70
00:03:54,350 --> 00:03:57,430
And don't forget to brag 
yourself once you receive any of

71
00:03:57,430 --> 00:04:02,310
those swags. 
Hello everyone, Welcome back to 

72
00:04:02,310 --> 00:04:05,910
another exciting new episode of 
the Techlyjuno Podcast. 

73
00:04:06,390 --> 00:04:09,310
Today I have with me two guests 
in one time, right? 

74
00:04:09,310 --> 00:04:13,310
So they are the co-authors of a 
book titled BDD in Action. 

75
00:04:13,390 --> 00:04:16,470
So if you are into software 
testing and if you have heard 

76
00:04:16,470 --> 00:04:18,630
about Behavior Driven 
development today, we will be 

77
00:04:18,630 --> 00:04:21,870
discussing a lot about it. 
And this BDD in Action is 

78
00:04:21,870 --> 00:04:25,190
actually a second edition in 
extension to the 1st edition 

79
00:04:25,190 --> 00:04:28,430
which was published I think 
sometimes in 2014. 

80
00:04:28,790 --> 00:04:32,190
So John Smart was the first 
author of the book, and then in 

81
00:04:32,190 --> 00:04:34,830
the second edition he 
collaborated with Jan Moloch 

82
00:04:34,830 --> 00:04:36,730
here. 
To come up with the 2nd edition.

83
00:04:37,010 --> 00:04:39,930
So really looking forward to 
this conversation and learn a 

84
00:04:39,930 --> 00:04:42,370
lot about BDD and software 
testing in general. 

85
00:04:42,370 --> 00:04:45,530
So thanks for being here guys. 
It's a pleasure. 

86
00:04:45,850 --> 00:04:48,650
Thank you for inviting. 
Thank you for having us. 

87
00:04:49,690 --> 00:04:52,890
So Yan and John, I always like 
to ask my guests to introduce 

88
00:04:52,890 --> 00:04:55,490
themselves a little bit, maybe 
telling about career highlights 

89
00:04:55,490 --> 00:04:58,330
or any turning points. 
So maybe I'll leave it to either

90
00:04:58,330 --> 00:05:01,360
one of you to start first. 
Well, I can go first. 

91
00:05:01,360 --> 00:05:05,320
So I'm John Ferguson, Smart. 
I've been in software 

92
00:05:05,320 --> 00:05:09,560
development for more years than 
I can remember since the 90s. 

93
00:05:09,960 --> 00:05:12,560
So I've been doing Agile 
software development since the 

94
00:05:12,760 --> 00:05:16,800
late 90s, early 2000. 
I've done a bit of everything, 

95
00:05:16,800 --> 00:05:20,240
so development. 
I still do active development, 

96
00:05:20,640 --> 00:05:25,600
testing, project management, 
waterfall, agile, XP, the whole 

97
00:05:25,840 --> 00:05:31,860
whole range of things. 
In the 2000s, my role was very 

98
00:05:31,860 --> 00:05:35,300
technical and I always thought 
the requirements side of things 

99
00:05:35,300 --> 00:05:38,260
was a little bit intimidating. 
All this talking to people and 

100
00:05:38,260 --> 00:05:40,060
stuff as well. 
That was a little bit of a 

101
00:05:40,660 --> 00:05:42,980
challenge. 
So I gave myself the challenge 

102
00:05:42,980 --> 00:05:45,900
of actually getting into that 
and doing that a little bit 

103
00:05:45,900 --> 00:05:48,140
more. 
And that's where a lot of my 

104
00:05:48,140 --> 00:05:50,580
activity in the sort of BDD 
space emerged. 

105
00:05:50,580 --> 00:05:54,380
I started to get involved with 
people in these sort of Agile 

106
00:05:54,380 --> 00:05:59,370
and BDD communities in London. 
Quite a bit, The Dan N, Liz Keo,

107
00:05:59,810 --> 00:06:02,730
people like that who were very 
active. 

108
00:06:03,090 --> 00:06:06,090
Chris Matts was another one, 
very active in that area. 

109
00:06:06,290 --> 00:06:09,770
And so that's where my big 
interest in behavior driven 

110
00:06:09,770 --> 00:06:12,610
development really came from. 
But if you're talking about 

111
00:06:12,610 --> 00:06:16,210
highlights, actually one of the 
interesting highlights was I've 

112
00:06:16,250 --> 00:06:21,170
actually been doing BDD for well
over 20 years because one, there

113
00:06:21,170 --> 00:06:23,810
was this one time I was working 
with an insurance company in 

114
00:06:23,810 --> 00:06:27,540
Paris, France. 
And their problem was they 

115
00:06:27,540 --> 00:06:30,500
wanted to put an insurance 
application online, and their 

116
00:06:30,500 --> 00:06:36,260
problem was reproducing their 
mainframe insurance algorithm in

117
00:06:36,260 --> 00:06:39,340
Java. 
And they had like a gazillion 

118
00:06:39,740 --> 00:06:42,780
lots of rules that are all done 
in this really complicated Excel

119
00:06:42,780 --> 00:06:45,980
spreadsheet. 
So I had the idea of taking that

120
00:06:45,980 --> 00:06:48,700
Excel spreadsheet and actually 
saying, well, give me all the 

121
00:06:48,700 --> 00:06:51,420
examples that you use to test 
your Excel spreadsheet and we 

122
00:06:51,420 --> 00:06:53,940
use that to test the actual code
we write. 

123
00:06:54,580 --> 00:06:57,780
And that was effectively, we 
just read it through J units and

124
00:06:57,780 --> 00:07:00,980
produced a little report. 
And there was actually another 

125
00:07:00,980 --> 00:07:03,780
Excel spreadsheet, somewheres 
were green, somewheres were red.

126
00:07:03,780 --> 00:07:08,340
And that was the first 
executable specification with 

127
00:07:08,340 --> 00:07:11,020
collaboration with the business 
that they ever wrote. 

128
00:07:11,020 --> 00:07:14,260
And I thought that was such a 
wonderful technique that works 

129
00:07:14,260 --> 00:07:16,500
really, really well. 
I've been trying to do it ever 

130
00:07:16,500 --> 00:07:19,540
since because I really do think 
it is by far the most effective 

131
00:07:19,540 --> 00:07:22,580
way of so collaborating and 
delivering software that makes a

132
00:07:22,580 --> 00:07:24,220
difference that I've 
experienced. 

133
00:07:25,040 --> 00:07:27,400
Wow, that must be a very 
tremendous effort. 

134
00:07:27,480 --> 00:07:31,240
So I really congratulate you to 
have a success for that project.

135
00:07:31,520 --> 00:07:35,120
How about you, young? 
Oh, so my career journey 

136
00:07:35,120 --> 00:07:38,640
actually didn't start in finance
or banking, where I work right 

137
00:07:38,640 --> 00:07:39,800
now. 
It started in a complete 

138
00:07:39,840 --> 00:07:43,120
opposite of the spectrum. 
So it started in early 2000 in 

139
00:07:43,120 --> 00:07:45,720
the video games industry when I 
was back in Poland. 

140
00:07:46,200 --> 00:07:50,000
So I remember one of my first 
jobs I was actually working for 

141
00:07:50,000 --> 00:07:52,920
CD Project Thread, the studio 
behind the games like The 

142
00:07:52,920 --> 00:07:56,460
Witcher for example. 
I was the very first full time 

143
00:07:56,460 --> 00:08:00,060
web developer there and my job 
spec had one sentence and said, 

144
00:08:00,060 --> 00:08:02,420
well sort out everything around 
the Internet. 

145
00:08:02,980 --> 00:08:06,340
So, well, that's quite broad. 
Well, I asked my boss, well what

146
00:08:06,340 --> 00:08:09,340
exactly do you need? 
And he told me, well, what do 

147
00:08:09,340 --> 00:08:11,460
you think we need? 
So I said, well, we would 

148
00:08:11,460 --> 00:08:14,460
probably need a place for people
to exchange comments about the 

149
00:08:14,460 --> 00:08:15,660
game. 
We need to have a place to 

150
00:08:15,660 --> 00:08:18,180
publish the news about the game.
I said all those things and he 

151
00:08:18,180 --> 00:08:20,420
was like, well that's awesome, 
let's do it. 

152
00:08:20,420 --> 00:08:23,320
How can I help you so? 
Remember that that's my first 

153
00:08:23,320 --> 00:08:24,320
job. 
I was like, you know, in my 

154
00:08:24,360 --> 00:08:26,720
early 20s I had absolutely no 
idea what I was doing. 

155
00:08:26,960 --> 00:08:30,000
But what it really helped me to 
do is to actually have this 

156
00:08:30,120 --> 00:08:32,760
business perspective on 
software. 

157
00:08:33,159 --> 00:08:36,520
So how can I create software, 
how can I work with my team to 

158
00:08:36,520 --> 00:08:40,679
create software to support a 
then small company. 

159
00:08:41,520 --> 00:08:46,040
So I've been used now the things
I learned back there and try to 

160
00:08:46,040 --> 00:08:49,000
apply it to other industries. 
Now, later on, I moved from 

161
00:08:49,000 --> 00:08:52,380
Poland to the United Kingdom. 
And there was similar to John. 

162
00:08:52,380 --> 00:08:55,620
That's where I met many people 
who are no practitioners of 

163
00:08:55,660 --> 00:08:59,100
Extreme Programming, of Test 
Driven Development of BDD and so

164
00:08:59,100 --> 00:09:01,100
on. 
And one of the problems I was 

165
00:09:01,100 --> 00:09:04,420
trying to solve, I was trying to
find the ancestor was how do we 

166
00:09:04,420 --> 00:09:06,620
ultimate testing? 
Now I'm not sure. 

167
00:09:06,620 --> 00:09:09,380
If the audience knows about it. 
But one of the main problems in 

168
00:09:09,660 --> 00:09:12,820
one of the many challenges in 
video games development is how 

169
00:09:12,820 --> 00:09:16,300
do we actually test the games? 
If you have a like a real time 

170
00:09:16,300 --> 00:09:19,420
simulation, because that's 
really what a video game is, how

171
00:09:19,420 --> 00:09:22,820
do you make sure it works? 
So I tried to find answers to 

172
00:09:22,820 --> 00:09:25,300
that, and typically the answer I
would get as well. 

173
00:09:25,340 --> 00:09:27,660
It's not possible. 
That was just too hard. 

174
00:09:28,060 --> 00:09:30,540
And whenever I hear it's not 
possible, it's not too hard. 

175
00:09:30,780 --> 00:09:33,140
The first thing I do is I try to
figure out why it's not 

176
00:09:33,140 --> 00:09:34,860
possible. 
Then the second thing I do is 

177
00:09:34,860 --> 00:09:38,220
try to figure out how to do it. 
So I tried to answer this 

178
00:09:38,220 --> 00:09:39,660
question now across different 
industries. 

179
00:09:39,660 --> 00:09:42,340
So I worked in publishing, I 
worked in media. 

180
00:09:42,340 --> 00:09:44,260
I worked in broadcasting, I 
worked in finance. 

181
00:09:44,640 --> 00:09:47,280
And the one thing I actually 
realized is that whatever 

182
00:09:47,280 --> 00:09:50,280
company I joined or whatever 
client I worked with is very 

183
00:09:50,280 --> 00:09:51,920
often here that the testing is 
impossible. 

184
00:09:51,920 --> 00:09:54,880
It's very hard to do well. 
Why is that? 

185
00:09:55,240 --> 00:09:58,000
So many of those companies, what
they would do is they would hire

186
00:09:58,000 --> 00:10:00,640
manual testers to click through 
the scenarios and basically 

187
00:10:00,720 --> 00:10:03,120
confirm whatever developers have
already created. 

188
00:10:03,470 --> 00:10:06,030
Now what I realized is that, you
know, testing is difficult 

189
00:10:06,070 --> 00:10:09,350
because it's actually very hard 
to understand what is that we 

190
00:10:09,350 --> 00:10:12,550
actually trying to test. 
Why try to test how to set the 

191
00:10:12,550 --> 00:10:15,070
priorities, how to understand 
what parts of the system are 

192
00:10:15,070 --> 00:10:18,150
actually important? 
And turn out is that just in 

193
00:10:18,150 --> 00:10:21,150
video games there was the same 
case in financing insurance, in 

194
00:10:21,150 --> 00:10:23,790
banking, in broadcasting, every 
was the same case. 

195
00:10:24,110 --> 00:10:26,110
So then I started looking at two
ways actually. 

196
00:10:26,350 --> 00:10:29,350
Well, first automate my tests, 
then figure out how to gather 

197
00:10:29,350 --> 00:10:31,550
the requirements. 
Actually, how to understand what

198
00:10:31,550 --> 00:10:34,110
bit are important. 
And that's how I came across 

199
00:10:34,110 --> 00:10:35,710
Jones work around behavior 
development. 

200
00:10:35,710 --> 00:10:39,830
That's how I got to meet guys 
like the North and Lee Skio and 

201
00:10:40,030 --> 00:10:43,070
the rest of the London BDD and 
TTD crowd. 

202
00:10:43,350 --> 00:10:46,310
So that's how I actually got to 
connect all those different 

203
00:10:46,310 --> 00:10:47,830
dots. 
And actually, if you got in 

204
00:10:47,830 --> 00:10:51,030
order to avoid issues with 
manual testing, in order to 

205
00:10:51,030 --> 00:10:53,430
automate testing, well, you 
actually need to understand what

206
00:10:53,430 --> 00:10:55,630
is that you're trying to test, 
why you're trying to test it 

207
00:10:55,870 --> 00:10:57,070
now. 
To do that, you need to 

208
00:10:57,070 --> 00:10:59,660
understand your requirements. 
To understand your requirements,

209
00:10:59,660 --> 00:11:01,780
you need to speak with the 
business stakeholders, you need 

210
00:11:01,780 --> 00:11:04,300
to speak with your customers, 
you need to have ways to 

211
00:11:04,300 --> 00:11:08,340
actually gather and analyze 
feedback in very fast and 

212
00:11:08,340 --> 00:11:10,780
efficient ways. 
So that's how all those 

213
00:11:10,780 --> 00:11:13,980
different pieces of my career 
journey came together here in 

214
00:11:13,980 --> 00:11:16,450
London. 
Thanks for sharing your story. 

215
00:11:16,490 --> 00:11:19,490
I think throughout both of your 
career journey and highlights, I

216
00:11:19,490 --> 00:11:22,770
can tell that you guys deal a 
lot with software requirements 

217
00:11:22,810 --> 00:11:26,410
and testing, right? 
And the challenges how BDD later

218
00:11:26,410 --> 00:11:29,010
on can help in terms of doing 
software testing and also 

219
00:11:29,010 --> 00:11:31,690
gathering requirements. 
So let's just go straight into 

220
00:11:31,690 --> 00:11:33,610
BDD, right? 
So in the 1st place, maybe if 

221
00:11:33,610 --> 00:11:37,410
you can summarize what were the 
challenges before BDD was around

222
00:11:37,410 --> 00:11:39,010
right? 
What were the challenges that 

223
00:11:39,330 --> 00:11:42,210
probably was prominent in the 
software development world? 

224
00:11:42,810 --> 00:11:47,880
So from my perspective. 
BDD, I've heard it described by 

225
00:11:47,880 --> 00:11:50,320
one of the managers I've worked 
with us. 

226
00:11:50,680 --> 00:11:55,040
It's what makes you actually be 
agile, not just do agile. 

227
00:11:55,560 --> 00:12:00,440
And so BDD and Agile are very 
closely related. 

228
00:12:00,720 --> 00:12:03,360
That is all about solving that 
same problem. 

229
00:12:03,360 --> 00:12:05,240
It all comes down to the 
communication. 

230
00:12:05,640 --> 00:12:09,960
So we can code all we want, but 
coding is not really the aim of 

231
00:12:09,960 --> 00:12:11,560
the game. 
The aim of the game is to 

232
00:12:11,560 --> 00:12:15,360
deliver solutions that actually.
Solve problems that the business

233
00:12:15,360 --> 00:12:17,720
have. 
Enable them to do something that

234
00:12:17,720 --> 00:12:20,400
they couldn't do previously. 
Enable them to do something that

235
00:12:20,400 --> 00:12:22,280
they could do previously but 
better. 

236
00:12:22,720 --> 00:12:24,960
Prevent problems. 
Save money. 

237
00:12:24,960 --> 00:12:26,520
Or where. 
There are the four categories 

238
00:12:26,520 --> 00:12:28,880
that we know about how you can 
actually deliver value. 

239
00:12:28,920 --> 00:12:32,640
Chris Matt's 4 categories, if I 
recall correctly, how you can 

240
00:12:32,640 --> 00:12:34,680
actually deliver value and all 
of that. 

241
00:12:35,080 --> 00:12:39,040
The problem is it comes from 
understanding the requirements. 

242
00:12:39,040 --> 00:12:40,960
And what we've always found is 
that. 

243
00:12:41,470 --> 00:12:44,670
You can't just write down the 
requirements, or have someone 

244
00:12:44,670 --> 00:12:48,470
write down the requirements for 
you and expect to get value out 

245
00:12:48,470 --> 00:12:50,470
of them. 
There's always iterations, 

246
00:12:50,470 --> 00:12:56,230
there's always feedback cycles, 
and the aim of the game is to 

247
00:12:56,230 --> 00:12:58,510
actually reduce those feedback 
cycles. 

248
00:12:58,510 --> 00:12:59,750
And the waste that comes from 
that. 

249
00:12:59,750 --> 00:13:04,950
And before, well before the days
are sort of BVD, you would 

250
00:13:04,950 --> 00:13:08,670
inevitably have really long 
cycles where. 

251
00:13:09,060 --> 00:13:12,820
You'd have siloed processes. 
And even in allegedly agile 

252
00:13:12,820 --> 00:13:16,940
projects, you still get that 
siloed processes of BA's or 

253
00:13:16,940 --> 00:13:19,460
analysts or product owners 
right? 

254
00:13:19,460 --> 00:13:22,220
Requirements hand them off to 
the development team to build, 

255
00:13:22,620 --> 00:13:25,860
they build something, they hand 
that off to testers to test, and

256
00:13:25,860 --> 00:13:29,620
then they the testers. 
Or maybe they even also have a 

257
00:13:29,620 --> 00:13:35,300
UAT testing phase where users go
through and test things in their

258
00:13:35,300 --> 00:13:37,170
own way. 
And that's always a bit of a 

259
00:13:37,170 --> 00:13:39,370
surprise because they never told
you what they were going to 

260
00:13:39,370 --> 00:13:42,890
actually test all of that. 
Every stage gives you the 

261
00:13:42,890 --> 00:13:45,970
opportunity to lose information,
to make mistakes. 

262
00:13:45,970 --> 00:13:49,170
And so that's what the biggest 
challenges we're having before 

263
00:13:49,170 --> 00:13:51,850
BDD is getting that 
communication allied. 

264
00:13:52,450 --> 00:13:54,250
Yeah, I think that's quite a 
funny thing because now 

265
00:13:54,450 --> 00:13:57,370
typically when we think about 
software development, we focus 

266
00:13:57,450 --> 00:14:00,890
on things like the languages we 
use, the frameworks we use, or 

267
00:14:00,930 --> 00:14:02,450
the automation tools we use. 
But. 

268
00:14:03,170 --> 00:14:05,810
We kind of forget about the most
important bit, which is the 

269
00:14:05,970 --> 00:14:08,090
social aspect of creating 
software. 

270
00:14:08,490 --> 00:14:12,290
So PDD is one of those tools, 
Behavior Driven Development. 

271
00:14:12,290 --> 00:14:14,810
It's one of those tools that 
helps you to focus on the actual

272
00:14:14,890 --> 00:14:18,810
outcome that your software or 
your solution is supposed to 

273
00:14:19,290 --> 00:14:22,130
bring to the organization. 
Now, the interesting thing about

274
00:14:22,130 --> 00:14:26,410
it is that bringing the outcome 
doesn't necessarily need to 

275
00:14:26,410 --> 00:14:28,720
require software. 
So that's again one of the 

276
00:14:28,720 --> 00:14:30,960
things that software developers 
very often forget about. 

277
00:14:30,960 --> 00:14:34,200
If you think about it, I'm a 
software developer before I have

278
00:14:34,200 --> 00:14:36,280
to build software in order to 
exist, right? 

279
00:14:36,280 --> 00:14:38,080
And that's my job. 
That's my role in the system. 

280
00:14:39,200 --> 00:14:42,840
With BDD, what we can do is we 
can look at the outcomes that 

281
00:14:42,840 --> 00:14:46,200
our organization seeks to 
achieve and then perhaps we 

282
00:14:46,200 --> 00:14:49,640
could try and find solutions 
that don't require us to build 

283
00:14:49,640 --> 00:14:52,610
any software. 
Perhaps we can bring the same 

284
00:14:52,610 --> 00:14:55,170
outcome by improving the 
process, by speaking to another 

285
00:14:55,170 --> 00:14:57,730
person, by reusing the tools we 
already have. 

286
00:14:58,090 --> 00:15:01,450
Now, if we can accomplish the 
same outcome without building 

287
00:15:01,450 --> 00:15:04,210
additional software, well, then 
we won't have any additional 

288
00:15:04,210 --> 00:15:06,690
software to maintain and 
therefore we can further reduce 

289
00:15:06,690 --> 00:15:09,690
the costs. 
Thanks for the addition to that 

290
00:15:09,690 --> 00:15:12,330
important bit, right. 
So we don't always have to need 

291
00:15:12,330 --> 00:15:14,530
software to bring an outcome for
the business or the 

292
00:15:14,530 --> 00:15:17,240
organization. 
It could come in many different 

293
00:15:17,240 --> 00:15:18,720
shapes and forms, right? 
It could be process 

294
00:15:18,720 --> 00:15:22,000
improvements, maybe some kind of
prototypes, maybe some kind of a

295
00:15:22,000 --> 00:15:24,160
cheaper solution than writing 
software. 

296
00:15:24,680 --> 00:15:27,640
So let's go to probably the 
definition of BDD, right? 

297
00:15:27,640 --> 00:15:30,800
So for people who are new to 
BDD, I also heard people 

298
00:15:30,800 --> 00:15:33,640
sometimes mistaken BDD with just
the Gherkin, right? 

299
00:15:33,640 --> 00:15:37,800
The Given when then. 
Some people also refer to ATDD 

300
00:15:37,880 --> 00:15:39,760
Acceptance Test Driven 
Development. 

301
00:15:40,310 --> 00:15:42,630
Also people are saying a 
specification by example. 

302
00:15:42,630 --> 00:15:44,070
There are so many different 
terms. 

303
00:15:44,310 --> 00:15:48,550
Maybe if you can help to define 
first what is BDD and how does 

304
00:15:48,550 --> 00:15:51,030
it compare with all these 
different terms that are 

305
00:15:51,030 --> 00:15:52,710
available out there in the 
industry. 

306
00:15:53,430 --> 00:15:58,230
So Behavior Driven Development 
is a collaboration approach from

307
00:15:58,230 --> 00:16:01,030
my perspective. 
It's not a particular tool set 

308
00:16:01,030 --> 00:16:03,910
or not a particular. 
Well, it is a methodology, but 

309
00:16:03,910 --> 00:16:06,670
it's not related to a particular
language or tool set or. 

310
00:16:07,070 --> 00:16:09,430
Testing approach. 
It's definitely not about test 

311
00:16:09,430 --> 00:16:13,630
automation and it does encompass
all of those other aspects 

312
00:16:13,630 --> 00:16:15,910
nowadays. 
I mean, it's a concept that's 

313
00:16:15,910 --> 00:16:17,670
been developed in different 
ways. 

314
00:16:17,670 --> 00:16:22,670
Back in the noughties we have 
fitness, we'd call that a TDD 

315
00:16:22,670 --> 00:16:26,030
because we'd try and define the 
acceptance tests first, just 

316
00:16:26,030 --> 00:16:29,390
like we're doing TDD and we'd 
try and write them in a business

317
00:16:29,430 --> 00:16:33,030
readable format. 
Specification by example was 

318
00:16:33,030 --> 00:16:36,930
Guico and Six. 
Book which described that same 

319
00:16:36,930 --> 00:16:39,810
approach, Behavior Driven 
Development was originally 

320
00:16:39,810 --> 00:16:44,610
coined by Dan North as a way to 
explain Test Driven Development.

321
00:16:44,610 --> 00:16:49,010
But with the work of Chris Matts
and Liz Keo and other people in 

322
00:16:49,010 --> 00:16:53,290
that community, it fairly 
rapidly expanded into being 

323
00:16:53,610 --> 00:16:57,450
applied to analysis. 
So we often we see BVD extends 

324
00:16:57,450 --> 00:17:01,370
from TVD, now it does it. 
BVD is a totally much broader 

325
00:17:01,370 --> 00:17:03,530
concept now. 
It's the collaboration. 

326
00:17:04,119 --> 00:17:09,319
Process where we involve 
business, users, developers, 

327
00:17:09,319 --> 00:17:13,040
testers, everyone to have 
conversations around the 

328
00:17:13,040 --> 00:17:16,359
requirements in BDD. 
One of the concrete things that 

329
00:17:16,359 --> 00:17:19,800
we use, one of the really 
characteristic aspects of BDD, 

330
00:17:19,800 --> 00:17:23,880
is that we use examples a lot. 
So rather than just writing 

331
00:17:23,880 --> 00:17:26,839
general specifications, we 
describe everything in terms of 

332
00:17:26,839 --> 00:17:30,220
examples. 
And we use those examples to 

333
00:17:30,220 --> 00:17:33,380
drill into the details and 
challenge the assumptions and 

334
00:17:33,380 --> 00:17:36,220
challenge our mental model of 
what a requirement actually is 

335
00:17:36,220 --> 00:17:39,060
about. 
So that using examples and 

336
00:17:39,060 --> 00:17:43,100
counter examples and telling 
concrete stories is a much 

337
00:17:43,100 --> 00:17:45,620
better way of getting the team 
involved and engaged than 

338
00:17:45,620 --> 00:17:48,780
there's a more traditional 
requirements writing approaches 

339
00:17:48,780 --> 00:17:52,260
and even just the classic news 
stories which can very quickly 

340
00:17:52,260 --> 00:17:54,420
become just a proxy for 
requirements. 

341
00:17:55,050 --> 00:17:58,770
Now the automation aspect. 
BDD is not about automation. 

342
00:17:58,770 --> 00:18:00,690
Cucumber is not an automation 
tool. 

343
00:18:00,930 --> 00:18:03,490
We'll test automation tool. 
We're not in the business of 

344
00:18:03,490 --> 00:18:06,890
automating test cases. 
What we're trying to do is 

345
00:18:06,890 --> 00:18:10,290
define the requirements in a 
format that can give us fast 

346
00:18:10,290 --> 00:18:12,490
feedback on whether they've been
implemented. 

347
00:18:12,810 --> 00:18:15,530
Now it turns out that a really 
effective way of getting that 

348
00:18:15,530 --> 00:18:17,530
fast feedback is to automate 
them. 

349
00:18:17,930 --> 00:18:21,640
So automate the requirements. 
It's using tools like Cucumber. 

350
00:18:21,640 --> 00:18:24,440
Now tomorrow, if we get a tool 
that's better than Cucumber, we 

351
00:18:24,440 --> 00:18:26,800
can use a different tool. 
We'll still be doing BVD. 

352
00:18:27,160 --> 00:18:29,080
It's not related to a particular
tool. 

353
00:18:29,520 --> 00:18:33,560
So Gherkin is the Given, When 
Then language that's used in 

354
00:18:33,560 --> 00:18:38,000
tools like Cucumber and Spectlow
and Behave and quite a few 

355
00:18:38,000 --> 00:18:40,430
others. 
And it's one of the more common 

356
00:18:40,430 --> 00:18:42,590
ways of doing BDD. 
But it's not the only way. 

357
00:18:42,590 --> 00:18:47,110
We can also do BDD, express our 
requirements and write them very

358
00:18:47,110 --> 00:18:49,950
well just in plain JavaScript or
Java or Python. 

359
00:18:50,430 --> 00:18:55,590
And if we write our scenarios, 
our examples in a business 

360
00:18:55,590 --> 00:18:59,950
readable language, and if we can
produce reports that reflect 

361
00:18:59,950 --> 00:19:03,110
that business readable language,
then that's BDD as well. 

362
00:19:03,600 --> 00:19:06,880
So I'll tell you that in a 
nutshell is sort of what BDD is 

363
00:19:06,880 --> 00:19:10,760
all about and it is a very broad
definition, but there is a lot 

364
00:19:10,760 --> 00:19:12,960
to it. 
Maybe one thing I would like to 

365
00:19:13,040 --> 00:19:18,320
add is that what PD helps you 
with is helping to avoid things 

366
00:19:18,320 --> 00:19:23,320
like scope creep, so focusing 
your team on outcomes, so 

367
00:19:23,320 --> 00:19:25,640
focusing on the conversation 
around outcomes. 

368
00:19:25,640 --> 00:19:27,960
So what is that our software 
system? 

369
00:19:27,960 --> 00:19:30,240
What is that our solution is 
supposed to bring to the 

370
00:19:30,240 --> 00:19:32,860
organization? 
What does does several 

371
00:19:32,860 --> 00:19:35,580
interesting things. 
So firstly, we talked a lot 

372
00:19:35,580 --> 00:19:38,500
about our collaboration and 
conversations and so on what 

373
00:19:38,500 --> 00:19:40,500
many people might hear. 
Well, Oh my God, we're just 

374
00:19:40,500 --> 00:19:42,420
going to have more meetings. 
No, no, not at all. 

375
00:19:42,780 --> 00:19:46,460
What we mean is that what we're 
doing with BDD is we're helping 

376
00:19:46,460 --> 00:19:50,780
team to start having informed 
conversations on focused 

377
00:19:50,780 --> 00:19:54,140
conversations around specific 
outcomes they were trying to 

378
00:19:54,140 --> 00:19:56,420
accomplish and it was just not 
any random chit chat. 

379
00:19:56,860 --> 00:20:00,380
So we are trying to focus on the
outcomes because focusing on the

380
00:20:00,380 --> 00:20:04,060
outcomes helps us find more 
precise solutions to the 

381
00:20:04,060 --> 00:20:06,940
problems we're trying to solve. 
We are not just shipping 

382
00:20:06,940 --> 00:20:10,180
features for the sake of 
shipping features, we want to 

383
00:20:10,180 --> 00:20:13,500
solve a specific problem. 
Now this focus also helps us to 

384
00:20:13,500 --> 00:20:15,420
avoid scope creep, as I 
mentioned earlier. 

385
00:20:15,900 --> 00:20:19,300
Now the idea here is that you 
know, if you know that your goal

386
00:20:19,340 --> 00:20:22,580
is to, I know, increase the 
number of conversions on your 

387
00:20:22,580 --> 00:20:24,900
homepage by what, about 20%? 
Nobody. 

388
00:20:25,310 --> 00:20:28,110
By some time, well then you are 
trying to focus on delivering 

389
00:20:28,110 --> 00:20:31,350
those features that help you to 
accomplish this specific goal. 

390
00:20:31,550 --> 00:20:34,670
Now this helps you to avoid 
having to ship any other 

391
00:20:34,670 --> 00:20:36,390
features that don't support this
goal. 

392
00:20:36,950 --> 00:20:40,350
Now what this focus also gives 
you is also gives you an 

393
00:20:40,350 --> 00:20:42,550
opportunity to improve the 
overall quality of your 

394
00:20:42,550 --> 00:20:45,270
software. 
So again, not only we can turn 

395
00:20:45,270 --> 00:20:48,310
those requirements, those 
scalable specifications into 

396
00:20:48,310 --> 00:20:52,050
automated tests by reducing the 
scope and focusing only on those

397
00:20:52,050 --> 00:20:56,130
things that matter, it's easier 
for us to ensure the quality of 

398
00:20:56,130 --> 00:20:58,770
the software we deliver simply 
because we have less of it to 

399
00:20:58,770 --> 00:21:01,810
deliver in the 1st place and 
what we deliver is of higher 

400
00:21:01,810 --> 00:21:03,930
value. 
So again, we're focusing on 

401
00:21:04,210 --> 00:21:08,530
delivering high value software 
and making sure that is actually

402
00:21:08,570 --> 00:21:11,530
the software itself is of high 
quality as well, not just 

403
00:21:11,530 --> 00:21:15,340
sharing more and more features. 
There are many other interesting

404
00:21:15,380 --> 00:21:19,220
outcomes of this approach by 
again focusing scope, improving 

405
00:21:19,220 --> 00:21:22,660
quality, improving the value of 
software we develop and deliver.

406
00:21:22,900 --> 00:21:25,540
We also improve things like 
developer happiness. 

407
00:21:25,580 --> 00:21:28,900
Because suddenly now that you 
have conversations with your 

408
00:21:28,900 --> 00:21:30,580
business sponsors, you have 
conversations with your 

409
00:21:30,580 --> 00:21:34,100
customers, you understand what 
is that you're trying to solve 

410
00:21:34,100 --> 00:21:35,300
now, why you're trying to solve 
it. 

411
00:21:35,300 --> 00:21:38,020
You actually have a mental image
of the person you're actually 

412
00:21:38,020 --> 00:21:42,110
delivering the solution to. 
It's much easier to see how your

413
00:21:42,110 --> 00:21:44,910
work is worthwhile. 
It's easier to see why you're 

414
00:21:44,910 --> 00:21:48,110
actually trying to do it now. 
This again improves developer 

415
00:21:48,110 --> 00:21:50,630
morale, improves developer 
happiness, increases developer 

416
00:21:50,630 --> 00:21:53,350
productivity, and so on. 
So it's actually quite 

417
00:21:53,390 --> 00:21:56,990
interesting how many positive 
effects that team can see by 

418
00:21:57,190 --> 00:22:01,310
doing things like focusing your 
work on the outcomes that you 

419
00:22:01,310 --> 00:22:02,950
are supposed to bring to your 
organization. 

420
00:22:04,000 --> 00:22:06,800
Thanks for highlighting the 
important aspects of BDD. 

421
00:22:06,840 --> 00:22:09,640
I think the first thing I heard 
very clearly from John is that 

422
00:22:09,640 --> 00:22:12,520
BDD is not automation only, 
right? 

423
00:22:12,520 --> 00:22:15,320
It's not software testing only. 
The first is about collaborative

424
00:22:15,320 --> 00:22:19,600
approach that focuses a lot on 
conversations, examples, right 

425
00:22:20,000 --> 00:22:23,280
and also outcomes like Yan also 
extended in the later part. 

426
00:22:23,710 --> 00:22:25,470
So I really love that 
explanation. 

427
00:22:25,470 --> 00:22:28,950
So for people who still think 
BDD is just another tools for 

428
00:22:28,950 --> 00:22:32,070
automation to make your software
testing much better, I think it 

429
00:22:32,070 --> 00:22:36,030
is more than that which speaks 
to the next topic that I'd like 

430
00:22:36,030 --> 00:22:38,510
to ask you guys. 
What do you think are some of 

431
00:22:38,510 --> 00:22:41,230
the benefits? 
If you can summarize that BDD 

432
00:22:41,230 --> 00:22:43,710
offers for people to give it a 
try? 

433
00:22:43,910 --> 00:22:47,590
If they don't have the time yet 
to try BDD, why they should 

434
00:22:47,590 --> 00:22:50,670
consider applying BDD now in 
their software development 

435
00:22:50,670 --> 00:22:53,430
practices? 
From my perspective, and this is

436
00:22:53,430 --> 00:22:56,110
what I see on the ground, it's a
good question because you do 

437
00:22:56,110 --> 00:22:58,830
need to know why you're 
introducing any technique and 

438
00:22:58,830 --> 00:23:01,550
what you're going to measure it 
on and whether it gives you the 

439
00:23:01,550 --> 00:23:03,830
outcomes, because that will tell
you whether you're actually 

440
00:23:04,230 --> 00:23:06,190
implementing it effectively or 
not. 

441
00:23:06,310 --> 00:23:09,870
And there are two levels of 
outcomes that I see. 

442
00:23:09,870 --> 00:23:14,390
There's what you might call the 
proxy outcomes, which are easier

443
00:23:14,390 --> 00:23:17,110
to spot, easier to see straight 
away. 

444
00:23:17,550 --> 00:23:19,630
And then there are the longer 
term outcomes which was what 

445
00:23:19,630 --> 00:23:22,750
you're really trying to achieve,
the sort of proxy or short term 

446
00:23:22,750 --> 00:23:26,630
outcomes because of the nature 
of the collaborative nature of 

447
00:23:26,630 --> 00:23:30,230
BDD and the fact that you really
do build up a shared 

448
00:23:30,230 --> 00:23:33,190
understanding within the team of
what you're trying to do, it 

449
00:23:33,190 --> 00:23:36,350
tends to reduce the number of 
defects dramatically. 

450
00:23:36,870 --> 00:23:40,110
So I see typically, and this is 
not talking about automation, 

451
00:23:40,110 --> 00:23:43,750
just the fact that you 
collaborate effectively reduces 

452
00:23:44,030 --> 00:23:46,790
a typical defect rate by seventy
8090%. 

453
00:23:46,790 --> 00:23:48,570
You just. 
Don't get defects into 

454
00:23:48,570 --> 00:23:52,450
production a lot of times 
because you get a much deeper 

455
00:23:52,450 --> 00:23:55,890
understanding and you've got the
opportunity to ask questions and

456
00:23:55,890 --> 00:23:59,570
people do ask questions. 
Now that assumes that you are 

457
00:23:59,570 --> 00:24:01,610
actually doing the collaboration
correctly. 

458
00:24:01,650 --> 00:24:04,850
If you're just writing given 
when, Then statements in your 

459
00:24:04,850 --> 00:24:08,770
test cases and calling it DVD, 
you won't get those benefits and

460
00:24:08,770 --> 00:24:10,130
you'll wonder why it doesn't 
work. 

461
00:24:10,130 --> 00:24:12,730
But if you do the collaboration 
and then think about how to 

462
00:24:12,730 --> 00:24:15,490
automate, you will get those 
benefits. 

463
00:24:16,100 --> 00:24:19,700
The automation BDD is a really 
effective way of doing 

464
00:24:19,940 --> 00:24:22,340
automation. 
So I find it when you do it well

465
00:24:22,340 --> 00:24:26,340
and combine it with TDD you can 
do a really nuanced level of 

466
00:24:26,340 --> 00:24:30,700
automation and get a lot of bang
for your buck for the amount of 

467
00:24:30,700 --> 00:24:33,900
automation effort that you do. 
So it really helps you get a 

468
00:24:33,900 --> 00:24:36,980
laser focus on what you should 
automate, why you should 

469
00:24:36,980 --> 00:24:38,780
automate, and where you should 
automate. 

470
00:24:39,180 --> 00:24:41,540
And so that's a good practical 
benefit. 

471
00:24:41,540 --> 00:24:44,500
I find there's also a longer 
term benefit. 

472
00:24:44,500 --> 00:24:46,800
Is that. 
Because you're having these 

473
00:24:46,800 --> 00:24:49,360
conversations and this applies, 
you want to be having 

474
00:24:49,360 --> 00:24:52,120
conversations not just at the 
story level, but also at your 

475
00:24:52,120 --> 00:24:55,720
features and epics and then 
coming up with examples of user 

476
00:24:55,720 --> 00:24:58,760
journeys and use cases at the 
epic level, so you can 

477
00:24:58,920 --> 00:25:01,360
understand what they're about 
and where the value is coming 

478
00:25:01,360 --> 00:25:03,600
from. 
And that helps you to be more 

479
00:25:03,600 --> 00:25:07,840
confident in delivering value, 
that actually delivering things 

480
00:25:07,840 --> 00:25:10,360
that make a difference to make 
an impact. 

481
00:25:10,680 --> 00:25:14,800
So that's a really important 
longer term benefit. 

482
00:25:15,470 --> 00:25:18,470
And the third big benefit that I
see and which is a little bit 

483
00:25:18,470 --> 00:25:22,110
less tangible, but as what a lot
of people report to me and what 

484
00:25:22,110 --> 00:25:25,750
I see in the teams that I work 
with is that you get the teams 

485
00:25:25,750 --> 00:25:28,630
which are much more engaged. 
So team members tend to be much 

486
00:25:28,630 --> 00:25:31,550
more engaged and creative 
because they know what they're 

487
00:25:31,550 --> 00:25:34,190
contributing to and they have a 
sense of mission and the sense 

488
00:25:34,230 --> 00:25:36,430
of ownership of the problems 
they're solving. 

489
00:25:36,790 --> 00:25:39,390
Much more so than the 
traditional siloed approach 

490
00:25:39,390 --> 00:25:43,350
where often development activity
is basically implement this 

491
00:25:43,350 --> 00:25:45,550
JIRA. 
Without really understanding the

492
00:25:45,550 --> 00:25:49,070
bigger picture, very much so. 
The teams do get much more 

493
00:25:49,070 --> 00:25:52,350
engaged and that leads to some 
better productivity and more 

494
00:25:52,350 --> 00:25:55,550
creative outcomes. 
Yeah, I think one of the things 

495
00:25:55,550 --> 00:25:58,910
that John mentioned, they really
deserve to be highlighted even 

496
00:25:58,910 --> 00:26:00,670
more. 
I mean, if you think about it, 

497
00:26:00,670 --> 00:26:03,870
according to various scientific 
research done over the last 

498
00:26:03,870 --> 00:26:08,950
couple of decades, it turns out 
that between I think 40 to 80% 

499
00:26:08,950 --> 00:26:12,630
of all software defects actually
come down to issues with 

500
00:26:12,630 --> 00:26:16,470
requirements, issues we've 
misunderstood or perhaps no 

501
00:26:16,470 --> 00:26:19,950
miscommunicated requirements. 
Now you asked about the 

502
00:26:19,950 --> 00:26:23,910
benefits, Henry. 
So if in your audience we have 

503
00:26:23,910 --> 00:26:26,990
listeners who are on teams that 
suffer from issues with 

504
00:26:26,990 --> 00:26:29,710
production defects, issues with 
defects in their software, if 

505
00:26:29,710 --> 00:26:33,230
there was one thing for you to 
improve, think about what can 

506
00:26:33,230 --> 00:26:36,070
you improve around your 
requirements, around how your 

507
00:26:36,070 --> 00:26:38,910
development team collaborates 
with the business, with testing,

508
00:26:38,910 --> 00:26:41,110
if you have one, with OPS teams,
and so on. 

509
00:26:41,570 --> 00:26:43,770
Think about improving how we 
collaborate around the 

510
00:26:43,770 --> 00:26:46,930
requirements, because issues 
with requirements cause most 

511
00:26:46,970 --> 00:26:49,570
issues with your software, most 
probably. 

512
00:26:49,850 --> 00:26:53,450
So by addressing issues with 
requirements, you are more 

513
00:26:53,450 --> 00:26:57,370
likely to improve the quality of
your software than by focusing 

514
00:26:57,370 --> 00:27:00,450
issues with, let's say, coding 
errors, which are much less 

515
00:27:00,450 --> 00:27:02,410
frequent than issues with 
requirements. 

516
00:27:03,130 --> 00:27:05,370
Well, thanks for the plug. 
I think I remember this kind of 

517
00:27:05,370 --> 00:27:08,370
research as well. 
And I also know that rework is 

518
00:27:08,370 --> 00:27:11,530
also something due to the 
miscommunication or maybe the 

519
00:27:11,610 --> 00:27:13,210
requirements not captured 
properly. 

520
00:27:13,570 --> 00:27:15,690
So I think yeah, if software 
engineering team wants to 

521
00:27:15,690 --> 00:27:18,770
improve some parts of their 
productivity and effectiveness, 

522
00:27:18,770 --> 00:27:21,970
probably requirements is 1 big 
area where it will bring a lot 

523
00:27:21,970 --> 00:27:24,860
of impact. 
So thank you for explaining some

524
00:27:24,860 --> 00:27:26,860
of these benefits. 
I really love that John 

525
00:27:26,860 --> 00:27:29,820
mentioned about this increased 
engagement from not just 

526
00:27:29,820 --> 00:27:32,020
engineers, probably it's the 
whole team, right, because they 

527
00:27:32,020 --> 00:27:35,620
are so collaborative and trying 
to come up with a better way of 

528
00:27:35,660 --> 00:27:39,140
approaching the problem and 
achieving the target outcomes. 

529
00:27:39,660 --> 00:27:43,500
So talking about BDD, I think we
talked about it earlier just now

530
00:27:43,500 --> 00:27:45,940
about Gherkin, right. 
I think talking about BDD, we 

531
00:27:45,940 --> 00:27:48,020
have to cover a little bit about
Gherkin. 

532
00:27:48,380 --> 00:27:50,940
So what is this Gherkin? 
Why the name is so funny? 

533
00:27:50,980 --> 00:27:53,360
And. 
What is the essence of Gherkin 

534
00:27:53,360 --> 00:27:56,160
anyway? 
Gherkin is a small cucumber, 

535
00:27:56,440 --> 00:27:59,360
Pickled cucumber kind of. 
It's in that family of 

536
00:27:59,440 --> 00:28:02,480
vegetables. 
And so there's a relationship 

537
00:28:02,480 --> 00:28:05,240
between cucumber the tool and 
Gherkin the language. 

538
00:28:05,240 --> 00:28:09,160
So Gherkin is the given when 
then notation that we use. 

539
00:28:09,560 --> 00:28:13,680
So Dan N was originally at the 
origin of that where coming up 

540
00:28:13,680 --> 00:28:17,160
with that notation and then 
Chris Matt observed that it was 

541
00:28:17,160 --> 00:28:20,360
a good way of describing 
business expectations as well. 

542
00:28:20,840 --> 00:28:24,360
But a lot of people misinterpret
it by a lot of people. 

543
00:28:24,720 --> 00:28:27,720
They don't know how to use it, 
basically use it incorrectly. 

544
00:28:28,240 --> 00:28:31,080
And it's what happens when we 
see test groups written in this 

545
00:28:31,080 --> 00:28:33,400
given, when then format given 
when. 

546
00:28:33,400 --> 00:28:36,800
That format that can be crystal 
clear, can be a really nice, 

547
00:28:36,800 --> 00:28:40,320
precise, readable way of writing
your requirements, or it can be 

548
00:28:40,320 --> 00:28:42,520
a horrible mess. 
It's like anything it can be 

549
00:28:42,640 --> 00:28:45,360
depending on whether it's well 
written or not. 

550
00:28:45,360 --> 00:28:48,040
So well written it will have 
value or not. 

551
00:28:48,580 --> 00:28:52,860
So there is quite a skill to 
writing a clean, effective, 

552
00:28:52,860 --> 00:28:56,620
concise, given when then 
statement that really reflects a

553
00:28:56,620 --> 00:28:59,340
business rule and really 
reflects a business 

554
00:28:59,340 --> 00:29:01,860
requirements. 
And so it does take some 

555
00:29:01,860 --> 00:29:04,260
practice and some effort to get 
that right to start with. 

556
00:29:04,260 --> 00:29:07,780
But when you do, what happens is
you end up with this, what we 

557
00:29:07,780 --> 00:29:12,500
call a domain specific language,
which is really the heart of the

558
00:29:12,500 --> 00:29:16,260
collaboration for a team around 
a set of requirements. 

559
00:29:16,260 --> 00:29:18,020
And that's where I've had 
projects. 

560
00:29:18,350 --> 00:29:22,150
Where we've defined this sort of
domain specific language for a 

561
00:29:22,150 --> 00:29:26,670
particular part of a project and
it's allowed business to write 

562
00:29:26,670 --> 00:29:30,390
their business rules and express
their business rules with such 

563
00:29:30,390 --> 00:29:33,630
clarity that there's no other 
automation that needs to be 

564
00:29:33,630 --> 00:29:35,270
done. 
They just need to express a new 

565
00:29:35,270 --> 00:29:38,630
business rule using their 
existing language and everyone 

566
00:29:38,630 --> 00:29:41,230
will understand what it needs to
do or what needs to be done. 

567
00:29:41,720 --> 00:29:44,440
That doesn't happen in all 
projects or in all cases and 

568
00:29:44,440 --> 00:29:48,040
with all situations. 
But when you aim to do that, you

569
00:29:48,040 --> 00:29:52,040
can come up with that language 
and use it as a really central 

570
00:29:52,040 --> 00:29:55,720
part of your requirements 
definition process. 

571
00:29:55,920 --> 00:29:58,120
If you just use it for test 
scripting, it's much less 

572
00:29:58,120 --> 00:30:01,480
valuable because a test script 
was given When then. 

573
00:30:01,480 --> 00:30:04,360
Generally people will mix up the
Given When Then and it won't 

574
00:30:04,360 --> 00:30:07,240
make any sense. 
It'll be hard to read, and also 

575
00:30:07,480 --> 00:30:10,000
when people write test scripts 
with them, they tend to be much 

576
00:30:10,040 --> 00:30:13,110
more granular. 
Much more focused on clicking on

577
00:30:13,110 --> 00:30:17,270
buttons or clicking on the 
fields, and that becomes brittle

578
00:30:17,270 --> 00:30:20,230
and hard to maintain. 
And so people say Gherkin's no 

579
00:30:20,230 --> 00:30:22,190
good because it creates test 
scripts that are hard to 

580
00:30:22,190 --> 00:30:23,830
maintain. 
Absolutely it does. 

581
00:30:24,030 --> 00:30:27,550
But if you use it to write 
executable specifications in the

582
00:30:27,550 --> 00:30:30,950
business language, it can be 
extremely effective. 

583
00:30:31,790 --> 00:30:34,230
Absolutely. 
I think one of the main things 

584
00:30:34,230 --> 00:30:37,750
that's character language is 
supposed to help you accomplish.

585
00:30:37,750 --> 00:30:40,710
What aims to help you accomplish
is a separation of 

586
00:30:40,710 --> 00:30:42,470
preconditions, actions, and 
outcomes. 

587
00:30:42,470 --> 00:30:46,630
So given when then it's actually
very similar to what you see in 

588
00:30:46,630 --> 00:30:49,350
well written unit tests with the
separation of three parts. 

589
00:30:49,350 --> 00:30:52,390
So Arrange, Act, Assert. 
Now we're doing something very 

590
00:30:52,390 --> 00:30:55,270
similar, but with the focus on 
business requirements. 

591
00:30:55,700 --> 00:30:58,380
Now the reason why we're 
expecting this in a human 

592
00:30:58,420 --> 00:31:01,980
readable language is so that now
we can create an opportunity to 

593
00:31:02,060 --> 00:31:05,020
avoid some implementation 
specific details. 

594
00:31:05,020 --> 00:31:08,020
So again, we can focus on the 
business language. 

595
00:31:08,020 --> 00:31:11,060
We can focus on introducing this
business domain language into 

596
00:31:11,060 --> 00:31:15,020
our executable specifications. 
Now an interesting thing about 

597
00:31:15,020 --> 00:31:18,860
Cucumber and Gherkin that you 
know many especially English 

598
00:31:18,860 --> 00:31:22,300
native speakers forget about is 
that what's Cucumber and Gherkin

599
00:31:22,300 --> 00:31:25,180
allow you to do is they allow 
you to express those in scalable

600
00:31:25,180 --> 00:31:27,740
specifications in a language 
other than English. 

601
00:31:28,140 --> 00:31:31,700
Now Cucumber, the last time I 
checked is supported over 70 

602
00:31:31,860 --> 00:31:34,380
different languages. 
So what you can do now as a 

603
00:31:34,380 --> 00:31:38,660
team, If your business sponsor 
or your audience speaks language

604
00:31:38,740 --> 00:31:40,900
other than English, or they're 
more comfortable with other 

605
00:31:40,900 --> 00:31:43,390
language other than English, 
then you can express your 

606
00:31:43,390 --> 00:31:46,310
specification in Spanish, 
French, Arabic or whatever other

607
00:31:46,310 --> 00:31:49,710
language you prefer. 
And then Cucumber under the hood

608
00:31:49,710 --> 00:31:53,310
will translate those statements 
in the human readable language 

609
00:31:53,310 --> 00:31:56,630
to your actual automation calls.
Now it's going to be very, very 

610
00:31:56,630 --> 00:31:59,630
useful again as a tool to 
improve collaboration with 

611
00:31:59,790 --> 00:32:03,190
different audiences of your 
automated specifications. 

612
00:32:03,790 --> 00:32:06,790
I wasn't aware that many 
languages are supported, so 

613
00:32:06,830 --> 00:32:09,320
thanks for adding that. 
So I think that's really 

614
00:32:09,320 --> 00:32:11,640
interesting. 
Yeah, even Pirates speak from 

615
00:32:11,640 --> 00:32:14,280
what I remember. 
So those are. 

616
00:32:15,320 --> 00:32:19,040
And also, I just knew from John 
what Gerkin means, right? 

617
00:32:19,040 --> 00:32:22,160
It's a small cucumber. 
So I think I learned these two 

618
00:32:22,160 --> 00:32:24,200
things really well today from 
you guys. 

619
00:32:24,840 --> 00:32:28,280
So talking about BDD, right, I 
think in order to introduce 

620
00:32:28,280 --> 00:32:30,600
that, I think it's not just a 
simple switch, right? 

621
00:32:30,600 --> 00:32:33,680
People need to learn and people 
need to understand how should 

622
00:32:33,680 --> 00:32:36,640
the flow be. 
And I think I believe many teams

623
00:32:36,640 --> 00:32:38,880
these days practice Agile 
software development 

624
00:32:38,960 --> 00:32:42,120
methodology, whether good or 
bad, it's a separate discussion,

625
00:32:42,480 --> 00:32:45,720
but I think in your book you 
outline several steps that 

626
00:32:45,720 --> 00:32:49,680
people can try in order to 
incorporate BDD in their 

627
00:32:49,680 --> 00:32:52,400
software development flow. 
Maybe if you can give us a 

628
00:32:52,440 --> 00:32:56,020
highlight, an outline. 
How should people introduce BDD 

629
00:32:56,020 --> 00:32:58,700
seamlessly in their software 
development methodology? 

630
00:32:59,580 --> 00:33:02,940
So we work with teams, John and 
myself, that's what we do. 

631
00:33:02,940 --> 00:33:05,380
We work with teams to introduce 
BDD into the. 

632
00:33:05,820 --> 00:33:08,460
So we've got a fair bit of 
experience with what works and 

633
00:33:08,460 --> 00:33:11,580
what doesn't. 
And what we've always found is 

634
00:33:11,580 --> 00:33:14,740
that you need to start with the 
requirements part. 

635
00:33:14,740 --> 00:33:16,420
You need to start with the 
conversation. 

636
00:33:16,420 --> 00:33:20,190
The automation comes later. 
You've got to start with the 

637
00:33:20,190 --> 00:33:22,070
conversation. 
So you've got to get people 

638
00:33:22,070 --> 00:33:26,110
communicating and collaborating 
and having those conversations. 

639
00:33:26,150 --> 00:33:28,310
And it might feel like, yeah, I 
was saying earlier, it might 

640
00:33:28,310 --> 00:33:30,670
feel like you're spending more 
time in meetings. 

641
00:33:30,670 --> 00:33:35,190
But actually what you get out of
those meetings is multiplied 

642
00:33:35,190 --> 00:33:39,310
many times by the time you save 
actually delivering the code 

643
00:33:39,310 --> 00:33:41,550
that you meant, building and 
delivering the code and the 

644
00:33:41,550 --> 00:33:45,870
features that add the value. 
So the first step is to 

645
00:33:46,350 --> 00:33:48,630
understand what the BDD process 
is. 

646
00:33:49,180 --> 00:33:53,220
Understand that it's about 
conversations and collaboration 

647
00:33:53,220 --> 00:33:58,380
and then automation and start 
structuring that those making 

648
00:33:58,380 --> 00:34:03,220
time, carving out a time in your
existing process to have those 

649
00:34:03,220 --> 00:34:05,660
conversations. 
You don't want to leave it at 

650
00:34:05,660 --> 00:34:08,820
Hock and you don't want to leave
it to sort of just random 

651
00:34:08,820 --> 00:34:11,840
conversations. 
So the second thing is that BDD 

652
00:34:11,840 --> 00:34:15,560
proposes a number of practices, 
like example mapping, feature 

653
00:34:15,560 --> 00:34:19,440
mapping, a whole lot of others. 
But they're structured practices

654
00:34:19,440 --> 00:34:22,880
which designed to help teams get
the most out of those 

655
00:34:22,880 --> 00:34:25,560
conversations. 
And they are very intended. 

656
00:34:25,560 --> 00:34:28,719
A whole lot of psychology that 
goes into a lot of the things we

657
00:34:28,719 --> 00:34:33,020
suggest in BDD. 
But those techniques are really 

658
00:34:33,020 --> 00:34:35,900
important, especially when we 
have teams where some people 

659
00:34:35,900 --> 00:34:38,900
might be more vocal, some people
might be more reflective and 

660
00:34:38,980 --> 00:34:40,940
like to take time to get their 
answers. 

661
00:34:40,940 --> 00:34:44,179
When we can use collaboration 
tools, when we use tools like 

662
00:34:44,179 --> 00:34:47,020
mural and figma and mural and 
whatnot for online 

663
00:34:47,020 --> 00:34:48,940
collaboration, we can get the 
same effect. 

664
00:34:49,300 --> 00:34:53,179
We can use a structured approach
to coming up with those examples

665
00:34:53,380 --> 00:34:55,739
and then turning them into an 
executable format. 

666
00:34:56,300 --> 00:35:00,460
The third step we introduce is. 
The actual automation side of 

667
00:35:00,460 --> 00:35:02,740
things. 
So how do we find an automation 

668
00:35:02,740 --> 00:35:06,740
approach that will work for the 
technologies that the team's 

669
00:35:06,740 --> 00:35:09,740
using? 
And that obviously varies and 

670
00:35:09,740 --> 00:35:13,340
I'm very reluctant to say to a 
particular team you must use 

671
00:35:13,340 --> 00:35:16,940
this automation tool. 
I'd rather the team own the 

672
00:35:16,940 --> 00:35:20,940
automation technology and then 
we basically what we do is we'll

673
00:35:20,940 --> 00:35:24,730
guide them and to choose. 
How they can actually implement 

674
00:35:24,730 --> 00:35:27,490
and I mean, we have our 
preferences, but I've worked 

675
00:35:27,490 --> 00:35:32,130
with teams who work with APL. 
I remember one team was working 

676
00:35:32,130 --> 00:35:34,290
on and also it's really obscure 
stuff. 

677
00:35:34,290 --> 00:35:36,570
So not everyone is using Java or
JavaScript. 

678
00:35:36,690 --> 00:35:39,530
So Java, JavaScript and Python, 
they're the big ones that people

679
00:35:39,530 --> 00:35:42,570
are using these days. 
And with them, Cucumber does 

680
00:35:42,570 --> 00:35:45,490
provide some nice options. 
But there are lots of options 

681
00:35:45,490 --> 00:35:48,330
out there and you want something
that the teams embrace and adopt

682
00:35:48,330 --> 00:35:51,240
themselves. 
And then the final stage is 

683
00:35:51,240 --> 00:35:53,840
actually getting the teams doing
the automation themselves. 

684
00:35:53,840 --> 00:35:57,520
So automation is not just about 
the test or automating test 

685
00:35:57,520 --> 00:36:00,160
cases. 
It's about we want an outside in

686
00:36:00,160 --> 00:36:02,640
approach. 
So we're as far much as 

687
00:36:02,640 --> 00:36:04,440
possible. 
You don't automate after the 

688
00:36:04,440 --> 00:36:07,760
fact, you automate before you 
actually start the work. 

689
00:36:08,080 --> 00:36:10,080
And that's what I was saying 
earlier on. 

690
00:36:10,080 --> 00:36:13,240
The ultimate end goal of that is
that you don't need to automate 

691
00:36:13,240 --> 00:36:16,640
at all, that you express the 
requirements in your domain 

692
00:36:16,680 --> 00:36:18,940
language. 
And the automation is already 

693
00:36:18,940 --> 00:36:20,780
done for you. 
So that's sort of the ultimate 

694
00:36:20,780 --> 00:36:24,140
in ATDD. 
So they're typically the stages 

695
00:36:24,140 --> 00:36:27,100
that we go through that we see 
when we help teams introduce 

696
00:36:27,100 --> 00:36:29,340
BDD. 
Yeah, absolutely. 

697
00:36:29,340 --> 00:36:32,580
I think the collaboration aspect
is again one of the most 

698
00:36:32,660 --> 00:36:35,460
important ones here. 
So like you mentioned earlier, 

699
00:36:35,460 --> 00:36:38,780
John, so one of the things that 
the teams very often try and do 

700
00:36:39,020 --> 00:36:42,100
when introducing BDD is to focus
on the tool. 

701
00:36:42,140 --> 00:36:43,980
I mean, it's an actual 
inclination of any software 

702
00:36:43,980 --> 00:36:46,570
engineer. 
We focus on the tool first, so 

703
00:36:46,570 --> 00:36:48,370
we think, Okay. 
Well, I like BDD. 

704
00:36:48,370 --> 00:36:50,210
I like all the things it 
promises. 

705
00:36:50,410 --> 00:36:53,210
I'll just use Cucumber to write 
some automated scripts after 

706
00:36:53,210 --> 00:36:55,530
I've already done development. 
Well, that's kind of pointless, 

707
00:36:55,530 --> 00:36:56,090
right? 
What do you mean? 

708
00:36:56,290 --> 00:36:57,570
The development has already 
happened? 

709
00:36:57,570 --> 00:36:59,770
The collaboration has already 
hopefully happened. 

710
00:37:00,170 --> 00:37:02,570
So now it's way too late to 
actually write any automated 

711
00:37:02,570 --> 00:37:05,650
tests. 
Now what we do, this workshop 

712
00:37:05,650 --> 00:37:09,970
that John mentioned earlier is 
one of the core practices of 

713
00:37:09,970 --> 00:37:13,130
Behavior Driven Development is a
Three Amigos workshop. 

714
00:37:13,590 --> 00:37:17,270
Now the idea of the Three Amigos
workshop is to have people 

715
00:37:17,270 --> 00:37:20,710
representing different 
perspective involved in software

716
00:37:21,030 --> 00:37:22,750
delivery. 
So the business perspective to 

717
00:37:22,750 --> 00:37:25,910
the development perspective and 
the verification perspective. 

718
00:37:26,110 --> 00:37:29,830
Someone to actually describe the
word and why it's needed for the

719
00:37:29,830 --> 00:37:33,070
organization, someone to figure 
out how we actually ship it, and

720
00:37:33,070 --> 00:37:36,190
someone to critique the idea to 
find the house, find the things 

721
00:37:36,190 --> 00:37:39,350
that might possibly not work so 
that we can actually guard 

722
00:37:39,590 --> 00:37:42,090
against them. 
So that's one of the critical 

723
00:37:42,090 --> 00:37:44,050
workshop that we typically 
introduce. 

724
00:37:44,450 --> 00:37:46,650
Now, another thing that you need
to do this workshop is you need 

725
00:37:46,650 --> 00:37:49,530
to make sure that the people who
actually can add value to those 

726
00:37:49,530 --> 00:37:51,770
workshops are involved. 
So what a team would need to do 

727
00:37:51,770 --> 00:37:56,130
is to identify the dependencies 
not only in terms of software, 

728
00:37:56,130 --> 00:37:57,610
but again in terms of other 
teams. 

729
00:37:57,610 --> 00:38:00,570
So for example, if I need to 
accomplish a certain goal that 

730
00:38:00,570 --> 00:38:04,690
requires me to work with my Dbas
or application security teams or

731
00:38:04,730 --> 00:38:08,000
QA teams or whatever other teams
I have in my organization, I 

732
00:38:08,000 --> 00:38:11,080
would try to establish those 
communication links first. 

733
00:38:11,320 --> 00:38:15,600
So again, we typically focus or 
we recommend teams to focus on 

734
00:38:15,840 --> 00:38:19,240
establishing those communication
links because this then leads to

735
00:38:19,240 --> 00:38:21,400
you understanding the 
requirements, but it doesn't 

736
00:38:21,400 --> 00:38:22,920
help you automate those 
requirements. 

737
00:38:22,920 --> 00:38:26,320
But then this helps you to 
deliver better quality software.

738
00:38:27,340 --> 00:38:29,500
Right. 
I like the emphasis that you put

739
00:38:29,500 --> 00:38:32,340
that we should not start with 
the automation first, right? 

740
00:38:32,340 --> 00:38:35,060
Like picking the tools do the 
automation, but actually the 

741
00:38:35,060 --> 00:38:38,180
development is done and maybe 
the story was already defined. 

742
00:38:38,460 --> 00:38:41,020
So I think, again, the emphasis 
is on the collaborative aspect. 

743
00:38:41,340 --> 00:38:44,340
What about if the teams already 
have a software in place? 

744
00:38:44,460 --> 00:38:47,020
There's a legacy code. 
There's a legacy requirements. 

745
00:38:47,180 --> 00:38:49,500
Maybe it written somewhere, 
maybe it doesn't get written 

746
00:38:49,500 --> 00:38:51,180
somewhere. 
Maybe it's in people's head. 

747
00:38:51,640 --> 00:38:55,200
Is there a way that you would 
advise people to incorporate BDD

748
00:38:55,200 --> 00:38:57,080
into, you know, like legacy 
software? 

749
00:38:57,960 --> 00:39:00,320
Generally speaking, there are 
two approaches. 

750
00:39:00,720 --> 00:39:05,120
Either you only do it for 
incrementally for new features, 

751
00:39:05,640 --> 00:39:10,200
or you backfit executable 
specifications for your entire 

752
00:39:10,200 --> 00:39:12,000
application. 
I don't generally recommend the 

753
00:39:12,000 --> 00:39:16,080
second approach, but I have had 
teams who are really insistent 

754
00:39:16,080 --> 00:39:19,880
on wanting to do that approach 
because they wanted the value of

755
00:39:19,880 --> 00:39:23,030
the living documentation. 
And they knew the legacy 

756
00:39:23,030 --> 00:39:25,830
application was mission critical
and they had no understanding of

757
00:39:25,830 --> 00:39:30,270
what it actually did. 
So they were in the case. 

758
00:39:30,270 --> 00:39:33,550
Particular case I'm thinking, 
which was a company in Sydney 

759
00:39:33,590 --> 00:39:38,150
who did this and it worked 
really well, is that they used 

760
00:39:38,150 --> 00:39:43,060
the BDD approach to retrofit. 
Executable specifications for 

761
00:39:43,060 --> 00:39:45,300
their existing functionality. 
And that was a way of them 

762
00:39:45,300 --> 00:39:47,980
understanding what the 
application did and documenting 

763
00:39:47,980 --> 00:39:49,940
what the application did. 
And that allowed them to 

764
00:39:49,940 --> 00:39:55,020
progress faster afterwards. 
But in most cases, what I find 

765
00:39:55,020 --> 00:39:59,900
is a path of lesser resistance 
is to apply it incrementally and

766
00:39:59,900 --> 00:40:02,980
progressively. 
So you come with a new feature. 

767
00:40:03,340 --> 00:40:06,980
Your new feature is at a column 
to a particular search result. 

768
00:40:07,440 --> 00:40:10,200
You're not going to write a 
whole lot of BDD scenarios for 

769
00:40:10,200 --> 00:40:12,640
everything around it. 
You're going to write a BDD 

770
00:40:12,640 --> 00:40:15,560
scenario for that particular use
case and use a journey. 

771
00:40:15,560 --> 00:40:20,600
So your use case might be well, 
a admin will add a product to a 

772
00:40:20,680 --> 00:40:23,880
catalog with a range of colors, 
and the search screen should 

773
00:40:23,880 --> 00:40:26,040
show those colors in the search 
results. 

774
00:40:26,360 --> 00:40:29,760
And so you might have a some 
scenarios around that, and that 

775
00:40:29,760 --> 00:40:33,770
will be your BDD scenarios. 
You won't explore every possible

776
00:40:33,770 --> 00:40:36,850
way the admin can add products 
to the catalog or every possible

777
00:40:36,850 --> 00:40:40,730
way you can search. 
But as you add new features, 

778
00:40:40,810 --> 00:40:45,370
you'll expand on what you've 
done and gradually you'll create

779
00:40:45,370 --> 00:40:48,170
these little islands of 
executable specifications which 

780
00:40:48,170 --> 00:40:51,250
will eventually come together 
and form a bigger picture. 

781
00:40:51,610 --> 00:40:54,410
And that is a more pragmatic 
approach when you've got an 

782
00:40:54,410 --> 00:40:57,690
existing application and you 
don't want to burden the team 

783
00:40:57,690 --> 00:41:01,370
too much with having to do too 
much automation at the start. 

784
00:41:01,890 --> 00:41:04,890
Now that said, I do know teams 
who use that approach, but 

785
00:41:04,930 --> 00:41:08,690
simultaneously they have a tech 
debt approach where they 

786
00:41:08,770 --> 00:41:12,130
recognize that there is a 
technical debt related to the 

787
00:41:12,130 --> 00:41:15,250
lack of automation, lack of 
executable specifications. 

788
00:41:15,250 --> 00:41:17,890
So each Sprint they'll do a 
little bit of work to chip away 

789
00:41:17,890 --> 00:41:21,650
at that and add a little bit 
more than they need to, so that 

790
00:41:21,650 --> 00:41:25,450
they can gradually build up 
their executable specifications 

791
00:41:25,450 --> 00:41:28,820
more quickly. 
Now, one of the things that 

792
00:41:28,900 --> 00:41:31,700
could be helpful to teams that 
actually need to support 

793
00:41:31,860 --> 00:41:34,940
existing software while 
introducing new features is 

794
00:41:34,940 --> 00:41:37,500
something we described in the 
book as well, and that's a 

795
00:41:37,500 --> 00:41:39,260
technique called journey 
mapping. 

796
00:41:40,140 --> 00:41:42,980
Journey mapping is a BDD 
technique that we've developed 

797
00:41:42,980 --> 00:41:47,020
when working with teams who work
on established software systems.

798
00:41:47,580 --> 00:41:50,820
If you think about it, this is a
very common case, especially in 

799
00:41:50,820 --> 00:41:54,010
finance, insurance, healthcare. 
Where you know you very rarely 

800
00:41:54,010 --> 00:41:57,170
have the luxury of starting with
a Greenfield project. 

801
00:41:57,170 --> 00:41:59,010
You typically have something you
have to maintain. 

802
00:41:59,010 --> 00:42:02,730
You need to add to that now 
techniques like journey mapping,

803
00:42:02,730 --> 00:42:05,650
what they allow you to do is 
they allow you to focus 

804
00:42:05,650 --> 00:42:10,130
collaboration with other parts 
of your organization around the 

805
00:42:10,130 --> 00:42:13,130
important aspects of the system 
that your systems to support. 

806
00:42:13,410 --> 00:42:17,450
So it allows you to focus on the
specific actors or the specific 

807
00:42:17,490 --> 00:42:20,930
external parties, your systems 
to support their main use cases,

808
00:42:20,930 --> 00:42:24,000
the main scenarios and so on. 
So with this collaboration 

809
00:42:24,000 --> 00:42:27,680
technique helps you to do this, 
helps you to prioritize any of 

810
00:42:27,680 --> 00:42:30,200
your refactoring or re 
architecting work better. 

811
00:42:30,440 --> 00:42:32,760
Because now that you understand 
what the system is supposed to 

812
00:42:32,760 --> 00:42:35,000
do, you understand what the 
important parts are. 

813
00:42:35,200 --> 00:42:38,120
You understand what parts need 
to keep working whenever you add

814
00:42:38,120 --> 00:42:41,800
new software or new features. 
Then you can make sure first 

815
00:42:41,800 --> 00:42:43,920
your manual testing or 
exploratory testing activities 

816
00:42:43,920 --> 00:42:47,160
around those important aspects. 
Then you can start creating your

817
00:42:47,160 --> 00:42:50,200
automation with the focus on the
important aspects of the system.

818
00:42:50,610 --> 00:42:53,250
Because now any existing system 
will have functionalities that 

819
00:42:53,250 --> 00:42:56,050
are used on a daily basis 
frequently, but most of the 

820
00:42:56,050 --> 00:42:59,130
users and we have some features 
that have been added by two 

821
00:42:59,130 --> 00:43:01,530
decades ago for whatever reason 
that nobody remembers. 

822
00:43:01,890 --> 00:43:04,890
So it's important to be able to 
distinguish between those two. 

823
00:43:05,810 --> 00:43:08,210
Right, so start small, start 
gradually, right? 

824
00:43:08,210 --> 00:43:10,050
It's not like one Big Bang 
approach. 

825
00:43:10,090 --> 00:43:12,970
You can have all the 
requirements captured in one 

826
00:43:12,970 --> 00:43:15,170
goal, right? 
Absolutely start small and build

827
00:43:15,170 --> 00:43:17,600
right. 
So both of you mentioned things 

828
00:43:17,600 --> 00:43:20,840
like features, scenarios, steps.
I think. 

829
00:43:20,840 --> 00:43:23,800
Let's go a little bit more into 
the techniques, right? 

830
00:43:24,200 --> 00:43:27,840
For teams who implement BDD, how
should they structure all these 

831
00:43:27,880 --> 00:43:30,680
different given, when then 
different scenarios? 

832
00:43:31,000 --> 00:43:34,520
Is it common to put it in their 
user stories or is there a 

833
00:43:34,520 --> 00:43:37,280
better way of structuring and 
managing those requirements? 

834
00:43:38,160 --> 00:43:41,400
Generally speaking, some teams 
will put the Given, When Then 

835
00:43:41,400 --> 00:43:45,360
statements directly in JIRA, 
some teams will put it in 

836
00:43:45,360 --> 00:43:47,760
version control. 
We used to. 

837
00:43:47,760 --> 00:43:52,240
Well, it was very common a while
back to actually come up with 

838
00:43:52,240 --> 00:43:55,400
the Given When Then statements 
directly in Three Amigos, then 

839
00:43:55,400 --> 00:43:58,040
automate them later on. 
But we've found that that's a 

840
00:43:58,320 --> 00:44:01,160
rather inefficient process 
because it takes a lot of people

841
00:44:01,160 --> 00:44:05,320
a lot of time to words with 
those given when then scenarios,

842
00:44:05,320 --> 00:44:09,760
whereas what you're really after
is getting the key examples and 

843
00:44:09,920 --> 00:44:13,240
counter examples. 
And so the given When then 

844
00:44:13,730 --> 00:44:17,330
really should be what we call an
executable specification. 

845
00:44:17,330 --> 00:44:20,650
And if it's executable, it's 
part of the source code, so it 

846
00:44:20,650 --> 00:44:22,890
should be actually in the source
code. 

847
00:44:23,410 --> 00:44:27,210
Now the problem that happens is 
product owners and business 

848
00:44:27,210 --> 00:44:30,810
analysts, they want visibility 
on those given when then. 

849
00:44:31,010 --> 00:44:36,090
So there are tools around Jira 
plugins for example, that allow 

850
00:44:36,090 --> 00:44:40,630
you to give you visibility on 
those given, when Then 

851
00:44:40,630 --> 00:44:42,630
statements that you've got in 
your source code. 

852
00:44:42,630 --> 00:44:45,950
Even edit them some of them so 
that you can get that visibility

853
00:44:45,950 --> 00:44:50,390
from Jira in your user stories, 
but without compromising the 

854
00:44:50,390 --> 00:44:53,630
fact that the Given When ends 
are effectively source code and 

855
00:44:53,630 --> 00:44:55,910
they need to be in a place where
they can be executed. 

856
00:44:56,430 --> 00:45:00,110
What is an anti pattern and I 
find is that when product owners

857
00:45:00,110 --> 00:45:02,670
right the Given, when, Then 
statements directly in the user 

858
00:45:02,670 --> 00:45:06,150
stories before they have the 
conversations because that cut 

859
00:45:06,150 --> 00:45:09,070
short the whole conversation 
part of BVD. 

860
00:45:09,590 --> 00:45:12,990
That introduces a whole lot of 
cognitive biases and actually 

861
00:45:13,350 --> 00:45:16,030
makes the conversations a lot 
less efficient. 

862
00:45:16,270 --> 00:45:18,310
And also they're really hard to 
automate generally. 

863
00:45:18,910 --> 00:45:23,070
So that is generally speaking, 
there's maybe one team in 10, 

864
00:45:23,070 --> 00:45:25,470
one team in 20 who can pull that
off that I've seen. 

865
00:45:25,830 --> 00:45:28,390
But generally speaking we don't 
advise that. 

866
00:45:28,390 --> 00:45:31,030
We advise having the 
conversations first, writing 

867
00:45:31,030 --> 00:45:34,030
lightweight acceptance criteria 
first, having the conversations 

868
00:45:34,030 --> 00:45:37,030
and then putting the Given When,
then inversions from, then 

869
00:45:37,030 --> 00:45:40,900
figuring out how to get that 
visibility in JIRA or whatever 

870
00:45:40,900 --> 00:45:43,740
tool you're using. 
Plus, I think a very important 

871
00:45:43,740 --> 00:45:47,780
distinction to make is between 
features and user stories. 

872
00:45:48,020 --> 00:45:51,940
I remember for me to say very 
important switch in how I was 

873
00:45:51,940 --> 00:45:54,380
thinking about software delivery
as a whole. 

874
00:45:54,820 --> 00:45:57,660
Features is what your software 
provides. 

875
00:45:57,700 --> 00:45:59,500
It's what the things that people
can use. 

876
00:45:59,820 --> 00:46:02,380
User stories is how you deliver 
those features, how you 

877
00:46:02,380 --> 00:46:06,540
structure your software delivery
process, in what sequence do you

878
00:46:06,540 --> 00:46:08,540
deliver different pieces of 
functionality. 

879
00:46:09,090 --> 00:46:11,930
So what typically happens with 
those feature files? 

880
00:46:12,010 --> 00:46:15,050
If your team uses Cucumber, or 
with your test specification 

881
00:46:15,050 --> 00:46:17,610
classes, if you're using JUnit 
or Aspect or whatever. 

882
00:46:18,010 --> 00:46:21,770
What typically happens is as you
deliver new user stories, you 

883
00:46:21,770 --> 00:46:25,970
will be expanding your feature, 
the executable specifications of

884
00:46:25,970 --> 00:46:28,810
your feature, with every new 
user story you deliver. 

885
00:46:28,970 --> 00:46:31,210
Sometimes you'll be adding 
additional scenarios, sometimes 

886
00:46:31,210 --> 00:46:32,650
you'll be changing the existing 
scenarios. 

887
00:46:32,650 --> 00:46:35,370
Sometimes you'll be removing 
scenarios when you see certain 

888
00:46:35,450 --> 00:46:38,370
aspects of a feature. 
Don't gain as much traction as 

889
00:46:38,370 --> 00:46:42,330
you were hoping it's to gain. 
So again, every user story your 

890
00:46:42,410 --> 00:46:46,090
team delivers, you're basically 
affecting the current shape of 

891
00:46:46,090 --> 00:46:50,010
the feature your system has. 
Well I think I get a lot of 

892
00:46:50,010 --> 00:46:54,050
explanation and clarity on how 
teams should manage their given 

893
00:46:54,050 --> 00:46:56,010
when then right? 
I see some teams actually just 

894
00:46:56,370 --> 00:46:59,850
write it in the stories and then
it gets lost once the story is 

895
00:46:59,850 --> 00:47:01,850
done. 
Maybe few sprints before right? 

896
00:47:02,170 --> 00:47:05,250
And the teams also couldn't 
figure out how to collect back 

897
00:47:05,250 --> 00:47:07,800
all these given when then. 
So I think all these 

898
00:47:07,800 --> 00:47:10,880
explanations make sense. 
Both of you have mentioned a few

899
00:47:10,880 --> 00:47:14,840
techniques in addition to making
BDD work more effectively, 

900
00:47:14,840 --> 00:47:17,080
right? 
Things like journey mapping, I 

901
00:47:17,080 --> 00:47:20,160
think impact mapping, private 
campuses, and all of these are 

902
00:47:20,160 --> 00:47:23,120
also mentioned in the book. 
Maybe if you can highlight one 

903
00:47:23,120 --> 00:47:26,320
or two of your favorites 
techniques that we can also 

904
00:47:26,320 --> 00:47:29,520
explore in order to make our BDD
implementation much more 

905
00:47:29,520 --> 00:47:31,920
effective. 
Yeah, sure thing. 

906
00:47:31,920 --> 00:47:34,600
So maybe we could start with the
screenplay pattern. 

907
00:47:34,980 --> 00:47:38,540
So the pattern itself caused a 
bit of a stir when we first 

908
00:47:38,540 --> 00:47:41,420
talked about it in the test 
automation community and the 

909
00:47:41,420 --> 00:47:45,540
ability community in general. 
So what is screenplay pattern? 

910
00:47:45,540 --> 00:47:48,540
So screenplay pattern is quite 
an innovative user centered 

911
00:47:48,540 --> 00:47:52,980
approach to writing high quality
automated acceptance tests. 

912
00:47:53,460 --> 00:47:57,460
And what it does It tears you 
towards an effective use of 

913
00:47:57,460 --> 00:48:01,340
layers of obstruction and helps 
your test scenarios capture the 

914
00:48:01,780 --> 00:48:04,260
business vernacular of your 
domain. 

915
00:48:04,910 --> 00:48:08,030
It also encourages good testing 
and software engineering habits 

916
00:48:08,030 --> 00:48:10,350
on your team. 
Now, how does it do it? 

917
00:48:10,670 --> 00:48:14,630
You see, typically when we do 
automated testing, when we write

918
00:48:14,630 --> 00:48:18,430
automated tests, we express 
those tests from the perspective

919
00:48:18,550 --> 00:48:21,430
of an integration tool 
interacting. 

920
00:48:21,430 --> 00:48:24,270
With our system. 
So in the UI testing you would 

921
00:48:24,350 --> 00:48:27,750
write a test as a web driver. 
So go to a page, click on a 

922
00:48:27,750 --> 00:48:30,030
button, enter a value into a 
field and so on. 

923
00:48:30,630 --> 00:48:33,590
When we do API testing, we 
express it from the point of 

924
00:48:33,590 --> 00:48:39,030
view really of an HTTP client. 
So I send the request, I get the

925
00:48:39,030 --> 00:48:40,910
response, I verify a status 
code. 

926
00:48:41,430 --> 00:48:44,390
But what we typically miss in 
those scenarios is we completely

927
00:48:44,390 --> 00:48:49,310
miss the business vocabulary. 
We miss the business reason 

928
00:48:49,310 --> 00:48:52,310
behind those scenarios. 
We completely failed to capture 

929
00:48:52,310 --> 00:48:54,670
all this information in our test
script. 

930
00:48:55,030 --> 00:48:58,350
So with the screenplay pattern, 
what we do is we flip this whole

931
00:48:58,350 --> 00:49:01,680
thing on its head. 
Instead of expressing the 

932
00:49:01,680 --> 00:49:04,440
automated tests from the 
perspective of a low level tool,

933
00:49:04,800 --> 00:49:11,640
we look at them as a way to 
express all the different tasks 

934
00:49:11,640 --> 00:49:16,600
that an external user of our 
system or of our interface would

935
00:49:16,600 --> 00:49:19,080
perform in order to accomplish 
their goal. 

936
00:49:19,480 --> 00:49:22,480
So rather than talking about a 
Webdriver or playwright or 

937
00:49:22,480 --> 00:49:25,960
Cypress clicking on button and 
entering values into fields or 

938
00:49:25,960 --> 00:49:29,360
talking about rest assured we 
identify actors. 

939
00:49:29,760 --> 00:49:33,600
So those could be either people 
or external systems interacting 

940
00:49:33,600 --> 00:49:37,560
with our system. 
What we do next is we capture 

941
00:49:37,760 --> 00:49:41,800
the specific goals and tasks 
they need to perform in order to

942
00:49:41,800 --> 00:49:44,520
accomplish their goals. 
So for example, we might focus 

943
00:49:44,560 --> 00:49:49,360
our scenario on a person or a 
persona of a shopper that goes 

944
00:49:49,360 --> 00:49:53,920
to an e-commerce website, tries 
to find a product added to the 

945
00:49:53,920 --> 00:49:57,040
basket, make sure that the tax 
is calculated correctly, and so 

946
00:49:57,040 --> 00:50:00,110
on. 
So what we do this pattern is we

947
00:50:00,110 --> 00:50:02,910
actually capture the business 
vocabulary, we capture the 

948
00:50:02,910 --> 00:50:07,830
business intent behind given 
piece of functionality and we 

949
00:50:08,310 --> 00:50:13,670
use high quality code to express
those things and capture them in

950
00:50:13,710 --> 00:50:16,190
a form of an executable 
specification. 

951
00:50:27,380 --> 00:50:33,340
So the main thing in a user 
centered model is a model 

952
00:50:33,340 --> 00:50:36,260
representing a user or an 
external system interacting with

953
00:50:36,260 --> 00:50:18,030
our system. 
Now the interesting thing about 

954
00:50:18,030 --> 00:50:20,750
the pattern itself is that it's 
actually, it might sound like 

955
00:50:20,750 --> 00:50:23,510
something really complicated, 
but in fact it really isn't. 

956
00:50:23,830 --> 00:50:26,390
It's made out of five main 
building. 

957
00:50:36,860 --> 00:50:40,020
So we have actors. 
Actors are the first building 

958
00:50:40,020 --> 00:50:43,340
block of the screenplay pattern.
Now I already talked about the 

959
00:50:43,340 --> 00:50:46,420
tasks. 
So tasks are basically a way to 

960
00:50:46,780 --> 00:50:50,100
express those different things 
that an actor would do in order 

961
00:50:50,100 --> 00:50:53,340
to accomplish their goal. 
They're basically aggregates of 

962
00:50:53,460 --> 00:50:56,260
lower level SAP tasks or 
interactions with the system. 

963
00:50:57,050 --> 00:50:58,770
So we have actors and we have 
tasks. 

964
00:50:59,290 --> 00:51:02,330
Those tasks are typically 
made-up of interactions. 

965
00:51:02,330 --> 00:51:05,210
Now interactions are the lower 
level actions that the actor 

966
00:51:05,210 --> 00:51:08,530
would perform in order to 
interact with the system, hence 

967
00:51:08,530 --> 00:51:11,410
the name. 
So we have actors who perform 

968
00:51:11,490 --> 00:51:14,010
tasks and those tasks are 
made-up of other tasks and 

969
00:51:14,010 --> 00:51:17,130
interactions. 
Now how do those actors perform 

970
00:51:17,130 --> 00:51:19,730
the tasks? 
So the interesting thing about 

971
00:51:20,210 --> 00:51:24,050
the screenplay pattern is that 
we try to encapsulate all the 

972
00:51:24,050 --> 00:51:27,830
lower level API calls to our. 
API clients. 

973
00:51:27,830 --> 00:51:31,270
So you wouldn't see any web 
driver or playwright or Cypress 

974
00:51:31,270 --> 00:51:34,950
calls in your tests. 
All those would be encapsulated 

975
00:51:34,990 --> 00:51:37,670
in another class. 
So those class are called 

976
00:51:37,670 --> 00:51:42,310
Abilities, and abilities are 
basically thin wrappers around 

977
00:51:42,310 --> 00:51:45,550
those integration libraries. 
So we have actors who perform 

978
00:51:45,550 --> 00:51:47,470
tasks. 
Tasks are made-up of other 

979
00:51:47,470 --> 00:51:51,230
subtasks and interactions, and 
what enables those interactions 

980
00:51:51,270 --> 00:51:54,270
are abilities and abilities. 
Again, just the thin wrappers 

981
00:51:54,270 --> 00:51:57,430
around your integration library.
So those are the four elements. 

982
00:51:57,510 --> 00:52:03,470
Now the fifth one are questions 
now similar to the CQRS model 

983
00:52:03,550 --> 00:52:05,910
for designing system 
architecture. 

984
00:52:06,350 --> 00:52:09,870
In the script play, we also 
separate the interactions that 

985
00:52:09,870 --> 00:52:13,470
the actor would perform from the
information that would get out 

986
00:52:13,470 --> 00:52:17,910
of the system and the test. 
So an equivalent of a command 

987
00:52:17,910 --> 00:52:22,350
from your CQRS model are the 
interactions in screenplay 

988
00:52:22,950 --> 00:52:25,950
equivalent. 
Of a request in the screenplay 

989
00:52:25,950 --> 00:52:26,870
button. 
Questions. 

990
00:52:26,870 --> 00:52:29,030
So questions are a way to 
retrieve information from the 

991
00:52:29,030 --> 00:52:32,470
system, and questions could be 
things like get me that text 

992
00:52:32,470 --> 00:52:36,830
from that element on the screen,
or get me the last response body

993
00:52:36,830 --> 00:52:39,870
that you received from the API 
requests, or get me the position

994
00:52:39,870 --> 00:52:44,550
of this button in my mobile app.
So again, you've got those five 

995
00:52:44,550 --> 00:52:48,350
building blocks, so actors, 
tasks, interactions, abilities, 

996
00:52:48,350 --> 00:52:51,350
and questions. 
And out of those five building 

997
00:52:51,350 --> 00:52:54,500
blocks, you can. 
Develop pretty much any type of 

998
00:52:54,500 --> 00:52:56,780
automated tests you might dream 
of, really. 

999
00:52:57,140 --> 00:53:00,580
So we've used it for UI testing,
for mobile testing, for API 

1000
00:53:00,580 --> 00:53:03,220
testing, for performance 
testing, for visual regression 

1001
00:53:03,220 --> 00:53:05,300
testing. 
You can do all sorts of things 

1002
00:53:05,420 --> 00:53:08,100
by expressing your test 
scenarios using those five 

1003
00:53:08,100 --> 00:53:12,740
building blocks, and also gives 
you a very nice way to introduce

1004
00:53:12,780 --> 00:53:16,300
code reusability patterns into 
your code base as well. 

1005
00:53:17,080 --> 00:53:20,040
Thank you so much for such 
elaborate explanation about 

1006
00:53:20,040 --> 00:53:22,640
screenplay pattern. 
I personally is the first time 

1007
00:53:22,640 --> 00:53:25,120
for me to learn about this. 
I think the abstraction makes 

1008
00:53:25,120 --> 00:53:26,760
sense, the five things that you 
mentioned. 

1009
00:53:27,040 --> 00:53:31,080
Maybe if I can ask a little bit 
further why was it causing a lot

1010
00:53:31,080 --> 00:53:32,840
of stir in the testing 
community? 

1011
00:53:33,120 --> 00:53:36,360
And then secondly, if I'm not 
mistaken, not just coming up 

1012
00:53:36,360 --> 00:53:39,120
with this pattern right, you 
also contribute an open source 

1013
00:53:39,120 --> 00:53:42,160
project called Serenity. 
Maybe if you can also give a 

1014
00:53:42,160 --> 00:53:44,280
high level about this serenity 
library. 

1015
00:53:45,580 --> 00:53:49,460
So I can chip in on this side of
things because I've seen a lot 

1016
00:53:49,460 --> 00:53:54,100
of conversation on the line when
we first proposed or came out 

1017
00:53:54,100 --> 00:53:56,100
with it started talking about 
screenplay. 

1018
00:53:56,900 --> 00:54:03,420
A lot of people still think in 
terms of UI as a test automation

1019
00:54:03,420 --> 00:54:05,180
approach. 
So a lot of people are very 

1020
00:54:05,180 --> 00:54:09,300
anchored on UI testing being the
default way to test an 

1021
00:54:09,300 --> 00:54:11,580
application and sort of goes 
back to the. 

1022
00:54:12,580 --> 00:54:16,300
Very first implementations of 
test automation where it was 

1023
00:54:16,860 --> 00:54:21,340
tools like Mercury and whatever 
it's called these days, and 

1024
00:54:21,340 --> 00:54:25,300
where it was just record replay 
tools were so very clunky. 

1025
00:54:26,180 --> 00:54:29,580
Basic Scripting. 
Literally Visual Basic Scripting

1026
00:54:30,420 --> 00:54:34,500
style scripting and tended to 
be. 

1027
00:54:35,120 --> 00:54:38,320
Very ugly and unmaintainable 
from when you come in from this 

1028
00:54:38,320 --> 00:54:41,320
perspective of an software 
engineering and you look trying 

1029
00:54:41,320 --> 00:54:43,320
to make your code maintainable, 
you try to make it 

1030
00:54:43,320 --> 00:54:46,640
understandable. 
You try to write code that when 

1031
00:54:46,640 --> 00:54:49,000
you come back to it next week 
and you have to maintain it, 

1032
00:54:49,000 --> 00:54:51,120
will change it. 
You can understand what it's 

1033
00:54:51,120 --> 00:54:53,360
doing. 
I mean I have to be careful with

1034
00:54:53,360 --> 00:54:56,240
my own code because I I won't 
understand what I did this 

1035
00:54:56,240 --> 00:54:58,080
afternoon. 
I'm not careful. 

1036
00:54:58,600 --> 00:55:02,360
So looking at code later on, 
it's really important to make 

1037
00:55:02,360 --> 00:55:04,800
sure that your code captures the
intent. 

1038
00:55:05,250 --> 00:55:09,850
And the traditional way that 
people tend to do these, even 

1039
00:55:10,250 --> 00:55:12,930
one of the big things that 
people try to do is use the page

1040
00:55:12,930 --> 00:55:17,370
objects approach. 
The problem is most people that 

1041
00:55:17,370 --> 00:55:20,250
we see, or I'd say most code 
that we see implementing the 

1042
00:55:20,250 --> 00:55:25,410
page object approach becomes 
very heavyweight and convoluted 

1043
00:55:25,410 --> 00:55:28,530
and complicated and hard to 
understand and hard to maintain.

1044
00:55:28,530 --> 00:55:33,090
So you have page objects that 
try and represent an entire web 

1045
00:55:33,090 --> 00:55:37,410
page, which the name might. 
Indicate and that'll be 1000 

1046
00:55:37,410 --> 00:55:41,370
lines long and have a gazillion 
selectors and then a whole lot 

1047
00:55:41,370 --> 00:55:43,410
of logic and assertions inside 
it. 

1048
00:55:43,410 --> 00:55:45,690
And do a whole lot of different 
stuff. 

1049
00:55:45,690 --> 00:55:49,650
And that means that if a test 
changes for reason A and then 

1050
00:55:49,650 --> 00:55:52,650
the test also needs to change 
for reason BA different test, 

1051
00:55:53,010 --> 00:55:57,450
they'll both affect the same 
page object and you get churn 

1052
00:55:57,530 --> 00:56:00,650
and instability. 
And you might have an 

1053
00:56:00,650 --> 00:56:03,840
implementation for one test. 
And start in a particular way. 

1054
00:56:03,840 --> 00:56:07,520
Then for another test you need 
to do something else and so it 

1055
00:56:07,520 --> 00:56:10,320
can create code that's 
historically very hard to 

1056
00:56:10,320 --> 00:56:14,160
maintain. 
And so basically the screenplay 

1057
00:56:14,160 --> 00:56:19,400
approach really is a way of what
happens when you apply OO and 

1058
00:56:19,400 --> 00:56:20,920
functional programming 
principles. 

1059
00:56:20,920 --> 00:56:25,120
Just clean coding principles to 
the problem of test automation. 

1060
00:56:25,520 --> 00:56:30,160
And also you start to step away 
from the screen, step away from 

1061
00:56:30,160 --> 00:56:32,890
the UI and think about. 
Hey, what is the business 

1062
00:56:32,890 --> 00:56:34,810
actually trying to do here? 
What is the task? 

1063
00:56:35,410 --> 00:56:40,610
And so I was talking to a team 
recently and using an approach 

1064
00:56:40,610 --> 00:56:44,770
that recommended a while back. 
Basically having a very clean 

1065
00:56:44,770 --> 00:56:48,450
separation of the description of
your tests, the description of 

1066
00:56:48,450 --> 00:56:50,610
what the business is trying to 
do, what the user is trying to 

1067
00:56:50,610 --> 00:56:54,290
do and how you implement that. 
And so they had cucumber 

1068
00:56:54,290 --> 00:56:57,010
scenarios where it was things 
like. 

1069
00:56:57,590 --> 00:57:00,950
Given I want to purchase some 
books, when I add these books to

1070
00:57:00,950 --> 00:57:04,190
the shopping cart, then the tax 
should be calculated correctly 

1071
00:57:04,670 --> 00:57:08,790
and then under the hood they had
three different implementations 

1072
00:57:08,790 --> 00:57:12,910
of that that they could hook in 
based on different tags and blue

1073
00:57:12,910 --> 00:57:16,070
code or whatnot. 
One implementation was through 

1074
00:57:16,070 --> 00:57:19,750
the UI, another implementation 
was through the API, another 

1075
00:57:19,750 --> 00:57:22,910
implementation was just with 
their pure domain logic, so 

1076
00:57:22,910 --> 00:57:26,860
effectively unit tests. 
And those 3 implementations were

1077
00:57:26,860 --> 00:57:29,980
all driven by the same Cucumber 
scenarios and that under the 

1078
00:57:29,980 --> 00:57:34,180
hood it was using actors but 
different tasks for those 

1079
00:57:34,180 --> 00:57:37,020
actors. 
And so I think the domain model 

1080
00:57:37,020 --> 00:57:40,340
was just a few unit tests, but 
the integration, the API calls 

1081
00:57:40,340 --> 00:57:44,980
and the UI calls, the code read 
very similar, It was an actor 

1082
00:57:44,980 --> 00:57:48,020
attempts to add these items to 
the shopping cart. 

1083
00:57:48,020 --> 00:57:49,660
Except there are two slight 
variations. 

1084
00:57:49,660 --> 00:57:52,540
One was going through the UI1 
was going through the API. 

1085
00:57:53,480 --> 00:57:56,040
And the cucumber layer never 
changed. 

1086
00:57:56,040 --> 00:57:59,160
It was the same for both 
implementations under the hood 

1087
00:57:59,160 --> 00:58:01,640
and the step definitions. 
The code was very similar, 

1088
00:58:02,040 --> 00:58:04,960
slightly different because it 
uses different tasks, but very 

1089
00:58:05,000 --> 00:58:06,880
relatable. 
You can read it and understand 

1090
00:58:06,880 --> 00:58:09,440
what I was doing. 
The only real difference was in 

1091
00:58:09,440 --> 00:58:11,160
the implementation of those 
tasks. 

1092
00:58:11,560 --> 00:58:14,360
Now that sort of approach would 
be impossible to do. 

1093
00:58:14,880 --> 00:58:17,960
If you start off with the 
mindset of I'm going to use Page

1094
00:58:17,960 --> 00:58:20,720
Objects, you can only have that,
sort of. 

1095
00:58:21,050 --> 00:58:23,970
Level of abstraction. 
When you think in terms of, I'm 

1096
00:58:23,970 --> 00:58:26,570
going to model how my user 
interacts with the system in 

1097
00:58:26,570 --> 00:58:29,090
business language. 
Then I'm going to decide what 

1098
00:58:29,090 --> 00:58:30,570
the best way to implement that 
is. 

1099
00:58:30,890 --> 00:58:34,890
What task do I need, does the 
business the user need to do? 

1100
00:58:34,890 --> 00:58:37,450
And then how will those tasks 
actually be performed? 

1101
00:58:37,490 --> 00:58:39,890
And the screenplay is not the 
only way of doing that, but it 

1102
00:58:39,890 --> 00:58:42,050
is a very elegant way of doing 
that. 

1103
00:58:42,850 --> 00:58:46,610
Wow, it sounds really powerful. 
So I think having a unified 

1104
00:58:46,610 --> 00:58:50,030
cucumber feature test. 
And you can have a different 

1105
00:58:50,030 --> 00:58:51,990
implementation details, so to 
speak, right. 

1106
00:58:52,030 --> 00:58:55,590
I think that's really powerful. 
So yeah, going to the Serenity 

1107
00:58:55,590 --> 00:58:57,630
part, right. 
So maybe if one of you can also 

1108
00:58:57,630 --> 00:59:00,310
share what kind of cool project 
that you're doing with this 

1109
00:59:00,310 --> 00:59:04,630
Serenity library. 
I can take the JavaScript part, 

1110
00:59:05,070 --> 00:59:08,590
so I'm the maintainer of 
Serenity JS project. 

1111
00:59:09,030 --> 00:59:13,390
So in terms of screenplay, just 
to maybe build on what John's 

1112
00:59:13,390 --> 00:59:15,430
already said. 
But I think what's really, 

1113
00:59:15,430 --> 00:59:17,310
really important about 
screenplay is that. 

1114
00:59:17,780 --> 00:59:21,020
It helps you focus on the 
business language and business 

1115
00:59:21,020 --> 00:59:23,900
domain and avoid the 
implementation details. 

1116
00:59:23,900 --> 00:59:26,020
I mean, you think about it from 
the implementation perspective, 

1117
00:59:26,020 --> 00:59:27,460
it's actually very, very 
important. 

1118
00:59:27,860 --> 00:59:31,340
Your company, your business, the
way your business processes 

1119
00:59:31,340 --> 00:59:35,980
work, those tends to change much
less frequently than the 

1120
00:59:35,980 --> 00:59:38,300
software systems that we 
implement to support them, 

1121
00:59:38,500 --> 00:59:41,140
right. 
Typically a bank would be doing 

1122
00:59:41,140 --> 00:59:43,540
their business in a very similar
way over the last 100 years, 

1123
00:59:43,540 --> 00:59:45,900
right? 
Or an airline or an automotive 

1124
00:59:45,900 --> 00:59:48,190
company, right? 
Unless you restart the pivot 

1125
00:59:48,190 --> 00:59:51,510
step product every week or so, 
then typically the way the 

1126
00:59:51,510 --> 00:59:54,870
vocabulary use the processes you
use there, they tend to remain 

1127
00:59:54,870 --> 00:59:57,790
fairly constant. 
It's just we constantly rebuild 

1128
00:59:57,790 --> 00:59:59,710
the software systems that 
support them because new 

1129
00:59:59,750 --> 01:00:02,470
technologies come along. 
So if you focus on expressing 

1130
01:00:02,470 --> 01:00:06,070
those test scenarios from the 
perspective of the business, you

1131
01:00:06,070 --> 01:00:09,910
will see much less change in the
overall flow of the scenarios, 

1132
01:00:10,390 --> 01:00:13,190
probably a bit more change on 
the implementation side or the 

1133
01:00:13,190 --> 01:00:16,860
integration side, so. 
Now going back to your question 

1134
01:00:16,860 --> 01:00:19,620
Henry about 70 JS. 
There's a lot of interesting 

1135
01:00:19,620 --> 01:00:23,100
things that the 70 JS team is 
doing right now with all the new

1136
01:00:23,100 --> 01:00:25,140
features. 
So recently we've introduced 

1137
01:00:25,140 --> 01:00:29,980
Strengthy JS 3.0. 
Now one interesting feature. 

1138
01:00:30,460 --> 01:00:32,540
Many of those, but the most 
interesting feature about Synt 

1139
01:00:32,540 --> 01:00:36,740
JS is that introduces a 
universal web facade. 

1140
01:00:37,140 --> 01:00:40,100
What it basically means is that 
you can create your automated 

1141
01:00:40,100 --> 01:00:43,300
tests using strengthy JS, 
screenplay pattern, building 

1142
01:00:43,300 --> 01:00:47,050
blocks, interactions and 
questions and you can then plug 

1143
01:00:47,530 --> 01:00:50,890
any web integration tool it's 
going to be supported into your 

1144
01:00:50,890 --> 01:00:53,170
tests. 
So you can run the exact same 

1145
01:00:53,170 --> 01:00:58,330
scenario using Webdriver IO or 
playwright or Protractor or 

1146
01:00:58,330 --> 01:01:02,170
puppeteer, which basically 
allows you to be completely 

1147
01:01:02,170 --> 01:01:04,370
vendor agnostic. 
So should there be a better 

1148
01:01:04,370 --> 01:01:08,430
integration tool in the future 
or you need to change from one 

1149
01:01:08,430 --> 01:01:10,870
tool to another or you want to 
share your code across different

1150
01:01:10,870 --> 01:01:14,110
teams that use different tools? 
You can do it again thanks to 

1151
01:01:14,110 --> 01:01:16,910
the abstraction and thanks for 
focusing on the business 

1152
01:01:16,910 --> 01:01:20,230
vocabulary. 
One other interesting feature 

1153
01:01:20,230 --> 01:01:23,110
that we've introduced recently 
is component testing. 

1154
01:01:23,470 --> 01:01:26,670
So apart from doing N 20 web 
testing, I think we typically 

1155
01:01:26,670 --> 01:01:28,310
use an acceptance testing 
framework for. 

1156
01:01:28,550 --> 01:01:31,030
You can also do component 
testing now so you can test 

1157
01:01:31,030 --> 01:01:35,060
individual react or view or 
spell or solid components using 

1158
01:01:35,060 --> 01:01:38,420
string, JS and tray right? 
So you can design and develop 

1159
01:01:38,420 --> 01:01:41,140
your low level interactions and 
questions. 

1160
01:01:41,140 --> 01:01:44,500
Again scripting pattern, 
building blocks in a very 

1161
01:01:44,580 --> 01:01:47,580
confined space of a single 
component and then plug them 

1162
01:01:47,580 --> 01:01:50,460
into your end to end tests. 
Now what this allows you to do, 

1163
01:01:50,460 --> 01:01:53,260
It allows you to share test 
automation code between 

1164
01:01:53,260 --> 01:01:56,500
component teams and to end teams
or product teams. 

1165
01:01:56,900 --> 01:02:00,520
So for example if you have a 
component team building a design

1166
01:02:00,520 --> 01:02:03,920
system for a company building 
color and widgets and drop down 

1167
01:02:03,920 --> 01:02:07,040
boxes and so on, they can 
provide you with test code that 

1168
01:02:07,040 --> 01:02:09,120
interacts with those specific 
components. 

1169
01:02:09,680 --> 01:02:12,880
And if you want to incorporate 
those components into a larger 

1170
01:02:12,880 --> 01:02:15,280
system and write an end to end 
test and detect those 

1171
01:02:15,280 --> 01:02:18,880
components, you can simply plug 
in this test alteration code 

1172
01:02:18,880 --> 01:02:21,960
that's already been tested at 
the uni level into your end to 

1173
01:02:21,960 --> 01:02:24,430
end tests. 
Now if you think about it, this 

1174
01:02:24,430 --> 01:02:28,470
approach removes completely the 
problem of trying to figure out 

1175
01:02:28,510 --> 01:02:31,230
what CSS selector should I use 
to interact with a specific 

1176
01:02:31,230 --> 01:02:32,670
component or you don't care 
anymore. 

1177
01:02:33,070 --> 01:02:35,470
You just take a library to 
interact with a date picker, you

1178
01:02:35,470 --> 01:02:37,070
don't care how the date picker 
is built. 

1179
01:02:37,470 --> 01:02:41,350
This also allows your UI 
components team to have much 

1180
01:02:41,350 --> 01:02:44,310
greater flexibility and freedom 
because they don't need to worry

1181
01:02:44,310 --> 01:02:51,900
about all the other teams. 
So if you think about it, the 

1182
01:02:51,900 --> 01:02:55,500
great thing about being able to 
use the same patterns for 

1183
01:02:55,500 --> 01:02:58,700
different kinds of testing, so 
end to end testing or acceptance

1184
01:02:58,700 --> 01:03:01,580
testing, performance testing, 
component testing, is that you 

1185
01:03:01,580 --> 01:03:05,020
actually get to reuse test code 
across all those different test 

1186
01:03:05,020 --> 01:03:08,140
suites so you don't have to do 
your work from scratch. 

1187
01:03:08,140 --> 01:03:10,140
You don't have to start from 
scratch every single time. 

1188
01:03:10,460 --> 01:03:13,100
Once you have a piece of code 
that works, you can just plug it

1189
01:03:13,180 --> 01:03:15,860
into another test suite and run 
it in a different context. 

1190
01:03:16,340 --> 01:03:19,060
Now it's particularly 
interesting in the context of 

1191
01:03:19,060 --> 01:03:22,140
component testing. 
So if you think about it, 1 

1192
01:03:22,500 --> 01:03:25,540
popular pattern that's very 
often used across especially 

1193
01:03:25,540 --> 01:03:29,300
large enterprises is that you 
would have component teams, UI 

1194
01:03:29,300 --> 01:03:33,340
component teams that develop 
design systems or UI widgets for

1195
01:03:33,340 --> 01:03:35,940
other teams to use. 
So you might have a component 

1196
01:03:35,940 --> 01:03:40,220
team that designs charts or 
dates because or drop down boxes

1197
01:03:40,220 --> 01:03:43,300
or buttons for all the other 
teams to use and other teams 

1198
01:03:43,300 --> 01:03:47,940
would assemble those into your 
booking systems or trading 

1199
01:03:47,940 --> 01:03:51,600
dashboards or other sorts of UI 
applications. 

1200
01:03:52,040 --> 01:03:56,240
And this way by reusing the 
common UI components they ensure

1201
01:03:56,400 --> 01:03:59,200
a common look and feel of all 
those systems and they also 

1202
01:03:59,200 --> 01:04:01,920
reduce the amount of rework that
would be required. 

1203
01:04:02,000 --> 01:04:04,240
Either wanted to build all this 
stuff from scratch themselves. 

1204
01:04:04,720 --> 01:04:09,360
Now with the screenplay pattern 
and Serenity implementation of 

1205
01:04:09,360 --> 01:04:12,360
the screenplay pattern, what you
can do is you can share your 

1206
01:04:12,360 --> 01:04:15,400
test codes the exact same way 
you can share your production 

1207
01:04:15,400 --> 01:04:17,160
code. 
So again if we have our 

1208
01:04:17,160 --> 01:04:20,320
components team that designs 
this, no date picker or a drop 

1209
01:04:20,320 --> 01:04:25,440
down box or a button and so on. 
Apart from providing other teams

1210
01:04:25,440 --> 01:04:27,520
with this specific 
implementation of a component, 

1211
01:04:27,840 --> 01:04:31,080
they can also provide those 
teams with test codes to 

1212
01:04:31,080 --> 01:04:34,240
interact with those components. 
So if you have a date picker, 

1213
01:04:34,240 --> 01:04:38,280
you might have a screenplay task
to advance a month, or pick a 

1214
01:04:38,280 --> 01:04:42,240
date or get the current date, 
enter a value and so on. 

1215
01:04:43,190 --> 01:04:46,110
Another team using this specific
widget could now incorporate the

1216
01:04:46,110 --> 01:04:49,030
widget into the application and 
incorporate the widget specific 

1217
01:04:49,030 --> 01:04:51,030
test code into their N twin 
tests. 

1218
01:04:51,390 --> 01:04:54,590
So again, if you have a trading 
dashboard for instance, where 

1219
01:04:54,590 --> 01:04:57,870
you want to set a date of a 
trade, you don't have to think 

1220
01:04:57,870 --> 01:05:01,310
about well how the date picker 
is structured, what are the HTML

1221
01:05:01,670 --> 01:05:04,190
tags I need to use, what are the
CSS selectors? 

1222
01:05:04,190 --> 01:05:07,270
Now you don't have to discover 
this whole thing from scratch 

1223
01:05:07,310 --> 01:05:09,310
every single time. 
You don't have to handcraft it, 

1224
01:05:10,080 --> 01:05:13,280
you can simply reuse the code 
that the team who developed the 

1225
01:05:13,280 --> 01:05:14,880
widget has already provided you 
with. 

1226
01:05:14,880 --> 01:05:19,320
If you think about it, this is a
complete game changer in test 

1227
01:05:19,320 --> 01:05:23,840
automation because it allows you
to avoid rediscovery of basic 

1228
01:05:23,840 --> 01:05:26,000
things like selectors and 
structures all over the 

1229
01:05:26,000 --> 01:05:29,040
enterprise, something all over 
again, and then seeing all the 

1230
01:05:29,040 --> 01:05:32,200
test suites break if someone 
changes even a slight thing in a

1231
01:05:32,200 --> 01:05:34,680
widget. 
It allows you to simply reuse 

1232
01:05:34,680 --> 01:05:37,820
test code the same way you would
reuse production code, and 

1233
01:05:37,820 --> 01:05:42,340
completely addresses this whole 
class of problems around how do 

1234
01:05:42,340 --> 01:05:44,700
I find the right selector for 
this widget? 

1235
01:05:44,780 --> 01:05:46,980
Well, you don't care. 
You don't need to worry about 

1236
01:05:46,980 --> 01:05:48,980
the selectors. 
You need to care about the 

1237
01:05:48,980 --> 01:05:53,420
business scenario to be able to 
prove or verify that a trader 

1238
01:05:53,420 --> 01:05:56,740
can book a trade, that a 
traveler can book a plane 

1239
01:05:56,740 --> 01:05:59,420
ticket, that a shopper can now 
put a thing into their basket. 

1240
01:05:59,420 --> 01:06:02,380
You don't need to care about the
CSS selectors that you need to 

1241
01:06:02,380 --> 01:06:03,980
use to interact the shopping 
basket. 

1242
01:06:04,060 --> 01:06:08,150
Simply reuse the test code. 
So that's an absolutely amazing 

1243
01:06:08,150 --> 01:06:10,710
thing and completely on game 
changer for many teams that have

1244
01:06:10,710 --> 01:06:12,830
been using particularly security
JS. 

1245
01:06:13,430 --> 01:06:17,390
And yeah, I'm actually looking 
forward to how it gets adopted 

1246
01:06:17,390 --> 01:06:21,990
in the rest of the industry. 
Thank you so much for explaining

1247
01:06:21,990 --> 01:06:25,430
in depth about this Serenity JS,
so I think I will put it in the 

1248
01:06:25,430 --> 01:06:27,910
show notes for people who are 
interested in this screenplay 

1249
01:06:27,910 --> 01:06:29,190
pattern. 
That's the first thing, right? 

1250
01:06:29,510 --> 01:06:32,270
And especially if you have 
JavaScript project, feel free to

1251
01:06:32,870 --> 01:06:34,750
try to incorporate this Serenity
JS. 

1252
01:06:35,140 --> 01:06:38,460
I'm a big fan of Serenity JS. 
I'd use it for any sort of front

1253
01:06:38,460 --> 01:06:41,140
end project or even front end 
plus APIs. 

1254
01:06:41,260 --> 01:06:44,300
If you've got a team who's 
familiar with TypeScript and 

1255
01:06:44,300 --> 01:06:47,020
JavaScript, or if the testers 
are happy to learn that or 

1256
01:06:47,020 --> 01:06:49,180
familiar with that, it really is
a no brainer. 

1257
01:06:49,180 --> 01:06:52,620
One of the things I find really 
cool about that and we'll talk 

1258
01:06:52,660 --> 01:06:56,700
about Serenity BDD, but Serenity
BDD is basically the Java. 

1259
01:06:57,480 --> 01:07:00,680
Implementation of the screenplay
pattern, and there's a lot of 

1260
01:07:00,680 --> 01:07:04,000
other stuff that goes with it, 
but it's a similar concept in 

1261
01:07:04,000 --> 01:07:08,160
the Java world. 
So often in teams that I coach, 

1262
01:07:08,440 --> 01:07:13,560
what I'd try to suggest is if 
they're doing front end work or 

1263
01:07:13,560 --> 01:07:17,240
UI work or if they come to with 
JavaScript and they should offer

1264
01:07:17,240 --> 01:07:21,560
Serenity JS because of just the 
reusable components and the way 

1265
01:07:21,560 --> 01:07:23,520
it's fits nicely into the front 
end. 

1266
01:07:24,150 --> 01:07:27,470
Build cycles and when they're 
working on either back end 

1267
01:07:27,470 --> 01:07:31,910
components or sometimes end to 
end scenarios, if they're more 

1268
01:07:31,910 --> 01:07:35,910
comfortable with the Java world,
then that's where anything BDD 

1269
01:07:35,910 --> 01:07:39,030
allows that as well. 
It integrates with API testing 

1270
01:07:39,030 --> 01:07:42,990
and UI testing with Selenium and
playwright and does all the nice

1271
01:07:42,990 --> 01:07:45,990
screenplay stuff so you can 
create those reusable business 

1272
01:07:45,990 --> 01:07:48,790
components. 
But in both cases, what I really

1273
01:07:48,790 --> 01:07:52,600
find powerful sort of what? 
Yarn was alluding to is the idea

1274
01:07:52,600 --> 01:07:55,560
that what screenplay does it 
helps you step away from the 

1275
01:07:55,720 --> 01:07:58,880
implementation, and we've 
actually used it. 

1276
01:07:58,880 --> 01:08:03,320
One of the first big screenplay 
projects we did was with teams 

1277
01:08:03,320 --> 01:08:07,040
where the testers were not 
particularly experienced with 

1278
01:08:07,080 --> 01:08:09,600
either the domain or with even 
Java. 

1279
01:08:10,120 --> 01:08:14,520
And so the way we got that team 
to sort of scale their 

1280
01:08:14,520 --> 01:08:19,080
automation and to. 
Produce more automated tests 

1281
01:08:19,160 --> 01:08:24,520
than anyone expected was by 
getting more experienced 

1282
01:08:24,640 --> 01:08:28,040
developers or testers to write 
these tasks. 

1283
01:08:28,040 --> 01:08:31,439
So write the task of place a 
trade or place a booking or 

1284
01:08:31,800 --> 01:08:36,520
create a customer which actually
interact with an API or a UI or 

1285
01:08:36,520 --> 01:08:40,279
a screen or whatever they need 
to interact with and then other 

1286
01:08:40,279 --> 01:08:42,200
testers who are maybe less 
experienced. 

1287
01:08:43,050 --> 01:08:48,050
They can assemble those tasks 
just like Lego blocks, and reuse

1288
01:08:48,050 --> 01:08:50,930
those tasks without having to 
worry about what's selected to 

1289
01:08:50,930 --> 01:08:54,090
use. 
And if they need to extend it or

1290
01:08:54,090 --> 01:08:57,850
add a new task, they can look at
what's already been done and 

1291
01:08:58,010 --> 01:09:01,810
start to learn how that works. 
But they've already got this set

1292
01:09:01,810 --> 01:09:06,250
of building blocks which is very
focused not on how to click on a

1293
01:09:06,250 --> 01:09:09,330
button, but on how to interact 
with the business domain. 

1294
01:09:10,529 --> 01:09:13,500
And that's something. 
You see a lot of the low code 

1295
01:09:13,500 --> 01:09:17,300
tools these days. 
None of them go anywhere near 

1296
01:09:17,300 --> 01:09:18,899
that. 
None of them are able to. 

1297
01:09:18,899 --> 01:09:22,100
The best low code tool in my 
experience is when you create it

1298
01:09:22,100 --> 01:09:23,939
yourself and it maps to your 
domain. 

1299
01:09:24,819 --> 01:09:28,580
All of the low code tools that 
we're seeing now there might be 

1300
01:09:28,580 --> 01:09:32,180
exceptions, but I'm not sure how
they could be, are very much 

1301
01:09:32,180 --> 01:09:35,700
focused on just basically 
scripting out low level 

1302
01:09:35,700 --> 01:09:39,010
interactions and. 
If you've got a good marketing 

1303
01:09:39,010 --> 01:09:41,250
team, you might be able to sell 
that well because it makes it 

1304
01:09:41,250 --> 01:09:44,410
feel easy to click on a button. 
But that's not where you get the

1305
01:09:44,410 --> 01:09:45,930
leverage. 
Where you get the leverage is 

1306
01:09:45,930 --> 01:09:49,410
where you can reuse business 
components and model business 

1307
01:09:49,410 --> 01:09:51,649
domains and actually understand 
that you are testing the 

1308
01:09:51,649 --> 01:09:54,690
important stuff and scaling your
tests. 

1309
01:09:54,690 --> 01:09:58,250
So if you have an end to end 
flow where you're on board a 

1310
01:09:58,250 --> 01:10:00,210
customer of a particular type 
and may. 

1311
01:10:00,610 --> 01:10:03,650
Take them through a long Kyz 
process and get them out the 

1312
01:10:03,650 --> 01:10:05,810
other side and make sure you've 
got heaps of systems that 

1313
01:10:05,810 --> 01:10:08,490
interact together correctly and 
then you need to do another flow

1314
01:10:08,490 --> 01:10:09,890
with a different type of 
customer. 

1315
01:10:10,650 --> 01:10:12,770
You can scale that really well 
because you have all these 

1316
01:10:12,770 --> 01:10:16,970
reusable components. 
If you had to re script that, 

1317
01:10:17,330 --> 01:10:22,170
even with low code tools that's 
still quite a headache. 

1318
01:10:22,170 --> 01:10:24,290
When you actually start to do 
things at scale. 

1319
01:10:24,700 --> 01:10:27,780
So I think that reusability, I 
mean, it does take some planning

1320
01:10:27,780 --> 01:10:29,580
and some thought and some 
design. 

1321
01:10:29,580 --> 01:10:33,060
And that's where the BDD aspect 
tells, because it does make you 

1322
01:10:33,060 --> 01:10:35,340
think about modeling the domain 
concepts. 

1323
01:10:35,780 --> 01:10:37,540
That's where you get the 
scalability. 

1324
01:10:38,380 --> 01:10:42,420
One more thing to add to that, 
so people often ask us so should

1325
01:10:42,420 --> 01:10:44,980
I choose Strengthy JS or should 
I choose Strengthy BDD? 

1326
01:10:44,980 --> 01:10:47,740
Which one's better? 
I mean that's not really the 

1327
01:10:48,270 --> 01:10:49,550
question that that's really 
important here. 

1328
01:10:49,550 --> 01:10:52,190
So if you think about it now you
can use either. 

1329
01:10:52,310 --> 01:10:55,710
If your product is predominantly
using a JVM language, now 

1330
01:10:55,830 --> 01:10:58,710
certainty is a perfect choice. 
If it's not predominantly front 

1331
01:10:58,710 --> 01:11:01,030
end or scripting languages, 
trying to just is great. 

1332
01:11:01,070 --> 01:11:04,190
But it was interesting that both
frameworks use the same 

1333
01:11:04,190 --> 01:11:07,270
reporting engine. 
So in fact you would actually 

1334
01:11:07,270 --> 01:11:11,070
use both Serenty JS and Serenty 
BD on the same project and many 

1335
01:11:11,070 --> 01:11:12,710
teams do that. 
So now sometimes you might have 

1336
01:11:12,710 --> 01:11:15,590
a huge mono repo and know some 
back end services using Serenty 

1337
01:11:15,590 --> 01:11:17,270
BD. 
The front end was using Serenty 

1338
01:11:17,270 --> 01:11:20,800
JS, but what you can do is you 
can actually make them produce 

1339
01:11:21,040 --> 01:11:25,440
reports that get combined and 
the result in a unified leading 

1340
01:11:25,440 --> 01:11:27,160
documentation of your entire 
system. 

1341
01:11:27,560 --> 01:11:30,880
So we've come across cases like 
that, so we've made strength to 

1342
01:11:30,880 --> 01:11:32,960
JS and strength to BD support 
this case as well. 

1343
01:11:33,560 --> 01:11:36,480
Might have the favorite from 
working with more complex 

1344
01:11:36,480 --> 01:11:40,880
requirements like finance, 
insurance and whatnot is feature

1345
01:11:40,880 --> 01:11:45,680
mapping, which I find a really 
nice way of mapping out. 

1346
01:11:46,000 --> 01:11:50,760
User journeys, mapping out 
variations of what a user 

1347
01:11:50,760 --> 01:11:53,320
actually does or how data gets 
transformed. 

1348
01:11:53,320 --> 01:11:55,960
So it might be a user, it might 
also be a client record. 

1349
01:11:56,000 --> 01:11:59,400
There are lots of different ways
of looking at how a process 

1350
01:11:59,400 --> 01:12:03,880
works, so feature mapping is 
very good at analyzing, walking 

1351
01:12:03,880 --> 01:12:08,080
through, and visualizing how a 
process actually plays out and 

1352
01:12:08,080 --> 01:12:10,600
what are the goals, what are the
outcomes we're trying to 

1353
01:12:10,600 --> 01:12:12,750
achieve. 
And a little bit more than say 

1354
01:12:12,750 --> 01:12:15,350
story mapping which is much 
broader feature mapping is very 

1355
01:12:15,350 --> 01:12:19,310
focused on a particular use case
and how we look at the 

1356
01:12:19,310 --> 01:12:22,990
variations around that. 
And the close second would be 

1357
01:12:22,990 --> 01:12:26,030
example mapping, which is the 
sort of go to tool I find just 

1358
01:12:26,030 --> 01:12:29,990
for getting clarity on what 
we're trying to do. 

1359
01:12:29,990 --> 01:12:33,550
It's really very deceptively 
simple but very effective 

1360
01:12:33,550 --> 01:12:37,270
technique for mapping out 
examples for identifying 

1361
01:12:37,270 --> 01:12:39,990
examples and counter examples 
and hunting out new ones. 

1362
01:12:41,010 --> 01:12:43,850
I think my other personal 
favorite is impact mapping. 

1363
01:12:44,170 --> 01:12:46,570
And the reason why I would like 
the impact mapping is because it

1364
01:12:46,570 --> 01:12:51,570
helps you to create this very 
easy to see visual association 

1365
01:12:51,570 --> 01:12:55,290
between the goal you're trying 
to accomplish, the actors that 

1366
01:12:55,530 --> 01:12:58,330
can help you accomplish this 
goal or can hinder your 

1367
01:12:58,330 --> 01:13:01,290
progress. 
It can help you understand the 

1368
01:13:01,410 --> 01:13:05,290
behaviors you want to change, 
and form some hypothesis around 

1369
01:13:05,290 --> 01:13:06,930
how you're going to change those
behaviors. 

1370
01:13:08,100 --> 01:13:11,820
What this allows us to do when 
using impact mapping tells us to

1371
01:13:11,820 --> 01:13:16,660
create a very good communication
link between typically business 

1372
01:13:16,660 --> 01:13:19,340
sponsors and the delivery team. 
Because business sponsors 

1373
01:13:19,380 --> 01:13:22,300
understand the goals very well, 
they tend to have a very good 

1374
01:13:22,300 --> 01:13:24,700
understanding of what is the 
audience they're trying to 

1375
01:13:25,060 --> 01:13:27,060
address with whatever 
functionality they want to ship.

1376
01:13:27,500 --> 01:13:31,420
Now developers have a very good 
understanding of deliverables of

1377
01:13:31,420 --> 01:13:34,900
the features they can build. 
So what those two parties need 

1378
01:13:34,900 --> 01:13:37,740
to figure out is how actually we
can now create those 

1379
01:13:37,740 --> 01:13:40,540
deliverables, how we can create 
software in order to change the 

1380
01:13:40,540 --> 01:13:43,580
behavior of the groups that we 
want to affect in order to 

1381
01:13:43,580 --> 01:13:47,260
accomplish our goal. 
So it's a really nice way to use

1382
01:13:47,260 --> 01:13:50,940
when you facilitate workshops 
between business and technical 

1383
01:13:51,060 --> 01:13:53,340
people. 
Thanks for sharing some of these

1384
01:13:53,340 --> 01:13:55,620
techniques if people are 
interested to learn more. 

1385
01:13:55,620 --> 01:13:58,860
I think the book covers some of 
these techniques in detail 

1386
01:13:58,860 --> 01:14:00,460
right? 
Including examples and 

1387
01:14:00,460 --> 01:14:03,100
fictitious stories how this can 
be applied. 

1388
01:14:03,380 --> 01:14:06,620
And I think I would also suggest
people reading a lot more about 

1389
01:14:06,620 --> 01:14:08,780
these techniques because they 
can really make the 

1390
01:14:08,780 --> 01:14:12,020
collaboration effort much more 
productive I would say and 

1391
01:14:12,020 --> 01:14:15,780
effective. 
So one thing about BDD that I 

1392
01:14:15,780 --> 01:14:19,100
always think people get confused
where we should apply it right? 

1393
01:14:19,100 --> 01:14:21,580
Because there is a unit test 
integration test. 

1394
01:14:21,910 --> 01:14:25,110
API tests, UI tests and so many 
other tests, right? 

1395
01:14:25,550 --> 01:14:28,270
Maybe a bit of wisdom here. 
Where should BDD be applied? 

1396
01:14:28,270 --> 01:14:30,270
Can it be applied to all of 
them? 

1397
01:14:30,310 --> 01:14:32,150
Or maybe yeah, based on your 
experience. 

1398
01:14:33,110 --> 01:14:36,150
That's a really good question 
and I tend to answer it by 

1399
01:14:36,150 --> 01:14:39,950
saying you want to use what I 
call the lowest responsible 

1400
01:14:39,950 --> 01:14:43,550
level of automation. 
And what I mean by that is what 

1401
01:14:43,550 --> 01:14:47,630
is the lowest possible level you
can automate and still have 

1402
01:14:47,630 --> 01:14:50,550
confidence that your feature has
been implemented so BDD 

1403
01:14:50,550 --> 01:14:53,550
transcends. 
End to end unit integration. 

1404
01:14:53,550 --> 01:14:56,670
It can be any of those. 
Any test can be a BDD test. 

1405
01:14:56,670 --> 01:15:00,830
A BDD test is simply a way of 
illustrating it that a 

1406
01:15:00,830 --> 01:15:03,670
particular business requirement 
has been implemented and you 

1407
01:15:03,670 --> 01:15:06,030
could do that with the unit test
or you could do that with an end

1408
01:15:06,030 --> 01:15:08,630
to end test. 
If you take our example of for 

1409
01:15:08,630 --> 01:15:13,310
the product catalog adding a new
column, you might have a BDD 

1410
01:15:13,310 --> 01:15:17,400
scenario where you say well. 
Given Sally is on the shopping 

1411
01:15:17,680 --> 01:15:21,000
search page when she searches 
for some addresses and she 

1412
01:15:21,000 --> 01:15:24,880
should see the following dresses
with these color options and 

1413
01:15:24,920 --> 01:15:26,840
that. 
Would that be a unit test? 

1414
01:15:26,840 --> 01:15:29,160
Would it be a UI test? 
Would it be an end to end test? 

1415
01:15:29,160 --> 01:15:31,520
An API test? 
It could be combinations of all 

1416
01:15:31,520 --> 01:15:34,120
of those. 
Whatever, depending on your 

1417
01:15:34,120 --> 01:15:38,000
architecture will be the most 
efficient way of testing that. 

1418
01:15:38,000 --> 01:15:41,200
It could be any of those, so 
it's not a specific. 

1419
01:15:41,850 --> 01:15:45,370
You don't implement BDD at a 
specific level, you implement at

1420
01:15:45,370 --> 01:15:47,490
the level which makes the most 
sense, and. 

1421
01:15:48,290 --> 01:15:51,170
I think throughout that, one of 
the things I really like about 

1422
01:15:51,170 --> 01:15:56,330
this BDD approach, so focusing 
on the observable behavior of 

1423
01:15:56,330 --> 01:15:58,450
the piece of software we're 
actually interacting with, be 

1424
01:15:58,450 --> 01:16:01,370
the system as a whole, being a 
component, being a unit or a 

1425
01:16:01,370 --> 01:16:04,530
function and so on, is that 
you're focusing on the 

1426
01:16:04,530 --> 01:16:08,560
observable outcome now. 
What you can also do with those 

1427
01:16:08,560 --> 01:16:13,120
tests is you can now describe 
what should a given piece of 

1428
01:16:13,120 --> 01:16:15,440
your software do. 
So what you're doing in those 

1429
01:16:15,440 --> 01:16:18,040
tests you are not simply 
specifying what the system 

1430
01:16:18,040 --> 01:16:19,920
already does, So what a 
component or a function already 

1431
01:16:19,920 --> 01:16:21,760
does. 
You're specifying what it should

1432
01:16:21,760 --> 01:16:23,560
do. 
Now, why is this important? 

1433
01:16:23,920 --> 01:16:26,480
This thing that we all suffer 
from, that's called confirmation

1434
01:16:26,480 --> 01:16:30,040
bias, which is basically the 
tendency to seek out and prefer 

1435
01:16:30,040 --> 01:16:33,120
information that supports our 
preexisting beliefs. 

1436
01:16:33,440 --> 01:16:35,560
One of the preexisting beliefs 
that all software developers 

1437
01:16:35,560 --> 01:16:38,000
have is that now our software, 
the one we've just written, is 

1438
01:16:38,000 --> 01:16:40,960
perfect, right? 
So if we write the software and 

1439
01:16:40,960 --> 01:16:44,120
we write the test after that, 
what we tend to do is we tend to

1440
01:16:44,120 --> 01:16:45,840
confirm what we've already 
written. 

1441
01:16:46,260 --> 01:16:48,380
In the test. 
So for example, I might have a 

1442
01:16:48,820 --> 01:16:51,540
customer class. 
I create a test that now I can 

1443
01:16:51,540 --> 01:16:54,140
set the address and I can get 
this sweet address from this 

1444
01:16:54,140 --> 01:16:57,540
customer, which is great. 
So I have just now confirmed 

1445
01:16:57,540 --> 01:16:59,620
that my code does what I told it
to do. 

1446
01:16:59,980 --> 01:17:01,900
Big achievements, right? 
Here's my gold medal. 

1447
01:17:02,180 --> 01:17:04,580
But what is much more 
interesting was what are the 

1448
01:17:04,620 --> 01:17:07,860
implications for the system of 
the customer changing their 

1449
01:17:07,860 --> 01:17:09,820
address. 
What should happen in the system

1450
01:17:09,820 --> 01:17:11,180
when the customer changes the 
address? 

1451
01:17:11,180 --> 01:17:12,820
Should their default settings 
change? 

1452
01:17:13,100 --> 01:17:16,580
Where we make this change now 
with BDD, we're focusing on the 

1453
01:17:16,580 --> 01:17:18,580
outcomes. 
So what we can do in our test 

1454
01:17:18,580 --> 01:17:21,620
scenarios is rather than saying 
that my set address method 

1455
01:17:21,620 --> 01:17:24,860
works, we're saying that when a 
customer changes their address, 

1456
01:17:24,900 --> 01:17:27,660
their default tax rates should 
change to whatever state they 

1457
01:17:27,660 --> 01:17:30,420
are in right now. 
Now this is much more useful 

1458
01:17:30,460 --> 01:17:32,900
from the business perspective as
well because now. 

1459
01:17:33,340 --> 01:17:35,260
Know. 
Should this test fail you know 

1460
01:17:35,300 --> 01:17:38,340
exactly what business 
functionality is affected. 

1461
01:17:38,340 --> 01:17:42,060
You can know easily judge the 
impact on your business based on

1462
01:17:42,060 --> 01:17:44,660
the failure of the test. 
If you tell a business person 

1463
01:17:44,660 --> 01:17:46,900
that, well, you know what? 
I have this unit test failing 

1464
01:17:46,900 --> 01:17:49,620
that was testing just one method
in a class that you've already 

1465
01:17:49,620 --> 01:17:51,340
forgotten about. 
I mean, should we know? 

1466
01:17:51,340 --> 01:17:53,460
Stop the release. 
The business person will be like

1467
01:17:53,740 --> 01:17:55,300
what? 
What are you talking about? 

1468
01:17:55,700 --> 01:17:58,140
But now if you say, well 
actually with this those changes

1469
01:17:58,140 --> 01:18:01,500
we just introduced, we've 
affected the behavior of how we 

1470
01:18:01,500 --> 01:18:04,940
calculate tax for our customers,
well, this will get you a much 

1471
01:18:04,940 --> 01:18:06,540
better answer from a business 
sponsor. 

1472
01:18:06,700 --> 01:18:08,300
Around the risk readiness of the
system. 

1473
01:18:09,180 --> 01:18:10,900
Thanks for expanding all those, 
right. 

1474
01:18:10,900 --> 01:18:12,900
So I think. 
I really like the confirmation 

1475
01:18:12,900 --> 01:18:16,420
bias that you mentioned, right. 
So we developers, if we have to 

1476
01:18:16,700 --> 01:18:20,300
incorporate new tests in our 
software, we always try to 

1477
01:18:20,300 --> 01:18:22,220
confirm whatever that we have 
written right. 

1478
01:18:22,540 --> 01:18:24,780
So not necessarily the quality 
would be much better. 

1479
01:18:25,480 --> 01:18:29,200
So both of you are very 
experienced in BDD and software 

1480
01:18:29,200 --> 01:18:30,840
testing in general. 
Even John mentioned in the 

1481
01:18:30,840 --> 01:18:33,640
beginning you have worked with 
BDD for 20 years. 

1482
01:18:33,760 --> 01:18:37,400
That's really a long time. 
Are there anti patterns, the 

1483
01:18:37,400 --> 01:18:40,040
common anti patterns that you 
see maybe your favorite anti 

1484
01:18:40,040 --> 01:18:43,040
patterns that you should advise 
us to avoid? 

1485
01:18:43,440 --> 01:18:47,520
Maybe some of anti patterns here
if you can mention there are so 

1486
01:18:47,520 --> 01:18:51,840
many I'd say the biggest. 
One is what we said at the 

1487
01:18:51,840 --> 01:18:54,800
start, treating BDD as a testing
activity. 

1488
01:18:55,480 --> 01:18:59,920
Because if BDD becomes 
considered as just another way 

1489
01:18:59,920 --> 01:19:03,840
of writing tests, it short 
circuits the whole BDD 

1490
01:19:03,840 --> 01:19:08,640
conversation process and drains 
a whole stack of most of its 

1491
01:19:08,640 --> 01:19:12,840
value in fact, and also makes it
actually harder to do what you 

1492
01:19:12,840 --> 01:19:15,440
set out originally to do, which 
is write the test if all you 

1493
01:19:15,440 --> 01:19:17,760
need to do is write is automate 
tests. 

1494
01:19:18,130 --> 01:19:20,890
So you don't need a BDD tool. 
You can do that perfectly well 

1495
01:19:20,890 --> 01:19:24,370
with any of the Java or 
JavaScript or Python testing 

1496
01:19:24,370 --> 01:19:27,010
tools that already exist. 
You don't need BDD for that. 

1497
01:19:27,530 --> 01:19:29,490
BDD is all about the 
collaboration. 

1498
01:19:29,490 --> 01:19:32,930
So the biggest anti pattern is 
writing test scripts in Gherkin.

1499
01:19:33,210 --> 01:19:37,610
The second big anti pattern is 
at the other end of the scale 

1500
01:19:37,610 --> 01:19:40,730
what we're saying earlier 
writing requirements in given, 

1501
01:19:40,730 --> 01:19:44,050
when then. 
So using the given, when, then 

1502
01:19:44,170 --> 01:19:47,770
notation as a way to write the 
requirements before you have the

1503
01:19:47,770 --> 01:19:51,970
conversation and not as a way to
confirm the understanding after 

1504
01:19:51,970 --> 01:19:54,370
the conversation. 
Because again that short 

1505
01:19:54,370 --> 01:19:58,730
circuits the conversation that 
introduces the cognitive biases 

1506
01:19:58,730 --> 01:20:01,530
that YA was talking about. 
But from the other direction, 

1507
01:20:01,810 --> 01:20:06,130
that you assume that whoever 
wrote these wonderful given when

1508
01:20:06,130 --> 01:20:07,810
then statements knows what 
they're talking about. 

1509
01:20:07,810 --> 01:20:10,610
So you don't question them, you 
assume that they're good. 

1510
01:20:11,090 --> 01:20:12,930
Whereas if you come up with 
something you're much more 

1511
01:20:12,930 --> 01:20:15,410
tentative and much more 
lightweight, you can have a much

1512
01:20:15,410 --> 01:20:18,050
more interesting conversation. 
So I'd say they're the two 

1513
01:20:18,050 --> 01:20:21,770
biggest anti patterns to avoid 
from my perspective, yeah, 

1514
01:20:21,770 --> 01:20:23,450
absolutely. 
I think the biggest one. 

1515
01:20:23,570 --> 01:20:26,730
Just like John said, is using 
BDD tools to avoid 

1516
01:20:26,730 --> 01:20:29,290
collaboration. 
That's kind of completely 

1517
01:20:29,290 --> 01:20:32,410
missing the point. 
Now interestingly enough, this 

1518
01:20:32,490 --> 01:20:34,890
typically happens out of good 
intentions actually. 

1519
01:20:34,890 --> 01:20:37,930
So you're very often see people 
new to behavior, different 

1520
01:20:37,930 --> 01:20:40,490
developments, like no product 
owners or business analysts. 

1521
01:20:40,900 --> 01:20:43,900
They're trying to ease some of 
the burden put on the 

1522
01:20:43,900 --> 01:20:46,940
development team, and they just 
try to write all the Cucumber 

1523
01:20:46,940 --> 01:20:50,220
scenarios before giving them to 
the developers just so that they

1524
01:20:50,220 --> 01:20:51,780
can avoid all this additional 
work. 

1525
01:20:51,780 --> 01:20:54,700
So they're trying to do the good
thing, but the outcome is the 

1526
01:20:54,700 --> 01:20:58,180
complete opposite. 
You might have testers write the

1527
01:20:58,220 --> 01:21:01,020
test scenarios in Cucumber so 
that they're easier to 

1528
01:21:01,020 --> 01:21:03,850
understand to other. 
People involved in software 

1529
01:21:03,850 --> 01:21:06,570
delivery, but then again they 
will write them typically from 

1530
01:21:06,570 --> 01:21:09,330
the point of view of a tester. 
So the producer test scripts 

1531
01:21:09,650 --> 01:21:13,370
full of implementation specific 
logic, talking about UI screens 

1532
01:21:13,370 --> 01:21:14,810
and clicking on buttons and so 
on. 

1533
01:21:15,250 --> 01:21:18,490
And what then typically happens 
is that now whoever reads this 

1534
01:21:18,490 --> 01:21:22,170
scenario who is not a tester by 
profession, they'll just now get

1535
01:21:22,170 --> 01:21:24,770
bored halfway through if you're 
lucky and they just say, yeah, 

1536
01:21:24,770 --> 01:21:26,970
okay fine, I trust you just go 
with the school. 

1537
01:21:27,250 --> 01:21:30,970
So again, we're missing the 
whole collaboration aspect of 

1538
01:21:31,130 --> 01:21:33,820
behavior driven. 
Development and I think the next

1539
01:21:33,820 --> 01:21:36,220
one is using UI to test 
everything. 

1540
01:21:36,220 --> 01:21:38,180
I think that's one of the more 
common ones. 

1541
01:21:38,180 --> 01:21:42,180
So very often people think of 
behavior driven development as 

1542
01:21:42,180 --> 01:21:45,780
using Cucumber to drive CD 
numeral playwright or Cyprus or 

1543
01:21:45,780 --> 01:21:49,980
whatever other web testing tool 
and uses that to verify your 

1544
01:21:49,980 --> 01:21:51,940
system. 
And again, that's a 

1545
01:21:51,940 --> 01:21:56,580
misconception, the whole idea of
expressing your executable 

1546
01:21:56,580 --> 01:21:59,320
specifications. 
In implementation agnostic 

1547
01:21:59,320 --> 01:22:02,760
manner is so that you can 
automate them using the fastest,

1548
01:22:02,760 --> 01:22:06,200
most sensible interface that 
makes sense in this particular 

1549
01:22:06,200 --> 01:22:07,640
context. 
That's what John was saying 

1550
01:22:08,040 --> 01:22:10,400
earlier about the lowest 
responsible level. 

1551
01:22:10,680 --> 01:22:14,080
If you can verify your business 
requirement at the unit level 

1552
01:22:14,080 --> 01:22:17,040
just by interacting with classes
and functions, awesome. 

1553
01:22:17,240 --> 01:22:19,320
This way you can avoid 
incorporating all the 

1554
01:22:19,320 --> 01:22:22,160
infrastructure in our databases,
docker, containers, all the 

1555
01:22:22,160 --> 01:22:24,920
other stuff just to verify. 
Something you can do at the unit

1556
01:22:24,920 --> 01:22:27,910
level, that's fine. 
BDD is not about using UI 

1557
01:22:27,910 --> 01:22:30,390
automation tools to verify a 
fully assembled system. 

1558
01:22:30,670 --> 01:22:33,470
It's about helping you 
collaborate with different 

1559
01:22:33,470 --> 01:22:36,470
parties involved in software 
delivery to understand what's 

1560
01:22:36,470 --> 01:22:39,070
actually required of your 
system, why you need to deliver 

1561
01:22:39,070 --> 01:22:42,150
it, and then to help you find 
the best possible way to 

1562
01:22:42,150 --> 01:22:45,590
automate your requirements. 
Either through the UI fine, but 

1563
01:22:45,590 --> 01:22:47,670
typically you'll have other 
better ways to do it. 

1564
01:22:48,550 --> 01:22:51,110
Thanks for sharing all these 
anti patterns I'm sure people. 

1565
01:22:51,190 --> 01:22:54,950
Will be able to relate to most 
of them, if not all I would say.

1566
01:22:55,430 --> 01:22:57,790
And I think that's a really key 
learning to end this 

1567
01:22:57,790 --> 01:23:00,710
conversation. 
So as we go to the end, I have 

1568
01:23:00,750 --> 01:23:03,710
only one last question for each 
of you, which is what I call 3. 

1569
01:23:03,710 --> 01:23:06,270
Technical leadership wisdom. 
So you can think of it like 

1570
01:23:06,270 --> 01:23:08,950
advice that you want to give to 
us to learn from you. 

1571
01:23:09,070 --> 01:23:11,830
So maybe one of you can share 
each your wisdom. 

1572
01:23:12,670 --> 01:23:16,830
Yep, sure. 
So I did come up with three tips

1573
01:23:16,830 --> 01:23:20,390
that hopefully are useful. 
The first is that good practices

1574
01:23:20,390 --> 01:23:22,230
transcend languages and 
frameworks. 

1575
01:23:22,230 --> 01:23:26,020
So the thing to remember is that
whatever technology you choose, 

1576
01:23:26,420 --> 01:23:30,460
it's less important than how you
actually use it and how your 

1577
01:23:30,460 --> 01:23:34,460
teams embrace it so you don't 
get too hung up on a particular 

1578
01:23:34,460 --> 01:23:36,700
technology or tool. 
Focus on the outcomes you're 

1579
01:23:36,700 --> 01:23:40,780
trying to achieve. 
The second one is think before 

1580
01:23:40,780 --> 01:23:43,740
you code. 
The time that you invest in 

1581
01:23:44,220 --> 01:23:47,060
understanding a problem and 
digging into the requirements 

1582
01:23:47,060 --> 01:23:50,740
and challenging your own 
assumptions pays off multiple 

1583
01:23:50,740 --> 01:23:53,610
times in preventing defects and 
waste. 

1584
01:23:54,090 --> 01:23:57,050
And the third gem would be lead 
by example. 

1585
01:23:57,330 --> 01:23:59,810
I find a lot of people will 
pontificate. 

1586
01:23:59,810 --> 01:24:02,090
I think it's a word. 
I'll say what she should be 

1587
01:24:02,090 --> 01:24:05,010
doing and tell people off 
because they're not doing the 

1588
01:24:05,010 --> 01:24:07,450
best practices. 
Don't tell people what to do, 

1589
01:24:07,450 --> 01:24:10,010
show them. 
And if you show that your own 

1590
01:24:10,010 --> 01:24:12,850
commitment to quality and 
learning and collaboration, then

1591
01:24:13,010 --> 01:24:15,490
you've got a much better chance 
of getting your team to follow. 

1592
01:24:16,250 --> 01:24:18,700
So maybe I'll just add one more 
to this list of. 

1593
01:24:18,700 --> 01:24:22,900
Three, so that we have four. 
When trying to optimize software

1594
01:24:23,140 --> 01:24:26,300
delivery processes, I see many 
organizations, many teams look 

1595
01:24:26,300 --> 01:24:28,300
at factors such as delivery 
speed. 

1596
01:24:28,660 --> 01:24:31,700
So how quickly can we ship new 
feature to production? 

1597
01:24:32,100 --> 01:24:34,740
However, what's much more 
important is whether those 

1598
01:24:34,740 --> 01:24:37,500
features actually solve the 
business problems they've been 

1599
01:24:37,500 --> 01:24:40,060
intended to solve. 
It's much more important to 

1600
01:24:40,060 --> 01:24:43,700
focus on doing the right thing 
than doing the wrong thing 

1601
01:24:43,700 --> 01:24:46,850
quickly. 
That's a perfect wisdom to end 

1602
01:24:46,850 --> 01:24:48,930
our conversation so. 
Thank you so much, John and 

1603
01:24:48,930 --> 01:24:51,090
Young for being here. 
If people want to connect with 

1604
01:24:51,090 --> 01:24:54,010
you, learn more about all these 
great practices, right? 

1605
01:24:54,210 --> 01:24:56,610
Is there a place where they can 
find both of you online? 

1606
01:24:57,490 --> 01:24:59,890
LinkedIn is usually the best 
place to find me. 

1607
01:25:00,170 --> 01:25:02,450
It's the easiest way to reach 
out and connect. 

1608
01:25:08,450 --> 01:25:10,730
If you'd like to learn more 
about our work, just connect on 

1609
01:25:10,730 --> 01:25:03,610
LinkedIn. 
That's probably. 

1610
01:25:03,610 --> 01:25:04,770
Yeah, it's probably the easiest 
way. 

1611
01:25:04,890 --> 01:25:06,490
Yeah, absolutely. 
Same here. 

1612
01:25:06,690 --> 01:25:08,250
So if you'd like to connect 
with. 

1613
01:25:11,770 --> 01:25:13,850
I'm Young Moloch. 
My colleague is John Ferguson 

1614
01:25:13,850 --> 01:25:15,840
Smart. 
Should be easy to look up. 

1615
01:25:16,160 --> 01:25:18,720
So yeah, hopefully we'll see you
all online. 

1616
01:25:19,320 --> 01:25:20,520
So thank you so much for your 
time. 

1617
01:25:20,520 --> 01:25:22,160
I really learned a lot about 
BDD. 

1618
01:25:22,160 --> 01:25:24,720
And generally good practice 
about software testing today. 

1619
01:25:25,440 --> 01:25:26,600
Thank you. 
It's been a pleasure. 

1620
01:25:27,000 --> 01:25:31,840
Thank you so much. 
Thank you for listening to this 

1621
01:25:31,840 --> 01:25:34,240
episode and for staying. 
Right until the end. 

1622
01:25:34,600 --> 01:25:37,760
If you highly enjoyed it, I 
would appreciate if you share it

1623
01:25:37,760 --> 01:25:40,760
with your friends and colleagues
who you think would also benefit

1624
01:25:40,760 --> 01:25:43,560
from listening to this episode 
and if you're new to the 

1625
01:25:43,560 --> 01:25:45,760
podcast. 
Make sure to subscribe and leave

1626
01:25:45,760 --> 01:25:47,840
me your valuable review and 
feedback. 

1627
01:25:48,160 --> 01:25:51,040
It helps me a lot in order to 
grow this podcast better. 

1628
01:25:51,560 --> 01:25:54,440
You can also find the full show 
notes of this conversation on 

1629
01:25:54,440 --> 01:25:57,400
the episode page at Techly 
journal dot def website, 

1630
01:25:57,720 --> 01:26:01,320
including the full transcript, 
interesting quotes, and links to

1631
01:26:01,320 --> 01:26:03,720
the resources mentioned from the
conversation. 

1632
01:26:04,160 --> 01:26:07,200
And lastly, make sure to 
subscribe to the show's mailing 

1633
01:26:07,200 --> 01:26:11,000
list on Techly journal dot def 
to get notified for any future 

1634
01:26:11,000 --> 01:26:13,280
episodes. 
Stay tuned for the next 

1635
01:26:13,280 --> 01:26:16,560
Technically Juno episode, and 
until then, goodbye.