Software Automation Testing Benefits

Software Test Automation is the use of software to execute the tests. Test Automation involves automating manual execution of test cases for enhancing speed and reliability.

Automation Testing is nothing but simulation of Manual Actions. Automation testing includes an additional activity of writing test scripts after Test case Development.

1. Saves time during the test execution: The execution of an automation test case( test script) is faster compared to the manual execution of a test case.

2. Execution of tests in un-attended mode: Once the entire automation suite( the automated test cases of the manual test case suite) is ready for the execution, the automation suite can be executed in an un-attended mode( human attendance is not required for the entire execution), if the framework is designed in such a way. You can use the human brain for better innovative testing to improve the productivity of the overall testing process.

3. Consistency of test execution: When you execute manual regression suite several times, it is a general human tendency that we get bored of executing the same test cases time and again and because of which we may miss to execute one or many steps which may finally lead to an undetected bug!!! But, if you execute the automation suite, may be for 1 time or 100 times, it executes with the same efficiency and effectiveness.

4. Reducing cycle time of regression test cycles.

5. Data Driven Testing: This feature helps to parameterize the data in the script. This helps to get rid of hard coding of the values required for the test. Also, this feature helps in the concept of Retesting i.e, re-execution of the test/functionality with multiple sets of input data.

6. Coverage: Test coverage can be increased with the help of Automation. In real-time, testers have very less time to test n number of features. This makes the testers limit their scope in testing the application/products by determining the priority of the feature/functionality to be tested. But, that limitation can be overcome to a great extent with the help of automation.

With the above benefits of automation, automation has actually become a part of the entire life project life cycle and more importantly Automation life cycle has become an important subset of the entire Test life cycle. To reap good benefits from Test Automation to the entire project, you need to have good planning and coordination from the Development team, Manual Testing team and the Automation team.

Pros & Cons of Automation Testing

• If you have to run a set of tests repeatedly, Test Automation is a huge win for you.
• It gives you the ability to run automation against code that frequently changes to catch regressions in a timely manner.
• It gives you the ability to run automation in mainstream scenarios to catch regressions in a timely manner.
• Aids in testing a large matrix(different languages on large OS platforms).
• Automated tests can be run at the same time on different machines, whereas manual tests would have to be run sequentially.
• Automation Testing takes more initial investment to design and develop Automation framework and automation test scripts.
• Can't automate visual References. For example the look and feel of the application should be done manually.
• What you automate depends on the tools you use. If the tools have any limitations, those tests are manual.
• It may not be worth automating if the repetition of test case execution is minimal.
  

QTP checkpoints tutorial

A checkpoint enables you to identify whether the Web site or application under test is functioning correctly or not by comparing a current value for a particular property with the expected value for that property.

After we add a checkpoint, QuickTest adds a checkpoint to the current row in the Keyword View and adds a Check CheckPoint statement in the Expert View.

By default, the checkpoint name receives the name of the test object on which the checkpoint is being performed. We can change the name of the checkpoint if
needed.

Types of Checkpoints:

1. Standard checkpoint
   
   
2. Image checkpoints


3. Bitmap Checkpoint


4. Table checkpoints


5. Accessibility Checkpoint


6. Text Checkpoint


7. Page Checkpoint


8. Database Checkpoint


9. XML checkpoints

Standard checkpoints allow checking the object property values in the Web site or application under test. Standard checkpoints evaluate (compare) the expected values of object properties captured during recording to the object's current values during a run session. For example we can check that a radio button is activated after it is selected. Standard checkpoints are supported for all add-in environments.

Standard checkpoints can be used to perform checks on

Images,
Tables,
Web page properties, and
Other objects within your application or Web site.

Standard checkpoints can be created for all supported testing environments (as long as the appropriate add-in(s) are loaded).

Image checkpoints allow you to check the properties of an image in the application or Web page. For example, you can check that a selected image's source file is correct or not. An image checkpoint can also be created by inserting a standard checkpoint on an image object. Image checkpoints are supported for the Web add-in environment

With Bitmap Checkpoint we can check an area of a Web page or application as a bitmap. While creating a test, we have to specify the area to check by selecting an object. An entire object or any area within an object can be checked. Bitmap checkpoints are supported for all add-in environments

By adding table checkpoints to the test, we can check the content of tables displayed in the application. For example, we can check that a specified value is displayed in a certain cell. Certain environments also support checking the properties of the table object. For example, a check that a table has the expected number of rows and columns. A table checkpoint can also be created by inserting a standard checkpoint on a table object.

Accessibility Checkpoint recognizes areas of your Web site that may not conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines.For example, check if the images on a Web page include ALT properties, required by the W3C Web Content Accessibility Guidelines. Accessibility checkpoints are supported for the Web add-in environment

QuickTest can check that a text string is displayed in the appropriate place in an application or on a Web page with Text Checkpoint. Text checkpoints are supported for the Web add-in environment, plus some Web-based add-in environments

Page Checkpoint checks the features of a Web page. For example, you can check how long a Web page takes to load or whether a Web page contains broken links. A page checkpoint can also be created by inserting a standard checkpoint on page object. Page checkpoints are supported for the Web add-in environment

The contents of a database accessed by your application can be checked by Database Checkpoint. Database checkpoints are supported for all add-in environments

By adding XML checkpoints to your test, you can check the contents of individual XML data files or documents that are part of your Web application. The XML Checkpoint option is supported for all add-in environments.

HP QTP recording modes

The default mode of recording is the Normal recording mode. There are other

recording modes also like Analog Recording or Low Level Recording. Normal mode is the default and takes full advantage of the QuickTest test object model, as it recognizes the objects in the application regardless of their location on the screen.

Analog Recording : Exact mouse and keyboard operations are recorded in relation to either the screen or the application window. In this QTP also records and tracks every movement of the mouse for example, recording a signature produced by dragging the mouse. Analog Recording steps are not editable from within QuickTest.

Low Level Recording : At any time, if an environment or on an object not recognized by QuickTest, use Low Level Recording. It records at object level and records all run-time objects as Window or WinObject test objects. QuickTest records all parent level objects as Window test objects and all other objects as WinObject test objects.

Each step recorded in Low Level Recording mode is shown in the Keyword View and Expert View.

All the three modes of recording can be used in a single test e.g. we can switch to either Analog Recording or Low Level Recording in the middle of a recording session for specific steps and then return to normal recording
mode.

Analog Recording and Low Level Recording require more disk space than normal recording mode.

Use Analog Recording when :

The actual movement of the mouse is what you want to record.

Recording in Analog mode can be relative to the screen or relative to a specific window (see user guide for detail)

In Analog Recording a separate file is saved and stored with the action.

In Analog Recording mode, QuickTest adds to your test a RunAnalog statement that calls the recorded analog file.

Use Low Level Recording when :

Environments or objects not supported by QuickTest.

Exact location of the operation on your application screen is necessary. in normal mode QuickTest performs the step on an object even if it has moved to a new location on the screen.

If the location of the object is important to your test, switch to Low Level Recording

Parameterizing Tests in QTP (QuickTest Professional)

By replacing fixed values with parameters QuickTest enables you to enlarge the scope of a basic test. It is known as parameterization, greatly increases the power and flexibility of a test. A parameter is a variable that is assigned a value from an external data source or generator. Values in steps and checkpoints and also the values of action parameters can be parameterize.

Parameters let us check how the application performs the same operations with multiple sets of data.

There are four types of parameters in QTP:

Test/action parameters: Test parameters make possible for us to use values passed from the test. Action parameters enable us to pass values from other actions in your test. To use a value within a specific action, the value must be passed down through the action hierarchy of the test to the required action. We can then use that parameter value to parameterize a step in the test. For example, suppose that we want to parameterize a step in Action3 using a value that is passed into the test from the external application that runs (calls) the test. We can pass the value from the test level to Action1 (atop-level action) to Action3 (a nested action of Action1), and then parameterize the required step using this action input parameter value (that was passed through from the external application). Alternatively, we can pass an output action parameter value from an action step to a later sibling action at the same hierarchical level. For example, suppose that Action2, Action3, and Action4 are sibling actions at the same hierarchical level, and that these are all nested actions of Action1. We can parameterize a call to Action4 based on an output value retrieved from Action2 or Action3. We can then use these parameters in the action step.

Data Table parameters allow us to create a data-driven test (or action) that runs several times using the data that we supply. In each repetition, or iteration, QuickTest uses a different value from the Data Table.

Environment variable parameters allow us to use variable values from other sources during the run session. These may be values that we supply, or values that QuickTest generates for us based on conditions and options we choose.

Random number parameters Enable us to insert random numbers as values in your test.

Values in steps and checkpoints can be parameterized while recording or editing the test.

The values of object properties can be parameterized for a selected step.

The values of the operation (method or function arguments) defined for the step can also be parameterized.

When the value of an object property for a local object is parameterized, we are amending the test object description in the local object repository. Therefore, all occurrences of the specified object within the action are parameterized.

Parameterizing the value of a checkpoint property enables us to check how an application or Web site performs the same operation based on different data.

QTP 10 keyword view

In QTP (QuickTest Professional) we first of all record a test, then run a test and then analyze the results, but before running the test we can also enhance it with checkpoints and parameters.

First of all let's talk a little about keyword view in QTP and then we will talk about recording in QTP and then we will move on to other things.

After recording all the operations, QuickTest displays them as steps in the Keyword View, and generates them in a script (in an Expert View).

In the keyword view there are 4 visible columns –

(For other valuable information on below points please see QTP user guide pg 92 and pg 114)

Item The item on which we want to perform the step and it can be a test object, utility object, function call, or statement. This column shows a hierarchical icon-based tree. The highest level of the tree is actions, and all steps are contained within the relevant branch of the tree.

Operation The operation (methods or functions) to be performed on the item selected in the Item column, for example, Click or Select.

Value The argument values for the selected operation, for example, the mouse button to use when clicking the image.

Documentation It is a Read-only auto-documentation of what the step does in an easy-to-understand sentence, for example, Click the "findFlights" image.

Assignment The assignment of a value to or from a variable for example, Store in cCols would store the return value of the current step in a variable called cCols so you can use the value later in the test. This column is not visible by default.

Comment Any textual information you want to add regarding the step. This column is also not visible by default.

Actions in HP QTP software

Actions break up the test into logical sections/units such as specific activities that we perform in our application.

When we create a new test, it contains a call to one action. By breaking up the tests into calls to multiple actions, we can design more modular and well organized and professional tests. An action has its own test script, containing all of the steps recorded in that action, and all objects in its local object repository. An action is stored with the test in which you created it.

If you create a test in which you log into the system (email), check inbox, and then log out of the system (email), your test might be structured as shown—one test calling three separate actions:

Test 1		Actions stored with Test 1
Call to action 1	--->	Action 1(Logging In)
Call to action 2	--->	Action 2(Checking Inbox Mails)
Call to action 3	--->	Action 3(Logging Out)

Actions make it possible to parameterize and iterate over specific elements of a test. They also make it easier to re-record steps in one action when part of your application changes. For every action called in the test, QuickTest creates a corresponding action sheet in the Data Table so that we can enter Data Table parameters that are specific to that action only.

Three types of actions are:

Non-reusable action This non reusable action can be called only once and that too in the test with which it is stored.

Reusable action Reusable actions are like functions in any programming language. If there is a process that needs to be included in several tests, we can record, modify, and enhance the steps of the process and save them in a reusable action. Then we can call the action from other tests, rather than recording, modifying, and enhancing the same steps each time. It can be called several times by the test with which it is stored (the local test), as well as by other tests.

Deleting a reusable action that is called by other tests will cause those tests to fail.

External action is a reusable action stored with another test. External actions are read-only in the calling test, but we can choose to use a local, editable copy of the Data Table information for the external action. When a call to an external action is inserted, the action is inserted in read-only format

We can create an additional call to any reusable or external action in the test by pressing CTRL while we drag and drop the action to another location at a parallel (sibling) level
within the test.

By default, new actions are non-reusable. Each action created in a test can be marked as reusable or non-reusable.

When we run a test with multiple actions, the test results are divided by actions within each test iteration so that we can see the outcome of each action, and can view the detailed results for each action individually.

If you expect other users to open your tests and all actions in your tests are stored in the same drive, you should use relative paths for your reusable actions so that other users will be able to open your tests even if they have mapped their network drives differently.