What is Data Driven Testing technology in IBM Rational Functional Tester?

- DATA DRIVEN TESTING or DDT involves testing the software systems or applications using a number of sets of input data and output data stored in a data table.
- The testing process is carried out in an environment where the controls as well as the settings are not hard coded i.e., where the controls and settings are modifiable.
- The input data values from the rows and columns of the table are supplied to the program by the tester and the output obtained is compared with the expected output of the corresponding row and column.
- The values stored in the table are related to the partition input spaces and boundary.
- However, when the control methodology is applied, the configuration for the test is read from the data base.
- Today several methodologies have been developed for implementing the data driven testing.
- All such methodologies are known to co – exist since there is a difference in the effort they demand for the creation and subsequent maintenance.
- The main advantage of applying data driven testing is the ease with which the inputs can be added to the data table on the discovery of new partitions and there addition to the system under test or product.
- Another thing about the data driven testing is that it costs more to implement it manually rather than automated implementation which is comparatively cheaper.
- Data driven testing involves creation of the test scripts together with the related data sets present in the frame work.
- The re – usable test logic is obtained from this frame work only and is used for the reduction of the maintenance and improvement of the test coverage.
- The input as well as the result is stored in either one or more than one central data sources which we commonly called as data bases though the organization of the data and actual data depends up on the implementation.
- The data that is used for driving the tests consists of both the input values and the expected output values or the verified output values.
- The data is got via a sniffer (or a purpose – built custom tool) from a running system.
- The data driven testing then performs a play back of the harvested data thus acting as a powerful automated tool for regression testing.
- The following things are coded in the test script:
1. Navigation through the application
2. Reading data sources
3. Logging test status
4. Information

- Any variability which has a potential to make a change is taken out from the test logic or the scripts and move to the set of external assets.
- Such set is called a test data set or a configuration.
- Data driven testing is one of the key technologies that is implemented by the IBM’s rational functional tester.
- The hard coded scripts have got a few limitations.
- Whenever a test script is recorded using some literal values, the data gets hard coded in that script.
- This script then can be executed only with one test case or with one set of valid inputs.
- Also, such scripts are difficult to be put in to reuse and maintenance is cumbersome.
- The rational functional tester separates the data from the script so that it can be modified without having any effect on the test scripts and new test cases can be added through the modification of the data rather than modifying the test script.
- Three scenarios have been defined for the implementation of the data driven testing in the rational functional tester:
1. Creation of a data pool while the recording of a data driven script is n progress within the functional tester. Modification of the data pool:
2. Importing a data pool that was created externally in to functional tester and associating it with a test script.
3. Creation of data pool while the recording of a script is going on within functional tester. Exporting the data pool and editing it externally. Importing this data pool for driving a test script.

What is keyword driven testing framework and methodology?

Keyword driven testing is one of the testing methodologies which is gaining popularity in the area of the test automation. Well, in this article, we are going to discuss regarding the frame work and methodology of the keyword driven testing. 

What is Keyword Driven Testing?

- The key word driven testing methodology is actually dependent on frame work. 

- It depends on such a frame work that calls for the development of the key words and data tables.

- But there is one condition which is that it should be independent of the test automation tool which is to be used for their execution. 

- Another condition is that it should also be independent of the test script code which is used to drive the application under test or AUT as well as the data. 

- In this testing methodology, the functionality of the application under test or AUT need to be documented in a table. 

- Also, the functionality needs to be stated as in step by step instructions for each and every test. 

- This then actually becomes a frame work approach for creating automated regression tests. 

- The frame work approach thus obtained proves to be successful in achieving many benefits of the automated testing when compared to the traditional methodology for capture and playback of the custom scripts. 

- Whenever automated testing is required, two sets of requirements come in to existence namely:

1. Business Requirements: This category included the following requirements:

a) Maintainability: The maintenance of the tests should be easy as well as there should be a minimum need for updating scripts with changes made to the application and newer versions.

b) Selective testing: Less requirement of in depth testing. Also it should be easy to select test scenarios for a much targeted regression.

c) Recovery: It should be possible for the test suite to resume testing from the point where it failed or crashed at a later point of time. The need for re- testing the functionality should be eliminated.

d) Scalability: For gaining the time efficiency the execution of the tests from different machines at the same time should be possible.

e) Inter environment portability: All the environments must support the test scripts without making nay changes to them.

f)   Usability: Minimal amount of training must be required by employees to learn to execute the automated suite. There should be no manual intervention in the execution of the scripts.

g) Reporting: The status of each test script must be known easily.

2. Technical requirements: This category includes:

a) Data abstraction: There should complete isolation of the test data for the execution of the scripts from the actual script code.

b) Separation of concerns: Concerns at each layer must be addressed by the distinct layers of the architecture.

c)  Portability

Methodology of the keyword driven testing lies in two different phases namely:

1. Planning phase and
2. The implementation phase

The planning phase involves the analyzation of the application and determination of operations and objects to be used in the business processes. The requirement of customized keywords is determined for the following purpose:

1. Additional functionality
2. Business level clarity
3. Maximizing efficiency
4. Maintainability

The second phase i.e., the implementation phase operates around a collection of objects or references usually known as repository which saves the info for unique identification of the objects. This phase also involves the development and documentation of the keywords of the business level in function libraries. Development of customized functions is required for the creation of the functional libraries. This is all done for the application under test or AUT.

The methodology of the keyword driven testing calls for more advance planning and time investment.

How many ways we can parameterize data in QTP?

Parameterization is one of the important provisions we have in quick test professional which has enabled the passing of the values to the tests very simple. This parameterization feature enables one to pass multiple values at a time to a test.

And what more? 

The process of parameterization has proven to be a great helping hand while carrying out the data driven testing. Data driven testing is the kind of testing that involves working with multiple sets of data on the same tests. 

The quick test professional comes with various ways for carrying out the process of parameterization:

1. Parameterization via loop statements
2. Parameterization via data table
3. Dynamic test data submission
4. Obtaining test data via front end objects
5. Getting test data directly from the spread sheets, flat files or we can say external files.
6. Getting test data directly from the oracle, MSaccess or we can say data bases.

Now we shall discuss the above 6 different ways of parameterizing the tests in detail.

1. Parameterization via loop statements: 

In this method the sequential numbers or logical numbers can be passed via the loop statements however you cannot pass strings to the tests.

2. Parameterization via data table: 

One data table or spread sheet is provided along every test in quick test professional. The provided data table along with the test can be used very well for the data driven testing. Furthermore the following 3 purposes are served by the data table:

a)   To import the test data from external spread sheets: for doing this open the data table and place the pointer. Then right click and select the import from file option. Then you need to enter the path of the spread sheet to be imported from and hit ok. Later connect to the test.

b)   To import the test data from the external flat files: for doing this open the data table and place the pointer. Then right click and select the import from file option. Then you need to browse the path of the file to imported and press ok. Later connect to the test.

c)   To import the test data from the data bases: for doing this the user needs to first create a DSN of the data base i.e., the data source name by making use of the SQL commands. This can be done by creating a test data base and saving the created data base with .mdb extension in msaccess. Next step involves creation of a data table and filling it up with data. The last step is to create a DSN and you can start importing the data.

    3. Dynamic test data submission: 

   This also involves the use of the loop statements however the data has to be entered again and again by the user.

    4. Obtaining test data via front end objects

   5. Getting test data directly from the spread sheets, flat files or we can say external files.

   6. Getting test data directly from the oracle, MSaccess or we can say data bases.

There is one more method for parameterizing the data apart from those mentioned above and is also less followed. The method makes use of the dictionary object for the purpose of parameterization. There are several types of parameterization namely:

1. Data table
2. Environment variable
3. Random number
4. Test and action

The data table consists of the following parameters:

1. Input parameter
2. Out put parameter
3. Random number
4. Environment variable. 

What is a Run-Time Data Table? Where can I find and view this table?

The quick test professional always makes it a point to produce a run time data table at the end of every run session so that the user can have a live view of the data table that is currently associated with the test being carried out at that time. 

What is a Run-Time Data Table?

- While the run session is still in progress, the run time data table is displayed in the data table pane of the quick test professional window. 

- This is to make it easy for the user to view any changes that are constantly made to data during the run session.

- At the end of the run session, this run time data table is closed and in the data table pane the stored design time data table is displayed again in the place of the run time data table. 

- In some of the cases the data which entered in to the run time data table during the run session is not saved along with the test.

- At the end of the run session the data in the table is finalized and is displayed is run time data table column of the results window of the test. 

- The name of the run time data table was derived from the fact that it is generated during the run time. 

- With every script or component there is an associated run time data table which serves the purpose of displaying the data.  

- One run time data table has the property to access the data from some other data table during the run time. 

After a particular test has been executed with either of the following:

1. Data table parameters and
2. Data table output value steps

The following are displayed by the run time data table:

1. Parameterized values that were used during the testing and automation and
2. Output values that were saved in the data table during the run session.

Certain data table methods are provided by the quick test professional with the help of which the user can alter the data table as required and these are:

1. Add sheet: This data table method can be used to add sheets in to the pre existing run time data table. Syntax used is:

Datatable.addsheet (name of the sheet)

2. Delete sheet: This data table method as obvious from its name is used for deletion of the already added sheets in a run time data table. However at one time only one sheet can be deleted. Syntax used is:

Datatable. Deletesheet (“ID of the sheet”)

3. Get sheet count: This data table method gives you the number of sheets that you have in your run time data table. Syntax used is:

Datatable. Getsheet count

4. Get sheet: This methods returns the sheet specified from the run time data table by the user. Syntax used is:

Datatable. Getsheet( ID of the sheet)

5. Get row count: Returns the number of rows present in a particular sheet of the run time data table. Syntax used is:  datatable. Getrowcount
6. Value: This data table method serves two purposes i.e., using it you can either obtain value of a specified cell or you can modify the value of the cell. Syntax for both the cases is:

Variable = datatable. Value( name of the parameter, name of the sheet)

Variable = datatable. Value( name of the parameter, name of the sheet) = value

  There are some other data table methods also like:

1. Set current row
2. Set next row
3. Set previous row
4. Import
5. Export and so on.

How will you call from one action to another action in QTP?

In the test scripts produced with the help of quick test professional, one action can be called from another action. In this article we are going to discuss the same i.e., how this can be done? 

How to call from one action to another action?

- A call to a reusable action can be inserted easily that might be stored in some local test (current test) or in some external test (external test). 

- Calling one action from some other action is just like inserting an action call in an existing action or just linking it to it.

- The steps involved in this whole process can be viewed using the action view tool but they cannot be modified. 

- The local object repository of the action that has been called is read only. 

- It is not necessary that each and every calling and called action must have a local object repository. 

- It may or may not have a repository.

- If the external action that has been called has some data in the data table, you get two options:

1. Either you take the data from the data sheet of the action and import it as a editable or local copy,
2. Or you take the data from the original action but here the data is read only type.

- The data obtained from the global data sheet of the action that has been called is imported to the test as an editable and local copy of data.

- In order to modify an existing external action you need to open the particular test where you have the action stored and make modifications there itself. 

- These modifications will be visible in all the tests that will call that particular function. 

- If you choose to go for the second option as mentioned above then the changes that you will make will apply to original data as well. 

Step by step procedure of how a call to an action can be inserted?

1. Go to insert menu, the select the “call to existing action” option and you will be provided with a list of actions. From that select “insert call to existing action” or you can also right click on any of the steps. The go for the action button and then click on “insert call to existing” option. Now a action properties dialog box pops up.
2. There is a browse button called “from test” and can be used to find the test that holds the action to be called. All the reusable actions in the test that you select are displayed in this action box.
3. From the action that is displayed select the action that is to be called and its type as well as description both are displayed if available. This type and description help you further in proper identification of the action that you wish to be called.  You can even set other properties of the actions by going to the “setting general action properties”.
4. Now you are done with setting the properties, decide on where the function has to be inserted. For inserting the function you are provided with two options namely:

a)   After the current step or

b)   At the end of the test

There is one thing to be noted which is that if the step that is in current selection is a reusable action from some another test, then the action call is added at the end of the test automatically.

5. Now the last step is to just clock on the OK button and you have your action inserted. This action can be moved to any other desired location by just dragging it to that position.

What are data driven tests and how they are created in WinRunner?

When you go for testing of your software system or application, it serves good if you check the performance of your software system or application with multiple sets of different data for some set of same operations. 

For doing so you can go for creating a data driven test! Let us see in detail what actually the data driven tests are and how you can create one in the winrunner. 

What are Data Driven Tests?

- Data driven tests cuts down on the difficulty of manually executing the same test over and over again. 

- The data driven test is created with a loop that iterates exactly the same number of times as there are sets of data to be implemented. 

- Say the loop executes 20 times, so in all these 20 iterations the loop executes with a different set of data and drives the test with it. 

- Since every time the test is driven by a different set of data, the test has been termed as the data driven test. 

- However, in order to make the winrunner run a data driven wizard, use parametrization which involves the linking of the data to the test script which it is to drive. 

- After parameterization, the data is stored in a table called data table. 

- It is up to you that whether you carry out this whole process on your own manually or you take the assistance of the data driver wizard. 

- Usually a non driven test consists of the following three steps:

1. Creation of a test
2. Execution of the test
3. Analyzation of the test results.

- In data driven testing there are two additional steps are there in addition to the above mentioned 3 steps. 

- These two extra steps lie between the creation of the tests and execution of the tests. 

- These two extra steps are as mentioned below:

1. Conversion of the test in to a data driven test and
2. Creation of a corresponding data table.

Stages involved in creation of data driven test

The below stated are all the stages that are involved in the process of data driven test creation:

1. Creation of a test
2. Conversion of a data driven test
3. Preparation of data table
4. Running the test
5. Analyzation of the test results.

- You cannot directly convert a test in to a data driven test. 

- For doing so, first it is required that you should create a basic test and then convert it in to a data driven test. 

- This basic test can be created by recording a test with only a single set of data. 

- Now this test is recorded by going to the insert menu, then selecting GUI check point, then “for single property” command.

- This is to ensure that the correct order is open. 

- This order can be later modified and updated. 

- There is an alternative to this, which is that you can create bitmap check points, bitmap synchronization points and data driven GUI check points. 

- Firstly, the values contained in the check point statements and recorded statements with parameters are replaced and a data table is created which stores the values that are to be assigned to the parameters. 

- This is the parameterization process. 

- The functions and statements are added to the test scripts so that they can be read from the data table.