WHIWH Rule
Performance testing requires a skill to identify bottlenecks. Without mastering this art, it is impossible to be an ideal performance tester. A proper method to locating the bottleneck and its source may be carried out with the use of certain performance test result analysis techniques. Apply the WHIWH rule before beginning an inquiry into the bottleneck. The WHIWH rule offers advice on how to steer the process of bottleneck identification in the proper direction. The project plan often includes a performance testing window that is closer to the Go-Live date and smaller than the functional testing window. As a performance tester, you must complete the testing quickly and not only finish the testing but also locate any bottlenecks. the WHIWH rule is very helpful in such a critical situation:
What does WHIWH stand for?
- What are the errors?
- How many errors?
- In which condition do errors come?
- When do errors come?
- How long do errors persist?
Explanation of WHIWH Rule:
What are the errors?
‘Type of Error’ is the first item you should look at. You cannot conduct an investigation without understanding the kind. You could encounter several problem kinds, including client-side and server-side failures, throughout the performance test. Decide on the mistakes’ type and group them accordingly to make the examination simple. The following are a few of the mistake categories:
- Scripting mistakes:
1.In certain locations, it was forgotten to change outdated URLs, which results in the failure of a specific transaction.
- What to do to fix: It is preferable to parameterize every URL.
- Lack of test data: A tester may neglect to check the boxes for “recycle the test data list” or “continue with last value” while establishing parameters, which might cause the transaction to fail or cause the user to quit.
- What to do to fix: Keep more test data than the test’s total number of iterations. Use appropriate parameter settings, such as continuing with the last value or recycling the test data if it stops, etc.
2.Testing Tool side errors:
- LG failed during the test: This issue occurs when LG(s) are unable to handle the user load during the test.
- LG memory problem: This problem occurs when LG does not have adequate memory. LG might disconnect in the middle of the test.
- What to do to fix: Before beginning the test, check LG’s available memory.
2. How many errors?
The program becomes more unstable the more test mistakes there are.
The amount or percentage of mistakes is significant when analyzing the results. While some financial systems have 0% error tolerance, several applications have a 3-5% mistake tolerance limit. The results of the performance test must next be carefully analyzed. The test should be successful for all NFRs and the specified SLA. Accepting the real test result is always preferable than assuming the figure by disregarding the error count, especially when the errors are small.
4.In which condition do errors come?
Study the circumstances under which mistakes arise, whether they happen during ramp-up, steady-state, or a protracted test.
Generally,
Errors that occur during the ramp-up phase are caused by the server’s inability to manage the steadily growing demand.
Errors during steady-state are caused by a backlog of requests, unavailable servers, and network bandwidth problems.
Memory leaking may be one of the causes of mistakes in a test that lasts for a long time (such as an endurance test).
When do errors come?
You may find the root of the rendering bottleneck in the server logs by using the precise time. To determine the influence of a certain fault at a specific moment on the test, you may integrate the error graph with other graphs. The developer anticipates a summarized report that includes precise error timing information. This enables them to save time and find a solution to the problem as soon as feasible.
How long do errors persist?
You must determine if the duration of the faults is brief or prolonged. A server failure and fast recovery (you may witness a spike in the response time) are common causes of brief duration (one peak) errors, as are user exit, incorrect test data for part of the entries, back-end server activity caused by shared test environments, etc. Longer-duration errors can be caused by server failure, database failure, queue overflow, response timeout, LG failure, or network problems while contacting LG.
The root cause analysis during the performance testing phase is carried out using the WHIWH rule, which is the simplest method. WHIWH rule implementation done correctly yields prompt and precise results.
