1
00:00:00,200 --> 00:00:03,300
As a developer it's your 
responsibility to make sure that

2
00:00:03,300 --> 00:00:06,300
what you do works in. 
The only way to do this is by 

3
00:00:06,300 --> 00:00:10,300
writing tests that prove to you 
and to your team that your code 

4
00:00:10,300 --> 00:00:14,200
works and automated testing is 
just as such an easy and cheap 

5
00:00:14,200 --> 00:00:16,600
way of doing it. 
And that's why I say in the 

6
00:00:16,600 --> 00:00:19,200
book, that's effective developer
is someone that effectively 

7
00:00:19,200 --> 00:00:26,100
tests what they do, Hey 
everyone. 

8
00:00:26,600 --> 00:00:28,400
My name is Henry Surya with 
Robin. 

9
00:00:30,100 --> 00:00:33,000
And you're listening to the 
technology, you know, podcast 

10
00:00:33,400 --> 00:00:35,700
the show where I'll be bringing 
you the greatest technical 

11
00:00:35,700 --> 00:00:39,600
leaders practitioners and 
thought leaders in the industry 

12
00:00:39,900 --> 00:00:44,300
to discuss about their Journey 
ideas and practices that we all 

13
00:00:44,300 --> 00:00:47,900
can learn and apply to build a 
highly performing technical team

14
00:00:48,300 --> 00:00:50,700
and to make an impact in your 
personal work. 

15
00:00:51,200 --> 00:00:59,000
So let's dive into our Journal. 
Hi, everyone. 

16
00:00:59,000 --> 00:01:02,000
Welcome to the Chocolate, you 
know, podcast the podcast where 

17
00:01:02,000 --> 00:01:04,700
you can learn about technical 
leadership and Excellence from 

18
00:01:04,700 --> 00:01:07,100
my conversations, with great 
thought leaders in the tech 

19
00:01:07,100 --> 00:01:09,400
industry. 
If you haven't, please follow 

20
00:01:09,400 --> 00:01:12,200
the show on your podcast app and
social media on LinkedIn, 

21
00:01:12,200 --> 00:01:15,500
Twitter and Instagram. 
And for video contents package. 

22
00:01:15,500 --> 00:01:18,500
You know, is also available on 
YouTube and Tick-Tock. 

23
00:01:18,800 --> 00:01:21,500
And if you are willing to 
support my work, please buy me a

24
00:01:21,500 --> 00:01:23,300
coffee at technology. 
Know that deaths. 

25
00:01:23,300 --> 00:01:26,100
Last tip or subscribe as a 
patron at technology. 

26
00:01:26,100 --> 00:01:29,800
Arnold Dev slash Patron. 
My guess what? 

27
00:01:29,800 --> 00:01:34,000
Today's episode is Mauricio a 
niche, Mauricio is the author of

28
00:01:34,000 --> 00:01:36,700
effective software testing in 
this episode. 

29
00:01:36,700 --> 00:01:39,600
He explained how to become a 
more effective software 

30
00:01:39,600 --> 00:01:43,200
developer by using effective and
systematic software, testing, 

31
00:01:43,200 --> 00:01:45,700
approaches. 
We discussed several such 

32
00:01:45,700 --> 00:01:49,200
testing techniques such as 
testing pyramid, specification 

33
00:01:49,200 --> 00:01:53,100
based testing boundary testing 
structural testing or code 

34
00:01:53,100 --> 00:01:57,700
coverage, mutation testing and 
property testing Mauricio also 

35
00:01:57,700 --> 00:02:00,100
shared his interesting. 
You about test-driven 

36
00:02:00,100 --> 00:02:03,700
development or also known as TD,
which you may find quite 

37
00:02:03,700 --> 00:02:07,900
surprising and towards the end, 
he suggested the one area we can

38
00:02:07,900 --> 00:02:10,300
do to improve our test 
maintainability. 

39
00:02:11,500 --> 00:02:14,200
I hope you enjoy listening to 
this episode and learning a lot 

40
00:02:14,200 --> 00:02:16,700
of things about effective 
software, testing and several 

41
00:02:16,700 --> 00:02:18,800
different systematic testing 
techniques. 

42
00:02:19,100 --> 00:02:22,000
It will be really great if you 
share this with your colleagues,

43
00:02:22,000 --> 00:02:25,100
your friends and communities, 
and leave a five-star rating and

44
00:02:25,100 --> 00:02:29,500
review on a podcast and Spotify,
your small help will help me a 

45
00:02:29,508 --> 00:02:32,600
lot in getting more people 
discover and listen to the 

46
00:02:32,600 --> 00:02:35,100
podcast. 
So let's go to my conversation 

47
00:02:35,100 --> 00:02:37,900
with Mauricio after a few words 
from our sponsor. 

48
00:02:38,200 --> 00:02:41,600
Are you looking for a new cool 
swag pack, leader, No, no 

49
00:02:41,600 --> 00:02:43,400
office. 
You some swags that you can 

50
00:02:43,400 --> 00:02:46,900
purchase online. 
These wax are printed on demand 

51
00:02:46,900 --> 00:02:50,300
based on your preference and 
will be delivered safely to you 

52
00:02:50,400 --> 00:02:52,900
all over the world where 
shipping is available. 

53
00:02:53,300 --> 00:02:55,900
Check out all the cool tracks 
available by visiting 

54
00:02:55,900 --> 00:02:59,300
technology, you know, the death 
/ shop and don't forget to break

55
00:02:59,300 --> 00:03:01,500
yourself. 
Once you receive any of those 

56
00:03:01,500 --> 00:03:07,000
tracks, hey everyone, welcome to
another new show of the 

57
00:03:07,000 --> 00:03:10,500
technician our podcast today. 
I have with me Mauricio an inch 

58
00:03:11,000 --> 00:03:14,600
He's the author of a book titled
effective software testing as 

59
00:03:14,600 --> 00:03:17,500
the title says, we'll be talking
a lot about software testing 

60
00:03:17,500 --> 00:03:19,600
today. 
How to do it effectively and how

61
00:03:19,600 --> 00:03:22,800
to do it properly. 
So our Niche is the technique at

62
00:03:22,800 --> 00:03:24,900
the end a company in 
Netherlands, I believe. 

63
00:03:25,100 --> 00:03:28,700
And I think, what is really cool
is a niche, is also a lecturer 

64
00:03:28,700 --> 00:03:31,800
and he has won a computer 
science teacher of the year in 

65
00:03:31,800 --> 00:03:34,100
2021. 
I think that sounds really 

66
00:03:34,100 --> 00:03:35,700
exciting. 
Maybe you can share a little bit

67
00:03:35,700 --> 00:03:38,000
more about that. 
So thank you so much for this 

68
00:03:38,000 --> 00:03:39,700
opportunity. 
I'm really looking forward to 

69
00:03:39,700 --> 00:03:42,800
discuss about software testing. 
Today, thanks Herring party, 

70
00:03:42,800 --> 00:03:46,100
invites Marisha. 
I always like to ask my guests 

71
00:03:46,100 --> 00:03:48,900
to share, maybe a little bit 
more about yourself telling us, 

72
00:03:48,900 --> 00:03:51,400
your highlights or any turning 
points in your career. 

73
00:03:51,400 --> 00:03:53,200
De interesting for us to learn 
from. 

74
00:03:53,900 --> 00:03:54,800
Yeah, cool. 
Yeah. 

75
00:03:54,800 --> 00:03:57,900
So, my name is Mauricio, I work 
as a software developer for 

76
00:03:57,900 --> 00:04:00,600
almost 20 years. 
I had a little break when I went

77
00:04:00,600 --> 00:04:04,600
fully to Academia. 
So, I spent five or six years as

78
00:04:04,600 --> 00:04:06,400
an assistant professor in 
software, engineering doing 

79
00:04:06,400 --> 00:04:08,000
research in software 
engineering. 

80
00:04:08,200 --> 00:04:10,900
So I wasn't coding 
professionally for the period. 

81
00:04:11,100 --> 00:04:15,400
And my career was always about, 
or my passion, in my career was 

82
00:04:15,400 --> 00:04:18,300
always about software, design, 
and software testing. 

83
00:04:18,500 --> 00:04:22,000
So, how to model your code in a 
way that's easy to maintain and 

84
00:04:22,000 --> 00:04:25,300
how to write tests for it. 
And at the very beginning of my 

85
00:04:25,300 --> 00:04:28,500
book, I tell this story that one
of my first projects in my 

86
00:04:28,500 --> 00:04:31,600
career, as a team leads, we 
coded some software that was 

87
00:04:31,600 --> 00:04:35,100
supposed to run on the hardware.
And then we spent six months 

88
00:04:35,100 --> 00:04:37,300
coding version. 
Number one, we flew to another 

89
00:04:37,300 --> 00:04:40,600
country, we installed it, it 
didn't work for 24 hours. 

90
00:04:40,600 --> 00:04:43,900
There was Super big bug and that
was super sad that my first 

91
00:04:43,900 --> 00:04:47,000
software didn't work for a day. 
And that was sort of the cake 

92
00:04:47,000 --> 00:04:49,300
for me to start focusing on 
testing. 

93
00:04:49,300 --> 00:04:53,500
So since then, and that was in 
2006, so it's been a while ago. 

94
00:04:53,800 --> 00:04:56,900
I've been trying to write tests 
for everything that I do, and I 

95
00:04:56,907 --> 00:04:59,900
think the book was just a 
consequence of me putting those 

96
00:04:59,900 --> 00:05:03,300
ideas on paper. 
Well, it always amazed me like, 

97
00:05:03,300 --> 00:05:07,300
your first experience in your 
career can actually leaves you a

98
00:05:07,300 --> 00:05:09,100
lot of impact to your career, 
right? 

99
00:05:09,100 --> 00:05:12,300
So you mentioned that your first
project maybe it didn't work as 

100
00:05:12,300 --> 00:05:15,100
much as you want. 
Is a team and that actually let 

101
00:05:15,100 --> 00:05:18,500
you two have more passion in 
testing and I think let you do 

102
00:05:18,500 --> 00:05:20,800
also writing this book. 
So maybe tell us a little bit 

103
00:05:20,800 --> 00:05:23,900
more about what if you can 
reflect back on that experience?

104
00:05:23,900 --> 00:05:27,200
What actually probably some of 
the root causes of why the 

105
00:05:27,200 --> 00:05:29,800
project failed and it didn't 
last for a day, even? 

106
00:05:30,600 --> 00:05:34,000
Yeah, lack of testing was the 
main reason we were doing a lot 

107
00:05:34,000 --> 00:05:38,200
of testing for sure but 
manually, we had beautiful 

108
00:05:38,400 --> 00:05:41,700
Excel, spreadsheets full of 
things that we Test. 

109
00:05:41,900 --> 00:05:45,100
We even create a simulator 
because in that software, we 

110
00:05:45,100 --> 00:05:47,800
would talk to an external party 
via serial Port. 

111
00:05:47,800 --> 00:05:50,100
So, we even create a simulator, 
so that we could test a little 

112
00:05:50,100 --> 00:05:53,000
bit more like the real world, 
but those tests are never 

113
00:05:53,000 --> 00:05:54,600
automated. 
And what happens is as a 

114
00:05:54,608 --> 00:05:57,700
developer, you change something,
you test the happy path of your 

115
00:05:57,700 --> 00:06:01,700
change, and that's it. 
And yeah, then we had a bug and 

116
00:06:01,700 --> 00:06:04,800
a bug that was totally 
preventable by very basic 

117
00:06:04,800 --> 00:06:07,500
automated testing. 
So there was a click for me, as 

118
00:06:07,500 --> 00:06:08,200
I said. 
Yeah. 

119
00:06:08,200 --> 00:06:11,200
And also you set you go back to 
Academia, right? 

120
00:06:11,200 --> 00:06:14,600
So you spend five six years and 
I think that also lets you to 

121
00:06:14,600 --> 00:06:16,400
win this award. 
Maybe tell us a little bit more 

122
00:06:16,400 --> 00:06:17,900
about it. 
What made you? 

123
00:06:18,000 --> 00:06:20,600
Leave a lasting impression to 
the students I guess? 

124
00:06:21,500 --> 00:06:23,400
Yeah. 
So it's very hard for me to 

125
00:06:23,400 --> 00:06:26,300
decide if I like working in 
Industry where I can write 

126
00:06:26,300 --> 00:06:29,900
software and deliver value right
away to people or if I like 

127
00:06:29,900 --> 00:06:32,800
Academia where I can just sit 
and reflect about how to make 

128
00:06:32,800 --> 00:06:35,000
software Engineers better at 
what they do. 

129
00:06:35,200 --> 00:06:37,500
So my life was always a little 
bit like this and it was working

130
00:06:37,500 --> 00:06:39,300
as a developer. 
I did my masters and then I 

131
00:06:39,300 --> 00:06:40,800
said, oh, that looks cool. 
I did it. 

132
00:06:41,000 --> 00:06:42,600
HD. 
I finish my PhD. 

133
00:06:42,600 --> 00:06:44,800
I said, well, maybe I want to 
try this a little bit more. 

134
00:06:44,800 --> 00:06:47,000
I did a postdoc. 
So, I took a postdoc position 

135
00:06:47,300 --> 00:06:49,500
and they're like, yeah, it's 
amazing to the research, right? 

136
00:06:49,500 --> 00:06:52,200
And then let me try being a 
professor full-time. 

137
00:06:52,600 --> 00:06:55,500
And what usually assistant 
professors do is they do 

138
00:06:55,500 --> 00:06:59,300
research and they also do 
teaching and I started to teach 

139
00:06:59,300 --> 00:07:02,400
software testing here at the 
Delta University of Technology, 

140
00:07:02,500 --> 00:07:05,500
a very important Technical 
University in the Netherlands 

141
00:07:05,800 --> 00:07:09,400
and first time I gave this 
course was 2017 and I've been 

142
00:07:09,400 --> 00:07:12,900
doing this course until today 
day and I think teaching testing

143
00:07:12,900 --> 00:07:15,400
has been also an amazing 
experience for me because it 

144
00:07:15,400 --> 00:07:18,400
made me just understand way more
about everything that I was 

145
00:07:18,400 --> 00:07:20,200
doing. 
I had to formalize my thoughts 

146
00:07:20,200 --> 00:07:21,900
so that I could pass it to 
people. 

147
00:07:22,200 --> 00:07:24,300
And I think, throughout the 
years, I've been doing lots of 

148
00:07:24,300 --> 00:07:27,700
changes, may be a big one was 
during Corona, because when 

149
00:07:27,700 --> 00:07:30,900
Corona came and then we suddenly
switch to online. 

150
00:07:31,100 --> 00:07:33,700
I didn't want my students to be 
in front of the camera as a 

151
00:07:33,700 --> 00:07:36,000
compulsory activity, you know, 
because people had their own 

152
00:07:36,000 --> 00:07:38,600
challenges. 
So I decided to open my lecture 

153
00:07:38,600 --> 00:07:40,800
notes and I remember I just got 
it. 

154
00:07:41,000 --> 00:07:42,900
Clean assistant here and then I 
said, those are my lecture 

155
00:07:42,900 --> 00:07:44,500
notes, just make it a little bit
more. 

156
00:07:44,500 --> 00:07:47,500
Beautiful publish it in a 
website and that's how we're 

157
00:07:47,500 --> 00:07:49,000
going to do. 
The course, people can read my 

158
00:07:49,000 --> 00:07:52,200
lecture notes and to my surprise
and then they started to get 

159
00:07:52,200 --> 00:07:54,400
emails from people from other 
universities. 

160
00:07:54,600 --> 00:07:56,600
Hey I'm reading your lecture 
notes, this is very cool. 

161
00:07:56,600 --> 00:07:58,500
Do you have exercises that I can
use? 

162
00:07:58,500 --> 00:08:01,900
We have slides and then same 
thing in your number 2 and then 

163
00:08:01,900 --> 00:08:04,600
this is started to grow. 
And at some point said, well 

164
00:08:04,600 --> 00:08:08,400
maybe I need to turn this into a
book and I contacted many, I 

165
00:08:08,407 --> 00:08:10,700
submitted a proposal. 
They accepted it. 

166
00:08:10,900 --> 00:08:13,000
My book went through. 
They are very thorough review. 

167
00:08:13,000 --> 00:08:17,100
So the book just got way better 
and I think in the end this 

168
00:08:17,300 --> 00:08:20,800
teaching award that I got. 
So Delta has a ward every year 

169
00:08:20,800 --> 00:08:23,400
that they give to teachers that 
are doing something impactful, 

170
00:08:23,400 --> 00:08:26,100
and this is based on the surveys
from students and Etc. 

171
00:08:26,300 --> 00:08:29,300
I think a lot of it was because 
of this first switch from, 

172
00:08:29,300 --> 00:08:32,299
instead of me lecturing, I just 
gave them a book. 

173
00:08:32,299 --> 00:08:35,200
That is easy to read. 
That is very practical, and in, 

174
00:08:35,200 --> 00:08:37,600
creating the book itself, I 
think students, like very much 

175
00:08:37,600 --> 00:08:41,500
the content of the course. 
So my course is far from Those 

176
00:08:41,799 --> 00:08:44,400
theoretical courses usually see 
about software testing that you 

177
00:08:44,408 --> 00:08:46,300
never see source code, it's more
practical. 

178
00:08:46,500 --> 00:08:50,000
So all of these combined gave me
this award that I'm actually 

179
00:08:50,000 --> 00:08:53,600
super proud of and even today. 
So I'm giving this course right 

180
00:08:53,600 --> 00:08:56,900
now, actually in this quarter 
students are reading my book. 

181
00:08:57,000 --> 00:08:59,500
And again, the feedback has been
super nice. 

182
00:08:59,500 --> 00:09:01,800
One of the students came to me 
this year and said, you know 

183
00:09:01,800 --> 00:09:04,700
what, this is the first book in 
my bachelor so far that I read 

184
00:09:04,700 --> 00:09:08,800
cover to cover or back to cover.
So yeah, that's the story. 

185
00:09:09,600 --> 00:09:12,200
Well, thank you for sharing, 
such a beautiful story and I 

186
00:09:12,208 --> 00:09:15,500
think, yeah, it always gives you
a very proud moment to hear such

187
00:09:15,500 --> 00:09:17,500
impact, right? 
Especially when someone reads 

188
00:09:17,500 --> 00:09:19,700
your book and do and especially 
it's a technical book. 

189
00:09:20,000 --> 00:09:22,700
I must admit myself. 
I rarely finish technical books 

190
00:09:22,700 --> 00:09:25,000
and to end because there are 
hundreds of pages, sometimes 

191
00:09:25,000 --> 00:09:26,700
it's dry. 
But I think, looking at your 

192
00:09:26,700 --> 00:09:28,800
book, I think I can see. 
There are practical things. 

193
00:09:28,800 --> 00:09:32,100
They are sample code, they are 
things that guides people to 

194
00:09:32,100 --> 00:09:34,800
actually understand your thought
process, which is a good segue 

195
00:09:34,800 --> 00:09:37,500
for us to start talking about 
your book effective software 

196
00:09:37,500 --> 00:09:41,400
testing, I think one key. 
Key sentence that I pick when I 

197
00:09:41,400 --> 00:09:43,900
read your book is that you 
mentioned to Be an Effective 

198
00:09:43,900 --> 00:09:46,300
developer. 
You must become an effective 

199
00:09:46,300 --> 00:09:48,700
software tester, but in 
Practical World, sometimes 

200
00:09:48,700 --> 00:09:51,000
developer, and tester, there are
two different roles. 

201
00:09:51,000 --> 00:09:54,100
So tell us more about this. 
Why do you say that to become an

202
00:09:54,100 --> 00:09:57,000
effective software developer, 
you need to become an effective 

203
00:09:57,000 --> 00:09:59,400
software tester. 
Thanks for the question. 

204
00:09:59,500 --> 00:10:02,400
I think it's, because as a 
developer, it's your 

205
00:10:02,400 --> 00:10:05,600
responsibility to make sure that
what you do works in. 

206
00:10:05,600 --> 00:10:09,100
The only way to do this is by 
writing tests that prove to you 

207
00:10:09,100 --> 00:10:13,600
and To your team that your code 
Works show indeed before in a 

208
00:10:13,600 --> 00:10:16,200
even worked in environments like
this where I would just focus on

209
00:10:16,200 --> 00:10:19,300
coding and then I would send my 
software to another company. 

210
00:10:19,300 --> 00:10:22,400
This company will do the testing
for me, they would send me a 

211
00:10:22,400 --> 00:10:25,600
report I would fix the bug so on
and so forth, and that's just 

212
00:10:25,600 --> 00:10:29,100
not productive back and forth 
between these two things is too 

213
00:10:29,100 --> 00:10:32,700
big and I think again, it's our 
responsibility to make sure that

214
00:10:32,700 --> 00:10:34,400
things work. 
And automated testing is just as

215
00:10:34,400 --> 00:10:37,500
such easy and cheap way of doing
it. 

216
00:10:37,600 --> 00:10:39,800
And that's why I say in the book
that Effective. 

217
00:10:39,800 --> 00:10:42,200
Developer is someone that 
effectively test is what they 

218
00:10:42,200 --> 00:10:45,100
do, right? 
And I think, I mean, I don't 

219
00:10:45,100 --> 00:10:47,800
know, I was a developer last 
time, sometimes developers can 

220
00:10:47,800 --> 00:10:50,100
be very confident type of 
person, right? 

221
00:10:50,100 --> 00:10:53,900
So we rewrite the code, we test 
a little bit during the local 

222
00:10:53,900 --> 00:10:55,500
development. 
We think it works. 

223
00:10:55,500 --> 00:10:58,100
We always think it works. 
Many developers probably do not 

224
00:10:58,100 --> 00:10:59,900
enjoy writing test, for some 
reasons. 

225
00:11:00,200 --> 00:11:02,300
May be apart from you neither 
sometimes because it's very 

226
00:11:02,300 --> 00:11:05,900
close to their workflow. 
So, how would you actually 

227
00:11:05,900 --> 00:11:09,200
invite most of the developers to
actually have more? 

228
00:11:09,400 --> 00:11:12,100
Passion or energy to start 
writing that if they have the 

229
00:11:12,100 --> 00:11:14,700
perception that I'm super 
confident, my code. 

230
00:11:14,800 --> 00:11:17,200
I don't want to spend more time 
to write automated tests and 

231
00:11:17,208 --> 00:11:19,600
things like that. 
Yeah, that's a very interesting 

232
00:11:19,600 --> 00:11:22,400
question. 
So the first part was you 

233
00:11:22,400 --> 00:11:24,400
mentioned about developers being
confident, right? 

234
00:11:24,400 --> 00:11:27,400
And what I always say is you 
never know, you don't know how 

235
00:11:27,400 --> 00:11:29,300
many times a day you make a 
mistake. 

236
00:11:29,400 --> 00:11:32,100
So you program something wrong 
and you only know this once you 

237
00:11:32,100 --> 00:11:34,600
have tests because if you don't 
have tests everything that your 

238
00:11:34,600 --> 00:11:36,800
code looks perfect, right? 
To just believe it works. 

239
00:11:36,800 --> 00:11:38,800
As soon as you have test then 
you see, you know, oh my God, 

240
00:11:38,800 --> 00:11:41,100
I'm ready. 
He might test 50 times a day. 

241
00:11:41,300 --> 00:11:44,000
And then you quickly realize how
much you need them because we 

242
00:11:44,000 --> 00:11:47,200
break stuff all the time. 
Now, how to convince developers 

243
00:11:47,200 --> 00:11:49,800
to write text. 
That's a very deep question. 

244
00:11:49,800 --> 00:11:53,000
I think there are many angles to
this one is to show to them and 

245
00:11:53,000 --> 00:11:55,800
to have them practice so that 
they don't see writing tests as 

246
00:11:55,800 --> 00:11:58,500
something that is a burden. 
They just get used to it, they 

247
00:11:58,500 --> 00:12:01,600
get proficient with writing 
tests, not only with the testing

248
00:12:01,600 --> 00:12:05,100
Frameworks, but on writing code,
that is easy to be tested on. 

249
00:12:05,300 --> 00:12:08,100
You look at a program and the 
test case is emerging your head 

250
00:12:08,100 --> 00:12:10,400
and all you need to do this too.
Them in your programming 

251
00:12:10,400 --> 00:12:12,600
language. 
So there's this aspect of just 

252
00:12:12,600 --> 00:12:15,200
practicing and getting better at
test itself. 

253
00:12:15,400 --> 00:12:18,500
The second one if you are in a 
very large and complex Software 

254
00:12:18,500 --> 00:12:21,200
System, things are too complex, 
right? 

255
00:12:21,200 --> 00:12:24,000
And then for you to have this 
pleasure back in writing tests, 

256
00:12:24,000 --> 00:12:26,700
you need to make sure it's easy 
to write tests. 

257
00:12:26,900 --> 00:12:30,200
And this means as a company, as 
a team, you have to invest in a 

258
00:12:30,200 --> 00:12:33,300
small infrastructure. 
That facilitates the act of 

259
00:12:33,300 --> 00:12:36,300
writing tests. 
I was discussing this yesterday,

260
00:12:36,300 --> 00:12:38,600
actually not here at the 
company, but in another 

261
00:12:38,600 --> 00:12:41,200
University, It was yesterday and
I was saying if you're working 

262
00:12:41,200 --> 00:12:43,700
on very complex Software System 
to test something, maybe you 

263
00:12:43,708 --> 00:12:48,600
need to know to instantiate 10 
entities or have data in 30 

264
00:12:48,600 --> 00:12:50,200
different tables in your 
database. 

265
00:12:50,200 --> 00:12:53,400
And that's just because your 
business is complex and you have

266
00:12:53,400 --> 00:12:55,900
to have some something in there 
that makes this easy for you 

267
00:12:56,100 --> 00:12:58,400
that in a bunch of couple lines 
of code. 

268
00:12:58,500 --> 00:13:01,400
You can set up the scenario you 
want to test and then you can do

269
00:13:01,400 --> 00:13:04,100
the test so those are the two 
perspectives. 

270
00:13:04,100 --> 00:13:07,700
I see, one is again getting good
at testing itself and the second

271
00:13:07,700 --> 00:13:10,600
one is having the proper plan. 
Form so that you can write it, 

272
00:13:10,600 --> 00:13:15,100
this totally makes sense for me.
So, from my point of view also 

273
00:13:15,100 --> 00:13:18,100
sometimes we also need to maybe 
introduce back like, what you 

274
00:13:18,108 --> 00:13:19,300
mentioned? 
The beginning of the pride, 

275
00:13:19,300 --> 00:13:21,100
right? 
So how can you tell that your 

276
00:13:21,100 --> 00:13:23,500
code works now and also in the 
future? 

277
00:13:23,800 --> 00:13:27,100
There's no other way to do it 
other than having some automated

278
00:13:27,100 --> 00:13:30,000
tests that can actually prove 
that your work is always passed.

279
00:13:30,000 --> 00:13:32,800
Write that in terms of test 
cases, and I think many 

280
00:13:32,800 --> 00:13:35,500
developers also think, probably 
writing, more code means like 

281
00:13:35,500 --> 00:13:38,200
doubling their effort, right? 
So I think this must be changed 

282
00:13:38,200 --> 00:13:39,200
as well. 
In terms of perspective. 

283
00:13:39,300 --> 00:13:41,700
Active so that you don't finish 
writing the code. 

284
00:13:41,800 --> 00:13:44,700
If you don't have the test, 
maybe just some perspective from

285
00:13:44,700 --> 00:13:46,800
me. 
Let's move to the thing that you

286
00:13:46,800 --> 00:13:49,700
mentioned in the book, right? 
So you mention about effective 

287
00:13:49,700 --> 00:13:51,800
and there's another key word 
that actually you mentioned in 

288
00:13:51,808 --> 00:13:54,900
the book, which is systematic. 
So, I find these two things are 

289
00:13:54,900 --> 00:13:57,000
very interesting, the way you 
explained in the book. 

290
00:13:57,000 --> 00:14:00,200
Maybe, if you can explain here 
as well, what would be your 

291
00:14:00,300 --> 00:14:03,200
advice for people to be a more 
effective software tester and 

292
00:14:03,200 --> 00:14:06,300
also to be systematic in coming 
up with those tests? 

293
00:14:06,900 --> 00:14:09,100
Yeah, indeed. 
So they make a very strong point

294
00:14:09,100 --> 00:14:11,300
that Maybe you can be a little 
bit more systematic. 

295
00:14:11,400 --> 00:14:15,000
When we approach testing, we 
wrote a paper a couple of years 

296
00:14:15,000 --> 00:14:16,800
ago. 
And in this paper we asked 

297
00:14:16,800 --> 00:14:21,200
developers to write tests. 
So we gave them a program and 

298
00:14:21,400 --> 00:14:24,300
write tests and we observe them 
and they were thinking aloud, so

299
00:14:24,300 --> 00:14:27,200
that we could see how they were 
coming up with test cases, and 

300
00:14:27,200 --> 00:14:30,300
we observed a couple of things. 
Maybe the most important one for

301
00:14:30,300 --> 00:14:32,800
this conversation is that 
developers were never 

302
00:14:32,900 --> 00:14:35,300
systematic. 
They were always, you know, just

303
00:14:35,300 --> 00:14:37,100
following their hearts. 
They would look at the code is 

304
00:14:37,600 --> 00:14:39,800
this shows like the next thing I
want to Test. 

305
00:14:39,800 --> 00:14:41,700
They would go and they would 
write the test and then they 

306
00:14:41,700 --> 00:14:44,100
would repeat, what is the next 
thing I want to test? 

307
00:14:44,200 --> 00:14:46,400
So, they would just follow their
hearts and follow. 

308
00:14:46,400 --> 00:14:49,700
Clear experience, and feelings 
are very important when it comes

309
00:14:49,700 --> 00:14:52,200
to testing. 
But it also opens up space for 

310
00:14:52,200 --> 00:14:54,900
mistakes, maybe you're not in a 
good day. 

311
00:14:55,100 --> 00:14:57,300
And then you forget something 
second. 

312
00:14:57,400 --> 00:15:00,600
If you're always using all your 
brain power to come up with test

313
00:15:00,600 --> 00:15:04,200
cases, even the basic ones, 
you're not saving energy to 

314
00:15:04,200 --> 00:15:07,200
think of complex cases. 
So when you're more systematic 

315
00:15:07,200 --> 00:15:10,400
in terms of testing, that means 
No, just follow some sort of 

316
00:15:10,400 --> 00:15:12,500
cake recipe. 
That helps you to come up with a

317
00:15:12,500 --> 00:15:14,900
bunch of test cases that are 
quite easy to see. 

318
00:15:14,900 --> 00:15:17,600
You can put them on a checklist,
basically, and then it is your 

319
00:15:17,600 --> 00:15:21,400
brain power to focus on test 
cases that really requires human

320
00:15:21,500 --> 00:15:24,400
Mark, people thinking about it. 
And the fun part is that are 

321
00:15:24,400 --> 00:15:27,500
lots of techniques like this. 
If you look at academic books on

322
00:15:27,500 --> 00:15:30,200
testing, even the books from the
80s, they are go back. 

323
00:15:30,200 --> 00:15:33,000
Then was to come up with a 
recipe that teaches you how to 

324
00:15:33,000 --> 00:15:36,400
write perfect tests and what are
lots of good ideas there. 

325
00:15:36,600 --> 00:15:39,100
And you can think of, I'm not 
going to give it 30 hero. 

326
00:15:39,200 --> 00:15:41,700
Of course, but you can think of 
basic things like, for example, 

327
00:15:41,800 --> 00:15:44,700
if your method receives a list 
as an input, there are a bunch 

328
00:15:44,700 --> 00:15:46,900
of interesting cases that always
make sense. 

329
00:15:46,900 --> 00:15:49,800
So, for example, what happens if
the list is empty, what happens 

330
00:15:49,800 --> 00:15:52,100
if the list is new? 
But if there is no linear 

331
00:15:52,100 --> 00:15:54,500
programming language, what 
happens if the list has just one

332
00:15:54,500 --> 00:15:57,200
element, right? 
Because sometimes your algorithm

333
00:15:57,200 --> 00:16:00,600
changes if there are multiple 
elements were just 14, there are

334
00:16:00,600 --> 00:16:02,600
a couple of days. 
It's stuff that you don't even 

335
00:16:02,600 --> 00:16:05,500
have to think and you can write 
those tests and they are usually

336
00:16:05,500 --> 00:16:08,900
good enough to get you to a very
high coverage already and then 

337
00:16:08,900 --> 00:16:11,700
leave Space for you to then 
focus on Boundary testing, you 

338
00:16:11,700 --> 00:16:14,200
know, Corner cases in this type 
of stuff. 

339
00:16:14,400 --> 00:16:17,000
And being systematic, is 
something that you seen other 

340
00:16:17,000 --> 00:16:20,200
engineering Fields, right? 
And I think I said in my book, 

341
00:16:20,300 --> 00:16:23,000
there's this very famous book 
called The checklist, Manifesto,

342
00:16:23,200 --> 00:16:25,700
and there's a story they're 
backed up by research. 

343
00:16:25,700 --> 00:16:29,600
That shows that medical doctors,
that use a checklist before some

344
00:16:29,600 --> 00:16:33,600
surgery, they make less mistakes
that medical doctors that don't 

345
00:16:33,800 --> 00:16:36,300
and you don't have to be ashamed
of following a checklist. 

346
00:16:36,300 --> 00:16:39,800
It's goods and I think that's 
the point of my When I say we 

347
00:16:39,800 --> 00:16:41,600
can be a little bit more 
systematic. 

348
00:16:41,700 --> 00:16:44,000
Of course, we don't have to be 
systematic all the time, it's 

349
00:16:44,000 --> 00:16:46,200
just too expensive. 
Maybe too complex to be 

350
00:16:46,200 --> 00:16:49,200
systematic all the time, but 
identifying, like I'm testing a 

351
00:16:49,200 --> 00:16:51,900
complex method here, let me be a
little bit more systematic. 

352
00:16:52,000 --> 00:16:54,400
So that's the whole idea of 
being systematic when it comes 

353
00:16:54,400 --> 00:16:56,400
to testing. 
Yeah, I think your point is 

354
00:16:56,400 --> 00:17:00,000
Right, sometimes we have typical
use cases, just like list or 

355
00:17:00,000 --> 00:17:03,500
maybe you'll have an API failure
cases, success cases. 

356
00:17:03,700 --> 00:17:05,900
So, all this can be made as a 
checklist. 

357
00:17:05,900 --> 00:17:07,599
I've heard about checklist, 
Manifesto as well. 

358
00:17:07,599 --> 00:17:09,099
I think the author named are 
together. 

359
00:17:09,300 --> 00:17:12,099
Day and I think becoming 
systematic in solving. 

360
00:17:12,099 --> 00:17:15,200
This kind of a testing problem 
is really crucial, because in 

361
00:17:15,200 --> 00:17:17,800
your book, you mentioned that, 
if you are systematic, you can 

362
00:17:17,800 --> 00:17:19,900
assign any developers to the 
same problem. 

363
00:17:20,000 --> 00:17:22,599
They will most likely come up 
with the same test Suite, right?

364
00:17:22,599 --> 00:17:24,500
How cool is that? 
Because sometimes we feel that 

365
00:17:24,500 --> 00:17:27,500
we only need a certain test, has
to come up with a comprehensive 

366
00:17:27,599 --> 00:17:30,200
amount of number of tests, but I
think the systematic way is 

367
00:17:30,200 --> 00:17:32,700
actually to have any developers 
working on the same problem, but

368
00:17:32,700 --> 00:17:35,200
they can come up with the same 
test Suite that I think is 

369
00:17:35,200 --> 00:17:38,500
really, really powerful concept 
and I think it also becoming 

370
00:17:38,500 --> 00:17:41,000
effective. 
Means that you write the right 

371
00:17:41,000 --> 00:17:42,800
test because I think it never 
ends, right? 

372
00:17:42,800 --> 00:17:45,600
You can come up with any number 
of tests as you long as you can 

373
00:17:45,600 --> 00:17:48,300
produce the test inputs, right? 
And I think to come up with the 

374
00:17:48,300 --> 00:17:49,900
certain right. 
Amount of test is very 

375
00:17:49,900 --> 00:17:53,100
important, which brings us to 
some of the techniques later on 

376
00:17:53,100 --> 00:17:55,000
one of the techniques that is 
commonly. 

377
00:17:55,200 --> 00:17:58,400
I don't know discuss in the 
software world is about test 

378
00:17:58,400 --> 00:18:00,200
pyramid. 
Maybe let's start from their 

379
00:18:00,200 --> 00:18:01,100
first. 
Do you think this is a 

380
00:18:01,100 --> 00:18:04,500
systematic way to think about 
producing test and what is your 

381
00:18:04,500 --> 00:18:08,300
view about this testing pyramid?
I think the testing pyramids. 

382
00:18:08,300 --> 00:18:10,900
Helps you, too. 
Pragmatic when writing those 

383
00:18:10,900 --> 00:18:13,600
tests because one thing is to 
come up with a test case, it's 

384
00:18:13,600 --> 00:18:14,700
right. 
So those are the inputs. 

385
00:18:14,700 --> 00:18:17,500
I want to give to my program and
this is the expected output. 

386
00:18:17,500 --> 00:18:20,800
The other one is writing this in
code and making sure that this 

387
00:18:20,800 --> 00:18:24,800
works nicely in your, let's say,
development process in your CI 

388
00:18:24,800 --> 00:18:27,500
and Etc. 
So for example, if you just 

389
00:18:27,500 --> 00:18:30,000
write end to end tests, maybe 
your test Suite will cost you 

390
00:18:30,000 --> 00:18:32,300
too much to execute. 
And then at some point this 

391
00:18:32,300 --> 00:18:35,100
becomes a bottleneck, right? 
So I think the testing pyramids 

392
00:18:35,200 --> 00:18:38,600
gives this pragmatic point of 
view on, hey we're going to have

393
00:18:38,600 --> 00:18:40,800
to automate the Stats and we're 
going to have to maintain those 

394
00:18:40,800 --> 00:18:43,500
tensor and we're going to run 
them the whole day and I like 

395
00:18:43,500 --> 00:18:46,300
the idea of the testing pyramid 
very much on the idea is that 

396
00:18:46,300 --> 00:18:48,600
the bottom you have unit tests, 
right? 

397
00:18:48,600 --> 00:18:51,400
And why is it at the bottom? 
Because they are usually cheaper

398
00:18:51,400 --> 00:18:53,800
to rights. 
They are cheaper to run. 

399
00:18:54,000 --> 00:18:57,700
They tend to be more robust. 
They did not do really fail. 

400
00:18:57,900 --> 00:19:01,000
They are not flaking General and
then you go up the pyramid. 

401
00:19:01,000 --> 00:19:03,200
You have integration. 
And then to intestine, you still

402
00:19:03,200 --> 00:19:06,100
have to do them, right? 
You have to, but you do them a 

403
00:19:06,100 --> 00:19:09,000
little bit less, maybe focus a 
little bit more thin than you. 

404
00:19:09,200 --> 00:19:11,800
That's maybe it's okay to maybe 
have some duplicated test series

405
00:19:11,800 --> 00:19:13,700
for ensure. 
Are you covering the same thing 

406
00:19:13,700 --> 00:19:15,400
or not? 
I think it's okay to make this 

407
00:19:15,400 --> 00:19:17,900
sort of mistakes in the unit. 
That's what it integration and 

408
00:19:17,900 --> 00:19:19,500
end-to-end tests. 
You want to prioritize a little 

409
00:19:19,500 --> 00:19:21,900
bit more. 
And I like this idea of the 

410
00:19:21,900 --> 00:19:24,300
pyramids. 
Although, you know, in the 

411
00:19:24,300 --> 00:19:28,100
software engineering at Google 
book, I think from 2018, I think

412
00:19:28,100 --> 00:19:31,000
they bring A New Perspective 
that I also appreciate very 

413
00:19:31,000 --> 00:19:33,000
much. 
That is forget about unit, 

414
00:19:33,000 --> 00:19:34,600
testing and integration testing,
right? 

415
00:19:34,600 --> 00:19:38,600
Just separate your test Suite 
between is this one fast enough 

416
00:19:38,600 --> 00:19:40,600
that I can. 
Actually run it during a pre 

417
00:19:40,600 --> 00:19:43,100
merge together with your merge 
request, or pull request. 

418
00:19:43,100 --> 00:19:45,700
Or is it super slow? 
That I will have to run in a 

419
00:19:45,708 --> 00:19:48,900
separate machine and etcetera. 
So separating, the death sweet 

420
00:19:48,900 --> 00:19:51,600
infesting slow, makes a lot of 
sense to me because if you 

421
00:19:51,608 --> 00:19:54,600
remember back in the 2000's, our
big discussions were what is the

422
00:19:54,600 --> 00:19:56,600
unit test? 
If I'm testing two classes 

423
00:19:56,600 --> 00:19:58,700
together is this to unit test or
not right. 

424
00:19:58,700 --> 00:20:01,900
Then, I think in 2023, we know 
that this doesn't matter at all 

425
00:20:02,000 --> 00:20:04,600
as long as it runs fast and it 
gives you proper feedback. 

426
00:20:04,600 --> 00:20:06,900
That's good. 
So, I like this new way of 

427
00:20:06,900 --> 00:20:10,300
seeing things and it brings way.
This is space for this type of 

428
00:20:10,300 --> 00:20:13,200
discussions, right? 
Because if you no one can argue 

429
00:20:13,300 --> 00:20:16,600
that a slow test is better than 
a fastest, you can argue that it

430
00:20:16,608 --> 00:20:19,900
may be like integration test 
more than unit tests, but no one

431
00:20:19,900 --> 00:20:22,700
can say a slow test is better 
than a fastest, right? 

432
00:20:22,700 --> 00:20:24,100
So I like this new way of 
phrasing. 

433
00:20:24,100 --> 00:20:27,100
This yeah, let's go to the 
point, you mentioned just now 

434
00:20:27,100 --> 00:20:29,600
because there are some 
discussions and debates about 

435
00:20:29,600 --> 00:20:32,200
people preferring more about 
integration tests rather than 

436
00:20:32,200 --> 00:20:35,100
unit as something that doing 
unit test because you probably 

437
00:20:35,100 --> 00:20:37,600
most of the things they feel is 
less valuable. 

438
00:20:37,700 --> 00:20:40,700
So what is your view about this?
I know it's probably a little 

439
00:20:40,700 --> 00:20:44,100
bit more hot topics to discuss, 
but what is your view on this? 

440
00:20:44,800 --> 00:20:47,200
I think I have a pretty clear 
opinion on this, right? 

441
00:20:47,200 --> 00:20:50,400
And I think walking can be 
dangerous for sure because if 

442
00:20:50,400 --> 00:20:52,700
you can walk too much then at 
the end you're not testing 

443
00:20:52,700 --> 00:20:55,700
anything so you want to test as 
much as possible real Behavior 

444
00:20:55,700 --> 00:20:57,800
or behavior that will look like 
in production. 

445
00:20:58,000 --> 00:21:01,300
But at the same time you don't 
want to be slowed down by thanks

446
00:21:01,300 --> 00:21:04,200
that you don't control so much. 
For example, let's say you're 

447
00:21:04,200 --> 00:21:07,000
writing a piece of code that 
makes a call to web service that

448
00:21:07,000 --> 00:21:10,400
is developed by another thing. 
And suddenly You to really run 

449
00:21:10,400 --> 00:21:13,500
this test, you need that web 
service available to you, right?

450
00:21:13,500 --> 00:21:16,100
And this becomes very quickly, a
pain. 

451
00:21:16,300 --> 00:21:20,000
So in this case is smoking, 
makes a lot of sense and the web

452
00:21:20,000 --> 00:21:21,200
service you don't control so 
much. 

453
00:21:21,200 --> 00:21:23,000
That's given an example of 
something, you control a 

454
00:21:23,008 --> 00:21:24,700
database. 
Should I mock my database or 

455
00:21:24,700 --> 00:21:25,700
not? 
To be honest. 

456
00:21:25,700 --> 00:21:28,100
I believe in my opinion is that 
you should not walk your 

457
00:21:28,100 --> 00:21:31,900
database because today you can 
make tests with database so fast

458
00:21:31,900 --> 00:21:34,700
that you can actually run them 
during your pre merge time and 

459
00:21:34,700 --> 00:21:36,000
you get feedback. 
They're very fast. 

460
00:21:36,000 --> 00:21:38,400
So why would you walk something 
that is not really preventing 

461
00:21:38,400 --> 00:21:40,700
you from, right? 
In the test, in an easy way into

462
00:21:40,700 --> 00:21:43,000
running too fast. 
So I think that's the trade-off 

463
00:21:43,100 --> 00:21:45,700
that needs to happen. 
I think it's not about writing 

464
00:21:45,700 --> 00:21:48,100
integration tests or unit tests,
but it's about writing. 

465
00:21:48,100 --> 00:21:50,900
Lots of tests are fasting the 
end and that you can have full 

466
00:21:50,900 --> 00:21:53,900
control over and those are the 
things you should mock, right? 

467
00:21:53,900 --> 00:21:56,900
Things that you don't have 
control over and then of course 

468
00:21:56,900 --> 00:21:58,800
if go back to the testing 
pyramid, let's say you're 

469
00:21:58,800 --> 00:22:01,900
mocking this web service so you 
can write lots of unit tests you

470
00:22:01,900 --> 00:22:04,600
know Superfast tests that just 
mark this web service but you 

471
00:22:04,600 --> 00:22:07,100
can still have one or two or 
three integration tests that are

472
00:22:07,100 --> 00:22:09,000
a bit more expensive that make 
real calls. 

473
00:22:09,100 --> 00:22:11,700
To this web service. 
So you see the things work, when

474
00:22:11,700 --> 00:22:13,300
you put all the components 
together. 

475
00:22:13,600 --> 00:22:15,800
But you know, something that I 
always say is you should not 

476
00:22:15,800 --> 00:22:19,200
write the integration test that 
could have been a unit test, 

477
00:22:19,300 --> 00:22:20,600
right? 
You don't need an integration 

478
00:22:20,600 --> 00:22:23,000
test exercise. 
An if statement in your code, 

479
00:22:23,000 --> 00:22:25,800
just write a unit test for it, 
leaving integration tests for 

480
00:22:25,800 --> 00:22:28,400
what it really pays off. 
That is to find the integration 

481
00:22:28,400 --> 00:22:33,100
works. 
I really love your pragmatic 

482
00:22:33,100 --> 00:22:35,800
approach to answering this 
question so I fully agree as 

483
00:22:35,800 --> 00:22:38,900
well in terms of control, right?
So first, think about the you 

484
00:22:38,900 --> 00:22:42,200
control that and especially is 
not just the external service or

485
00:22:42,200 --> 00:22:45,300
infrastructure related time. 
Is also, probably one thing that

486
00:22:45,300 --> 00:22:48,400
you want to consider, right time
is something you cannot control 

487
00:22:48,400 --> 00:22:51,200
by itself, but you can actually 
create like a fixed system or 

488
00:22:51,200 --> 00:22:54,100
Market sometimes. 
So I really love the way you 

489
00:22:54,100 --> 00:22:56,900
explained about this. 
So let's move on to maybe some 

490
00:22:56,900 --> 00:22:58,900
of the other techniques, right? 
We have talked about unit 

491
00:22:58,900 --> 00:23:00,300
testing. 
As integration tests. 

492
00:23:00,300 --> 00:23:03,400
And to end tests in your book, 
you actually mentioned a couple 

493
00:23:03,400 --> 00:23:05,800
of testing techniques. 
So let's start with the first 

494
00:23:05,800 --> 00:23:06,800
one. 
Which is called the 

495
00:23:06,800 --> 00:23:10,500
specification based testing and 
it's actually very interesting 

496
00:23:10,500 --> 00:23:12,400
the way you start by expanding 
this. 

497
00:23:12,400 --> 00:23:15,200
I would assume like some people 
would start with unit tests but 

498
00:23:15,200 --> 00:23:17,000
you start with specification 
based testing. 

499
00:23:17,100 --> 00:23:20,000
So maybe tell us more what is 
specification, based testing why

500
00:23:20,000 --> 00:23:22,700
you prioritize that as the first
who? 

501
00:23:22,700 --> 00:23:24,400
Yeah. 
So what is testing, right? 

502
00:23:24,400 --> 00:23:27,400
So best thing is about trying to
find bugs and how do you do 

503
00:23:27,400 --> 00:23:29,100
this? 
Because you compare what 

504
00:23:29,300 --> 00:23:31,900
Expected program to do with what
the program does, right? 

505
00:23:32,000 --> 00:23:34,000
And for you to do this, you need
to know what the program should 

506
00:23:34,000 --> 00:23:36,200
do. 
Where is this information in the

507
00:23:36,200 --> 00:23:38,900
requirements? 
Then I'm not saying like a Word 

508
00:23:38,900 --> 00:23:41,600
document that contains the 
requirements or uml, it doesn't 

509
00:23:41,600 --> 00:23:43,100
matter. 
The requirements can be in your 

510
00:23:43,100 --> 00:23:46,100
mind's at some pointers is 
notion of what the program 

511
00:23:46,200 --> 00:23:48,600
should do. 
And specification based 

512
00:23:48,600 --> 00:23:50,900
techniques are the ones that 
help you look at the 

513
00:23:50,900 --> 00:23:54,300
requirements and identify 
interesting test cases. 

514
00:23:54,600 --> 00:23:58,400
This is not new again this dates
from the 80s and we became very 

515
00:23:58,400 --> 00:23:59,900
good at coming up. 
With techniques. 

516
00:24:00,100 --> 00:24:02,300
And basically what I want to 
show you, my book is to look at 

517
00:24:02,308 --> 00:24:05,000
the requirements, it's quite 
easy to see, you know, those are

518
00:24:05,000 --> 00:24:07,500
the inputs of the program. 
This is sort of what the program

519
00:24:07,500 --> 00:24:10,500
is to do in the output. 
Those are the different paths 

520
00:24:10,500 --> 00:24:13,300
that the program may take, so on
and so forth, and you can look 

521
00:24:13,300 --> 00:24:16,700
to all of this and then get 
inspiration to write your tests.

522
00:24:17,200 --> 00:24:21,300
And the one technique of showing
my book is actually a very basic

523
00:24:21,300 --> 00:24:22,800
one. 
That basically says, look at the

524
00:24:22,800 --> 00:24:25,200
inputs of your program for the 
message or testing or the 

525
00:24:25,200 --> 00:24:28,800
component, whatever, or the 
inputs separate them, one by 

526
00:24:28,800 --> 00:24:30,500
one. 
Your function receives three 

527
00:24:30,500 --> 00:24:33,800
inputs and integer is string 
that represents whatever and the

528
00:24:33,800 --> 00:24:35,400
list. 
Look at them separately and 

529
00:24:35,400 --> 00:24:38,400
explore their domain. 
So let's say this is string. 

530
00:24:38,600 --> 00:24:40,700
What are the possible strings 
that can come here? 

531
00:24:40,800 --> 00:24:43,000
Are there any special strings 
that would make the program to 

532
00:24:43,000 --> 00:24:46,300
do something different? 
You do this / inputs, then when 

533
00:24:46,300 --> 00:24:48,400
you do the separately because 
it's just much easier for our 

534
00:24:48,400 --> 00:24:50,700
brains to process small things, 
right? 

535
00:24:50,900 --> 00:24:53,300
So you do each one of them 
separately, then you try to look

536
00:24:53,300 --> 00:24:57,300
at all of them together you look
for other possible Corner cases 

537
00:24:57,300 --> 00:25:00,500
and so that might be explicit on
the documentation or the 

538
00:25:00,500 --> 00:25:03,800
requirements and then and only 
then you come up with test cases

539
00:25:04,200 --> 00:25:07,400
and that is sort of the idea of 
specification based testing that

540
00:25:07,400 --> 00:25:10,100
you start your tests from what 
the program should do, and not 

541
00:25:10,100 --> 00:25:12,900
from the implementation. 
And I actually like this very 

542
00:25:12,900 --> 00:25:15,200
much, because as a developer, 
right, the person writing the 

543
00:25:15,200 --> 00:25:18,200
codes that I'm about to test. 
That gives me the opportunity to

544
00:25:18,200 --> 00:25:20,600
disconnect from implementation. 
Really focus. 

545
00:25:20,600 --> 00:25:23,100
Hey, this is the input that I'm 
going to pass the program. 

546
00:25:23,100 --> 00:25:26,100
This is the expected output. 
So this is my suggestion. 

547
00:25:26,100 --> 00:25:28,400
If you really want to be my 
little bit more systematic when 

548
00:25:28,400 --> 00:25:31,500
it comes to testing, His first 
step is start, dragging tests, 

549
00:25:31,500 --> 00:25:34,500
or creating test cases from the 
specs from the requirements. 

550
00:25:35,000 --> 00:25:37,400
So when we talk about 
specification based testing, I 

551
00:25:37,408 --> 00:25:41,100
think people always, I mean, not
always often associate with bdd 

552
00:25:41,200 --> 00:25:44,500
right Behavior driven design and
sometimes it's like gherkin type

553
00:25:44,500 --> 00:25:46,200
of language and things like 
that. 

554
00:25:46,300 --> 00:25:49,600
What's your view is of this, do 
you always have to come up with 

555
00:25:49,600 --> 00:25:53,400
bdd type of specification test? 
Or is there some other types of 

556
00:25:53,400 --> 00:25:56,800
tests that we can also use? 
Yeah very good question. 

557
00:25:57,000 --> 00:25:59,400
And maybe that's a difference 
between my book and No other 

558
00:25:59,400 --> 00:26:00,800
books. 
Usually when people talk about 

559
00:26:00,800 --> 00:26:03,400
specification based testing, 
they are focusing on a very 

560
00:26:03,400 --> 00:26:06,000
coarse grain feature from the 
point of view of user. 

561
00:26:06,400 --> 00:26:09,900
Why should I test in my book? 
I show that you can do this at 

562
00:26:09,900 --> 00:26:12,400
method level, for example or a 
class level because as a 

563
00:26:12,408 --> 00:26:14,900
developer, that sort of the 
unit's, you're always handling 

564
00:26:14,900 --> 00:26:18,300
with, right? 
And I think, to me, really makes

565
00:26:18,300 --> 00:26:21,000
more sense when you're looking 
at the big picture and looking 

566
00:26:21,000 --> 00:26:24,800
at the whole functionality from 
really, the point of view of the

567
00:26:24,800 --> 00:26:28,100
final user and the specification
based techniques you can apply 

568
00:26:28,100 --> 00:26:31,900
in both now, Should you write 
tests in a bdd style? 

569
00:26:32,300 --> 00:26:34,200
I think that's really a matter 
of taste. 

570
00:26:34,400 --> 00:26:38,400
I am personally not a bdd fan, 
so I don't like tests using vdd 

571
00:26:38,400 --> 00:26:40,000
style. 
I don't use cucumber. 

572
00:26:40,300 --> 00:26:43,500
That's just not my thing. 
But I see where this comes from,

573
00:26:43,500 --> 00:26:45,300
right. 
And I don't think, you know, in 

574
00:26:45,300 --> 00:26:48,100
practice, this is two different.
It's really telling you to focus

575
00:26:48,100 --> 00:26:50,100
on the specs, on the behavior of
the program, right? 

576
00:26:50,100 --> 00:26:52,800
And coming up with the best 
cases tooling is a matter of 

577
00:26:52,800 --> 00:26:54,500
personal taste in the end, 
right? 

578
00:26:54,600 --> 00:26:56,700
As long as you're looking at the
behavior of the program, what 

579
00:26:56,700 --> 00:26:59,500
you expect from it? 
I think this is a great Step 

580
00:26:59,500 --> 00:27:01,800
towards a good testing. 
Right. 

581
00:27:01,900 --> 00:27:05,000
You also mentioned just now in 
your explanation about Corner 

582
00:27:05,000 --> 00:27:07,000
cases, right? 
Sometimes when you have 

583
00:27:07,000 --> 00:27:09,900
requirements, most often, it's 
just the normal case, right? 

584
00:27:09,900 --> 00:27:11,600
I expect the program to work 
like this. 

585
00:27:11,900 --> 00:27:14,400
So first of all like who will 
come up with this corner cases 

586
00:27:14,700 --> 00:27:17,400
and how would you actually 
invite people to come up with 

587
00:27:17,400 --> 00:27:20,200
more creative Corner cases? 
And I know you mentioned about 

588
00:27:20,200 --> 00:27:22,900
boundary testing. 
Is it also one way to actually 

589
00:27:22,900 --> 00:27:25,300
generate Corner cases. 
So tell us more about this. 

590
00:27:26,100 --> 00:27:28,900
Yes indeed. 
So Corner cases are the cool. 

591
00:27:29,200 --> 00:27:33,400
Sprite and Empirical research 
actually shows that bugs, love 

592
00:27:33,400 --> 00:27:36,000
boundaries because we are very 
good at implementing happy 

593
00:27:36,000 --> 00:27:39,900
paths, the bugs, then they start
to cluster on things that were 

594
00:27:39,900 --> 00:27:42,200
not so good at that. 
Is to handle Corner cases, 

595
00:27:42,200 --> 00:27:44,600
right? 
And coming up with Corner cases,

596
00:27:44,600 --> 00:27:47,900
is very hard because we develop 
complex software systems, but 

597
00:27:47,900 --> 00:27:51,000
one way to get started is to 
observe your program. 

598
00:27:51,000 --> 00:27:54,400
You look at the inputs and how 
this inputs change the outputs 

599
00:27:54,600 --> 00:27:56,900
and Boundary testing is a 
perfect technique. 

600
00:27:56,900 --> 00:27:58,900
For this. 
What this boundary mean? 

601
00:27:59,100 --> 00:28:01,500
So imagine you have a very 
simple program, you know that 

602
00:28:01,500 --> 00:28:05,500
has an if if x greater than 5 do
something else. 

603
00:28:05,600 --> 00:28:09,100
So this if divides the execution
of the program so if the input 

604
00:28:09,100 --> 00:28:12,300
is 4 4 is not greater than 5. 
So the program will do 

605
00:28:12,300 --> 00:28:15,700
something. 
Then next 155 is not greater 

606
00:28:15,700 --> 00:28:17,900
than 5, so the program will do 
the same thing. 

607
00:28:18,200 --> 00:28:21,900
Now 66 is greater than 5 another
program, there's something else.

608
00:28:22,100 --> 00:28:25,300
There was a small change in the 
input from 5 to 6, right? 

609
00:28:25,300 --> 00:28:28,200
So there is more changing the 
integer value but the program 

610
00:28:28,200 --> 00:28:30,400
responded to something. 
Completely different. 

611
00:28:30,400 --> 00:28:33,800
So this is a boundary and this 
is precisely where you can write

612
00:28:33,800 --> 00:28:36,400
a test because we love to put 
bugs there, right? 

613
00:28:36,400 --> 00:28:38,300
And as a developer that makes 
sense because it's very easy to 

614
00:28:38,300 --> 00:28:40,900
confuse, you know, a greater 
than with a greater than or 

615
00:28:40,900 --> 00:28:42,900
equals to. 
And the ideal of boundary 

616
00:28:42,900 --> 00:28:45,600
testing is look at your program 
and look at the inputs and how 

617
00:28:45,600 --> 00:28:48,300
the inputs affect the outputs. 
And look for those moments where

618
00:28:48,300 --> 00:28:50,900
a small change in the input 
changes the output. 

619
00:28:51,200 --> 00:28:55,800
There's a paper from 1994, the 
reciting my book that explains 

620
00:28:55,800 --> 00:28:58,900
this in a more mathematical way.
So this was really written. 

621
00:28:59,100 --> 00:29:01,500
Buy a computer scientist and 
that shows that if you write 

622
00:29:01,500 --> 00:29:04,600
tests like this, you are more 
likely to reveal a bug. 

623
00:29:04,800 --> 00:29:07,200
And I think this is something 
very easy to change in the 

624
00:29:07,200 --> 00:29:09,000
behavior of the developer, 
right? 

625
00:29:09,000 --> 00:29:12,400
And it's like a very quick win. 
That will give you better test, 

626
00:29:12,400 --> 00:29:14,900
because as a developer, you look
in, if you write a test for the 

627
00:29:15,000 --> 00:29:16,800
true branch and for the false 
Branch. 

628
00:29:16,800 --> 00:29:19,200
But then we usually pick random 
numbers that exercise. 

629
00:29:19,200 --> 00:29:21,500
The true branch in that 
exercise, the false Branch 

630
00:29:21,600 --> 00:29:23,900
instead of picking random 
numbers, pick the numbers that 

631
00:29:23,900 --> 00:29:26,900
are close to the boundary. 
These two tests will be way 

632
00:29:26,900 --> 00:29:28,500
stronger than the other two 
tests. 

633
00:29:28,700 --> 00:29:30,800
That's Of exercise the 
programming the same way but 

634
00:29:30,800 --> 00:29:34,100
very far from the boundary. 
It's a very easy change and a 

635
00:29:34,108 --> 00:29:35,900
funny enough. 
I get emails from people reading

636
00:29:35,900 --> 00:29:38,900
my book and this part of the 
book is the ones that people 

637
00:29:38,900 --> 00:29:40,800
like the most. 
And people say, oh my God, this 

638
00:29:40,800 --> 00:29:43,700
is so simple and that really 
made my test so much better 

639
00:29:43,800 --> 00:29:46,200
because it's also easy. 
So think of boundary testing for

640
00:29:46,200 --> 00:29:48,000
sure. 
And of course in this example is

641
00:29:48,008 --> 00:29:51,400
very easy to find the boundaries
but more complex programs you're

642
00:29:51,400 --> 00:29:54,000
going to have to spend some time
looking for the boundaries, 

643
00:29:54,100 --> 00:29:56,800
identifying the boundaries, but 
that's just part of the exercise

644
00:29:56,800 --> 00:29:59,000
that we have to do. 
Now thanks for sharing this. 

645
00:29:59,100 --> 00:30:02,300
This technique this tip. 
So I really loved the way you 

646
00:30:02,300 --> 00:30:04,600
phrase it right box, love the 
boundaries. 

647
00:30:04,900 --> 00:30:07,600
So before people here, maybe 
that's also a lesson for all of 

648
00:30:07,600 --> 00:30:09,700
us, right? 
So when you think of test cases,

649
00:30:09,900 --> 00:30:12,900
now start to think in terms of 
boundary first then you can pick

650
00:30:12,900 --> 00:30:15,900
maybe some random inputs later 
on after you have covered the 

651
00:30:15,908 --> 00:30:18,300
boundaries. 
So let's move on to the next 

652
00:30:18,300 --> 00:30:21,600
technique, which you categorize,
as structural testing. 

653
00:30:21,800 --> 00:30:24,600
So maybe tell us more. 
What is structural, testing, how

654
00:30:24,600 --> 00:30:27,600
can we use it to become an 
effective software tester? 

655
00:30:28,300 --> 00:30:33,400
So structural Things sort of the
chemical name for using Code 

656
00:30:33,400 --> 00:30:36,200
coverage in practice. 
So the idea of structural 

657
00:30:36,200 --> 00:30:39,500
testing is let's use the 
structure of the program as a 

658
00:30:39,500 --> 00:30:41,400
source of inspiration to write 
tests. 

659
00:30:41,400 --> 00:30:45,200
So before we were looking at the
requirements with specification 

660
00:30:45,200 --> 00:30:46,800
based testing, right? 
Maybe texts. 

661
00:30:46,800 --> 00:30:49,800
Now we're looking at the 
implementation and trying to 

662
00:30:49,800 --> 00:30:52,000
come up with ideas and how do 
you do this while we look at 

663
00:30:52,000 --> 00:30:54,800
them, if statements and then you
think, well, I want to write a 

664
00:30:54,800 --> 00:30:58,200
test that actually exercises 
that if statement, and maybe you

665
00:30:58,200 --> 00:30:59,700
can do this line by line. 
A line, right? 

666
00:30:59,700 --> 00:31:02,800
And then once you cover all the 
lines, you're done with your 

667
00:31:02,800 --> 00:31:05,300
structural testing because you 
tested the structure in the way 

668
00:31:05,300 --> 00:31:08,100
you want and your coverage 
tools, give you this 

669
00:31:08,100 --> 00:31:10,300
information, right? 
You can see line coverage for 

670
00:31:10,300 --> 00:31:13,700
example, or you can be a little 
bit more thorough and say, well 

671
00:31:13,700 --> 00:31:17,100
I want to cover all the branches
and whenever there's an if I 

672
00:31:17,100 --> 00:31:19,700
want to make sure that there's a
test for the true branch in for 

673
00:31:19,700 --> 00:31:22,900
the false Branch, or you can go 
deeper an if statement can have 

674
00:31:22,900 --> 00:31:26,700
multiple conditions and I want 
to exercise every condition as 

675
00:31:26,700 --> 00:31:29,600
true and as false, right? 
So you can keep going Crazy 

676
00:31:29,600 --> 00:31:32,800
about this, but this is sort of 
structural testing and I think 

677
00:31:32,800 --> 00:31:36,200
the main point of my book is 
that there's this hate in 

678
00:31:36,200 --> 00:31:39,100
Industry about called coverage, 
right there are many reasons for

679
00:31:39,100 --> 00:31:42,600
this, you know, one, you can 
cheat the coverage number, 

680
00:31:42,700 --> 00:31:44,200
right? 
It's very easy to write a test 

681
00:31:44,200 --> 00:31:47,000
that covers a lot of stuff, but 
the test is not so good if 

682
00:31:47,000 --> 00:31:49,000
you're using coverage as a 
target number. 

683
00:31:49,000 --> 00:31:51,600
So let's say your company says 
90%. 

684
00:31:51,600 --> 00:31:53,300
Otherwise, we don't get from 
merge request. 

685
00:31:53,300 --> 00:31:56,100
Maybe that forces you to write 
useless test, just so you get to

686
00:31:56,100 --> 00:31:58,300
90%. 
Also, if you get to a hundred 

687
00:31:58,300 --> 00:32:00,800
percent coverage, Each that also
doesn't mean your code is 

688
00:32:00,800 --> 00:32:03,100
perfect, right? 
And it's quite expensive to get 

689
00:32:03,100 --> 00:32:06,200
to 100% College. 
This is why people usually hate 

690
00:32:06,200 --> 00:32:08,000
it. 
But I think people usually hate 

691
00:32:08,000 --> 00:32:11,200
cold coverage because they are 
focusing more on the number 

692
00:32:11,400 --> 00:32:15,000
rather than on the output the 
information that coverage brings

693
00:32:15,000 --> 00:32:16,500
to you, right? 
And in my book, I showed it 

694
00:32:16,500 --> 00:32:19,900
coverage should compliment 
specification testing because, 

695
00:32:19,900 --> 00:32:22,100
you know, you write the test 
based on the specification and 

696
00:32:22,100 --> 00:32:23,300
then you do, maybe boundary 
testing. 

697
00:32:23,300 --> 00:32:25,000
And then the question is, am I 
done? 

698
00:32:25,300 --> 00:32:27,700
Well, you can triangulate this 
and you can look at coverage, 

699
00:32:27,700 --> 00:32:29,800
right? 
And then you see, Did I cover 

700
00:32:29,800 --> 00:32:32,200
everything and maybe you forgot 
to cover something. 

701
00:32:32,200 --> 00:32:34,300
And then the question is, why 
did I forget was it? 

702
00:32:34,300 --> 00:32:36,700
Because I forgot was it, because
there was a mismatch between the

703
00:32:36,700 --> 00:32:39,500
requirements and the 
implementation you reflect about

704
00:32:39,500 --> 00:32:41,400
it. 
You either write a test or you 

705
00:32:41,400 --> 00:32:43,900
don't try to test and it's also 
fine, right? 

706
00:32:43,900 --> 00:32:47,400
But it helped you to reflect a 
multi, my done writing tests. 

707
00:32:47,700 --> 00:32:50,900
And if you use coverage with 
this purpose, notice that we are

708
00:32:50,900 --> 00:32:52,400
not talking about numbers 
anymore. 

709
00:32:52,500 --> 00:32:55,100
Furthermore, talking like the 
test that I wrote, are they good

710
00:32:55,100 --> 00:32:56,900
or not? 
And coverage is giving me 

711
00:32:56,900 --> 00:32:59,100
insights about it. 
And I think that story You 

712
00:32:59,100 --> 00:33:02,800
should use coverage but then the
1 million dollar question then 

713
00:33:02,800 --> 00:33:05,500
is also, okay. 
Okay, coverage is cool. 

714
00:33:05,700 --> 00:33:08,400
I use structural coverage that 
will maybe help me increase my 

715
00:33:08,400 --> 00:33:10,500
coverage because I'm going to 
look at an obstruction that I 

716
00:33:10,508 --> 00:33:12,500
didn't test. 
I'm going to test it now, is 

717
00:33:12,500 --> 00:33:16,100
there a correlation between High
coverage numbers and the 

718
00:33:16,100 --> 00:33:18,400
effectiveness of the test Suite?
So that's sweet. 

719
00:33:18,400 --> 00:33:21,200
That has a very high coverage. 
Is this one more likely to find 

720
00:33:21,200 --> 00:33:23,200
bugs? 
If I have a bug in my code? 

721
00:33:23,500 --> 00:33:26,400
And this is a perfect question 
for academics to answer, right? 

722
00:33:26,400 --> 00:33:30,000
And then you see lots of Papers 
written in my Besides papers 

723
00:33:30,000 --> 00:33:33,200
from the 1990s to 2010 or 
something. 

724
00:33:33,500 --> 00:33:38,100
And a lot of those papers show 
correlation between coverage and

725
00:33:38,100 --> 00:33:40,300
effectiveness of the test suite 
and that makes sense. 

726
00:33:40,300 --> 00:33:42,300
Right? 
Because the more code your test 

727
00:33:42,300 --> 00:33:44,800
Suite covers, the more likely it
will find a bug. 

728
00:33:44,800 --> 00:33:47,400
If you introduce a bug, of 
course, different paper, show 

729
00:33:47,400 --> 00:33:50,700
different levels of correlation,
some of them are strong, 

730
00:33:50,700 --> 00:33:52,700
correlations some others 
anymore, weak correlation, but 

731
00:33:52,700 --> 00:33:55,300
the correlation does exist. 
And I think the lesson that I 

732
00:33:55,300 --> 00:33:58,800
get from these papers are. 100 
coverage, may not mean a lot. 

733
00:33:59,000 --> 00:34:00,700
Because once you're there, 
you're desert very good. 

734
00:34:00,700 --> 00:34:02,300
But that doesn't mean it's 
perfect. 

735
00:34:02,300 --> 00:34:05,200
And then when you're at 100% 
coverage coverage doesn't give 

736
00:34:05,200 --> 00:34:08,199
you more useful information 
because it's all covered. 

737
00:34:08,300 --> 00:34:11,300
So if you're there that stream, 
then coverage is not so good 

738
00:34:11,300 --> 00:34:12,900
anymore for you. 
And doesn't tell you much with 

739
00:34:12,900 --> 00:34:14,699
each other on the other side. 
That is you have very low 

740
00:34:14,699 --> 00:34:16,800
coverage. 
That's a 10% then that means a 

741
00:34:16,808 --> 00:34:18,600
lot, right? 
That means your test Suite is 

742
00:34:18,600 --> 00:34:20,600
still, may be poor. 
Maybe there's something that you

743
00:34:20,600 --> 00:34:24,100
can improve their so, to 
summarize it in coverage can be 

744
00:34:24,100 --> 00:34:26,800
used as a way to complement your
tests to help. 

745
00:34:26,800 --> 00:34:28,900
You see if your test Suite is 
good enough for now. 

746
00:34:29,300 --> 00:34:33,300
In coverage, helps you to 
identify poorly tested areas of 

747
00:34:33,300 --> 00:34:35,900
the code base and hey, this is 
not covered. 

748
00:34:35,900 --> 00:34:37,400
So maybe I should write a bunch 
of tests for. 

749
00:34:37,400 --> 00:34:39,699
They don't have to go to a 
hundred percent coverage, but I 

750
00:34:39,707 --> 00:34:42,800
have to add some text for it. 
Well, I really love another 

751
00:34:42,800 --> 00:34:45,400
pragmatic advice on this, right?
Because people always debate 

752
00:34:45,400 --> 00:34:48,400
about code coverage. 
I know some companies also who 

753
00:34:48,500 --> 00:34:51,500
put code coverage as the 
so-called the build gate, right?

754
00:34:51,500 --> 00:34:54,400
So if you don't pass a certain 
threshold, will fail your build.

755
00:34:54,600 --> 00:34:57,100
So I think you remind us that 
code coverage should be a 

756
00:34:57,100 --> 00:34:59,000
complimentary thing. 
It should not be the main. 

757
00:34:59,100 --> 00:35:01,500
Main thing, right? 
And I really loved the way you 

758
00:35:01,500 --> 00:35:05,400
mentioned that 100% doesn't mean
that we will not find any bugs, 

759
00:35:05,400 --> 00:35:06,700
right? 
Although there's a correlation 

760
00:35:06,700 --> 00:35:09,500
of course, but a low coverage 
actually means that there are 

761
00:35:09,500 --> 00:35:12,500
room for improvement and I also 
like one particular statement 

762
00:35:12,500 --> 00:35:16,200
that you mentioned, how should 
we use a criteria in terms of 

763
00:35:16,200 --> 00:35:19,300
covering more line coverage you 
say in your book that all code 

764
00:35:19,400 --> 00:35:21,900
should be covered until proven 
otherwise, right? 

765
00:35:22,000 --> 00:35:25,400
So I think that's also another 
good guideline I find sometimes,

766
00:35:25,400 --> 00:35:28,600
we can leave some coverage 
behind but actually you should 

767
00:35:28,600 --> 00:35:30,000
have a good. 
Listen for that, right? 

768
00:35:30,000 --> 00:35:31,500
So I think that's a very good 
thing. 

769
00:35:31,700 --> 00:35:34,900
Another technique that sometimes
is used for, this is actually 

770
00:35:34,900 --> 00:35:37,400
called mutation testing. 
So this is also in the 

771
00:35:37,400 --> 00:35:39,500
structural test kind of 
territory. 

772
00:35:39,800 --> 00:35:42,400
So tell us more for people who 
may not have heard about this 

773
00:35:42,400 --> 00:35:46,700
term mutation testing what it is
and how does it help to provide 

774
00:35:46,700 --> 00:35:48,300
effective software testing as 
well? 

775
00:35:49,000 --> 00:35:51,400
Sure. 
So, how do you know if your test

776
00:35:51,400 --> 00:35:54,000
Suite is good or not? 
You can look at coverage for 

777
00:35:54,000 --> 00:35:57,700
sure, right? 
But maybe you can get to a lot 

778
00:35:57,700 --> 00:35:59,000
of coverage, but maybe your 
assertion. 

779
00:35:59,100 --> 00:36:01,400
As our poor, right, and then 
there's a bug but your 

780
00:36:01,400 --> 00:36:03,600
assertions are not catching that
bug but you're covering the 

781
00:36:03,600 --> 00:36:05,100
code. 
So your coverage is very high. 

782
00:36:05,400 --> 00:36:09,000
Mutation testing helps you to 
identify this Gap and what is 

783
00:36:09,000 --> 00:36:12,400
the idea, the idealist I'm going
to create mutants of my codes. 

784
00:36:12,600 --> 00:36:15,200
So imagine like, I just get your
production code and I own 

785
00:36:15,200 --> 00:36:18,700
purpose insert, the bug. 
So I change a greater than to a 

786
00:36:18,700 --> 00:36:22,300
smaller them, right? 
So let's say I do this, if I run

787
00:36:22,300 --> 00:36:25,300
the tests, your tests, you must 
have a test. 

788
00:36:25,300 --> 00:36:27,500
That is failing because it just 
introduced a bug. 

789
00:36:27,800 --> 00:36:31,100
If that happens, that means 
Okay, your test can actually q 

790
00:36:31,100 --> 00:36:33,100
that mutants. 
So your tests are doing some 

791
00:36:33,100 --> 00:36:36,700
good stuff but if I can mutate 
your code so they introduced a 

792
00:36:36,700 --> 00:36:38,800
bug on purpose in your tests are
still green. 

793
00:36:39,000 --> 00:36:42,000
Hey, I just found the case a 
possible bug that someone can 

794
00:36:42,000 --> 00:36:44,500
introduce that, you'll never 
know with your test Suite. 

795
00:36:44,800 --> 00:36:46,700
So that is the idea of mutation 
testing. 

796
00:36:47,000 --> 00:36:50,600
And what mutation testing tools 
do for you is to automate this 

797
00:36:50,600 --> 00:36:52,200
process. 
So they change your code, they 

798
00:36:52,200 --> 00:36:54,100
run your tests and they see for 
test. 

799
00:36:54,100 --> 00:36:57,600
Catch the bug and they repeat 
this in a structured way and 

800
00:36:57,600 --> 00:36:59,900
they give a beautiful report in 
the the end solely for in the 

801
00:36:59,900 --> 00:37:02,600
Java world. 
For example, like I am, you have

802
00:37:02,600 --> 00:37:06,200
Pi tests which is an open source
tool that does that for you. 

803
00:37:06,600 --> 00:37:08,800
And I love the idea of mutation 
testing. 

804
00:37:08,800 --> 00:37:11,900
It just makes a lot of sense to 
understand if your tests are 

805
00:37:11,900 --> 00:37:15,000
good or not, I think in practice
a lot of companies are not there

806
00:37:15,000 --> 00:37:17,400
yet to benefit from mutation 
testing. 

807
00:37:17,600 --> 00:37:20,500
You start to benefit from 
mutation testing when you have a

808
00:37:20,500 --> 00:37:22,200
lot of tests and have very good 
test. 

809
00:37:22,200 --> 00:37:24,400
Suites if your test Suite is 
very poor. 

810
00:37:24,700 --> 00:37:27,100
Well it doesn't get it doesn't 
kill any Mutant. 

811
00:37:27,100 --> 00:37:28,900
So why would you run mutants in 
first place? 

812
00:37:29,100 --> 00:37:30,400
Right. 
Comfort is good enough for you 

813
00:37:30,400 --> 00:37:32,400
at that moment. 
So I should like a lot of 

814
00:37:32,400 --> 00:37:34,900
companies are not there yet in 
terms of materiality to use 

815
00:37:35,100 --> 00:37:38,300
mutant but if you are so if you 
have a beautiful day sweetened 

816
00:37:38,600 --> 00:37:41,400
put mutants in your pipeline 
tools are evolving. 

817
00:37:41,400 --> 00:37:44,500
So by test is a very nice tool 
that are ways for you to reduce 

818
00:37:44,500 --> 00:37:47,100
the time it takes because it's 
an expensive process, right? 

819
00:37:47,100 --> 00:37:48,600
We have to mutate your code and 
run. 

820
00:37:48,600 --> 00:37:51,300
All your test suite and we do 
this a million times or the tool

821
00:37:51,300 --> 00:37:53,900
does this a million times. 
So those tools are getting 

822
00:37:53,900 --> 00:37:56,600
better and better you know. 
So that you just run the tests 

823
00:37:56,600 --> 00:37:58,900
that are really relevant for the
mutant and blah blah blah. 

824
00:37:59,400 --> 00:38:03,100
There's a beautiful paper that I
cite in my book called, I think 

825
00:38:03,100 --> 00:38:07,600
it's mutation testing at Google.
It was published in an academic 

826
00:38:07,600 --> 00:38:10,300
conference but in the industry 
track and that paper sort of 

827
00:38:10,300 --> 00:38:13,700
describes the experience of 
Google in trying to put mutation

828
00:38:13,700 --> 00:38:15,800
testing on scale mutation 
testing. 

829
00:38:15,800 --> 00:38:18,300
By the way, is also it dates 
from the 70s, right? 

830
00:38:18,300 --> 00:38:21,300
So the ideal is super old but I 
think now that we have very good

831
00:38:21,300 --> 00:38:24,600
Hardware to make it work and the
tools are getting better and 

832
00:38:24,600 --> 00:38:26,100
better. 
I think now that industry is 

833
00:38:26,100 --> 00:38:28,200
adopting it more, which is 
really cool. 

834
00:38:29,100 --> 00:38:33,400
Loved your analogy using mutants
to explain how this mutation 

835
00:38:33,400 --> 00:38:35,800
testing works. 
So, I think it's true that. 

836
00:38:35,800 --> 00:38:38,700
I think if you have a very low 
coverage or kind of like the 

837
00:38:38,700 --> 00:38:41,800
poor test Suite, you will not be
able to kill the mutant so to 

838
00:38:41,800 --> 00:38:43,500
speak, right? 
Because your test will always 

839
00:38:43,500 --> 00:38:45,100
pass because you don't cover 
enough. 

840
00:38:45,400 --> 00:38:47,800
Another technique that you 
mention in your book is called 

841
00:38:47,800 --> 00:38:50,300
property testing. 
How does this differ in what is 

842
00:38:50,300 --> 00:38:53,600
property testing? 
Yeah, so property based testing 

843
00:38:53,600 --> 00:38:56,700
is the way of writing a test 
that is different from the way 

844
00:38:56,800 --> 00:38:59,200
we write normal tests, right? 
So usually when we write, At a 

845
00:38:59,200 --> 00:39:02,300
normal test, which I call 
example based test in the book, 

846
00:39:02,600 --> 00:39:06,000
you know, in our minds, what 
sort of Branch you an exercise 

847
00:39:06,000 --> 00:39:08,700
in the cold or test case when I 
create based on requirements and

848
00:39:08,700 --> 00:39:11,900
what you do is you think of a 
concrete inputs that room run 

849
00:39:11,900 --> 00:39:14,800
the program will exercise the 
program in their way you want. 

850
00:39:15,000 --> 00:39:18,200
So in the example that I gave X 
greater than 5, it can be Any 

851
00:39:18,200 --> 00:39:21,200
number greater than 5 5 6 7 8, 
right? 

852
00:39:21,300 --> 00:39:23,900
And you pick just one because 
you're pregnant again because 

853
00:39:23,900 --> 00:39:25,200
you cannot do more than that, 
right? 

854
00:39:25,200 --> 00:39:28,400
So maybe we can do two or three 
or four then you cannot do 50 

855
00:39:28,400 --> 00:39:29,900
by. 
Right hand, it's just too 

856
00:39:29,900 --> 00:39:32,200
expensive. 
So this is example based testing

857
00:39:32,200 --> 00:39:35,200
because you're testing, by 
example, you pick one example in

858
00:39:35,200 --> 00:39:37,100
property, based testing what you
do. 

859
00:39:37,100 --> 00:39:40,100
Is you try to describe a 
property of the program and you 

860
00:39:40,107 --> 00:39:42,100
let the to come up with the 
inputs for you. 

861
00:39:42,400 --> 00:39:45,500
So, let's say in this program, 
if for any number that is 

862
00:39:45,500 --> 00:39:48,300
greater than 5, you know, that 
the output of the program, 

863
00:39:48,300 --> 00:39:49,800
should always be a positive 
number. 

864
00:39:49,900 --> 00:39:53,000
So, inputs, X greater than 5, 
then the program always prints 

865
00:39:53,000 --> 00:39:55,100
positive numbers. 
You can write the property and 

866
00:39:55,100 --> 00:39:58,000
then you say, create any number 
that is greater than 5. 

867
00:39:58,000 --> 00:40:01,300
And just assert, it's that the 
number that comes out of it is 

868
00:40:01,300 --> 00:40:03,200
positive. 
And then the two creates a lot 

869
00:40:03,200 --> 00:40:05,100
of inputs for you. 
So, for example, in the Java 

870
00:40:05,100 --> 00:40:08,000
world, you have J quick, when 
you run the test, Jake will 

871
00:40:08,000 --> 00:40:11,900
think of 1000 inputs for your 
function and it will send 1,000 

872
00:40:11,900 --> 00:40:14,400
input for your function. 
So in a way, you're exploring 

873
00:40:14,400 --> 00:40:17,300
way more, the domain of that 
input right? 

874
00:40:17,300 --> 00:40:19,300
Because you're not trying one 
example, you're trying multiple.

875
00:40:19,600 --> 00:40:22,500
So the ideal is very cool. 
It is, of course, much harder to

876
00:40:22,500 --> 00:40:25,500
write a test because you have to
stop thinking of specific 

877
00:40:25,500 --> 00:40:27,500
functionality when a test but 
more like what are the 

878
00:40:27,500 --> 00:40:30,400
properties of my program? 
That I want to exercise. 

879
00:40:30,700 --> 00:40:33,700
But once you can do this, then 
it's very powerful because 

880
00:40:33,900 --> 00:40:37,200
you're just testing a lot. 
So maybe another example so that

881
00:40:37,200 --> 00:40:39,800
you can see the usefulness of it
imaginary just implementing some

882
00:40:39,800 --> 00:40:42,500
data structure. 
So let's say you're implementing

883
00:40:42,500 --> 00:40:45,200
a set yourself, right? 
So you cannot have repeated 

884
00:40:45,200 --> 00:40:48,500
elements on the set and you can 
write a property based testing 

885
00:40:48,500 --> 00:40:52,300
that just transfer to insert 
random elements in the set and 

886
00:40:52,300 --> 00:40:55,500
you make sure that you're having
repeated elements and it doesn't

887
00:40:55,500 --> 00:40:56,700
matter. 
The order that you insert the 

888
00:40:56,707 --> 00:41:00,000
elements in the end, the 
property is The set must only 

889
00:41:00,000 --> 00:41:03,700
have unique elements in there 
and erectus like this. 

890
00:41:03,900 --> 00:41:06,700
And then suddenly you're testing
dozens and hundreds of 

891
00:41:06,700 --> 00:41:09,900
combinations of inserts of 
repeated stuff, new stuff 

892
00:41:09,900 --> 00:41:11,400
repeated stuff. 
Something that you would never 

893
00:41:11,400 --> 00:41:14,200
be able to do by hens. 
So that's how powerful those 

894
00:41:14,200 --> 00:41:16,500
things can be. 
Now we need Distributing 

895
00:41:16,500 --> 00:41:19,700
Information Systems, which is 
what a lot of us do property. 

896
00:41:19,700 --> 00:41:22,900
Based testing is I think you 
have less opportunities to write

897
00:41:22,900 --> 00:41:24,900
this to use property based 
testing. 

898
00:41:24,900 --> 00:41:27,700
So I still feel like example 
based testing is something you 

899
00:41:27,700 --> 00:41:31,300
should do as the to Approach but
considered property based 

900
00:41:31,300 --> 00:41:34,100
testing especially for 
situations like this where 

901
00:41:34,200 --> 00:41:37,300
sometimes you just feel unsure. 
This one example is enough and 

902
00:41:37,300 --> 00:41:39,800
it more and then property based 
testing can help. 

903
00:41:40,500 --> 00:41:42,700
Thanks for that. 
Toro, explanation about this 

904
00:41:42,700 --> 00:41:45,100
property, based testing. 
I personally haven't done, 

905
00:41:45,100 --> 00:41:47,400
mutation testing and property 
testing myself. 

906
00:41:47,400 --> 00:41:49,600
So I think it will be cool to 
introduce that. 

907
00:41:49,600 --> 00:41:51,600
Sometimes in my test Suites I 
guess. 

908
00:41:51,600 --> 00:41:54,400
So for people who also have an 
experienced it, I think you can 

909
00:41:54,400 --> 00:41:57,200
check some of the papers that 
Mauricio has mentioned. 

910
00:41:57,200 --> 00:41:59,200
Also, some more materials from 
his Book. 

911
00:41:59,200 --> 00:42:01,400
Make sure to check out as well 
talking about testing. 

912
00:42:01,400 --> 00:42:04,300
I think it will be a Miss if we 
don't discuss about test-driven 

913
00:42:04,300 --> 00:42:07,100
development or tdd. 
What's your view about this 

914
00:42:07,100 --> 00:42:10,000
workflow? 
Are you a proponent or do you 

915
00:42:10,008 --> 00:42:12,200
always do tdd? 
So maybe tell us more about 

916
00:42:12,200 --> 00:42:14,800
that. 
That's a tough question hearing 

917
00:42:14,800 --> 00:42:17,900
because usually you know you 
have some very passionate people

918
00:42:17,900 --> 00:42:19,600
about disturbing developments, 
right? 

919
00:42:19,600 --> 00:42:22,200
And sometimes I make fun with my
friends that on my Twitter 

920
00:42:22,200 --> 00:42:24,900
bubble, sometimes I just post 
something that says that he's 

921
00:42:24,900 --> 00:42:28,600
not that perfect. 
And then yeah a lot of backlash 

922
00:42:28,600 --> 00:42:31,400
in, right? 
And I'm a big fan of tdd. 

923
00:42:31,500 --> 00:42:35,000
I even wrote a book about TD 
until 2012, it's in Brazilian 

924
00:42:35,000 --> 00:42:37,500
Portuguese. 
So maybe not accessible for 

925
00:42:37,500 --> 00:42:40,300
everyone that's listening here 
and that was because I was doing

926
00:42:40,300 --> 00:42:44,000
a lot of DVD myself and I really
felt I was just being a better 

927
00:42:44,000 --> 00:42:47,800
developer doing tdd and this was
2012 and when I wrote the book 

928
00:42:47,800 --> 00:42:50,400
so I was doing tdd for a couple 
of years now, 2023. 

929
00:42:50,400 --> 00:42:54,000
I think I do 3D wave less and I 
feel that just because I found a

930
00:42:54,000 --> 00:42:58,300
way to get the benefits of tdd 
without having to do tdd and 

931
00:42:58,300 --> 00:42:59,700
what are these Benefits. 
Right. 

932
00:42:59,700 --> 00:43:02,400
What am I talking about? 
If you like the big benefit for 

933
00:43:02,400 --> 00:43:07,500
me, about TD is the ability is 
that we work on very small 

934
00:43:07,700 --> 00:43:11,000
steps, right? 
And we make very small steady 

935
00:43:11,000 --> 00:43:13,400
progress towards the bigger 
feature before. 

936
00:43:13,400 --> 00:43:16,600
Knowing TD, someone would give 
me a feature to implement and I 

937
00:43:16,600 --> 00:43:19,600
would be all over the place, 
trying to write the full 

938
00:43:19,600 --> 00:43:22,400
algorithm in one goal. 
And that would just complicate 

939
00:43:22,400 --> 00:43:24,100
my life. 
I would code for an entire day. 

940
00:43:24,100 --> 00:43:27,500
A lot of frustration because you
know you bump into barriers, you

941
00:43:27,500 --> 00:43:28,800
break stuff that was already 
working. 

942
00:43:29,000 --> 00:43:31,400
And so on and so forth. 
And then after, you know, a few 

943
00:43:31,400 --> 00:43:34,100
days of work or whatever, then 
writing test is, you know, I 

944
00:43:34,100 --> 00:43:35,700
just want to get this feature 
done. 

945
00:43:35,700 --> 00:43:37,500
I don't want to do this anymore,
right? 

946
00:43:37,700 --> 00:43:41,400
And we tdd it was like, oh, and 
I cannot do tdd if I work on 

947
00:43:41,400 --> 00:43:45,200
such a big chunk of code. 
So it forced me to see 

948
00:43:45,200 --> 00:43:48,500
programming as an act of writing
small things, and combining 

949
00:43:48,500 --> 00:43:50,900
these small things. 
One by one to give bigger 

950
00:43:50,900 --> 00:43:53,200
Behavior. 
I think that's sort of the big 

951
00:43:53,200 --> 00:43:55,800
difference between TV and known 
tdd. 

952
00:43:56,100 --> 00:43:59,100
And if you can incorporate these
three development practice I 

953
00:43:59,100 --> 00:44:01,200
think it's okay if you don't 
start with the test. 

954
00:44:01,200 --> 00:44:03,500
So today, for example, in a lot 
of cases, I actually start with 

955
00:44:03,500 --> 00:44:06,700
the production code but my 
coding sessions are very small. 

956
00:44:06,900 --> 00:44:09,300
I write a little bit of 
production code and then a 

957
00:44:09,300 --> 00:44:12,200
little bit of testing the 
experiments sometimes I delete 

958
00:44:12,200 --> 00:44:14,600
the code and I start again and 
do it small tests. 

959
00:44:15,000 --> 00:44:18,100
I think if you find your way to 
work on small and steady steps, 

960
00:44:18,400 --> 00:44:21,300
I think you got the benefit from
DVD and this is actually what's 

961
00:44:21,300 --> 00:44:24,300
more recent research shows about
test-driven development. 

962
00:44:24,400 --> 00:44:27,700
So if you look at the whole body
of knowledge on DVD, you see 

963
00:44:27,700 --> 00:44:31,000
papers and What have you built 
of these papers in a nutshell 

964
00:44:31,200 --> 00:44:33,600
qualitatively. 
If they s developers that are 

965
00:44:33,600 --> 00:44:35,400
doing tdd, do you like to 
delete? 

966
00:44:35,500 --> 00:44:37,000
The answer will be. 
Yes, I am. 

967
00:44:37,000 --> 00:44:39,800
Actually one of the authors of 
these papers, I wrote a paper 

968
00:44:39,800 --> 00:44:41,800
that did qualitative research on
this and that was sort of the 

969
00:44:41,808 --> 00:44:44,200
feedback we like tdd 
quantitatively. 

970
00:44:44,400 --> 00:44:47,200
If you compare the quality of 
the test Suites in comparison to

971
00:44:47,200 --> 00:44:50,500
people, not doing tdd. 
The differences are negligible 

972
00:44:50,800 --> 00:44:53,300
very small. 
So 3D by itself doesn't do 

973
00:44:53,300 --> 00:44:55,800
magic. 
So more recent research actually

974
00:44:55,800 --> 00:44:58,800
shows that the benefits are on 
those small steps. 

975
00:44:59,000 --> 00:45:02,000
And not because you're writing 
the test before that means side,

976
00:45:02,000 --> 00:45:04,600
do I recommend you to do tdd 
definitely? 

977
00:45:04,600 --> 00:45:06,900
Yes. 
Especially if you've never done 

978
00:45:06,900 --> 00:45:10,000
it because if you never done it,
odds are you're not used to work

979
00:45:10,000 --> 00:45:12,700
on doing small things. 
We're just used to work on big 

980
00:45:12,700 --> 00:45:15,100
things. 
So TD is the best teacher, you 

981
00:45:15,100 --> 00:45:18,900
can have when it comes to 
explain to you how to program in

982
00:45:18,900 --> 00:45:21,900
small bits. 
So, do tdd, do a lot of it. 

983
00:45:22,200 --> 00:45:24,800
Once you internalize the ideas, 
then it's okay. 

984
00:45:25,100 --> 00:45:26,400
Then you don't have to do it 
anymore. 

985
00:45:26,900 --> 00:45:28,700
Wow. 
It's like a safety will write so

986
00:45:28,700 --> 00:45:30,400
too. 
Figure out you start using it 

987
00:45:30,400 --> 00:45:33,300
and once you kind of like Master
it and like a bicycle, right? 

988
00:45:33,300 --> 00:45:36,700
You can take it off and you can 
choose when to use it and when 

989
00:45:36,700 --> 00:45:39,800
not to use it, and I like that, 
you mention about this Empirical

990
00:45:39,800 --> 00:45:42,600
research, when I read it in your
book, I was intrigued. 

991
00:45:42,800 --> 00:45:46,800
This research doesn't actually 
show that TD produces much way 

992
00:45:46,800 --> 00:45:50,300
better test versus the non TDS. 
So I think that's really cool to

993
00:45:50,300 --> 00:45:52,700
know about this and I think I'll
make sure to put it in the show 

994
00:45:52,700 --> 00:45:55,700
notes as well, for people who 
are interested and also have 

995
00:45:55,700 --> 00:45:58,800
passion about Didi. 
It's not saying that tdd is not.

996
00:45:58,900 --> 00:46:00,500
Good, right? 
But I think it's the mindset of 

997
00:46:00,500 --> 00:46:03,600
working with small things. 
That is very important. 

998
00:46:03,700 --> 00:46:06,500
So we have a few minutes left 
before we go to the technical 

999
00:46:06,500 --> 00:46:08,700
leadership. 
Wisdom, I have one question, 

1000
00:46:08,700 --> 00:46:12,300
maybe tips from you for people 
to be able to become a better 

1001
00:46:12,300 --> 00:46:15,500
tester in terms of their quality
or maintainability. 

1002
00:46:15,500 --> 00:46:18,600
Is there any few tips that you 
can just give us here so that we

1003
00:46:18,600 --> 00:46:20,900
can improve? 
That's a very good question 

1004
00:46:20,900 --> 00:46:24,400
because, you know, if you really
write lots of tests you're going

1005
00:46:24,400 --> 00:46:26,500
to have lots of source code in, 
they're going to have to 

1006
00:46:26,500 --> 00:46:29,800
maintain this as well. 
Not only Production codes, 

1007
00:46:29,800 --> 00:46:32,100
right? 
So I think all the love that you

1008
00:46:32,100 --> 00:46:34,300
put in your production code. 
You also have to putting a 

1009
00:46:34,300 --> 00:46:37,700
passcode and to me in the test 
code if you have to focus on one

1010
00:46:37,700 --> 00:46:41,100
thing because in my book I 
mentioned lots of ideas you know

1011
00:46:41,100 --> 00:46:43,700
good practices that you can have
to make a cool beautiful and 

1012
00:46:43,700 --> 00:46:45,900
blah blah blah. 
But if I can just talk about one

1013
00:46:46,100 --> 00:46:49,000
that is you have to make sure 
that the part of your test where

1014
00:46:49,000 --> 00:46:51,300
you create the data, right? 
That you create the inputs that 

1015
00:46:51,300 --> 00:46:52,900
you're going to pass it to the 
method, or to the class, you 

1016
00:46:52,900 --> 00:46:55,500
want to test. 
That part has to be crystal 

1017
00:46:55,500 --> 00:46:57,400
clear. 
Because if you're working in a 

1018
00:46:57,400 --> 00:47:00,400
very complex information, Mmm, 
odds are that the complexity of 

1019
00:47:00,400 --> 00:47:03,200
the test will be in that part. 
So that part needs to be very 

1020
00:47:03,200 --> 00:47:05,700
easy to read. 
It has to be very easy to evolve

1021
00:47:05,700 --> 00:47:08,900
because your entities in your 
domain are evolving all the 

1022
00:47:08,900 --> 00:47:10,900
time. 
So it has to be easy to make an 

1023
00:47:10,900 --> 00:47:13,100
evolution in the production 
code, without breaking the test 

1024
00:47:13,100 --> 00:47:17,900
code, and it has to be easy for 
you to come up with complex data

1025
00:47:17,900 --> 00:47:21,900
inputs without having to spend 
50 100 lines of codes. 

1026
00:47:22,200 --> 00:47:24,800
So you have to have lots of 
utility methods or whatever you 

1027
00:47:24,800 --> 00:47:27,100
want to call it that help you 
build data, right? 

1028
00:47:27,100 --> 00:47:30,900
Test data, Builders the famous. 
For patterns like this, you need

1029
00:47:30,900 --> 00:47:33,900
to invest on them. 
So, that is my tip number one, 

1030
00:47:33,900 --> 00:47:35,600
and that's what you need to 
focus. 

1031
00:47:36,100 --> 00:47:37,700
Input data has to be Crystal, 
Clear? 

1032
00:47:38,300 --> 00:47:41,100
Yeah, I also mentioned reading 
about this in the I think the 

1033
00:47:41,100 --> 00:47:43,800
growing's object-oriented 
software Guided by test. 

1034
00:47:43,900 --> 00:47:46,600
Right, I think this is also one 
key technique that is mentioned 

1035
00:47:46,600 --> 00:47:48,500
in the book. 
So I really love it because I 

1036
00:47:48,500 --> 00:47:51,700
have seen in my experience 
before seeing, you know, lines 

1037
00:47:51,700 --> 00:47:55,000
of test code which are probably 
too complicated to understand 

1038
00:47:55,000 --> 00:47:57,600
and especially the part where 
you produce this test data, 

1039
00:47:57,600 --> 00:48:00,000
right? 
Initially, We will see a lot of 

1040
00:48:00,000 --> 00:48:02,700
gibberish, probably like, why 
are these logic here? 

1041
00:48:02,700 --> 00:48:05,600
But it's actually to produce 
test data and I think it's a 

1042
00:48:05,600 --> 00:48:07,800
really, really important for us 
here to improve. 

1043
00:48:08,300 --> 00:48:11,900
And if I can tell a personal 
story Henry, if I can tell a 

1044
00:48:11,900 --> 00:48:14,600
personal story, you mentioned 
this growing object-oriented 

1045
00:48:14,700 --> 00:48:17,500
Guided by test, right? 
Altered by Steve Freeman, 

1046
00:48:17,500 --> 00:48:20,600
Annette pranks and I have a very
funny story about it because in 

1047
00:48:20,607 --> 00:48:24,200
2010 there was this Workshop in 
Terris about test-driven 

1048
00:48:24,200 --> 00:48:27,400
development, the one and only on
the series and I had a paper 

1049
00:48:27,400 --> 00:48:30,100
there and Treatment. 
The author of the book was 

1050
00:48:30,100 --> 00:48:32,900
giving a keynote and so he gave 
the keynote and it was then 

1051
00:48:32,900 --> 00:48:35,800
giving a presenting my paper and
you, my paper will siphon him a 

1052
00:48:35,808 --> 00:48:37,900
lot, so that was like, Freeman 
and price. 

1053
00:48:37,900 --> 00:48:40,800
Say this in the yearbook at some
point, Steve looked at me, you 

1054
00:48:40,800 --> 00:48:42,800
know, for like, because it was a
tenth time. 

1055
00:48:42,800 --> 00:48:44,800
I said his name on my 
presentation and then I said, 

1056
00:48:44,800 --> 00:48:46,900
I'm sorry. 
I just like her book, very much 

1057
00:48:47,300 --> 00:48:50,900
and we became friends, right? 
And when I moved to Europe, then

1058
00:48:50,900 --> 00:48:54,200
we were closer to each other and
then Steve started to teach one 

1059
00:48:54,200 --> 00:48:56,300
guest lecture every year in my 
course in delft. 

1060
00:48:56,300 --> 00:48:59,800
So he always comes to death 
every year from my I course and 

1061
00:48:59,800 --> 00:49:02,800
that book influenced me a lot 
and he's, in fact, one of the 

1062
00:49:03,000 --> 00:49:04,900
forward altars of my book, 
right? 

1063
00:49:04,900 --> 00:49:08,300
So one of the forward there was 
written by Steve, so he 

1064
00:49:08,300 --> 00:49:11,100
influenced me a lot in this book
is an amazing book if you have 

1065
00:49:11,100 --> 00:49:14,700
the chance to read it as well. 
Well thanks for sharing about 

1066
00:49:14,700 --> 00:49:16,600
this personal story. 
I find it really, really 

1067
00:49:16,600 --> 00:49:18,800
interesting. 
So I think that's also One Good 

1068
00:49:18,800 --> 00:49:21,000
Reason. 
How do you get connected to a 

1069
00:49:21,200 --> 00:49:23,200
more famous gas of famous 
authors. 

1070
00:49:23,200 --> 00:49:24,500
So I think thanks for sharing 
that. 

1071
00:49:25,000 --> 00:49:28,100
So, as I mentioned, I have one 
last question that normally, I 

1072
00:49:28,100 --> 00:49:30,200
ask for all. 
Guess which is called the tree 

1073
00:49:30,200 --> 00:49:32,500
technical leadership, is them. 
You can think of it just like 

1074
00:49:32,500 --> 00:49:35,200
advice that you want to give to 
the listeners here, maybe from 

1075
00:49:35,200 --> 00:49:37,000
your experience, from the 
expertise. 

1076
00:49:37,200 --> 00:49:39,300
What would be some of your 
wisdom that you can share? 

1077
00:49:39,300 --> 00:49:42,500
Here, Maurice, you three. 
Let's do it. 

1078
00:49:42,800 --> 00:49:45,900
So number one focused on these 
episodes, right? 

1079
00:49:45,900 --> 00:49:50,600
So you should Master testing and
measuring testing means not only

1080
00:49:50,600 --> 00:49:53,800
mastering the tools like ju and 
it and mockito and whatever to 

1081
00:49:53,800 --> 00:49:56,600
you use. 
But also mastering creating good

1082
00:49:56,600 --> 00:49:59,600
test cases. 
And once It's you really become 

1083
00:49:59,600 --> 00:50:02,000
proficient with it. 
It just becomes way easier and 

1084
00:50:02,000 --> 00:50:04,800
way cheaper. 
So you start having less reasons

1085
00:50:04,800 --> 00:50:06,900
not to do it because it just 
more natural. 

1086
00:50:07,300 --> 00:50:09,100
How do you get there by 
practicing? 

1087
00:50:09,100 --> 00:50:11,400
Right, it's going to hurt at the
beginning but the more you do 

1088
00:50:11,400 --> 00:50:15,200
it, the easier it will get. 
So practice, testing advice 

1089
00:50:15,200 --> 00:50:18,600
number two, for software 
engineers in general is you 

1090
00:50:18,600 --> 00:50:20,900
should never stop learning, 
right? 

1091
00:50:20,900 --> 00:50:23,900
I think it's very easy for us, 
you know, a lot of us, go 

1092
00:50:23,900 --> 00:50:26,800
through education and then we 
just join a company and you 

1093
00:50:26,808 --> 00:50:28,700
start working as a developer and
then send it. 

1094
00:50:29,000 --> 00:50:31,800
We forget that we need to keep 
updating ourselves. 

1095
00:50:32,000 --> 00:50:34,300
I once heard from a developer, 
you know, hey, I'm here working 

1096
00:50:34,300 --> 00:50:37,200
for two years in a row and I 
started to read this book. 

1097
00:50:37,500 --> 00:50:39,700
I recommend the book to this 
person, and he said, I started 

1098
00:50:39,700 --> 00:50:41,900
to read this book in a few. 
So nice to learn something new, 

1099
00:50:41,900 --> 00:50:44,000
and I don't know why I wasn't 
reading books before. 

1100
00:50:44,000 --> 00:50:46,700
I guess I was just too busy 
working, and that's life. 

1101
00:50:46,700 --> 00:50:49,100
That's life, we're all adults, 
we have responsibilities, it's 

1102
00:50:49,100 --> 00:50:51,900
very hard. 
So, I think you have to find 

1103
00:50:51,900 --> 00:50:54,400
time during her work hours. 
To be honest, your employee 

1104
00:50:54,400 --> 00:50:56,900
needs to be on this to upskill 
yourself. 

1105
00:50:57,100 --> 00:50:59,800
So read books. 
Are you interested in? 

1106
00:50:59,800 --> 00:51:03,700
I don't know, microservices with
the book so just keep studying 

1107
00:51:03,700 --> 00:51:06,900
because there's so much new 
stuff going on and so many best 

1108
00:51:06,900 --> 00:51:10,000
practices and something that I 
feel among developers is that a 

1109
00:51:10,008 --> 00:51:13,300
lot of them when they go, you 
know, in a big company and 

1110
00:51:13,300 --> 00:51:15,900
you're going to have this big 
discussions to decide what 

1111
00:51:15,900 --> 00:51:19,000
architecture to take, should we 
use practice a versus B? 

1112
00:51:19,000 --> 00:51:22,400
Whatever people have intuition, 
but they have very little 

1113
00:51:22,400 --> 00:51:25,500
evidence to explain to people 
and if a reading books you have 

1114
00:51:25,500 --> 00:51:28,600
clear ways to explain why you 
want to go for this or not. 

1115
00:51:28,800 --> 00:51:31,900
That's so there are so many 
benefits in studying and putting

1116
00:51:31,900 --> 00:51:34,300
studying as part of your daily 
job. 

1117
00:51:34,700 --> 00:51:38,300
And so work on this, make sure 
you study a lot in advice. 

1118
00:51:38,300 --> 00:51:41,200
Number three will be. 
You just learned a lot from my 

1119
00:51:41,200 --> 00:51:42,800
advice number two, because 
you're studying. 

1120
00:51:43,100 --> 00:51:45,300
Now, it's time to share your 
knowledge. 

1121
00:51:45,700 --> 00:51:48,100
So make sure you also write 
about what you learn or give 

1122
00:51:48,100 --> 00:51:51,500
talks at conferences, right? 
And this is very good for you 

1123
00:51:51,700 --> 00:51:55,300
because it exposes you to other 
people, it forces you to 

1124
00:51:55,300 --> 00:51:58,700
formalize what's in your head. 
And you have to put in words and

1125
00:51:58,800 --> 00:52:01,200
I find that putting in words is 
the best way for you to really 

1126
00:52:01,200 --> 00:52:03,500
understand how much understand 
about something. 

1127
00:52:03,900 --> 00:52:05,700
And maybe that's because, you 
know, I have this academic 

1128
00:52:05,700 --> 00:52:07,700
background. 
So writing really helps me to 

1129
00:52:07,700 --> 00:52:09,900
see how much I understand about 
something. 

1130
00:52:10,300 --> 00:52:12,500
It's good for you, right? 
Because you're just getting 

1131
00:52:12,500 --> 00:52:14,200
better as a person as a 
developer. 

1132
00:52:14,300 --> 00:52:16,600
And it's also good for others 
because I'm pretty sure you have

1133
00:52:16,600 --> 00:52:20,200
cool stuff to share and that 
will be others that are willing 

1134
00:52:20,200 --> 00:52:23,300
to listen to you. 
So please share knowledge. 

1135
00:52:23,400 --> 00:52:25,900
It's as important as learning 
new knowledge. 

1136
00:52:26,500 --> 00:52:29,100
So there you go, the tree. 
Is Henry. 

1137
00:52:29,300 --> 00:52:32,600
Well, really beautiful. 
Thanks for sharing that after I 

1138
00:52:32,600 --> 00:52:34,700
hear about our discussion about 
testing. 

1139
00:52:34,700 --> 00:52:37,800
Now, I think sharing is like a 
form of testing itself, right? 

1140
00:52:37,800 --> 00:52:41,200
That you actually learn from 
what you study, right from 

1141
00:52:41,200 --> 00:52:43,800
reading the books and things 
like that, may be the best test 

1142
00:52:43,800 --> 00:52:46,300
case that you write for those 
learning is actually to share it

1143
00:52:46,300 --> 00:52:49,600
either, you know, writing a blog
or whatever YouTube video and 

1144
00:52:49,600 --> 00:52:51,300
things like that. 
So I'm having this testing 

1145
00:52:51,300 --> 00:52:54,500
mindset these days after hearing
what you explained earlier. 

1146
00:52:54,500 --> 00:52:57,500
So thank you so much for 
covering this testing. 

1147
00:52:57,500 --> 00:53:00,700
I think it's really part of Out 
of the skill set that developers

1148
00:53:00,700 --> 00:53:02,700
should Master more, right? 
Like, what you mentioned in your

1149
00:53:02,700 --> 00:53:06,100
first wisdom, developers need to
practice more and be good at 

1150
00:53:06,100 --> 00:53:09,100
testing because I think that 
really is the key to produce a 

1151
00:53:09,100 --> 00:53:12,000
quality software. 
So for people who love to 

1152
00:53:12,000 --> 00:53:14,700
connect with you, maybe to talk 
more about testing, is there a 

1153
00:53:14,700 --> 00:53:16,500
place where they can reach you 
on mine? 

1154
00:53:16,900 --> 00:53:19,800
I'm always on Twitter. 
So it's at now, this your 

1155
00:53:19,800 --> 00:53:22,400
nation. 
So my name and my surname, I 

1156
00:53:22,400 --> 00:53:25,600
also have a free newsletter 
related to my book so if you go 

1157
00:53:25,600 --> 00:53:29,400
to the website effective Dash 
software Dash testing, You can 

1158
00:53:29,400 --> 00:53:32,800
subscribe to the newsletter. 
Those are the best ways to get 

1159
00:53:32,800 --> 00:53:35,500
in contact with me for sure. 
LinkedIn, you can also add me on

1160
00:53:35,500 --> 00:53:38,100
LinkedIn now. 
Recent issue find me, feel free 

1161
00:53:38,100 --> 00:53:39,600
to drop me a message there as 
well. 

1162
00:53:40,300 --> 00:53:43,400
Cool, so I'll make sure to put 
the newsletter as well, so that 

1163
00:53:43,400 --> 00:53:45,300
people can learn maybe every 
week, right? 

1164
00:53:45,300 --> 00:53:47,600
How do you improve your testing 
experience. 

1165
00:53:47,900 --> 00:53:49,700
So, thank you so much for your 
time and ratio. 

1166
00:53:49,700 --> 00:53:53,200
I hope people enjoy learning 
about testing and I wish that 

1167
00:53:53,200 --> 00:53:56,600
your book is also going to be 
teaching people a lot more about

1168
00:53:56,600 --> 00:53:58,500
how to produce the best quality 
code. 

1169
00:53:58,800 --> 00:54:02,400
Thank you so much, Henry Ford 
invite and I hope you like it 

1170
00:54:02,600 --> 00:54:03,600
everyone. 
Bye bye. 

1171
00:54:06,200 --> 00:54:09,500
Thank you for listening to this 
episode and for staying, right 

1172
00:54:09,500 --> 00:54:11,900
until the end if you highly 
enjoyed it. 

1173
00:54:12,100 --> 00:54:14,400
I would appreciate if you share 
it with your friends and 

1174
00:54:14,400 --> 00:54:17,400
colleagues who you think would 
also benefit from listening to 

1175
00:54:17,400 --> 00:54:19,500
this episode. 
And if you are new to the 

1176
00:54:19,500 --> 00:54:22,500
podcast, make sure to subscribe 
and leave me your valuable 

1177
00:54:22,500 --> 00:54:25,500
review and feedback. 
It helps me a lot in order to 

1178
00:54:25,500 --> 00:54:28,700
grow this podcast better. 
You can also find the full show 

1179
00:54:28,700 --> 00:54:32,300
notes of this conversation on 
the episode page, at Tech Legion

1180
00:54:32,300 --> 00:54:35,900
o.f website, including the full 
transcript interesting. 

1181
00:54:36,000 --> 00:54:39,000
Quotes and links to the 
resources mention from the 

1182
00:54:39,000 --> 00:54:41,800
conversation. 
And lastly, make sure to 

1183
00:54:41,800 --> 00:54:44,100
subscribe to the shows mailing 
list on package. 

1184
00:54:44,100 --> 00:54:47,700
You know, dot f to get notified 
for any future episodes. 

1185
00:54:48,100 --> 00:54:49,700
Stay tuned for the next 
technology. 

1186
00:54:49,700 --> 00:54:52,500
No episode. 
And until then goodbye.