Concurrent Testing
Run multiple tests at the same time.
Contrary to popular belief, performance tests do not have to be run one test at a time. In fact, it is more efficient to run multiple tests in parallel. This is because the combined runtime of the test takes only as long as the longest single test takes to run. Running tests concurrently can save hours, depending on the size of the tests and the number of tests previously fired sequentially. When code is checked in, or when a build is performed or a deployment is staged, the feedback needs to be as close to instant as possible. The idea of a four or five-hour test cycle every time a build is performed may have made sense in a nightly or weekly build world, but in the world of continuous delivery, "always have a working build" means proving the current build is working minutes or even seconds after it is run, not hours later.
How Developers Balance Speed and Quality
When implementing new technology, there is often the expectation that the faster new innovations can be released, the better. Today's modern DevOps teams look for additional ways to automate and streamline the development process, in light of the rising pressure to innovate at a faster pace.
But oftentimes, speed comes at a price. New capabilities are not always bug-free the first time, which means taking the time to step back and make sure that the quality of the finished product is of a standard acceptable to your user base.
So how does a developer balance the pressure for speed with the need to ensure quality? There are multiple tactics and processes that go into ensuring that an application can work seamlessly, or handle a certain spike in usage or traffic pattern. With the help of the performance testing experts at BlazeMeter, we share common best practices for striking an appropriate balance to ensure that speed and quality is not an either/or choice.
