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.