In any automation certain errors might happen due to environmental issues. Such issues are very hard to debug as there may not be a trace available to handle such errors.

In this blog i will be introducing few environmental problems with appropriate solution available in QEngine,

1. Browser Cache:
   While loading a requested page browser may load the page from the browser cache instead of requesting it from the server. This may cause any functionality breakage, due to which the test cases may result in failure. 
   
   In the above case, if the requested page is got from the server, the above failure mat not have happened. 
   
   Solution:
   In QEngine there is a setting available to clear cache before starting the playback.
   To configure the above setting goto, Suite->Settings->Replay Settings and enable the checkbox for Clear browser cache before starting the playback.
   
   With the above settings we can minimize the error occurring due to browser cache.
   
   
2. Cookies:
   Cookies are the state identifiers sent with the request to the server from the browser. Browsers will store the cookies of the previous visit to use it next time when the server is requested. If there is any cookie of the expired server session present in the browser, then it will cause the wrong page to load in the browser. This may cause any functionality error, thus the test case will result in failure.
   
   In the above case, if the cookies were not present for the server domain, then these problem may not happen.
   
   Solution:
   In QEngine there is a setting available to clear cookies for the configured domain from the browser.
   To configure the above setting goto,Suite->Settings->Replay Settings and enable the checkbox for Clear browser cookies for and configure the server domain name in the textbox.
   
   With the above setting the we can minimize the error occuring due to cookies.
   
   

Here i am going to discuss about the new recording option in QEngine which actually incorporates Recording / Playback and Manual Scripting.

In Record / Playback type of script authoring, normally the element data will be stored in a external Map file, and during playback the play engine will read the map file and fetch the required data from it and use it for identification in the DOM. In this mode, the tester will not be involving in the scripting much. But if there is any change in the GUI, then it will be difficult for the user to identify the property changed and modify the same in the map file.

In Manual Scripting, you have to author the script with some dynamic functions, where all the required element data will be stored in the script file itself. So, it will be clear to the user, which element is being handled and flow of script. In this mode the user has to author the script manually knowing all necessary data for element identification in the DOM. If there is any GUI changes, it will be easy for the tester to modify the details in the script itself.

QEngine introduced a new recording mode called Expert Mode. Using this you can record the script in manual authoring mode, thus the object repository (Map file) will not be required. Actions will be recorded with dynamic functions and all required element data will also be present in the script file itself.

This recording mode eases the tester from knowing all the element identification properties and manually authoring the scripts. The power of Manual Script Authoring can be attained in recording mode also.

While start the recording itself you can choose to record in Record in Expert Mode or while creating the new script check the check box for Record in Expert Mode.

Hope this will be helpful for you to understand and automate your scripts quickly in the Expert Mode Recording.

Regards,
Raghavan
srinivasar at zohocorp dot com

Hi All,

We have published Performance Testing Evaluation Guide in the QEngine website in the below link,

http://www.manageengine.com/products/qengine/web-performance-evaluation-guide.html

or You can download it as PDF from the below link,

http://www.manageengine.com/products/qengine/web-performance-evaluation-guide.pdf

Raghavan

Hi All,

We received a good question from one of our customer. The question is

Why should i parameterize the transactions in Load Testing ?

It is indeed a nice question. Actually his question is, i am not configuring those parameters while recording. Then how do i know what are the parameters it takes and its value.

Here is the solution. Yes the user don't know what are all the parameters it takes while submitting a page. Hence in QEngine we introduced a feature called Auto parameterization.

What is Auto Parameterization ?

Auto parameterization facilitates to automatically extract the parameters from the associated reference page and use it while submitting the particular page to the server.
This is what happens while submitting the page while browsing in the browser.

This feature will work perfectly for most cases.

But for some cases the server may require unique value for each virtual user. In those cases, you may be required to parameterize value for the username, password and those parameters which you input during recording in the browser.

For this QEngine easy to use user interface namely Parameterization screen. It will list all the parameters for each URL separately, thus user can easily configure the value for the parameters. QEngine provides various options to parameterize such as Dataset / Cookie / Java script / Previous Response Content / HTML Element / Random values etc.

To know more on parameterization look at the below URL:
http://www.manageengine.com/products/qengine/performance-testing.html

There are still more improvements can be done in parameterization. This will happen in future QEngine releases.

Raghavan


[/b]

Recently we received a query from a customer how could i check if the particular element is displayed in the web page or not.

We suggested them to use doesElementExist function for the above query. But in her case it always returned the Success. So we analyzed the problem and found the element she is referring is exist in the webpage, but its display property is toggled to show / hidden the element in the web page. If it is shown then the display property is block. If it is hidden display property is none.

Hence we thought to suggest her to use styleCheckInfo where it will validate the display property of the particular element and tell you whether the element is displayed or hidden in the web page.

Very recently in QEngine we given customization option to retrieve the style properties of the element from the web page. It will be huge to retrieve all the style properties of an element from the web page. Hence we thought to give the option to the user so that he can define whatever the properties he is interested in.

Hence under Recorder Settings we have given an option to define the style properties he interested to retrieve from the web page.

Coming back to the problem,

To validate an element is hidden in the web page use the following function,

styleCheckInfo("","display","none")

To validate an element should be visible in the web page,

styleCheckInfo("","display","block")

Hope this will be helpful to validate the element presence in the page.

Raghavan

Dear All,

We are pleased to announce the release of QEngine 7.0.

There are lot of new features added in this release.

Main Highlight of this release is Automation support in IE 8 and Firefox 3.0 browsers.

Find more at what's new.

Download QEngine 7.0 and let us know your feedback.

Raghavan

QEngine has the feature namely "Report Javascript Error in Reports", using which javascript arising in the web applications can be reported in the QEngine reports.

To configure to report the javascript errors follow the below instruction in QEngine,

Go to Settings page
Choose Exception Handling tab
Check the checkbox for "Report Javascript Error in Reports" and Apply the changes.

Now during playback if there is any javascript error arise, it will be notified in the reports.

Thanks & Regards,
Raghavan

One of the powerful feature of QEngine WebPerformance Testing is the ability to automatically extract the request parameters from the previous response to use it in the next request. Hence any kind of dynamic parameters can be extracted automatically by QEngine.

In Web Performance Testing, the transaction with the web application will be recorded as URL with the associated parameters.The parameters may contain SessionID / VIEWSTATE variables, which will be used to maintain the session. These parameters will change time to time. These dynamically changing values can only be taken by parsing the response content of the previous request or from cookies.

With QEngine Auto parameterization option, QEngine will automatically parse the response content of the last request and extract the required parameter values and use it in the subsequent request. This will reduce the burden of parameterizing each and every request parameter manually.

Hence you may required to parameterize only the needed parameters, if required.

Regards,
Raghavan

QEngine does have a built-in feature to automatically recover from any of error scenario during regression test execution.

The feature is explained below,

Error Recovery settings is used in regression playback only. During script creation stages you may run script one at a time or maximum a module of script. But when you move the script in to regression mode you may want to execute all the scripts present in the suite in a single night. Assume you have some 500 scripts in your suite. In that case, if the script is continuously executed the performance of the system may be degraded. This may lead to failures / system hang up / delay in script execution. To overcome such problem in QEngine , it has "Error Recovery" option.

In "Error Recovery", all the browser for playback will be closed and reopened after playing back certain number of scripts. The number of script after which the browser should close can be configured. By doing this the memory foot print of the browser will be nullified and hence the playback will be fast and successful.

In another case, if the browser goes unresponsive / crashes during playback and does not respond to any commands, QEngine has a mechanism, which will terminate the browser process and restart the regression from the point at which script it crashed. You can also configure to rerun the script where it went unresponsive or start from the next script from the one in which it crashed. The unresponsiveness of the browser will be determined by a timeout value which is configurable. If the browser does not respond to QEngine within the configured timeout value then QEngine will assume the browser is crashed and close the browser process and restart the regression.

This is a powerful mechanism which will allow QEngine to use the System resource efficiently, hence the test can be completed as scheduled. This way the time to market the product will be improved.

Raghavan

Another scenario where QEngine scripts can be efficiently utilized is discussed below.

Scenario 1,

You have your application got installed in a test machine and automated the application using QEngine. In case you move your application to a new high end test machine then the automated scripts created against the old test machine goes unusable, as the scripts recorded will refer to the old test machine which is no longer available.

Scenario 2,

You have your application running over HTTP protocol and automated the application using QEngine. After automation you are upgrading your server to secured HTTPS protocol. In this case also the automated scripts goes unusable as the scripts recorded will refer to HTTP protocol as recorded, rather than the latest changes to HTTPS.

To overcome this, QEngine has a feature namely Host Port Settings. Using this option you can configure the machine name / port /protocol changes in the Host Port Editor. So that QEngine will automatically substitute the new test machine name / port / protocol in place of the recorded one.

To configure the host port settings, goto Settings -> Host-Port Settings and enable "Use Host-Port Configuration" and click on "Host-Port Editor" link. This will open "Host Port Editor", click on "New" button to create new Host Port Configuration. On creating new Host Port configuration it will list all the host name / port /protocol details recorded in the script in the suite. You should configure change host / port /protocol appropriately against each host listed in the editor.

This will enable the tester to utilize the same script without re-recording, even though the host / port / protocol of the application under test changes.

Thanks
Raghavan