Taking a look back at how the internet has evolved can certainly be nostalgic. Have you ever visited the ‘Way Back Machine' and looked for companies that have been around for a while? It’s amazing how far the web has evolved. In its infancy, sites were mostly static, there were few content creators, blinking text and bad gifs were drastically over-used and web applications were just not sophisticated. The internet was often accessed via all-in-services like AOL or Prodigy, and for advanced users, a dedicated browser like Netscape Navigator.
Fast forward to the late 90’s where usage of all-in-one providers diminished and a browser war began between IE and Netscape. At the time, web standards were poorly defined and web applications were gaining popularity. This created the need to test applications across browsers to ensure functional and visual defects were detected. Cross-browser testing was born – and quickly evolved from companies creating a local matrix to the usage of cloud-based VMs.
HTML 5 & Responsive Web
As mobile became dominant, so did the use of HTML5, CSS and responsive web applications. As a result, a new generation of browser wars began with additional players entering the mix, specifically Google Chrome, Firefox (born from Netscape), Safari – and Internet Explorer, which remained widely popular. At this point in time, traditional cross browser testing began to show scalability issues – and naturally so. There are now four main browsers that are updated far more frequently combined with multiple viewports and we haven’t even discussed operating systems.
Traditional cross browser testing executes tests built on your existing testing framework, (think Selenium), across all browser, viewport, and OS combinations specified by the engineer. This means a 2 minute test would need to run separately across each combination in the matrix. The issue that began to arise was the result of brittle functional tests, and the need to maintain connectivity and connection of those tests for every single browser, viewport, and OS combination.
The Modern / Intelligent Web
Today, we are in a phase referred to as the “intelligent” web. With chatbots, and more sophisticated omni-channel applications being driven by AI and ML. JavaScript, HTML, and CSS standards are strictly driven by W3C and WHATWG bringing deeper consistency across modern browsers. Additionally, modern JavaScript solutions like jQuery & Babel have smoothed out browser support for JavaScript APIs, making the testing of browser engines themselves relatively binary. In a nutshell, the modern browser engines have been tested to near perfection.
Because of standards, you might expect any combination of browser, OS, device, and viewport size to function identically. And, unless you use platform-specific or device-specific functionality, that’s a reasonable expectation. So, what should you expect from cross-browser testing?
Functional differences between modern standards-compliant browsers happen rarely. You expect the browser to receive and process the same HTML, CSS, and JavaScript from the server. Rendering differences do occur, though, as each platform uses its own rendering engine. And those rendering differences can result in real-world functional differences from a user’s perspective.
So, if your cross-browser tests run the same DOM across different devices, do you need to keep asking the server to serve up the same content multiple times to find defects caused by rendering?
The Next Generation of Cross Browser Testing
As you’ve read, traditional cross browser testing is not providing the ROI it once did, but a new modern approach is bringing new hope to quality-focused teams.
Applitools Ultrafast Grid leverages Visual AI (AI powered computer vision) to test across browsers faster and with more coverage than ever possible.
Here is how it works:
Your test suite is executed locally on a single browser. During execution, the Applitools SDKs capture the DOM & CSS rules for every browser state and sends it to the Ultrafast Grid. This is a one-way connection thus does not require a reverse proxy or IPSec VPN – something any IT team with a focus on security can appreciate.
Next, the Ultrafast Grid renders the DOM in parallel using containers and grabs a screenshot across each browser and viewport combination. The screenshots are then sent to Applitools Eyes for Visual AI analysis. This entire process is blazing fast – in a matter of seconds you are viewing results from the test run.
Because the tests are executed only once, connectivity and connection to the browser are only required for that single run which results in incredible stability of the run. What’s more – that single run also reduces the required set-up and tear down of data (data consumption). Parallelization and containers result in incredible speeds and Visual AI can replace many of the brittle locators in your test code resulting in further stability.
Above: Diagram of Applitools Ultrafast Grid
Summary
In summary, your test coverage plan should be focused on your specific needs. If older browsers are still supported – you will want to ensure that you run your regression suite on each of those browsers and versions, plus a modern browser. By combining traditional cross-browser testing with the new modern approach, you can save time with faster builds and save money by reducing dependency on expensive cloud testing providers.
The intent of this post is to share with you details of the Applitools Ultrafast Grid, an evolution in cross-browser testing designed for modern teams who test modern apps at scale.
The Ultrafast Grid represents the first true breakthrough in cross-browser testing architecture since it’s initial inception many years ago. It’s important to understand the differences between the traditional approach to cross browser testing and the modern approach that Applitools has taken.
Top comments (0)