Testing your system

I have raised this specific topic 3 times this week alone, twice in a MySQL setting.

The fundamental philosophy of testing is NOT to verify features of your product that work, it is to BREAK your system.

One such discussion this week was with a service provider that deployed a new system into an existing ecosystem. The release has been delayed due to development issue, and credibility with customers is now being further damaged because the system is reaching physical hardware limitations after just one month.

With this was described to me, my simple response was. You did not test you system to stress the system to breaking point. To know the limit of your capacity ahead of time is a proactive analysis, not a reactive one.

It’s not that complicated to do, easier in early stage before you have a 50-100-1000 server total environment, but it’s a best practice not see often enough.


  1. says

    Hi Roland,

    It is the basic pitfall for all organization due to the fact they want to rollout quick on their services.

    Although testing/street test is already our SDLC collegue book during our collegue time.

    We have to do our best to inform customer on this , at least with that we can ‘avoid’ any possible problem which we need to fix later on..:)