diff options
Diffstat (limited to 'usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt')
-rw-r--r-- | usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt | 179 |
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. |