State Transition Testing Technique Training Kateryna Dribas Agenda Introduction Technique Examples Summary Q&A Before practice start Practice References Questions Introduction Let’s remember… Dynamic testing: Testing that involves the execu-tion of the software of a component or system. What is dynamic testing? What is black box testing? Black box testing: Method of testing that examines the functionality of an application without peering into its internal logical structure. Introduction What is finite state system? Finite state system is any system where user gets a different output for the same input, depending on what has happened before.
What is state transition testing? State transition technique is a dynamic black-box testing technique, which is used when the system is defined in terms of states and the transitions between the states is governed by the rules of the system.
Introduction What is it used for? - gives us the opportunity to visualize all of the states in which the system (application) can exist; - to capture certain kinds of system requirements and to document internal system design; - can serve as a guide to creating test cases;
- is used in cases when system’s reaction depends on its state.
Technique Start Card inserted - states (that the software may occupy) - transitions (from one state to another) - events (that cause a transition) Actions that result from a transition are not shown explicitly but they would be a message to the customer saying things (such as 'Please enter your PIN'). Technique: designations A state transition model can be represented as diagram and as a table.
User inserts credit card and enters PIN for getting bank account.
He has 3 tries to enter valid PIN and to get access to account.
After 3rd invalid try the card will be "eaten". And in 10 seconds start menu appears. Wait for PIN 2nd try 3rd try Access to account Eat card Start Card inserted Enter valid PIN Enter invalid PIN Enter valid PIN Enter invalid PIN Enter valid PIN Enter invalid PIN Technique: State diagram In 10 seconds Whether all situations were considered? Wait for PIN 2nd try 3rd try Access to account Eat card Start Card inserted Enter valid PIN Enter invalid PIN Enter valid PIN Enter invalid PIN Enter valid PIN Enter invalid PIN Card inserted Card inserted Enter invalid PIN Enter valid PIN Technique: State diagram In 10 seconds Card inserted Enter valid PIN Enter valid PIN Enter invalid PIN Enter valid PIN TR 1 TR 2 TR 3 TR 4 TR 5 TR 6 CURRENT STATE Start Wait for PIN 2nd try 3rd try Access to account Eat card EVENT Card inserted Card inserted Card inserted Card inserted Card inserted In 10 seconds NEXT STATE Wait for PIN Wait for PIN 2nd try 3rd try Access to account Start The transition of states can be also shown as state transition table. Where every column illustrates every transition from one state to another. Technique: State table TR 13 TR 14 TR 15 TR 16 TR 17 TR 18 CURRENT STATE Start Wait for PIN 2nd try 3rd try Access to account Eat card EVENT Enter invalid PIN Enter invalid PIN Enter invalid PIN Enter invalid PIN Enter invalid PIN Enter invalid PIN NEXT STATE Start 2nd try 3rd try Eat card Access to account Eat card TR 7 TR 8 TR 9 TR 10 TR 11 TR 12 CURRENT STATE Start Wait for PIN 2nd try 3rd try Access to account Eat card EVENT Enter valid PIN Enter valid PIN Enter valid PIN Enter valid PIN Enter valid PIN Enter valid PIN NEXT STATE Start Access to account Access to account Access to account Access to account Eat card Technique: State table A first test case here would be the normal situation, where the correct PIN is entered the first time. Wait for PIN 2nd try 3rd try Access to account Eat card Start Enter valid PIN Enter invalid PIN Enter valid PIN Enter valid PIN Enter invalid PIN Card inserted Technique: Test Cases. 1st flow Enter invalid PIN In 10 seconds Wait for PIN 2nd try 3rd try Access to account Eat card Start Card inserted Enter valid PIN Enter invalid PIN Enter valid PIN Enter valid PIN Enter invalid PIN Technique: Test Cases. 2nd flow Enter invalid PIN A second test (to visit every state) would be to enter an incorrect PIN each time, so that the system eats the card. In 10 seconds Wait for PIN 2nd try 3rd try Access to account Eat card Start Card inserted Enter valid PIN Enter invalid PIN Enter valid PIN Enter valid PIN Enter invalid PIN Technique: Cover 1st , 2nd flows Enter invalid PIN In 10 seconds Wait for PIN 2nd try 3rd try Access to account Eat card Start Card inserted Enter valid PIN Enter invalid PIN Enter valid PIN Enter valid PIN Enter invalid PIN Technique: Test Cases. 3rd flow A third test case where the PIN was incorrect the first time but OK the second time.
In 10 seconds Enter valid PIN Wait for PIN 2nd try 3rd try Access to account Eat card Start Card inserted Enter valid PIN Enter invalid PIN Enter valid PIN Enter valid PIN Enter invalid PIN Technique: Cover 1st , 2nd , 3rd flows In 10 seconds Enter valid PIN Wait for PIN 2nd try 3rd try Access to account Eat card Start Card inserted Enter valid PIN Enter invalid PIN Enter valid PIN Enter valid PIN Enter invalid PIN Technique: Test Cases. 4th flow A fourth test where the PIN was correct on the third try.
In 10 seconds Enter valid PIN Wait for PIN 2nd try 3rd try Access to account Eat card Start Card inserted Enter valid PIN Enter invalid PIN Enter valid PIN Enter valid PIN Enter invalid PIN Technique: Cover 1st ,2nd,3rd,4th flows A fourth test where the PIN was correct on the third try.
In 10 seconds Enter valid PIN Wait for PIN 2nd try 3rd try Access to account Eat card Start Card inserted Enter valid PIN Enter invalid PIN Enter valid PIN Enter valid PIN Enter invalid PIN Technique: Cover all flows Enter invalid PIN In 10 seconds Another test where user select illogical for system behavior. Wait for PIN 2nd try 3rd try Access to account Eat card Start Card inserted Enter valid PIN Enter invalid PIN Enter valid PIN Enter invalid PIN Enter valid PIN Enter invalid PIN Card inserted Card inserted Card inserted Enter invalid PIN Enter valid PIN Enter valid PIN Technique: Test Cases.
Another flow Enter invalid PIN In 10 seconds In the case when the same event is repeated more than once and leads to the same state there is no need to create many identical states and transitions. Technique: simplistic diagram Wait for PIN 2nd try Enter invalid PIN try = 1 or Enter invalid PIN try = 2 nth try Enter invalid PIN try = n-1 Wait for PIN Enter invalid PIN try = 1 Enter invalid PIN try = 2 Enter invalid PIN try = n-1 Wait for PIN … Eat card Enter invalid PIN try = n Enter invalid PIN try < n Enter invalid PIN try = n Enter invalid PIN try = n or Wait for PIN Eat card Start Card inserted Enter invalid PIN, try = 3 Enter valid PIN Technique: simplistic diagram We can consider the repeated events as a single cyclic event which leads to the same state.
Enter invalid PIN, try < 3 In 10 seconds Access to account Technique: Notification Some illogical repeated events that lead to the states with equal behavior can be considered as one event.
Enter invalid PIN (try < 3 ) ~ Enter invalid PIN (try = 3) ~ Enter invalid PIN (try > 3) ~ Enter invalid PIN (try = n) A first test case here would be the normal situation, where the correct PIN is entered the first time. Technique: Simplistic Test Cases. 1st flow Wait for PIN Eat card Start Card inserted Enter invalid PIN, try =3 Enter valid PIN Access to account Enter invalid PIN, try <3 In 10 seconds Technique: Simplistic Test Cases. 2nd flow A second test (to visit every state) would be to enter an incorrect PIN each time, so that the system eats the card. Wait for PIN Eat card Start Card inserted Enter invalid PIN, try =3 Enter valid PIN Access to account Enter invalid PIN, try <3 In 10 seconds Technique: Simplistic Test Cases. 3rd flow A third test case where the PIN was correct the second or third time.
Wait for PIN Eat card Start Card inserted Enter invalid PIN, try = 3 Enter valid PIN Access to account Enter invalid PIN, try < 3 In 10 seconds Examples Example 1:User types his friend’s mobile account.
He enters amount of money he likes to send, types mobile number and click ‘Send’. If entered amount of money is allowed and phone number format is correct, then money will be sent and user will get appropriate message.
If sum is too low or too high, then user should re-enter it.
If phone number format is incorrect, then user should enter correct phone number.
Example 1 Example 1: State diagram Validation phone number and sum Send money Start Enter sum and phone number Valid sum and phone number Invalid sum and / or phone number The money has been sent In examples is not clear how many times user can repeat the operation of entering sum and phone number.
Example 1: Notification Start Validation phone number and sum Enter sum and phone number Invalid sum or phone number This issue should be clarified with BA. We should find the cases when it has sense.
Example 1: Causes - Test coverage (higher or good enough for project); It depends on:
- Cost of mistake. - Time constraints;
- Budget constraints;
- Defect location identification;
- Business need;
- Quality requirements for the project from customer; Example 1: Test Cases . 1st flow Validation phone number Send money Enter sum and phone number Valid sum or phone number Invalid sum or phone number The money has been sent Start A first test case here would be the normal situation, where the correct sum and phone number are entered the first time. A first test case here would be the normal situation, where the correct sum and phone number are entered the first time. Example 1: Test Cases . 2nd flow A second test (to visit every state) would be to enter an incorrect sum and phone number, so that the system brings back the user to ‘start’ state. Validation phone number Send money Enter sum and phone number Valid sum or phone number Invalid sum or phone number The money has been sent Start Example 1: Test Cases . 3rd flow A second test (to visit every state) would be to enter an incorrect sum and phone number at first time, but correct at second time.
This test case covers all previous flows. Validation phone number Send money Enter sum and phone number Valid sum or phone number Invalid sum or phone number Start The money has been sent Example 2:Chocolate vending machine.
Customer selects a mark of the chocolate (e.g. ‘Kit Kat’), and enters money.
If not enough money is entered, then machine will ask to enter more.
If amount of money is ok, then machine will start selection of chocolate.
If ‘Kit Kat’ chocolate is available, then customer will get ‘Kit Kat’ in a minute.
In a 10 seconds menu returns to main menu.
If there is no selected mark of the chocolate, then customer will get proper message and his money back.
In a 10 seconds menu returns to main menu.
The machine doesn’t give the change.
Example 2 Example 2: State diagram Type of chocola-te Valida-tion sum Check selected chocola-te Wait for enough money Start Enter money Enter money Select type of chocolate Not enough money Money back Give chocola-te Enough money, with or w/o change Chocolate exists In 10 seconds In 10 seconds Chocolate doesn’t exist Example 2: Notification 1 Valida-tion sum Wait for enough money Enter money Not enough money In examples we should discover how much times user has to enter money to get enough pay.
This issue should be clarified with BA. We should find the cases when it has sense.
Let’s take that ‘Kit Kat’ costs 10.00 UAH. What is the minimum number of cases we should make for sum validation? Example 2: Notification 1 Every bank notes and coins? - until get the ___________________________chocolate cost. 10? - equal the chocolate cost;
20? - more the chocolate cost;
1cop? - until get the chocolate cost; In examples is not clear how many times user can repeat the operation of chocolate (the number of types chocolate, e.g. 10 (and if 50??) Example 2: Notification 2 Start Check selected chocolate Select type of chocolate Chocolate doesn’t exist This issue should be clarified with BA. We should find the cases when it has sense.
Example 2: Causes - Test coverage (higher or good enough for project); It depends on:
- Cost of mistake. - Time constraints;
- Budget constraints;
- Defect location identification;
- Business need;
- Quality requirements for the project from customer; Example 2: Test Cases. 1st flow A first test case here would be the normal situation, where the enough sum of money is entered the first time, and selected mark of chocolate exists in vending machine.
Type of chocola-te Valida-tion sum Check selected chocola-te Wait for enough money Start Enter money Enter money Select type of chocolate Not enough money Money back Give chocola-te Enough money, with or w/o change Chocolate exists In 10 seconds In 10 seconds Chocolate doesn’t exist Example 2: Test Cases. 2nd flow A second test would be to enter not enough sum of money the first time, but the sum is getting enough the second time.
And selected mark of chocolate doesn’t exist in vending machine. Type of chocola-te Valida-tion sum Check selected chocola-te Wait for enough money Start Enter money Enter money Select type of chocolate Not enough money Money back Give chocola-te Enough money, with or w/o change Chocolate exists In 10 seconds Chocolate doesn’t exist In 10 seconds Example 2: Notification 3 We have covered all states and transitions. These flows are used to create main test cases. But we may want to verify that all combinations of states and transitions still work correctly. Additional test cases may make you feel warm and fuzzy.
But there’s less probability that they discover defects previous cases don't find.
Example 2: Test Cases. 3rd flow A third test case where the enough sum of money is entered the first time, and selected mark of chocolate doesn’t exists in vending machine. Type of chocola-te Valida-tion sum Check selected chocolate Wait for enough money Start Enter money Enter money Select type of chocolate Not enough money Money back Give chocola-te Enough money, with or w/o change Chocolate exists In 10 seconds In 10 seconds Chocolate doesn’t exist Example 2: Test Cases. 4th flow A fourth test would be to enter not enough sum of money the first time, but sum is getting enough the second time.
And selected mark of chocolate exists in vending machine. Type of chocola-te Valida-tion sum Check selected chocola-te Wait for enough money Start Enter money Enter money Select type of chocolate Not enough money Money back Give chocola-te Enough money, with or w/o change Chocolate exists In 10 seconds Chocolate doesn’t exist In 10 seconds Summary Summary Capture requirements and describe the design of the application.
Describe how the state of the application may vary.
Determine all the events that occur during the application and how the application reacts to these events.
So State Transition testing technique is a tool to: Before practice start Let’s summarize the steps of the technique: Determine all states.
Consider and prioritize according to requirements all ways which cover whole functionality.
Identify all transitions.
Create a test case for each way, that covers main functionality.
Create additional test cases that cover remaining functionality (if it is needed).
Practice For creating appointment provider selects the date and enters his Short Name (SN). If the SN was entered incorrectly the warning message appears and SN should be entered again. If SN has been entered correctly but provider is busy at selected date the appropriate message appears and provider has to select date and enter the SN again. If provider is not busy on selected date he selects an operatory (Op) and a free time from list.
After this appointment is created.
Task 1 Task 1: State diagram Validati-on of SN and date Wait for Op and time Appointment is created Start Select the date Select Op and time Wait for SN Enter SN Invalid SN Provider is busy SN is valid and provider isn’t busy Task 1: Test Cases. 1st flow A first test case here would be the normal situation, where the SN was entered correctly and the provider is not busy at the selected date.
Validati-on of SN and date Wait for Op and time Appointment is created Start Select the date Select Op and time Wait for SN Enter SN Invalid SN Provider is busy SN is valid and provider isn’t busy Task 1: Test Cases. 2nd flow A second test case verifies the case when some of validation doesn’t pass every time.
The entered SN is valid but provider is busy at selected date.
Or SN is invalid.
Validati-on of SN and date Wait for Op and time Appointment is created Start Select the date Select Op and time Wait for SN Enter SN Invalid SN Provider is busy SN is valid and provider isn’t busy Task 1: Test Cases. 3rd flow A third test case where the SN is invalid at first time but valid at the second time and the provider is not busy. Validati-on of SN and date Wait for Op and time Appointment is created Start Select the date Select Op and time Wait for SN Enter SN Invalid SN Provider is busy SN is valid and provider isn’t busy Task 1: Test Cases. 4th flow A fourth test case where the SN is valid at every time and the provider is busy at the first selected date, but not busy at the second one. Validati-on of SN and date Wait for Op and time Appointment is created Start Select the date Select Op and time Wait for SN Enter SN Invalid SN Provider is busy SN is valid and provider isn’t busy Task 1: Test Cases. 5th flow A fifth test is following.
At first time SN is invalid at but valid at the second time an the provider is busy at the first selected date, but not busy at date selected the second time.
This test case covers all previous flows. Validati-on of SN and date Wait for Op and time Appointment is created Start Select the date Select Op and time Wait for SN Enter SN Invalid SN Provider is busy SN is valid and provider isn’t busy For creating appointment provider selects his Short Name (SN) from the list of clinic's providers and than enters the date of appointment.
If provider is busy on entered date or the date’s format is incorrect the warning message appears and the date should be entered again.
If provider is not busy on entered date he selects a free time and an operatory (Op) from lists.
After this appointment is created.
Task 2 Provider can entre invalid date twice.
After third invalid try the calendar with available dates for selected provider appears.
And the date should be selected from calendar. If selected operatory is not available the appropriate message appears and provider should select another operatory (Op) from appeared list of free operatories. Task 2: State diagram Validati-on of the date Wait for Op and time Validati-on of Op Start Select Op and time Wait for date Select SN Select date Provider is busy or incorrect date format Try < 3 Provider isn’t busy Enter the date Provider is busy or incorrect date format.
Try = 3 Calendar Appoint-ment is created List of free Ops Op is available Op isn’t available Select Op Task 2: Test Cases. 1st flow A first test case here would be the normal situation, when the date was entered correctly, provider is not busy at the selected date.
And the Op is available.
Task 2: Test Cases. 1st flow Validati-on of the date Wait for Op and time Validati-on of Op Start Select Op and time Wait for date Select SN Select date Provider is busy or incorrect date format Try < 3 Provider isn’t busy Enter the date Provider is busy or incorrect date format.
Try = 3 Calendar Appoint-ment is created List of free Ops Op is available Op isn’t available Select Op Task 2: Test Cases. 2nd flow A second test is following.
The date is invalid at every time and provider is busy every time until calendar appears.
The Op isn’t available every time until calendar appears. Tasks:
2 Test Cases. 2nd flow Validati-on of the date Wait for Op and time Validati-on of Op Start Select Op and time Wait for date Select SN Select date Provider is busy or incorrect date format Try < 3 Provider isn’t busy Enter the date Provider is busy or incorrect date format.
Try = 3 Calendar Appoint-ment is created List of free Ops Op is available Op isn’t available Select Op Tasks:
2 Test Cases. 3rd flow A third test case where the date was entered incorrectly and provider is busy at first time, but ok at second time and the Op is available at first time.
Tasks:
2 Test Cases. 3rd flow Validati-on of the date Wait for Op and time Validati-on of Op Start Select Op and time Wait for date Select SN Select date Provider is busy or incorrect date format Try < 3 Provider isn’t busy Enter the date Provider is busy or incorrect date format.
Try = 3 Calendar Appoint-ment is created List of free Ops Op is available Op isn’t available Select Op Tasks:
2 Test Cases. 4th flow A fourth test case where the date was entered incorrectly and provider is busy every time until calendar appears and the Op is available at first time.
Task 2: Test Cases. 4th flow Validati-on of the date Wait for Op and time Validati-on of OP Start Select Op and time Wait for date Select SN Select date Provider is busy or incorrect date format Try < 3 Provider isn’t busy Enter the date Provider is busy or incorrect date format.
Try=3 Calendar Appoint-ment is created List of free Ops Op is available Op isn’t available Select Op Task 2: Test Cases. 5th flow A fifth test case where the date was entered correctly and provider is not busy at first time.
The operatory isn't available at first time.
Tasks:
2 Test Cases. 5th flow Validati-on of the date Wait for Op and time Validati-on of Op Start Select Op and time Wait for date Select SN Select date Provider is busy or incorrect date format Try < 3 Provider isn’t busy Enter the date Provider is busy or incorrect date format.
Try = 3 Calendar Appoint-ment is created List of free Ops Op is available Op isn’t available Select Op Task 3 Operation with procedures (Proc) for selected patient:
1. Provider adds planned Proc to the patient;
2. When planned Proc has been done provider should change its status from 'Plan' to 'Completed;
3. When completed Proc has been paid provider should change its status from 'Completed’ to ‘Paid’;
4. If planned or completed Proc has incorrect information and it has not been paid yet it can be deleted by provider;
5. If 100 days take after adding planned Proc it will automatically become inactive and can't be deleted, but it can be voided by provider;
6. If 100 days take after adding complete Proc, that has not been paid it will auto-matically get status 'Warning‘ and can't be deleted, but it can be voided or paid;
7. It is no possibility to make any operation with paid Proc.
Task 3: State diagram Paid Proc Inactive Proc Planned Proc posted Add ‘Plan’ Proc Delete Proc Complet-ed Proc Choose ‘Completed’ status Delete Proc Choose ‘Paid’ status In 100 days Voided Choose ‘Void’ status Warning Proc In 100 days Patient selected Choose ‘Paid’ status Choose ‘Void’ Status Task 3: Test Cases. 1st flow A first test case here would be the normal situation, when planned procedure for selected patient has been added, completed and paid.
Task 3: Test Cases. 1st flow Paid Proc Inactive Proc Planned Proc posted Add ‘Plan’ Proc Delete Proc Complet-ed Proc Choose ‘Completed’ status Delete Proc Choose ‘Paid’ status In 100 days Voided Choose ‘Void’ status Warning Proc In 100 days Patient selected Choose ‘Paid’ status Choose ‘Void’ Status Task 3: Test Cases. 2nd flow A second test case where the planned procedure has been added, completed, deleted, and than the planned procedure has been added again and deleted.
Task 3: Test Cases. 2nd flow Paid Proc Inactive Proc Planned Proc posted Add ‘Plan’ Proc Delete Proc Complet-ed Proc Choose ‘Completed’ status Delete Proc Choose ‘Paid’ status In 100 days Voided Choose ‘Void’ status Warning Proc In 100 days Patient selected Choose ‘Paid’ status Choose ‘Void’ Status Task 3: Test Cases. 3rd flow A third test case where the planned procedure has been added, and voided after 100 days passed. Task 3: Test Cases. 3rd flow Paid Proc Inactive Proc Planned Proc posted Add ‘Tx Plan’ Proc Delete Proc Complet-ed Proc Choose ‘Completed’ status Delete Proc Choose ‘Paid’ status In 100 days Voided Choose ‘Void’ status Warning Proc In 100 days Patient selected Choose ‘Paid’ status Choose ‘Void’ Status Task 3: Test Cases. 4th flow A fourth test case where the planned procedure has been added completed, after 100 days has got warning status and has been paid at the end. Task 3: Test Cases. 4th flow Paid Proc Inactive Proc Planned Proc posted Add ‘Tx Plan’ Proc Delete Proc Complet-ed Proc Choose ‘Completed’ status Delete Proc Choose ‘Paid’ status In 100 days Voided Choose ‘Void’ status Warning Proc In 100 days Patient selected Choose ‘Paid’ status Choose ‘Void’ Status Task 3: Test Cases. 5th flow A fifth test case where the planned procedure has been added completed, after 100 days has got warning status and at has been void. Task 3: Test Cases. 5th flow Paid Proc Inactive Proc Planned Proc posted Add ‘Tx Plan’ Proc Delete Proc Complet-ed Proc Choose ‘Completed’ status Delete Proc Choose ‘Paid’ status In 100 days Voided Choose ‘Void’ status Warning Proc In 100 days Patient selected Choose ‘Paid’ status Choose ‘Void’ Status References Questions & Answers