1 files changed, 143 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/11 - Why Not Random Testing? - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/11 - Why Not Random Testing? - lang_en_vs4.srt
new file mode 100644
index 0000000..a91af45
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/11 - Why Not Random Testing? - lang_en_vs4.srt
@@ -0,0 +1,143 @@
+1
+00:00:00,310 --> 00:00:02,250
+So then maybe what we can do is just to
+
+2
+00:00:02,250 --> 00:00:05,720
+pick our test inputs randomly so to do what is called
+
+3
+00:00:05,720 --> 00:00:08,850
+random testing. And what that means is that we pick the
+
+4
+00:00:08,850 --> 00:00:11,720
+inputs to test just as we pick a number by rolling
+
+5
+00:00:11,720 --> 00:00:15,410
+a set of dice randomly. And this will have several advantages.
+
+6
+00:00:15,410 --> 00:00:18,780
+First, we will pick inputs uniformly. So if we use a
+
+7
+00:00:18,780 --> 00:00:21,790
+uniform distribution as the basis for our random testing, we will
+
+8
+00:00:21,790 --> 00:00:25,540
+make no preferences. In other words, all inputs will be considered
+
+9
+00:00:25,540 --> 00:00:28,324
+equal, of equal value. And what that means in turn, is
+
+10
+00:00:28,324 --> 00:00:32,640
+that random testing eliminates designer bias. So what does designer bias
+
+11
+00:00:32,640 --> 00:00:36,030
+mean? Designer bias is the problem of making the same assumption,
+
+12
+00:00:36,030 --> 00:00:38,570
+when we read the specification and we interpret it and when we
+
+13
+00:00:38,570 --> 00:00:42,100
+develop test cases. Which means that the developer might develop code,
+
+14
+00:00:42,100 --> 00:00:44,930
+assuming a given behavior of the user. And we may write
+
+15
+00:00:44,930 --> 00:00:47,520
+tests, making the same assumptions. And the problem, of course, is
+
+16
+00:00:47,520 --> 00:00:50,690
+even worse if it's the same person that develops the code and
+
+17
+00:00:50,690 --> 00:00:53,730
+writes the test cases. With random testing, the problem is gone,
+
+18
+00:00:53,730 --> 00:00:57,440
+because we just pick randomly what our inputs will be. So
+
+19
+00:00:57,440 --> 00:01:00,180
+why not do in random? The problem is that when testing,
+
+20
+00:01:00,180 --> 00:01:03,610
+we are looking for a needle in a haystack. Actually, multiple
+
+21
+00:01:03,610 --> 00:01:06,620
+needles in multiple haystacks, if we want to be precise. So,
+
+22
+00:01:06,620 --> 00:01:09,500
+random approaches are not necessarily the best way to go about
+
+23
+00:01:09,500 --> 00:01:12,430
+it, because we might just be looking in all the wrong
+
+24
+00:01:12,430 --> 00:01:15,760
+places. So let me show you this, using a different representation
+
+25
+00:01:15,760 --> 00:01:18,000
+for the haystack. What I'm showing here is a grid, and
+
+26
+00:01:18,000 --> 00:01:22,130
+imagine this grid just expanding indefinitely outside the screen, and this grid
+
+27
+00:01:22,130 --> 00:01:26,120
+represents the domain for the program, so each box in the grid,
+
+28
+00:01:26,120 --> 00:01:29,050
+each square in the grid, it's a possible input. So what happens
+
+29
+00:01:29,050 --> 00:01:32,670
+with bugs is that bugs are very scarce in this grid. Maybe
+
+30
+00:01:32,670 --> 00:01:35,070
+there is a bug here, so that means that there is a
+
+31
+00:01:35,070 --> 00:01:38,090
+bug, than an input, in this point we'll reveal. And maybe there
+
+32
+00:01:38,090 --> 00:01:40,820
+is another bug that will be triggered by an input over here.
+
+33
+00:01:40,820 --> 00:01:44,570
+So imagine this spread out over this infinite grid. Its very unlikely
+
+34
+00:01:44,570 --> 00:01:47,440
+that just by picking randomly that we will be able to get to
+
+35
+00:01:47,440 --> 00:01:50,910
+these two points. Fortunately not all is lost, there is a silver lining.
+
+36
+00:01:50,910 --> 00:01:53,410
+So we need to look a little more in depth into this grid.