With help from Gerhard, a QAInsight reader, the User Agent Switcher MONTSTER XML file has been updated to use the new, folder feature. Also, another IPhone user agent has been added as well as one for Chrome. As always, the permalink is here, and can be found in the right navigation under the “My Testing Tools” header, link: “User-Agent Info and Tools“.
Archive for the ‘Web Browsers’ Category
It’s never really been quick or easy when I mine the data (which seems to be about once a year), but when I reassess the cheat-sheet I typically spend most of the time re-reminding myself of how to gather the info for the various browsers, all the while discovering new sources. Here is my high-level browser info excavating process:
- Get the info from the browser itself:
- Install it
- Look at the browser download site, FAQ, & Release Notes
- Look at the user-agent string at browserhawk.com
- Look at the installed assembly version numbers and text files
- Look at the Help/About section
- Look at comments in source control and source code (if available)
- Search the web
And on to a few lower-level details for a few of the most popular browsers:
- Rendering Engine: Trident being the name of the IE rendering engine, it was once believed that the version of Trident matched the the version of the MSHTML.dll found at C:\windows\System32\. But with IE 8.0, the IE team has a reference on their blog that rendering engine in 8.0 is Trident 4.0 which can now be found in the user-agent string. This version conflicts with prior data I had gathered but we’ll run with it. Hopefully, from here on out you can just gather the version from the user-agent string, only time will tell. Here is an example user-agent string for IE8: “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0;)
- Rendering Engine: Webkit is the rendering engine for Chrome. To get the rendering engine version, in the browser URL bar just type “About:”. The version will follow the “Webkit:” key. Notice that the User Agent contains the same Webkit number, hence the rendering engine version can be gathered from the User Agent string also.
- Rendering Engine: Firefox uses the Gecko rendering engine and the version number can be found in the user-agent string (can be seen by typing “about:” in the URL bar or going to Help->About in the menu). For example in the following string: “Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:126.96.36.199) Gecko/2009042316 Firefox/3.0.10”, the “rv:188.8.131.52” is the version and the “2009042316” build number.
- Rendering Engine: Webkit is the rendering engine in Safari and the version can be found in the user-agent string. For example in the string: “Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Safari/528.17” the version number is 528.18. This can also be seen on the webkit.dll file property “Product Version” in Windows (\program files\safari\).
And there you have it, the method to my madness. If you have differing or better data please feel free to add it in a comment.
This link/post will serve as the official place for the Browser Compatibility Cheat-Sheet and the post can be permanently accessed from the side navigation. Any new updates/links to the cheat-sheet will be put in this post.
What is the Browser Compatibility Cheat-Sheet?
Download the latest Browser Compatibility Cheat-Sheet here (zipped Excel file):
BrowserCompatCheatSheet-052509.zip (8.74 KB)
Written over a weekend, Sean Sullivan the CTO of Black Baud lab’s created an iPhone browser simulator, and it’s FREE!
Basically, what he did was take the Webkit rendering engine from Safari and embed it into a Windows application. Browser requests are being made through Safari Webkit using an iPhone mobile user-agent string. Here is an example of the user-agent string that came into my website while capturing the screenshot at the bottom of this post:
Setup is as simple as installing Safari, and then running the .exe from Black Baud lab.
Check out the details and a screencast on Black Baud lab’s site.
BUT.as always, when it comes to browser compatibility testing there is nothing like testing the real browser on the real platform. Keep these things in mind my dear browser compatibility testing friend:
- The rendering results will be based on the version of Safari for Windows you have installed and its Webkit version. This will likely not match the version you intend to test on the iPhone. For example, I’ve installed Safari version 3.2.2 which uses Webkit 525.28.1, the page I’m testing will utilize that version. Make sure you are aware of the iPhone browser version you need to be testing and the Webkit version that comes along with that iPhone browser version. You’ll need to install that version of Windows Safari to be in sync with the iPhone. How do you know which version of Safari/Webkit is running in an iPhone app install? I don’t know! I can find no reference or history of versions on the Web. I suppose it could be gathered easy enough by installing each iPhone app version and then either doing a Help->About in Safari? Or gathering the data from the user agent string by going to browserhawk.com. Post a link in the comments if you’ve seen this data somewhere.
- Apparently iPhone Safari 3 is not the same code base as Safari 3! The code base was branched. Changes made in that branch could cause your results to vary between the real iPhone browser and the iPhone browser simulator. From the threads I’ve read it seems to be more “shell” type features, which lowers your risk if you’re just looking for rendering issues.
Seven ways to test browser compatibility, without having to manage your own testing lab:
Browser compatibility testing solutions have made some progress in the last year but it’s still far from ideal. A while back, I had a dream…
- I want to screen-shot any page in my website (requires a decent, free, scripting engine that will allow me to get to the various pages in my site that can’t be accessed via a specific URL (Watir?) ).
- I want to screen-shot my site that is not yet published for the world (requires the service to exist within my internal network).
- Once I’ve approved an ideal layout screen-shot I want the software to determine and tell me if the other screen-shots are worth looking at (by doing a statistical image comparison with a predefined pass/fail threshold). Maybe MeerMeer is on the right road to doing this?
- I want to provide basic wire-frame definitions and have software determine if my screen-shots are within reason (by analyzing elements in the DOM and browser dimensions)
- Get rid of screen-shots and do DOM to DOM element width and height comparisons between browsers (Come on, it’s a dream, standards compliance for all browsers (another dream) might make it possible?)
Start testing. When an error occurs you’ll see a red icon with a number in it next to the page that the error occurs:
Just when you thought you had a handle on your browser compatibility testing, Google gives us Chrome. What does that mean for you, the infamous browser compatibility tester? Just another browser to test? Yes and no…
Have you seen my previous screencast on Browser Compatibility Testing Risk Analysis? If not, its a worthy watch if you want to get a feel for how the browser generally works and how to trim that browser test list based on a little bit of data and risk analysis. Once that’s under your belt, continue on my friend…
Let’s dive into the details of Chrome to get a quick grasp on where some new browser compatibility defects for your site may be lurking:
The Layout Engine
What does Google Chrome use for a layout engine? WebKit. The same layout engine that Safari uses. Will it render exactly like Safari? Well, it depends on which version of WebKit that your installations of Chrome and Safari use. You can determine this quickly by looking at the user-agent string. A quick way to do this is to go to BrowserHawk.com, click “more” in the top right menu, scroll to the bottom of the new page and look for the text “User agent”. Here is the Google Chrome user-agent:
As you can see we have a WebKit version of 525.13. Chances are that the latest version of Safari runs WebKit 525 also (again do this by looking at the user-agent of the latest version of Safari). Ignoring the minor version number and focusing on the major version number, if they are the same we can feel comfortable that Chrome and Safari will display layout the same…Meaning they will align objects on the page the same. If you’ve already tested Safari, chances are you aren’t going to find any unique layout defects in Chrome.
The IE team announced what the user agent string for IE 8 will be:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)
This particular one is for Vista. They’ve decided not to use the ‘b’ in ‘MSIE 8.0b’ for the beta version this time due to issues they’ve encountered in the past with that approach. I’ve updated my User Agent Switcher import file to contain the string for Internet Explorer 8 on Vista and XP. As always you can get to that file from the right menu under the “My Testing Tools” section: User-Agent Information and Tools. Load up the new file and go see if your browser detection script will work with IE’s new string.
I also updated it with FireFox 2.0.12 for Vista.
I did my first presentation for the Phoenix Software Quality Association (PSQA) yesterday evening on “Browser Compatibility Testing Risk Analysis”. Those who attended learned:
“The art of trimming browsers from a browser compatibility test list by knowing your users, understanding how the browser works, OS & browser facts versus misconceptions, and grouping browsers by common component versions to remove redundancy.”
For those that attended I promised to post my presentation and handouts here on my blog. So here they are:
Browser Compat Presentation.zip (1.62 MB)
Browser Compatibility Testing.pptx (1.65 MB)
Browser Facts Misconceptions and Experience.docx (29.24 KB)
BrowserCompatCheatSheet.xlsx (14.89 KB)
Setting Browser Compatibility Testing Expectations.docx (13.87 KB)
If you don’t have Office 2007 you can get the Office 2007 viewers here for free.
I’m thinking about screencasting this while it’s fresh in my mind. If I do, it will be posted here within the next few weeks.
PSQA is always looking for presenters or a place to meet. If you can offer up either, the organization would greatly appreciate it (contact email@example.com). If you’re in the valley, have anything to do with QA, and are not already a PSQA member, go sign up. It’s free!
After the IE Team posted their intent and work on compliance to standards the debates have begun. Revelations have shown that the standards compliance is really an an option that would be invoked by a developer with a META tag or header using the value of ‘X-UA-Compatible’. Now, IE 8 will have 3 modes:
- “Quirks mode” remains the same, and compatible with current content.
- “Standards mode” remains the same as IE7, and compatible with current content.
- If you (the page developer) really want the best standards support IE8 can give, you can get it by inserting a simple <meta> element. Aaron gives more details on this in his article.
There is much debate on how this will impact the Web, user experience, as well as how developers will program. There are interesting thoughts around all of them. What is most intriguing to me is that IE 8 is going to be standards compatible. With news like this, I can now test that a Web application conforms to a standard. The standard is now my guideline for my set of test cases. But really will it be a “set of test cases”? Quite possibly it could be only one: Load the page and validate that the page is rendered using “Best standards mode”. But hopefully the test wouldn’t even be of my concern, with the right Content Management System, the code will be compiled by a developer and the check will be done by the CMS before release to QA. Either way, conforming to standard lowers the risk of a browser compatibility dramatically.
Another interesting feature in IE 8 is the idea of “Version Targeting”. In other words:
“The idea is that when IE10 loads up my IE7 page, it rewinds itself to act like IE7 did, all those years ago—no matter what changed in the meantime.”
What will “Version Targeting”, do to my browser compatibility testing list when IE 8 is released? My first impression is that it won’t slim my test list at all. For example, if you have a page that is coded for IE 8 and X-UA-Compatible, it doesn’t necessarily mean that it will look good in IE 7 or in IE 6 since the code is targeted for IE 8. Using that same Web page (IE 8 and X-UA-Compatible), will the testing list shrink with the release of IE 9? It depends… Will the standards and the compliance to those standards change between IE 8 & 9? How many compliance to standard defects were in IE 8 and fixed in IE 9. If their were few defects and the standards didn’t change then the risk is low and you probably wouldn’t need to test both IE 8 and 9, just 9.
It’s too early to speculate and come up with concrete answers. The IE Team is still working through this stuff with themselves and the active community. But I’m happy to see their attention on the matter.