One of our customers recently wanted to know about our internal quality processes. On this occasion we collected data on our tests. Some of the results surprised us.

• 25% of our development time is dedicated to explicit manual testing of new features & fixing bugs,
• code coverage for tests is set to 90% and we use about 10.000 unit tests that run automatically on each code check-in (so called ‘pre-commit’),
• we also have automatic integration testing (via watin, covering about 250 different user scenario's) and these are automatically run 4 times a day.

Before allowing a code check-in, agents run automatic build & unit tests and check code coverage of the unit tests. Elementary measurements are in place to detect potential performance leaks, such as count of SQL-statements, or time-limits set to test execution.

We have learned the hard way that this kind of automation is required when we want to deliver production quality code every two weeks. After 67 sprints we still feel we can improve, more precisely on testing customer specific configurations, creating everything in a build with one step and getting more hardware to run all these agents.

The picture below is a view on the dashboard screen we have deployed in the engineering room. It has been put up to allow all visitors to get a one-screen overview of the status of the sprint.

On this picture you can view:
-    Red/Green indicator for the automated build process
-    Red/Green indicator for the automated testing
-    Content of the current sprint
-    Burndown graph
-    Number of bugs currently open