This post talks about cross Browser testing,cross browser testing tools free,cross browser testing tools open source,cross browser testing definition,cross browser testing advantages.

What is Cross Browser Testing?

Now a days we talk more on browser compatibility. Every Manual Testing is having a mandate part as Browser Compatibility.Web browser is a translation device. It takes a document written in the Html language and translates it into a formatted Web page. What happens in HTML.

It converts the HTML code to machine language and sends it through the wire by binary format. The receiving device(mobile and computer) catches the binary code and converts that code to HTML. After that, it shows to the user.

Let me jump into the problem. Very few people code HTML by hand anymore. There is a multiplicity of programs such as DreamWeaver and Microsoft FrontPage which help make the process of web page creation easier.

The basic rules for translating HTML documents are established by the World Wide Web Consortium, which publishes the official HTML standards. But there’s considerable room for interpretation within those ground rules.

For example, the HTML standards say that the TABLE tag should support a CELLSPACING attribute to define the space between parts of the table. But standards don’t define the default value for that attribute, so unless you explicitly define CELLSPACING when building your page, two browsers may use different amounts of white space in your table.
In addition, the HTML standards usually run ahead of what the browsers support.

No browser as yet supports 100% of the HTML Version 5 standard, but some browsers come closer than others. Over the past few years, Internet Explorer has done a much better job of this than Netscape Navigator, though Opera has done arguably the best job.

But since support for the latest HTML tags isn’t universal, you could be building your pages with parts of the language that not all browsers understand. In that case, the browser will ignore that part of your page it can’t translate, and the way your page displays will be affected.

One of the greatest problems with CSS, or Cascading Style Sheets, is the issue of cross-browser compatibility. What may look great in Mozilla browsers looks terrible in Internet Explorer, and may totally break in Netscape.

The biggest mistake a web designer or developer using CSS can make is to design for only one browser or to assume that since the largest group of viewers use IE, to disregard its flaws that are apparent in other browsers.

The new cutting edge Ajax technology is also browser dependent.So Browser compatibility testing is a must for Ajax-based Application.In the case of business-to-consumer (B2C) style web applications, cross-browser compatibility will generally be necessary.

Customers resent being told which product to use and they may not have disk space to load a second browser on their hard drive. Also, certain ISPs support only one browser. If your browser chooses conflict with the ISP, you have put your customer in a difficult situation.

In business-to-business (B2B) web application, you may be able to insist that a particular browser be selected. It will depend on your relationship with the counter-parties, standards in that industry, and the number of counterparties involved.

The cross-browser problem is getting complicated by browser-specific “HTML extensions.” Back during the heyday of the Browser Wars, both Netscape and Microsoft tried to get a competitive edge by running ahead of the HTML standards, inventing their own tags and attributes. Those are basically
custom tags and attributes only viewed in the compatible browser only.

Browser compatibility and strategy for testing:

Different Browser Versions

The major difference between two versions of the same browser is their support for newer portions of the HTML language. A new browser is generally better at displaying Web pages than an old one. However, Internet users tend to upgrade their browser based on the addition of new features, like email integration and instant messaging. If a user doesn’t care about these features, they’re happy to keep surfing the Web with their old browser. If IE doesn’t quite understand something, like sloppy code or unsupported features, it attempts to do something anyway, instead of simply ignoring them, like Mozilla and Netscape based browsers. Unfortunately, this results in major headaches for CSS developers. Microsoft has attempted to help “dumb down” coding issues, resulting in more developers that write sloppy code, by having the browser anticipate the design. There are obvious problems with this concept. In my humble opinion, the CSS code should be written, validated, and 100% compliant with the standards.

The best way out is to design pages to work for the last two versions of the major browsers.
Also note that new browser versions sometimes represent major changes in a browser, and in these cases all bets on the browser’s behavior are off.For example, Navigator Version 6.1 is a complete rewrite of Netscape’s browser, so a page that worked well under Navigator Version 4 may not work under Version 6. That’s especially true if you use Dynamic HTML on your pages.

Different Computer Types

The Macintosh is still used by 12% of computer users, and has a very loyal following among graphic designers and publishers. In theory, if you view your page on both a PC and a Mac using the same version of the same browser, it should display the same, right?In practice that’s rarely the case. There are three reasons for this:

Font Availability.

When you tell your Web page to use a particular typeface, such as “Arial,” you may not always get the font you want. Fonts are a computer resource, and not all computers have the same fonts as your computer. That’s true even between different PCs, but it’s especially true between the PC and the Mac. If the typeface of your page suddenly changes between these computers, you’ve probably used a font that isn’t available on both computer types.

Font Size.

The Mac will generally render your typeface in a smaller pixel size than the PC will. That’s especially true if you use the FONT tag to set your type size, since this tag uses abstract units to define size. You can avoid this problem is you use Cascading Style Sheets to set your font size in pixels. ac.

Internet Explorer:

Microsoft outsources the development of Internet Explorer for the Mac, and so to a large extent this is a different browser from the PC version. In particular, the Mac version of Internet Explorer is prone to quirks and bugs that you won’t see in the PC version. If you check your Web page under only one browser on the Mac, do so under Internet Explorer!

Different Screen Sizes

If you don’t test your pages using different screen resolutions, your page may be stretched to fit a large screen, or be cropped to fit a small screen.

Many experienced Web designers use HTML tables to control their page layout, yet they design their pages on large, 1024×768 pixel screens. When these pages are displayed on smaller computer screens, the browser may not be able to fit all the content onto the screen. In these cases, the content will scroll of the right of the page. While this may not sound like much of a problem, users hate scrolling left and right to view a page.

This problem should be easy to avoid, yet a surprising number of otherwise well-designed Websites don’t fit within the standard 800-pixel PC computer screen. This is especially a problem for pages built by graphic artists using a Macintosh, whose standard screen size is 1024×768. Many designers forget that designing for an 800-pixel screen means using roughly a 750-pixel layout.

Many less experienced Webmasters design their pages without tables, or dimension their tables to fit 100% of the screen width. If you’ve built your Web page this way on a computer with an 800-pixel screen, you may be surprised how your page is stretched to fit a larger screen. Text and graphics that were adjacent on your smaller screen may not be so on a large screen.

To avoid this, wrap the content of your page inside a single, large, one-cell table. Set the width of this table to be about 560-pixels, if you’re designing for a 600 pixels layout, or 750-pixels if you’re designing for an 800 pixel layout.

Because the majority of Internet users have a screen resolution of 800 pixels or less, it’s a bad idea to design your site for a larger screen.

Different Font Sizes

Most browsers allow users to customize their default font size. Many users who work on computers all day do this to reduce eye strain. As a result, user preferences may cause the typeface that you used to design your Web page to increase as much as 50% larger in a user’s browser. This increase in font size can hurt many carefully-planned page designs.

HTML Errors

Whether you’re an HTML coder who builds Web pages by working with the raw HTML tags, or a designer using a WYSIWYG editor like FrontPage or Dreamweaver, the odds are your finished Web page will contain HTML errors.

An HTML error is some spot on your Web page where you’ve violated the official rules of HTML. For example, you may have two tags that overlap one another in a way that the standards say isn’t legal.

In practice, the major browsers are robust and forgive many of these HTML errors. But not all browsers forgive the same errors. So your favorite browser may display your Web page without error, but another browser may be seriously affected by the same error. Internet Explorer forgives this error and displays the page correctly; Netscape Navigator can’t recover from the errors and doesn’t display the page at all!

Browser Problem:

I have gathered this info from the portal. Credit goes to the actual author.

• IE will try and guess mime-types based on file extension, even if the mime-type was specified by the webserver. This can result in unexpected security holes – for example, if you allow users to upload files and you even take the precaution of saving them as “.dat” (which a default server config would serve as application/octet-stream ) they could be executed in IE with Javascript by anyone who knows the URL. This is a very dangerous XSS vector – the hacker just would just need to upload a malicious file, give the URL to an IE user to open, and they could steal things like passwords from that user. Fortunately in IE8 this behaviour can be disabled but it requires explicit action by the programmer/server-admin for it to be.
• IE does not actually support XHTML, it can’t display it at all. For this reason people rarely if ever have their servers configured to send true XHTML – instead they send XHTML documents using an HTML mime-type. When you view this “XHTML” on IE or any other browser it’s actually just rendered by an HTML parser. Contrary to common understanding the doctype does not specify to a browser what renderer to use. Firefox and other browsers do support XHTML, but XHTML is a lot stricter than most people realize, and if it is truly enabled people find they have made a few mistakes that stop whole pages from rendering at all (true XHTML has no error tolerance). Hopefully, IE9 will support XHTML, but when people update their servers to use the right mime-type they’re in for a shock. ocPortal does use XHTML, but we develop it wit the correct mime-type enabled on our test servers, to ensure it’ll work.
•  You can’t have “disabled” list items in a select. These are incredibly useful for spacing out lists for usability purposes and it’s a shame they don’t work right in IE.
• In IE if you do something like:

you get a Javascript error. Unfortunately, IE can’t do this pattern across its Active-X interfaces, even though it is valid and normal Javascript. However, fortunately, you can do:

which is better code anyway. Never-the-less, it’s very easy to fall into the trap.

•  This is a really interesting one: I checked, this will break on IE, but work on Firefox. It’s due to the order in which entities and Javascript are parsed. Firefox is smarter, but arguably it may actually be Firefox in the wrong here.

• You can’t do the following in IE: Consider the 1st line of the code…due to the final comma. However, in other browsers, it works.
• This is a very common problem: Look at the last 3 lines of code On Firefox both work, but on IE only the second works. It’s a real shame, but mostly it leaves a big trap to fall into if you don’t test in different browsers.
• Firefox is less fussy about semi-colons: Code

var foo1=function() { }
var foo2=function() { }
In IE Javascript won’t parse, but it does work on Firefox. I actually think Firefox should explode too (IMO there’s no good reason for missing a semi-colon even if the ECMA specification allows it – it’s just sloppy) – but what matters is the difference in behavior can lead to easy bugs.

• IE will cache the output of it’s XMLHttpRequest object, for scripts not marked as cacheable, whilst Firefox will not. Unless you know about this problem it is very frustrating to debug. One solution is just to append random parameter values to the URL so that it can’t be cached; however I would guess this causes cache pollution, so in ocPortal we actually output extra explicit “do not cache” headers on the server-side.
•  IE (or is it Firefox?) ignores PNG-file gamma settings, meaning unless gamma settings are stripped, images get subtle color differences on IE and Firefox. Photoshop unfortunately always uses gamma. As I mentioned I’m not sure whether it’s IE or Firefox at fault here, but I always solve this by running PNG files through a PNG compression application such as PNG Gauntlet, which kills two birds with one stone

  Browser Bugs As you’ve probably seen by now, building a Web page that displays well on all browsers isn’t easy. To make matters worse, sometimes you’ve done everything right, and your page still doesn’t display correctly under one specific browser.
  It’s not your fault – you’ve just encountered a browser bug. Unfortunately, browser bugs are a fact of life for Web designers.

  Each browser has its own unique set of errors and quirks that you have to adapt to. That’s especially true with Version 4 of Netscape Navigator, whose early editions were rushed out the door to beat Internet Explorer to market. A columnist for WebReference recently called Navigator Version 4 “truly terrible browser.” For example, take perhaps the most widely encountered browser bug in existence.

  The HTML standards say that when you build an HTML table, you don’t have to explicitly close each table cell with a closing tag. This closing tag is optional. Yet unless you explicitly close your table cells, Navigator 4 will not display your table if it is nested inside another table. Since nesting tables is common practice to control page layout, this bug wrecks many well-designed pages. Netscape isn’t the only browser prone to bugs. Internet Explorer for the Macintosh has a number of bugs and quirks in the way it handles text spacing. When you encounter a browser bug, it often means resorting to trial-and-error debugging to remove the problem.
  Set a Goal First, understand that it’s hard to build a Web page that displays perfectly on every version of every browser running on every computer. And doing so may require you to leave out features that you really, really want to have on your Web page. Building a Web page that’s compatible with Version 1.0 of every browser would mean building a bland page filled with plain text. So the first step to solving browser compatibility problems is to determine which browsers really matter to you. Avoid the Cutting Edge The Web is hip; it’s hot and exciting; it’s radical.

  So many Web designers feel they have to build cutting-edge features into their Web page. That’s a bad idea, because cutting-edge features are rife with browser compatibility problems, not to mention the impact they have on your page load time.

  Pay Attention to Your Browser Compatibility Report While HTML Toolbox can solve many browser display problems, there are some problems it can’t address. That’s especially true if these problems are caused by browser quirks and bugs. In these cases, you’ll have to track down your HTML problem yourself.

  Be patient; you can expect this process to take anywhere from one to four hours. Try following these steps to track down the cause: Make a copy of your Web page so you can restore it to its original form if you need to. Debug this page, not your original Web page. Isolate the problem on your copied page. Do this by eliminating as much of the page as you can. Is the problem at the top of your page? Then throw away everything but the top section of the page. View the pared-down page in the problem browser (use Browser Photo to do this if you need to).

  Is the problem still there? Then remove more of the page. Eventually, you’ll get to a point where the problem disappears. In that case, the last part of the page you deleted probably caused the problem. Now go back to your original page (or create a fresh copy of it and work with that). Look at the section of HTML that may have caused your problem. Change it.

  Now start a new Browser Photo session for your page. View the results and see if you’ve corrected your display problem. If so, then it is ok. After you’ve fixed the problem, be sure to review your Browser Photo snapshots for other browsers too. It’s a common mistake for HTML coders to fix a problem under one browser, and in the process break the page under another browser. Don’t expect your first guess to solve the problem. More often you’ll have to try a number of different things to see if they solve the problem. Again, be patient with yourself; this takes time.

  Why do you care about Browser Compatibility? Web sites reflect the company’s professional image. If your site renders improperly or not at all, your company’s reputation can be tarnished. If your site has browser display problems, visitors and potential customers will leave your site and not look back. In contrast, a professional-looking site will make visitors feel more comfortable, stay longer, and browse more pages. And because of this increased credibility, they are more likely to purchase the products and services that they are looking for from you. Now the ultimate point Write correct markup – make sure it validates Make sure your markup is in standards mode Write correct CSS – make sure it validates You can use a CSS framework, like Blueprint, 960.gs, YUI CSS library For Internet Explorer -related issues, there is ie7.js and ie8.js

  So Browser Compatibility or cross-browser testing is a technique by which we can test a webpage in different browsers and check the integrity of the page.

  If we are making any web portal or Testing a web portal it is a Mandate to test that particular portal in different browsers. Now how is a new developer or a Black box tester is supposed to know what are the features available for a cross-browser Test.

  Well, I was googling for this into web and found out some interesting things on Cross-browser testing..Well if want to see how much support which browser gives. please navigate to the link written below: Cross Browser Support:

  This link is a summary of all available browser..their support in a tabular manner..like the picture.
  I always refer to this link before i develop or Test any website /portal related work. Hope this will help you. Cross browsers can also be tested through…Test the link in different Browsers

  In reality, no Internet user will download a new browser just to view a Web site. To mitigate the plan is to pay attention to browser compatibility when building your Web page. Avoid using HTML extensions and be careful about using cutting-edge features of the language that may not yet be supported by all the major browsers.

  The list of different Browsers:

  1X, Act 10, ActiveBrowser, Active Worlds, Alice, Amaya, ANT Fresco, Arachne, AvantGo, a web-II,
  Beonex Communicator, Browse-X, Charon, Chimera, CipherNet, Clickgarden, CrystalPort, CubicEye,
  DocZilla, E:ID Frame, Encompass, Enigma, Escape, ezWAP, FairLighHTML Viewer, Fast Browser, Firefox,Galeon, Go.Web, Grail, Grasshopper V1, Home Page Reader, HotJava, iBrowse, IBrowser, iBrowserPlus, iCab, ICE Browser, I-Comm, iConnecter, InfoScanner, Internet Explorer, IPowerPortal WebBrowser, KBrowser MIPS Edition, KBrowser Palm Edition, Kidnet Explorer, Klondike Web Browser, K-Meleon, Konqueror, Konqueror/Embedded, Links, Lynx, Lynx for Amiga, Micro Digital Browser, Mobile Explorer, Mozilla, MSN Explorer, Multilingual Mosaic, MultiWeb

  but wait, there’s more!……

  Neoplanet, Nestor, Netcaptor, NetClue, NetPositive, NetRaider, Netscape, Net-Tamer, Newt’s Cape,
  Nokia Wap Browser, oKID Browser, Oligo, OmniWeb, Openwave Mobile Browser, Opera, OrangotangoVirtualBrowser, Oregano, Palmscape, Pendragon Browser, Pixo Internet Microbrowser, Planetweb browser, Pocket Browser, Palm Browser, Pocket IE, ProxiWeb, Q.Bati, RapidBrowser, Safari,Safexplorer, SlipKnot, SpeedSeek Portal Solution, SPIN, StarDesktop, TV Interactor, UltraBrowser,ViOS, Voyager, w3m, Wapaka, WAPman, Web, WebsterXL, WebPhace, WebTV, WeMedia Talking Browser, Whack Force, WWW/LX, XBrowser, Yalzer, Yoozee.

  The good news for developers is that the vast majority of web surfers use either Internet Explorer,
  Firefox and Netscape – approximately 95%. The bad news is that there are over 200 flavours of
  Internet Explorer, Firefox, and Netscape. Web pages can look totally different between the different versions. The testing scope talks about the all available browsers.

  So the best way to test in as many browsers is to use different tools.I have elaborated in the tools section.

  Cross Browser Free Testing Tools

  Cross Browser Free Testing Tools:

  Testing applications in different browsers to check the compatibility is termed as Cross Browser Testing. They are categorized as cross-browser testing tools free or paid.

  Browsershots:
  This is free in nature. The paid service is available. But the free service is also satisfactory. It provides screenshots of a page from just about any browser from all of the common operating systems. All you have to do is enter your URL and select the browsers and operating systems that you want to test. It is categorized as cross-browser testing tools free.

  Browser Sandbox
  The main advantage is without installing any Browser. Users can test and check the page in all browsers in working condition. They will open up in front of Users. It will not provide any screenshot. It is categorized as cross-browser testing tools free.

  BrowserCam
  This is a paid service. But The charges are very nominal. It provides various support for different testing on browsers. It will give you the screenshots for different Browsers along with Different OS combinations.
  There is also a device capture option for working with Blackberry and PDAs. The Remote Access service will test JavaScript DHTML, forms, and other dynamic functionality on any platform. It provides 24 hours trail as well.

  CrossBrowserTesting.com

  This is also a paid service. But once a user signs up …It gives the user 5 minutes free session to do anything with this.
  The main advantage of using this tool is to select a machine ( There are several configuration machines available) of your choice and select OS and browser on that machine.

  You can have a look at how they will perform in reality.Java-based Applet or a VNC can be used to connect to this tool. Again the best part of this tool that it provides solutions also along with the screenshot. It is categorized as cross-browser testing tools free.

  NetMechanic Browser Photo:
  The net Mechanic is a paid service. It is also having the feature of different OS…Different browsers.
  The unique feature available to this site is that you can test in different resolutions. The charges start from $15.

  Cloud Computing

  I have not used this tool much….rather they are new to this service. They provide 7 days trial for free and the rest is chargeable. It gives you a record run facility. The browsers supported by this tool are:

  • Internet Explorer (6, 7 & 8)
  • Firefox (2.0, 3.0 & 3.5)
  • Safari (3.2 & 4.0)
  • Google Chrome (2.0 & 3.0)
  • Opera (9.6 & 10.0)

  The record and run facility can be further customized by modifying the code. There are test schedules which is another best feature. The Report out feature is also very catchy. It is categorized as cross-browser testing tools free.

  IETester:
  This is a free downloadable windows program which will give access to all browsers It is having different IE version .and can be tested side by side. Again this is free. It is categorized as cross-browser testing tools free.

  BrowsrCamp:
  This tool is for newly launched Safari and Mac OS. It provides the screenshot for different OS with a changeable resolution. This also helps in in-depth testing. But that feature is chargeable. It is categorized as cross-browser testing tools free.

  ieCapture:
  This is a free tool for getting screenshots from websites in Internet Explorer. It’s very simple, just enter a URL and in a moment your screenshot will appear. It is categorized as cross-browser testing tools free.

  Litmus:
  This is new to the market but gained significant market share within a few spans of time. The free version is limited to IE-7 and Firefox-2. The good point is that the paid service is more robust. The testing can be done on more browsers and email clients. It is categorized as cross-browser testing tools free.

  Price starts with $49 for a single user.

  NetRenderer: 

  cross browser testing tools free