Behaviorally there will be differences between how your users act and how your load test plan is executed. A small difference in the two can cause problems you didn't expect. That's the point I was trying to make.
For some things I can agree with you, usually web-apps with many possible branching execution paths where it is hard to know exactly what will be the most common use case to test for.
However in this case what can the users do that can be different to their plan? The most basic example would be logging in, there are not that many execution paths I can think of for that one.
As for the integration / reporting during gameplay, this is all done via a strictly defined API which is called by the game client in relatively predictable ways (game started, player does X, authentication ping every x seconds, achievement unlocked), unlike a web-app where users can do whatever they want the API usage flow is basically controlled by Blizzard.
That is why I am not impressed with blizzard on this one; they control basically the entire use of this API apart from one thing, the number of users trying to use it at any one time, which is there the load testing plan should have worked.
However in this case what can the users do that can be different to their plan? The most basic example would be logging in, there are not that many execution paths I can think of for that one.
As for the integration / reporting during gameplay, this is all done via a strictly defined API which is called by the game client in relatively predictable ways (game started, player does X, authentication ping every x seconds, achievement unlocked), unlike a web-app where users can do whatever they want the API usage flow is basically controlled by Blizzard.
That is why I am not impressed with blizzard on this one; they control basically the entire use of this API apart from one thing, the number of users trying to use it at any one time, which is there the load testing plan should have worked.