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.

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.

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

1. Internet Explorer
2. Firefox
3. Chrome
4. Safari
5. Opera

But then within each of these browsers there are different versions available to the general public.  Just because the company comes out with a new version of the browser doesn’t mean that people upgrade to it.  So lots of people will be visiting your website using different versions of these browsers.  So what do I test and support?  Two things you should monitor: #1 What are the Global Internet Statistics and #2 What are your actual customers using.

#1 What are the Global Internet Statistics

It is always advisable to monitor what is going on with technology and where its headed.  So you should monitor what the global traffic is like so that you can gage the direction of technology usage.  In doing so you should use multiple sources in order to get a non-biased result.  I use 5 different sites, take their stats and identify an average.  The sites I use are:

StatCounter GlobalStats
Stats are based on aggregate data collected by StatCounter on a sample exceeding 15 billion pageviews per month collected from across the StatCounter network of more than 3 million websites. Stats are updated and made available every 4 hours, however are subject to quality assurance testing and revision for 7 days from publication.

NetMarketShare
We collect data from the browsers of site visitors to our exclusive on-demand network of live stats customers. The data is compiled from approximately 160 million visitors per month. The information published is an aggregate of the data from this network of hosted website statistics.

W3Counter
This report was generated … based on the last 15,000 page views to each website tracked by W3Counter. W3Counter’s sample currently includes 47,262 websites. The browser market share graph includes data from all versions of the named browser families, not only the top 10 as listed below.

StatOwl
Our data is made up of an average of 28 million unique visitors per month to the network of web sites that we collect data from. We do our best to collect data only from web sites that have a broad appeal taking things like target market, audience, geographic location and type of web site into consideration. We attempt to cover a good mix of all of these indicators to provide as accurate a look as possible into Internet browsing trends.

Clicky
Marketshare is calculated from over 300 million daily page views across the 300,000+ web sites that use Clicky Web Analytics.

w3schools.com is another site however their monitoring is based on their traffic usage and since they are a technical site they admit their stats are skewed towards a technical audience which is willing to experient with different browsers and use tools that the average user will not use.  This holds true as you will see their stats are very different than they other 5 sites, therefore I don’t use their stats in my analysis at my fulltime job since my customer base is non-technical.

As of September 2011, the global stats from each of the 5 sites are:

Averaging them together presents this view of the Global Average Percentage on Browser Usage:

Now it is important that you track your customer usage and add that to your monitoring.  This stat can be gathered from tools like AWStats, Google Analytics and your own logging in your database if you process user records.  When you add this information to the graphing grid you will get a good idea what your customers are using and whether they are trending like the general internet traffic or if they are slightly different.  It is very important to remember that what your customers are using is the most important stat.

Browser Versions: Now the next bit of analysis is to drilldown into the browser versions.  In looking at the global averages, Internet Explorer and Firefox make up about 70% of all the usage.  Since you can come up with all sorts of older version combinations out there, I only deal with older versions for Internet Explorer and Firefox.  The other browsers (Chrome, Safari and Opera) I just test the latest version available on the market.

If we look at Internet Explorer you will notice that once you hit IE6 the usage really drops, therefore we only support back to IE7.

In looking at Firefox the two most used versions are Firefox 6 and Firefox 3.6.  The odd thing is that Firefox 3.6 has so much traffic but that can be attributed to the fact that Firefox is available on both Windows OS and Linux.  I’m not positive on this but the opinion floating around is that until recently, the latest “common” version on Linux was 3.6, but with the release of Firefox 7 in October, Firefox upgraded Linux too so this stat should shift once we get in the monthly stats for October.

Testing: now how do I handle supporting these various browsers.  Here is my strategy – our development team is Linux based therefore they only use Firefox.  So during their coding and unit testing they will see how the site looks in Firefox so this takes care of testing on the latest version of Firefox.  Since the QA team is primarily testing the UI through browsers (backend testing is different) and not tied to an OS, the entire QA Team is on Windows and uses Internet Explorer (we also do this because we use the Quality Center and it only runs on IE).  So we have Firefox and IE taken care of.  Now for the other browsers and older versions I have a PC test lab consisting of many PCs with different configurations and containing various browser versions on each.  On the test lab wall is a grid listing what is installed on each PC so if someone wants to test IE7 they can look on the grid and see which PC has that version and they can then log into that machine to test the site on that older version.  Likewise I have each PC’s configuration also taped to its monitor for easy reference.   Depending on the OS, I have several of the systems setup so that the test team can perform a Remote Desktop into the machines remotely from their cubes.  This way they don’t have to physically go over to the Test Lab.  I’m using physical machines because I was able to utilize hardware that was rotated out of regular inventory but fine for our use since they are primarily used just for internet access.  If you don’t have physical hardware to use, another great option is to something like VMWare on a server that can be setup with numerous virtual instances to simulate numerous machines.  This is a very effective way of “creating” the effect of having many different configurations, remote access and easy maintenance for the IT team.

If you need older browser versions, a great site that contains tons of versions to pick from for FREE is OldApps.com (note: I have not had a problem with that site but you download apps at your own risk.  Always scan them for viruses and adware prior to running the install program).

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.

Severity helps to define this.  By identifying the impact to the project functionality, we can determine which defects are more important and need to be worked on now and which ones could be ignored in the short-term.  In addition, severity also helps provide a metric on what kind of quality of work the development team is delivering to the QA Team.  An example of the severities we work with are as follows:

1-Showstopper:  This is critical functionality that does not work and must exist for the application to go into production, and there is no “work around”.

2-Major:  This is critical functionality that does not work and must exist for the application to go into production, however there is a “work around”.

3-Average:  This bug is serious in nature but less severe than major problems.  A simple work around for this bug exists.  There is an insufficient or unclear error message that has a minor impact on product use.

4-Minor:  This bug is mostly cosmetic, user friendly or considered an enhancement for future release.

Now lets say we have 15 defects to work on and the break down is as follows:

Showstopper: 3
Major: 8
Average: 2
Minor: 2

If you are working on a tight timeline and there is a chance that not all the defects will get addressed, then you need to define the order of importance otherwise the developers will have a tendency to work on the easy ones first to reduce their queue.  However if you can’t get them all done before the release date, what good is it to have all the Minor, Average and most of the Majors done, but you go live in Production with Showstoppers that directly impact major functionality.  So as managers and Project Managers we would want to provide some guidance to the development team as to what is most important to work on first.  Where there are only 3 Showstoppers, that is pretty easy to assign to indviduals but what about the Majors?  There are 8 Majors so which ones do we work on first?  This is where Priority comes in to play.

Priority defines the order of the defects to be worked on within the same Severity category.  So we will simply rank the importance from 1 through 8 within the Major defects in order to make sure the most important ones are worked on first. 

Severity and Priority don’t have to be complex; it is simply intended to be a communication mechanism to help let the developers know which issues to work on and in what order.

What is the Maximum Rows and Columns in QuickTest Pro?

The data table built into QuickTest Professional is actually a 3rd party product that was integrated into the product back when Mercury Interactive first created AstraQuickTest.  This tool looks and acts like Excel for the most part, and likewise includes some of the Excel limitations.  One of the issues is that Excel has a limitation on the amount of rows and columns that exist in a spreadsheet.  This limitation carries over to the QTP Data Table.  Microsoft Excel has increased the limitations with certain versions of Excel and is basically in three groupings of size (see the image below). 

Unfortunately the 3rd party product QTP is using is not updated beyond the mid-tier in the table displayed (highlighted in yellow).  The QTP Data Table is in the format of an “Excel 97-2003 Workbook” so the worksheet (Global or Action) will have a limitation of 65,536 rows and a limit of 256 columns.  The rows are not normally an issue, but I have run into the limitation of 256 columns due to the number of fields that needed to be parameterized in an application when making a data-driven test. 

An approach to handling the column limitation is to break the script up into major areas and then use the local “Action” worksheet instead of putting everything in the Global worksheet.  For example if you have a web application that displays numerous fields over a series of web pages, then make each web page a separate QTP “Action” so that the fields can be stored in the “Action” data table (worksheet).  The side-effect from this is that you loose the built-in feature of being able to say “run my script on all the 30,000 rows of data I have”.  This is normally defined in the “Test > Settings” Run tab which uses the “Global” data table to drive the test iterations for a QTP script.  By having the data now split across numerous Action data tables you will need to control the row being executed using a counter and specifying the row to use with the DataTable.SetCurrentRow method within each Action.  Try the following approach:

1. Create a “main driver” Action that will call each of the “Actions” from it.
2. Define an input parameter for each Action.
3. In the “main driver” use a For Loop to specify how many rows of test data to execute and then within the loop call each Action passing in the loop counter.
4. Within each Action, use the DataTable.SetCurrentRow method referencing the input parameter to know which row you are on.

This should help you overcome the column limitation.