Презентация e learning State Transition Testing Technique

State Transition Testing Technique Training Kateryna Dribas

Agenda 1. Introduction 2. Technique 3. Examples 4. Summary 5. Q&A 6. Before practice start 7. Practice 8. References 9. 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 3 rd invalid try the card will be «eaten». And in 10 seconds start menu appears. Wait for PIN 2 nd try 3 rd try Access to account Eat card Start Card inserted Enter valid PINEnter invalid PIN Enter valid PINEnter invalid PINTechnique: State diagram In 10 seconds

Whether all situations were considered? Wait for PIN 2 nd try 3 rd try Access to account Eat card Start Card inserted Enter valid PINEnter invalid PIN Enter valid PINEnter invalid PIN Card inserted. Enter invalid PIN Enter valid PINTechnique: State diagram In 10 seconds Card inserted 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 2 nd try 3 rd try Access to account Eat card EVENT Card inserted Card inserted In 10 seconds NEXT STATE Wait for PIN 2 nd try 3 rd 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 2 nd try 3 rd try Access to account Eat card EVENT Enter invalid PIN Enter invalid PIN NEXT STATE Start 2 nd try 3 rd 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 2 nd try 3 rd try Access to account Eat card EVENT Enter valid PIN Enter valid PIN NEXT STATE Start 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 2 nd try 3 rd try Access to account Eat card Start Enter valid PINEnter invalid PIN Card inserted Technique: Test Cases. 1 st flow Enter invalid PINIn 10 seconds

Wait for PIN 2 nd try 3 rd try Access to account Eat card. Start Card inserted Enter valid PINEnter invalid PINTechnique: Test Cases. 2 nd flow Enter invalid PINA 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 2 nd try 3 rd try Access to account Eat card. Start Card inserted Enter valid PINEnter invalid PINTechnique: Cover 1 st , 2 nd flows Enter invalid PINIn 10 seconds

Wait for PIN 2 nd try 3 rd try Access to account Eat card Start Card inserted Enter valid PINEnter invalid PINTechnique: Test Cases. 3 rd 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 2 nd try 3 rd try Access to account Eat card Start Card inserted Enter valid PINEnter invalid PINTechnique: Cover 1 st , 2 nd , 3 rd flows In 10 seconds Enter valid PIN

Wait for PIN 2 nd try 3 rd try Access to account Eat card. Start Card inserted Enter valid PINEnter invalid PINTechnique: Test Cases. 4 th flow A fourth test where the PIN was correct on the third try. In 10 seconds Enter valid PIN

Wait for PIN 2 nd try 3 rd try Access to account Eat card. Start Card inserted Enter valid PINEnter invalid PINTechnique: Cover 1 st , 2 nd , 3 rd , 4 th flows A fourth test where the PIN was correct on the third try. In 10 seconds Enter valid PIN

Wait for PIN 2 nd try 3 rd try Access to account Eat card. Start Card inserted Enter valid PINEnter invalid PINTechnique: Cover all flows Enter invalid PINIn 10 seconds

Another test where user select illogical for system behavior. Wait for PIN 2 nd try 3 rd try Access to account Eat card Start Card inserted Enter valid PINEnter invalid PIN Enter valid PINEnter invalid PIN Card inserted. Enter invalid PIN Enter valid PIN Technique: Test Cases. Another flow Enter invalid PINIn 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 2 nd try. Enter invalid PIN try = 1 or. Enter invalid PIN try = 2 n th try. Enter invalid PIN try = n-1 Wait for PINEnter 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 = nor

Wait for PIN Eat card Start Card inserted Enter invalid PIN, try = 3 Enter valid PINTechnique: 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 = n)

A first test case here would be the normal situation, where the correct PIN is entered the first time. Technique: Simplistic Test Cases. 1 st 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. 2 nd 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. 3 rd 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

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. 1 st 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.

Example 1: Test Cases. 2 nd 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. 3 rd 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

Example 2: State diagram Type of chocola- te Valida-ti on sum Check selected chocola-te Wait for enough money. Start 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

Example 2: Notification 1 Valida-ti on 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; 1 cop? — 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. 1 st 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-ti on sum Check selected chocola-te Wait for enough money. Start 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

Example 2: Test Cases. 2 nd 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-ti on sum Check selected chocola-te Wait for enough money. Start 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. 3 rd 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-ti on sum Check selected chocolate Wait for enough money. Start 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

Example 2: Test Cases. 4 th 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-ti on sum Check selected chocola-te Wait for enough money. Start 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

Task 1: State diagram Validati-o n of SN and date Wait for Op and time Appoint ment 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. 1 st 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-o n of SN and date Wait for Op and time Appoint ment 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. 2 nd 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-o n of SN and date Wait for Op and time Appoint ment 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. 3 rd 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-o n of SN and date Wait for Op and time Appoint ment 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. 4 th 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-o n of SN and date Wait for Op and time Appoint ment 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. 5 th 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-o n of SN and date Wait for Op and time Appoint ment 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-o n 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. 1 st 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. 1 st flow Validati- on of the date Wait for Op and time Validati-o n 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. 2 nd 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. 2 nd flow Validati- on of the date Wait for Op and time Validati-o n 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. 3 rd 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. 3 rd flow Validati- on of the date Wait for Op and time Validati-o n 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. 4 th 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. 4 th flow Validati- on of the date Wait for Op and time Validati-o n of OPStart 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. 5 th 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. 5 th flow Validati- on of the date Wait for Op and time Validati-o n 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. 1 st 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. 1 st 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. 2 nd 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. 2 nd 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. 3 rd flow A third test case where the planned procedure has been added , and voided after 100 days passed.

Task 3: Test Cases. 3 rd 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. 4 th 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. 4 th 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. 5 th 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. 5 th 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