Thanks saramic for your comment. We have a couple of slide decks, one from OOP2008 / Jaoo and one from Xtech which we presented in Dublin the other day going into a little more detail on our information architecture. I'm at home at the moment and don't have the slides with me but I'll get them over to you when I get back in the office.

Good luck with your project!

Mat

Alexander,

I'm at home at the moment and don't have my slides to hand but I'll ensure that I get them over to you when I get back into the office.

A brief overview of our testing phase is as follows:
1: TDD everywhere. We are an agile team and use TDD to design our software so have around 90% unit test coverage using standard Junit, EasyMock and recently Mockito. Mockito is a very lightweight mocking framework and we have found it very useful and are thinking of adopting it as our standard framework for unit testing.

2: CruiseControl. We have two cruise pipelines, one that runs our unit tests and one that runs our integration / acceptance tests. The integration pipeline is more complex than simply running unit tests as we deploy the application to our container here and run end to end functional tests using Selenium.

Testing in the browser is not trivial and working with selenium does have issues. You need to code your tests defensively to ensure that you don't get timeouts etc. We have a general rule that if Selenium does not have the capability to easily test a particular piece of functionality reliably then we do not write an automated test and rely on our QA function to manually test.

Performance test is critical. First of all, ensure that you are testing on as close you can get to the production hardware. Obviously this is expensive, so we test on a vertical slice of the hardware scaled down from production. We also need to represent the production traffic as closely as possible so in each test run we extract the previous weeks logs from the production site and run them against the new build. This gives us reasonable confidence with old data, but does not test the new functionality. To test the new functionality the only thing we can really do is make an educated guess as to what the traffic patterns are likely to be and to simulate them.

The sorts of thing that we monitor in our test are the average response time, number of concurrent threads, length of the database connection pool queue, average db response time, system load and free memory.

Thanks for the comment, hope this was of help. Let me know if you'd like more detail on anything.

Mat

We use Zabbix to monitor the various system attributes in our architecture. We also use Oracle Enterprise Manager to monitor the database and Cacti for realtime monitoring of services.

Cheers

Mat