Saturday, 24 September 2011

Descriptive Programming In QTP

Assume that we want to perform some operation on the objects which are not present in the object repository.In such kind of situation we can use descriptive programming.

There are two ways to write descriptive programs.
01. By giving the description in the form of string arguments
02. By creating the properties collection object for description

01.By giving the description in the form of string arguments:

This is the most commonly used method.We can directly describe an object in the form of property:=value pairs instead of describing the object name.

The general syntax for this type is TestObject("PropertyName:= PropertyName", "...","PropertyValue:= PropertyValue"). Where TestObject could be WebEdit, WinEdit etc.

Consider the following code. 

<input type = "textbox" name = "txtName" -->
<input type = "radio" name = "txtName" -->

So,the descriptive code for the above samples will be, Browser("aaa").Page("bbb").WebEdit("Name:="txtName","htmi tag:=INPUT").set "quicktestprofessional"
  
Browser("aaa").Page("bbb").WebRadioGroup("Name:="txtName","htmi tag:=INPUT").set "quicktestprofessional"

We can also distinguish the above two object by using their index. 

Browser("aaa").Page("bbb").WebEdit("Name:="txtName","htmi tag:=INPUT","Index:=0").set "quicktestprofessional"  ---> Represent the webedit object.
  
Browser("aaa").Page("bbb").WebRadioGroup("Name:="txtName","htmi tag:=INPUT","Index:=1").set "quicktestprofessional" --. Represents the radio button object.

We can determine the property,value pairs by using object spy.

* Navigate Tools > Object Spy
* Once selected select the "Test Object Properties" button
* Spy on the desired object
* From the properties list not down the property values to be used in test.

02. By creating the properties collection object for description

Properties collection also does the same as the property and value pairs. The only difference is it collects all properties of a particular object in an instance of that object.So, the object can be identified by that instance of the object instead of string arguments.

In this method first we need to create the empty description as follows.
Set oDesc = Description.Create

We need to use the properties name, value and regular expressing for an object.The syntax will be oDesc(html tag).value ="INPUT".

When we use a property name for the first time the property is added to the collection and when you use it again the property is modified. By default each property that is defined is a regular expression. 

Consider the following example,
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt.*”.

This would mean an object with html tag as INPUT and name starting with txt. Now actually that “.*” was considered as regular expression. So, if you want the property “name” not to be recognized as a regular expression then you need to set the “regularexpression” property as FALSE.

oDesc(“html tag”).value= “INPUT”
oDescc(“name”).value= “txt.*”
oDesc(“name”).regularexpression= “txt.*”

This is how we create a description. Now below is the way we can use it. Browser(“aaa”).Page(“bbb”).WebEdit(obj_Desc).set “quicktestprofessional”

Assume that we have more than one element in the same page.We can use the index property to differentiate the elements.Assume that we have 2 text boxes on the same page.In that case we can use the index property as follows.

Representing 1st text box:
oDesc("html tag").value ="INPUT"
oDesc("name").value ="txt"
oDesc("index").value ="0" 

Representing 2nd text box:
oDesc("html tag").value ="INPUT"
oDesc("name").value ="txt"
oDesc("index").value ="1" 

We can also use this method to identify the child objects on the same page.Assume that we have n-number of check boxes on the same screen.By using the collection properties we can loop through the n-number of objects. 

Set oCheckBox = Description.Create
oCheckBox("html tag").value ="INPUT"
oCheckBox("type").value ="checkbox"
Dim sCheckBox,aCheckBoxes
Set aCheckBoxes= Browser("aaa").Page("bbb").ChildObjects(oCheckBox)

'Loop through the checkboxes
For each sCheckBox in aCheckBoxes
 sCheckBox.set "ON"
Next

The above code will check all the check boxes present on the page. To get all the child objects we need to specify an object description.

When and Where to use Descriptive programming?

Below are some of the situations when Descriptive Programming can be considered useful:

1. One place where DP can be of significant importance is when you are creating functions in an external file. You can use these function in various actions directly , eliminating the need of adding object(s) in object repository for each action[If you are using per action object repository]

2. The objects in the application are dynamic in nature and need special handling to identify the object. The best example would be of clicking a link which changes according to the user of the application, Ex. “Logout <>”.

3. When object repository is getting huge due to the no. of objects being added. If the size of Object repository increases too much then it decreases the performance of QTP while recognizing a object. [For QTP8.2 and below Mercury recommends that OR size should not be greater than 1.5MB]

4. When you don’t want to use object repository at all. Well the first question would be why not Object repository? Consider the following scenario which would help understand why not Object repository
Scenario 1:
Suppose we have a web application that has not been developed yet.Now QTP for recording the script and adding the objects to repository needs the application to be up, that would mean waiting for the application to be deployed before we can start of with making QTP scripts. But if we know the descriptions of the objects that will be created then we can still start off with the script writing for testing
Scenario 2: Suppose an application has 3 navigation buttons on each and every page. Let the buttons be “Cancel”, “Back” and “Next”. Now recording action on these buttons would add 3 objects per page in the repository. For a 10 page flow this would mean 30 objects which could have been represented just by using 3 objects. So instead of adding these 30 objects to the repository we can just write 3 descriptions for the object and use it on any page.

5. Modification to a test case is needed but the Object repository for the same is Read only or in shared mode i.e. changes may affect other scripts as well.
6. When you want to take action on similar type of object i.e. suppose we have 20 textboxes on the page and there names are in the form txt_1, txt_2, txt_3 and so on. Now adding all 20 the Object repository would not be a good programming approach.

Wednesday, 21 September 2011

Recovery Scenarios In QTP

We may come across some unexpected errors or exceptions during our test case execution. Consider the following scenario. Assume that after every step of the execution, we need to print the result.So, we need to call the printer from our script. Assume that the printer is out of paper.Obviously we will get the  message "Printer Out of Paper" pop up. This is an unexpected behavior results in test cases failure. So, we should have a mechanism to handle these type of unexpected behaviors.To handle these type of unexpected behaviors we have recovery scenarios in QTP.

We can use "On Error Resume Next"  or "if step" in our script if we know the exact place in which the exception occurs every time based on the scenario.But sometimes we can't handle the above mentioned scenario directly in test cases. Because we don't know that the time taken by network  to respond when the printer is out of paper. By that time the script could have crossed the step which handles the unexpected behavior. So, our test case will fail. In such conditions,it's always better to use recovery scenarios.

The main important to remember when using the recovery scenarios are as follows.

Trigger Event: Trigger the event which causes the script execution interruption.For example, we can say that the pop up which displays the printer out of paper message.

Recovery Option: The operations to be performed to enable QTP to continue the script execution.As per our example, we need to clock on "OK" button in the pop up window which causes the script interruption.

Post Recovery Operation: The operation which represents the actions to be performed after recovery. It means that from which step script execution to be started. For example, we can restart the test execution from beginning or skip the step which causes interruption.

Recovery scenarios will be stored with the file extension ".rs".A recovery scenario file is a logical collection of recovery scenarios, grouped according to your own specific requirements. By default, QTP checks for recovery triggers when an error is returned during the run session. You can use the Recovery object's method to force QTP to check for triggers after a specific step in the run session. 
For the complete list of recovery scenarios go to QTP Documentation > Quick Test Advanced References > Quick Test Automation > Recovery Object.

Monday, 19 September 2011

Smart Identification In QTP

Sometimes the mandatory properties of an object can be changed during run time. So, QTP will enable to the Smart Identification mechanism to identify such kind of objects.

We can configure a set of properties in smart identification dialog box to identify the objects whose properties are changed during run time. Those properties are called as Base filter properties and Optional filter properties.QTP will automatically enable the smart identification mechanism if the selected object is unable to identify.

QTP uses Base Filter Properties and Optional Filter Properties to identify the objects. Base filter properties are the properties which can't be changed until the essence of the object is changed. Assume that a web link is changed from tag A is changed to some other tag Ex: B. So, we can't call both objects are same

Assistive properties are the properties which will be used by QTP if the mandatory properties are not enough to identify the objects. These properties will not be changed on a regular basis. QTP may use ordinal identifier to identify the objects if the base filter and assistive are not enough to identify the objects.

We can get more details about the smart identification from QTP help by reading the following topics.

  1. About Configuring Smart Identification
  2. Understanding the Smart Identification Process
  3. Reviewing Smart Identification Information in the Test Results
  4. Walking Through a Smart Identification Example
  5. Step-by-Step Instructions for Configuring a Smart Identification Definition

Thursday, 15 September 2011

Tips to become a good software tester

In this article am trying to give some tips for the software test engineers to be at their best.


01. Test engineers should be involved from the requirement phase of the project. They should understand the requirement of all modules in the project.
02. Based on the understanding of the module, the Test Engineer should implement some process.The same process should be followed by all the resources in the ream. If we do so, we can filter most of the issues at initial phase itself.
03. The test engineers can create some template to follow.They should force all resources in the team to follow the same template.
04. If there are any changes in the requirement the same should be updated in the testing document. It's always better to keep the back up of the document based on the old requirement. It'll not be useful if the requirement is changed. Still we can keep it.
05.Once the requirement is finalized divide the project into chunks. It'll be helpful to know which module have more priority than other module.
06. Once the project is divided into chunks, identify the impacted areas. It means that the issue in one module may impact the behavior of other module.So, those type of modules should be given high priority.
07. Then prepare test scenarios for each module first.Then we can write the test scenarios for the impacted areas.
08. Do the peer review as soon as the test scenarios are ready.It'll be helpful to clarify if there is any doubt. Then we can use the standard template to write the test cases.
09. Test cases should clearly describe the action to be done. Number of steps should be less as well as descriptive.Based on the functionality we can give the priority of the test cases as High,Medium, Low.
10.Once the test cases are ready we can match the cases with requirement to make sure that all modules has been covered.


11. The most important thing is identify the module which has the complex code with the help of developer.We have to give more attention to the specific modules.

Tuesday, 13 September 2011

Tips To Write Quality Test Cases

This article gives some basic ideas to write the complete test cases.
Before writing the test cases the tester should know the complete functionality of the module. Then only we can develop both positive and negative test cases.We can divide the test case relation as Test Scenario > Test Case > Test Steps.
Test Scenario: It comes directly from the requirements or userstory. It represents the list of test cases and often their sequences.
Test Case: It consists of the list of test steps need to be performed. And may linked to environmental situations, link to bugs etc.
Test Step: It represents the action to be performed and the expected result from the application.
So, as a tester, we need to make sure that the quality test cases are in place to test against the application and deliver it with high quality.
I am trying to give some of the tips to write quality test cases here. 


01. We need have one complete template to create the test cases. We can have template in the form of excel spread sheet or some customized tool.


02. Test cases should be descriptive and specific. The title of the test case should be short , concise and   descriptive. Test case should clearly define the purpose and scope of the operations.
03.Test cases should be reusable in many scenarios.


04.We should create both positive and negative test cases. So, it’s important to remember the order of test  cases. Positive test cases should cover the expected behavior of the application. In turn negative test cases should cover the un expected behavior of the application. So,it is always better to keep the relationship between the positive and negative test cases.


05.Test cases should be atomic in nature. Assume that the test case is too long and doing too much of dependency checks. It’ll be a nightmare for a tester to all dependency check each and every time and also reducing the tester’s motivation and vigilance.


06.We need to refactor the test cases. It means that we need to re write or update the test cases whenever there is a change in functionality. It should be strictly followed by all testers to make sure that the test cases are always matching or covering all functionalities in the project.


07.As a tester, we should always have the test data for the complex as well as easy test cases. The test data should be attached in the form of binary data along with the test cases.


08. We need to make sure that all required configurations are in place before executing the test cases. We can have a list of checklist to make sure that the required configurations are in place.


09.It’s always better to have the review with the peers as well as product analyst. It’ll help in big time to make sure that we are not missing anything.

Saturday, 3 September 2011

Expert View in QTP

This article explains the details about the expert view in QTP.
Creating new steps in a Test using Expert view.We can insert new step into QTP by anyone of the following ways.
01.Use "STEP GENERATOR"
02.Enter steps manually in expert view
03.Record steps on the AUT
04.Use the ACTIVE SCREEN
05.Enter the steps directly
Using Step Generator:Step Generator can be accessed through Insert> Step> Step Generator from the menu.Steps are organized according to three categories.Test Objects,Utility objects,Functions.To define a new step we need to complete Object or Library,Operation and Arguments fields.We can also insert the additional steps by selecting INSERT ANOTHER STEP checkbox and clicking on OK button.
Manual Entry of Steps:Steps can also be added directly to tests and components with the expert view.Expert view also provides Statement completion,Auto expand VBScript syntax,Content-sensitive help.
By Using Statement completion feature presents options for finishing the VBScript file.The feature useful in the following contexts.
01. When you type a class followed by a parenthesis.QTP displays the test  objects in the object repository  for that class.
02.When you type a object followed by a dot,QTP displays the child objects and methods for that objects.
03.When a method is typed QTP displays the arguments for that method.
Expanding VBScript Syntax:The AUTO EXPAND VBSCRIPT SYNTAX feature returns VBScript statements that match characters you typed.You trigger the feature by typing some initial characters and then pressing the space key.QTP looks for VBScript statements that match the initial characters you typed.If only one statement fits the criteria, that statement is entered automatically. If multiple options exist, a dialog is opened in which you select your choice.If the VBScript statement has a closing keyword as well as an opening keyword (e.g., FOR…NEXT) the closing keyword will also be entered automatically into the script.
Launching Context-Sensitive Help:QTP’s online help is context-sensitive. This means that the help page displayed will differ depending on where the cursor is.You can use context-sensitive help to retrieve the description of any object, method, or statement in your script.To open context-sensitive online help, place the cursor on the desired item and select HELP>QUICK TEST PROFESSIONAL HELP from the menu or type F1. The QUICK TEST PROFESSIONAL HELP window opens to a page describing the item you elected.
With Statement:The VBScript WITH statement allows you to perform a series of operations on the same object.By using the WITH statement, you can group related steps together to make the script easier to read.To convert a script so that sequential steps related to the same object are grouped together using a WITH statement, select EDIT>APPLY “WITH” TO SCRIPT from the menu.To return the script to its previous format, select EDIT>REMOVE “WITH” STATEMENTS  from the menu.
Basic Debugging:Once you have created the script for your test or component, you will need to debug it to ensure that it is free of errors.QTP provides debug features to help you perform each of the following:
Find syntax errors.Execute a script from a desired step,Add breakpoints,Execute single steps.
Finding Syntax Errors: QTP will check your script for syntax errors whenever you switch from the Expert View to the Keyword View. The SYNTAX ERRORS window opens, displaying the following information for each error found in your script:Action Name,Line,Description.To navigate directly to an error in your script, select the error and click GO TO ERROR.
Executing Steps from a desired step:The RUN FROM STEP option allows you to execute a QTP script starting from any step in the script.To use this option, place the cursor at the desired starting step and select TEST>RUN FROM STEP.Note: You will need to manually navigate the AUT to the state expected by the step in your script.
Adding Breakpoint:Breakpoints allow you to suspend a run session at a pre-determined place in the script in order to inspect the run-time state of your application.To set a breakpoint, place the cursor on the desired step and select DEBUG>INSERT/REMOVE BREAKPOINT. The breakpoint symbol is displayed in the left margin of the script.To remove the breakpoint, place the cursor on the step and select DEBUG>INSERT/REMOVE BREAKPOINT again.When you are done debugging, you can clear all breakpoints from a script by selecting DEBUG>CLEAR ALL  BREAKPOINTs.
Executing Single Steps:The step commands in the DEBUG menu allow you to execute a single step of a script. These commands are available once a run session has been paused.The commands are Step Into,Step Over,Step Out.

Friday, 2 September 2011

SQL Statements

This article explains the various statements available in SQL.


Data Retrival: SELECT
This statement is used to retrieve the data from the database.
Data Manipulation Language[DML]:INSERT, UPDATE, DELETE, MERGE
This statement is used to enter the new data,update the existing data, deleting the existing data and merging the data in the selected table of a database.So, these statements are called as Data Manipulation Language.
Data Definition Language[DDL]: CREATE,ALTER,DROP,RENAME, TRUNCATE
Sets up the database and removes the data from database.So, these commands are collectively known as Data Definition Language.
Transition Control: COMMIT,ROLLBACK, SAVEPOINT
These statements are used to manage the the changes made by DML statements.Changes to the data can
be grouped together into logical transactions.
Data Control Language [DCL]: GRANT,REVOKE

Gives or removes access rights to both the Oracle database and the structures within it. Collectively known as data control language.












Best Practices In Automation Testing

This article talks about many interesting things like what's the Case for Automated Testing, Why Automate the Testing Process?, Using Testing Effectively, Reducing Testing Costs, Replicating testing across different platforms, Greater Application Coverage, Results Reporting, Understanding the Testing Process, Typical Testing Steps, Identifying Tests Requiring Automation, Task Automation and Test Set-Up and Who Should Be Testing?.


The Case for Automated Testing
Today, rigorous application testing is a critical part of virtually all software development projects. As more organizations develop mission – critical systems to support their business activities, the need is greatly increased for testing methods that support business objectives. It is necessary to ensure that these systems are reliable, built according to specification and have the ability to support business processes. Many internal and external factors are forcing organizations to ensure a high level of software quality and reliability.

Why Automate the Testing Process?
In the past, most software tests were performed using manual methods. This required a large staff of test personnel to perform expensive and time-consuming manual test procedures. Owing to the size and complexity of today’s advanced software applications, manual testing is no longer a viable option for most testing situations.

Using Testing Effectively
By definition, testing is a repetitive activity. The methods that are employed to carry out testing (manual or automated) remain repetitious throughout the development life cycle. Automation of testing processes allows machines to complete the tedious, repetitive work while human personnel perform other tasks. Automation eliminates the required “think time” or “read time” necessary for the manual interpretation of when or where to click the mouse. An automated test executes the next operation in the test hierarchy at machine speed, allowing test to be completed many times faster than the fastest individual. Automated test also perform load/stress testing very effectively.

Reducing Testing Costs
The cost of performing manual testing is prohibitive when compared to automated methods. The reason is that computers can execute instructions many times faster and with fewer errors than individuals. Many automated testing tools can replicate the activity of a large number of users (and their associated transactions) using a single computer. Therefore, load/stress testing using automated methods requires only a fraction of the computer hardware that would be necessary to complete a manual test.

Replicating testing across different platforms
Automation allows the testing organization to perform consistent and repeatable test. When applications need to be deployed across different hardware or software platforms, standard or benchmark tests can be created and repeated on target platforms to ensure that new platforms operate consistently.

Greater Application Coverage
The productivity gains delivered by automated testing allow and encourage organization to test more often and more completely. Greater application test coverage also reduces the risk if exposing users to malfunctioning or non-compliant software.

Results Reporting
Full-featured automated testing systems also produce convenient test reporting and analysis. These reports provide a standardized measure of test status and results, thus allowing more accurate interpretation of testing outcomes. Manual methods require the user to self-document test procedures and test results.

Understanding the Testing Process
The introduction of automated testing into the business environment involves far more than buying and installing an automated testing tool.
Typical Testing Steps: Most software testing projects can be divided into general steps

Test Planning: This step determines like ‘which’ and ‘when’.
Test Design: This step determines how the tests should be built the level of quality.
Test Environment Preparation: Technical environment is established during this step.
Test Construction: At this step, test scripts are generated and test cases are developed.
Test Execution: This step is where the test scripts are executed according to the test plans.
Test evaluation: After the test is executed, the test results are compared to the expected results and evaluations can be made about the quality of an application.
Identifying Tests Requiring Automation
Most, but not all, types of tests can be automated. Certain types of tests like user comprehension tests test that run only once and tests that require constant human intervention are usually not worth the investment incurred to automate. The following are examples of criteria that can be used to identify tests that are prime candidates for automation.

High path frequency – Automated testing can be used to verify the performance of application paths that are used with a high degree of frequency when the software is running in full production. Examples include: creating customer records.

Critical Business Processes – Mission-critical processes are prime candidates for automated testing. Examples include: financial month-end closings, production planning, sales order entry and other core activities. Any application with a high –degree of risk associated with a failure is a good candidate for test automation.

Repetitive Testing – If a testing procedure can be reused many times, it is also a prime candidate for automation

Applications with a Long Life Span – If an application is planned to be in production for a long period of time, the greater the benefits are from automation.

Task Automation and Test Set-Up
In performing software testing, there are many tasks that need to be performed before or after the actual test. For example, if a test needs to be executed to create sales orders against current inventory, goods need to be in inventory. The tasks associated with placing items in inventory can be automated so that the test can run repeatedly. Additionally, highly repetitive tasks not associated with testing can be automated utilizing the same approach.

Who Should Be Testing?
There is no clear consensus in the testing community about which group within an organization should be responsible for performing the testing function. It depends on the situation prevailing in the organization.

Thursday, 1 September 2011

Insert Call To Copy,Insert Call To Existing Action

Steps to Insert Call to Copy in QTP:
  • Navigate to Expert View
  • Right click > Action > Insert Call To Copy option
  • Select the action to be copied
  • Observe that a new action is created in the current test
This can be used for Resuable and Non Reusable action.
  • If the copied action has checkpoints, parameters, data table plus any definedparameters , everything will be copied into the current test
  • If the copied action has per action repository /shared object repository, that also will be copied into the current test
  • Even though the copied action is reusable in actual action it becomes non re usable in the current test
  • When the copied action has shared repository, the copied action will also use the shared object repository
  • Make sure that the shared object repository contains all objects referenced in copied action before running the test
  • If necessary make the changes in the repository
  • Once the action is copied into the test, we can delete, add or modify the action just as we could with any other non reusable action
  • When the changes are done to this action after insertion, it affects only this action
  • Any changes we make to the original action will not affect the copied action
Steps to use "Insert Call To Existing Action":

  • Go to expert view of the action
  • Right click and Select Action > Insert Call to Existing option
  • Observe that a window is opened
    • You can view the list of re usable/shared actions by clicking the ... button in the newly opened window
    • Observe that the above dialog creates RunAction "Selected Action", oneIteration code
    Note:
    • We can create the above code manually in our testing without following the above mentioned steps
    • Deleting the code will not delete the link between the actions
    • To delete the link between the actions, we should use the Keyword view.

 
Back To Top