During the normal flow of a script and HTTP error will cause a failure and immediately end the current unit. There are some times however where you would like to look at the failed response. more⇛

In many cases you may have a website where important information is stored within comment nodes. This is usually debugging information which is helpful in your automated tests. Working with this information may at first seem tricky in XPath. more⇛

Several pointers and references for achieving specific tasks with TestPlan. more⇛

This is a fairly simply example which simply submits a search at this site. It covers the very basic functions of TestPlan and is thus a good introduction to the test language. more⇛

TestPlan automation is organized into a series of scripts, call test units, and something known as a LogicalRoot→ which groups several scripts into a logical test. more⇛

TestPlan has a few basic functions to manipulate DateTime variables. These will allow you to select time ranges for a fixed period, or relative to the current time. more⇛

This is a collection of parameters which can be altered to enable certain debugging aspects of TestPlan. This is useful if you are compiling or developing TestPlan but also if you need more details about an error your are getting. more⇛

If you successfully retrieve an XML document but are unable to extract any data from it, or every Check statement fails, then you are likely a victim of the XML Namespace malarkey. more⇛

A state refers to a particular point in the program, or step in processing, along with all the current data in the program. more⇛

While testing websites the response time of a page can be troublesome for the automated tests. Additionally JavaScript and/or page redirections can mean the page doesn't finish loading in the first request. more⇛