117: How to Avoid Rookie Mistakes in Testing

Today we’ll be test talking with the founder of Performance Wisdom, Rebecca Clinard, about performance testing and the most frequent rookie mistakes folks make with performance testing. Do you have a web or mobile application you need load tested to determine its scalability limitations? Are you unsure of your tool, technology or skill set requirements? If you’re thinking about getting into performance testing or want to know how you can help your teams with performance-related tasks, you won’t want to miss this episode.

About Rebecca Clinard

Rebecca Clinard is an expert Performance Engineer, a Performance Lead for Applause and founder of PerformanceWisdom, LLC . She’s been active in the web application performance industry for 16+ years. Rebecca enjoys taking very technical information and evangelizing the technology into easier to understand words. She’s published a variety of syndicated blogs, while making a name for myself in this niche industry. All her content is derived from hands-on experience.

Rebecca has held several performance engineer positions for industries spanning many verticals such as retail, financial services, insurance, gaming, and supply management. Her expertise lies in creating realistic load tests and performance tuning multi-tier deployments.

Quotes & Insights from this Test Talk

As a QA person to transition to performance testing the first thing you’ll need is curiosity. You want to understand really what’s going on behind the scenes, typical front end functional QA testers are looking at websites, mobile applications. They’re clicking, they’re testing for bugs or are testing for user experiences. Well, performance engineering takes it deeper. The first thing to do is get really curious about those transactions. In other words, what are they hitting in the back end. Is it a database call? Is it logic being executed on the application server? What parts of the transaction responses are static, which are dynamic?
The key KPIs are the throughput, the TPS and the response time and the user load. With your tool, you’re going to gather key KPIs to say, okay at this throughput, throughput started to plateau. Response time started to creep up and what user load was that and you correlate all three KPIs to understand the scalability of the application.
The website is performance engineering wisdom. Basically, I started it to help educate. I wanted to share my 16 years of experiences, mistakes and all, so that other people can learn performance engineering more quickly and not spend so much time figuring it out. It’s a tool agnostic website too, so you can apply those core concepts to any tool. Also, I created a blog on very specific issues and challenges of performance testing and how to solve them.
Performance engineering is well “why”, why does it only … or what happens… What do you need to change in the environment to support a higher number of users? What I do in the course is I go into performance engineering and how to set up a performance test to answer those questions. A lot of gotchas, stuff that you can get tripped up on, methodologies where you reproduce the results, how to analyze tons of data to understand scalability and what to look for. I call it clear the clutter because you get overwhelmed when you run performance test. There’s so much data to look at afterwards. I say okay this is really the only things you really need to look at.
I think it’s interesting in the last couple years, what’s been mostly wrong well I shouldn’t say mostly wrong, but a lot of times is the clients don’t understand. They know they need performance or their web application or their mobile application performance tested but they don’t really know what they need tested. A lot of our responsibilities kind of educating them with performance testing and saying okay, we can performance test transactions which can be automate-able and something that can be tested over and over again.
The one piece of advice I have is relates back to what we talked to is do not be in a rush. Don’t be in a rush to slap together performance test and get results. Spend your time on those scripts, and making sure that you understand what’s going on. You understand the business transaction flows in the infrastructure and then start off with a low, low load and then increase it methodically. Take your time. Don’t be in a rush because you’re going to get the most valuable information if you do it methodically and with patience.

Resources

Connect with Rebecca Clinard

Twitter:@webappperf
Blog: performanceengineeringwisdom.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!