1 files changed, 0 insertions, 275 deletions
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.