Hello,
I have the scenario for testing a workflow from start to end. The workflow is same but the scenario varies based on data. We have about 15 scenarios for the workflow but the data for each scenario is different.
We would like to test each scenario at least 5 times with different values. The data fields being large, having the data entered in excel sheet will be difficult for the tester to navigate the record from column 1 …. Column n.
We were looking at an alternative where we could have the record structured in xml, with name value pair. We plan to have the parent node, 5 child nodes, each child node will have one set of data where each row will be name value.
Here is the same xml.
We will have one test data driven connecting to the xml file (datasource). The data table in TestStudio (2014TR1), only allows us bind only one table (i.e. data-1 or data-2, etc)..
Ideally would like to run the complete file once… We don’t want write to many custom coded steps since the testers do not have coding background.
Please share solution if anyone have implemented both coding and non-coding is welcome but using Test Studio UI.
Thanks
Govind
I have the scenario for testing a workflow from start to end. The workflow is same but the scenario varies based on data. We have about 15 scenarios for the workflow but the data for each scenario is different.
We would like to test each scenario at least 5 times with different values. The data fields being large, having the data entered in excel sheet will be difficult for the tester to navigate the record from column 1 …. Column n.
We were looking at an alternative where we could have the record structured in xml, with name value pair. We plan to have the parent node, 5 child nodes, each child node will have one set of data where each row will be name value.
Here is the same xml.
<?xml version="1.0" encoding="utf-8"?><Approval > <data-1> <Fault label="IncidentType" value = "Fatal"/> <Fault label="IncidentDate" value = "01/01/2014"/> <Fault label="IncidentTime" value = "10:00"/> <Fault label="Location" value = "Surface"/> <Fault label="Detailedocationonsite" value = "Location"/> . . . . <data-1> <data-2> <Fault label="IncidentType" value = "Fatal"/> <Fault label="IncidentDate" value = "01/01/2014"/> <Fault label="IncidentTime" value = "10:00"/> <Fault label="Location" value = "Surface"/> <Fault label="Detailedocationonsite" value = "Location"/> . . . . <data-2> . . . . <data-n> <Fault label="IncidentType" value = "Fatal"/> <Fault label="IncidentDate" value = "01/01/2014"/> <Fault label="IncidentTime" value = "10:00"/> <Fault label="Location" value = "Surface"/> <Fault label="Detailedocationonsite" value = "Location"/> . . . . <data-n></Approval >We will have one test data driven connecting to the xml file (datasource). The data table in TestStudio (2014TR1), only allows us bind only one table (i.e. data-1 or data-2, etc)..
Ideally would like to run the complete file once… We don’t want write to many custom coded steps since the testers do not have coding background.
Please share solution if anyone have implemented both coding and non-coding is welcome but using Test Studio UI.
Thanks
Govind
4 Answers, 1 is accepted
0
Hi Govind,
It sounds like an approach like that described in this KB article might fit your needs. Basically you have one parent test and multiple child tests. Each test is bound to a different data source (i.e. a different table). The parent test will run X loops (once for each row of its table) and each child test will also run Y loops (once for each of its table) before returning control to the parent.
In the end the parent test will end up calling each child text X times while each child test will run Y times before returning control. You'll need to think some how to split the data because, as you correctly pointed out, each Test Studio test can only bind to a single table within the data source.
Regards,
Cody
Telerik
It sounds like an approach like that described in this KB article might fit your needs. Basically you have one parent test and multiple child tests. Each test is bound to a different data source (i.e. a different table). The parent test will run X loops (once for each row of its table) and each child test will also run Y loops (once for each of its table) before returning control to the parent.
In the end the parent test will end up calling each child text X times while each child test will run Y times before returning control. You'll need to think some how to split the data because, as you correctly pointed out, each Test Studio test can only bind to a single table within the data source.
Regards,
Cody
Telerik
0
Govind
Top achievements
Rank 1
Rank 1
answered on 26 Aug 2014, 12:56 AM
Hi Cody,
If i have to bind the data source (table) for each test, then i will have to copy and paste the test script each time i bind to a data source.
When compared to coding, all we need to do is loop through the data source (5 files for each test) with one test script (code) then having multiple copies of the same test scripts.
example:
1) Fetch Data Availables in the folder (*.xml)
2) for (int i = 0; i < number of files; i++) {
read each file; ---- (process files one at a time)
bind to test script ----- (dynamically bind to files)
execute test script ----- ( 1 test script processing 'n' data files)
write result to output file (xls file)
}
3) end of test
Am not sure whether my understanding of the solution description (KB) is correct.
Thanks
Govind
If i have to bind the data source (table) for each test, then i will have to copy and paste the test script each time i bind to a data source.
When compared to coding, all we need to do is loop through the data source (5 files for each test) with one test script (code) then having multiple copies of the same test scripts.
example:
1) Fetch Data Availables in the folder (*.xml)
2) for (int i = 0; i < number of files; i++) {
read each file; ---- (process files one at a time)
bind to test script ----- (dynamically bind to files)
execute test script ----- ( 1 test script processing 'n' data files)
write result to output file (xls file)
}
3) end of test
Am not sure whether my understanding of the solution description (KB) is correct.
Thanks
Govind
0
Hello Govind,
The technical challenge here is that Test Studio was not designed to handle dynamic data binding as you describe. It can only handle static data binding. Thus yes, the KB article I previously pointed you too is written with static data binding in mind... where each test is statically bound to a different data source that cannot be changed during test execution (only during design time).
We have written this KB article on tricks you can do to achieve the same net effect as dynamic data binding.
Regards,
Cody
Telerik
The technical challenge here is that Test Studio was not designed to handle dynamic data binding as you describe. It can only handle static data binding. Thus yes, the KB article I previously pointed you too is written with static data binding in mind... where each test is statically bound to a different data source that cannot be changed during test execution (only during design time).
We have written this KB article on tricks you can do to achieve the same net effect as dynamic data binding.
Regards,
Cody
Telerik
0
Shashi
Top achievements
Rank 1
Rank 1
answered on 27 Aug 2014, 03:08 AM
Govind,
If I am understanding this correctly, you want to execute the same workflow either once per "Fault" per data set - or once per data set (passing in all Fault values as a collection) - are either of those correct?
If so, the following may work:
Shared Test (not data bound).
- implement workflow
- Steps that need data from the xml file will be databound to extracted variables
- Extracted variables can be defined during the databinding - simply type in a new variable name (that doesn't already exist in the list) in the text field, hit Enter and then hit Set (this is per UI in version 2012.2.1420.0 - not sure if it has changed in recent versions).
- You may want to have a prefix such as "Ext" or "ExtIn" in the variable name to distinguish them from other extracted and data variables.
- Define as many extracted variables as necessary - 2 if shared test needs to run for each "Fault" separately, or more if you are going to pass in all the Faults as a set.
Main Test
- Add a coded step to set the extracted variables for each call.
- Call the shared test.
- Add a for or while loop around the above steps if shared test is to be called for each "Fault".
Implementation of the coded step will depend on how you are going to databind. I see the following options:
a) Use Builtin grid as data source - one row per data set, each label is a column with Column value = value.
- If shared test is to be called for each "Fault", coded step will then "feed" each column label and its value to the shared test.
- If shared test is to be called for the entire set of Faults, coded step would set the extracted variables
b) If you want to use XML file, you can bind to the "Approval" node and have the coded steps set extracted variables from the individual nodes using XML API. Handling a hierarchical node structure may be a bit tricky - but shouldn't be too hard.
If you need to be able to run the shared test standalone (as you would need to if you need to debug it - assuming TS still does not support debugging of shared tests when running main tests), you would need to do the following:
a) Add code (at the beginning) to verify that the app is in the initial state expected by the shared test - and if it is not met, execute the necessary steps to get it to that state.
b) Shared test can then databind to an appropriate sample data source (either one of the data sets in the XML file, or the Builtin grid with sample values).
c) Add a coded step in the standalone code to populate the extracted variables from the databound values.
Hope that helps,
Shashi
If I am understanding this correctly, you want to execute the same workflow either once per "Fault" per data set - or once per data set (passing in all Fault values as a collection) - are either of those correct?
If so, the following may work:
Shared Test (not data bound).
- implement workflow
- Steps that need data from the xml file will be databound to extracted variables
- Extracted variables can be defined during the databinding - simply type in a new variable name (that doesn't already exist in the list) in the text field, hit Enter and then hit Set (this is per UI in version 2012.2.1420.0 - not sure if it has changed in recent versions).
- You may want to have a prefix such as "Ext" or "ExtIn" in the variable name to distinguish them from other extracted and data variables.
- Define as many extracted variables as necessary - 2 if shared test needs to run for each "Fault" separately, or more if you are going to pass in all the Faults as a set.
Main Test
- Add a coded step to set the extracted variables for each call.
- Call the shared test.
- Add a for or while loop around the above steps if shared test is to be called for each "Fault".
Implementation of the coded step will depend on how you are going to databind. I see the following options:
a) Use Builtin grid as data source - one row per data set, each label is a column with Column value = value.
- If shared test is to be called for each "Fault", coded step will then "feed" each column label and its value to the shared test.
- If shared test is to be called for the entire set of Faults, coded step would set the extracted variables
b) If you want to use XML file, you can bind to the "Approval" node and have the coded steps set extracted variables from the individual nodes using XML API. Handling a hierarchical node structure may be a bit tricky - but shouldn't be too hard.
If you need to be able to run the shared test standalone (as you would need to if you need to debug it - assuming TS still does not support debugging of shared tests when running main tests), you would need to do the following:
a) Add code (at the beginning) to verify that the app is in the initial state expected by the shared test - and if it is not met, execute the necessary steps to get it to that state.
b) Shared test can then databind to an appropriate sample data source (either one of the data sets in the XML file, or the Builtin grid with sample values).
c) Add a coded step in the standalone code to populate the extracted variables from the databound values.
Hope that helps,
Shashi