Are you testing against Chrome?

Question

I'm curious to know who is testing against Chrome.

I am mainly because it has become my primary browser, so all development is taking place on Chrome, then i test with IE and Firefox.

Answer 1

I test on chrome first, FF second and IE last...

When debugging JS I use Firefox Firebug...

Chrome is using the Webkit rendering engine similar to Safari. So, if your site looks bad on Chrome, it'll probably look bad on Safari...

Answer 2

For public websites: yes.

Internal Corporate sites: it's still "un-supported" (IE is forced, FF is sneaked in)

Chrome's market share is increasing every day. If you want about 10% of your users to miss out, feel free not to test. It's a cost and maybe it's acceptable to put "unsupported" message for chrome user agents.

You best bet would be to look at your web stats for your site and see what the percentage of chrome users is. Monitor your user base and see if they have adapted chrome. Remeber you are building your site for your users.

http://www.w3schools.com/browsers/browsers_stats.asp

Answer 3

I test on IE, FF, Chrome and Opera (and occasionally Safari). You really have to these days. For debugging Javascript I tend to use Chrome for its console, and sometimes Firebug in FF - they're both very helpful.

Answer 4

The answer should be a definitely yes.

Google is big enough not to be missed, same as Apple, almost as important as Microsoft.

Only thing I'd like to say here is bear in mind its rendering engine is sort of webkit(not too sure about the subtle differences), so just don't leave mozilla(-moz-) unhandled :)

And also, I feel like the Firebug console the most. You can add some quite useful panels to it, such like:

• Google Page Speed
• FirePHP

Personally, I test my web application against (from most important to least):

1. Firefox 3+ (version is not that important actually, Firefox is always good);
2. Safari 4 (For the iMac people, my iPhone, my-iPad, to make sure my web app works);
3. IE8 (I hate MS, but I cannot ignore its Browser);
4. Chrome (It usually works like Safari, but it's good just to make sure);
5. Opera

6. IE7 (If I really really have the time...)

   ......

Max.Integer IE6 (For the reasons everybody knows already...)

Answer 5

Since I'm working on a Google Maps API site I test for what they support: Chrome, IE, and Firefox. I tend to check Chrome first as it's my default browser.

Answer 6

What are your browser-usage stats? You must start there. Every app's userbase is different. Rank the browsers based on those stats, and test/bug-fix in that order. That will, in most cases, give you the best bang for your time/money.

How can you track browser usage stats? Analyze your web server's logs or use Google Analytics.

For example, I know a B2B web app with 5000 users that have these ratios:

• 90% IE (6,7,or 8)
• 8% Firefox
• 2% Chrome
• Safari, etc are negligible

So they should:

• do complete full-featured tests with IE
• test only core features and general CSS compatibility with Firefox
• disregard other browsers

What if they have automated testing (i.e. Selenium)? Then testing all browsers is trivial. But you could still apply my logic to browser-specific bug-fixing. That cannot be automated. And the business will have to triage what bugs get fixed.

Certainly, this answer is subjective. Perhaps the 2%-chrome users are the highest paying users. I don't know. Consider your browser usage stats, your most important users, and the dev/QA resources available.

Answer 7

I test on Google Chrome first, then IE and in last Firefox... Because sometime we are getting some issues mainly from IE and Chrome.. So it's necessary to test complete application flow and UI in these Browsers.

and Google chrome also provides some good Extensions like, IE tab, iMacros, Firebug, Flashbug etc etc..

Answer 8

Our testing is carried out against IE and Firefox. Our product is used by large banks and telecoms companies so we dont have to worry about usage in other browsers.

I have found using firefox the test run 50% + quicker and the main reason for this is IE does not process Xpath's very well. To work around this I use alot of Jquery and the selenium command WaitForCondition. I would recommend doing this as it does provides alot more flexability. For example to emulate the waitForElementPresent (this uses isElementPresent in a loop with a Thread.sleep) i just use a single selenium statement WaitForCondition(My Jquery Statement, wait duration), so if i was waiting for a control to load of btn_login i would use the following

WaitForCondition("selenium.browserbot.getCurrentWindow().$('#btn_login'),"10000") !=null), this waits 10 seconds.

Im thinking of writting a selenium blog as alot of the work i am doing seems to be quite advanced. What does everyone think.

Answer 9

Firebug is brillant when it comes to writting the Jquery elements of the test. You need to be careful mind you as some of the selenium commands act differently in IE and Firefox (keyUp, KeyDown) Im sure there are alot more than this :).

I have found actually using Jquery for most things is a lot better. I can input the text and fire off an event. Pressing the Enter key was a real pain in the b**. I had to check which environment i was running and then run 1 of the 2 commands. I can just use $(the id of the control).trigger(event you want to run) ie (onblur,click,keyup etc).

Also using Jquery means it is cross browser compliant as well (yippieee) and even in IE6.