1 files changed, 199 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt
new file mode 100644
index 0000000..5164f1a
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt
@@ -0,0 +1,199 @@
+1
+00:00:00,140 --> 00:00:02,790
+Now, let's go back to our systematic functional testing
+
+2
+00:00:02,790 --> 00:00:05,540
+approach and all the steps in this process. So
+
+3
+00:00:05,540 --> 00:00:07,680
+far we've seen the first step and the second
+
+4
+00:00:07,680 --> 00:00:10,340
+step. Now we're going to look at this step in which,
+
+5
+00:00:10,340 --> 00:00:13,290
+once we have identified the values of interest, we
+
+6
+00:00:13,290 --> 00:00:18,110
+derive test case specifications for these values, or using these
+
+7
+00:00:18,110 --> 00:00:21,300
+values. And the test case specification defines how the
+
+8
+00:00:21,300 --> 00:00:25,230
+values should be put together when actually testing the system.
+
+9
+00:00:25,230 --> 00:00:29,110
+And test case specification describe how these values should be put
+
+10
+00:00:29,110 --> 00:00:32,360
+together when testing the system. So let me go back one more
+
+11
+00:00:32,360 --> 00:00:34,780
+time to our split program, so that we can use the
+
+12
+00:00:34,780 --> 00:00:37,450
+information that we already computed. At this point what we have is
+
+13
+00:00:37,450 --> 00:00:41,670
+some possible inputs for "string," our first parameter, and for "size,"
+
+14
+00:00:41,670 --> 00:00:44,410
+our second parameter. And we want to put them together, to generate
+
+15
+00:00:44,410 --> 00:00:47,080
+the description of what the test case should be. So let
+
+16
+00:00:47,080 --> 00:00:50,420
+me once more rearrange this a little bit. I first remove the
+
+17
+00:00:50,420 --> 00:00:53,360
+description of the subdomains, because we won't use them in this step.
+
+18
+00:00:53,360 --> 00:00:55,800
+And I moved out the set of all our possible inputs, that we're
+
+19
+00:00:55,800 --> 00:00:59,470
+going to combine to create the test case specification. And one possible way
+
+20
+00:00:59,470 --> 00:01:03,320
+of doing that is simply to combine the values for the first parameter,
+
+21
+00:01:03,320 --> 00:01:06,370
+and the values for the second parameter. So the Cartesian product. So
+
+22
+00:01:06,370 --> 00:01:09,060
+if we do that, what we will obtain is, for example, if we
+
+23
+00:01:09,060 --> 00:01:12,470
+consider the first possible input, size is equal to minus 1, we can
+
+24
+00:01:12,470 --> 00:01:15,510
+combine it with these two possible inputs for string, and we will get
+
+25
+00:01:15,510 --> 00:01:18,680
+size is equal to minus 1 string with length minus 2, or
+
+26
+00:01:18,680 --> 00:01:21,680
+size is equal to minus 1 string with length minus 1. And we'll
+
+27
+00:01:21,680 --> 00:01:24,200
+go back in a second to see what this means. Now if we
+
+28
+00:01:24,200 --> 00:01:27,510
+consider the second possible value for size, size is equal to one, we
+
+29
+00:01:27,510 --> 00:01:30,260
+also have two cases so the first one in this case that will
+
+30
+00:01:30,260 --> 00:01:34,030
+be considered a string with length zero. So the antistring. And we can
+
+31
+00:01:34,030 --> 00:01:37,410
+continue combining this value, but one thing I want to point out is
+
+32
+00:01:37,410 --> 00:01:40,570
+that if we just go in this straight forward and brute force sort
+
+33
+00:01:40,570 --> 00:01:43,390
+of way, we will obtain many combinations that don't make any sense,
+
+34
+00:01:43,390 --> 00:01:46,500
+like for example, this combination which doesn't make any sense because we can
+
+35
+00:01:46,500 --> 00:01:50,410
+not create the string with length minus 2. Similar for this combination, because
+
+36
+00:01:50,410 --> 00:01:53,190
+then by the same token, we cannot raise things with length minus 1.
+
+37
+00:01:53,190 --> 00:01:55,730
+And so there's a lot of cases that we will have to eliminate
+
+38
+00:01:55,730 --> 00:01:59,380
+afterwards. So what we're going to see in a few minutes is a possible
+
+39
+00:01:59,380 --> 00:02:02,970
+way in which we can avoid producing these meaningless cases. And at the
+
+40
+00:02:02,970 --> 00:02:06,380
+same time, keep under control, the number of test cases that we generate.
+
+41
+00:02:06,380 --> 00:02:09,070
+So lets go back for the last time to our steps
+
+42
+00:02:09,070 --> 00:02:11,980
+for systematic functional testing. What we just did was to derive
+
+43
+00:02:11,980 --> 00:02:15,040
+test case specification from a set of relevant inputs. The following
+
+44
+00:02:15,040 --> 00:02:18,420
+step is to use these test case specifications to generate actual test
+
+45
+00:02:18,420 --> 00:02:21,170
+cases. And this is normally a fairly mechanical step in the
+
+46
+00:02:21,170 --> 00:02:23,900
+sense that we just have to instantiate what is in the test
+
+47
+00:02:23,900 --> 00:02:27,970
+case specification as actual test cases. And it's really dependent on
+
+48
+00:02:27,970 --> 00:02:32,300
+the specific type of partitions and values identified on the specific context.
+
+49
+00:02:32,300 --> 00:02:35,100
+So instead of looking at that here in the, in the abstract,
+
+50
+00:02:35,100 --> 00:02:37,480
+I'm going to show you with an example later on, in the lesson.