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