HP QTP Experts - Here is a Great Opportunity for You
Boost up Your Earnings !!!!

SoftwarTestingGenius Team is looking for Couple of Experts on QTP 11.0 for being on our panel of Online-Trainers for imparting training to students aspiring to learn & get certified on QTP 11.0. Tester Friends having good expertise on QTP & flair for teaching On-line - Write to us at software.testing.genius@gmail.com for full details on training & lucrative earnings.
******************************************************************

"Full Study Material For ISTQB - Foundation and All 3 Advanced Level Certification Exams" ******************************************************************
Tips to Optimize HP QTP 11.0 Scripts to Yield Better Performance

We use Automated-testing tools to optimize our manual testing processes. But in order to reap full benefits of any automated testing tool, we must know the complete ins and outs of the tool otherwise it would be a huge waste of money spent on automation. We have to learn the automation tool very thoroughly. We also need to learn the language of the automation tool to do coding more effectively and efficiently. I believe that a software testing tool is as good as the person who is actually using it.

I have been getting so many emails from my esteemed readers asking about HP QuickTest Professional tutorials, QTP tips and tricks etc. Some readers even complain that their QTP scripts are too slow to execute. This time I decided to write a post on how to use QTP more effectively which means how to make our QTP scripts perform better. In order words, this post will throw light on some points, which will optimize your QTP scripts.

Some of the QTP optimization tips can be:

Tip – 1: You should not use hard coded wait statement until absolutely necessary. Instead of the wait statement, you should use either exist or synchronization (sync) statements. The wait statement waits for the number of seconds, which have been provided. For example using wait(5) will wait for 5 seconds even if the browser gets into a ready state even after 2 seconds which means a waste of 3 seconds. Imagine how much time would be wasted if you have say 10 wait statements per script and you are running a batch of 500 scripts. A better alternative is using sync or exist statements for example:

Browser("").Page("").Sync

var=Browser("").Page("").Exist(2)

Programming remains the biggest & most critical component of test case automation. Hence designing & coding of test cases is extremely important, for their execution and maintenance to be effective.

Seven fundamental attributes of good automated test cases, as per the following picture are being described below:

1) Simplicity: The test case should have a single objective. Multi-objective test cases are difficult to understand and design. There should not be more than 10-15 test steps per test case, excluding the setup and cleanup steps. Multipurpose test cases are likely to break or give misleading results. If the execution of a complex test leads to a system failure, it is difficult to isolate the cause of the failure.

2) Modularity: Each test case should have a setup and cleanup phase before and after the execution test steps, respectively. The setup phase ensures that the initial conditions are met before the start of the test steps. Similarly, the cleanup phase puts the system back in the initial state, that is, the state prior to setup. Each test step should be small and precise. One input stimulus should be provided to the system at a time and the response verified (if applicable) with an interim verdict. The test steps are building blocks from reusable libraries that are put together to form multi-step test cases.

What exactly constitutes a good requirement is always subjective to some degree, but in most cases, as software testing engineers you will know a good one when we see it. You shouldn’t be concerned with less than perfect requirements as long as you understand them and know how they’re understood by the stakeholders and project team - and you can test them accurately.

Once requirements have been received by the testing team they can be used for identifying and writing tests. As the process of identifying and creating tests begins, it quickly becomes apparent whether or not requirements are good enough, since the major part of identifying and writing tests is gaining an early understanding of the requirements.

Now the two questions arise

1) What should be done when requirements aren’t available at all?

2) What should be done when requirements are available but are substandard?

What should be done when requirements aren’t available at all?

Best solution is: Be Proactive & Anticipate Requirements