• admin
• Feb 20,2011
• In: Articles

Features of formation of the performance requirements of B2B systems

In terms of performance testing, all systems are divided into:

Heavy-performance systems. Hundreds of thousands of users, tens of millions of hits a day, dozens of gigabytes of data, terabytes of traffic. Yandex.ru, for example.

Low-performance systems. For example, a system of B2B interaction (inter-enterprise collaboration system). Such a system typically use about 100-500 employees and 1000 – 5000 the company’s clients and, of course, not all at once.

If a heavy-performance systems is in the first place, B2B systems in the first place – functionality. An inherent characteristic of B2B systems – a complex business logic. And this complex logic should work without a glitch and glitches.

Therefore, when testing B2B systems the bulk of resources and time given to such forms of testing such as: functional, usability, and integration testing. Benchmark testing is very little time.
But it is still necessary to carry out.

Only here it is important to understand what we want from our system in terms of performance.
Of course, you always want to have the best, but as they say "that a Russian well, for a German – death."

We can spend a lot of time and funds to ensure super performance of our system. Assume it will work wonderfully under stress million hits a day. But in reality, the maximum load, which is subject to our system – 10 thousand hits a day. And experts predict that up to a million hits to her long time to grow. What have we done? We just threw your money away and spend your energy in vain. Our system does not need such a performance, and many more years will not be needed. Would be better if we developed some new features that really would make life easier for our users.

That is, we must honestly answer some questions such as:

• What is the average number of users will simultaneously work with the system (How many employees use the system daily?. How many customers a day come into our system?)
• What is the maximum number of users will simultaneously work with the system (How many people will need to obtain or download the data in the system at the end of the quarter, for example?)
• What is the stock performance, we want to have (what will happen if something unpredictable and a bunch of people crammed into the system, as many as possible? Or, what if we made a mistake commonplace in our calculations, the average loading of the system. How could we go wrong?)
• The boundaries of acceptable performance of the system (Which performance, we considered good / normal / bad / very bad. The time of the operation for 3 seconds is good or bad indicator for our system, and 10 seconds? "Well, 10 seconds is exactly bad, you say. Oak . And if this operation is the formation of a quarterly report on the results of the department? "Do you still believe that 10 seconds is a lot for such an operation? Hint: there is no universally accepted standards. For each particular system, and even for each particular operation are good and bad results could differ at times).

Sometimes I hear criticism of fellow testers, they say here, I found that the system crashes during continuous operation of 20 users with such a module for 30 minutes. Nightmare! Has got the bug, said the manager, but they do not do this. Oh they are!

And managers just know that this module use the strength of 2.1 user per day and not every day. That is a performance module suits everyone for the past few years. And a few more years will hold. As soon as the draw a tendency to increase users’ interest to the module, it was then found the problem becomes really relevant and it will pay the necessary attention.

That is, before embarking on any performance testing of a system, we must clearly understand what we want (in reality) of our system. Otherwise it will test for the sake of testing.

See Also