In this webinar, you will learn how you can test for different browsers directly on your machine. No SAAS or server-side software involved.

Transcript:

And welcome everybody to today’s webinar about cross-browser testing right on your machine. Before we get started, just two quick reminders. One, you get an email with the recording of the webinar roughly one hour after the webinar ends, so you don’t need to record yourself or take furious notes.

And, of course, at the end of the webinar, we will do a Q&A session. So, if during the webinar at any point you have any questions, you can go to webinar UI to right normally, and enter some questions, so we can go through them at the end, and I will try to answer every question as good as possible.

Okay, that’s that. Let’s get right into it. Today, we will take a look at how you can do cross browser testing right on your machine without using any third party service provider, which would run your browser in the cloud somewhere, and this might be preferable to the cloud approach for a few different reasons like you need to test a lot of pages that are either running in development mode and are only available on your local machine, or you need to test some staging environment that is normally not available to the public internet, so you would have a harder time testing this with the cloud first approach here.

For this testing, we will have a few different things. We have an example page here, and you can see it here on my screen, which is just a simple demo page with a header, and a function to log in and log out as a user, and, for demonstration purpose, I have introduced a bug in Firefox here, which will change the layout. So, in Firefox, the layout will be broken in some way, and the login functionality will not work in Internet Explorer.

Please don’t get confused. The page is in German here because we are a German-based company, but you don’t need to really understand much of the page. You just take note that the header here is a darker color in background, and you can log in by entering your email and your password and then click the button here, and then, of course, you can see here that the application is greeting you and you can log out again to get back to the main page, and, as I said, the log in functionality will not work in Internet Explorer, and we will now, in turn, take a look at how we can find this box, and diagnose the problems using a tool that runs entirely on my machine here.

Also, please take note that not all browsers we will use for testing are installed on the machine natively. So, here on my machine I have obviously installed Google Chrome, but, other than that, I don’t have currently Firefox installed, and here, understand, of course, I have some version of Internet Explorer installed, but not all different versions of that.

Okay. So, keep this example page in mind, and now we will launch to what we will use for testing, which is a desktop application and it’s called Browse Em All, and this desktop application runs entirely on my machine here. If not for the webinar, I could use it without an active internet connection. I could use it on my laptop while flying to the US for testing, and I could do all sorts of things even if I’m in a secure or offline environment like a secure lab or something.

Also, all things that are tested here, all pages, all data that I enter, is not logged in any way so that I could test security sensitive applications like an online banking application without having to share the data I use for testing with a third party, or to make sure that the third party that I use for testing is, for example, PCI or HIPAA compliant.

Okay. So, here we have the main screen of the application and we will just use it to make the different browsers for testing available to us, which we can do in the live testing section here, and, in the live testing section, we can now launch different browsers to test our page, and what my approach always is for cross-browser testing … During development, I will settle on one browser that I and my team use mainly for development if that’s possible and every developer can agree and use the same browser, make the process so much easier later on.

So, in this example, let’s assume we are using Google Chrome during development, and so we should be reasonably sure that the features we developed will already work in Google Chrome. That said, of course, we need to check this because different developers could, in theory, introduce different bugs even if they test for the same browser.

So, here, first let’s select our URL, and you can see that the page is running on local host so it’s only available to my machine here locally and not available to the public internet, and in the first step, we will select a browser we want to test in and we will select Google Chrome here, and now what the tool does, it will launch an instance of Google Chrome, a clean instance, so we have no cookies from other sessions or stuff like that, and this would even work if we don’t have Google Chrome installed on our machine.

And now as we can see here, the page comes up just fine. The header is a dark color and, if I try to log in here, it should work as expected. Of course not. Here we go. So, now I’m logged in and it seems like the application works just fine in Google Chrome. Of course, if we would find any bug, we could just open the developer tools like in a normal Chrome instance and take a look at the code, source, the CSS to find any issues.

Okay. Now that we’re sure that the page actually works in the browser we used for development, the next step would be to make sure that the page and the functionality also work in the other browsers we want to support. Now, for this example we will assume that we need to at least support Google Chrome, Firefox and Internet Explorer, but, of course, the actually supported browser list will be different for your application for your company depending on your customers and your different needs, simply.

Okay. So, now that we know that Google Chrome is working, we will move on to Firefox in here. Of course, we could now test here a lot of different versions of Firefox, but for sake of argument, let’s just assume we will test on the latest version of Firefox here, and, as before, the tool will launch Firefox on my machine even if I don’t have it installed, and I can browse to localhost, which is only available to my machine here.

And we can see the glaring, obvious bug again if we show the correct page in Google Chrome, the header is black or dark at least, and in Firefox, now it has a background color of red, which I think is a bug here because it looks really bad, and so we will need to find out why that is. Still, we also wanted to test the login functionality so we will try that as well to see if there is more than one bug we need to fix.

See if I can type in a password, yes. So, log in seems to work fine in Firefox and we only have the layout problem here above that we need to fix, and, again, of course, I already know the bug because I introduced it before the webinar, but if we take a look at the developer tools, which are also available in Firefox, then we can actually quickly see what the problem is and I think it will be something with the CSS.

Right, and here we can clearly see that there is a rule for the navigation to be red, which seems to not be triggering in Google Chrome, but here in Firefox … And if we remove this, we see that the error here is fixed, and Firefox will also tell us which CSS file and which line the problem lies in. So, here we can quickly take a look at the code. We have the correct file already open and here is the line, and, as you can see here, we have a special rule, which only applies to Firefox, and it turns the header red. Now, if we removed this line and reload in Firefox, we can see that the header is actually black again so we have fixed this bug for now.

What is always important if you find a layout bug and fix it, and you’re in the middle of a testing cycle, testing cycle means that you run through all the browsers you want to support … It’s always very advisable to retest our change on all browsers previously tested. So, in this example, we already tested for Google Chrome, but we are not 100% sure that removing this CSS will not introduce a bug in Google Chrome now so just to make sure that this didn’t happen, we will start Google Chrome here again, and it’s already suggested in our recent tests. So, I just want to click just to make sure that the layout is still correct in Google Chrome as well. You can see here, now on both browsers, the header is a darker color.

Okay. So, Firefox and Google Chrome seems to work just fine, and now we can move on to the third browser that we want to support, which is Internet Explorer, and, in this case, we will use Internet Explorer 11 because it’s the newest version, but the tool, of course, would allow for other Internet Explorer versions here as well, depending on what’s the oldest Internet Explorer version you want to support, and, as I said before, you don’t need to have all these Internet Explorer versions installed on your machine. It would work just the same if, for example, I would have Internet Explorer 9 installed on my machine here instead of whatever version that’s installed, and of course on Windows, you can’t install more than one version of Internet Explorer anyway.

Okay. So, let’s take a look at the page in Internet Explorer 11, and here, we can see that the header looks correct just like before with Firefox and Google Chrome so we did not introduce any new bugs here, but we didn’t test the log in functionality yet so we’ll take a look if this works, and we can see it seems that it didn’t work because we are not logged in even though there is no error message like the password was wrong or something along those lines. User not found would be another example.

So, to find this bug, most likely the developer tools of Internet Explorer will not help us very much because it seems that this is a server-side problem because it was correctly posted to the server to log in, and try this again here. You can see the page reload and there is no further error.

So, let’s take a look at the application itself, and it doesn’t matter if you don’t know any C Sharp because it will be obvious in a second what the problem is. Here, we can see that the method that will validate the user, and here, we can see that there’s a special case if the browser is Internet Explorer. In this case, it will not try to validate the password at all. It will instead return right away and give us the login screen back, and this is obviously wrong so we will remove it here because we want to allow users of Internet Explorer to log in as well.

Let’s restart the server just to see if it works, and now we can try it again here in Internet Explorer, and we can see that now the login works just fine in Internet Explorer as well. You can see here that it greets our user and we can log out, again, just fine.

Okay. So, now we’ve fixed the login functionality as well and it works in Internet Explorer 11, but is our fix really the right one? Maybe this rule for Internet Explorer was there for a reason, and now we broke the login in Google Chrome or in Firefox. For a full, complete test cycle, we should test this again just to make absolutely sure. Let’s start Firefox and Google Chrome again, and see if our log in still works here or if we introduced a new bug.

Okay. So, it seems to work just fine in Chrome still, and if we take a look at Firefox, it works here as well. So, it seems like we’ve found all the bugs both in layout and in functionality, and now we can be quite certain that our page, so far, works correctly in Google Chrome, Firefox and Internet Explorer, which are all target browsers for this example.

Now, if we continue to develop the page, we will need to test every new feature with all these browsers and, of course, to get the full cycle, we will also need to test all the old functionality again. So, now let’s say we add a password reset feature to the page. We would then need to test this password reset feature in all the three browsers we just mentioned, but of course, we would also need to check if the login still works in all those three browsers, and we will also need to check if the layout is still correct in all of these browsers.

You can see where this is going. This will be a tedious task if you have to do it again and again and again and again, and if you’re doing this manually, there will be problems and tests will be missed, features will be missed, bugs will be missed. That’s just the way it is with a lot of manual labor so to speak. There will be problems introduced.

So, for reducing the amount of work, we might want to take a look at more tool support or more automation to automate this kind of testings, and the tool will support both. Just as a really brief glimpse because we will do more webinars in the next few weeks and cover this topic in more depth. Just to give you a quick glimpse, you could do visual testing to see if the page layout is correct in all browsers that we want to support. Here, we can see the tool has tested Internet Explorer, Firefox, Google Chrome, taking a screenshot and it tells us what we already know in this case, the layout is not different between the different browsers.

So, if we take a look at the screenshots here, we can see that the layout is identical between Internet Explorer in this case and Firefox and so on and so on, and if we want to automate something like testing the log in functionality, we could see the test recorder to record and rerun later on the test which does a log in, or we could write a Selenium test and run the Selenium test against different browsers later on in this scenario, depending on your preferred style of testing.

But for today, we have seen how we can test with different browsers right on our machine here without having to use an online solution, or run any virtual machines on our machine or in the cloud, and without having to make our test page available to the public internet one way or another to test on an online service.