- End User Perspective: First and foremost focus on holistic system performance testing. It’s the end user experience that ultimately counts. Don’t get initially distracted with items such as subsystem testing.
- Just Test IT! Don’t spend too much time formulating a strategy, writing plans and getting committee approval before being hands on. Get onto the system and start writing basic tests – this allows you to:
- Learn about the system intricacies faster,
- Assess strengths and requirements of different performance tools
- Get aquatinted and talking to stakeholders quickly
- Pull together a strategy and plan that that is more effective. I’ve seen substantial documents being rendered redundant as soon as people go ‘hands on’.
- The Inside to the Out: Priority should go to Load Testing inside the firewall first, then from the cloud and then from the ‘last mile’. Having a dedicated in house performance test environment means you can run more tests more often and analyse in much more detail. Quick Tip: From the outside run http fox and Google Page Speed to quickly find and identify any obviously areas of improvement.
- Repeatable Tests: Ensure your performance tests have repeatable metrics. If the performance test doesn’t have repeatable metrics then chances are you do not fully understand the system. Flush caches, fill caches, restarts etc – learn what you have to do to make the load tests repeatable. Effective performance testing comes by having a repeatable set of tests and metrics (with a high statistical correlation). See Performance Test Definitions Here.
- Application Under Test Internals: Don’t just blindly performance test the system, learn and understand as much about the system internals and architecture as possible. This enables much more cost-effective and intelligent Performance Testing.
- Workload Requirements: The Performance Testing is wordpress casino en ligne only as accurate as the model you reproduce. Spend time evidencing and clarifying the requirements making up the load model.
- Requirements Requirements Requirements: Make sure all the performance tests can be tied back to a set of requirements given by the business with named stakeholders. I am amazed at how often I have seen performance tests constructed with no traceability to requirements. You should be able to answer the question “What is the point of this test?” (See Performance Requirements Stage here)
- Real Time Monitors: Its much much easier to diagnose performance issues if you can tie in real time metics respectively with performance graphs.
- Think about Load Environment ASAP: Does the client have a performance environment? Is it scaled or full size? Is their build and deployment process mature (See Scaled Environments). In my experience this is the area that is the most problematic and swallows most time.
- Performance Tool Selection: Let your client and their requirements drive the tool selection – Do not pick a tool and then try and make it fit. (See Selecting Performance Tools here)
- Be flexible and adapt: Every business operates differently. I have a core process and set of principles that I work to – I then meld them to work with the business and their processes. I do not have a generic and monolithic approach that I dictate must be followed. Something is better than nothing – An imperfect load testing process is better than a perfect process that isn’t practical for the business.
Thats eleven not ten – but point eleven is so important I had to drop it in.
Performance testing can get hazy and confused for internal staff, everyone has a slightly different idea of what performance means. If benefit is shown quickly then it begins to solidify the process, it then becomes easier to work it into the SDLC.