Lots of applications nowadays have robust and complex front-end development - user experience becomes so important! That's why, we need to understand how these front-end features and elements work under load. In this interview, we will talk with Damion White, software testing consultant from WiseClouds, and discuss the issues you can face when creating API load tests for such scenarios and how to avoid them.
Watch the interview and leave your comments (find the transcript below):
Damion White is a seasoned technology professional specializing in developing, testing, integrating and implementing strategic, web and software-based solutions for customers across a wide range of industries and business applications. Most recently, Damion joined the team at WiseClouds – a provider of training and professional services for NoSQL technologies, high performance APIs and GUI architecture – as a lead application performance architect, specializing in GUI performance. He has worked extensively across SMBs, mid-market and enterprise businesses and has been tapped to engage in highly regulated industries for clients such as Pfizer, HP, Intel, Sanofi-Aventis and Lenovo. This has given Damion unique perspective and insight valuable to clients whose businesses emphasize data privacy and governing protocols like HIPAA, PCI, GDPR & FINRA compliance.
Presently, he resides in Austin, Texas with his wife and two daughters. As a former two-sport NCAA Division I athlete, when he’s not producing and recording music, Damion enjoys spending a portion of his spare time coaching high school football and basketball.
I hope you like the video! If you have any questions, please post them here. The series contains 5 videos that will be posted each Monday of August 2020. Subscribe to the SmartBear Community Matters Blog to get the news from us first!
Watch the previous videos of the series:
- Mistake #1 to Avoid: Separating Load Tests from Business Process
- Mistake #2 to Avoid: Not Calibrating Virtual Users to Real Users
- Mistake #3 to Avoid: Failing to Explore Multiple Load Generation Scenarios
Hi! I'm welcoming you in SmartBear Talks where we are talking about five major API load testing mistakes you need to avoid. We have already discussed three mistakes and if this happens to be the first video that you found, please watch the previous videos in order to be aware of the mistakes you need to avoid.
Today, Damion White from WiseClouds will help us understand the fourth mistake.
Hi Damion, how are you today?
Hi Tatyana, I'm doing very well. It's great to be here with you again. How are you?
I'm good thanks! Thanks for joining us on this call. Today we will talk about some GUI security testing, and we need to pay attention to some load testing scenarios here. So what should we pay attention to?
Absolutely. And, again, first and foremost, it is certainly my pleasure to join, and I'm grateful to have this opportunity to speak with you and discuss these topics, as well as addressing the SmartBear audience and potentially offering some insight to help with the creation and execution of load testing.
So, the fourth mistake that we wanted to unpack a little bit and avoid is that of testing the GUI security interactions using API load test tools or API load tests. Now, given the way that security and authentication, and certification in the application environment often work, it is possible to test these features through API load tests and API load test tools. However, there's been a bit of a fundamental shift in the way that applications are developed. And, that shift has entailed a much more robust and complex approach to front-end development than we've seen in time past. And, with that because users are seeking more flexible, more nuanced, and more complex end user experiences, we often find that there's more code written in the front end of an application than there is in the back end. Within that, it becomes integral that we understand how these features, these elements, that are written into this front end of this code into the user interface, how they perform when subjected to load.
And, so, the issue with testing these security interactions using API load test and API load test tools is it strips away the GUI elements and the processes that underlie them, and, so, yeah, sure, we can get a sense of how load affects our security interactions functionally and from our operability perspective. But, we don't get what the end user experience will reflect in terms of those same interactions when subjected to load. And, so, again, this goes back to what we spoke about in the second mistake, in terms of creating a load testing plan or a battery of load tests that just simply aren't effective, that aren't testing the performance and testing the features that we think we're testing under an amount of load or a type of load that is going to reflect anything that is impactful or insightful for our production releases. And, you know, that's just something to avoid.
Will it help to create less load tests if you set up UI testing like in LoadNinja, will it mean that you will need to do less work creating tests?
Absolutely no. And, I've always subscribed to the thought that you have to do a little bit of leg work, experience a little bit of pain on the front end to create those efficiencies down the line that will ensure that you're able to continuously develop, continuously improve upon your processes, your application and even in the project development sense because of what you did early on. And, the alternative to that is we don't get this separation between what's most appropriately tested via GUI load test tools versus that of API load test tools. And, it creates pain points down the road.
Those pain points often include violation of SLAs, they create the inability to impact the dev and iterative processes for application projects because we simply aren't testing that which we think we are. And, so, what we inherently avoid, when we test GUI elements or GUI interactions using GUI load test tools, is the stripping away of that which comprise the end user experience. And, without testing a GUI security interaction like Okta or Ping or Single Sign-On at the GUI layer, we simply don't know how it's going to perform.
Thanks a lot! That was the fourth mistake you need to avoid when doing API load testing. We have one more, and it will be released very soon, so stay tuned! Thank you Damion.
Thank you Tatyana again, it was my pleasure to be here. Take care!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.