diff options
Diffstat (limited to 'usth/ICT2.7/P4L1 General Concepts Subtitles')
19 files changed, 1781 insertions, 0 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 new file mode 100644 index 0000000..df7cdbe --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/1 - Lesson Overview - lang_en_vs5.srt @@ -0,0 +1,91 @@ +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 new file mode 100644 index 0000000..a671818 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/10 - Verification Approaches - lang_en_vs4.srt @@ -0,0 +1,239 @@ +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 new file mode 100644 index 0000000..36a58ee --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/11 - Pros and Cons of Approaches - lang_en_vs4.srt @@ -0,0 +1,195 @@ +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 new file mode 100644 index 0000000..a5aa4f7 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/12 - Verification Approaches Quiz - lang_en_vs5.srt @@ -0,0 +1,47 @@ +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 new file mode 100644 index 0000000..b8a0076 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/13 - Verification Approaches Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,11 @@ +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 new file mode 100644 index 0000000..70df565 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/14 - Testing Introduction - lang_en_vs4.srt @@ -0,0 +1,119 @@ +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 new file mode 100644 index 0000000..83df7ea --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/15 - Testing Granularity Levels - lang_en_vs4.srt @@ -0,0 +1,275 @@ +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 new file mode 100644 index 0000000..f81f551 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/16 - Alpha and Beta Testing - lang_en_vs4.srt @@ -0,0 +1,95 @@ +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 new file mode 100644 index 0000000..c61e331 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/17 - Black and White Box Testing Introduction - lang_en_vs4.srt @@ -0,0 +1,115 @@ +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 new file mode 100644 index 0000000..dab72eb --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt @@ -0,0 +1,135 @@ +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 new file mode 100644 index 0000000..896f9b1 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/19 - White Box Testing Example - lang_en_vs4.srt @@ -0,0 +1,143 @@ +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 new file mode 100644 index 0000000..1a25089 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/2 - Introduction - lang_en_vs4.srt @@ -0,0 +1,103 @@ +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 new file mode 100644 index 0000000..e6459c0 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/3 - Failure, Fault, and Error - lang_en_vs4.srt @@ -0,0 +1,79 @@ +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 new file mode 100644 index 0000000..03f6a6a --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/4 - Failure, Fault, and Error Quiz - lang_en_vs4.srt @@ -0,0 +1,15 @@ +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 new file mode 100644 index 0000000..1bcde7f --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/5 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,15 @@ +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 new file mode 100644 index 0000000..f51ac9f --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/6 - Failure, Fault, and Error Quiz - lang_en_vs4.srt @@ -0,0 +1,19 @@ +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 new file mode 100644 index 0000000..bc55603 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/7 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,31 @@ +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 new file mode 100644 index 0000000..18515a6 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/8 - Failure, Fault, and Error Quiz - lang_en_vs4.srt @@ -0,0 +1,15 @@ +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 new file mode 100644 index 0000000..56db4c1 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/9 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,39 @@ +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. |