Updated: May 20
Shifting performance testing to the left is certainly a hot topic these days. All major companies have either implemented this practice already or have huge test-improvement programs lined up. But why do you need to do early performance testing, and what does it involve? Is it a case of your performance engineer joining the development team and contributing to their scrum meetings? The answer is yes, but that’s still not enough…
Make Sprint-performance testing part of your strategy
It also helps if you provide resources for dedicated jobs, but the most important thing :is to have an overall strategy. The strategy should clearly outline how you’ll make testing part of your value stream. This blog post gives you insights into how you can implement Sprint-performance testing with the minimal effort and enable your development team to do early performance assessments.
As James Bach, our leader in software testing, explains in his recent blog post, <https://www.satisfice.com/> the earth model of software testing involves many different surfaces. Better quality at the user layer requires better quality in the lower levels, such as in the code, and in the unit and integration testing. Unit-level testing is one of the best means of risk-mitigation because risk is always higher close to the user layer. Here I’m going to introduce an approach that fully supports this perspective. It’s all about creating good test coverage early in the development process.
First, let’s talk a bit about implementing in Sprint-performance testing. Those of you working as software testers will know just how difficult it is to keep the automated-scripts functioning in an Agile CI/CD environment. The fact is that making too many changes in a short time doesn’t give us enough time to fix automated-testing scripts. We throw away, these test cases, and instead of letting a robot do the repetitive checks we do them manually, again and again. This only wastes time and it’s frustrating too. So how can we reverse this downward slide? The solution is to shift automation left as well, and instead of implementing the automation from scratch, we can reuse the existing automated test cases or scripts that our developers deliver with their code.
Cucumber is cool!
Cucumber is a nice behavior-driven testing solution. This 5th-generation language provides a formal approach to describing test cases on a higher level that also allows business teams to follow and document the process.
The beauty of cucumber is that it fully supports the test-driven development concept. That means we can write test cases before implementing the code. The execution of the actual automated tests is done by several frameworks such as JUnit, Selenium and several others. Our developers now take the driver’s seat in implementing these automated tests, as well as executing the tests to validate the code. Finally, they hand over the tests to the testing teams to check functionality at the QA stages.
Cucumber and performance testing
In one of my recent projects, the flow of new releases was too fast for the automated scripts. The scripts couldn’t be updated fast enough to validate the performance of a newly deployed application. There were also too many bugs in the later stages, which delayed the time to production. Then—after a bit of research—we found a simple solution. Using the existing cucumber-test scripts, we integrated the cucumber-performance package. It meant that we didn’t need to write any of the test scripts that are normally used for performance testing.
I’ve now created a training package for the cucumber-performance-testing framework. It outlines the entire approach and gives you more details on how this forward-thinking methodology can be used to shift performance testing to the left.
Follow this link for more details about this training: https://leanpub.com/c/cucumberperformancetesting
Happy performance testing!