Most recent edit on 2009-02-19 23:01:10 by Admin
No differences.
Oldest known version of this page was edited on 2004-02-06 17:46:01 by Roland Stens []
Page view:
Do you need Performance Testing in your project?
When the requirements for your project yield performance-related requirements, you should do a thorough risk analysis to fully understand the risks involved.
Performance risks have a potential to seriously delay your project, impact your budget and create significant user dissatisfaction.
Experience and literature show a distinct number of performance-related factors that influence risk to your project, they are:
- User count - Obviously, a large number of users will stress the available resources more than a small number. Experience learns us that unexpected results show up when a large group of users become active, system resources run out, network segments choke, servers crash, database contention becomes intolerable etc. When reviewing the amount of users that the system is going to support, take into account that most systems are used continuously by a relative limited amount of users. Occasionally the systems will be used by a very large group of users (year-end, data entry etc.). Your system should always be able to support the peak usage.
- Front Office/Back Office balance - If you work on a system that will support mainly front office type of activities (Talking on the phone with customers while working on their information), the response times of your activities are more critical than when your system supports back office type operations (printing, research etc.).
- Throughput - If your system is required to be able to process a certain number of transactions per day/hour etc.
- New Architecture/Technology - If you plan to use a new architecture for your system or you are planning to deploy new technology or technology components. Even small changes to an architecture could trigger unexpected performance results. It is also important to ask the question if the technology and architecture is new for your team.
- Team - If you work with designers/developers/contractors who have not been exposed before to the proposed architecture/technology, that is used in other places in the organization, it will be a risk factor.
- One-shot project - If you have to get your system right the first time.
- Future Growth - If it is anticipated that the load your system has to support will grow from small to large.
- Dependency on other systems and resources - If your system has to cooperate with other systems that are dependent on your system's performance. Or, if your system has to share resources (servers, network etc.) that have defined capacity limits.