- [[Performance]] [[Performance Testing]] [[Load Testing]] [[Performance Engineering]] - Remediation of a production incident requires investigation into the [[Root cause]], because it's too easy to get caught up in symptoms. Determining the root cause also means you can address it with certainty so that it doesn't happen again. - In that scenario, though, we're reacting to a situation that has already occurred. When we're being __pro__active and preparing for a situation that __might__ occur in the future, we should look for the Root problem. - The root problem is the __real__ reason for the testing, and not the proximate one. - Nonfunctional [[Requirements]] may state that an ecommerce store needs to handle 1,000 users at peak load with a response time of less than 1 second, but why? - Because customers complained that it took too long to process a payment. - Why? - Because they missed out on a special sale of an item. - Why? - Because the item had a limited quantity. - Why? - Because significantly fewer units arrived than were expected, and the item was promoted in an email newsletter. - We've just gone from the stated problem ("the online store can't handle peak load") to the root problem (we don't have a process to confirm the number of items delivered before promoting it). - One is a technical problem, and the other is a human processes problem. - In this case, addressing the stated problem would have been valuable, and indeed we should do so, but it would not have resolved the root problem. - To provide real value, we should try to address (or delegate to someone to address) real problems as well as stated problems. - [[The answer is often determined by the statement of the problem.]]