1 files changed, 0 insertions, 179 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
deleted file mode 100644
index 75da7e8..0000000
--- a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt
+++ /dev/null
@@ -1,179 +0,0 @@
-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.