Frank talks about fear and how it can derail efforts to find and solve scalability and performance problems. He has seen a lot of fear on his various engagements, and here he talks about why, and how.

Read JDK 1.5 from Joshua and Neal

Ha, I don't think it is fear. My experience tells me differently. The main reason tests are stopped is actually frustration. So you have this nice little (or big) tool that drives the gui or your web pages and records response times. Great! Unfortunately, if a problem occurs, this problem will spoil whatever the results of the tests are. If you are hammering a wooden bolt into a piece of iron, the size of the hammer makes little difference!

First thing is to understand the core reason why performance issues occur and that needs proper monitoring of the applications, databases, directories, network, IO etc. You will only find the problems one at a time, so in order to get your system properly tuned, there is no way around the "scientific method": Find a problem, fix a problem, test again, find a problem, ...

Unfortunately in I daresay the most testing activities, the database is not properly monitored, the directory response times are not monitnored ("They'll perform, son!"), there is profound desire to stick any performance bottleneck on either a product, a third party developer or whatever before even attempting to understand what the problem is ("I want your world expert in MQSeries/Tipco/BEA/JBoss in here tomorrow!").

QA people, especially in big organization, actually understand this, and they behave accordingly.

Frank talks about fear and how it can derail efforts to find and solve scalability and performance problems. He has seen a lot of fear on his various engagements, and here he talks about why, and how. Read JDK 1.5 from Joshua and Neal

Or maybe even "Fear and Testing by Frank Cohen" :-> (How about a TSS preview function?!)

I know the fear they are talking about... I work with a lot of database driven apps. And the fear is that I'll mess up the database and need to recreate it. Or otherwise manage to mess up the testing environment.

I've found a few ways to get over that fear. e.g. by automating the test environment setup as much as possible. So it can be re-created from scratch very easily. That certainly helps remove the fear that a failed test is going to require a whole bunch of work on my part to fix.

Recently I've been using the Linux virtual private servers (that my company happens to provide for hosting) for testing. With those I can have a whole Linux server setup (complete with databases and app servers). Run our tests. Get the results. Then reset the server back to its original state (by removing a copy on write filesystem file and doing a restart) in under a minute.

Very neat for regression testing. It means that the whole environment (file systems, database, server config, installed apps, etc) is exactly as it was before the test was run.

Cheers, Peter
RimuHosting - Java/JSP Hosting

Uhmmm, do you guys have anything to do with the latest art robbery in Norway?

;)