1
00:00:00,040 --> 00:00:02,400
Welcome back to the Deep dive. 
Today we're moving past the 

2
00:00:02,400 --> 00:00:05,120
usual suspects, you know, unit 
integration tests. 

3
00:00:05,440 --> 00:00:08,520
We're going deeper into some 
other really crucial testing 

4
00:00:08,520 --> 00:00:11,000
types in software development. 
Think of it getting the inside 

5
00:00:11,000 --> 00:00:13,320
scoop. 
Our guide for this is Software 

6
00:00:13,320 --> 00:00:17,160
Engineering a Modern Approach by
Marco Tulio Valente. 

7
00:00:17,240 --> 00:00:19,280
Great book packed with useful 
stuff. 

8
00:00:19,640 --> 00:00:22,720
And our goal simple, quickly 
pull out the key ideas about 

9
00:00:22,720 --> 00:00:24,880
these less common tests so 
you're up to speed fast. 

10
00:00:25,280 --> 00:00:27,760
OK, let's impact this. 
So when people talk testing 

11
00:00:27,760 --> 00:00:30,760
techniques, black box and white 
box usually come up first. 

12
00:00:31,120 --> 00:00:33,160
Seems basic, but what is the 
real difference? 

13
00:00:33,160 --> 00:00:34,480
And why should we, you know, 
care? 

14
00:00:34,600 --> 00:00:37,920
Yeah, good starting point. 
The core difference, really it 

15
00:00:37,920 --> 00:00:42,000
just comes down to what you know
about the codes insides when 

16
00:00:42,000 --> 00:00:44,000
you're testing it. 
So black box testing, you're 

17
00:00:44,000 --> 00:00:46,960
intentionally only looking at 
the outside the interface, like 

18
00:00:46,960 --> 00:00:49,560
what's the function name, what 
parameters does it take? 

19
00:00:49,560 --> 00:00:52,480
What's it supposed to give back 
any errors it might throw? 

20
00:00:52,560 --> 00:00:54,080
You don't see the actual code 
lines. 

21
00:00:54,080 --> 00:00:56,320
It's often called functional 
testing too because you're just 

22
00:00:56,320 --> 00:00:59,120
checking if it does what it's 
supposed to do functionally. 

23
00:00:59,440 --> 00:01:02,760
Think about testing a car with 
black box. 

24
00:01:02,760 --> 00:01:05,319
You just use the steering wheel,
the pedals, the lights. 

25
00:01:05,319 --> 00:01:06,560
You wouldn't look under the hood
at all. 

26
00:01:06,560 --> 00:01:08,280
Just does it drive? 
Does it stop? 

27
00:01:09,080 --> 00:01:13,440
OK, so exterior view only what 
it does not how so white boxes 

28
00:01:13,440 --> 00:01:15,200
pop in the hood? 
Exactly. 

29
00:01:15,200 --> 00:01:17,440
Yeah, white box testing is the 
opposite. 

30
00:01:17,680 --> 00:01:21,200
Your tests use information about
the internal code structure. 

31
00:01:21,360 --> 00:01:24,240
You are looking under the hood. 
You're looking at the source 

32
00:01:24,240 --> 00:01:26,720
code, maybe thinking about the 
different paths through the 

33
00:01:26,720 --> 00:01:29,640
logic, the decision points, the 
loops, how things connect 

34
00:01:29,640 --> 00:01:31,080
inside. 
Sometimes called structural 

35
00:01:31,080 --> 00:01:33,560
tests. 
Here you might write tests 

36
00:01:33,560 --> 00:01:36,880
specifically to make sure, say, 
every single line of code gets 

37
00:01:36,880 --> 00:01:40,520
run at least once. 
Or maybe every if statement gets

38
00:01:40,520 --> 00:01:43,400
tested for both true and false 
conditions. 

39
00:01:43,680 --> 00:01:46,120
Using the car analogy, you'd be 
like the mechanics checking the 

40
00:01:46,120 --> 00:01:48,960
engine itself, the wiring, 
making sure each part works 

41
00:01:48,960 --> 00:01:51,040
right? 
It's an internal inspection. 

42
00:01:51,120 --> 00:01:52,880
Got it. 
Black is outside, white is 

43
00:01:52,880 --> 00:01:55,880
inside. 
Seems clear enough, but what 

44
00:01:55,880 --> 00:01:58,760
about unit tests? 
I feel like I hear conflicting 

45
00:01:58,760 --> 00:02:00,800
things. 
Are they black or white or 

46
00:02:00,840 --> 00:02:02,760
neither? 
That's a really sharp question 

47
00:02:02,760 --> 00:02:05,240
because unit tests are kind of 
slippery. 

48
00:02:05,240 --> 00:02:06,800
They don't have to be 1 or the 
other. 

49
00:02:06,800 --> 00:02:08,840
It actually depends entirely on 
how you write them. 

50
00:02:08,840 --> 00:02:10,520
OK, yeah. 
If you write a unit test just 

51
00:02:10,520 --> 00:02:14,160
based on the public interface, 
the method signature, what it 

52
00:02:14,160 --> 00:02:17,400
promises to do, you're treating 
that unit like a black box, 

53
00:02:17,680 --> 00:02:20,640
purely external view, right? 
Based on the spec. 

54
00:02:20,640 --> 00:02:23,320
Exactly. 
But let's say you write a test. 

55
00:02:23,320 --> 00:02:26,440
Then you run a code coverage 
tool and you see oh, this else 

56
00:02:26,440 --> 00:02:29,560
branch wasn't executed. 
If you then write another test 

57
00:02:29,560 --> 00:02:32,360
specifically to hit that 
internal branch, now you're 

58
00:02:32,360 --> 00:02:34,400
using knowledge of the internal 
structure. 

59
00:02:35,000 --> 00:02:37,720
So that makes it white box even 
though it's still a unit test? 

60
00:02:37,760 --> 00:02:41,320
Precisely your motivation for 
writing that second test came 

61
00:02:41,320 --> 00:02:44,280
from looking inside. 
So the same unit can be tested 

62
00:02:44,280 --> 00:02:47,640
with both black box and white 
box approaches, even within unit

63
00:02:47,640 --> 00:02:49,440
testing. 
That clears things up. 

64
00:02:49,600 --> 00:02:51,800
It's the approach, not the test 
type itself. 

65
00:02:52,600 --> 00:02:55,720
And this whole blurring lines 
thing, it applies to TDD too, 

66
00:02:55,720 --> 00:02:57,800
right? 
Test Driven Development because 

67
00:02:57,800 --> 00:02:59,560
you write tests first there. 
Absolutely. 

68
00:02:59,560 --> 00:03:01,680
TDD is a fascinating case study 
for this. 

69
00:03:01,720 --> 00:03:03,920
Kent Beck himself said something
really insightful about it. 

70
00:03:03,920 --> 00:03:06,640
He basically said, look, TDD 
tests are written before the 

71
00:03:06,640 --> 00:03:10,280
code exists, so by definition 
they have to be black box tests.

72
00:03:10,280 --> 00:03:13,000
Initially you're testing against
an interface that isn't 

73
00:03:13,000 --> 00:03:14,160
implemented yet. 
Makes sense. 

74
00:03:14,440 --> 00:03:17,600
But then, he added, he often 
gets the inspiration for the 

75
00:03:17,600 --> 00:03:20,200
next test by looking at the code
he just wrote to make the 

76
00:03:20,200 --> 00:03:22,920
previous test pass. 
Right, which is white box 

77
00:03:22,920 --> 00:03:24,080
thinking. 
Exactly. 

78
00:03:24,080 --> 00:03:25,920
That's the hallmark of white box
testing. 

79
00:03:25,920 --> 00:03:29,320
So what's fascinating here? 
Whereas key DD isn't strictly 

80
00:03:29,320 --> 00:03:31,920
one or the other. 
It's this cycle. 

81
00:03:31,960 --> 00:03:34,360
You start black box. 
What should it do? 

82
00:03:34,920 --> 00:03:38,000
Write minimal code, then use 
white box insight. 

83
00:03:38,240 --> 00:03:41,640
How does it work now to figure 
out the next black box test? 

84
00:03:41,640 --> 00:03:45,040
What else should it do? 
It really shows these categories

85
00:03:45,040 --> 00:03:48,120
aren't rigid boxes in practice, 
they're more like different ways

86
00:03:48,120 --> 00:03:50,840
of looking at the problem. 
It's a really practical way to 

87
00:03:50,840 --> 00:03:52,680
see it. 
Not strict rules, but useful 

88
00:03:52,680 --> 00:03:55,440
perspectives. 
OK, so we know how we might look

89
00:03:55,440 --> 00:03:57,880
at the code, but what do we 
actually test it with? 

90
00:03:57,880 --> 00:04:00,120
What data? 
Because like you said, testing 

91
00:04:00,120 --> 00:04:00,960
everything. 
Forget it. 

92
00:04:00,960 --> 00:04:03,760
Even for simple functions, A 
function taking two integers, 

93
00:04:04,040 --> 00:04:05,800
testing every combo could take 
forever. 

94
00:04:05,840 --> 00:04:07,920
Literally. 
And just picking random inputs 

95
00:04:07,920 --> 00:04:10,040
that sounds hit or miss. 
You might test the same kind of 

96
00:04:10,040 --> 00:04:11,560
thing over and over and miss 
something crucial. 

97
00:04:11,760 --> 00:04:13,480
Here's where it gets really 
interesting. 

98
00:04:13,760 --> 00:04:16,480
You've hit on a huge challenge. 
Since exhaustive testing is out,

99
00:04:16,480 --> 00:04:19,160
especially for black box, we 
need smarter ways to choose our 

100
00:04:19,160 --> 00:04:22,640
test inputs and a key technique 
here is equivalence classes. 

101
00:04:22,880 --> 00:04:26,080
The idea is simple but powerful.
You look at all the possible 

102
00:04:26,080 --> 00:04:28,080
inputs and divide them into 
groups or classes. 

103
00:04:28,200 --> 00:04:30,600
Within each group, all the 
inputs are considered equivalent

104
00:04:30,600 --> 00:04:33,480
in the sense that if one of them
finds a bug, any other input in 

105
00:04:33,480 --> 00:04:35,000
that same group probably would 
too. 

106
00:04:35,000 --> 00:04:36,640
OK. 
Grouping similar inputs. 

107
00:04:36,640 --> 00:04:38,680
Exactly. 
And the beauty is you only need 

108
00:04:38,680 --> 00:04:41,520
to test one representative value
from each distinct class. 

109
00:04:41,760 --> 00:04:44,160
This massively cuts down the 
number of tests you need. 

110
00:04:44,320 --> 00:04:46,280
Let's use that income tax 
example from the book. 

111
00:04:46,280 --> 00:04:54,040
Remember the salary ranges Range
one $1930.99 to $2826.65 gets 

112
00:04:54,040 --> 00:05:01,840
7.5% tax. 
Range two $2826.66 to $3764.68 

113
00:05:01,840 --> 00:05:04,080
gets 22.5%. 
Range 4. 

114
00:05:04,080 --> 00:05:08,160
Anything above $4064.68 gets 
27.5% right? 

115
00:05:08,200 --> 00:05:11,040
Four different tax brackets. 
So using equivalence classes, 

116
00:05:11,040 --> 00:05:14,240
you wouldn't test thousands of 
salaries, You'd identify these 4

117
00:05:14,240 --> 00:05:17,680
ranges as your equivalence 
classes for valid inputs and you

118
00:05:17,680 --> 00:05:21,520
just one salary from each range.
Maybe 2000 dollars, 3000 

119
00:05:21,520 --> 00:05:25,480
dollars, $4000 and $5000. 
Just four tests to cover the 

120
00:05:25,480 --> 00:05:27,880
core logic for all valid 
positive salaries. 

121
00:05:27,880 --> 00:05:30,880
That's incredibly efficient 
compared to trying everything. 

122
00:05:31,080 --> 00:05:35,000
Just pick one from each zone. 
What about the edges, The exact 

123
00:05:35,000 --> 00:05:36,520
points where the tax rate 
changes? 

124
00:05:36,520 --> 00:05:38,920
Aren't those risky spots? 
Absolutely spot on. 

125
00:05:39,040 --> 00:05:42,840
Those edges or boundaries are 
notorious bug hot spots, and 

126
00:05:42,840 --> 00:05:45,160
that's why equivalence classes 
often go hand in hand with 

127
00:05:45,160 --> 00:05:47,600
another technique, boundary 
value analysis. 

128
00:05:47,840 --> 00:05:50,000
Equivalence classes tell you 
which groups to test. 

129
00:05:50,200 --> 00:05:52,680
Boundary value analysis tells 
you which specific values, 

130
00:05:52,680 --> 00:05:55,320
especially around the edges of 
those groups, are most critical.

131
00:05:55,520 --> 00:05:58,480
The thinking is programmers 
often make off by 1 errors or 

132
00:05:58,480 --> 00:06:01,040
handle comparisons incorrectly. 
Right at the limits. 

133
00:06:01,040 --> 00:06:02,440
Yeah, I. 
Can see that like using tech 

134
00:06:02,440 --> 00:06:04,280
instead of. 
Exactly that kind of thing. 

135
00:06:04,280 --> 00:06:07,280
So boundary value analysis says 
for each boundary of an 

136
00:06:07,280 --> 00:06:10,080
equivalence class, test the 
boundary value itself, the value

137
00:06:10,080 --> 00:06:12,080
just before it, and the value 
just after it. 

138
00:06:12,360 --> 00:06:16,600
Let's take that first salary 
range again, $1903.99 to 

139
00:06:16,600 --> 00:06:21,280
$2826.65. 
Boundary value analysis would 

140
00:06:21,280 --> 00:06:22,840
suggest testing these specific 
values. 

141
00:06:22,840 --> 00:06:26,920
For that lower boundary, 
$1930.98 just below the 

142
00:06:26,920 --> 00:06:30,840
boundary, $1923.99 right on the 
boundary. 

143
00:06:31,120 --> 00:06:37,920
For the upper boundary, $2826 
right on the boundary, $2826.66 

144
00:06:38,200 --> 00:06:40,680
just above the boundary. 
OK, so you're testing the exact 

145
00:06:40,680 --> 00:06:43,120
point and also making sure you 
don't accidentally include 

146
00:06:43,120 --> 00:06:46,080
values just outside the range or
exclude values right on the 

147
00:06:46,080 --> 00:06:47,080
edge. 
Precisely. 

148
00:06:47,160 --> 00:06:49,560
You're probing those transition 
points very carefully. 

149
00:06:50,160 --> 00:06:52,800
Mining equivalence classes with 
boundary value analysis gives 

150
00:06:52,800 --> 00:06:55,240
you pretty good coverage without
needing an impossible number of 

151
00:06:55,240 --> 00:06:56,840
tests. 
It makes total sense, though I 

152
00:06:56,840 --> 00:06:59,800
guess defining those classes and
boundaries isn't always as neat 

153
00:06:59,800 --> 00:07:02,480
as salary ranges, right? 
Like for a text field or 

154
00:07:02,480 --> 00:07:04,920
something more complex. 
That's true, it requires more 

155
00:07:04,920 --> 00:07:08,240
thought sometimes for text, 
boundaries might be empty 

156
00:07:08,240 --> 00:07:11,360
string, minimum length, maximum 
length, strings with special 

157
00:07:11,360 --> 00:07:14,520
characters, etcetera. 
But the core idea of 

158
00:07:14,520 --> 00:07:17,440
partitioning inputs and checking
edges still applies. 

159
00:07:18,200 --> 00:07:19,800
Right. 
OK, so we've COVID testing from 

160
00:07:19,800 --> 00:07:22,600
the inside, testing from the 
outside, picking smart inputs, 

161
00:07:22,960 --> 00:07:25,320
but ultimately software has to 
work for the customer. 

162
00:07:25,680 --> 00:07:27,200
Let's talk about acceptance 
tests. 

163
00:07:27,200 --> 00:07:29,280
These are done by users, right? 
Exactly. 

164
00:07:29,440 --> 00:07:31,480
This is where the rubber really 
meets the road. 

165
00:07:31,800 --> 00:07:34,600
Acceptance tests are all about 
the customer deciding if the 

166
00:07:34,600 --> 00:07:38,080
software is, well, acceptable, 
doesn't meet their needs, will 

167
00:07:38,080 --> 00:07:40,600
they sign off on it? 
This decision determines if it 

168
00:07:40,600 --> 00:07:42,560
ships to production or needs 
more work. 

169
00:07:43,200 --> 00:07:46,640
In Agile, you often hear that a 
user's story isn't truly done 

170
00:07:46,640 --> 00:07:50,240
until it passes its acceptance 
tests, which are usually defined

171
00:07:50,240 --> 00:07:52,920
and run by the product owner or 
a customer proxy. 

172
00:07:53,080 --> 00:07:56,440
So what makes these tests 
different besides who runs them?

173
00:07:56,440 --> 00:07:57,800
They sound like they might be 
manual. 

174
00:07:58,000 --> 00:08:02,120
Yes, that's one key difference. 
Acceptance tests are typically 

175
00:08:02,120 --> 00:08:05,680
manual tests, real people 
interacting with the system 

176
00:08:05,920 --> 00:08:08,880
customers or their 
representatives, not usually 

177
00:08:08,880 --> 00:08:10,720
automated scripts written by 
devs. 

178
00:08:11,320 --> 00:08:13,960
The 2nd and maybe even more 
important difference connects 

179
00:08:13,960 --> 00:08:16,880
back to something we mentioned 
earlier, verification versus 

180
00:08:16,880 --> 00:08:20,160
validation. 
Right verification is did we 

181
00:08:20,160 --> 00:08:23,080
build it? 
Right validation is did we build

182
00:08:23,080 --> 00:08:24,920
the right thing? 
You got it. 

183
00:08:25,160 --> 00:08:28,440
Most of the tests we discussed 
earlier, unit integration, even 

184
00:08:28,440 --> 00:08:31,640
system tests based on specs, are
primarily verification. 

185
00:08:32,000 --> 00:08:34,039
They check if the software 
matches the blueprint. 

186
00:08:34,480 --> 00:08:37,200
Acceptance tests are 
fundamentally about validation. 

187
00:08:37,240 --> 00:08:39,640
They check if the software 
actually solves the customer's 

188
00:08:39,640 --> 00:08:42,720
real problem and meets their 
actual needs, which might not 

189
00:08:42,720 --> 00:08:44,760
have been perfectly captured in 
the initial specs. 

190
00:08:45,040 --> 00:08:48,480
It's the ultimate reality check.
That's a crucial distinction. 

191
00:08:48,880 --> 00:08:51,960
Building the wrong thing 
perfectly is still building the 

192
00:08:51,960 --> 00:08:53,520
wrong thing. 
Are there different types of 

193
00:08:53,520 --> 00:08:56,320
these acceptance tests? 
Yes, there's usually a sequence.

194
00:08:56,320 --> 00:08:59,080
First comes alpha testing. 
This happens with real 

195
00:08:59,080 --> 00:09:01,240
customers, but it's in a 
controlled environment. 

196
00:09:01,480 --> 00:09:04,920
Think maybe at the developer's 
office or on a specific testing 

197
00:09:04,920 --> 00:09:07,840
set they control. 
It's a small group, close 

198
00:09:07,840 --> 00:09:11,280
interaction, easy to observe and
get quick feedback. 

199
00:09:11,280 --> 00:09:12,760
OK, like a review. 
Screening. 

200
00:09:13,080 --> 00:09:16,960
Kind of, yeah. 
If the alpha tests go well, then

201
00:09:16,960 --> 00:09:20,640
you might move to beta testing. 
Beta tests involve a much larger

202
00:09:20,640 --> 00:09:22,680
group of customers using the 
software in their own 

203
00:09:22,680 --> 00:09:25,080
environments, on their own 
hardware, doing their own real 

204
00:09:25,080 --> 00:09:27,080
tasks. 
It's no longer controlled. 

205
00:09:27,400 --> 00:09:30,040
This is where you find issues 
related to diverse setups, 

206
00:09:30,280 --> 00:09:33,480
unexpected workflows, and just 
general real world chaos that 

207
00:09:33,480 --> 00:09:35,200
you can't easily simulate. 
Got it. 

208
00:09:35,480 --> 00:09:39,520
Alpha is controlled, beta is out
in the wild, more or less. 

209
00:09:39,560 --> 00:09:42,760
OK, OK, so far it feels like 
most of these tests, black box, 

210
00:09:42,760 --> 00:09:45,920
white box, equivalence classes, 
even acceptance to some extent, 

211
00:09:45,920 --> 00:09:47,760
are focused on finding 
functional bugs. 

212
00:09:48,560 --> 00:09:50,160
Does the software do what it's 
supposed to? 

213
00:09:50,160 --> 00:09:53,880
But what about everything else? 
Like how fast is it? 

214
00:09:54,040 --> 00:09:56,160
How easy is it to use? 
What happens if something 

215
00:09:56,160 --> 00:09:57,720
breaks? 
So what does this all mean for a

216
00:09:57,720 --> 00:10:00,040
complete testing strategy? 
We need to test that other stuff

217
00:10:00,040 --> 00:10:02,280
too, right? 
Absolutely critical point. 

218
00:10:02,280 --> 00:10:05,240
Focusing only on functional 
requirements is a huge mistake. 

219
00:10:05,720 --> 00:10:08,720
The non functional stuff, 
performance, usability, 

220
00:10:08,720 --> 00:10:11,560
reliability is often just as 
important for success. 

221
00:10:12,000 --> 00:10:14,680
O yes, a complete strategy must 
include tests for these 

222
00:10:14,680 --> 00:10:17,640
nonfunctional requirements. 
Take erformance tests. 

223
00:10:17,960 --> 00:10:20,440
These measure how the system 
behaves under load. 

224
00:10:20,960 --> 00:10:23,800
Think about that ecommerce site 
getting ready for Black Friday. 

225
00:10:24,400 --> 00:10:27,000
They don't just need the buy 
button to work, they need it to 

226
00:10:27,000 --> 00:10:29,560
work fast for millions of 
simultaneous users. 

227
00:10:29,880 --> 00:10:31,800
Otherwise, nobody buys anything.
Exactly. 

228
00:10:31,800 --> 00:10:35,080
So they'll run load tests, 
stress tests, pushing it until 

229
00:10:35,080 --> 00:10:38,160
it breaks to see where the limit
is, spike tests, sudden bursts 

230
00:10:38,160 --> 00:10:41,120
of traffic, all to ensure it 
performs well under pressure. 

231
00:10:41,160 --> 00:10:42,520
OK. 
Performance is key. 

232
00:10:42,880 --> 00:10:44,200
What else? 
You mentioned usability. 

233
00:10:44,400 --> 00:10:47,880
Right usability tests. 
These focus purely on the user 

234
00:10:47,880 --> 00:10:49,640
interface and the user 
experience. 

235
00:10:49,840 --> 00:10:52,120
Is it easy to learn? 
Efficient to use? 

236
00:10:52,160 --> 00:10:54,480
Are the buttons clear? 
Is the workflow logical? 

237
00:10:54,960 --> 00:10:57,760
This often involves watching 
real users try to accomplish 

238
00:10:57,760 --> 00:11:00,240
tasks with the software and 
seeing where they get stuck or 

239
00:11:00,240 --> 00:11:02,560
confused. 
It's less about code bugs and 

240
00:11:02,560 --> 00:11:04,680
more about design flaws. 
Makes sense. 

241
00:11:04,880 --> 00:11:07,000
A functional but unusable system
isn't much good. 

242
00:11:07,200 --> 00:11:10,480
And the last one, failure. 
We test for failure. 

243
00:11:10,480 --> 00:11:14,720
We do failure tests, sometimes 
called resilience or chaos 

244
00:11:14,720 --> 00:11:17,040
testing. 
The idea isn't to prevent all 

245
00:11:17,040 --> 00:11:19,440
failures, That's impossible in 
complex systems. 

246
00:11:19,640 --> 00:11:22,880
It's about simulating failures 
to see how the system reacts. 

247
00:11:23,160 --> 00:11:26,040
What happens if a key database 
goes down, or a network 

248
00:11:26,040 --> 00:11:29,840
connection fails, or an entire 
server rack loses power? 

249
00:11:29,920 --> 00:11:31,560
Yikes, you actually simulate 
that. 

250
00:11:31,560 --> 00:11:33,560
You do, in controlled ways. 
Hopefully. 

251
00:11:33,920 --> 00:11:36,600
The goal is to ensure the system
degrades gracefully, maybe 

252
00:11:36,600 --> 00:11:39,640
switches to a backup, recovers 
properly, and doesn't, you know,

253
00:11:39,640 --> 00:11:41,880
corrupt all its data or crash 
entirely. 

254
00:11:42,120 --> 00:11:44,840
It's about building resilient 
systems that can handle the 

255
00:11:44,840 --> 00:11:46,680
inevitable bumps in the road. 
Wow. 

256
00:11:47,280 --> 00:11:50,440
OK, so black box, white box, 
equivalence classes, boundary 

257
00:11:50,440 --> 00:11:54,120
values, alpha, beta performance,
usability, failure tests. 

258
00:11:54,480 --> 00:11:57,520
It's quite a landscape beyond 
just unit and integration. 

259
00:11:57,800 --> 00:11:59,760
There's been a really insightful
deep dive. 

260
00:11:59,760 --> 00:12:02,400
Thanks for joining us today and 
exploring this wider world of 

261
00:12:02,400 --> 00:12:03,160
software testing.