Oftentimes, before applications are tested and put into production, they are deployed internally and only accessible from within an organization’s private development network or QA environment, behind a firewall. The reasons for this vary, but in some cases, it could be an internal application that is used only by members of the organization. In other instances, developers and QA teams may choose to test an application internally before a big launch and releasing it into the wild. The drawback to having applications sitting behind the firewall is that many organizations configure their firewalls to block external traffic, which can make performance testing applications from cloud-based platforms impossible.
Regardless of the situation, it’s necessary that applications can be easily tested to ensure they stand up to the demands that will be placed on them and that they’re free of any bugs, bottlenecks, and other performance-related issues. We’ll look at the challenges presented by testing applications behind a firewall and the methods the LoadView platform uses to help QA and development teams work around issues so they can focus on performance testing.
Whitelisting Static IPs
In order to adequately perform testing on applications behind a firewall, one method is to whitelist IPs, which is the process of creating a pre-approved, trusted list of specific IPs for accessing them through your organization’s firewall so that they can be accessed for performance testing. This is a common approach with many tools, but isn’t a perfect solution, as IP addresses can change if you’re a remote developer or tester, for example. In the case of LoadView, you have access to over 20 AWS and Azure load injector zones/locations. As is the case with most cloud-based solutions, the IP addresses for load injectors are created dynamically, so it’s important that they are whitelisted so that you can run your tests from approved, static IPs.
Scripting Web Application Scenarios
Oftentimes with web applications, it’s necessary to script a series of user steps or paths so you can run those scripts against a high volume of concurrent load. In order to create scripts for load testing web applications that are behind a firewall, you must also whitelist the IP address of their scripting tool, the EveryStep Web Recorder. The recorder itself is easy to use. Just point and click your way through the application in the same way you intend your users’ will and the recorder saves all the script automatically. No need to manually write code, however, you can manually edit scripts, if necessary. Additionally, the recorder supports all the popular technologies and frameworks used to create web applications, as well as the latest desktop and mobile browsers.
On-premises Agent
Like many organizations, security is of the utmost importance, so whitelisting static IPs may not be an option for you. For this use case, LoadView offers an on-premises agent that can be deployed from a server within your network. Using the agent doesn’t require you to open your firewall to external traffic, making it a more secure option. Once the agent is configured, you can connect to the 20+ AWS and Azure load injector servers and push traffic from the agent to your web application, all from within the network.
Conclusion: Performance Testing Behind the Firewall
As we all know, the time and cost of fixing issues increase dramatically as you go further into the testing process. Add to that the fact that performance testing applications behind a firewall can limit what developers and QA teams can do and test, especially earlier in the testing process. Luckily, there are cloud-based performance testing solutions, such as LoadView, that help to address this problem and can be deployed easily to help overcome those concerns, allowing teams to focus on testing, not having to wait on a complex and costly workaround.Learn more about load testing web applications, web pages, and APIs from behind your firewall.