browsers Archives | CrossBrowserTesting.com

Why Your Website Looks So Bad on Internet Explorer

October 2, 2018 By Alex McPeak Leave a Comment

Just the mention of Internet Explorer is sure to bring on a migraine for developers and testers. But why is IE so often the browser we love to hate?

As we know, your web page will have slight differences across browsers because of the different ways they render HTML, CSS, and JavaScript. Oftentimes, this is minimal, but it can also lead to more major functional and visual differences that could potentially affect how a user interacts with the web applications, which is why cross-browser testing is so important.

This becomes even more evident with Internet Explorer where those differences are often more obvious. The problem is that despite all of IE’s issues, it continues to hold a share of the browser market, which is why developers and testers have to keep it in mind when building out and releasing a website.

So why is Internet Explorer so problematic, and if so, why do people use it all? Let’s take a look back at some browser history to get a better understanding of where the issues first started.

Blast to the Past

In the early years of the web, Netscape, which was largely considered the first major internet browser, ran the show. It didn’t have much competition until Microsoft came out with Internet Explorer in 1995.

This was the first time there was real competition between two browsers a.ka. the browser wars. Not only was Internet Explorer free and automatically installed on Windows, Microsoft’s advantageous financial situation allowed them to continue implementing new capabilities, such as scripting support and the first CSS implementation.

This helped IE inch ahead in the race against Netscape, and in 2003, Internet Explorer became the most popular web browser, captivating about 96 percent of the market share.

However, we know the browser wars don’t end there. Following Internet Explorer’s takeover, Opera made its way into the picture. Then Safari, Firefox, and Chrome.

Where the problem truly lies, however, is that Microsoft didn’t abide by the guidelines of the World Wide Web Consortium (W3C), which gives specific HTML and DOM specifications for browsers to follow, and decided to make their own decisions when it comes to features and plugins.

So while every other browser was following certain rules and regulations, Internet Explorer was a wild card. With users split between those newer, W3C compliant browsers and the non-compliant Internet Explorer, developers were attempting to write standards-compliant applications and running into issues when it came to IE.

Meanwhile, Internet Explorer had already grown a large user base and used competitive advertising to drive users away from other browsers. While new browsers created competition for IE, some people stayed with the browser because it was the default on Windows and they were already using it.

User interest began to noticeably wane when IE stopped releasing new developments and updates. New browsers focused on speed, security, and, to developers’ delight, standards compliance. They released regular updates for continuous improvement, and by the time Internet Explorer tried to catch up, they were already too far behind.

Microsoft hadn’t updated IE6 for 10 years, and as Android and iOS mobile operating systems emerged, Internet Explorer was not compatible.

Not to mention, Internet Explorer was brimming with security issues, criticized for using third-party technology, suffered from a lack of development tools for debugging, was slow to update, experienced slow performance, and was crawling with software bugs.

Eventually, in 2015, Microsoft ended support for Internet Explorer and replaced it with Microsoft Edge as the default Windows browser.

Back to the Future

Over time, Internet Explorer has made great strides in some of the areas they have been most widely scrutinized for by users. However, because so much of the underlying code still does not follow the W3C guidelines, it still remains a problematic browser for developers and testers.

As new versions of Chrome, Firefox, and Safari are continuously released, it’s important that we test web applications in those newest versions as well as previous versions. Though Internet Explorer is defunct, it’s still important for us to test on versions of Internet Explorer since it retains a user base.

Moreover, because of the fact that it is non-compliant, it remains a problematic browser, which means that it’s less likely to render your website the way you intended it to look and work, and more likely to crash it. This makes it high-risk, and savvy software professionals know the importance of including it in browser testing. In fact, our customers’ second most commonly tested desktop browser is IE 11, and many of our customers go back to IE 9 or further.

Of course, there are other methods for deciding which browsers to test and if Internet Explorer is one of them. But one thing is to be expected — looking at your website in Internet Explorer for the first time may make you doubt your design and development skills — just know you’re not alone. And make sure to check your website in IE from time to time.

What Our Customers’ Top 100 Tested Browser & OS Combinations of 2018 Tell Us

September 18, 2018 By Alex McPeak Leave a Comment

What are the top browsers, operating systems, and devices? We looked at data from the top configurations of CrossBrowserTesting customers tested to give you better insight.

After looking at the millions of browser and operating system configurations our customers have tested in 2018, 100 reign supreme. These results have come from a mix of people in different roles, industries, and company sizes, showing us the most commonly tested configurations out of 1500+ choices.

If you’re trying to decide which browsers and devices to test, this data should give you more to consider when it comes time to pick. Whether you’re testing in 5 browsers or 500, keeping in mind some of the most commonly tested configurations will help you outline a strategy for testing.

Top Takeaways

The top 100 combinations make up 68% of total tests – One hundred configurations may seem like a lot, but there’s more where that came from. We have thousands of browser/OS/device combos that extend well beyond this view. However, the top 100 does make up the majority of our customers’ browser testing, so it gives up a good benchmark of common trends and patterns.

The top 100 browsers include Chrome, Safari, IE, Edge, Firefox, and Opera – These are the 6 major browsers, so it’s not surprising that they’re the most common choices. It’s important to note, however, that our customers are not only testing on the latest versions of these browsers. By includer older browser versions in your testing, you get a more complete understanding of whether your application works for both Chrome users that are quick to update to the latest browser as well as those who might prolong it and be a few versions back.

Only Chrome and Safari are tested on mobile OSs – Unexpectedly, people most often test Safari on iOS and Chrome on Android. However, in this data set, there are ranges of browser versions and device models. If you are keeping your mobile testing limited to mobile Chrome and Safari browsers, make sure to keep older versions and diversified devices in mind. Keep in mind that the mobile browser share of your users may differ depending on where your users are. For example, internationally, UC Browser and Opera Mini will be more popular on mobile. It’s always good to use an analytics tool in order to get an accurate representation of your user base.

The #1 most tested browser/OS is Safari 11 in Mac OSX 10.13 – While Safari isn’t overwhelming in browser share, this Mac OSX and Safari combo is the most commonly tested configuration. Most likely, this means a lot of testers aren’t on Mac or Safari together and realize it’s a common configuration.

The most tested browser is Chrome – Considering Chrome is the most popular browser, this makes a lot of sense. The most commonly tested version is actually an older one with Chrome 43 hitting the #2 spot, but throughout the top 100 most people are testing in 63 or higher. It’s evident that people are testing on older Chrome versions and recent versions, which is good, especially being as popular as it is.

For mobile browsers, people are testing the most in Safari 8 – 11 – Again, we’re seeing that not only are people testing on a range of mobile devices, they’re also being mindful of testing older versions of those browsers. For mobile Chrome, we see users go back as far as 58. Especially with mobile devices, not everyone may be updating as soon as it’s available, and it’s important to keep this in mind with mobile testing.

The most popular mobile browser is Safari 10 on iPhone 7 – Here’s Another data point that shouldn’t surprise too many people. This configuration makes it into the top 10 most commonly tested browsers. Since this is one of the most common mobile devices, it goes to show that people are aware of these trends and including them in their testing strategy.

The second most often tested desktop browser after Chrome is Internet Explorer with the most popular version being IE11 and going back until IE9 – Internet Explorer is a consistent problem for developers and testers alike. Although it may not be the most widely used browser, the fact that it is highly problematic means it deserves a spot on your browser roster. It’s apparent that our customers know this, too.

Most popular mobile OS is iOS with iPhone 7 being the most popular device, followed by the nexus 6p on Android 7.0 – Most people are testing iPhones and the most recent models at that. This is because, unlike the fragmented Android market, most iPhone users will be using the most recent devices and operating systems. This is ideal because it means you can cover a larger portion of your user base without testing on too many iOS devices. However, as you dive into mobile testing, make sure you include Android phones too. Although their users are more diversified, it’s good to get a base to understand of the Android users’ experience.

While it’s popular for mobile, Safari desktop browser only appears 3 times in the top 100 – Safari is predominately tested on mobile devices, but not often tested on desktop Mac OSX and only appears 3 times in the top 100 despite also being in the #2 spot. Although Safari is the default browsing option for Mac, similar to iOS, it seems that people tend to download Chrome and use it more often on Mac OS than iOS. If you are testing on Mac, it’s probably best to test in both Safari and Chrome, since we are aware that users are on both and others test both.

Twenty-six of the top 100 configurations are mobile, 5 are tablets – When it comes to mobile testing, it can be confusing to know how many devices to add to your mix, but this gives us a pretty good idea — about 25% should be mobile. This, of course, is not an exact number and it should be based more heavily on your users and application — if you see high mobile traffic it should be higher, and vice versa — but it gives you a good starting point. Use this as a benchmark, and make sure to include iOS and Android with different browsers or models, as well as a few tablets, which will be telling when it comes to responsive design and verifying the way your application looks on different screen sizes.

Customers are testing as far back as Windows 7 OS and Mac 10.11 – Not only are our customers testing older browser versions, they’re also testing older OS versions as well. This is important because while new browsers are coming out the time, there are also regular OS updates that not everyone will do. Keeping these older operating systems in mind while testing will give you more insightful and accurate browser testing.

Conclusion

Our customers seem to have a pretty good idea of what they’re doing when it comes to browser testing. From the Top 100 data, we can see that users are testing the most popular browsers, operating systems, and devices to cover large market shares, but they’re also testing older versions to account for people that may not update right away.

As you approach testing in your organization, keeping these takeaways in mind will guide you to account for the most significant coverage. This way, no matter whether users visit your website on IE or Chrome, iPhone or Android, Mac or Windows, you can be prepared to provide the best experience possible to everyone.

CrossBrowserTesting Product Update: What’s New and What’s Coming Up

August 23, 2018 By Alex McPeak Leave a Comment

If you’re a CrossBrowserTesting user, you may have noticed a few new changes. Behind the scenes, our product team is always working hard to make the experience better for you. That’s why we want to share some of the exciting new features, releases, and improvements we’ve been working on this year, as well as some exciting things to come.

As always, feel free to get in contact with us and tell us what you’d like added or what integration would make your life easier. Who knows — you may just be the inspiration for the next product update.

15 Browser Releases

Did you know there have been 10 major browser releases in 2018 alone? New browser versions are coming out all the time, and every change could affect the way your web application works.

We’re dedicated to having the largest selection of browsers, which means we prioritize getting new browser releases to you within 24 hours after their rollout.

Check out our latest additions, and maybe spin up a test or two to make sure your application is working on all the latest versions.

Opera 50 – 54
Firefox 58 – 61
Chrome 64 – 68
Edge 17

3 New Real Devices

Additionally, want to make sure our customer have access to popular mobile devices on the market, which is why we’ve made three new real devices available for testing.

Because these aren’t simulators or emulators, you’re getting pinpoint accuracy in your testing, so your results are the same as if you were holding it in your hand.

You can now find the following real devices for testing, plus 3 major OS updates:

Samsung Galaxy S7 & S8
iPhone 8

Record & Replay

We’re so excited to bring a Record & Replay option to CrossBrowserTesting so that teams of all technical abilities can get started with automation with no coding knowledge needed.

If you haven’t already heard, Record & Replay is our click-to-script feature that allows you to record the steps on your manual tests once and replay them back on a selection of browsers. This not only makes it much faster and easier for you to perform a test, it eliminates the human error that arises when you’re manually repeating the same test over and over.

And that’s not all — parallel testing lets you select your test suites and play them back at the same time against different browsers, so you can run your tests in Safari, Chrome, and Firefox all at once. Talk about a time saver.

If you need more reasons to try Record & Replay, here’s seven of them.

WebRTC

We’ve switched to a new type of streaming to reduce lag and improve the accuracy of your Live Tests with WebRTC. WebRTC is an Open Source project that provides browsers and mobile applications with Real-Time Communications (RTC) that became standard in the last couple years. CrossBrowserTesting has recently upgraded to RTC, which means you should be having better experiences when it comes to testing applications that have videos and other media. You’ll literally be able to see the difference every time you test.

Other Updates

In addition to some of these more noticeable changes, you’ll see a few other updates that should help you out in your day-to-day.

Audio in Live Tests – You can now test sites that have videos and music to know whether the sound is working.
File Uploads on Mobiles – Now you can test upload functionality on mobile.
New Local Connection Chrome Extension – If you’re using local connections, make sure to update.
Record & Replay Selector – You can change the selector for Record & Replay, which lets you find an element more reliably during playback.

Performance Improvements

Browsers and devices won’t do you much good if the experience inside the CrossBrowserTesting app isn’t up to par. In addition to new features, the entire CrossBrowserTesting experience is noticeably faster.

Here are a few places you might notice better performance:

Reduced recorder launch times by 15 seconds
4 seconds faster Mac Launch times
30 Second iOS Appium Launch times
Significantly improved Android screenshot success rate

Coming Up

We’re always thinking about what’s next. We have a few browser and OS updates in the pipeline, as well as real devices like the Galaxy S9, iPhone X, and two TBD tablets. Additionally, we have a few major initiatives coming up as we plan out upcoming features and functions.

Again, make sure to let us know what devices you want to see or integrations that would make your life easier and help streamline your workflow so we can take them into considerations.

You’ll see:

5 Browser Releases
4 New Real Devices
4 Major OS Updates

Major initiatives include:

Laying down foundation work to get the latest devices out in a more timely manner and available for Live, Screenshots, and Selenium tests.
Queueing Selenium Tests for when you run out of parallel execution time.
Faster key and mouse input speed for laggy Android and iOS devices.
Continuing to work on R&R and maybe bring to mobile or add screenshots. Record & Replay is still in beta, so we’re looking for suggestions and exploring new ways to improve.

To watch the full webinar that includes all the updates from the first half of the year with Product Manager Joan Liu, check out the recording.

The Div That Looks Different on Every Browser

July 12, 2018 By Alex McPeak Leave a Comment

If you’ve been around the internet lately, you may have heard of the div that looks different in every browser.

But if you haven’t or unsure of what it’s all about, here’s the situation:

A guy named Martijn Cuppens coded a div in CSS which made a fairly simple green square. However, when you look at it across different browsers, it transforms completely into another shape.

The div that looks different in every browser https://t.co/hXmxoLA8fW pic.twitter.com/DTyOKxjhSG

— Martijn Cuppens (@Martijn_Cuppens) July 6, 2018

In fact, almost every browser gives you something different than the last. The shapes range from a square with a hole in the middle, to two green squares, to a solid square, to different versions of the original shape. The browser even affects color properties, changing the hues and shades of green depending on Firefox, Chrome, IE, Edge, etc. You can see a few versions in this CrossBrowserTesting screenshot test:

This phenomenon has gone a bit viral on Twitter, Reddit, and HackerNews with designers and devs scratching their heads and examining what went wrong.

If you look in CodePen, the HTML is pretty basic, but the CSS is where things get more tricky. If you have any experience with CSS, you know this is where browser rendering can go haywire.

Most devs are aware of these idiosyncrasies when developing for cross-browser problems. We can see from Martin’s code that he uses outline-offset, which seems to be what causes the issue.

Since each browser renders the offset value differently, it causes the shape to morph according to those varying rules.

“I wanted to know if there is a way to inset outlines (like box-shadow). Turned out ‘inset’ was a outline-style and a negative outline-offset can be used to inset outlines. The combination of these properties led to this result,” said Martin in a Twitter thread.

So what does this teach us? For one thing, it’s probably a good idea to avoid outline-offset. But ultimately, it reinforces the importance of cross-browser testing your code.

Martin’s div gives a visual representation of why cross-browser testing matters, and what can happen when your code isn’t cross-compatible. We can plainly see that there are so many ways for different browsers to interpret a few lines of code.

His example provided a fun insight into how CSS can go wrong, but you wouldn’t want this happening to your web application with elements looking different in every browser.

CSS can be complex, but by testing your site in a selection of browsers, you can avoid the surprise that comes when you haven’t checked how your site looks in Safari.

Join Our Upcoming Webinar on Creating a Cross-Compatible WordPress Website

May 17, 2018 By Alex McPeak Leave a Comment

Did you know WordPress powers over 30 percent of websites on the internet? People love WordPress because it’s easy to set up and has thousands of templates and plugins that reduce development and deployment costs, making it the most popular Content Management System in the world.

Since about 75 million websites use it, there’s no surprise that WordPress developers are so high in demand. However, with thousands of browser and device combinations, it takes more than superstar coding and design skills to be successful — you also have to be an expert in cross-compatibility. Otherwise, you risk losing users and clients.

But how exactly do you make a WordPress site that’s cross-compatible? Amidst the proliferation of devices and screen sizes, there are thousands of ways that someone could visit your website.

As a copywriter, developer, and consultant for all things WordPress, Jenni McKinnon knows it’s not about just creating a beautiful website, but also creating a cross-functional once. This means having a website that works and looks great no matter where your users are coming from.

Join CrossBrowserTesting and Jenni McKinnon in our webinar on Tuesday, May 29 as we discuss:

What it means to be cross-compatible
Determining how your users are visiting your site
Techniques for building a cross-compatible WordPress site
What to look for when testing your site and how to do it

Save Your Seat

From Bad to Brutal: Performing a Risk Analysis of Your Web Application

May 15, 2018 By Alex McPeak 1 Comment

Test automation is great, but even with the ability to cover more parts of your application in less time, testing everything is impossible. This is why you have to perform a risk analysis of your web application in order to decide when certain test cases get performed and how often.

There are many levels to creating a risk analysis, and deciding which tests go to the top level depends on largely on your business needs and the state of your application. However, these five considerations will give you a good place to start when trying to decide your most important tests.

Most Popular and Problematic Browsers – Take a look at Google Analytics or Mixpanel to see which browsers, operating systems, and devices are being used most often to access your web page. The number of configurations you include in your testing will depend on how fragmented your user base is. You want to ensure basic functionality for at least 80 percent of your users, so if 80 percent are between five browsers, you can get away with including those five in your first tier of testing. However, if it’s split between ten configurations, you’ll want to allow more time for cross-browser testing. If you do find browser use is highly fragmented, parallel testing is a good way to check off your boxes in multiple configurations at once. But we’re talking about risk here, so you also want to think about which configurations cause the most problems for you. IE 8 always breaking? Make sure to include it in your first tier.
Most Critical Unit and Integration Tests – Which tests will have the biggest impact on your bottom line if broken? For example, if you’re running an e-commerce website, the ability to enter payment details and submit them for processing is clearly important for allowing users to make a purchase. If they aren’t able to make a purchase and the application fails when they try to submit this information, they won’t be giving you their business and will probably go to a competitor. On the other hand, this will be different if you’re working in healthcare, finance, or government, for example. Identify the unit and integration tests that make up the foundation of your business as well as your application and associated risk on a scale from minimal to critical in order to determine which place at the top of your risk analysis.
Most Common Landing Pages – Ask any marketer — a big part of the success of any web application is a user’s first interaction with it. This means that you should be looking at the pages with the heaviest traffic to determine which should be tested most often in regression. Choose five to ten pages that users land on most often. Whether that includes the homepage, pricing page, or the “about us” page, you want to make sure these are consistently up to par with a healthy mix of functional testing and visual testing.
Security and Privacy – Ensuring security in any instances where personal information is being requested from your users should be of top importance in your risk analysis. Take note of any times where payment is being received, passwords are being entered, contact information is input, or confidential information is requested. In addition, any part of the application that may have an impact on the safety or financial status of your users should always be a priority to ensure that their data is uncompromised. Just ask the companies that have been victim to some of the worst software bugs in history — once you lose user trust, it’s hard to get it back.
Extended Downtime – Which functionalities will take the longest for your team to get up and running again? While your users should usually be your first priority, sometimes risk goes beyond their inconveniences when it puts the entire team on a backlog. If you already know it’s not going to be an easy fix that could affect the application downtime for days and team productivity for weeks, it should probably be high on your list when thinking of risk. Where have you had issues in the past? History repeats itself in life and your application. Log and report areas that have a high probability of failure so you can prepare your team and avoid excessive repair time.

You have to be familiar with the risk associated with different functions and features in an application to know what should be tested first, what should be tested again, and what you can deprioritize.

While you can never guarantee that code will be deployed with zero bugs, you can develop a strategy to ensure that any issues that do slip through the cracks won’t be detrimental to your application.

Using Mixpanel for Data-Driven Cross-Browser Testing

March 15, 2018 By Alex McPeak Leave a Comment

Most testers know there’s much more to testing than going into an application blindly and clicking around. In fact, planning test cases and collecting data beforehand is the best way to understand who you’re testing for, what you should test, and why.

When it comes to browser testing, this data becomes even more valuable. For example, what good is it to waste time testing Opera if none of your traffic is visiting your web app through that browser?

While there are multiple ways to decide which browsers and devices to test, you’ll find the most accurate is through an analytics tool. We’ve already explored how to find this data in Google Analytics, so let’s see how to find it in Mixpanel.

Go to “Analysis” and “Segmentation”, which will both be at the head of your dashboard.
Go to the first drop-down menu you see on the top left and pick an event, which is an action correlated with a page on your web application. You probably want to pick a page that’s either high converting or high traffic to get the best glimpse of your customer data. For example, it might be a good idea to pick your homepage because that’s probably one of the first pages people see when they come to your website. You might also want to look at a few of these events to get a more accurate glimpse of how the data changes for different user journeys.
For the second drop-down menu, you want to pick a browser. As you can see, this gives you a good look at which desktop and mobile browsers hold the majority of your users. From our data, we can see that we’d want to focus on Chrome, Firefox, Safari, Mobile Safari, Internet Explorer, and Microsoft Edge. You can refine these results by time duration and view them as a line graph, bar graph, or pie chart.
You could stop there, but why not get as detailed as possible? Add a segment by another dimension and set it to Operating System. This will tell you which configurations your users are on, so you can get more accurate information about what machines you should be testing. Looking at our example, you can see we would want to specifically test Chrome on Windows, Mac, Chrome OS, Android, and Linux as well as Firefox on Windows, and Safari on Mac.
Another data point you may want to look at is devices. Mobile testing is taking center stage, and you want to have an idea of what mobile devices people are on. By picking “Device” as your main dimension, Mixpanel will give you a good idea of what you should test for whether it be Android, iPhone, iPad, Windows Phone, or BlackBerry. Once you see how many users on each device, you can decide which you want to test for.

Depending on what resources you have at hand (in-house device lab or cloud testing tool), how divided your Mixpanel data is, and the amount of cross-browser coverage your team has allocated for, you’ll want to use this information to form a risk analysis of your application across different configurations and determine the minimum number of browsers, operating systems, and devices you should be testing on. You may find that you have only five major players that need to be accounted for, or it could be fifteen. Either way, you should check this data on a semi-regular basis to maintain accurate information about where your customers are coming from.

A Brief History of Web Browsers and How They Work

January 24, 2018 By Alex McPeak 1 Comment

We all know the basic functionality of the browser — it’s what connects you with everything on the web. Your browser allows you to shop online, watch videos, upload pictures, play games, and billions more. More technically though, the browser is a software application that retrieves and displays information from a server including web pages, text, images, videos, and other content. But that’s just the beginning.

Why do different browsers respond differently to websites, and why is there more than one to begin with? How do browsers work and where did the need for cross-browser testing come from? By understanding the history and backend of some major browsers including Chrome, Safari, Internet Explorer (IE), Firefox, and Opera, it’ll be easier to understand what goes into developing and testing a cross-compatible website.

Browser Timeline

There’s an entire history of web browsers. Before the web browsers we knew today, there were the first browsers, which are no longer in use or have highly evolved.

1990 – The WorldWideWeb (not to be confused with the World Wide Web) was the first browser ever created by W3C Director Tim Berners-Lee, then renamed Nexus to differentiate from the actual World Wide Web. Unlike today, this was the only browser and the only way to access the web.
1992 – Lynx was a texted-based browser that couldn’t display any graphic content.
1993 – Mosaic was the first browser to allow images embedded in text making it “the world’s first most popular browser”.
1994 – A noticeable improvement to Mosaic came Netscape Navigator.
1995 – Internet Explorer made its debut as Microsoft’s first web browser.
1996 – Opera started as a research project in 1994 that finally went public two years later. This was also arguably the beginning of the browser wars, mainly between IE 3 and Navigator 3 as Internet Explorer inched ahead with new capabilities.
2003 – Apple’s Safari browser was released specifically for Macintosh computers instead of Navigator.
2004 – Mozilla launched Firefox as Netscape Navigator faded out.
2007 – Mobile Safari was introduced as Apple’s mobile web browser and continues to dominate the iOS market.
2008 – Google Chrome appeared to soon take over the browser market.
2011 – Opera Mini was released to focus on the fast-growing mobile browser market.
2015 – Microsoft Edge was born to combat Google.

What’s Behind a Browser?

There are a few main components that make up the browser. For more of a deep dive to understand what happens between A (you clicking a link or typing in a URL) and B (you seeing a fully rendered web page), we can look closer at these elements to understand how browsers work.

The UI, or user interface, is basically the browser wrapper. It includes the address bar, back and forward buttons, minimize/maximize/exit buttons, tabs, and the reload page button. These are standards in all browsers. Although they aren’t technically required, all these elements are usually found on every browser page to ensure usability.

The browser acts as a client to contact the web server and request information. When you search something on Google and click on a link or enter a URL in the address bar, the web server locates and sends the information you just requested to the web browser.

It does this by first performing a Domain Name System (DNS) look to find the correct IP address. This basically means that every URL has an equivalent set of numbers – the IP address – and the DNS translates it into language so we can type “Google.com” instead of “74.125.134.102”. After that, it sends a Hypertext Transfer Protocol (HTTP) request to the web server, which sends a response with HTML, CSS, and other content files to the browser.

The browser then communicates with the network to ask for all the documents that make up the page. Browsers can also display other more advanced material like interactivity and animations made with JavaScript with internal JavaScript interpreters.

The browser engine bridges the UI and the rendering engine. This is where the rendering engine reads the HTML and XML documents and interprets it to make a Document Object Model (DOM) tree and display the content. The rendering engine of every browser is different, which means a web page will likely look different depending on the browser.

W3C Standards

So why do browsers act differently? Why can you write a web application that works properly on Firefox, but when you pull it up on Safari, certain elements are hidden or unusable?

The World Wide Web Consortium is the standards organization for the web, which has a set of guidelines for browsers to adhere certain to HTML and DOM specifications.

Because it’s not a strict set of rules, they can be interpreted differently by different rendering engines. This is largely why you see discrepancies in browser experiences. Browsers can conform the specification while still abiding by their own rules, which can cause compatibility issues.

As browser versions update, many will add in other areas or features not specified in the W3C. Whether this be for competitive advantage or just because of a grey area in the guidelines, it can create cross-browser issues for software teams.

As we already know, the rendering engine is responsible for interpreting and displaying content. Since the rendering engines of browsers are different, the content behaves different ways. Sometimes these differences are slight, while sometimes they’re major and can even make a web page unusable.

For example, Safari uses WebKit. Meanwhile, Chrome and Opera are both using Blink. Firefox uses Gecko and IE are using Trident. This means that each of these browsers abide by their own rules when it comes to rendering and displaying a web page, which can be a huge pain for developers trying to create a consistent experience.

Browser Wars

As mentioned, browser wars have been happening since Internet Explorer and Netscape Navigator went up against each other to be best in class browser of the 90’s. Netscape had previously been leading the market, but with the release of Internet Explorer 3, Microsoft took the lead. Since it was automatically included in the Windows OS, it became the standard for many desktop users.

The same situation happened when Safari came to be in 2003. Whereas Macintosh users were previously on IE or Navigator, Safari being preinstalled in Apple’s OS mean that it gained control of that desktop market.

After some time of IE beating out Navigator, Netscape made the code for the browser open source and gave it to Mozilla. However, when Firefox was introduced in 2004, it saw a rapid rise in popularity for a few years. That is until Google Chrome was released in 2008 and quickly fought to be the favored browser, which we still see today.

Of course, in between, we’ve also seen increased mobile use and differences in mobile browsers as well as the introduction of HTML5 and CSS3. This all contributes to the browser wars between Internet Explorer, Safari, Firefox, Chrome, Opera, and, recently, Edge to be the preferred browser for surfing the World Wide Web.

That competition comes in the form of frequent browser updates and version releases that you may notice today as each browser tries to one-up the other in speed, security, features, and design. For developers, many will try to program in a popular browser or a browser with a standard rendering engine so that the page is cross-compatible. For example, most people avoid developing in Internet Explorer since it’s known to be so problematic.

Modern Browsing

Today, Chrome still rules desktop browsers while Safari owns the mobile browsing market. However, there still is no defined winner. The browser wars are still going strong and fragmentation is a more prevalent issue than ever due to the frequent updates and releases of different browser versions and operating systems.

Browsers preferences are also largely dependant on demographics including age, country, and even job. For example, many schools and companies have certain requirements about what devices, operating systems, and browsers users may access and don’t permit individuals to update on their own.

Additionally, as browsers continually update versions hoping to be the next Google Chrome, there’s no saying when one will finally surpass its popularity or when another company creates their own browser to enter the mix. In fact, with Firefox’s recent Quantum version, more and more users and considering making the switch in favor of a faster browsing experience.

Not to mention, the underdog browsers still capture a distinct user base. While something like UC Browser might not capture a large percentage of the internet in comparison to the big five, it still serves about 500 million people.

So, what lessons can we take away from the history of web browsers? As software professionals, the only sure-fire way to approach this diverse user behavior is to develop web applications to be cross-compatible and test them across different browsers to make sure they’re visually and functionally acceptable.

Now that you know browser history, find out how to develop a cross-compatible website.

2017 in Review: 9 Times That Proved Why You Need a Cross Browser Testing Tool

December 28, 2017 By Alex McPeak Leave a Comment

It’s been another tumultuous year, to say the least, both in our everyday lives and in the world of software testing. If nothing else, most of us can say that we’ve learned a thing or two in 2017.

Of course, what’s really stuck out to us is the number of occurrences that continue to prove why using a cross-browser testing tool is so critical. Here’s a roundup of our top 9 from 2017:

iPhone X – Apple turned the world of smartphones on its head once again with the release of iPhone X. While the notch feature may be controversial, the larger screen suggests a new era of responsive design and emphasizes purposeful UI choices. Organizations that don’t test for emerging technology, and mobile devices in particular, will be left behind by their more cutting-edge competitors who place a larger emphasis on mobile testing. In this way, the iPhone X has exemplified the importance of staying on top of new and popular devices in testing.
iOS 11 – For the iPhone users that may not be convinced to order the X in light of its hefty price tag, the iOS 11 update made its way into their lives with promise of more emojis, upgraded photo filters, a shiny new App store, redesigned control center, and smarter Siri. This means, however, that as more Apple addicts adopt the most recent iOS, you have to test on it, while keeping a few older iOS versions on hand as well (hint: we do that for you). And, if you’ve been avoiding iOS 11 because you heard there were a few autocorrect glitches, you can use us for that too.
Selenium Conference – It’s obvious that the testing community’s support continues to grow and grow for Selenium, and this open source tool isn’t going anywhere, as proven by the growing popularity of Selenium Conference. On the contrary, it’s predicted to become even more widely adopted in the next few years. As automation engineers become better acquainted with best practices in Selenium, the need for cloud testing tools to more effectively and efficiently run scripts will rise as well. Not to mention, open source projects have been and will continue to be heavily supported by the testing community.
Year of Chrome – Google Chrome has been users’ most beloved browser for some time now. While most can agree on Chrome’s superiority, Google doesn’t differ from other browser brands with their release history. By putting out multiple versions every year, Google can really mess with a cross-browser testing strategy that heavily relies on Chrome. In 2017 alone, Chrome had eight browser version releases. But don’t worry, we had all of them within 24 hours of release, plus a plethora of historical versions…all the way down to Chrome 6.
Firefox Quantum – Of course, we can’t forget the other big browser news this year. In fact, with the release of Firefox Quantum and it’s new lightning fast speeds, some may be willing to abandon Chrome altogether. It’s a good thing we have the browser for your users who have already moved to Firefox — and you don’t even have to switch over to see what all the fuss is about.
SmartBear State of Testing Survey – As per SmartBear’s first State of Testing Survey, the majority of over 5,000 professionals in Software Development, QA, and Testing agreed on the importance of cross-browser testing and include it in their workflows. Two-thirds of survey participants reported testing on mobile devices, and 80 percent of respondents reported testing on more than one mobile device. Additionally, 77 percent of respondents are doing some parallel testing by running at least two UI tests in parallel. Though the survey showed there was still much to be improved, we see a clear adoption of best cross-browser testing practices with the prediction of more to come in 2018.
CBT Product Updates – You reached out to us, and we listened. Actually, we did better than listen, because we implemented a lot of new features that you requested in 2017. From the option to fast forward video playback, to test reporting, and our new integration with Applitools Eyes, CrossBrowserTesting just keeps getting better and better to provide you the most comprehensive browser testing tool on the market.
#WhyTestingMatters – Whether it’s affected you personally or professionally, everyone has encountered examples of why software testing matters. From autocorrect glitches to compromised traffic predictions, testing can be the difference between gaining new customers with a great product or sacrificing your brand’s reputation. Similarly, cross-browser testing oversights happen every day. Don’t be the website that only works on Google Chrome — test the application before it’s released to your customers.
Nokia 3310 – Look, we’re not saying that a ton of people are going to trade in their smartphones for a slice of the simple life or just to play Snake on the revamped Nokia 3310. All we’re saying is that we have Opera Mini if they do.

Looking Towards 2018

As we make our way into the new year, we predict to see these underlying themes further evolve. Many of these patterns that we’ve seen will continue to grow, and trends like automated testing, open source software, faster delivery cycles, DevOps, Agile, cloud-based testing, and mobile testing will become the standard for QA teams in 2018.

6 Ways to Choose Which Browsers and Devices to Test

December 21, 2017 By Alex McPeak Leave a Comment

It’s no secret that testing an application solely on the machine it was developed on isn’t the best way to know whether or not it’s cross-compatible. Once you decide between building or buying a device lab, there still comes the issue of deciding which browsers to test. After all, you can’t test everything.

That’s exactly why we’re outlining the best methods for picking which browser, operating systems, screen sizes, and devices are going to be most beneficial to your team in testing. By choosing the configurations to account for as many users as possible, you can form an intelligent desktop and mobile testing strategy.

Analytics

Google Analytics is a precise method of finding online user data because it looks at who’s actually coming to your website and how.

To get a list of the devices your users on on with Google Analytics, you’ll want to go to “Audience” on the left side, click down to “Mobile”, and then click “Devices”.

This will show you how many people are visiting your application on what kind of mobile device, and you can get more information by setting a secondary dimension to view additional data such as service provider, operating system, mobile brand, and screen resolutions.

Additionally, you can go to “Overview” under “Mobile” and set the Secondary Dimension to “Browser” to see find out what browsers are being used on desktops, mobile devices, and tablets.

You can also find out what browsers your customers are using by going to “Technology” under “Audience” then clicking “Technology” and “Browser & OS”.

Click “Operating System” as the Primary Dimension and set the Secondary Dimension to “Browser” for the most common configurations. Set the Secondary Dimension to “Browser Version” when on “Browser” as the Primary Dimension for more specific browser data that will tell you how what version users have.

As far as understanding your users goes, this information gives you the most accurate glimpse of the devices you should be testing on. Make a list of some of the most popular browser, operating system, and device combinations to prioritize during testing.

You can also use other analytics engines, such as Mixpanel, to get an understanding of which environments your users are on.

Most Popular Browsers and Devices

While Google Analytics is a great way to understand the current users that come to your website, it’s not very predictive nor does it account for your potential users.

Because of this, it’s a good idea to include a few of the most popular browsers and devices even if they aren’t seen on your analytics list. If a high number of people use them, it’s logical that you want your web application to support them as well.

For example, the top web browsers are Chrome 62, Chrome 61, Safari 11, Safari 10, Firefox 56, IE 11, Firefox 57, and Chrome 56, while the most popular desktop operating systems are Windows 7, Windows 10, Windows XP, Windows 8, Mac 10.12 (Sierra) and Mac 10.11 (El Capitan).

In terms of operating systems for mobile devices, the most popular are Android 6, Android 5, iOS 10, Android 7, Android 4, iOS 10 and iOS 11.

You also may want to think about popularity by regions. If you your organization is international, you will probably want to prioritize Samsung phones when thinking about testing mobile devices, for example, since they lead in worldwide popularity. However, if you’re customer base is mainly located in the United States, you’d want to focus on testing Apple products.

Of course, this will continually change from country to country and might even change month over month, so you will want to continuously check the market share for your target market.

Testing the Old and the New

You also have to keep in mind when looking at analytics and that sometimes they’re more prone to show up in a report because the web application is actually optimized for them, so it makes sense that people will visit your site and come back if the page already works for them.

If you really want to touch all the bases, it’s important to include a few old browsers. Older browsers and devices are going to be more problematic, so while it’s good to check popular models, you also want to test on ones that are less popular but still capture a percent of your users.

You also have to consider devices that may be new to the market. While the number of devices you have now may seem like it could get the job done, new devices come out on the time. If your users have them, you want them too.

The new iPhone X is one case where testing would be important. Up until this year, Apple’s iPhones have generally taken on the same design with a few slight changes. The iPhone X was a big deal when announced because of how different it looked due to a larger screen that had a lack of bezels formerly seen on the front.

Additionally, the notch at the top of the screen has proven to be an issue during visual testing, so running your web application on a iPhone X simulator would be a smart move to avoid unfortunate design issues.

Learn from CrossBrowserTesting Customers

Our customers are pros when it comes to cross-browser testing. Recently we looked at some of the most popular browsers, operating systems, and devices our customers have been testing on this year. We found some trends and patterns in this data, as well as some really interesting insights on what they prioritize in testing.

Check out the full study in What Our Customers’ Top 100 Tested Browser and OS Combinations Tell Us.

Whether you’re testing in 5 browsers or 500, keeping in mind some of the most commonly tested configurations will help you outline a strategy for testing.

Problematic Browsers

When thinking about doing a risk analysis of our applications, we want to test pages that get high traffic and business crucial functions, but we also want to test areas that we know are problematic in order to avoid expected downtime. The same is true with browsers.

While you may find that your users are saturated on the most recent versions of Chrome and Safari but you also acknowledge that your application has difficulties in another browser, it’s probably a good idea to add that configuration to your mix.

Internet Explorer, for example, may not take up a large portion of your user base, but it’s known to be one of the most problematic browsers. You may understand that Chrome, Safari, or Firefox is a better browsing option, but someone that isn’t as familiar with technology might still be using a past version of IE on an older OS, and you may want to check that your web application still works despite their outdated machine.

Even if you aren’t running tests on 100 browsers every regression, it’s a good idea to do some exploratory testing and visual testing on a wide array of browsers and operating systems in order to get a better understanding of which ones are most likely to create issues for your team.

Sample List

Still don’t know where to start? Choose how many configurations you want to test and follow our testing guide based on these combined factors.