I was recently watching a Discovery Network program on Airbus A380, and it was an eye opener. It was amazing how they were testing the aircraft for impact analysis. About 75% of air collisions happen because of mid-air bird impacts, the simplest solution in the past was to make the Aluminium sheet thicker (about 0.8mm). Because of the new A380′s weight, they decided to try a new approach and design a new lighter material. 
As a base, they took a thinner 0.6mm Aluminium sheet. But this time, rather than trying the usual impact analysis they create a real life scenario. They created a Chicken Gun – a gun capable of firing a 1kg skinned chicken at 260 mph towards an Aluminium target.
No surprises, the results of this testing were completely unexpected. The chicken actually tore apart the Aluminium foil like a paper. The result was a new material which combined both glass-fiber and Aluminium.
Honestly has been an eye opener for me !
Testing InSync isn’t easy, unlike server backup you have to the data is much more dispersed and diverse, coming from 1000 different sources over different networks. This time for v4.0 testing, we have decided to follow the Chicken Gun Theory. We are in the process of building three new test suites for -
- Parallel Stress
- Fatigue
- Volume of Data
- Different Networks
To simulate parallel testing we have leased over 200+ small servers from a grid provider for next few months. Each of these servers will simulate multiple users to detect bottlenecks in parallel testing. Hopefully this would also be useful for testing scalability of the storage engine. For example we recently discovered that enabling native compression in the embedded database puts some marginal load on abundantly available CPU power, but reduces critical disk I/O by 30% !
Sometimes we have seen issues surfacing from prolonged usage when server is working relentlessly for months. To test this, a small set of these servers will be kept in constant “synchronizing” state for weeks. This fatigue testing should be able to test various corner cases causing memory leaks, open file handlers, de-fragmentation etc.
And to test the effect of different networks, we would be using different proxies which will induce latency and network drops in the network. This should help us understand the “remote” backup better. This actually helped us understand a recent customer case, where backup was suffering because of VPN time-outs.
I am sure, this would help us make your laptop backup much more robust … without sacrificing any chickens (except for the launch parties) 
