1
00:00:00,200 --> 00:00:02,800
Thank you for listening and 
supporting the tekhelet journal 

2
00:00:02,800 --> 00:00:05,400
podcast. 
It is my ultimate pleasure to 

3
00:00:05,400 --> 00:00:08,800
serve you in the past two years.
I hope the podcast serves you 

4
00:00:08,800 --> 00:00:12,300
well and gives a lot of insights
that you can apply in your work 

5
00:00:12,300 --> 00:00:15,900
and Life as we are going to 
celebrate the 100th episode 

6
00:00:15,900 --> 00:00:19,400
soon, I would appreciate if you 
can drop a few words in our 

7
00:00:19,400 --> 00:00:22,500
survey related to your 
experience with the podcast. 

8
00:00:22,800 --> 00:00:26,300
And if you record your story or 
message in an audio format, we 

9
00:00:26,300 --> 00:00:28,900
may feature you in the podcast 
special episode. 

10
00:00:29,100 --> 00:00:32,900
The survey is I opened for both 
listeners and guess I'm looking 

11
00:00:32,900 --> 00:00:36,600
forward to hearing your message.
Soon, drop me the message on 

12
00:00:36,600 --> 00:00:40,400
technology. 
No WF. / celebrate Dash 100. 

13
00:00:40,900 --> 00:00:42,900
Here's the link one more time. 
Technology? 

14
00:00:42,900 --> 00:00:46,300
Know, the baths. 
Let's celebrate bash. 100-mile 

15
00:00:47,200 --> 00:00:51,900
definition of acceptance. 
Test is any test the system must

16
00:00:51,900 --> 00:00:57,000
pass in order to be accepted 
that can be provided by the 

17
00:00:57,000 --> 00:01:03,300
customer the users. 
The testers or anybody else and 

18
00:01:03,300 --> 00:01:07,000
if you can't ship the system 
without these tests. 

19
00:01:07,200 --> 00:01:09,400
Well, they are deep septons 
test. 

20
00:01:14,600 --> 00:01:17,400
Hey everyone. 
My name is Henry Surya with 

21
00:01:17,400 --> 00:01:20,700
Robin. 
And you're listening to the 

22
00:01:20,700 --> 00:01:24,000
technology, you know, podcast 
the show where I'll be bringing 

23
00:01:24,000 --> 00:01:27,100
you the greatest technical 
leaders practitioners and 

24
00:01:27,100 --> 00:01:30,800
thought leaders in the industry 
to discuss about their Journey 

25
00:01:31,100 --> 00:01:35,600
ideas and practices that we all 
can learn and apply to build a 

26
00:01:35,600 --> 00:01:39,100
highly performing technical team
and to make an impact in your 

27
00:01:39,100 --> 00:01:42,300
personal work. 
So let's dive into our Journal. 

28
00:01:47,600 --> 00:01:49,700
Hello my friend. 
Welcome back to the tekhelet 

29
00:01:49,700 --> 00:01:52,700
journal podcast, the show where 
you can learn about technical 

30
00:01:52,700 --> 00:01:56,000
leadership and Excellence from 
my conversations with great 

31
00:01:56,000 --> 00:01:59,100
thought, leaders in the tech 
industry and this is the episode

32
00:01:59,100 --> 00:02:01,800
number 99. 
I can't believe that we are just

33
00:02:01,800 --> 00:02:04,200
one episode away from episode 
100. 

34
00:02:04,600 --> 00:02:06,900
If this is your first time 
listening to package, you know, 

35
00:02:07,200 --> 00:02:10,199
make sure to subscribe and 
follow the show on your podcast 

36
00:02:10,199 --> 00:02:13,100
app and social media. 
And for those of you you who 

37
00:02:13,100 --> 00:02:15,800
want to contribute to the 
creation of this podcast, 

38
00:02:15,900 --> 00:02:18,800
support me by subscribing as a 
patron at technology. 

39
00:02:18,800 --> 00:02:23,000
No, dot f / Patron. 
My guest for today's episode is 

40
00:02:23,000 --> 00:02:27,300
Kenneth pube, also known as 
Camp, you can is in a claim 

41
00:02:27,300 --> 00:02:30,100
author and thought leader in 
acceptance test-driven 

42
00:02:30,100 --> 00:02:33,700
development or a TD and behavior
driven development. 

43
00:02:33,700 --> 00:02:38,100
Or bdd in this episode can 
explain in depth, the concept of

44
00:02:38,100 --> 00:02:42,100
acceptance test and a TD. 
He first describe what an 

45
00:02:42,100 --> 00:02:45,100
acceptance test. 
Is why it is beneficial to 

46
00:02:45,100 --> 00:02:48,900
deliver better software and why 
we should invest our effort to 

47
00:02:48,900 --> 00:02:51,900
automate. 
It can also touch on a few other

48
00:02:51,900 --> 00:02:56,700
important Concepts such as the 
testing Triad test, pyramid user

49
00:02:56,700 --> 00:03:01,600
acceptance test and table-driven
specifications towards the N can

50
00:03:01,600 --> 00:03:05,300
share some advice on how we can 
start implementing a TD. 

51
00:03:06,100 --> 00:03:09,300
I really enjoyed my conversation
with Ken deepening. 

52
00:03:09,300 --> 00:03:12,600
My understanding of acceptance 
test the insights. 

53
00:03:12,800 --> 00:03:15,800
Can share regarding where 
acceptance test results in the 

54
00:03:15,800 --> 00:03:19,700
tests pyramid, and his view 
about user acceptance, testing. 

55
00:03:20,300 --> 00:03:23,900
If you also find this episode 
useful, I would appreciate if 

56
00:03:23,900 --> 00:03:26,700
you share it with your friends 
and colleagues who you think can

57
00:03:26,700 --> 00:03:30,200
also benefit from listening to 
this episode, it is my ultimate 

58
00:03:30,200 --> 00:03:32,800
mission to spread this podcast 
to more people. 

59
00:03:33,400 --> 00:03:36,000
And I need your help to support 
me towards fulfilling my 

60
00:03:36,000 --> 00:03:37,900
mission. 
Before we continue to the 

61
00:03:37,900 --> 00:03:41,200
conversation, let's hear some 
words from our sponsor 

62
00:03:41,600 --> 00:03:45,200
definitely is Top International 
software development conference,

63
00:03:45,400 --> 00:03:49,100
with an emphasis on coding 
architecture and take leadership

64
00:03:49,100 --> 00:03:51,400
skills. 
The lineup for this year is 

65
00:03:51,400 --> 00:03:55,100
truly stellar and features many 
Legends in software development 

66
00:03:55,400 --> 00:03:59,800
names, such as Robert Uncle Bob.
Martin can back Scott Hanselman 

67
00:04:00,100 --> 00:04:02,900
Franca subramanium, Carolyn 
honey, Alan. 

68
00:04:02,900 --> 00:04:06,800
Hello, Mary poppendieck and many
other prominent names including 

69
00:04:06,800 --> 00:04:10,100
some of those who have also 
appeared in this podcast before 

70
00:04:10,600 --> 00:04:12,600
the conference takes place 
online. 

71
00:04:12,800 --> 00:04:15,400
So, you can enjoy it from the 
comfort of your couch. 

72
00:04:15,800 --> 00:04:18,800
We spoke to the definitey 
organizers, and I'm happy to 

73
00:04:18,800 --> 00:04:21,300
share that technology. 
You know, has got the 10% 

74
00:04:21,300 --> 00:04:25,900
discount code for you. 
Enter the promo code, awsm 

75
00:04:26,100 --> 00:04:29,200
underscore tlj. 
When you purchase the ticket on 

76
00:04:29,200 --> 00:04:32,200
definite e.com, here's the promo
code. 

77
00:04:32,200 --> 00:04:36,300
One more time awsm underscore, 
tlj. 

78
00:04:37,100 --> 00:04:40,300
Depending on the time when you 
purchase a ticket early price is

79
00:04:40,300 --> 00:04:42,600
still available. 
See you there. 

80
00:04:43,000 --> 00:04:46,300
Today's episode is proudly 
sponsored by skills matter. 

81
00:04:46,600 --> 00:04:48,800
The global community and events 
platform. 

82
00:04:48,800 --> 00:04:53,300
With more than 100,000 software 
professionals here members. 

83
00:04:53,300 --> 00:04:55,900
Can organize their learning 
experiences around the 

84
00:04:55,900 --> 00:04:58,900
technology topics. 
They care about most you get 

85
00:04:58,900 --> 00:05:02,500
on-demand access to their latest
content thought, leadership 

86
00:05:02,500 --> 00:05:06,100
insights, as well, as the 
exciting schedule of tech events

87
00:05:06,200 --> 00:05:10,000
running across all time zones. 
So whether devops our data 

88
00:05:10,000 --> 00:05:14,000
science is your bus or you are 
fan of General programming or 

89
00:05:14,000 --> 00:05:17,700
all things Cloud, you can make 
real connections with people who

90
00:05:17,700 --> 00:05:21,800
share your interests head on 
over to skills method or Cam to 

91
00:05:21,800 --> 00:05:24,600
become part of the tech 
community that matters most to 

92
00:05:24,600 --> 00:05:26,700
you. 
It's free to join and you will 

93
00:05:26,700 --> 00:05:32,600
find it easy to keep up with the
latest tech Trends, welcome 

94
00:05:32,600 --> 00:05:35,000
everyone to the new episode of 
the technology know. 

95
00:05:35,300 --> 00:05:38,900
Today I have with me, a guest 
named Kenneth puke or Camp you 

96
00:05:38,900 --> 00:05:41,100
in short. 
He is a very experienced, 

97
00:05:41,100 --> 00:05:44,200
thought leaders out there. 
So Has written a number of books

98
00:05:44,300 --> 00:05:47,700
and specialized in acceptance, 
test-driven development and 

99
00:05:47,700 --> 00:05:50,400
behavior driven development. 
So as you can guess, we will be 

100
00:05:50,400 --> 00:05:54,800
talking a lot about a TD + VD. 
Today can read some books, one 

101
00:05:54,800 --> 00:05:58,300
of it, won the 2006 job Award 
winner, which is the pre 

102
00:05:58,300 --> 00:06:01,900
factoring book followed by his 
latest book called lean, Asia 

103
00:06:01,900 --> 00:06:04,300
acceptance, test-driven 
development and he's also a 

104
00:06:04,300 --> 00:06:07,300
co-creator of safe, Agile, 
software, engineering course. 

105
00:06:07,700 --> 00:06:10,700
So can really looking forward to
have this conversation with you.

106
00:06:10,800 --> 00:06:14,600
I'm going to learn a lot about 
80 DB Really, I guess I'm going 

107
00:06:14,600 --> 00:06:17,900
to be here and chat with you. 
So can in the beginning, I 

108
00:06:17,900 --> 00:06:21,300
always love to start my 
conversation to understand about

109
00:06:21,300 --> 00:06:23,600
your background. 
Maybe if you can share your 

110
00:06:23,600 --> 00:06:26,400
career Journey, any highlights 
or turning points in your 

111
00:06:26,400 --> 00:06:28,800
career. 
So, I graduated with an 

112
00:06:28,800 --> 00:06:32,200
electrical engineering degree. 
They actually not have computer 

113
00:06:32,200 --> 00:06:35,900
science much in those days, we 
need to digital logic 

114
00:06:35,900 --> 00:06:40,400
engineering and it turns out 
after about five years, the 

115
00:06:40,400 --> 00:06:45,000
until 8:00. 
Eight came out, not the 8080 

116
00:06:45,000 --> 00:06:50,000
with the 8008 and I suddenly 
realized that the future was not

117
00:06:50,000 --> 00:06:55,900
a digital logic, but in software
so I actually made a switch at 

118
00:06:55,900 --> 00:06:59,600
that time. 
I went into software, I did some

119
00:06:59,600 --> 00:07:04,800
programming on radar systems on 
Long Baseline interferometry and

120
00:07:04,800 --> 00:07:08,100
other stuff was out in the 
Marshall Islands for a while. 

121
00:07:08,500 --> 00:07:12,500
And when I came back, I started 
my own consulting firm and get 

122
00:07:12,500 --> 00:07:13,600
her. 
Custom programming. 

123
00:07:14,000 --> 00:07:17,300
Of course, those were with the 
PCS we're just coming out so 

124
00:07:17,300 --> 00:07:21,600
your programming was on a PC, no
network, no nothing. 

125
00:07:21,600 --> 00:07:25,300
So it had to fit it, 64 K of 
memory, all the programs. 

126
00:07:25,800 --> 00:07:30,200
So then I was doing custom 
programming got need to training

127
00:07:30,200 --> 00:07:33,400
in the C language. 
And then from there I've been 

128
00:07:33,400 --> 00:07:37,900
doing training, roots of books, 
read a couple of books on C and 

129
00:07:37,900 --> 00:07:41,500
then progress to more 
Consulting, agile came out 

130
00:07:41,500 --> 00:07:44,700
around. 
I was doing some of the tenants 

131
00:07:44,700 --> 00:07:47,200
that were actually in XP 
programming already. 

132
00:07:47,200 --> 00:07:50,700
I was writing tests for all my 
code in C code. 

133
00:07:50,700 --> 00:07:55,000
There was no see unit, but it 
was tested writing the test for 

134
00:07:55,000 --> 00:07:58,600
the code first. 
And then when you do Agile 

135
00:07:58,600 --> 00:08:02,100
Consulting as well, training, 
join with net objectives. 

136
00:08:02,100 --> 00:08:05,500
For a few years who's doing 
design patterns. 

137
00:08:05,600 --> 00:08:09,300
Test-driven development about 12
15 years ago. 

138
00:08:09,300 --> 00:08:14,100
Was when I started creating the 
course on a TDE Bdd, and then 

139
00:08:14,100 --> 00:08:16,000
eventually that turned into the 
book. 

140
00:08:16,600 --> 00:08:18,600
Thanks for sharing your story 
looking back. 

141
00:08:18,600 --> 00:08:20,600
I think it's a very long 
journey, right? 

142
00:08:20,800 --> 00:08:22,900
If you can share, what made you 
decide that software? 

143
00:08:22,900 --> 00:08:24,600
Is the future? 
What things that make you 

144
00:08:24,600 --> 00:08:26,700
believe that actually software 
is the future? 

145
00:08:27,600 --> 00:08:31,600
Well, many years ago, I 
actually, it spent over a couple

146
00:08:31,600 --> 00:08:36,000
of months designing their 
digital logic circuit and then 

147
00:08:36,000 --> 00:08:40,400
when the 8008 came out, I 
realized that I could have done 

148
00:08:40,400 --> 00:08:44,700
the same thing. 
Just Firmware without trying to 

149
00:08:44,700 --> 00:08:49,200
hook up all the digital, logic, 
gates and everything and I said,

150
00:08:49,700 --> 00:08:51,700
guess what? 
It's going to be software. 

151
00:08:52,000 --> 00:08:54,500
Now, there's talk. 
Where was it big in those days 

152
00:08:54,900 --> 00:08:58,200
in college had programmed, an 
IBM 360. 

153
00:08:58,300 --> 00:09:01,900
So I was familiar with Assembly 
Language and COBOL and 

154
00:09:01,900 --> 00:09:06,000
everything and I realized that 
the digital logic was being 

155
00:09:06,000 --> 00:09:08,700
taken over. 
You can write it for homework 

156
00:09:08,700 --> 00:09:11,900
program, it do the same thing. 
Instead of look for asleep, 

157
00:09:11,900 --> 00:09:14,100
drawing. 
Block diagram. 

158
00:09:14,800 --> 00:09:17,200
I see. 
So in the last few years I think

159
00:09:17,200 --> 00:09:20,100
you specialize in a TD 
acceptance test-driven 

160
00:09:20,100 --> 00:09:23,200
development and bdd, right? 
Although in your early years, 

161
00:09:23,200 --> 00:09:26,300
definitely you started from 
programming practitioners of X 

162
00:09:26,300 --> 00:09:28,900
be a gel and all that but let's 
focus today, may be 

163
00:09:28,900 --> 00:09:31,100
predominantly on acceptance 
test. 

164
00:09:31,300 --> 00:09:34,100
So you wrote this book, lean 
agile, acceptance, test-driven 

165
00:09:34,100 --> 00:09:36,800
development, that the software 
true collaboration. 

166
00:09:37,000 --> 00:09:39,700
But first of all I think let's 
clarify the definition. 

167
00:09:40,000 --> 00:09:42,900
So what is acceptance test 
because I hear Here. 

168
00:09:42,900 --> 00:09:45,900
This term being used multiple 
times, sometimes means 

169
00:09:45,900 --> 00:09:48,600
differently to different people.
So maybe if we can start from 

170
00:09:48,600 --> 00:09:53,300
there, that will be great. 
Okay, so my definition of 

171
00:09:53,300 --> 00:09:58,400
acceptance test is any test that
is system must pass in order to 

172
00:09:58,400 --> 00:10:05,600
be accepted that can be provided
by the customer, the users, the 

173
00:10:05,600 --> 00:10:10,400
testers because the tester still
play a big role or anybody else,

174
00:10:10,800 --> 00:10:14,700
and if you can't ship Without 
these tests. 

175
00:10:14,900 --> 00:10:17,300
Well, they are deep septons 
test. 

176
00:10:18,200 --> 00:10:22,200
Well it's very concise actually 
I was struck by your definition 

177
00:10:22,200 --> 00:10:27,100
of the tests that actually makes
the system accepted and a lot of

178
00:10:27,100 --> 00:10:29,700
people these days especially 
maybe in the startups we have 

179
00:10:29,700 --> 00:10:33,400
tests but we just deployed 
anyway what does it take for 

180
00:10:33,400 --> 00:10:35,900
people to realize that? 
Okay, you really need to have 

181
00:10:35,900 --> 00:10:39,400
these kind of tests before you 
can actually accept the system. 

182
00:10:40,100 --> 00:10:42,300
You've got a couple things here 
first. 

183
00:10:42,300 --> 00:10:46,700
If you know what you want the 
system to do as opposed to your 

184
00:10:46,700 --> 00:10:49,800
just experimenting. 
And it's hard agreed acceptance 

185
00:10:49,800 --> 00:10:51,600
test. 
If you're experimenting with a 

186
00:10:51,600 --> 00:10:54,700
system, it's like, you just want
to try something out, 

187
00:10:54,700 --> 00:10:57,000
prototyping it. 
So we're not going to be ready 

188
00:10:57,000 --> 00:11:00,100
to acceptance test for those 
sorts of things because they 

189
00:11:00,100 --> 00:11:03,400
take draw all the time. 
But once you've decided in your 

190
00:11:03,400 --> 00:11:06,500
experiment that this is what you
want the system. 

191
00:11:06,500 --> 00:11:09,900
To do, that writing the 
acceptance test. 

192
00:11:10,000 --> 00:11:12,900
Absolutely clarifies. 
The requirements. 

193
00:11:13,600 --> 00:11:16,400
You don't get into this issue of
well. 

194
00:11:16,400 --> 00:11:21,600
Should it work for? 
1000 or 900, you have a test for

195
00:11:21,600 --> 00:11:24,300
it either. 
Test says line under the test 

196
00:11:24,300 --> 00:11:27,400
says, a thousand white 
documenting that test and it's 

197
00:11:27,400 --> 00:11:31,500
actually didn't become editor, 
be executable specification, if 

198
00:11:31,500 --> 00:11:36,300
you will means that. 
Now our description is the test 

199
00:11:37,000 --> 00:11:39,900
as opposed to a set of 
requirements that well, that's 

200
00:11:39,900 --> 00:11:42,100
nice. 
But what does it mean? 

201
00:11:42,300 --> 00:11:44,900
Are we sure that we're meeting 
the requirements in that 

202
00:11:44,900 --> 00:11:48,600
misinterpretation of the 
requirements is Probably the 

203
00:11:48,600 --> 00:11:52,000
biggest thing that goes back and
hits people, it's like to get to

204
00:11:52,000 --> 00:11:56,300
the end and the testers find the
defect and the developers that I

205
00:11:56,308 --> 00:11:58,900
know they requirement said this 
and that that's who said no, the

206
00:11:58,900 --> 00:12:02,300
requirement says that. 
Why don't you guys agree at a 

207
00:12:02,308 --> 00:12:06,700
time with the requirements set? 
I think that's a very important 

208
00:12:06,700 --> 00:12:08,600
key point, right? 
Because you mentioned 

209
00:12:08,600 --> 00:12:10,600
requirements, sometimes is 
misunderstood. 

210
00:12:10,900 --> 00:12:14,100
Sometimes it's vague as well, 
and sometimes it's just one 

211
00:12:14,100 --> 00:12:15,000
line. 
Okay, built me. 

212
00:12:15,000 --> 00:12:18,700
This you bring a point in your 
book that you Mentioned that a 

213
00:12:18,700 --> 00:12:22,200
testable requirements should 
have acceptance tests associated

214
00:12:22,200 --> 00:12:24,100
with them. 
So, I think this is also a key 

215
00:12:24,100 --> 00:12:26,000
discipline. 
When you define requirements, 

216
00:12:26,200 --> 00:12:29,300
you always have to Define it in 
such a way, that it is testable.

217
00:12:29,700 --> 00:12:32,700
If you can, elaborate a little 
bit more on this point. 

218
00:12:33,200 --> 00:12:35,700
Okay. 
So there's a concept of a 

219
00:12:35,700 --> 00:12:39,200
testable requirement. 
How do you know the requirement 

220
00:12:39,200 --> 00:12:42,500
is testable by writing a test 
for it. 

221
00:12:42,800 --> 00:12:46,400
If you cannot write a test for 
requirement, then the 

222
00:12:46,400 --> 00:12:49,900
requirement is untestable. 
If an earthworm, it is 

223
00:12:49,900 --> 00:12:52,900
untestable. 
How do you know the system is 

224
00:12:52,900 --> 00:12:55,900
doing it? 
Why are you asking for the 

225
00:12:55,900 --> 00:12:58,700
requirement? 
If there's no way we can tell 

226
00:12:58,700 --> 00:13:02,000
this system is actually 
performing that behavior. 

227
00:13:03,000 --> 00:13:06,300
Yeah, that is actually true if 
you define a requirement in one 

228
00:13:06,300 --> 00:13:08,700
liner but then leave other 
people to test. 

229
00:13:08,900 --> 00:13:11,500
If at the end you think the 
software is not acceptable? 

230
00:13:11,500 --> 00:13:13,600
I mean, at the end, it's your 
fault as well. 

231
00:13:13,800 --> 00:13:16,700
So you don't actually specify 
the requirement that can be 

232
00:13:16,700 --> 00:13:19,200
tested in a way. 
There's a point where you 

233
00:13:19,200 --> 00:13:22,200
mentioned that acceptance test, 
if done properly, then be an 

234
00:13:22,200 --> 00:13:25,000
authoritative and reliable 
source of what the software 

235
00:13:25,000 --> 00:13:27,900
should do functionally. 
So, I think, especially we 

236
00:13:27,900 --> 00:13:29,900
mentioned by executable 
specifications. 

237
00:13:29,900 --> 00:13:33,900
If everything even is defined by
using test, I think that's a 

238
00:13:33,900 --> 00:13:36,600
good way of getting the reliable
source of truth. 

239
00:13:36,600 --> 00:13:38,800
About all the requirements that 
the software does. 

240
00:13:39,400 --> 00:13:41,800
So, we know about the 
definition, I think some people 

241
00:13:41,800 --> 00:13:44,700
also know about the benefits but
can you, elaborate, what are the

242
00:13:44,700 --> 00:13:51,300
benefits of acceptance test? 
Okay, so the main benefit, it's 

243
00:13:51,300 --> 00:13:56,300
always based on your content if 
I go into some place and I asked

244
00:13:56,300 --> 00:13:59,300
them. 
So how many times the something 

245
00:13:59,300 --> 00:14:03,300
come back from the testing 
environment or for reduction 

246
00:14:03,300 --> 00:14:05,200
back to development with a 
defect? 

247
00:14:06,100 --> 00:14:10,200
And if the answer is point zero 
one percent, I'm gonna go. 

248
00:14:10,200 --> 00:14:12,100
Well there's not much I can do 
for you. 

249
00:14:12,100 --> 00:14:15,600
I mean we can spend some time 
but you're pretty good. 

250
00:14:16,300 --> 00:14:19,300
If the answer is 1%, I'm going 
well. 

251
00:14:19,800 --> 00:14:23,300
How much time does it take you 
to solve the defect if it's 

252
00:14:23,300 --> 00:14:25,000
starting to creep anymore than 
that? 

253
00:14:25,000 --> 00:14:27,600
There are places. 
That are why call them a 

254
00:14:27,600 --> 00:14:30,000
loopback? 
A loopback is when you send 

255
00:14:30,000 --> 00:14:33,600
something out and it gets sent 
back with a defect that you 

256
00:14:33,600 --> 00:14:38,000
should have thought about before
as opposed to feedback, which is

257
00:14:38,200 --> 00:14:41,500
you send something out and you 
learn something new to help 

258
00:14:41,500 --> 00:14:45,600
improve the product. 
If you can cut your look back 

259
00:14:45,600 --> 00:14:52,000
rate, down traumatically, they 
you can flow that business value

260
00:14:52,000 --> 00:14:56,900
through your developmental value
stream, much quicker and get 

261
00:14:56,900 --> 00:15:00,000
things out. 
So that you're actually always 

262
00:15:00,000 --> 00:15:05,700
working on new stuff as opposed 
to fixing defects and if I guess

263
00:15:05,700 --> 00:15:08,100
the way I don't usually sell it 
to developers or no. 

264
00:15:08,100 --> 00:15:11,800
Hey guess what you're getting 
your requirements and a testable

265
00:15:11,800 --> 00:15:16,300
for Your job is to write an 
implementation that passes those

266
00:15:16,300 --> 00:15:18,400
texts. 
Now you'll still maybe have some

267
00:15:18,400 --> 00:15:21,700
communication and collaboration 
because maybe the tests aren't 

268
00:15:21,700 --> 00:15:26,000
quite clear and so forth, but 
once you pass the test, you're 

269
00:15:26,000 --> 00:15:31,900
done, if we are able to describe
as much as possible requirements

270
00:15:31,900 --> 00:15:35,800
and test that would have 
normally been done in a post 

271
00:15:36,000 --> 00:15:41,000
implementation phase, that means
that you won't have any defects 

272
00:15:41,000 --> 00:15:44,700
to fix Do you like fixing 
defects? 

273
00:15:45,400 --> 00:15:50,000
You spend your life, just going.
Oh man, I just want another 

274
00:15:50,000 --> 00:15:51,700
defect. 
I can fix today. 

275
00:15:52,400 --> 00:15:55,800
So that's how I sell it to a 
development team. 

276
00:15:57,200 --> 00:16:00,300
Well, some people with wrong 
incentives might like fixing 

277
00:16:00,300 --> 00:16:03,200
defects because some people are 
incentivized by number of 

278
00:16:03,200 --> 00:16:05,600
defects found. 
But I mean, joke aside, I think 

279
00:16:05,600 --> 00:16:10,800
I get your point that if we can 
reduce the number of loopback 

280
00:16:10,800 --> 00:16:13,600
all rework or something that 
Goes back from your value 

281
00:16:13,600 --> 00:16:15,700
stream, right, from the last, 
back to the beginning. 

282
00:16:15,700 --> 00:16:18,700
Again, I think that can cut down
a lot of inefficiency. 

283
00:16:19,100 --> 00:16:22,400
And you mentioned, I think that,
if the product team or the 

284
00:16:22,400 --> 00:16:25,800
developers and testers actually 
write acceptance test prior to 

285
00:16:25,800 --> 00:16:29,300
the implementation that actually
can double the productivity. 

286
00:16:29,700 --> 00:16:32,700
I think, some teams I observe as
well after the requirements, 

287
00:16:32,700 --> 00:16:35,500
maybe it's a little bit big and 
then they will have a face 

288
00:16:35,500 --> 00:16:38,600
within the same sprint. 
Testers, write the test cases. 

289
00:16:39,000 --> 00:16:40,700
So, there are small. 
What do you think about this 

290
00:16:40,700 --> 00:16:42,100
practice? 
How can we change? 

291
00:16:43,400 --> 00:16:49,900
Okay, so it is a change because 
in many instances, it's like 

292
00:16:49,900 --> 00:16:53,800
developers just want to take 
their coat and throw it over the

293
00:16:53,800 --> 00:16:57,900
wall to the test, even if 
they're on the same team, I'm 

294
00:16:57,900 --> 00:16:59,800
going to call it. 
It's a mini wall. 

295
00:17:00,500 --> 00:17:04,900
I've seen too many instances 
where all right, the developers 

296
00:17:04,900 --> 00:17:10,400
get a story done and they get it
done at 4:45 on the last day of 

297
00:17:10,400 --> 00:17:14,300
the Sprint. 
The testers in have 15 minutes 

298
00:17:14,300 --> 00:17:19,300
to test it or they have to work 
the weekend and everybody's 

299
00:17:19,300 --> 00:17:23,599
after them because the story 
isn't done until it's tested. 

300
00:17:24,400 --> 00:17:26,900
And then, of course, what 
happens is this breaks into 

301
00:17:26,900 --> 00:17:29,000
Behavior go. 
Well, let's create a testing 

302
00:17:29,000 --> 00:17:31,400
store and for the next Sprint 
store, at least through say, 

303
00:17:31,400 --> 00:17:34,500
we're done with our development.
This brand of the testing, your 

304
00:17:34,500 --> 00:17:36,800
next break. 
We, of course, obviously is 

305
00:17:36,800 --> 00:17:39,900
really opposed to the idea of 
Agile development. 

306
00:17:40,600 --> 00:17:46,000
And so the point is that if we 
and the testers and it takes 

307
00:17:46,000 --> 00:17:51,100
just a couple of days to switch 
this thing around, you've got to

308
00:17:51,100 --> 00:17:56,800
be able to pull something off 
the backlog spin an hour, two 

309
00:17:56,800 --> 00:17:59,800
hours, and if it takes any more 
than that, do you have 

310
00:17:59,800 --> 00:18:05,100
complicated story but spend it 
our two hours creating all these

311
00:18:05,100 --> 00:18:09,000
acceptance tests. 
And then start to implement it. 

312
00:18:09,000 --> 00:18:14,100
Now, developers run the 
acceptance test while they're 

313
00:18:14,100 --> 00:18:17,000
implementing or once they're 
finished depending on how much 

314
00:18:17,000 --> 00:18:22,400
of the application they need. 
And then the testers job at the 

315
00:18:22,400 --> 00:18:26,800
end is okay, let me run it 
through on my environment, if 

316
00:18:26,800 --> 00:18:30,700
necessary, or I'm going to spend
my 15 minutes doing some 

317
00:18:30,700 --> 00:18:36,700
exploratory test to see if there
is some unintended behavior that

318
00:18:36,800 --> 00:18:40,200
We have not described by all the
acceptance tests. 

319
00:18:40,900 --> 00:18:44,700
What this does is it puts an 
entirely different spin on 

320
00:18:44,700 --> 00:18:47,800
things. 
The number of defects that are 

321
00:18:47,800 --> 00:18:50,900
tester, has to report for purely
the functional part. 

322
00:18:50,900 --> 00:18:53,700
I mean, the things that when you
look at the requirements, it's 

323
00:18:53,700 --> 00:18:55,500
like okay this is the way it 
should work. 

324
00:18:55,500 --> 00:18:58,200
And yeah, we've got a higher 
limit here. 

325
00:18:58,200 --> 00:19:01,400
If it goes above that limit, we 
should get a message, it's put 

326
00:19:01,400 --> 00:19:04,100
up and it's like, oh well, 
that's an edge case. 

327
00:19:04,100 --> 00:19:06,600
That's what testers do. 
Don't let's write the test. 

328
00:19:06,700 --> 00:19:10,000
The education and developers can
make sure that it works that 

329
00:19:10,000 --> 00:19:12,800
way. 
If the application is folks to 

330
00:19:12,800 --> 00:19:16,200
have a behavior for both good 
and bad input. 

331
00:19:16,200 --> 00:19:21,600
We can write all those tests for
and then the testers can be 

332
00:19:21,600 --> 00:19:26,300
spending their job looking for 
all the unintended things. 

333
00:19:26,400 --> 00:19:29,600
What happens if we do instead of
doing it ABC? 

334
00:19:29,600 --> 00:19:33,400
Like we thought we'd do a CB in 
our workflow does something 

335
00:19:33,400 --> 00:19:38,200
break, it puts an entirely 
different And to just give an 

336
00:19:38,200 --> 00:19:42,500
example, one of my things that I
asked one team for months later 

337
00:19:42,500 --> 00:19:44,700
to give me a report how well it 
works. 

338
00:19:44,700 --> 00:19:50,900
And they said that t, that lead 
developer and Lead tester are 

339
00:19:50,900 --> 00:19:56,400
much more mellow because they're
doing testing throughout the 

340
00:19:56,400 --> 00:20:03,100
Sprint, it isn't crammed in the 
last day and it creates the 

341
00:20:03,100 --> 00:20:07,700
we're the team feeling it. 
Isn't US versus The testers, 

342
00:20:07,900 --> 00:20:12,300
it's everybody's in it. 
They just found that their 

343
00:20:12,300 --> 00:20:16,900
defects would dramatically down.
Yeah do things slip through, 

344
00:20:17,500 --> 00:20:21,300
it's going to happen. 
But with the number defects is 

345
00:20:21,300 --> 00:20:24,900
like you can use your fingers on
one hand account them. 

346
00:20:25,300 --> 00:20:28,200
You don't need to have a gyro 
board to take care of these. 

347
00:20:28,900 --> 00:20:32,900
It's like okay, let's go fix 
them or will decide that well. 

348
00:20:32,900 --> 00:20:35,300
Okay, nobody's ever going to do 
that one. 

349
00:20:35,700 --> 00:20:37,600
So let's know. 
Worry about that. 

350
00:20:37,600 --> 00:20:40,600
That's a case that shown it show
up in normal stuff. 

351
00:20:41,300 --> 00:20:44,100
Thanks for sharing this story 
and the impact that people have 

352
00:20:44,100 --> 00:20:47,300
done by following your advice. 
I like what you said that the 

353
00:20:47,300 --> 00:20:49,500
testing actually happened 
throughout the spring. 

354
00:20:49,500 --> 00:20:52,700
Not at the last one week of few 
days before the Sprint and 

355
00:20:52,700 --> 00:20:54,400
everyone is cramming and 
waiting. 

356
00:20:54,400 --> 00:20:57,300
When can we deploy this feature?
So you mentioned that in the 

357
00:20:57,300 --> 00:21:00,900
beginning, the team should come 
up with these tests been 12 

358
00:21:00,900 --> 00:21:02,800
hours. 
You mentioned that the people 

359
00:21:02,800 --> 00:21:05,000
that should be involved in 
creating test, which is called 

360
00:21:05,000 --> 00:21:07,400
the Triad, some people call it. 
A Amigos. 

361
00:21:07,600 --> 00:21:10,300
Can you elaborate, what is this 
concept that Triad? 

362
00:21:10,500 --> 00:21:12,200
How should people implement 
this? 

363
00:21:13,100 --> 00:21:17,000
So I call it the Triad because 
that represents three 

364
00:21:17,000 --> 00:21:20,900
perspectives. 
Not necessarily three people, 

365
00:21:21,400 --> 00:21:25,000
The Three Amigos tends to be 
three people and everybody wants

366
00:21:25,000 --> 00:21:27,800
to be Steve Martin so you didn't
dollars. 

367
00:21:27,900 --> 00:21:32,100
I'm Steve though you're Steve so
I call it the Triad and three 

368
00:21:32,100 --> 00:21:36,200
perspectives. 
The customer who is providing 

369
00:21:36,200 --> 00:21:40,000
the requirements, the developer 
who's implementing the 

370
00:21:40,000 --> 00:21:45,200
requirements and the tester who 
is critically, analyzing both 

371
00:21:45,200 --> 00:21:48,900
the requirements and the 
implementation, so they get 

372
00:21:48,900 --> 00:21:51,900
together. 
Now I give three perspectives, 

373
00:21:52,400 --> 00:21:56,500
the customers perspective, it 
could be the product owner, it 

374
00:21:56,500 --> 00:22:00,300
could be a business, analyst it 
could be a subject matter 

375
00:22:00,300 --> 00:22:02,400
expert. 
It could be all three of them 

376
00:22:02,400 --> 00:22:05,000
could be. 
Getting that perspective for 

377
00:22:05,000 --> 00:22:08,200
particular story. 
So that's why it's not just 

378
00:22:08,200 --> 00:22:10,700
three people. 
It's the three perspectives, 

379
00:22:11,100 --> 00:22:15,800
they meet with the developer 
with the tester and explain what

380
00:22:15,800 --> 00:22:19,600
the story is, they work together
to create. 

381
00:22:19,900 --> 00:22:24,300
And bde terms, we call it a 
scenario, just a given when them

382
00:22:24,300 --> 00:22:29,300
scenario of what the state is, 
what the action, or event that 

383
00:22:29,300 --> 00:22:33,200
occurs and then what should be 
the output or the new state? 

384
00:22:33,800 --> 00:22:36,100
And they work on these while 
they're doing it. 

385
00:22:36,100 --> 00:22:41,600
They're defining domain terms. 
They're defining ranges out of 

386
00:22:41,600 --> 00:22:45,700
range stuff and they're defining
to other things, which is what I

387
00:22:45,700 --> 00:22:49,900
add to the normal, given wind 
in, which our business rules, 

388
00:22:50,600 --> 00:22:55,600
the business rules, which for 
some systems, take up 80% of the

389
00:22:55,600 --> 00:22:58,400
code, or at least 80% of the 
work. 

390
00:22:58,900 --> 00:23:04,700
For example, for an ATM, 
everybody has the And given I 

391
00:23:04,700 --> 00:23:09,700
had some money in my bank when I
go to my ATM and withdraw $20, 

392
00:23:09,900 --> 00:23:14,000
they'll I should have $20 in my 
hand and my cheek pouch, $20, 

393
00:23:14,000 --> 00:23:16,900
less. 
Well, it turns out that's nice 

394
00:23:17,300 --> 00:23:21,200
and that's a simple thing, but 
they're actually about in the 

395
00:23:21,200 --> 00:23:25,600
banking industry about 150 
business rules on whether you 

396
00:23:25,600 --> 00:23:29,800
can withdraw that money out. 
How many times have you thrown 

397
00:23:29,800 --> 00:23:33,200
that money map, hello, much 
money and be withdrawn, sold for

398
00:23:33,200 --> 00:23:34,600
that. 
Install one and I will not 

399
00:23:34,600 --> 00:23:38,900
elaborate them all here and it's
really that simple flow. 

400
00:23:38,900 --> 00:23:43,300
That's easy to automate. 
But it's adding in those hundred

401
00:23:43,300 --> 00:23:47,000
and fifty business rules. 
That need to be clarified 

402
00:23:47,000 --> 00:23:52,400
precisely if you're banking, if 
you're an investment firm, 

403
00:23:52,400 --> 00:23:55,500
you're letting your customers 
buy and sell stocks. 

404
00:23:55,500 --> 00:23:58,200
You better have your business 
rules right? 

405
00:23:58,200 --> 00:24:00,900
Or you're in trouble with these 
Securities and Exchange 

406
00:24:00,900 --> 00:24:04,100
Commission. 
So in addition, Should it gets 

407
00:24:04,100 --> 00:24:08,700
the normal given wind, then of 
what I call a flow scenario, I 

408
00:24:08,700 --> 00:24:14,200
emphasize business rules here. 
It's some inputs of my business 

409
00:24:14,200 --> 00:24:16,800
rule. 
What's the output here is? 

410
00:24:16,800 --> 00:24:20,100
How much money? 
How many times I've withdrawn 

411
00:24:20,100 --> 00:24:24,700
over how many days and so forth.
Given all these inputs, then I 

412
00:24:24,700 --> 00:24:26,500
get my money out. 
Yes, or no? 

413
00:24:27,100 --> 00:24:31,000
And bones become very elaborate.
I have seat business rules that 

414
00:24:31,000 --> 00:24:34,600
have over a thousand different 
Recombinations. 

415
00:24:34,600 --> 00:24:37,500
Each one is unique, and has to 
be done. 

416
00:24:37,700 --> 00:24:41,000
There has to be an answer for. 
It isn't like an algorithmic 

417
00:24:41,000 --> 00:24:44,700
sort of thing and then, the 
third thing is our domain terms.

418
00:24:45,200 --> 00:24:50,300
This is a key where a TD meets 
DDD domain driven development, 

419
00:24:50,700 --> 00:24:53,300
because during this 
collaboration, we're going to 

420
00:24:53,300 --> 00:25:00,100
come up with those domain, terms
0, balance currency, so forth. 

421
00:25:00,100 --> 00:25:03,300
And so on, it's critical that 
you get your domain. 

422
00:25:03,500 --> 00:25:06,800
Arms wrecked all for example 
balance. 

423
00:25:06,800 --> 00:25:09,900
Yeah that's what you're all 
seeing that little ATM sort of 

424
00:25:09,908 --> 00:25:15,600
examples, but is it your current
balance or Does it include 

425
00:25:15,600 --> 00:25:19,300
potential withdrawals that are 
going to be posted in the next 

426
00:25:19,300 --> 00:25:24,700
two hours and so forth and so on
and we need absolutely clarify 

427
00:25:24,700 --> 00:25:26,900
these things to make sure it's 
right. 

428
00:25:27,400 --> 00:25:31,200
There, are some cases, where do 
you take Facebook or something 

429
00:25:31,200 --> 00:25:33,600
like that? 
Doesn't matter whether Either 

430
00:25:33,600 --> 00:25:37,700
you get this sent out to 5,000 
people or forty. 

431
00:25:37,800 --> 00:25:42,500
Eight hundred people. 
Now, that's an instance of yeah,

432
00:25:42,500 --> 00:25:44,700
you can write except it says for
it, but you don't have to be 

433
00:25:44,708 --> 00:25:46,100
quite as picky. 
You. 

434
00:25:46,100 --> 00:25:50,900
And if you a lot of my 
Consulting is with Financial 

435
00:25:51,000 --> 00:25:56,400
Insurance investment, firms, and
medical for where the business 

436
00:25:56,400 --> 00:26:00,400
rules are critical. 
Thanks for emphasizing all these

437
00:26:00,400 --> 00:26:02,900
key points. 
So maybe if I can summarize, you

438
00:26:02,900 --> 00:26:04,900
mentioned that Test should have 
the flow. 

439
00:26:04,900 --> 00:26:08,100
Of course, the scenario given, 
when then kind of thing you have

440
00:26:08,100 --> 00:26:11,000
the domain terms. 
So I think in DDD, we call it 

441
00:26:11,000 --> 00:26:14,100
the weakest language, where you 
used the terms, that business 

442
00:26:14,100 --> 00:26:16,800
people use, and as much as 
possible, maybe you should be 

443
00:26:16,800 --> 00:26:18,700
able to see it throughout your 
code. 

444
00:26:18,700 --> 00:26:21,500
Try your test cases and all that
and business rules. 

445
00:26:21,500 --> 00:26:24,700
I think you emphasize very 
clearly, depending on the domain

446
00:26:24,700 --> 00:26:27,600
and the industry, of course, 
there will be some industry that

447
00:26:27,600 --> 00:26:30,800
has a complex business rules. 
Maybe elaborate business rules, 

448
00:26:30,800 --> 00:26:33,700
as well, you mentioned Financial
technology Healthcare And all 

449
00:26:33,700 --> 00:26:35,600
that. 
But many people don't work in 

450
00:26:35,600 --> 00:26:39,100
this industry. 
So they think writing a TD or 

451
00:26:39,100 --> 00:26:42,300
except themselves in the 
beginning is expensive or maybe 

452
00:26:42,300 --> 00:26:44,600
they don't even understand all 
the business rules that are 

453
00:26:44,608 --> 00:26:47,300
available, and they'll just 
leave it to the team to decide. 

454
00:26:47,700 --> 00:26:51,400
So what is your counter-argument
to this a TDS expensive to 

455
00:26:51,400 --> 00:26:56,000
implement? 
Well, I look at it as we got the

456
00:26:56,000 --> 00:26:58,800
user. 
We got a customer if the 

457
00:26:58,800 --> 00:27:03,200
customer cares about the details
of how something works. 

458
00:27:03,600 --> 00:27:05,600
Then we are to create these 
accepted status. 

459
00:27:06,200 --> 00:27:10,200
If all they said it was all. 
I just want you to withdraw 

460
00:27:10,200 --> 00:27:14,200
money out of an ATM, will let 
the team decide how to do it. 

461
00:27:14,400 --> 00:27:19,000
You can write acceptance this. 
Well, I have an article on this 

462
00:27:19,100 --> 00:27:23,300
about the accepted says, very in
the domain just as you're 

463
00:27:23,300 --> 00:27:26,800
saying. 
For example, if it's a video 

464
00:27:26,900 --> 00:27:30,600
that we're doing, suppose you 
have a video website and we want

465
00:27:30,600 --> 00:27:32,900
to write an acceptance test for 
video. 

466
00:27:33,500 --> 00:27:36,400
Well, there's not much, we can 
accept, we can say, we don't 

467
00:27:36,400 --> 00:27:39,700
want it to pause. 
We wanted to start pretty 

468
00:27:39,700 --> 00:27:43,900
quickly and I want to be able to
forward and backward on it or 

469
00:27:43,900 --> 00:27:47,500
something like that. 
That's a very high-level 

470
00:27:47,700 --> 00:27:51,100
behavioral thing. 
The developers have a lot of 

471
00:27:51,108 --> 00:27:55,200
work to do to implement that and
our acceptance tests really are 

472
00:27:55,200 --> 00:27:59,700
just the external behavior and 
there's a lot of internal 

473
00:27:59,700 --> 00:28:03,200
Behavior whose result is 
reflected in the external. 

474
00:28:03,400 --> 00:28:06,900
Either but which can't be 
specified other than in those 

475
00:28:06,900 --> 00:28:09,400
gross terms. 
So it's perfectly fine, if 

476
00:28:09,400 --> 00:28:13,300
you're in a situation like that 
you can express fi she just a 

477
00:28:13,300 --> 00:28:17,700
gross external behavior and 
leave it to the developers to 

478
00:28:17,700 --> 00:28:21,200
write an application about that,
but it's still good to have the 

479
00:28:21,208 --> 00:28:24,000
acceptances could see it. 
You sort of have an idea of your

480
00:28:24,000 --> 00:28:25,700
gun. 
So I think that's a very 

481
00:28:25,700 --> 00:28:27,400
critical point know when you are
done. 

482
00:28:27,700 --> 00:28:31,600
Because if you don't have these 
tests or specification, you 

483
00:28:31,600 --> 00:28:33,100
probably don't know when you're 
done sir. 

484
00:28:33,300 --> 00:28:36,600
I think that's really important.
You mentioned that actually, it 

485
00:28:36,600 --> 00:28:40,100
doesn't cost a lot more, even if
you write it in the beginning, 

486
00:28:40,200 --> 00:28:43,600
this is writing it at the end, 
so it literally takes the same 

487
00:28:43,600 --> 00:28:45,600
effort, probably, but the 
impact, right? 

488
00:28:45,600 --> 00:28:48,300
So you can imagine the number of
defects number of rework. 

489
00:28:48,400 --> 00:28:51,300
Number of Miss clarifications, 
that needs to happen between 

490
00:28:51,300 --> 00:28:54,500
developers and their customers 
or business owners or product 

491
00:28:54,500 --> 00:28:56,600
owners. 
So thanks for emphasizing that. 

492
00:28:57,000 --> 00:29:00,000
Maybe we can go into one level 
technical. 

493
00:29:00,000 --> 00:29:03,100
Now, there are so many different
types of tests in this. 

494
00:29:03,300 --> 00:29:06,500
Technology will be States. 
We have unit tests components as

495
00:29:06,500 --> 00:29:11,200
acceptance test itself API test.
So where does acceptance tests 

496
00:29:11,200 --> 00:29:14,700
actually get categorized? 
Is it the same all over the 

497
00:29:14,700 --> 00:29:16,500
place? 
Or is it different? 

498
00:29:16,500 --> 00:29:18,200
Maybe need your clarification 
here? 

499
00:29:18,800 --> 00:29:21,000
Oh, that's an excellent 
question. 

500
00:29:21,000 --> 00:29:26,200
Okay, we have all these tests in
fact oh man, unit test 

501
00:29:26,200 --> 00:29:29,900
integration test and an tests 
and so forth and so on, what's a

502
00:29:29,900 --> 00:29:31,900
unit test versus integration 
tests? 

503
00:29:31,900 --> 00:29:35,200
Like oh is it a single man? 
That well, I go along with 

504
00:29:35,200 --> 00:29:38,300
Google Google came up with the 
concept. 

505
00:29:38,300 --> 00:29:42,000
If you have a test here and at 
the bottom of the test pyramid 

506
00:29:42,000 --> 00:29:46,600
are small text and in the middle
are medium tests and at the tone

507
00:29:46,600 --> 00:29:49,800
bar large decks. 
So what you want to do is have a

508
00:29:49,800 --> 00:29:53,500
lot of small tests, less medium 
disk. 

509
00:29:53,500 --> 00:29:56,300
That is very few on the 
end-to-end tests. 

510
00:29:56,800 --> 00:29:59,000
Now we don't get into an 
argument of whether it's an 

511
00:29:59,000 --> 00:30:03,000
integration tests or unit tests 
because is it a small test, 

512
00:30:03,000 --> 00:30:06,000
there's Run pretty fast. 
Regardless of whether it 

513
00:30:06,000 --> 00:30:10,900
includes 32, classes are not if 
it's fast, it's small and so 

514
00:30:10,900 --> 00:30:14,900
therefore we're not looking at 
trying to make these 

515
00:30:14,900 --> 00:30:18,400
discriminatory things of. 
So it's an integration because 

516
00:30:18,400 --> 00:30:22,900
we include two classes or 
dissing that on this level, the 

517
00:30:22,900 --> 00:30:26,700
three types of things that I've 
indicated, the flow, the 

518
00:30:26,700 --> 00:30:31,600
business rules in the domain 
terms, Well, in reality, the 

519
00:30:31,600 --> 00:30:35,000
business rules in their main 
turrets actually are small test.

520
00:30:35,800 --> 00:30:40,900
They go against either single 
class or maybe even a single 

521
00:30:40,900 --> 00:30:44,200
method in the case of a business
rule, although they evolved more

522
00:30:44,200 --> 00:30:46,700
things. 
So they're pretty fast. 

523
00:30:47,100 --> 00:30:50,000
So we can't put them at the top 
there at the bottom with the 

524
00:30:50,008 --> 00:30:54,800
fast test and now this load 
test, some of them are eating 

525
00:30:54,800 --> 00:30:58,200
because we're only going to test
the flow of something like 

526
00:30:58,300 --> 00:31:01,800
request. 
Years and it receives $20 and we

527
00:31:01,800 --> 00:31:04,400
get back an indication that 
we're going to get $20. 

528
00:31:04,600 --> 00:31:08,100
That's a small little piece of 
the entire flow because we need 

529
00:31:08,100 --> 00:31:12,800
to log onto her ATM, then get 
the money out and so forth. 

530
00:31:13,400 --> 00:31:18,000
So we can have some of these ATD
given with men's being medium 

531
00:31:18,600 --> 00:31:21,000
and then some of them are going 
to be the large. 

532
00:31:21,200 --> 00:31:24,600
Because I do want to run through
the entire scenario, low 

533
00:31:24,900 --> 00:31:29,500
sticking my card in putting my 
pin in looking at the silly. 

534
00:31:29,600 --> 00:31:32,200
Vert Iseman. 
They decided to put on the ATM 

535
00:31:32,200 --> 00:31:34,100
and say, no. 
I really want to just get my 

536
00:31:34,100 --> 00:31:38,100
money and then entering my 
money, receiving money, money my

537
00:31:38,100 --> 00:31:42,300
card it's a long test, what you 
got to do it but giving want one

538
00:31:42,300 --> 00:31:48,600
of those so it's an intent test.
Well okay so with that levels to

539
00:31:48,600 --> 00:31:51,600
System test because it's testing
the entire system meow. 

540
00:31:51,900 --> 00:31:57,600
So a TD balls on that level also
falls in the unit level could 

541
00:31:57,600 --> 00:32:01,200
fall in the integration level. 
If you're A small little given 

542
00:32:01,200 --> 00:32:04,100
wind that. 
So where does it fall 

543
00:32:04,700 --> 00:32:08,000
everywhere? 
Now, you've mentioned ATI, 

544
00:32:08,300 --> 00:32:12,100
you're going to come up with an 
acceptance test for your API and

545
00:32:12,100 --> 00:32:15,200
you're going to come up with 
test for the individual methods 

546
00:32:15,300 --> 00:32:19,200
or the individual calls, and 
then you'll probably have a few 

547
00:32:19,200 --> 00:32:22,400
tests that involve multiple 
calls that you want to say. 

548
00:32:22,400 --> 00:32:25,300
Okay, I call this, then I call 
Dan McCall that did everything 

549
00:32:25,300 --> 00:32:28,400
work out, right. 
Well, sir, acceptance tests 

550
00:32:28,700 --> 00:32:32,600
typically for an API, you don't 
be a customer. 

551
00:32:33,000 --> 00:32:38,100
However, it's a public API. 
You've got customers. 

552
00:32:38,600 --> 00:32:42,300
Are you talking to them? 
Are you finding out what they 

553
00:32:42,300 --> 00:32:45,400
want? 
Are you finding out how they 

554
00:32:45,400 --> 00:32:50,500
want their errors or anything to
be returned how you want, error 

555
00:32:50,500 --> 00:32:54,900
handling, and so forth. 
So it works on a smaller level, 

556
00:32:55,500 --> 00:32:57,900
somebody's the customer for an 
API. 

557
00:32:58,500 --> 00:33:02,100
Somebody is Developer of it. 
And you might have a test their 

558
00:33:02,100 --> 00:33:04,800
come through once again, they 
could go, okay? 

559
00:33:04,800 --> 00:33:08,500
So what happens if I call this? 
But oh, this isn't working. 

560
00:33:08,700 --> 00:33:10,600
Well, this at least return me 
the right. 

561
00:33:11,700 --> 00:33:16,100
So you've got a smaller thing 
and it's an internal acceptance 

562
00:33:16,100 --> 00:33:19,500
test for API. 
It's not an external giving 

563
00:33:19,500 --> 00:33:23,800
somebody money out of the ATM. 
Thank you for clarifying this 

564
00:33:23,800 --> 00:33:26,800
using test pyramid. 
So if you can classify your test

565
00:33:26,800 --> 00:33:30,900
into like small medium and large
probably You can easily deduce. 

566
00:33:30,900 --> 00:33:33,400
Which test should it be? 
And you mentioned about 

567
00:33:33,400 --> 00:33:35,400
acceptance, tests should be 
everywhere. 

568
00:33:35,800 --> 00:33:38,900
Maybe one, kind of a confusion. 
May be also personally myself, 

569
00:33:38,900 --> 00:33:40,800
right? 
Sometimes we treat acceptance 

570
00:33:40,800 --> 00:33:44,000
tests as something to be 
reported, so think of it like a 

571
00:33:44,000 --> 00:33:47,800
user acceptance test, right 
before you can deploy your 

572
00:33:47,800 --> 00:33:50,500
product or your feature, you 
need to have this report. 

573
00:33:50,800 --> 00:33:53,800
And if you mention that, these 
acceptance tests can be anyway, 

574
00:33:54,100 --> 00:33:57,700
how do you report it easily? 
So that maybe is my question, 

575
00:33:58,200 --> 00:34:00,400
Okay? 
So They just part of your 

576
00:34:00,400 --> 00:34:04,100
question and then I'll get to 
the recording user acceptance 

577
00:34:04,100 --> 00:34:05,800
test. 
Okay, that's something you give 

578
00:34:05,800 --> 00:34:07,600
the user at the end and they go.
Okay. 

579
00:34:07,600 --> 00:34:10,600
Is it working or not? 
How come you didn't talk to that

580
00:34:10,600 --> 00:34:14,699
user ahead of time and say, 
look, when I give you this 

581
00:34:14,699 --> 00:34:16,400
application, what are you going 
to do? 

582
00:34:17,100 --> 00:34:19,600
Can you just tell me the steps 
you're going to follow? 

583
00:34:19,600 --> 00:34:22,900
Okay, well first of all that 
might change what you actually 

584
00:34:22,900 --> 00:34:26,600
implement but secondly why 
aren't you running that? 

585
00:34:27,600 --> 00:34:30,500
Why are you waiting for the user
to read it? 

586
00:34:31,100 --> 00:34:34,300
We find those uses. 
We ask them how they're going to

587
00:34:34,300 --> 00:34:37,400
be using this system. 
They're the ones who should be 

588
00:34:37,400 --> 00:34:40,199
helping create the test in the 
beginning. 

589
00:34:42,000 --> 00:34:46,300
I will make my exception so 
usability test, okay? 

590
00:34:46,300 --> 00:34:49,500
Because until they finally see 
what the gooey looks like, and 

591
00:34:49,500 --> 00:34:53,400
they're actually using it, while
you can do some prototyping. 

592
00:34:53,800 --> 00:34:57,200
But in reality, they've got to 
have a Hands-On. 

593
00:34:57,400 --> 00:35:01,000
Now, this is too many clicks. 
You can only do so much with 

594
00:35:01,000 --> 00:35:05,000
prototyping and so there still 
is that usability, but the 

595
00:35:05,000 --> 00:35:07,500
functionality is, should already
have taken. 

596
00:35:08,600 --> 00:35:11,700
Now as far as report goes, what 
are we reporting? 

597
00:35:12,600 --> 00:35:16,000
And why are we report? 
If I have accepted status for 

598
00:35:16,000 --> 00:35:20,900
every requirement and every 
requirement is required then, am

599
00:35:20,900 --> 00:35:25,600
I only report is everything past
And I should have know, we got a

600
00:35:25,600 --> 00:35:27,600
couple of failures here. 
Well why don't? 

601
00:35:27,600 --> 00:35:30,700
We need to report we have 
failures fix them. 

602
00:35:31,100 --> 00:35:35,600
So your only decision is 
everything works or these few 

603
00:35:35,600 --> 00:35:38,200
things don't work and we're 
going to fix them which is a 

604
00:35:38,207 --> 00:35:40,800
no-brainer or these things that 
work. 

605
00:35:40,800 --> 00:35:43,600
And we're going to put a feature
flag or something so people 

606
00:35:43,600 --> 00:35:46,700
don't see them. 
So we can ship the system or 

607
00:35:46,800 --> 00:35:49,700
these things don't work and we 
just decided we're just going to

608
00:35:49,700 --> 00:35:52,400
take these out so let we can 
remove the test because we 

609
00:35:52,400 --> 00:35:55,000
remove the requirement. 
And we've gotten rid of the 

610
00:35:55,000 --> 00:35:58,500
failure by removing the 
required, so those are 

611
00:35:58,500 --> 00:36:00,900
decisions. 
But basically the entire 

612
00:36:00,900 --> 00:36:06,100
application should work as is so
it's 100% except it's this. 

613
00:36:06,900 --> 00:36:09,300
So I think, yeah, go back to the
CI CD pipelines. 

614
00:36:09,300 --> 00:36:11,500
Do you have the number of tests 
that you have there? 

615
00:36:11,500 --> 00:36:15,000
So if anything breaks, then even
though it's unit integration, 

616
00:36:15,000 --> 00:36:17,600
whatever you want to call it, 
classify it, if something 

617
00:36:17,600 --> 00:36:20,700
breaks, Daniel you have is that 
the software networking place on

618
00:36:20,700 --> 00:36:25,000
the specification, one area, of 
course about Ten steps people, 

619
00:36:25,000 --> 00:36:28,200
sometimes, heavily associated 
with the automation, part of it 

620
00:36:28,300 --> 00:36:29,900
writing automated acceptance 
test. 

621
00:36:29,900 --> 00:36:34,200
So many people call it bdd so 
maybe we can go there about the 

622
00:36:34,200 --> 00:36:37,400
automation part of the 
acceptance test or this given, 

623
00:36:37,400 --> 00:36:40,400
when then kind of thing that you
must have seen in the industry. 

624
00:36:40,400 --> 00:36:42,400
This taser. 
So, how can people take 

625
00:36:42,400 --> 00:36:44,900
acceptance tests? 
May be defined by the Triad and 

626
00:36:44,900 --> 00:36:48,400
then automate that. 
So, if the old days and I'm 

627
00:36:48,400 --> 00:36:55,200
talking about early, Guinea the 
Millennium. 

628
00:36:55,600 --> 00:36:59,600
There was a acceptance test 
framework called fit framework 

629
00:36:59,600 --> 00:37:03,400
for integrated testing, and it 
worked pretty well. 

630
00:37:03,400 --> 00:37:07,800
It was tabled based system. 
It was perfect for doing 

631
00:37:07,800 --> 00:37:09,800
business rules and things like 
that. 

632
00:37:09,900 --> 00:37:13,800
And it had automation that it's 
now sort of turned into fitness 

633
00:37:13,800 --> 00:37:17,500
which is fit with a Wiki for 
I'll call it the modern day. 

634
00:37:18,000 --> 00:37:20,300
You've got the variations of 
cucumber. 

635
00:37:20,500 --> 00:37:23,500
There are other automation 
Frameworks but I'll call it the 

636
00:37:23,500 --> 00:37:25,800
girl. 
And the Kirk and style is the 

637
00:37:25,800 --> 00:37:29,600
one that I tend to use. 
It's simple to write. 

638
00:37:29,800 --> 00:37:34,000
If you're consistent, it's civil
to automate and just a little 

639
00:37:34,000 --> 00:37:35,800
discipline, and how you write 
this stuff. 

640
00:37:36,500 --> 00:37:40,400
So, if I have a given wind then,
and most of my given wind ends 

641
00:37:40,400 --> 00:37:42,400
have some data associated with 
them. 

642
00:37:42,800 --> 00:37:45,400
I've got a bank account, has a 
balance. 

643
00:37:45,500 --> 00:37:49,400
I'm taking so much money out. 
I'm taking $10 out, and 

644
00:37:49,400 --> 00:37:53,400
therefore, my balance was 20 
now, my balance should be 10, so

645
00:37:53,400 --> 00:37:56,900
forth. 
You can then automate those, you

646
00:37:56,900 --> 00:38:02,000
can turn them into automation 
Ian, approximately 30 seconds to

647
00:38:02,000 --> 00:38:07,800
a minute so we can convert that 
given win then into code and 

648
00:38:07,800 --> 00:38:13,100
whatever language you like Java 
C sharp, which uses their 

649
00:38:13,300 --> 00:38:17,500
version is called Speck floating
set of cucumber or Ruby Pearl 

650
00:38:17,500 --> 00:38:22,600
python you did. 
So now you've got the template 

651
00:38:22,600 --> 00:38:27,500
that gets the data. 
The gherkin and now, you can 

652
00:38:27,500 --> 00:38:31,900
provide some production code if 
you want multiple asserts into 

653
00:38:31,900 --> 00:38:35,100
this statement, but then you 
gyrate some production code. 

654
00:38:35,100 --> 00:38:37,400
Here's my data. 
Here's what I'm expecting from 

655
00:38:37,400 --> 00:38:39,100
Ryan. 
Put guys. 

656
00:38:39,400 --> 00:38:42,400
Let's start coding because we 
got some work to do. 

657
00:38:43,100 --> 00:38:48,700
So the automation part is 
Trivial, in fact, both in 

658
00:38:48,700 --> 00:38:50,100
cucumber. 
And spec floats. 

659
00:38:50,100 --> 00:38:53,400
Basically you have a feature 
file that has the gherkin it, 

660
00:38:53,700 --> 00:38:58,200
you Push a button and it will 
actually create a skeleton code 

661
00:38:58,200 --> 00:39:00,300
for you. 
He even has hit your 

662
00:39:00,300 --> 00:39:03,400
implementation here, put your 
call to your implementation 

663
00:39:03,400 --> 00:39:05,700
here, some for it. 
So, it's pretty nifty. 

664
00:39:05,800 --> 00:39:10,100
And as I say, very little 
overhead, you mention something 

665
00:39:10,100 --> 00:39:12,800
that also piques my interest. 
So, you mentioned above table 

666
00:39:12,800 --> 00:39:16,800
driven specifications', forces, 
textual format, kind of a 

667
00:39:16,808 --> 00:39:19,800
specification guy. 
So that maybe three or blog 

668
00:39:19,800 --> 00:39:22,600
posts and things like that, that
you promote a lot about 

669
00:39:22,600 --> 00:39:25,700
table-driven test. 
Met so tell us more way. 

670
00:39:25,700 --> 00:39:28,500
Probably table-driven is more 
beneficial. 

671
00:39:28,500 --> 00:39:33,500
May be more useful than the 
textual simple format so this 

672
00:39:33,500 --> 00:39:37,700
gives it that how much data 
you're having to deal with in a 

673
00:39:37,700 --> 00:39:42,600
standard opening? 
You might say given my balance 

674
00:39:42,600 --> 00:39:48,600
is $10 and I have had three 
withdrawals, something like 

675
00:39:48,600 --> 00:39:51,800
that. 
That's nice for simple stuff. 

676
00:39:52,000 --> 00:39:55,900
It works perfectly fine but But 
now, when you're starting to get

677
00:39:55,900 --> 00:39:59,900
more complicated, given my 
account is, and now I want to 

678
00:39:59,900 --> 00:40:05,000
have a table of the attributes 
for that account is the account,

679
00:40:05,000 --> 00:40:07,800
an object, I don't care yet, and
we're not dealing with that, but

680
00:40:07,800 --> 00:40:10,900
it's an entity and it's a domain
term that everybody would 

681
00:40:10,900 --> 00:40:13,900
understand. 
And the attributes would be 

682
00:40:13,900 --> 00:40:17,200
something that product owners 
and the smees when understand. 

683
00:40:17,500 --> 00:40:20,500
So now we have balance in our 
header. 

684
00:40:20,700 --> 00:40:24,000
We have the number of 
withdrawals in the past week, 

685
00:40:24,300 --> 00:40:28,300
And so forth. 
Each of those data items becomes

686
00:40:28,400 --> 00:40:32,000
a column header and then we give
it just the data underneath. 

687
00:40:32,400 --> 00:40:36,000
Well, what that does is it draws
out the attributes. 

688
00:40:36,400 --> 00:40:40,600
Those domain terms for each of 
those fields better than if you 

689
00:40:40,600 --> 00:40:45,000
just sort of string it in a 
sentence because it's like okay,

690
00:40:45,100 --> 00:40:49,500
the balance is and it's like the
term was well-balanced. 

691
00:40:49,900 --> 00:40:51,300
I do we just put that as a 
header. 

692
00:40:51,700 --> 00:40:55,300
If we put that as a hammer it's 
all Already parsed out for you 

693
00:40:55,300 --> 00:40:58,700
and every day. 
So having these step tables, if 

694
00:40:58,700 --> 00:41:03,400
you will, the data underneath, 
each step, in a table, gives you

695
00:41:03,500 --> 00:41:07,300
an easy way to look at the 
Domain terms and easy way to 

696
00:41:07,300 --> 00:41:11,100
look at the values. 
Each, I always say it's in the 

697
00:41:11,100 --> 00:41:15,100
language of business and 
everybody looks at me and says, 

698
00:41:15,100 --> 00:41:18,800
what are you talking about? 
I said every business person 

699
00:41:18,800 --> 00:41:23,500
uses Excel, they're all used to 
tables. 

700
00:41:24,100 --> 00:41:28,100
So having this in a tabular 
format, it's like yeah, let's 

701
00:41:28,100 --> 00:41:32,000
easy to read than this 50 lines 
of here's some inputs and every 

702
00:41:32,400 --> 00:41:35,100
so that's why I emphasize that 
tables. 

703
00:41:35,300 --> 00:41:37,700
It also turns out. 
There's some other interesting 

704
00:41:37,700 --> 00:41:42,000
easy thing, it's very easy to 
add another column to a table 

705
00:41:42,300 --> 00:41:45,000
and it turns out you don't have 
to pass all the values in the 

706
00:41:45,000 --> 00:41:47,700
table. 
You can default them in a step 

707
00:41:47,700 --> 00:41:52,700
definition code itself. 
So it's both readable and can be

708
00:41:52,700 --> 00:41:55,600
more efficient. 
Yes, 01 count Acumen that 

709
00:41:55,600 --> 00:41:58,900
sometimes I observed by business
people looking at the gherkin 

710
00:41:58,900 --> 00:42:01,600
although it's in plain simple 
language natural language 

711
00:42:01,800 --> 00:42:04,500
sometimes. 
Yeah, it gets to maybe granula 

712
00:42:04,500 --> 00:42:07,100
in such a way that it's very 
difficult to grasp. 

713
00:42:07,100 --> 00:42:09,400
What this test is all about, 
just by looking it. 

714
00:42:09,400 --> 00:42:12,800
Simply so you mentioned that 
business, people tends to use 

715
00:42:12,800 --> 00:42:15,800
Excel spreadsheet in order to 
Define their business rules, or 

716
00:42:15,800 --> 00:42:18,800
maybe some examples of how this 
should be done, I think. 

717
00:42:18,800 --> 00:42:21,200
Yeah, that's correct. 
Actually by having tables, you 

718
00:42:21,200 --> 00:42:24,200
focus the attention into the 
headers, which are The 

719
00:42:24,200 --> 00:42:27,600
attributes and the domain terms,
the important Concepts and their

720
00:42:27,600 --> 00:42:31,400
variations of values that could 
potentially happen and what your

721
00:42:31,400 --> 00:42:33,800
code should assist in terms of a
correctness. 

722
00:42:34,100 --> 00:42:36,700
So thanks for emphasizing that. 
I think your table driven, I've 

723
00:42:36,700 --> 00:42:39,600
used it in the past as well for 
insurance calculation. 

724
00:42:39,700 --> 00:42:42,500
That actually is the main 
language that the Actuarial 

725
00:42:42,500 --> 00:42:45,500
people used to actually Define 
the formula for this 

726
00:42:45,500 --> 00:42:48,400
calculation. 
So can we are reaching towards 

727
00:42:48,400 --> 00:42:51,500
the end but before we go into 
the last question so I want you 

728
00:42:51,500 --> 00:42:53,800
to probably give us some advice 
for people. 

729
00:42:53,900 --> 00:42:56,900
People who are building products
or building software, what 

730
00:42:56,900 --> 00:43:00,600
should they do in order to kick?
Start this journey of acceptance

731
00:43:00,600 --> 00:43:03,400
test-driven development. 
So it's not like acceptance 

732
00:43:03,400 --> 00:43:06,500
tests last sir. 
What should they do to get 

733
00:43:06,500 --> 00:43:09,600
started? 
Well, I would take class and I 

734
00:43:09,600 --> 00:43:13,700
want the team to adopt it. 
What happens, sometimes is what 

735
00:43:13,700 --> 00:43:17,100
individual goes off into class 
and comes back with this great 

736
00:43:17,100 --> 00:43:20,100
idea. 
And it's like, oh yeah. 

737
00:43:20,100 --> 00:43:22,600
Okay. 
That sounds like a lot of work. 

738
00:43:23,300 --> 00:43:27,600
And by having a teen, take the 
class because it's a team that 

739
00:43:27,600 --> 00:43:31,100
needs to collaborate together. 
They need to have a common 

740
00:43:31,100 --> 00:43:33,200
understanding of how everything 
goes. 

741
00:43:33,400 --> 00:43:37,000
So that's why I teach my classes
to teams, not individuals, 

742
00:43:37,300 --> 00:43:41,700
having the T to get together. 
Do it on their own stories and 

743
00:43:41,700 --> 00:43:45,800
realize how much they may have 
learned from actually creating 

744
00:43:45,800 --> 00:43:49,400
these steps and how much the 
clarification of the 

745
00:43:49,400 --> 00:43:52,400
requirements come. 
Why do we do this first? 

746
00:43:52,900 --> 00:43:55,000
And which is of course the 
developers always biggest 

747
00:43:55,000 --> 00:43:57,200
completo the core requirements 
around clear? 

748
00:43:57,500 --> 00:44:02,200
Yeah test this absolutely you 
know it's yes or no either you 

749
00:44:02,200 --> 00:44:06,500
pass it or you don't and so 
that's how I would start. 

750
00:44:06,500 --> 00:44:08,100
I mean you can try it on your 
own. 

751
00:44:08,400 --> 00:44:11,200
I have workshops that I teach 
for teens. 

752
00:44:11,700 --> 00:44:16,800
We basically go through and use 
your stories as the exercises. 

753
00:44:17,300 --> 00:44:22,300
Not might ATM example, we use 
your stories and you come out of

754
00:44:22,300 --> 00:44:25,000
the workshop. 
We Sunday your stories that are 

755
00:44:25,000 --> 00:44:29,600
fully developed and now you may 
be able to recognize, here's the

756
00:44:29,607 --> 00:44:34,300
difference between what we were 
doing and what we could be do, 

757
00:44:35,100 --> 00:44:38,700
that is always nice to compare 
or contrast between what you 

758
00:44:38,700 --> 00:44:41,300
were doing before. 
And after the new knowledge, how

759
00:44:41,300 --> 00:44:44,000
you should do it, it gets 
started from there and 

760
00:44:44,000 --> 00:44:46,500
hopefully, the behaviour and 
habits stays on. 

761
00:44:46,700 --> 00:44:49,100
And you have a much more 
improved software development, 

762
00:44:49,100 --> 00:44:51,700
life cycle. 
So, can it's been a pleasure 

763
00:44:51,700 --> 00:44:54,100
talking to you. 
Unfortunately, we reach the end 

764
00:44:54,100 --> 00:44:57,200
of our conversation, but before 
I let you go, normally, I would 

765
00:44:57,200 --> 00:45:00,400
have one last question that I 
always ask for all my guests 

766
00:45:00,500 --> 00:45:03,500
which is to share about three 
technical leadership wisdom. 

767
00:45:03,700 --> 00:45:07,000
So think of it like advice or 
maybe some kind of insights that

768
00:45:07,000 --> 00:45:09,600
you have retrieved from your 
journey so far in your career. 

769
00:45:09,600 --> 00:45:12,300
So what would be your tree 
technical leadership is system 

770
00:45:13,200 --> 00:45:16,000
in or okay? 
Technical leadership. 

771
00:45:16,400 --> 00:45:21,600
Hey, trust your people you hire 
good people. 

772
00:45:22,000 --> 00:45:27,300
Let Make the decisions and let 
them do their job. 

773
00:45:27,600 --> 00:45:36,200
That would be number one, number
two ecourage consistency so that

774
00:45:36,200 --> 00:45:41,700
people can move from a team to 
team and have a similar process 

775
00:45:41,700 --> 00:45:44,200
or similar environment in which 
to work. 

776
00:45:44,500 --> 00:45:50,200
But don't demand, it encourage 
it because there will always be 

777
00:45:50,200 --> 00:45:55,700
cases and exceptions. 
To any standard you come up with

778
00:45:55,900 --> 00:45:58,900
so go. 
Here's what we really encourage 

779
00:45:58,900 --> 00:46:02,000
you to do but we're reasonable 
for exceptions. 

780
00:46:03,300 --> 00:46:07,200
And then three, and it's sort of
goes along with it. 

781
00:46:07,300 --> 00:46:13,400
You've got the best people read.
You're making decisions involve 

782
00:46:13,400 --> 00:46:17,300
them in the decision, get 
feedback. 

783
00:46:17,300 --> 00:46:20,600
Now, there are always times when
it might be, okay, we got to do 

784
00:46:20,600 --> 00:46:23,500
this because we got a half an 
hour and we don't have time, but

785
00:46:23,500 --> 00:46:29,400
if you're making changes, let 
there be time for the change to.

786
00:46:29,400 --> 00:46:32,700
I'm going to call it be accepted
before the changes me. 

787
00:46:33,100 --> 00:46:36,600
So you're going to clarify why? 
We're doing a change, you're 

788
00:46:36,600 --> 00:46:39,500
going to ask for, is this the 
right change? 

789
00:46:40,000 --> 00:46:42,200
And what are the pitfalls in the
chain? 

790
00:46:42,300 --> 00:46:48,600
So instead of going downwards, 
asked, upwards and Fry and form 

791
00:46:48,700 --> 00:46:53,100
a cohesion naturally. 
Now, there will always be the 

792
00:46:53,100 --> 00:46:57,500
tail ends of the gaussian curve 
and you will never be able to 

793
00:46:57,500 --> 00:47:02,800
satisfy everybody, but let's at 
least move the mean over to it. 

794
00:47:03,000 --> 00:47:07,500
Accepting the change that you 
wish to make rather than just 

795
00:47:07,500 --> 00:47:09,600
going. 
Okay, next week we're going to 

796
00:47:09,607 --> 00:47:12,900
be doing this. 
If I may try to relate it with 

797
00:47:12,900 --> 00:47:16,000
acceptance test as well, before 
you actually make the software 

798
00:47:16,000 --> 00:47:18,100
that decision. 
Make sure that you involve the 

799
00:47:18,100 --> 00:47:21,900
people, the try it to actually 
tip in and give comments and 

800
00:47:21,900 --> 00:47:25,300
maybe agree or disagree with all
those before you actually down 

801
00:47:25,300 --> 00:47:28,100
to implementing it. 
So can it's been a pleasure. 

802
00:47:28,100 --> 00:47:30,700
Thank you so much for sharing 
everything about acceptance 

803
00:47:30,700 --> 00:47:33,100
test. 
I learned so much today for But 

804
00:47:33,100 --> 00:47:35,100
who would like to continue this 
conversation? 

805
00:47:35,100 --> 00:47:37,400
Or maybe get into your class or 
resources? 

806
00:47:37,800 --> 00:47:39,700
Is there a place where they can 
find you online? 

807
00:47:40,600 --> 00:47:43,700
Yeah, you can find me on 
LinkedIn can Pew. 

808
00:47:44,000 --> 00:47:47,600
And I am confused because I was 
the first Camp you on LinkedIn 

809
00:47:47,800 --> 00:47:54,200
or you can go to Kemp you.com 
Ian, D ug H.com and you've got 

810
00:47:54,200 --> 00:47:57,700
all like information there any 
books that you're going to write

811
00:47:57,700 --> 00:48:01,000
lately? 
Well actually, I am thinking of 

812
00:48:01,000 --> 00:48:04,100
writing two books in there, sir.
Art of parallel books. 

813
00:48:04,100 --> 00:48:07,900
One is an effective software 
development which is going to be

814
00:48:07,900 --> 00:48:11,700
a book on doing agile or even on
agile. 

815
00:48:12,200 --> 00:48:17,200
It going with patterns on how to
develop software and picking the

816
00:48:17,200 --> 00:48:20,000
right patterns in your 
development process. 

817
00:48:20,600 --> 00:48:23,700
Some of them if you pick one set
of patterns would look somewhat 

818
00:48:23,700 --> 00:48:26,800
like scrum and other you might 
look like safe another by 

819
00:48:26,800 --> 00:48:29,000
kanban. 
So it will be a sort of a 

820
00:48:29,000 --> 00:48:32,200
pattern selection book and then 
there's another one. 

821
00:48:32,500 --> 00:48:35,300
I've Sort of like a, just a 
little basis for it. 

822
00:48:35,400 --> 00:48:39,100
And that's basically coalesce 
view of software development, it

823
00:48:39,100 --> 00:48:44,500
takes in a value stream and 
acceptance testing and how to 

824
00:48:44,500 --> 00:48:48,300
break things into scenarios and 
become stories and so forth and 

825
00:48:48,300 --> 00:48:51,100
so on and it's sort of like a 
one way. 

826
00:48:51,400 --> 00:48:53,900
I always called it one week 
because there's always three 

827
00:48:53,900 --> 00:48:57,300
ways to do anything. 
The best way is whatever works 

828
00:48:57,300 --> 00:49:01,000
in your context. 
And so this would be a book on, 

829
00:49:01,000 --> 00:49:04,600
here's one way to do things. 
Things of all the possible 

830
00:49:04,600 --> 00:49:07,700
combinations. 
Looking forward to seeing those 

831
00:49:07,700 --> 00:49:10,900
books published. 
And if you have it published, I 

832
00:49:10,900 --> 00:49:13,600
guess I can have you back in 
this podcast. 

833
00:49:14,100 --> 00:49:17,100
Okay, sounds good. 
So, thanks again, Ken, thanks 

834
00:49:17,100 --> 00:49:19,400
for your sharing today. 
You're welcome. 

835
00:49:19,500 --> 00:49:24,600
Take care. 
Thank you for listening to this 

836
00:49:24,600 --> 00:49:28,000
episode and for staying, right 
until the end if you highly 

837
00:49:28,000 --> 00:49:30,400
enjoyed it. 
I would appreciate if you share 

838
00:49:30,400 --> 00:49:32,800
it with your friends and 
colleagues who you think would 

839
00:49:32,800 --> 00:49:35,200
also benefit from listening to 
this episode. 

840
00:49:35,500 --> 00:49:38,200
And if you are new to the 
podcast, make sure to subscribe 

841
00:49:38,200 --> 00:49:40,700
and leave me your valuable 
review and feedback. 

842
00:49:41,000 --> 00:49:43,400
It helps me a lot. 
In order to grow this podcast 

843
00:49:43,400 --> 00:49:45,600
better. 
You can also find the full show 

844
00:49:45,600 --> 00:49:49,100
notes of this conversation on 
the episode page, at Tech Legion

845
00:49:49,100 --> 00:49:53,700
l.f website, including the full 
transcript, In quotes and links 

846
00:49:53,900 --> 00:49:56,600
to the resources mentioned, from
the conversation. 

847
00:49:56,900 --> 00:50:00,000
And lastly, make sure to 
subscribe to the show's mailing 

848
00:50:00,000 --> 00:50:03,400
list on technology. 
Not deaf to get notified for any

849
00:50:03,400 --> 00:50:06,100
future episodes. 
Stay tuned for the next 

850
00:50:06,100 --> 00:50:09,400
technology, another episode. 
And until then goodbye,