Want to lower the performance testing barriers to help get your developers involved in testing? K6 is an open source, modern load testing tool that provides a clean, approachable scripting API, local and cloud execution, with command and control through CLI or a REST API using JavaScript. In this episode, you’ll discover developer-friendly performance tips as well as how k6 was developed to make the performance testing barrier to entry as smooth as possible for your developers.

About Robin Gustafsson

Robin Gustafsson is the CTO at Load Impact, with 10+ years of experience as a developer. He is a driving force behind the newly released open source tool, k6 . Robin has a strong belief that developers should test their own code.

Quotes & Insights from this Test Talk

• We wanted the tool to fit natively into automation pipelines. So k6 has features to make it very easy to integrate into different CI tools and services.
• If you are a developer and you’re using other languages in your day job, then you know learning in a completely new language is a big deal a big hurdle. And I would say the same thing goes for some of the other tools like you mentioned like Gatling for example which is Scala and a DSL is called on top of that. So I think that those kinds of hurdles you need to remove as many of those getting started hurdle’s as possible. So that’s one of the reasons why we decided to go with the JavaScript’s for k6 that is a very very common language amongst developers. So I think that’s not that for one thing and making the barrier to entry is as smooth as possible.
• It goes into the trend of you know a lot of companies architecting their systems with smaller micro-services and things like that. So you have a naturally a divide between different parts and components of the system which also makes it easier to test earlier whereas if you have a monolith it might be challenging to test early because you have to wait for everyone to complete their part of the Monolith, so that’s also something that we care about a lot.
• Start small try to understand what your system your testing where the performance is at the moment. So you have a good idea of what you’re starting from, what the baseline is and then try to test a small part of it to see how it is performing how it is trending over time and then kind of scale from there. Make your tests bigger test larger portions of the system maybe start testing more components together so you kind of move towards that end-to-end test. But there’s a lot of education that needs to happen, but it varies a lot.
• So we have like two and a half (more or less) full-time developers working on k6. So as you say we have “skin in the game” and an incentive to move k6 forward.
• I think going back to what we have touched upon like two times I think at least during this discussion I think — don’t have too complicated of a goal initially. It’s more important to start and test. Start off small and then kind of iterate towards more and bigger tests. I think that’s that’s the most important advice to give to anyone that wants to get into start doing long-term performance testing and not see it as such a large and complex project or undertaking.

Connect with Robin Gustafsson/k6

• Twitter: k6_io
• GitHub:github.com/loadimpact/k6
• Company: loadimpact.com

May I Ask You For a Favor?

Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.

Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.

Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!