1 files changed, 179 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt
new file mode 100644
index 0000000..75da7e8
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt
@@ -0,0 +1,179 @@
+1
+00:00:00,140 --> 00:00:02,690
+So what is the starting point of black box testing? Black
+
+2
+00:00:02,690 --> 00:00:06,010
+box testing start from a description of the software or as we
+
+3
+00:00:06,010 --> 00:00:09,590
+call it, a functional specification. And the final result of black
+
+4
+00:00:09,590 --> 00:00:12,760
+box testing is a set of test cases, a set of actual
+
+5
+00:00:12,760 --> 00:00:16,410
+inputs and corresponding outputs that we can use to exercise our
+
+6
+00:00:16,410 --> 00:00:19,030
+code and to try to find defects in our code. So the
+
+7
+00:00:19,030 --> 00:00:22,060
+question is, how do we get from functional specification to test
+
+8
+00:00:22,060 --> 00:00:25,510
+cases? Doing these derivations, so going from this description to a concrete
+
+9
+00:00:25,510 --> 00:00:28,550
+set of tests, is a very complex analytical process.
+
+10
+00:00:28,550 --> 00:00:31,220
+And normally brute force generation is not a good
+
+11
+00:00:31,220 --> 00:00:34,430
+idea because it's inefficient and ineffective. What we want
+
+12
+00:00:34,430 --> 00:00:37,540
+to do instead is to have a systematic approach to
+
+13
+00:00:37,540 --> 00:00:40,250
+derive test cases from a functional specification. What a
+
+14
+00:00:40,250 --> 00:00:43,970
+systematic approach does is to simplify the overall problem by
+
+15
+00:00:43,970 --> 00:00:48,320
+dividing the process into elementary steps. In particular, in
+
+16
+00:00:48,320 --> 00:00:50,520
+this case, we will perform three main steps. The first
+
+17
+00:00:50,520 --> 00:00:55,790
+step is to identify independently testable features. Individual features in
+
+18
+00:00:55,790 --> 00:00:57,600
+the soft hood that we can test. And we're going to
+
+19
+00:00:57,600 --> 00:00:59,990
+expand on each one of these steps in the next
+
+20
+00:00:59,990 --> 00:01:02,490
+part of the lesson. The following step is once we have
+
+21
+00:01:02,490 --> 00:01:06,000
+these independently testable features to identify what are the relevant
+
+22
+00:01:06,000 --> 00:01:08,590
+inputs. So what are the inputs or the behavior that is
+
+23
+00:01:08,590 --> 00:01:11,610
+worth testing for these features. Next once we have these
+
+24
+00:01:11,610 --> 00:01:13,020
+inputs, we're going to derive test
+
+25
+00:01:13,020 --> 00:01:15,770
+specifications. And test case specifications are
+
+26
+00:01:15,770 --> 00:01:19,490
+description of the test cases that we can then use
+
+27
+00:01:19,490 --> 00:01:23,270
+to generate actual test cases. And proceeding in this way,
+
+28
+00:01:23,270 --> 00:01:26,050
+by this steps, has many advantages. It allows for the
+
+29
+00:01:26,050 --> 00:01:29,920
+coupling different activities. It allows for dividing brain intensive steps from
+
+30
+00:01:29,920 --> 00:01:32,240
+steps that can be automated, which is a great advantage.
+
+31
+00:01:32,240 --> 00:01:34,980
+And also we will see, it allows you for monitoring
+
+32
+00:01:34,980 --> 00:01:38,040
+the testing process. So to figure out whether your testing
+
+33
+00:01:38,040 --> 00:01:41,000
+process is going as expected, for example, if you're generating too
+
+34
+00:01:41,000 --> 00:01:44,160
+many test cases. Or you're generating the number of test cases that your
+
+35
+00:01:44,160 --> 00:01:47,880
+amount of resources available allows you to run. So let's start by looking
+
+36
+00:01:47,880 --> 00:01:51,230
+at the first step of this process in which our goal is to
+
+37
+00:01:51,230 --> 00:01:54,820
+go from a Functional Specification to a set of features that we can
+
+38
+00:01:54,820 --> 00:01:57,700
+test in the software. So what we want to do is to identify all
+
+39
+00:01:57,700 --> 00:02:00,290
+of the feature of the software. And why do we want to do this?
+
+40
+00:02:00,290 --> 00:02:02,650
+Well you know, in the spirit of breaking down the complexity of the
+
+41
+00:02:02,650 --> 00:02:06,170
+problem, it does not make sense to just try to devise test cases for
+
+42
+00:02:06,170 --> 00:02:08,750
+all the features of the software at once. For any non-trivial
+
+43
+00:02:08,750 --> 00:02:11,980
+software, that's a humongous problem, and something that we cannot really
+
+44
+00:02:11,980 --> 00:02:16,300
+handle effectively. A much better way is to identify independently testable
+
+45
+00:02:16,300 --> 00:02:19,100
+features and consider one of them at a time when generating tests.