1 files changed, 251 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt
new file mode 100644
index 0000000..f889057
--- /dev/null
+++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt
@@ -0,0 +1,251 @@
+1
+00:00:00,140 --> 00:00:03,010
+In this example, we're going to start from an informal specification, and the
+
+2
+00:00:03,010 --> 00:00:06,670
+specification is the one shown here in file spec.txt. This is the
+
+3
+00:00:06,670 --> 00:00:10,210
+specification for the maintenance function in a specific system. So what we're
+
+4
+00:00:10,210 --> 00:00:13,630
+doing is that we're taking the description of the functionality of a system,
+
+5
+00:00:13,630 --> 00:00:16,219
+and we're building a model, in this case a final state machine
+
+6
+00:00:16,219 --> 00:00:18,710
+for it. And there is no need to look at all the details
+
+7
+00:00:18,710 --> 00:00:21,350
+for this specification, but I want to point out that if you
+
+8
+00:00:21,350 --> 00:00:25,640
+look at the way the specification is written, we can identify specific cases
+
+9
+00:00:25,640 --> 00:00:28,210
+that we need to take into account. Like here if something
+
+10
+00:00:28,210 --> 00:00:31,920
+happens, something else will follow. Again, if something happens something else
+
+11
+00:00:31,920 --> 00:00:35,690
+will follow. So we have multiple choices here. Here will determine
+
+12
+00:00:35,690 --> 00:00:38,140
+the next steps and so on. So all we have to
+
+13
+00:00:38,140 --> 00:00:42,420
+do is to go through this process, identify these cases and
+
+14
+00:00:42,420 --> 00:00:45,300
+then build a machine that represents these cases. For the spec
+
+15
+00:00:45,300 --> 00:00:47,830
+that we just consider this is the state machine that will
+
+16
+00:00:47,830 --> 00:00:50,960
+result. Again there is no need to go through all the details,
+
+17
+00:00:50,960 --> 00:00:53,090
+but what I want to point out is that we have
+
+18
+00:00:53,090 --> 00:00:55,710
+a set of states. So for instance, we have state zero,
+
+19
+00:00:55,710 --> 00:00:58,380
+which is no maintenance, and if a request comes in, the
+
+20
+00:00:58,380 --> 00:01:01,350
+system will move, and the system wait for pickup. Then if
+
+21
+00:01:01,350 --> 00:01:04,400
+the pickup actually occurs, the system will move to the repair
+
+22
+00:01:04,400 --> 00:01:07,540
+state, and so on and so forth. So this is just
+
+23
+00:01:07,540 --> 00:01:13,070
+a more systematic representation of what was in the former specification.
+
+24
+00:01:13,070 --> 00:01:16,160
+And I will argue that this is much easier to understand at
+
+25
+00:01:16,160 --> 00:01:19,170
+least for somebody who has to develop tests for this system. In
+
+26
+00:01:19,170 --> 00:01:21,770
+fact what we're going to see next is how we can go from that
+
+27
+00:01:21,770 --> 00:01:24,790
+representation to a set of test cases. And the way which we do
+
+28
+00:01:24,790 --> 00:01:28,950
+it is by covering the behaviors represented by defining state machine. And we
+
+29
+00:01:28,950 --> 00:01:31,500
+can decide how we want to cover them. For example we might want
+
+30
+00:01:31,500 --> 00:01:35,080
+to cover all the states. So we might want to identify paths in
+
+31
+00:01:35,080 --> 00:01:38,310
+the state machine that go through all the states in the machine. Like
+
+32
+00:01:38,310 --> 00:01:41,840
+the one I just draw or this one, this one and this one.
+
+33
+00:01:41,840 --> 00:01:44,900
+So if we consider these four test cases, we can see that all the
+
+34
+00:01:44,900 --> 00:01:48,470
+states in my system or at least all the states that I have identified
+
+35
+00:01:48,470 --> 00:01:51,450
+are covered. I might want to go a little further, and decide that I
+
+36
+00:01:51,450 --> 00:01:54,210
+don't only want to cover all of the states, but I want to cover, all
+
+37
+00:01:54,210 --> 00:01:57,930
+of the transitions, because, it makes sense to visit a state, when coming from
+
+38
+00:01:57,930 --> 00:02:00,380
+different states. And, if I want to do that, and I look at the
+
+39
+00:02:00,380 --> 00:02:03,440
+test cases that I generated so far, I can see that there is one
+
+40
+00:02:03,440 --> 00:02:06,910
+transition, the one here, that is not covered. And, the same can be said for
+
+41
+00:02:06,910 --> 00:02:09,210
+the two transitions here. So what I can decide to do is
+
+42
+00:02:09,210 --> 00:02:13,370
+to generate another test case, that covers those or extend an existing one.
+
+43
+00:02:13,370 --> 00:02:16,500
+For instance, I could extend this test case by adding a visit to
+
+44
+00:02:16,500 --> 00:02:20,760
+the state, before going back to these two. Alternatively, I could also generate
+
+45
+00:02:20,760 --> 00:02:24,390
+new test cases, such as this one. To cover the missing transitions.
+
+46
+00:02:24,390 --> 00:02:26,350
+And once I have these test cases, I can express them in a
+
+47
+00:02:26,350 --> 00:02:29,860
+clearer way by simply specifying what are the states that they cover. I'm
+
+48
+00:02:29,860 --> 00:02:31,990
+just going to give you a couple of examples. Say, if we look
+
+49
+00:02:31,990 --> 00:02:34,280
+at the last one that I added, which will be test case
+
+50
+00:02:34,280 --> 00:02:37,190
+number five, I just need to specify that it will go through state
+
+51
+00:02:37,190 --> 00:02:41,090
+zero, which is this one, five, which is this one, six, and
+
+52
+00:02:41,090 --> 00:02:43,130
+then back to zero. And I can do the same for the other
+
+53
+00:02:43,130 --> 00:02:46,500
+test cases. So this will be my complete set of test cases.
+
+54
+00:02:46,500 --> 00:02:50,060
+So the bottom line here is that it is much harder to build
+
+55
+00:02:50,060 --> 00:02:53,080
+a set of test cases that will cover the behavior of an informal
+
+56
+00:02:53,080 --> 00:02:56,970
+description. But by going through a model, so by building in this case,
+
+57
+00:02:56,970 --> 00:03:01,700
+a finite state machine for that description, we can, in a much easier way, see
+
+58
+00:03:01,700 --> 00:03:04,100
+what the behaviors of interest of the system
+
+59
+00:03:04,100 --> 00:03:05,960
+are, and try to cover them. And there
+
+60
+00:03:05,960 --> 00:03:07,400
+is again in the spirit of breaking
+
+61
+00:03:07,400 --> 00:03:09,950
+down a complex problem into smaller steps that
+
+62
+00:03:09,950 --> 00:03:11,620
+we can better manage, which in the end,
+
+63
+00:03:11,620 --> 00:03:14,450
+results in a more efficient and effective testing.