diff options
Diffstat (limited to 'usth/ICT2.7/P4L1 General Concepts Subtitles')
19 files changed, 0 insertions, 1781 deletions
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/1 - Lesson Overview - lang_en_vs5.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/1 - Lesson Overview - lang_en_vs5.srt deleted file mode 100644 index df7cdbe..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/1 - Lesson Overview - lang_en_vs5.srt +++ /dev/null @@ -1,91 +0,0 @@ -1 -00:00:00,700 --> 00:00:03,682 -Hello, and welcome back. In the previous - -2 -00:00:03,682 --> 00:00:07,160 -mini course we covered software design, discussed the - -3 -00:00:07,160 --> 00:00:10,020 -UML and the unified software process, and worked - -4 -00:00:10,020 --> 00:00:12,160 -on a complex project in which we developed - -5 -00:00:12,160 --> 00:00:16,020 -a distributed software system. In this mini course, - -6 -00:00:16,020 --> 00:00:17,900 -which is the last one for this class, - -7 -00:00:17,900 --> 00:00:21,080 -we will cover my very favorite topic, software - -8 -00:00:21,080 --> 00:00:24,850 -testing or more generally, software verification and validation. - -9 -00:00:25,860 --> 00:00:28,850 -So why do I love software testing? Well, - -10 -00:00:28,850 --> 00:00:32,430 -I love it because it is extremely important. It - -11 -00:00:32,430 --> 00:00:38,330 -is very challenging and it is fun but only if you do it in the right way. - -12 -00:00:38,330 --> 00:00:40,900 -In the upcoming lessons we will discuss why - -13 -00:00:40,900 --> 00:00:44,710 -software verification is important, why software testing, which is - -14 -00:00:44,710 --> 00:00:47,730 -a specific type of verification, is important, and - -15 -00:00:47,730 --> 00:00:50,730 -what are the main techniques for performing software testing. - -16 -00:00:51,910 --> 00:00:54,866 -We will also discuss test-driven development and agile methods, - -17 -00:00:54,866 --> 00:00:57,780 -in which we'll lose some of the rigidity of - -18 -00:00:57,780 --> 00:01:01,340 -the earlier processes and turn things around by writing - -19 -00:01:01,340 --> 00:01:04,260 -tests before we write the code and then writing - -20 -00:01:04,260 --> 00:01:08,280 -code that makes the test pass. Finally, we will - -21 -00:01:08,280 --> 00:01:10,750 -perform a project, in which you get to apply - -22 -00:01:10,750 --> 00:01:14,010 -most of the principles and practices of agile development - -23 -00:01:14,010 --> 00:01:17,430 -in a realistic scenario. So let's jump right in. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/10 - Verification Approaches - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/10 - Verification Approaches - lang_en_vs4.srt deleted file mode 100644 index a671818..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/10 - Verification Approaches - lang_en_vs4.srt +++ /dev/null @@ -1,239 +0,0 @@ -1 -00:00:00,320 --> 00:00:01,630 -Now that we got out of the way this - -2 -00:00:01,630 --> 00:00:04,460 -initial set of basic definitions. Let's go back to our - -3 -00:00:04,460 --> 00:00:08,770 -main concept, which is software verification. We said that software - -4 -00:00:08,770 --> 00:00:11,730 -is buggy, and because software is buggy, we need to - -5 -00:00:11,730 --> 00:00:14,690 -verify the software as much as we can. But how - -6 -00:00:14,690 --> 00:00:17,960 -can we verify software? There are several ways to verify - -7 -00:00:17,960 --> 00:00:21,150 -a software system. Among those, we will discuss four mainstream - -8 -00:00:21,150 --> 00:00:25,410 -approaches. The first one is testing, also called dynamic verification. - -9 -00:00:25,410 --> 00:00:29,400 -The second approach is static verification. The third approach is - -10 -00:00:29,400 --> 00:00:33,000 -inspections. And finally, we're going to consider a fourth approach which is - -11 -00:00:33,000 --> 00:00:36,090 -formal proofs of correctness. So what I'm going to do - -12 -00:00:36,090 --> 00:00:39,570 -next, I'm going to first provide an overview of these approaches and - -13 -00:00:39,570 --> 00:00:41,930 -then discuss some of them in more depth and please - -14 -00:00:41,930 --> 00:00:44,430 -note that although we will discuss all four approaches we will - -15 -00:00:44,430 --> 00:00:47,350 -spend most of our time on software testing. As software - -16 -00:00:47,350 --> 00:00:50,850 -testing is the most popular and most used approach in industry. - -17 -00:00:50,850 --> 00:00:53,050 -So let's start with our overview and in particular - -18 -00:00:53,050 --> 00:00:58,050 -with testing. Testing a software system means exercising the system - -19 -00:00:58,050 --> 00:01:01,680 -to try to make it fail. More precisely, let's consider - -20 -00:01:01,680 --> 00:01:04,440 -a program. Its input domain, which is the set of - -21 -00:01:04,440 --> 00:01:06,990 -all the possible inputs for the program and, its output - -22 -00:01:06,990 --> 00:01:09,470 -domain, which is a set of all the possible corresponding - -23 -00:01:09,470 --> 00:01:13,010 -outputs. Given this context, we can define what a test - -24 -00:01:13,010 --> 00:01:16,360 -case is. A test case is a pair that consists - -25 -00:01:16,360 --> 00:01:19,090 -of a, an input from the input domain D, - -26 -00:01:19,090 --> 00:01:22,620 -and then, expected output O from the output domain. - -27 -00:01:22,620 --> 00:01:25,950 -And O is the element in the output domain - -28 -00:01:25,950 --> 00:01:29,670 -that a correct software would produce when ran against I. - -29 -00:01:29,670 --> 00:01:32,170 -We can also define the concept of test suite, - -30 -00:01:32,170 --> 00:01:34,840 -which is a set of test cases, and we're going to - -31 -00:01:34,840 --> 00:01:37,730 -use these two concepts of test case and test - -32 -00:01:37,730 --> 00:01:41,400 -suite quite a bit in the rest of the lessons. - -33 -00:01:41,400 --> 00:01:44,980 -Subject verification, tries to identify specific classes of problems - -34 -00:01:44,980 --> 00:01:47,620 -in the program. Such as null pointer dereferences. And - -35 -00:01:47,620 --> 00:01:49,750 -unlike testing, what it does is that it does - -36 -00:01:49,750 --> 00:01:53,610 -not just consider individual inputs, it instead considers all - -37 -00:01:53,610 --> 00:01:56,594 -possible inputs for the program. So it consider in - -38 -00:01:56,594 --> 00:01:59,366 -a sense all possible executions of the program and - -39 -00:01:59,366 --> 00:02:02,402 -all possible behaviors of the program, that's why we - -40 -00:02:02,402 --> 00:02:06,560 -save the verification unlike testing it's complete. The 3rd technique - -41 -00:02:06,560 --> 00:02:08,755 -we are going to consider is inspections, - -42 -00:02:08,755 --> 00:02:12,804 -and inspections are also called reviews or walkthroughs. - -43 -00:02:12,804 --> 00:02:15,010 -And unlike the previous techniques, inspections are a - -44 -00:02:15,010 --> 00:02:18,660 -human intensive activity, more precisely, they are a - -45 -00:02:18,660 --> 00:02:22,520 -manual and group activity in which several - -46 -00:02:22,520 --> 00:02:25,700 -people from the organization that developed the software, - -47 -00:02:25,700 --> 00:02:29,190 -look at the code or other artifacts developed - -48 -00:02:29,190 --> 00:02:31,888 -during the software production and try to identify - -49 -00:02:31,888 --> 00:02:35,950 -defects in these artifacts. And interestingly inspections - -50 -00:02:35,950 --> 00:02:37,580 -have been shown to be quite effective in - -51 -00:02:37,580 --> 00:02:39,820 -practice and that's the reason why they're used - -52 -00:02:39,820 --> 00:02:42,550 -quite widely in the industry. Finally, the last - -53 -00:02:42,550 --> 00:02:45,100 -technique I want to mention is Formal - -54 -00:02:45,100 --> 00:02:49,650 -Proof (of correctness). Given a software specification, and - -55 -00:02:49,650 --> 00:02:53,370 -actually a formal specification, so a document that - -56 -00:02:53,370 --> 00:02:57,410 -formally defines and specifies the behavior, the expected - -57 -00:02:57,410 --> 00:03:00,320 -behavior of the program. A form of proof of - -58 -00:03:00,320 --> 00:03:05,400 -correctness proves that the program being verified, actually implements - -59 -00:03:05,400 --> 00:03:07,922 -the program specification and it does that through a - -60 -00:03:07,922 --> 00:03:12,880 -sophisticated mathematical analysis of the specifications and of the code. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/11 - Pros and Cons of Approaches - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/11 - Pros and Cons of Approaches - lang_en_vs4.srt deleted file mode 100644 index 36a58ee..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/11 - Pros and Cons of Approaches - lang_en_vs4.srt +++ /dev/null @@ -1,195 +0,0 @@ -1 -00:00:00,230 --> 00:00:02,870 -The four different techniques that we just discussed have - -2 -00:00:02,870 --> 00:00:06,120 -a number of pros and cons. So next we - -3 -00:00:06,120 --> 00:00:08,780 -are going to discuss the main pros and cons - -4 -00:00:08,780 --> 00:00:11,140 -for these techniques, so as to be able to compare - -5 -00:00:11,140 --> 00:00:14,330 -them. When testing is concerned the main positive about - -6 -00:00:14,330 --> 00:00:17,600 -this technique is that it does not generate false - -7 -00:00:17,600 --> 00:00:21,740 -alarms. In other words, it doesn't generate false positives. - -8 -00:00:21,740 --> 00:00:25,180 -What that means, is that when testing generates a failure, - -9 -00:00:25,180 --> 00:00:27,230 -that means that there is an actual problem in the - -10 -00:00:27,230 --> 00:00:30,060 -code. The main limitation of testing, however, is that it - -11 -00:00:30,060 --> 00:00:33,680 -is highly incomplete. Consider again the picture that we drew - -12 -00:00:33,680 --> 00:00:36,430 -a little earlier. The one representing the input domain of - -13 -00:00:36,430 --> 00:00:39,430 -the program being tested. Even in the best scenario, testing - -14 -00:00:39,430 --> 00:00:44,050 -can consider only a tiny fraction of the problem domain, - -15 -00:00:44,050 --> 00:00:47,430 -and therefor a tiny fraction of the program's behavior, and - -16 -00:00:47,430 --> 00:00:50,308 -we'll say a lot more about that in the following lessons. - -17 -00:00:50,308 --> 00:00:53,780 -Static verification, unlike testing, has the main advantage - -18 -00:00:53,780 --> 00:00:57,320 -that it considers all program behaviors. If we - -19 -00:00:57,320 --> 00:01:00,370 -look back at our diagram, whereas testing will - -20 -00:01:00,370 --> 00:01:04,010 -select only a few of those inputs, static verification - -21 -00:01:04,010 --> 00:01:07,120 -will consider them all. Unfortunately, however, this comes - -22 -00:01:07,120 --> 00:01:08,990 -with a price. Due to limitation of this - -23 -00:01:08,990 --> 00:01:11,490 -kind of analysis and due to infeasibility issues, - -24 -00:01:11,490 --> 00:01:15,260 -static verifiation considers not only all the possible behaviours, - -25 -00:01:15,260 --> 00:01:18,870 -but also some impossible behaviors. And what that means is - -26 -00:01:18,870 --> 00:01:22,472 -that static gratificaition can generate false positives. And this is, - -27 -00:01:22,472 --> 00:01:24,590 -in fact, the main issue with static verification techniques. As - -28 -00:01:24,590 --> 00:01:28,550 -we will further discuss later in the class, static verification can - -29 -00:01:28,550 --> 00:01:31,280 -generate results that are not true. For example, it might - -30 -00:01:31,280 --> 00:01:33,970 -report a possible no point of the refernce that cannot - -31 -00:01:33,970 --> 00:01:37,590 -actually occur in practice. The strongest point about inspections is - -32 -00:01:37,590 --> 00:01:40,950 -that, when they're done in a rigorous way, they're systematic and - -33 -00:01:40,950 --> 00:01:43,420 -they result in a thorough analysis of the code. - -34 -00:01:43,420 --> 00:01:46,840 -They are nevertheless a manual process, a human process. - -35 -00:01:46,840 --> 00:01:49,890 -So they're not formal and their effectiveness may depend - -36 -00:01:49,890 --> 00:01:53,560 -on the specific people performing the inspection. So its results - -37 -00:01:53,560 --> 00:01:57,150 -can be subjective. Finally, the main pro about formal - -38 -00:01:57,150 --> 00:02:01,090 -proofs of correctness is that they provide strong guarantees. - -39 -00:02:01,090 --> 00:02:03,740 -They can guarantee that the program is correct, which - -40 -00:02:03,740 --> 00:02:06,280 -is not something that any of the other approaches can - -41 -00:02:06,280 --> 00:02:09,505 -do, including study verification. But the main limitation of - -42 -00:02:09,505 --> 00:02:12,680 -formal proofs is that they need a form of specification, - -43 -00:02:12,680 --> 00:02:15,750 -a complete mathematical description of the expected behavior of - -44 -00:02:15,750 --> 00:02:19,060 -the whole program, and unfortunately such a specification is rarely - -45 -00:02:19,060 --> 00:02:21,920 -available, and it is very complex to build one. - -46 -00:02:21,920 --> 00:02:25,170 -In addition, it is also very complex, and possibly expensive, - -47 -00:02:25,170 --> 00:02:27,720 -to prove that the program corresponds to a specification. - -48 -00:02:27,720 --> 00:02:30,990 -That is a process that requires strong mathematical skills and, - -49 -00:02:30,990 --> 00:02:32,551 -therefore, a very specialized personnel. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/12 - Verification Approaches Quiz - lang_en_vs5.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/12 - Verification Approaches Quiz - lang_en_vs5.srt deleted file mode 100644 index a5aa4f7..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/12 - Verification Approaches Quiz - lang_en_vs5.srt +++ /dev/null @@ -1,47 +0,0 @@ -1 -00:00:00,240 --> 00:00:02,570 -So let's have another simple quiz, and we're going to - -2 -00:00:02,570 --> 00:00:05,490 -have our developer Brett introducing the quiz. And the - -3 -00:00:05,490 --> 00:00:07,900 -starting point for this quiz is the fact that - -4 -00:00:07,900 --> 00:00:11,970 -today, quality assurance, or verification, if you wish, is mostly - -5 -00:00:11,970 --> 00:00:15,730 -testing. That is, testing is the most commonly used - -6 -00:00:15,730 --> 00:00:19,550 -activity to perform software verification. So now, I'm going to show - -7 -00:00:19,550 --> 00:00:22,310 -you a quote, 50% of my company employees are - -8 -00:00:22,310 --> 00:00:25,691 -testers and the rest spends 50% of their time testing, - -9 -00:00:25,691 --> 00:00:27,347 -so I want to ask you, who said - -10 -00:00:27,347 --> 00:00:29,664 -that? I'm going to give you some possibilities. Was - -11 -00:00:29,664 --> 00:00:34,215 -that Yogi Berra, Steve Jobs, Henry Ford, Bill - -12 -00:00:34,215 --> 00:00:37,360 -Gates or Frank Gehry? Take your best guess. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/13 - Verification Approaches Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/13 - Verification Approaches Quiz Solution - lang_en_vs4.srt deleted file mode 100644 index b8a0076..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/13 - Verification Approaches Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,11 +0,0 @@ -1 -00:00:00,260 --> 00:00:04,090 -And the correct answer is Bill Gates. So this gives you an idea of how - -2 -00:00:04,090 --> 00:00:07,070 -important testing is in Microsoft in particular, - -3 -00:00:07,070 --> 00:00:09,350 -but in many other software companies in general. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/14 - Testing Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/14 - Testing Introduction - lang_en_vs4.srt deleted file mode 100644 index 70df565..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/14 - Testing Introduction - lang_en_vs4.srt +++ /dev/null @@ -1,119 +0,0 @@ -1 -00:00:00,340 --> 00:00:02,290 -So let's talk more about testing, as we said a - -2 -00:00:02,290 --> 00:00:06,500 -little earlier in the lesson, testing means executing the program on - -3 -00:00:06,500 --> 00:00:09,400 -a sample of the input domain, that is of all - -4 -00:00:09,400 --> 00:00:12,210 -the possible input data and I really want to stress that - -5 -00:00:12,210 --> 00:00:16,190 -this sample is tiny sample of the input domain. There - -6 -00:00:16,190 --> 00:00:19,154 -are two important aspects of testing that I'm want to mention here, - -7 -00:00:19,154 --> 00:00:22,360 -there first one is that testing is a dynamic technique. And - -8 -00:00:22,360 --> 00:00:25,370 -what that means is that the program must be executed in - -9 -00:00:25,370 --> 00:00:28,130 -order to perform testing. The second important point is that - -10 -00:00:28,130 --> 00:00:32,040 -testing is an optimistic approximation. And what does it mean - -11 -00:00:32,040 --> 00:00:35,590 -to be optimistic? Well, it means that the program under - -12 -00:00:35,590 --> 00:00:38,820 -test is exercised with a very small subset of all the - -13 -00:00:38,820 --> 00:00:41,260 -possible inputs as we just said. And this is done - -14 -00:00:41,260 --> 00:00:45,150 -under the assumption that the behavior with any other input - -15 -00:00:45,150 --> 00:00:47,770 -is consistent with the behavior shown for the selected subset - -16 -00:00:47,770 --> 00:00:51,140 -of input data, that is why it is an optimistic approach. - -17 -00:00:51,140 --> 00:00:54,620 -Another concept that I want to mention explicitly, is the - -18 -00:00:54,620 --> 00:00:57,930 -concept of successful test. And I'm going to do that, - -19 -00:00:57,930 --> 00:01:01,260 -using another quote. This one from Goodenough and Gerhart - -20 -00:01:01,260 --> 00:01:03,850 -in their paper Towards a Theory of Test Data Selection, - -21 -00:01:03,850 --> 00:01:06,420 -and what the quote says is that a test - -22 -00:01:06,420 --> 00:01:10,000 -is successful if the program fails. And this might sound - -23 -00:01:10,000 --> 00:01:13,650 -counterintuitive, but the point here is that testing cannot - -24 -00:01:13,650 --> 00:01:16,490 -prove the absence of errors, but only reveal their presence. - -25 -00:01:16,490 --> 00:01:21,550 -If a set of tests does not produce any failure, we are either in the extremely - -26 -00:01:21,550 --> 00:01:24,050 -unlikely case of a correct program, or in - -27 -00:01:24,050 --> 00:01:26,650 -the very likely situation of a bad set of - -28 -00:01:26,650 --> 00:01:30,932 -tests that are not able to reveal failures of the program. And that is why we - -29 -00:01:30,932 --> 00:01:32,730 -say that the test is successful if you - -30 -00:01:32,730 --> 00:01:35,110 -can show that there are problems in the program. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/15 - Testing Granularity Levels - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/15 - Testing Granularity Levels - lang_en_vs4.srt deleted file mode 100644 index 83df7ea..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/15 - Testing Granularity Levels - lang_en_vs4.srt +++ /dev/null @@ -1,275 +0,0 @@ -1 -00:00:00,160 --> 00:00:03,050 -And before I start talking about specific testing techniques, there's - -2 -00:00:03,050 --> 00:00:05,490 -something else that I want to discuss, which is Testing - -3 -00:00:05,490 --> 00:00:09,090 -Granularity Levels. So let's consider a software system, a system - -4 -00:00:09,090 --> 00:00:12,310 -made out of components that interact with one another. So the - -5 -00:00:12,310 --> 00:00:15,000 -first level that we consider in testing is called Unit - -6 -00:00:15,000 --> 00:00:18,490 -Testing, which is the testing of the individual units or modules - -7 -00:00:18,490 --> 00:00:20,690 -in isolation. The next step, is to see there are - -8 -00:00:20,690 --> 00:00:25,340 -multiple modules and their interactions. And this is called Integration Testing. - -9 -00:00:25,340 --> 00:00:28,650 -So, integration testing is the testing of the interactions among - -10 -00:00:28,650 --> 00:00:31,460 -different modules. And it can be performed according to different - -11 -00:00:31,460 --> 00:00:34,260 -strategies. Depending on the order in which the modules are - -12 -00:00:34,260 --> 00:00:37,570 -integrated and on whether we integrate one module at a time - -13 -00:00:37,570 --> 00:00:40,510 -or multiple modules together, all at once. And in this - -14 -00:00:40,510 --> 00:00:43,240 -latter case, we call this kind of integration testing, the one that - -15 -00:00:43,240 --> 00:00:47,640 -integrates all the modules at once, Big Bang integration testing. - -16 -00:00:47,640 --> 00:00:50,520 -And after performing integration testing, the next step is to test - -17 -00:00:50,520 --> 00:00:52,750 -the complete system as a whole. And this level of - -18 -00:00:52,750 --> 00:00:56,190 -testing is normally called, System Testing. So system testing in the - -19 -00:00:56,190 --> 00:00:59,560 -testing of the complete system and it includes both functional and - -20 -00:00:59,560 --> 00:01:03,250 -non functional testing. We will discuss functional and non functional testing - -21 -00:01:03,250 --> 00:01:05,575 -in details in the next two lessons. But I just - -22 -00:01:05,575 --> 00:01:08,330 -want to give you an idea of what they are intuitively. Functional - -23 -00:01:08,330 --> 00:01:12,250 -tests are the test that aim to verify the functionality provided - -24 -00:01:12,250 --> 00:01:15,680 -by the system. For example if you consider the function double - -25 -00:01:15,680 --> 00:01:17,840 -value that we saw earlier in the lesson, a - -26 -00:01:17,840 --> 00:01:20,660 -functional test will try to assess that that function - -27 -00:01:20,660 --> 00:01:23,970 -is producing the right value given a specific input. - -28 -00:01:23,970 --> 00:01:26,826 -Conversely, no functional test are the one that target, as - -29 -00:01:26,826 --> 00:01:30,540 -surprisingly, no functional properties of the system. For example, - -30 -00:01:30,540 --> 00:01:34,060 -no functional test will include performance tests, load tests, - -31 -00:01:34,060 --> 00:01:37,310 -robustness tests. In general, no functional tests will try - -32 -00:01:37,310 --> 00:01:41,410 -to assess different qualities of the system, such as reliability, - -33 -00:01:41,410 --> 00:01:45,970 -maintainability, usability, so basically, all the ilities that you can - -34 -00:01:45,970 --> 00:01:49,760 -think about. In addition to these three basic testing levels, there - -35 -00:01:49,760 --> 00:01:51,830 -are two more levels that I want to consider and that - -36 -00:01:51,830 --> 00:01:55,150 -I want to discuss. And they both involve the whole system. - -37 -00:01:55,150 --> 00:01:57,610 -And the first one is Acceptance Testing which is the - -38 -00:01:57,610 --> 00:02:01,320 -validation of the software against the Customer requirements. So this is - -39 -00:02:01,320 --> 00:02:04,090 -the testing that makes sure that the system does what the - -40 -00:02:04,090 --> 00:02:06,720 -customer wants it to do. And the last type of testing - -41 -00:02:06,720 --> 00:02:09,729 -that I want to mention is Regression Testing. And regression testing - -42 -00:02:09,729 --> 00:02:13,260 -is the type of testing or retesting, that we perform every time - -43 -00:02:13,260 --> 00:02:15,540 -that we change our system. And we need to make sure - -44 -00:02:15,540 --> 00:02:19,060 -that the changes behave as intended and that the unchanged code is - -45 -00:02:19,060 --> 00:02:22,680 -not negatively affected by the modification, by these changes. In fact, - -46 -00:02:22,680 --> 00:02:25,070 -what can happen when you modify the code is that parts of - -47 -00:02:25,070 --> 00:02:28,120 -the code that are related to the changes, are actually affected - -48 -00:02:28,120 --> 00:02:32,110 -by the changes, and start misbehaving. And we call those regression errors. - -49 -00:02:32,110 --> 00:02:35,080 -And regression errors, are very common. For example, you're probably - -50 -00:02:35,080 --> 00:02:38,070 -familiar with the situation in which, one software update is - -51 -00:02:38,070 --> 00:02:41,350 -released, and just a few days later, another software update - -52 -00:02:41,350 --> 00:02:44,640 -is released. In many cases that happens because the first update - -53 -00:02:44,640 --> 00:02:47,760 -was containing regression errors. So the changes in the code - -54 -00:02:47,760 --> 00:02:51,100 -that broke some functionality, that resulted in failures on the user's - -55 -00:02:51,100 --> 00:02:53,940 -machine and in bug reports and therefore that caused further - -56 -00:02:53,940 --> 00:02:57,090 -maintenance, further bug fixes, and a release on a new version. - -57 -00:02:57,090 --> 00:02:59,790 -Something else I'd like to mention about regression testing, is that - -58 -00:02:59,790 --> 00:03:02,535 -regression testing is one of the main causes why software maintenance is - -59 -00:03:02,535 --> 00:03:05,679 -so expensive. And that's also why researchers have invested a great - -60 -00:03:05,679 --> 00:03:07,481 -deal of effort into refining regression - -61 -00:03:07,481 --> 00:03:09,495 -testing techniques that can make regression - -62 -00:03:09,495 --> 00:03:12,599 -testing more effective and more efficient. So let me leave you, - -63 -00:03:12,599 --> 00:03:15,129 -with a little piece of advice which is try to automate as - -64 -00:03:15,129 --> 00:03:19,470 -much as possible regression testing. For example use scripts, use tools, make - -65 -00:03:19,470 --> 00:03:22,660 -sure to save your harness, make sure to save your input, and - -66 -00:03:22,660 --> 00:03:24,820 -outputs for the test, because you want to be able - -67 -00:03:24,820 --> 00:03:27,680 -to rerun your test, at a push of a button as - -68 -00:03:27,680 --> 00:03:29,750 -much as possible every time you change your code, to - -69 -00:03:29,750 --> 00:03:32,560 -avoid the presence of regression errors in the code you release. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/16 - Alpha and Beta Testing - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/16 - Alpha and Beta Testing - lang_en_vs4.srt deleted file mode 100644 index f81f551..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/16 - Alpha and Beta Testing - lang_en_vs4.srt +++ /dev/null @@ -1,95 +0,0 @@ -1 -00:00:00,510 --> 00:00:02,754 -All the testing levels that we've seen so far is what - -2 -00:00:02,754 --> 00:00:06,058 -we can call developer's testing. So that's testing that is performed - -3 -00:00:06,058 --> 00:00:09,649 -either within the testing organization, or by somebody who's doing like - -4 -00:00:09,649 --> 00:00:13,520 -third-party testers on behalf of the testing organization. But there are two - -5 -00:00:13,520 --> 00:00:16,280 -other kinds of testing that are worth mentioning that are also - -6 -00:00:16,280 --> 00:00:19,600 -related to testing phases and these are alpha and beta testing. - -7 -00:00:19,600 --> 00:00:23,050 -Alpha testing is the testing performed by distributing a software system - -8 -00:00:23,050 --> 00:00:26,000 -ready to be released to a set of users that are internal - -9 -00:00:26,000 --> 00:00:29,480 -to the organization that developed the software. So you can consider these - -10 -00:00:29,480 --> 00:00:32,460 -users as, if you pass me the term, guinea pigs that will - -11 -00:00:32,460 --> 00:00:35,170 -use an early version of the code and will likely discover errors - -12 -00:00:35,170 --> 00:00:37,850 -that escaped testing and will have made it to the field if - -13 -00:00:37,850 --> 00:00:41,390 -not caught. Beta testing is the next step after alpha testing, in - -14 -00:00:41,390 --> 00:00:44,530 -which the software is released to a selected subset of users, in - -15 -00:00:44,530 --> 00:00:47,770 -this case, outside your organization. And also in this case, the users - -16 -00:00:47,770 --> 00:00:51,110 -are likely to discover latent errors in the code before it is officially - -17 -00:00:51,110 --> 00:00:54,240 -released to the broader user population, so before we have an - -18 -00:00:54,240 --> 00:00:56,850 -actual product release. So you may wonder why do we need - -19 -00:00:56,850 --> 00:00:59,360 -to do both alpha and beta testing. Why not just one - -20 -00:00:59,360 --> 00:01:02,980 -of the two? The reason is that alpha testing is performed - -21 -00:01:02,980 --> 00:01:06,730 -to iron out the very obvious issues that still escape testing, - -22 -00:01:06,730 --> 00:01:09,610 -but we want to do that before involving people outside your - -23 -00:01:09,610 --> 00:01:12,730 -organization. And the rationale is that alpha testers have a higher - -24 -00:01:12,730 --> 00:01:16,710 -tolerance for problems than beta testers, who expect a mostly working system. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/17 - Black and White Box Testing Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/17 - Black and White Box Testing Introduction - lang_en_vs4.srt deleted file mode 100644 index c61e331..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/17 - Black and White Box Testing Introduction - lang_en_vs4.srt +++ /dev/null @@ -1,115 +0,0 @@ -1 -00:00:00,370 --> 00:00:02,520 -We're almost at the end of this lesson. In the - -2 -00:00:02,520 --> 00:00:05,520 -next two lessons we're going to talk about two main families - -3 -00:00:05,520 --> 00:00:07,800 -of testing techniques, black-box testing - -4 -00:00:07,800 --> 00:00:10,340 -techniques, and white-box testing techniques. So, - -5 -00:00:10,340 --> 00:00:12,730 -what I want to do before getting into the discussion of the - -6 -00:00:12,730 --> 00:00:15,385 -specific techniques in this families. I want to give you an - -7 -00:00:15,385 --> 00:00:19,440 -overview of what black-box testing and white-box testing are. Black box - -8 -00:00:19,440 --> 00:00:21,950 -testing is the kind of testing in which we consider the - -9 -00:00:21,950 --> 00:00:25,570 -software as a closed box. That's why it's called black box. - -10 -00:00:25,570 --> 00:00:27,770 -So we don't look inside the software, we don't want to - -11 -00:00:27,770 --> 00:00:30,131 -look at the code. We just going to look at the description - -12 -00:00:30,131 --> 00:00:33,210 -of the software. So this is the testing that is based - -13 -00:00:33,210 --> 00:00:36,100 -on a description of the software, which is what we normally - -14 -00:00:36,100 --> 00:00:39,690 -call the specification for the software. And what black box testing - -15 -00:00:39,690 --> 00:00:44,040 -tries to do is to cover as much specified behavior as - -16 -00:00:44,040 --> 00:00:47,290 -possible, and the main limitation black box testing and the reason - -17 -00:00:47,290 --> 00:00:51,540 -why this is complimentary to white-box testing is that it cannot reveal - -18 -00:00:51,540 --> 00:00:56,590 -errors due to implementation details. Conversely, white-box testing - -19 -00:00:56,590 --> 00:00:58,430 -is the kind of testing that looks inside the - -20 -00:00:58,430 --> 00:01:00,360 -box. So looks at the code and how - -21 -00:01:00,360 --> 00:01:02,760 -the code is written and uses this information to - -22 -00:01:02,760 --> 00:01:06,300 -perform the testing. So white-box testing is based - -23 -00:01:06,300 --> 00:01:09,120 -on the code, its goal is to cover as - -24 -00:01:09,120 --> 00:01:13,210 -much coded behavior in this case, as possible, and - -25 -00:01:13,210 --> 00:01:17,100 -its limitation is that unlike black-box testing, it can't - -26 -00:01:17,100 --> 00:01:21,880 -reveal errors due to missing paths. Where missing paths are - -27 -00:01:21,880 --> 00:01:25,250 -a part of a software specification that are not implemented and - -28 -00:01:25,250 --> 00:01:27,320 -the reason why you can not reveal them is because - -29 -00:01:27,320 --> 00:01:29,790 -it is focused on the code and not on the specification. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt deleted file mode 100644 index dab72eb..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt +++ /dev/null @@ -1,135 +0,0 @@ -1 -00:00:00,500 --> 00:00:03,185 -To give you a slightly better understanding of the differences - -2 -00:00:03,185 --> 00:00:06,300 -between black-box testing and white-box testing, I am going to provide you - -3 -00:00:06,300 --> 00:00:10,040 -a couple of simple examples that illustrate the, the strengths and - -4 -00:00:10,040 --> 00:00:12,920 -limitations of these two techniques. So, in this case, let's start - -5 -00:00:12,920 --> 00:00:15,750 -with black-box testing, so we're only working with this specification. - -6 -00:00:15,750 --> 00:00:18,540 -So, let's say that our specification says that this is a - -7 -00:00:18,540 --> 00:00:23,550 -program that inputs an integer value and prints it. And implementation, - -8 -00:00:23,550 --> 00:00:25,900 -we don't know because we're working at the black box level. - -9 -00:00:25,900 --> 00:00:28,710 -If we wanted to test this function according to its - -10 -00:00:28,710 --> 00:00:32,060 -specification, what we will probably do is to select a positive - -11 -00:00:32,060 --> 00:00:35,370 -integer, a negative integer, and the zero as test inputs - -12 -00:00:35,370 --> 00:00:37,840 -and see how the program behaves for these inputs. So let - -13 -00:00:37,840 --> 00:00:41,500 -me now show you a possible implementation for this specification. - -14 -00:00:41,500 --> 00:00:44,590 -What I'm showing here is this function that we called print - -15 -00:00:44,590 --> 00:00:48,010 -NumBytes, which takes the parameter and prints it. And one thing - -16 -00:00:48,010 --> 00:00:50,905 -that we notice right away is that, although in the specification, - -17 -00:00:50,905 --> 00:00:53,960 -numbers that are less than 1024 and numbers that - -18 -00:00:53,960 --> 00:00:57,320 -are greater or equal to 1024 are exactly equivalent from - -19 -00:00:57,320 --> 00:01:01,020 -the specification standpoint. They're however treated differently in the - -20 -00:01:01,020 --> 00:01:04,140 -code, so the developer decided that the program was just - -21 -00:01:04,140 --> 00:01:06,200 -going to print the value of the parameter if it's - -22 -00:01:06,200 --> 00:01:09,300 -less than 1024. But it was actually divided by 1024 - -23 -00:01:09,300 --> 00:01:13,560 -and printing it with a kilobyte mark after it - -24 -00:01:13,560 --> 00:01:16,170 -if you are greater than 1024. And notice that here, - -25 -00:01:16,170 --> 00:01:19,370 -there is a problem. The developer, just a number 124, instead - -26 -00:01:19,370 --> 00:01:22,840 -of 1024. So there's probably a typo in this point in the - -27 -00:01:22,840 --> 00:01:26,260 -code. So this is a case in which by simply doing black-box - -28 -00:01:26,260 --> 00:01:28,750 -testing, so by simply looking at the specific issue, we might miss - -29 -00:01:28,750 --> 00:01:31,510 -this problem. Because we have no reason to consider numbers that are - -30 -00:01:31,510 --> 00:01:34,780 -less than 1024 or greater than 1024. However if we were to - -31 -00:01:34,780 --> 00:01:38,010 -look at the code, so operating at white-box manner, we will right - -32 -00:01:38,010 --> 00:01:41,340 -away see that we need to have a test case that checks - -33 -00:01:41,340 --> 00:01:44,880 -the program when the parameter is greater than 1024. And we will find - -34 -00:01:44,880 --> 00:01:47,300 -the problem right away. So now let me show you a dual example. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/19 - White Box Testing Example - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/19 - White Box Testing Example - lang_en_vs4.srt deleted file mode 100644 index 896f9b1..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/19 - White Box Testing Example - lang_en_vs4.srt +++ /dev/null @@ -1,143 +0,0 @@ -1 -00:00:00,080 --> 00:00:03,086 -In this case we focus on white box testing. So consider now this - -2 -00:00:03,086 --> 00:00:06,556 -other function, called fun. And let's assume that we want to test this function - -3 -00:00:06,556 --> 00:00:09,777 -without having a specification. So without knowing exactly what it needs to do. - -4 -00:00:09,777 --> 00:00:12,996 -But just by looking at the code. So we will try to do the - -5 -00:00:12,996 --> 00:00:16,030 -problem in this case is to try to just execute all the statements. - -6 -00:00:16,030 --> 00:00:18,995 -In the function. And notice I will talk extensively of what does it - -7 -00:00:18,995 --> 00:00:22,560 -means to do white box testing later on in the next, two classes. - -8 -00:00:22,560 --> 00:00:25,560 -So if that's our goal, if our goal is to cover all the statements, - -9 -00:00:25,560 --> 00:00:27,670 -any input will really do. So any test case - -10 -00:00:27,670 --> 00:00:30,250 -will excecute all statements in the code. And we'll a - -11 -00:00:30,250 --> 00:00:33,801 -complete, you know, white-box testing coverage for the program. - -12 -00:00:33,801 --> 00:00:35,865 -Imagine that I now give you a specification for this - -13 -00:00:35,865 --> 00:00:39,071 -function. And what the specification says is that this - -14 -00:00:39,071 --> 00:00:43,232 -function inputs an integer parameter, param, and returns half of - -15 -00:00:43,232 --> 00:00:45,860 -its value, if param is even, and its value - -16 -00:00:45,860 --> 00:00:50,740 -unchanged otherwise. That means if param is odd. So looking - -17 -00:00:50,740 --> 00:00:54,320 -at this specification, we can clearly see that the function fun - -18 -00:00:54,320 --> 00:00:57,740 -works correctly only for even integers, and it doesn't work for - -19 -00:00:57,740 --> 00:01:00,570 -odd integers. Because it computes. Half of the value of the - -20 -00:01:00,570 --> 00:01:04,410 -parameter and returns it every time, no matter what param is. So - -21 -00:01:04,410 --> 00:01:07,320 -this is a case in which white box testing could easily - -22 -00:01:07,320 --> 00:01:10,620 -miss the problem, because as we said any input will exercise - -23 -00:01:10,620 --> 00:01:12,900 -the code. It's just by chance that we could reveal one - -24 -00:01:12,900 --> 00:01:15,750 -that revealed the problem in the code. Conversely if we were to - -25 -00:01:15,750 --> 00:01:19,520 -work, in a black box manner. Typically looking at the specification, we - -26 -00:01:19,520 --> 00:01:22,390 -will select at least one odd, and one even input number to - -27 -00:01:22,390 --> 00:01:25,010 -exercise all of the specified behavior. And we will find the problem - -28 -00:01:25,010 --> 00:01:28,110 -right away. So these two examples are just very small examples, and - -29 -00:01:28,110 --> 00:01:30,910 -they're kind of, you know, stretched. But these kind of issues occur - -30 -00:01:30,910 --> 00:01:33,680 -on a much bigger scale and in much more subtle ways in - -31 -00:01:33,680 --> 00:01:36,970 -real world software. And so what this examples do is to show - -32 -00:01:36,970 --> 00:01:41,270 -you, how black box and white box tests are really complimentary techniques. - -33 -00:01:41,270 --> 00:01:43,130 -So in the next two lessions we will explore - -34 -00:01:43,130 --> 00:01:45,130 -these two types of techniques in detail. We will - -35 -00:01:45,130 --> 00:01:48,020 -see different kinds of white box and black box - -36 -00:01:48,020 --> 00:01:50,670 -testing. And we'll talk about their strengths and the mutations diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/2 - Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/2 - Introduction - lang_en_vs4.srt deleted file mode 100644 index 1a25089..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/2 - Introduction - lang_en_vs4.srt +++ /dev/null @@ -1,103 +0,0 @@ -1 -00:00:00,280 --> 00:00:02,750 -So let me start with some examples that motivate the - -2 -00:00:02,750 --> 00:00:06,330 -need for very fine software. The first example I want to - -3 -00:00:06,330 --> 00:00:09,580 -use is the famous Arian five. And if you remember - -4 -00:00:09,580 --> 00:00:13,060 -that's a rocket that exploded not too long after departure. - -5 -00:00:13,060 --> 00:00:15,800 -Because of a software error. And even without going to - -6 -00:00:15,800 --> 00:00:19,400 -such dramatic examples. I'm sure you're all familiar with this - -7 -00:00:19,400 --> 00:00:22,470 -kind of situation. Or this one, or again in this - -8 -00:00:22,470 --> 00:00:26,070 -one. And here I'm not really picking on any specific organization, - -9 -00:00:26,070 --> 00:00:32,280 -operating system or software. The point I want to make is that software is - -10 -00:00:32,280 --> 00:00:34,730 -buggy. In fact, a federal report from - -11 -00:00:34,730 --> 00:00:37,810 -a few years ago assessed that software bugs - -12 -00:00:37,810 --> 00:00:41,300 -are costing the US economy, $60 billion - -13 -00:00:41,300 --> 00:00:44,120 -every year. In addition, studies have shown that - -14 -00:00:44,120 --> 00:00:47,810 -software contains on average one to five - -15 -00:00:47,810 --> 00:00:51,472 -bugs every 1000 lines of code. Building 100% - -16 -00:00:51,472 --> 00:00:55,940 -correct mass-market software is just impossible. And if - -17 -00:00:55,940 --> 00:00:58,270 -this is the case, what can we do? - -18 -00:00:58,270 --> 00:01:03,520 -What we need to do is to verify software as much as possible. In this part of - -19 -00:01:03,520 --> 00:01:05,750 -the course, we will discuss how we can - -20 -00:01:05,750 --> 00:01:09,480 -do this. We will discuss different alternative ways - -21 -00:01:09,480 --> 00:01:13,980 -of very fine software systems. With particular attention - -22 -00:01:13,980 --> 00:01:16,570 -to the most common type of verification. Which is - -23 -00:01:16,570 --> 00:01:19,470 -software testing. Before doing that however, let - -24 -00:01:19,470 --> 00:01:21,090 -me go over some basic terms that are - -25 -00:01:21,090 --> 00:01:23,190 -commonly used. And I have to say, - -26 -00:01:23,190 --> 00:01:26,330 -often misused in the context of software verification. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/3 - Failure, Fault, and Error - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/3 - Failure, Fault, and Error - lang_en_vs4.srt deleted file mode 100644 index e6459c0..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/3 - Failure, Fault, and Error - lang_en_vs4.srt +++ /dev/null @@ -1,79 +0,0 @@ -1 -00:00:00,390 --> 00:00:03,460 -The first term I want to define, is failure. - -2 -00:00:03,460 --> 00:00:09,080 -A failure is an observable incorrect behavior of the software. - -3 -00:00:09,080 --> 00:00:10,910 -It is conceptually related to the behavior of the - -4 -00:00:10,910 --> 00:00:13,910 -program, rather than its code. The second term I want - -5 -00:00:13,910 --> 00:00:17,600 -to introduce is fault, which is also called bug. - -6 -00:00:17,600 --> 00:00:20,540 -And the fault or bug, is an incorrect piece of - -7 -00:00:20,540 --> 00:00:22,780 -code. In other words, a fault is related to - -8 -00:00:22,780 --> 00:00:25,900 -the code. And is a necessary, but not sufficient condition - -9 -00:00:25,900 --> 00:00:28,160 -for the occurrence of a failure. The final - -10 -00:00:28,160 --> 00:00:30,880 -term I want to introduce is, error. Where an - -11 -00:00:30,880 --> 00:00:33,630 -error is the cause of a fault. It is - -12 -00:00:33,630 --> 00:00:36,990 -usually a human error, which can be conceptual. A - -13 -00:00:36,990 --> 00:00:39,620 -typo or something along those lines. And know that - -14 -00:00:39,620 --> 00:00:43,422 -this terminology, failure, fault and error, is the official - -15 -00:00:43,422 --> 00:00:46,945 -[UNKNOWN] terminology. So you cannot go wrong if you - -16 -00:00:46,945 --> 00:00:51,282 -use it. Now, let me illustrate the difference between - -17 -00:00:51,282 --> 00:00:57,153 -failure, fault and error. Using a small example. What I'm showing here is - -18 -00:00:57,153 --> 00:01:00,876 -a small function that, as you can see from its name, takes an - -19 -00:01:00,876 --> 00:01:04,920 -integer parameter i. And is supposed to double the value of i, and - -20 -00:01:04,920 --> 00:01:08,420 -return it. As we can clearly see, this is not what the function does. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/4 - Failure, Fault, and Error Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/4 - Failure, Fault, and Error Quiz - lang_en_vs4.srt deleted file mode 100644 index 03f6a6a..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/4 - Failure, Fault, and Error Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,15 +0,0 @@ -1 -00:00:00,120 --> 00:00:02,900 -So now I have a few questions for you. And so we use, as - -2 -00:00:02,900 --> 00:00:07,350 -usual, our developer Janet to introduce a quiz. And the first question I want to - -3 -00:00:07,350 --> 00:00:11,710 -ask you is the following. A call to double passing three as a parameter returns - -4 -00:00:11,710 --> 00:00:16,149 -the value nine. What is this? Is that a failure, a fault, or an error? diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/5 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/5 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt deleted file mode 100644 index 1bcde7f..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/5 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,15 +0,0 @@ -1 -00:00:00,440 --> 00:00:06,614 -The fact that the call to double three returns nine instead of six is clearly - -2 -00:00:06,614 --> 00:00:13,000 -a failure because it is an observable incorrect behavior of the program. - -3 -00:00:13,000 --> 00:00:16,110 -So let me remind you that the failure is conceptually related to the - -4 -00:00:16,110 --> 00:00:20,076 -behavior of the program, to the way the program acts and not its code. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/6 - Failure, Fault, and Error Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/6 - Failure, Fault, and Error Quiz - lang_en_vs4.srt deleted file mode 100644 index f51ac9f..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/6 - Failure, Fault, and Error Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,19 +0,0 @@ -1 -00:00:00,310 --> 00:00:02,690 -So now, let me ask you a second question. We just saw that we - -2 -00:00:02,690 --> 00:00:04,640 -can, reveal a failure in the program - -3 -00:00:04,640 --> 00:00:06,640 -by calling double with parameter three. Where - -4 -00:00:06,640 --> 00:00:09,750 -is the fault that causes such failure in the program? So I want you - -5 -00:00:09,750 --> 00:00:12,900 -to write the number of the line of code that, that contains the fault. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/7 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/7 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt deleted file mode 100644 index bc55603..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/7 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,31 +0,0 @@ -1 -00:00:00,190 --> 00:00:02,404 -Before telling you what the right answer is, let - -2 -00:00:02,404 --> 00:00:04,240 -me remind you that the fault is related to - -3 -00:00:04,240 --> 00:00:06,508 -the code, and is a necessary, but not sufficient - -4 -00:00:06,508 --> 00:00:09,560 -condition for the occurrence of a failure. So in this - -5 -00:00:09,560 --> 00:00:12,450 -case, a single faulty line is responsible for the - -6 -00:00:12,450 --> 00:00:17,435 -failure, which is line three. So the correct answer, is - -7 -00:00:17,435 --> 00:00:20,700 -three. At line three, the program computes i times - -8 -00:00:20,700 --> 00:00:23,080 -i, instead of i times 2, as it should do. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/8 - Failure, Fault, and Error Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/8 - Failure, Fault, and Error Quiz - lang_en_vs4.srt deleted file mode 100644 index 18515a6..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/8 - Failure, Fault, and Error Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,15 +0,0 @@ -1 -00:00:00,370 --> 00:00:02,090 -So, I want to ask you one last question about - -2 -00:00:02,090 --> 00:00:05,480 -this problem. What is the error that cause the fault - -3 -00:00:05,480 --> 00:00:08,180 -at line three? Remember that an error is the - -4 -00:00:08,180 --> 00:00:11,010 -cause of a fault and it's usually a human error. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/9 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/9 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt deleted file mode 100644 index 56db4c1..0000000 --- a/usth/ICT2.7/P4L1 General Concepts Subtitles/9 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,39 +0,0 @@ -1 -00:00:00,350 --> 00:00:02,740 -And I apologize, but this was a tricky question that - -2 -00:00:02,740 --> 00:00:06,770 -we cannot really answer. We really have no way to - -3 -00:00:06,770 --> 00:00:08,860 -know what the error was. It could have been a - -4 -00:00:08,860 --> 00:00:13,240 -typo, an erroneous copy and paste operation, or even worse - -5 -00:00:13,240 --> 00:00:16,079 -a conceptual error. In case a developer did not know - -6 -00:00:16,079 --> 00:00:19,910 -what it means to double a number. Unfortunately though, the - -7 -00:00:19,910 --> 00:00:22,200 -developer is the only one who could actually answer this - -8 -00:00:22,200 --> 00:00:25,610 -question. So even though we cannot really answer this question, - -9 -00:00:25,610 --> 00:00:28,000 -having it help us think about how the - -10 -00:00:28,000 --> 00:00:31,000 -error is in fact related to human behavior. |