Setting up synthetic testing is relatively easy, provided that you have a working knowledge of your web application. To test dynamic features, you’ll also need a “dummy” user account that can place orders, leave messages, and log in and out without having an impact on the real world.
Also consider how you name your test accounts and your test scripts. The name “testscript5” will be much less meaningful than “westcoast-retail-orderpage” when you’re configuring alerts or trying to tie an outage to a business impact.
Testing services generally bill per test. Four main factors affect how much your bill will be at the end of the month:
The number of tests you want to run
How often you want to run them
The number of different clients you want to mimic in terms of browser type, network connection, desktop operating system, and so on
The number of locations you want to test from, both in terms of geography and in terms of the Internet backbones and data centers
You’ll also pay more for some of the advanced features outlined earlier, such as browser puppetry, multipage transactions, error capture, and object drill-down.
You should test every revenue-generating or outcome-producing component of your site, and perform comparative tests of a static page, a dynamic page, and a database-access page. If you rely on third-party components, you may want to test them, too.
That sounds like ...