Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We run a few commercial webapps facing customers. The release schedule for them is regular, but there's always worries about testing changes, patches and upgrades. It seems like acceptance testing is promoted for contract development rather than "Commercial Off The Shelf." Is acceptance testing worthwhile for something we've already paid for? And if so, is there anything available with an eye towards:

  • Free. Everyone's budget is tight, ours is no different. Open Source is also a bonus. Being able to hand off a failing test to our support contact feels pretty damn handy, and commercial licensing might get in the way of that.
  • Automated. We probably don't have a budget to do something like this "by hand".
  • AJAX-y. Some of the pages rely on client side javascript, so we can't just replay HTTP get requests.
  • Robust. I'd rather not have to rewrite the tests for every minor revision release.
  • Cross Browser, Cross Platform. Different browsers behave differently and I'd feel more confident if the web engines behind the browsers were involved somehow. And we intend to support Macs.
share|improve this question
up vote 1 down vote accepted

Take a look at Cucumber and Selenium. They don't quite meet all your needs, but they come close. I've used Selenium and it's a bit of a pain but gets the job done, while I've heard very good things about Cucumber.

share|improve this answer

I'd be interested as well if someone has a more automated solution, but for front-end web applications, nothing beats a human tester with a testing checklist to work through on each platform, browser, and version to be supported. There are too many variables with the way browsers render HTML, CSS, and execute JavaScript to trust front-end testing to an automated tool. BrowserCam comes in handy for this sort of work.

share|improve this answer
Start out with a human checklist. Then you can gradually work the list and find easy things that can be automated. A suggestion would then to be for each release spend the time to automate 1 or 2 tests so that gradually you can test more things quicker. Take small steps toward an eventual ideal keeping in mind how much it costs to automate versus costs to manually go through the checklist. – Aaron Weiker Jun 16 '09 at 2:45

I think a lot depends on what the vendor is offering and how much confidence you have in their product. For example, do you really need to test the functionality on all the relevant browsers? Don't they have a QA department?

In some cases a manual walkthrough when relevant is the most cost effective. You can write up scripts and really pass them around so that everyone with a stake in it only has to do a little bit of work.

In other cases, where you don't have confidence in the QA department of the vendor, or there is significant customization involved, then your own automated tests will certainly be necessary if you don't want your customers to see an issue. Then it really depends on how much you are willing to invest in the robust aspect. The more robust, the more programming and hard work it is to make the tests. The more point-click-record the less effort to make the initial test, but more effort to maintain.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.