In this post, I would like to show a few things that you might want to know about on-premise cross-browser testing and why our tools choose this approach. Of course, you will also learn if on-premise testing is the right solution for your use case or not.
I think most of you will have this problem that you need to test your work in one or more browsers to make sure that it works. This is a process we normally call cross-browser testing because you test in different browsers. At first glance, it might sound really easy, and straightforward to do, but unfortunately there are quite a few different browsers, and of course not every browser will run on your platform of choice.
Let’s say for example you’re using a Mac and so you might be able to test with Google Chrome, and Mozilla Firefox just fine. But if you want to test against Internet Explorer or the new Microsoft browser, Microsoft Edge, you will need to resort to some Virtual Machine or tool to get this testing done as because Internet Explorer does not run on Mac OS.
How Do Online Testing Solutions Work?
The first thing that you can use to do this testing is one of the many online tools available. Well, how do these tools work? It’s really easy if you take a look at the below diagram.
On your local machine you can start a browser. If you want to test with Internet Explorer, you can’t launch it directly on that machine though. What these online tools do is that it will launch a Virtual Machine in the cloud where the actual browser you want to test is running. Let’s say for example on the left-hand side you have Mac OS, you will then launch the Safari browser, which runs on Mac OS, and connect to an online solution that will provide you with a Virtual Machine that runs Windows, and in this Virtual Machine then Internet Explorer can run.
The connection between your browser and the browser in the cloud is then made through the Internet, so you will see the browser using a remote desktop like connection. The browser online will then connect to the page under test, provided it’s available on the public Internet. This, of course, has the advantage that your machine doesn’t really matter here anymore.
It’s totally irrelevant which operating system your local machine is running, as long as you have a browser, you will be able to test just fine. The downside is that the page you want to test has to be available to the public Internet because otherwise the Virtual Machine and the cloud will not be able to reach it. And all this back-and-forth traveling for the remote session of the browser through the Internet will introduce network latency.
It will delay user input, for example, you will not be able to quickly see animations. Furthermore, you rely on your Internet connection, which has to be reasonably fast for this to make a great experience.
Let’s say you want to test a page that runs in your internal staging environment or on your local machine. In this case, the solution will not work like this. As we see in the diagram below we need to add another tool to make it work.
Testing can now be done by using a so-called VPN tunnel, which will connect the online Virtual Machine to your local machine / network. The process is that the browser you’re running locally, will connect through the Internet to the browser in the online Virtual Machine and this browser inside it will then turn around, and connect back to your local machine through a VPN tunnel to get to the page under test.
Of course this adds two more complexities to the whole process. For one, you will have more network latency and you have the encryption inside the VPN. The other thing is, if you’re working in a bigger corporation, this VPN tunnel will need some IT approval and firewall changes.
While these online testing solutions make it totally possible to test any kind of page, even if it’s not available to the public internet, it can get messy in the details.
How Do On-Premise Solutions Work?
So what’s the alternative here? Well, the alternative is that you can remove this online Virtual Machine from the whole process to make it easier to test. This is where an on-premise solution comes in.
Let’s take a look at the exact two examples again with on-premise testing solutions. Again, the simpler example is that you have a page under test, which is available to the public Internet for everybody to see, and you want to test against this in one or more specific browsers. Now in the diagram, we can see that the local machine runs the testing browser directly.
As an example let us take Google Chrome. You might not want to install it on your machine, especially not 20 different versions of it for testing. This can be taken care of by the on-premise solution tool which is running this browser on your local machine directly and can connect to the Internet and the page under test. We have eliminated the whole step with network latency between your browser and the online Virtual Machine.
The most obvious thing I’ve skipped over here is that not all browsers run natively on your machine. What will we do in this case? Really simple, if the on-premise testing tool cannot run the browser natively on your machine it can just launch a Virtual Machine on your local machine. We have traded using more of your local system resources against the network slow down that is incurred by running the browser in the cloud.
To be honest there is really no good reason that the Virtual Machine needs to run in the cloud because we can’t get any real advantage. If we don’t want to test a page that’s available to the public Internet we can make this even more simple.
As you can see in this diagram everything runs on your local machine now. With an on-premise tool, the browser you want to test for is also running on your local machine, or on a Virtual Machine on your local machine. This gives us direct testing possibilities even if in the extreme scenario where the local machine is standing somewhere in a secure lab or does not have any Internet access. You can still use the on-premise solution just fine in contrast to an online solution that will not work offline.
Advantages Of On-Premise Solutions
Now that you know how both of these approaches work let us take a look at the advantages of an on-premise solution:
- The most obvious strong point is that you can much more easily test local or internal staging environments. There are lots of internal applications that will never be available to the public Internet but will still need to be tested against multiple browsers.
- The next great advantage of on-premise testing is the experience you have with the browser that runs directly on your machine: It is more native. You have less delay between your user interaction and the browser responding. Let’s say for example you’re testing animations, or you’re testing video inside the browser. This works much more fluidly than it would in the online solution.
- Because it works on your local machine the data you’re working with does not travel to any third party provider. This is great news if you need HIPAA / PCI compliance.
- Running an application on your local machine is also much easier for your internal IT department than using a cloud-hosted provider.
- The last point here is that all online solutions are subscription-based in pricing, so you pay a fixed amount per month to get access to all the browsers. On the other hand, an on-premise solution is normally a one-off purchase, because the vendor doesn’t need to pay for any ongoing server costs.
Let’s take a look at two different solutions that are available on-premise. The first one I would like to show is called MultiBrowser, which is a windows only tool.
The MultiBrowser tool for manual testing has three main features. The most useful feature is to start different browser versions directly on your local machine. In this browsers we can use the developer tools, plug-ins, and everything we need for testing. This way with the application of MultiBrowser can run different browsers without installing anything other than the on-premise tool itself.
There is also the possibility to test responsivness of designs. The tool will be able to create a screenshot in any screen size. This way we can see if our page works, and displays correctly with different screen sizes. And a mobile emulator is also integrated, which has the correct screen size, pixel density and so one for testing with mobile devices.
Let us take a look at a different tool as well, which is called BrowseEmAll. The difference is that this tool is cross-platform compatible, so you could run it on Mac OS, Linux, and Windows. Again you can use the live testing feature to start different versions of browsers regardless of the fact if they’re installed on your local machine or not.
Of course, this one has mobile emulators as well. The difference is mainly in the UI experience. Here the mobile emulator will start using a Google Chrome skin instead of a real device skin. And lastly screenshots are available here as well, this time also for different browsers.
On-Premise Is For You If…
When might on-premise testing be a good fit for you?
- On-premise tools work much better for desktop browsers.
- An on-premise solution is also worth a look to you if you have any kind of security concerns.
- You are working with sensitive customer data or you have the need for testing applications that should not be visible to the public? Again an on-premise solution will make this possible!
- If you need to work off-line an on-premise solution is also a better fit for you.
- And lastly if you’re developing, or testing things that need a native testing experience (video, animations, games).