We’re often too pushed for time to run many performance tests for our new application release. Chances are, there’s no time to review performance requirements, prepare and execute tests, or conduct a thorough results analysis. Instead, you’re forced to come up with creative solutions at the last minute, running a smaller set of test scenarios perhaps, or cutting test-data volumes to a minimum set. Engineers find themselves having to run performance tests out of working hours—which often makes things even worse because environment support is so limited at those times.
What causes these problems?
1. Launching in a hurry
Nowadays, businesses often believe that the earlier they launch new products, the higher their chances of success. But no one can build for quality in a rush. The process actually needs to start in the very early stages of the project. In the mad scramble at the end, we tend to focus entirely on how quickly we can release the new feature. Our developers are coding at high speed, a few functional tests are executed, and at best a performance test is executed just days before the go-live, when we deploy the crucially important feature to production. What do you think? Is a fast launch time really the priority, or should quality come first?
2. Getting your testing priorities right
As the time for performance testing often coincides with the functional and security tests, it can make things awkward when they all share the same environment. Functionality and security are typically treated with a higher priority than speed. We find ourselves running performance tests in the evening and even late at night. If we find something that isn’t working as expected, we have to wait for the next regular working day, and this is a waste of valuable defect-fixing time. Environments can be expensive, and having dedicated spaces is often a luxury. Pushing performance tests to non-working hours is obviously not the solution you’re looking for. Dealing with environmental constraints can be very frustrating, but there are several strategies for solving this problem.
3. Performance testing at the last minute
Everything that’s not immediately doable—such as manual testing of the happy flow—tends to just get pushed back on our daily agenda. Performance testing is one of those things that is often delayed until just a few days before deployment to production. It’s not part of our sprint planning, there’s no task for it, and also in a few rare cases, the acceptance criteria are related to performance. Why is it that nobody realizes how one of the most important acceptance tests before release— performance validation—is always overlooked?
4. Wrong user-simulation techniques
It appears that our modern web applications hold a large proportion of their business logic in the client layer. A backend-centric performance-testing approach is always easier to implement, and there are plenty of freeware tools available too. Neglecting the client layer for too long means our users end up frustrated after deployment to production. We wonder why they’re unhappy when our backend services are loading so fast.
How a performance way maker can help
All these pitfalls are quite natural because challenges related to response times aren’t apparent immediately. The absence of many good practices and a lack of forward-thinking are the factors that often lead to performance disasters on a grand scale.
A performance way maker is someone who can be part of the development, QA or architecture teams. He/she will have extended performance-engineering experience and can be brought in to review important projects from time to time. His/her job is to improve performance-testing practices and drive new practices for performance improvement, as well as sharing knowledge with all your performance engineers. This professional will have a background in development, full stack insights and automation experience, as well as performance-testing and monitoring expertise. The engineer fulfilling the role of performance way maker will be your single point of contact for performance engineering. Whenever your performance engineers run into a showstopper, they can call this expert.
Some key benefits:
Guidance in challenging situations
Sharing of performance engineering good practices
Continuous improvement of performance-testing techniques
Bringing the required level of performance practices to all projects
Performance is a matter for everyone. Make it part of your sprint planning; add performance stories and performance-acceptance criteria to these stories; and ensure you have a continuous performance baseline test in place. An experienced performance way maker can give you the required guidance.
Keep up the great work. Happy performance testing!
Comments