1 files changed, 55 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/27 - Review Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/27 - Review Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..9945694
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/27 - Review Quiz Solution - lang_en_vs4.srt
@@ -0,0 +1,55 @@
+1
+00:00:00,340 --> 00:00:03,581
+And the answer is no. So even path coverage's stronger criteria
+
+2
+00:00:03,581 --> 00:00:06,376
+that we saw is not enough to reveal this problem. And why
+
+3
+00:00:06,376 --> 00:00:08,526
+is that? So let me go back to a concept that
+
+4
+00:00:08,526 --> 00:00:12,491
+I mentioned in a previous lesson, the cost of exhaustive testing. Exhaustive
+
+5
+00:00:12,491 --> 00:00:15,236
+testing is really the only way in which we can exercise
+
+6
+00:00:15,236 --> 00:00:18,230
+all of the possible behaviors of a program. So we can say
+
+7
+00:00:18,230 --> 00:00:21,884
+even though it might sound like topology, that only exhaustive testing is
+
+8
+00:00:21,884 --> 00:00:25,710
+exhausted. All the coverage criteria that we saw are just process and
+
+9
+00:00:25,710 --> 00:00:30,900
+just approximation of a complete test. So test is a best effort kind
+
+10
+00:00:30,900 --> 00:00:33,180
+of activity. Coverage criteria help you assess
+
+11
+00:00:33,180 --> 00:00:35,430
+how well you tested but once more,
+
+12
+00:00:35,430 --> 00:00:40,060
+test can only reveal issues, can only reveal problems. You can never show the
+
+13
+00:00:40,060 --> 00:00:42,530
+absence of problems. And that's something is
+
+14
+00:00:42,530 --> 00:00:44,377
+important to remember when we do testing.