Explain the check points in QTP? In how many ways we can add check points to an application using QTP?

Check points in quick test professional have always proved to be an efficient tool. In this article, we discuss exclusively about the check points in quick test professional and the ways in which the check points can be added to an application with the help of quick test professional. 

What is Check Point? How it is added to an application?

- Check point can be thought of as a point to confirm or verify whether the application under test or AUT is working properly or not. 

- This is verified by making comparisons between the current value of some property and the expected value of the same property decided earlier. 

- Whenever a check point is added by the user, an equivalent check point is added by the quick test professional to the present row in the key word view as well as a “check check point” statement is added to the expert view. 

- The name of the test object also serves as a name for the check point that has been added to it. 

- The check points can be added via an active screen by placing the cursor on the desired location and clicking the insert standard check point option. 

Types of Check Points

It is on the basis of this expected value that the check points have been classified in to various types as described below:

1. Page check point: 

- This check point is the check point that is created exclusively for a web page. - This check point keeps a count of all the images and links present on that particular web page. 

- Another purpose for which page check point is used for checking the time taken by the web page to load fully i.e., the load time.

2. Bitmap check point: 

- This check point is the check point that helps in checking of the bitmap of either a full web page or an image. 

- Two images are provided to this check point, one the actual image and the other one expected image. 

- These two images are compared pixel by pixel by the bit map check point.

3. Image check point: 

- This check point is used for keeping a check on certain properties belonging to a web page such as the source file location of the image. 

- However, being a image check point, it cannot check pixels of an image like a bitmap check point does.

4. Text check point: 

- This check point is the check point that is employed in checking the expected text in a web application or web page. 

- This text may belong to a specific region of the text displayed or application under test.

5. Accessibility check point: 

- This check point verifies whether or not the accessibility standard of the application under test matches with the accessibility guidelines laid down by the W3C or world wide web consortium for information systems and technology which are web based.

6. Data base check point: 

- This check point performs the task of generating a query while the recording is in progress. 

- The values stored in the data base serve as expected values. 

- This query is executed during the run time to obtain the actual value which is then compared with the expected value.

7. Table check point: 

This check point is the one that is used for checking various table properties such as cell width, row width and so on.

8. XML check point: 

This check point is the one that is used to verify the following:

a)     XML schema

b)     XML data etc.

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.

Inventory Analysis - an activity involved in software re-engineering process model.

The software re- engineering process model over the years has proved to be a very effective process in bringing the poorly maintained and controlled code to an acceptable standard. This model consists of the below mentioned 5 steps:

1. Inventory analysis
2. Document reconstruction
3. Reverse engineering
4. Code re- structuring
5. Data re- structuring
6. Forward Engineering

In this article we have discussed about the first step of the process i.e., inventory analysis in detail. 

Characteristics of Inventory Analysis

- It is obvious for every organization to maintain an inventory of all the software systems or applications it has developed whether they are active or not.

- An inventory is like a spreadsheet containing details of the software system or application against its name. 

- In inventory analysis, the software systems and applications are sorted out on the basis of the following criteria:

1. Business criticality
2. Longevity
3. Current maintainability and
4. Local criteria

- This step of the software re engineering process model helps the team to identify what all the software systems or applications require to be re- engineered.  

- Firstly, a table is build that lists all the software applications.

- After this a list of criteria is established on the basis of the criteria like few of which have been mentioned below:

1. Name of the software system or application.
2. Year of its creation.
3. Number of changes or modifications it had gone through since its creation.
4. Effort applied in making those modifications.
5. Effort applied in making the last of the modifications.
6. Date on which the last modification was made.
7. The systems in which the application now resides.
8. Other applications with which this application shares the interface.

- The primary purposes of this step is prioritizing all of them and analyze them so as to select the candidates for re- engineering. 

- The steps for the creation of an effective inventory are:

1. Preparing for data collection
2. Collecting the data
3. Deciding the criteria
4. Allocation

- It has not been wrongly said that “well begun is half done” since the organization may have to suffer a huge set back if it chose wrong candidates for re- engineering. 

- So selecting the candidates for re- engineering during the stage of inventory analysis holds importance. 

- The inventory analysis is a very generic process.

- The inventory analysis looks up with the details of all small and big aspects of the software systems and applications and therefore it becomes easy to select which candidates really need re- engineering.

- Usually the software systems or applications which have not been updated since a long time and are no more accepted and are undocumented are given the first priority.

- Such software systems and applications often have documentation associated with them that is either not updated or relates to the previous versions of the particular software system or application. 

- Problems with the selected candidates are identified and they are carried forward to the next step of the software re- engineering process model. 

- Before you start the restructuring of the code it is necessary that the objectives of the re- engineering are defined. 

- Re- engineering actually consists of 11 steps but they are shortened down to 5 major steps. - The detailed steps are:

1. Identifying the existing documentation
2. Verifying the identified code
3. Familiarising with the existing software
4. Identifying the re- engineering requirements
5. Drawing up the re- engineering plan
6. Producing a test plan, test script and test data.
7. Producing test results for original software and the ported version.
8. Restructuring the code
9. Testing the code
10. Updating the documentation