One of the current industry trends focus on Feature Velocity, which demands high speed performance testing.
LST based performance testing is way too slow so has no answer to this and has become the next bottleneck in the software development process.
The same goes for Shift left performance testing, which is based on load and stress testing.
The mBrace answer: mBrace Methodology
The mBrace Methodology departs from the notion that performance testing is about reducing the risk of poor performance and this risk can be divided into three areas:
1. The risk of insufficient Performance Potential of the software Code developers deliver
2. The risk of insufficient Capacities
3. The risk of defects in the run time environment's Implementation of the application
Risk mitigating stages
Reducing the risk of substandard performance is conducted in three successive independent risk mitigating stages governed by a Product Risk Assessment.
Stage 1, Performance potential of the Code,
Stage 2, Capacities,
Stage 3, Defects in the Implementation,
After each stage part of the risk is eliminated.
In the Product Risk Assessment it is decided if the application imposes sufficient risk to do a performance test in the first place. If you decide to conduct a performance test, then Stage 1 is always done. Next, the Product Risk Assessment helps to decide about the other two stages. Stage 3, exclusively dedicated to defect detection and elimination and not for performance assessment, only requires involvement of a small part of the application in the test.
This way it is possible to optionally mitigate the risk of each area successively at the right time, with the right tools, by the right expertise and . . . with the right expenses. This enables us to integrate Stage 1 in the software development process in such a way that it does not disrupt the developer’s productivity.
Applying modelling helps to drastically reduce the scripting and testing efforts needed in Stage 3, which consists of a slightly adapted conventional endurance test.