<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=338168267432629&amp;ev=PageView&amp;noscript=1">
DevOps

Stress Testing versus Load Testing

These two types of testing are similar but answer two different questions about your project: how does it perform under normal circumstances versus where is the breaking point of this software? Both help you understand areas for improved stability ultimately providing your customers with with an excellent experience. Full Transcript …


These two types of testing are similar but answer two different questions about your project: how does it perform under normal circumstances versus where is the breaking point of this software? Both help you understand areas for improved stability ultimately providing your customers with with an excellent experience.

Full Transcript Below:

Cody:

Yeah, and stress testing is, as it sounds like, you’re going to stress the server out and you’re going to test it until it breaks.

Cris:

What kind of testing do you see on development projects? Is the breaking limit or which one’s load testing? Which one is stress testing?

Cody:

Testing a whole subsection to testing everything from the front end to the backend. And the goal here is to shake the tree and see what falls loose.

Cris:

So I want to jump in and talk about testing a little bit today and get some context about different kinds of testing, how those involved in projects and then, who knows we might even go into specifics.

Cody:

Yeah, for sure.

Cris:

But overall, what kind of testing do you see on development projects coming across our plate?

Cody:

Oh there is such a bunch. So for any modern enterprise-scale project, testing is a huge part of the actual ecosystem. Starting at the grassroots, the microscopic level you have unit testing where you’re just testing individual units of code, just like, does this small little bit of payment processing actually work in the way we expect it to and do everything? Et cetera, et cetera. From there, you move up the tree to integration testing, where you’re integrating units of code together to make a giant flow usually and this can take place from just testing a whole subsection to testing everything from the front end to the backend.

Cris:

Gotcha.

Cody:

And then moving even further up from there, you have behavioral testing, which is basically from the interaction of a user, does the actual app produce exactly what we expect it to in a visual way? So it’s everything from the top down instead of being so granular and then going even further, we’ve got things once you’re actually in deployment or otherwise in a testable, I guess you could say in vivo situation, you would have load testing and stress testing, which are basically two different types of testing that do almost the same thing.

Cody:

One is you’re going to test it to test at the load you expect and make sure everything works correctly and the next one is we’re going to test it until it breaks, so we know where that is.

Cris:

Okay, interesting.

Cody:

Yeah.

Cris:

So again, run that by me again slowly, so load testing is the breaking limit? Or which one’s load testing? Which one’s stress testing?

Cody:

Sure, so load testing is the expected level, so you have a certain amount of users per day, you have this measured metric, the ebb and flow of your traffic, you’re going to test it, what would be probably the highest or at least the middle percentile of that so you know, okay, this is how the server operates at load. Usually this would take place for one to test efficiency, but also to test reliability, that’s the point of that whole one-

Cris:

And my ideal flow of work when I have this many customers hitting my site or transactions going through or whatever it is, this is going to work, so let’s test around there. Okay, got it.

Cody:

Yeah and stress testing is, as it sounds like, you’re going to stress the server out and you’re going to test it until it breaks.

Cris:

Literally pull the jaw bone… Not the jawbone.

Cody:

Yeah, it’s wishbone there we go.

Cris:

That’s disgusting, pull the wishbone and see when it breaks.

Cody:

Exactly, you’re going to basically test it, basically at the limit of load testing all the way up to the point where the server fails or you cannot cause it to break because you’ve maxed out your testing systems, whatever one comes first, ideally, and the goal here is to shake the tree and see what falls loose and that helps you obviously make a more stable environment for the circumstances that you can’t predict, what if you all of a sudden get very popular? Thousands and thousands of users come to your site, you’ve got to know what’s going to happen.

Cris:

That makes sense. So what are some ways that we actually go about doing that? Doing some of this load testing and the stress testing as a company, or how is someone that’s wanting to make sure that they’re actually testing their product within loads? How do they even go about doing that? Can they do it themselves? Does it have to be a CIS admin person that does this? How does that even work?

Cody:

There’s a lot of solutions for this problem, for one there’s a huge amount of tools built for this, both for load and stress testing, both in the Linux world, the Windows world, the Mac world, they’re all over the place and there’s even third-party cloud-based solutions that will allow you to more or less have a botnet of users to just go attack your own site, more or less, you’re basically paying someone to DDoS yourself, for those who are familiar with the term.

Cody:

But there is obviously some complexity with all this and either A, if you are a semi-technical person who owns a software project, you can probably do one of these cloud-based based solutions assuming it’s one that’s fairly user-friendly, but if you want to get really in depth and pull out metrics and understand specific failure points and more importantly, communicate those failure points accurately to your software engineering team, you’re probably going to want someone who has a more technical role to do so because you can know that something’s failing, but to know what’s failing and have the intuition to say, this is how you fix it, that takes a bit of a technical loop and flow of the feedback from the testing, execution, fixing, deployment loop, the software life cycle and ssadmin or a DevOps professional or even software engineers that happen to know a thing or two about load testing or stress testing among other forms of testing are all great candidates for that role.

Cris:

Cool. So when should I do this? Should everyone be stress testing, load testing on their projects? Is this only a certain size of project? What’s the limit?

Cody:

I would gauge the importance of your project first.

Cris:

Okay.

Cody:

If this project fails in production, what happens to your business? Is it essential? Is it not essential? Is it just some other sub-service that there’s an easy replacement for? Or does it actually just make sense to just restart the thing if it fails? It depends highly on your reliability perspective and for the most part, when it comes to load testing and stress testing, all that is going to take place after you’ve at least gotten to launch. This is a post-launch activity typically because at least for load testing, you don’t know what your user load is going to be until you’ve deployed.

Cris:

Got it, okay.

Cody:

Now that said you can stress test before you go to launch, but that’s ultimately… What’s going to happen is eventually you’re going to test it so hard that something’s going to break and you’re going to invent work for yourself, so you have to be really judicious about which breakages you qualify as we actually need to work on this and delay the launch versus just get it live, because a lot of the times the answer for many things, as long as the site actually works in a reliable basis is just get it live.

Cody:

So yeah, that’s the first bit and then there’s obviously the other testing strategies we talked about, integration, testing, unit testing, behavior testing, those all would take place during the software development life cycle from the startup, that’s one of the differences between stress and load testing and those, is that for the most part, for the behavior unit and integration testing, you would want to start that procedure basically as soon as the software is in development.

Cody:

As soon as there’s an ability… because you can’t test behavior testing when there’s literally no project but as soon as there is an ability to do so, that’s pretty much when you want to start because the earlier you invest in that, the better return you’re going to have in the long run, as opposed to stress and load testing, which the return you’re going to see over time after deployment.

Cris:

Very nice. Well, any other thoughts on this topic regarding testing? I think we covered it pretty well and I’ve obviously learned a lot as far as some of these areas for testing, I assumed might’ve been post or pre or not or in the actual launch of the product, so that’s obviously interesting, but any other closing thoughts on this topic?

Cody:

I think the takeaway here is that testing is a valuable thing if you need reliability. Ultimately that is a sliding scale, a lot of people will claim we need testing on this project, it’s the most important thing. I wouldn’t say that as inherently true if your perspective is that your software does not need to be reliable, if it just needs to be cheap, it needs to get done as quickly as possible based on your needs then sure.

Cody:

You don’t really need to focus on testing, but if you need your software to be working at a 99.99% guarantee to your customers or upwards, and no one has a hundred percent, but we can all strive for it.

Cris:

Sure.

Cody:

You need to focus on testing as early as possible and you need to eventually, on that launch, do some stress testing and load testing so you know not only how your software performs, but also where it’s going to break.

Cris:

That’s awesome and so that’s obviously where someone like yourself or Tyler or many members of our team that are connected within DevOps can come and help walk through that full process of scoping things out, building these flows of testing and proper practices for programming along the way and then stress test everything at the end.

Cody:

We love software that works so that’s what we do.

Alexandra:

Thank you for joining us for this episode of Bixly Tech Tuesday. I hope you learned some of the nuances of the different types of testing styles and even between stress testing and load testing and how they really benefit your project. If you have any questions at all, go ahead and leave them in the comment section down below and don’t forget to check out our free custom guide, it’s actually linked in the description to this video and that will walk you through the whole process of planning out your whole app idea. If you feel like you’re ready to talk about the idea that you have, go ahead and check out our website, bixly.com, there’s actually a button there, free app validation meeting and you actually get to meet with Cris for 60 minutes to talk about your app idea and start strategizing how to execute it. Thank you for joining us for this episode of Bixly Tech Tuesday.

 

Similar posts

Get notified about the latest in Tech

Be the first to know about new tech from the experts at Bixly!