Using software development practices like Agile/DevOps/CI gives us the ability to instantly access the risk of a new release or change before it impacts our customers.
The goal is to catch unexpected behaviors introduced into the code base as soon as possible. The sooner you find or prevent bugs, the easier and cheaper they are to fix.
This goal has caused teams to shift towards automation testing to help them find issues sooner in the software development lifecycle. Many teams have made this transition with functional testing and are only now starting to include performance testing as well.
Because of this shift, load and performance testing responsibilities have also partially fallen into the laps of developers. But how can you lower the performance testing barriers to help get your developers involved in stress and load testing?
Introducing k6 byLoad Impact.
It works like this:
k6 at a High Level
k6 is a developer-centric load and performance testing tool. You can use it to describe performance-based user journeys or scenarios and have k6 run them.
k6 runs tests with any number of users ramping up and down in any pattern that you desire to measure how well the target system can cope with the amount of traffic you’re throwing at it.
Here’s the deal.
Treating Performance Scripts as Code
One of the main issues that can deter a team from adopting performance testing practices is that not many companies design their performance tools with developers in mind.
Understandably, programmers tend to prefer taking a code-like approach to developing load test scripts.
Developers and teams working in DevOps environments also want the ability to version control all the different types of code they have.
So why not treat your performances testing scenarios or test cases like you would any other application code?
This was one of the reasons why Load Impact created k6. They wanted to create a tool that was not only freely available but was usable in various scenarios.
k6 also wanted to support developer flows, like running a tool on a local development machine, integrating it into a company’s CI tool or service, and pushing it all the way to using Cloud infrastructure, etc.
The focus was on having all aspects of the scripting and configuration as code so its users could easily have their performance code in version control and fit into their developer’s eco-systems.
Modularized Performance Testing Code
Another aspect of Load Impact’s focus was to make sure the tool was able to modularize the code so test cases could be easily separated into different modules that teams could reuse code among different tests. Because of the shift towards QA, performance testing engineers and developers all leveraging the same script means that responsibility has to be spread across a more substantial number of users.
Being able to share and reuse a common foundation of code is very important.
k6’s main focus is on having all aspects of the scripting and configuration “as code” so a team’s code version can be easily controlled and fit properly into the developer’s standard development eco-systems.
Performance Testing Power from the Command Line
Load Impact also developed k6’s execution in a way that fits well into the way a lot of developers work already, which means using the command line.
Many traditional testing tools are more GUI-oriented, but developers tend to want to use their favorite editor or IDE when developing, so it’s handy to have the option to run from the command line.
Command line-based execution helps the tool fit into a developer’s workflow, which is why k6 is a command line tool. This feature also makes it easy to move from the early testing/debugging stages all the way through to the automation stage.
So this tool fits natively into automation pipelines.
k6 also has features that make it very easy to integrate into different CI tools and services.
Performance testing result analysis can be one of the more challenging aspects of performance testing.
Luckily, the result analysis phase of k6 is very flexible. K6 has multiple options for outputting the result data. For example, there is a JSON format, and there is integration with influxDB that is an open source database you can then hook into the Grafana platform to visualize the data.
It also has some other integrations on the way with Prometheus and some other tools.
Writing Performance Testing Using JavaScipt
If you’re a developer who is using other languages in your day job, learning a completely new language is a big deal and quite a learning hurdle.
Small things like this help make a developer’s barrier to entry into performance testing as smooth as possible.
Also, good documentation doesn’t hurt. ☺
That’s another area k6 has been focusing their efforts on– providing clear documentation—which, of course, helps people get started.
So once developers are set up with the right tools to help them with performance testing, how do you get them to start including the performance as an activity that is done early in the software development lifecycle (SDLC)?
Performance Testing Earlier in SDLC
Most companies start testing quite late in the game, and they tend to focus most of their testing on end-to-end tests.
I try to encourage and help folks to start testing earlier. I also suggest testing smaller components or smaller parts of a more extensive application.
People often try to start doing too much too soon. But rather than go for overly realistic and complicated tests right off the bat, they should start off by testing smaller things and gradually work their way up.
If your team is mostly made up of developers and you want them to help with your performance testing efforts, k6 should be a tool that you evaluate. Check out their Github page now.
More Performance Testing Awesomeness?
How to Stay Up To Speed with the Latest in Performance Testing?
If you feel overwhelmed with staying up to date with all the latest performance testing and performance testing tools and best practices check out my annual online conference dedicated 100% to just performance testing — PerfGuild.