1. You can use the “DataTable.Export” method or “DataTable.ExportSheet” method to literally create a new .xls file of the workbook or specified worksheet, and have this new file saved in your file system (locally or on the network).  With this approach you can then use that datatable/spreadsheet however you want including importing it into the permanent datatable attached to the test script if you want.
   
   
2. Also keep in mind that your Test Results Report will show you the data used and created during the test run.  You can view this in the “Data Table” in the test report itself.
   
   You can then export that data into an external file too, from the report.  The steps are slightly different depending on the version of QTP you are using, but from QTP v11 you would simply select “File > Export to File…” and then select “Data Table” from the “Report type” drop-down list.  When you click the “Export” button you can then specify a new name and location for the data file (.xls).  This will export ALL the data in the datatable (all the worksheets will be exported this way).  Like the previous approach, you now have an external .xls file that you can now do whatever you want with it, including importing it back into the permanent datatable attached to the test script.

Let’s breakdown this simple script, I have three transaction times being recorded – “trans1″, “trans2″ and “trans3″.  “trans1″ encapulates “trans2″, and “trans3″ logs its own time at the end of the script.

The timers and duration times breakdown as follows:

“trans2″ – this transaction actually completes before the “trans1″ because it is contained within the “trans1″ wrapper (nested within the “trans1″ code), so if we look at the results for “trans2″ you will see that it contains a “wait 3″ statement and an “AddWastedTime” of 1000 milliseconds (which is 1 second).  In looking at the test results report you can see that the “Total Duration” time is 3.0300 seconds (the 3 seconds from the “wait” statement and a slight delay for the execution of the statements themselves) and it also logs the “Wasted Time” of 1 second.

“trans1″ – this has a total duration time of approximately 12 seconds.  Simply add up the “wait” statements contained within the “trans1″ transaction wrapper and add a slight delay for the execution of the statements themselves.  As you can see in this image the “Total Duration” time is 12.1080 seconds.  Now the “Wasted Time” is all the “AddWastedTime” statements contained within the “trans1″ wrapper, so this includes the “Services.AddWastedTime MercuryTimers(“timer1″).Stop” statement (which is a dynamic statement based on the “MercuryTimers(timer1)” wrapper around a subset of code (the “wait 4″ statement in this case – however this would normally be a real chunk of code)) and the “Services.AddWastedTime 1000″ which is a hardcoded value where we are saying that “we want to reduce the time by 1 second”.  Added together this is 5 seconds with a slight delay for the execution of the statements themselves – which as you can see in the test results report is 5.0190 seconds of “Wasted Time”.

“trans3″ – Finally we have the last transaction time being recorded and notice it is outside of the “trans1″ wrapper.  So this is self-contained code at the end of the script and logs its own time which in this case is a hardcoded 1 second using the “Services.AddWastedTime 1000″ statement.  Notice the timers from above do not affect this timer.

As you can see the “Wasted Time” is logged in the Test Results for a normal QTP test process, and realize it is also integrated with LoadRunner and the Business Process Monitor.

Be aware that there are Pros and Cons to using this function in a QuickTest Pro automation script.

Pro: Using this function you can define an Edit box to appear that you can prompt for a value from the user that you can then use in your test script.  The function has several parameters but the most common parameters used are the “prompt” (which is the only required parameter), title and default (which is the default value to automatically pre-populate if you want).  The other parameters are used less often.  The value that is entered is then passed back to the script as a return value and can be captured in a variable to be used within your test script.  Here is an example of using it to retrieve a security code during test execution.

Notice in this image how the statement generates this edit box.  You can then enter a value in the edit field to be passed back to the script like in this image.  Notice the value entered into the edit field, it will be passed back as the return value and in this example it will get stored in the variable “vReturnValue” based off the example in this image.

Notice in this final image, the InputBox statement has been executed and we are now paused on the wait statement so that we can examine the variables.  In looking at the variable in the Debug Viewer, notice how the variable has the value that was entered in the edit box.

Con: The con to using this function in a QuickTest Pro automation script is that it requires interaction from a user.  The biggest goal that you are always trying to achieve with test automation is to get “long term unattended testing” which means your script needs to be able to execute without any user interaction.  This function requires a response from a user and will just sit there forever until it gets a response.  So be careful on using this.  If you really want to use this function then I would recommend putting it at the very beginning of any automated process so that you could enter in all the values immediately and then be able to walk away from the process and let it run independently from you.  However my recommendation on better options for getting a value for your automation is to have this value retrieved from one of these options, retrieve it from:
- a variable or constant from within your test script
- from a text file that the script opens and reads from
- from an environment variable
- or from a parameter passed in from another script

These statements will log the duration time to the Test Results Report, which will tell you how long the “process” that resides between the two statements took to execute.  Typically what you would do is wrap a submission or transaction process to see how long it is taking; like submitting an order or new user profile.  In using the QTP training application we will time the submission of the order, so find the “Insert Order” button statement and your synchronization statement to know when the insert process has completed. 

So just before the “Insert Order” button you would put a Services.StartTransaction “InsertOrder” statement and once you are synchronized on the success of the submission of the order you will have an Services.EndTransaction “InsertOrder” statement (placed right after the sychronization statement).

This will tell you how long it took to insert a new order and you can pass or fail this test step based on your functional requirements as to how long is an acceptable timeframe.  These statements will log the results to the Test Results Report directly and appear like this:

The disadvantage of this statement is that it only logs the results to the Test Results Report, so you don’t have the actual time within the test script in order to code your own logic on passing or failing the statement.  People complained about this for many years and finally they came out with a new function prior to the sale of “Mercury Interactive” to “HP”, so the function name actually has the old company name contained in it.  The functions are “MercuryTimers(“<timer name>”).Start” and “MercuryTimers(“<timer name>”).Stop”.  The Stop function returns the duration time as a return code so you can use it within your test script.  You would use this function the same as the StartTransaction statements; identify were in the test script you want the statements and then type these statements in (note that using the Step Generator will produce the wrong syntax so it is best to just manually type the statement in your test script in the Expert View.

Notice that I added a “msgbox” statement to display the duration time so that you can see how it is returned as a return value into a variable and can be used in the test script.  Notice that the time is returned in milliseconds.

The odd thing is that when Mercury added this function to QTP in order to provide you with the duration time as a return code within the script, they didn’t keep the feature of also logging it to the Test Results Report.  Notice in this image that there is no reference to the fact that the “MercuryTimers” function was executed. 

So if you want to log the time to the Test Results Report (which I highly recommend so that you have a log of the duration time) then you will want to add your own “Reporter.ReportEvent” statement.

And then the report will have entries for each timing and because I used a conditional statement to verify the duration time against the functional requirement of taking less than 6 seconds, I can then pass and fail the statement automatically.

Changing Object Synchronization Timeout from within a QTP script:

To figure out the setting name of other items that you can change, simply open the Test > Settings window and click the Generate script button. This will produce a text file that can be used to launch your QTP instance from a script (basically using the QTP API). We are not going to execute the script but use it to get the proper setting names for the various settings that we can change from within our test script. Open the file in notepad and look at the names. The file should look similar to this:

Other examples of changing settings include:

Changing Object Sync Timeout:

Changing the Test Iteration Mode:

The Quality Center is a software application accessed through the Internet Explorer browser with a database on the backend.  Most of the data you enter into the Quality Center like test cases, requirements, defects, etc. become “data records” stored in the database.  In my case I’m currently using SQL Server, so all this data is stored in this SQL Server database on the backend that the Quality Center interacts with.  So the first thing after installing the Quality Center is that you should setup a regular schedule of doing backups of your database.  But what a lot of people fail to realize or forget is that a lot of information is NOT stored in the database but instead stored in the File System where the Quality Center is installed.  Things stored here are QuickTest Pro scripts, and file attachments like images, files, snapshots, etc.  So you should also schedule backups of the file system.  You should try to get these backup software applications to backup these two entities (database and file system) as close in time as possible in order to keep them in sync as close as possible.

But realize that most likely your database backup software is not the same as your file system backup application.  Therefore they will not be in sync exactly if you needed to perform a complete restore.  In the case of a catastrophe these backups will be fine.  But what about basic everyday mistakes?  I have run into this several times where a tester accidently deletes an entire folder in the Test Plan module instead of the individual test case they were trying to delete.  Guess what, the Quality Center does not have an “undo” button for this nor does it have a recycle bin that you can grab the test cases from.  When this first happened to me, the folder the tester deleted contained 20 test cases in it.  All 20 test cases were lost instantly.  When we considered the backups we realized that the database and file system backups were performed once a day at 1am in the morning when no one was using the software and the system load was low.  Then we realized that to get those older 20 test cases back we would be restoring back to the previous day which meant that we gained those 20 test cases back, but lost everything else that was done today like all the other new test cases created, defects created, test sets executed and all the history.  At this point we realized it wasn’t worth the loss.  Our only choice was to recreate the test cases manually.  However I quickly came up with a new strategy – I now regularly create a backup QC project that is a copy of the current project we are working on, in addition to the database & file system backups.  In the Quality Center Site Administration tool, I create a new Domain called “BACKUP” and then I make a new QC Project in this domain.  The new QC project is named the same as the project I’m going to copy with the name “_Backup” and the date like “102511″ on the end, and then I specify to make a copy of my current project so it basically creates a duplicate project at this point in time.  So if my project name is “ABCorporate” then my backup I’m creating in this example would be called “ABCorporate_Backup102511″.  The big benefit to this approach is that you have a working QC Project that you can actually log into and access your information like normal.  So in my scenario where a folder was deleted and we lost 20 test cases, I could now log into this backup QC Project and use the reporting features of QC to generate a report file that contains the 20 test cases and then use one of the QC Add-in macros (Word or Excel) to import the test cases using this new report file, back into my existing QC project.  This saves a lot of time and effort.  I keep the projects deactivated as a safety mechanism so that no one gets confused and logs in and changes something.  This way it is preserved and I activate the project only if I need to login to find some data to export.

Since hard drive space is very affordable these days, I can easily keep 7 to 10 copies of the QC Project as working backup copies.  Then after that when I create a new copy I’ll delete the oldest version. This has been a great approach as I don’t have to deal with the tech support team responsible for the backups and try to coordinate a restore that ends up wiping out more data than I actually lost. Now I can just log directly into a backup copy and export the data. 

The only catch to this is that you will most likely not create a project copy daily, so you still run the risk of not having recent data available in this approach but it does cover you on the larger quantity of older data that will occupy about 75% of your QC Project.

So as a review, my backups consist of creating the following:

1. Database backup
2. File System backup
3. New QC Project that is a copy of the existing project as a backup

If you are using QuickTest Pro, then QTP uses VBScript as the programming language and there are basically two types of procedures in VBScript - Functions and Subroutines.  The main difference between them is  that a Function performs some actions and returns a value while a subroutine is used to perform some actions but does not return a value. 

There is also a concept of private versus public.  If you create a Function or Subroutine at the top of your test script in QTP, then it is private and only that script can call the procedure(s) and use it.  If you add it to a Function Library and add the Function Library reference to the Resources tab in the Test Settings window in QTP, then all the scripts/actions in the test suite (including all called action & reusable actions) can call all the procedures stored in that Function Library (thus it is considered public).

Bugzilla: http://www.bugzilla.org/download/
Bugzilla is probably the most popular, well known and used open source defect tracking tool.  It works fine and is found in many companies.  My only comment is that it is and was designed as a “defect tracking tool”.  I’ve been in many shops where they started using it for other things that it wasn’t designed for and it got messy.  Your best success will be to use it for what it was designed for.

Mantis: http://www.mantisbt.org/download.php
Mantis I’ve used once and it was fine.  It is similar to Bugzilla and free.  Honestly there is not much needed to make a tool a decent defect tracking tool.

Both of these tools provide the basics of:

1. Defect logging
2. Defect reporting
3. Multiple user capability
4. Easy to maintain
5. Easy to use
6. Customization

The majority of them will store defects as records in a database sharing common fields (columns) for information.  For presentation in the tool, most will present the defects in a table grid, like a spreadsheet.  So besides the elements I just listed above, the most important factors in a tool are:

1. Ability to create custom fields – needed to customize the tool to your needs in your environment.  Ability to customize existing fields and create new ones.  This should include data types and also the ability to create list values to select from.
2. Reporting – needed to present the defects found, ones being worked on, ones that are closed and also to be able to see trending.  Filtering and sorting are needed for robust reporting.
3. Exporting defects – the ability to export your defects based on a certain criteria is very useful and needed in most environments.
4. Email notification – this is very useful and enables developers and testers to know about the state of a defect.

  Online training is great because you can work at your own pace, whenever it is convenient for you.  You can do this work during down-time at work, over your lunch break, at home, or even at your kids sports practice if a wireless connection is available (we’ve had parents tell us how their kids hockey rink has wireless and so they would bring their laptop to the practice and go over some of the lessons during the practice). 

  We have customers from around the world to include the entire United States, Canada, Europe, New Zealand and Australia.  What makes my training so popular is that I have 17 years of experience implementing the product line in real-world scenarios.  So I’m not some tech writer or an instructor who has never actually used the tool.  I have implemented solutions for some of the biggest corporations with incredible success. Click here for PDF file of Company Reference List

Course Details: This lesson includes over 12 lessons consisting of 179 online training pages of material for only $50.  The Lessons covered in this class are:

1. Introduction
2. Record & Playback
3. Object Repository
4. Standard Checkpoints
5. Regular Expressions
6. Bitmap Checkpoints
7. Text Checkpoints
8. Database Checkpoints
9. Parameterization
10. Data Driven Testing
11. Output Values
12. Actions

Read more about this class on our “Products” page.

Ever get an “Overflow error” when using the CInt function?  You might encounter this error when you are doing some programming in your test script and doing some data manipulations or calculations.  Let’s review an example of a situation that could cause this to happen – a classic example would be if you were processing a file where a number could be rather large.   Here is a code snippet where the batch size of a data extract was retrieved and generated the Overflow error:

First thing is that in VBScript it only has one data type called Variant.  This can contain either a numeric or string in it and by default it will be a string if there are any other characters in the original value (which is very common).  There are sub-types available to use that you can convert a string or Variant to; they can be one of these:

Typically what you want to do in order to either add numbers together or compare two numbers in a conditional statement is to convert the variable to a numeric integer.  The way to do that is using the CInt() function.  However if you notice in the table above, an Integer is in the range of -32,768 to 32,767.  The problem is if you are working with an integer that is larger than 32,767.  Like in this example, if you look at the bottom in the Debug Viewer you will see that the Batch Size is actually 56,989 (which is not a surprise when dealing with data extracts).  So this is what is throwing the error because if you look above the error at the test script, you will see on line 103 that CInt is being used.  But if you know that a data element could be large, then use CLng() instead.  This will convert it to a Long which then accepts a range of -2,147,483,648 to 2,147,483,647 and works fine for our situation.

Now if you look at this second image, notice how line 103 now uses CLng and how we have paused on the next line, there is no error and the batch size is correct at 56,989 and notice the type is now “Long” to the right of the value.