To test early and often, you need an infinitely scalable, high-performance Selenium Grid within your internal network. BrowserStack Local Testing gives you that grid, minus the hassle of maintenance.
Learn how to set up and optimize Local Testing for fast feedback, scalability, and security.
Elevate Developer Efficiency & build GenAI Application with Amazon Q
Test at Scale within your Internal Networks with BrowserStack Local Testing
1. Test at Scale within your Internal Networks
with BrowserStack Local Testing
Praveen Umanath
Director Product Marketing,
BrowserStack
Sreyantha Chary
Product Manager,
BrowserStack
9. What is Local Testing?
● It is easy to perform “dev testing” on your local machine with the browsers you have
● To test applications on the cloud, teams usually deploy them to a publicly accessible
server
● With Local Testing, you don’t need to deploy your application to a publicly accessible
server to test it—as it establishes a secure connection between BrowserStack and your
network
Without Local
Testing
With Local Testing
15. Getting started with Local Testing: Using the Binary
Enabling Local Testing with Automate is a simple two-step process:
1. Establishing a Local Testing connection.
a. Use language bindings
b. Use the CLI (shell scripts)
./BrowserStackLocal --key your_access_key
1. Configuring test scripts so they run through the Local Testing connection.
caps.setCapability("browserstack.local", "true");
Read more here: https://www.browserstack.com/local-testing/automate
17. ● Many networks are set up behind proxies
● Using Local Testing in this case is easy:
○ Pass the proxy options while creating the Local Testing connection
○ Run tests like you would normally do
● Local binary v7.6 and above automatically detect proxy settings on your machine and
setup the connection
What if my test environments are behind a proxy?
19. ● Disable packet inspection for requests to and from *.browserstack.com, or else you’ll
face a Bad SSL certificate error
● We provide solutions to handle packet inspection and certificates for our Enterprise
users
What if my network inspects HTTPS packets?
20. ● In big corporations and fintech companies, applications and test environments are set up
behind a firewall
● Enable egress (from your network to BrowserStack) traffic by whitelisting
*.browserstack.com for all HTTP, HTTPS, WS and WSS requests & responses
● Bypass packet inspection for requests from *.browserstack.com to avoid Bad SSL
certificate errors
What if my test setup is behind a firewall?
22. ● Sometimes, your testing or compliance requirements mandate routing all the requests to
your network rather than just the private-host requests
● You can achieve this by using the --force-local flag while setting up Local Testing
connection with the binary
There are more options you can use to set up the connection. For example, --only flag
allows connections only for certain hosts and ports.
Read more about these options here: https://www.browserstack.com/local-testing/binary-
params
But, I want everything to be routed via my network!
25. ● In reality, using Local can get complex quickly when multiple teams test multiple builds
at the same time
● Where possible, assign an identifier to each local connection you create with --local-
identifier flag and use it in your tests with browserstack.localIdentifier
capability
○ Also use --enable-logging-for-api flag so you can manage these connections
via Local Testing APIs
Managing multiple local connections
27. Best practices
● Don’t use a single binary connection for all of your testing
○ Setup a new connection for every build
○ You can also create a new connection every test, but it increases your overall build
time
● Use local-identifier options where possible as it is much easier to debug should you have
issue while running your tests
● Always close your connection only after you are done with your testing; not doing so will
break any network requests that are in pending state
28. Local Testing for Enterprise
We also provide the following features for our Enterprise users:
● IP whitelisting: for websites that are behind IP restrictions but are otherwise public
● Central Local connection manager: when you don’t want your team members to spawn
individual Local connections.
a. Admin can spawn several local connections with different identifiers, and team
members can use those connections without creating new ones
b. You don’t need to specify the local identifiers either—an active connection for each
test will be picked randomly
Note: IP geolocation will not work when you use Local Testing.
29. Here’s what we covered
● What exactly Local Testing is
● Why is Local Testing useful
● How to use Local Testing
○ Extension for Live and binary / executable for Automate
● How to use Local Testing in different network setups
○ Use the relevant binary options
● Best Practices of Local Testing
○ Separate connection for each build
○ Use local-identifiers for easier debugging
● Enterprise features
○ IP whitelisting
○ Central Local connection manager (Closed Beta)
Praveen can use this slide to intro the webinar and handover the control to Sreyanth
Let’s understand what problem Local Testing solves.
In any software development process, developers usually test their code on their machines using their dev setup
Sometimes they can run their unit tests on their own machines too
Testing front-end is no different. While implementing the backend functionality and writing HTML / CSS, the natural way to test the implementation is to check the functionality on localhost
But what if you want to test the same on browsers and devices that you don’t have with you? BrowserStack solves that problem for you.
But since your application is not publicly accessible, BrowserStack’s browsers and devices will not able to run your tests
That is where the Local Testing feature comes into picture. Local Testing feature creates a secure connection between your machine and BrowserStack, and when you run your tests, the relevant requests will be routed to your machine via that secure connection.
With Local Testing, you can access and test websites that:
Are hosted as localhost / private IP address on a remote machine
Are hosted as an intranet site on a remote machine
Serve different pages for a public domain (set locally via /etc/hosts file)
Are just HTML files in a folder