When an existing application is being replaced by a new application, performance and usability requirements become intricately linked. In case of data entry applications, what matters is the speed and agility with which the user can get through a given scenario. This is where things get tricky. The speed is not only a function of how fast the system responds (performance) but also how is the interaction design of the application aiding in that agility(usability).
Consider a call center customer care application. If your boss comes to you and says “I need you to plan a new call center. Let me know how many people will you need to answer calls and manager those who are answering calls”, you may naturally ask questions such as “how many calls do we receive on average and peak times?” and “what types of calls are coming in?” and “how long does it take typically to get through a single call?”. Since you are a math genius, you figure, you will do some math and take number of calls on an average day, multiply by time it takes to handle a single call and divide by 8 hours.. and ta da you should have a magic figure of how many people you need. So some years pass by and existing application must be replaced with a new application. How is your life as a call center manager going to change?
Is the new application making the customer service representative take longer to get through each call or its making their life easier by taking less time than before? Is the application high friction and making the life of the customer and the service representative much harder?
So how do performance and usability play into this? Performance testing in isolation is only step one. Step two must be a combined usability drill during peak load conditions to validate that the new application indeed makes life better.
If you were the customer paying for the new application, wouldn’t you expect this validation?