assume we have the following scenario:
We have an application which supports only firefox only. The applications uses GWT. Some customer requires that the application should also support chrome browser as well. New permutation was compiled for chrome as well.
Question: What should be tested to ensure that we have same functionality on the new browser and how? Should we just start application with the new browser and check page by page and function by function?
Like you say, you would need to check each page and function.
In my experience, when the app does not explicitly style a visual element, the browser's base style for that element is used, and in some cases that can differ a little between browsers, as each browser has a slightly different base CSS. So, depending on your app, you might find things sized or positioned or colored differently.
It shouldn't be necessary to test any differences.
From GWT's overview:
Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript.
So, unless you do some fancy things, all should work the same way, no matter which browser is used.
Related
Is there any single framework with which I can build a css3, html5 website that is compatible for all browsers including IE7 and later? Can http://html5boilerplate.com/ boilerplate help me in this?
You will never get the IE7 or IE8 rendering engine to achieve full compatibility with HTML5, CSS3, and other modern technologies. They are simply not capable of it.
However there are some hacks, tools and plugins which can get you part of the way.
Tools like Modernizr will help you by allowing you to detect which features are supported, to give your site a chance to work around it.
jQuery is a great library anyway, but is particularly good in this context because it abstracts a lot of browser differences away from the developer. Some things are easy in most browsers but a real pain in IE; jQuery takes a lot of that kind of stuff and makes it easy regardless.
Dean Edwards' IE7.js and Selectivzr are both Javascript libraries that give IE support for lots of the CSS selectors which were missing in older versions. This allows you to write your stylesheets without worrying so much about what IE supports. (IE7.js also fixes a number of IE's other glitches and missing features too)
CSS3Pie is a hack for IE that adds support for CSS border-radius, gradients and box-shadow.
There are in fact a whole load of hacks along these lines, all aimed at adding features to older versions of IE which it is missing. Modernizr's website has a big list of them here: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
However there is one big caveat to all of this. Speed. IE<=8 is a slow browser. It has a slow Javascript engine. Virtually all of these hacks are javascript based. You might get away with running a few of them on any given site, but trying to use enough of them to give IE anything like full support for HTML5 and CSS3 will slow the browser down to the point of being unusable.
There is one other angle to approach this question though, and that's Google's Frame plugin for IE. This basically installs the entire Google Chrome browser engine into IE. The user is still running the IE shell, but the web page is rendered as it would be in an up-to-date version of Chrome.
This sounds great, but of course it isn't perfect. The main down-side of it is that the end user has to install it manually onto their computer, which means that you as a web developer have no real control over whether it's there or not. So its not something you can just add to your site and expect everything to magically work.
Finally, you may also be interested in CanIUse.com, which gives browser support tables for various features, allowing you to see at a glance what is and what isn't supported in various versions of each browser.
HTML 5 is more an umbrella term for a variety of technologies than any one thing or framework. Really, any implementation you do should degrade gracefully-- and that is what makes the site browser compatible. Detect what the browser supports, and then have alternatives that are legacy friendly.
Check out: http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/
And: http://diveintohtml5.ep.io/detect.html
Good luck.
Modernizr is an open-source JavaScript library that helps you build the next generation of HTML5 and CSS3-powered websites.
MS is including it in the ASP.net MVC template projects
html5boilerplate won't help you.
As others have said html5 and css3 are very broad terms, there's no framework that implements all of the features provided by both of these. In fact they are not equally supported in browsers that say that they support them. And more, even W3C guys (who write the specs for html5 and css3) are not yet established on what features they will include or what steps will be required to implement them. You get the idea...
But.. if you narrow your requirements to some specific features, like video, audio tags, canvas drawing, nifty css effects, File API, or others, you CAN find frameworks that implement (or try to mimic) them with available technologies in cross-browser manner (more or less).
We're looking for a tool that would allow us to script and run tests across multiple browsers including Chrome, FF 3,4, IE 6,7,8 and during the running allow a human to visually inspect each page / action. This must support javascript so a simple browsershots approach will not work. Something like Selenium Grid may work but I haven't seen anything that would act like a console so that a human could visually inspect each test step. Ideally the answer to this question would be a tool that runs a scripted front-end test and displays those tests on each browser in a grid so that a human could visually inspect the look of each page while the test was testing the html content.
How about Cucumber Sauce?
I've not tried it purely because I do not need to run tests in parallel across multiple browsers or headless. However, I am using Cucumber BDD for almost all my web application testing. Cucumber Sauce looks like it might have solved the parallelism problem so it might work for you.
How about Telerik Test Studio http://www.telerik.com/automated-testing-tools.aspx? It can do FF 3 & 4, IE7, 8, 9 (but not IE6), Chrome and Safari. It literally hooks into the browser and drives it as if a real person was sitting there clicking things and typing text.
A couple months ago I ran into a browser that allowed users to see how different rendering engines displayed their site: Lunascape, and here are its features. As far as it validity, or accuracy goes, I cannot vouch for it (I have never used it); I can link you to a CNET review though: CNET.
So my best idea would be to use lunascape (to allow your tester to see all the engines side-by-side), then script the tests in javascript which is included in every page.
Good luck, and hope this helps.
TestComplete can do this: http://www.automatedqa.com/products/testcomplete/
You can record any interaction with an application and when the tests run you can watch them.
It supports:
Internet Explorer 6—9 support (both 32- and 64-bit versions)
Firefox 3.5—4.0 support
Open source tool Selenium, which supports many browsers and can be run as a simple record / playback tool or from code but the browser compatibility varies a bit depending on which method you choose. Google uses Selenium in a big way these days and there are plenty of good articles such as this one on their testing blog.
Very good question.
The closet tool that i think of will be HP load runner for :
the ability to visually inspect each page while the test is running and inserting break point if needed
Javascript is supported but you might have problem with asynchronous request (ajax)
Since there is alway a but :
Not all browsers are simulated.
Browsers are simulated also ...
The report will print the performance and not what was shown on the page.
The price
I do not think that visual inspection falls into automated test. Automated test is about performance and to detect regression. Visual inspection on the other side is to check if the layout is properly rendered.
Doesn't this testing depend on the size of the site to be tested? If I have a 5-10 page site, I would use some of the tools mentioned above, handle it manually (i.e. walk through the site in each browser on each platform), use browsershots.org, or use a tool within Safari, such as simulating a browser.
If the site is large, then these options become very difficult and time consuming, and my experience is that the best thing to do is make sure that each page is standards compliant, and try different pages in a few browsers.
Hope this helps.
What would be the process for ensuring that the code works as expected across multiple browsers. What would be the best answer?
Be XHTML compliant (w3.org validator)
Be CSS compliant (w3.org validator)
Use a JavaScript library that is cross-browser compatible (less direct call to JavaScript as possible)
Test, test, test during development. Not at the end!
Avoid bleeding edge code.
Yeah, I know, many of you will hate that answer. And if you've never worked in a large enterprise environment, you'll think I'm a Luddite. However, I can't tell you how many times the requirements I've been given have specifically listed "No HTML5" or "No CSS3" elements simply because the client was paranoid about IE6 working exactly as the others did.
The obvious overall answer is testing, but I'd go one step further. If you're worried about 100% operation in all browsers, you have to define your standards. For example, if you have to code back to IE6, do you have to worry about mimicking rounded corners, which is always a hack on IE6 and below? Or, will the client accept progressive enhancement such as square corners for those on browers from the dark ages and rounded for the rest of us? Does the client specify fonts that can't be told apart when pulling the page up side-by-side, or do they understand that browsers use different font rendering engines? Is it ok to work just in IE6, or do you have to also support quirks mode? What about rendering with a screen reader (accessibility) or without CSS or Javascript. How about mobile devices? All these were valid and measurable issues with my last major corporate client.
I like Adobe's Browser Labs as my first line of defense for testing. However, it's just one of many steps I take including multiple physical computers on multiple OS's connecting via multiple connections through different network proxies. You just can't test enough....and even then expect to find an error as the site is launched and matures.
Take each browser and test :D
You can use websites like browsershots.org to see how it looks on different browsers and platforms.
The most comprehensive way of doing that is to actually test in different browsers. A simple solution would be to create a virtual machine hosting server, set up multiple VMs, and then install a different browser version to different VMs to fully test your application.
Absent that, there are tools that can emulate (but not fully) browsers and you can test through those.
The best measures to adopt are:
Use a CSS Reset (read about it at the link, implement it however you like)
Use a Javascript Framework like jQuery (This will abstract a lot of cross browser quirks)
Validate your HTML and CSS. Make sure you are specifying a Doctype
You can test most browsers via Chrome, Firefox and IE8. IE8 has an IE7 mode that can be used to test for IE7. Press F12 in IE8 to get the developer window to debug and solve issues. Make sure you are prompting for all JS errors. IE6 is a tough one, but there are a number of resources available that you can probably find to help you with this.
Hope this helps. Good luck.
http://browsershots.org/
thats the site you looking for. You need to put in the url of your website, select the browsers that you want to check and click submit. It will return screenshots of the your website based on the browsers that you have selected.
There is no one way to test the app's compatibility for web browsers. First thing to keep in mind is understand the standards set for the app, define the number of browsers and versions to support. Once we know what we need to support we can keep the following points to ensure compatibility:
Test during development. Not at the end.
Avoid bleeding edge code. New functions that come with ES5 or ES6 standards would only be supported by modern browsers, hence would need polyfills in older browsers. Therefore use the most native form of Javascript wherever possible.
Use jQuery functions if it's included in the project. It helps take care of most javascript cross browser issues. If not included, use just bring its particular function in your project that you might need.
For CSS, try to use the traditional methods of layout and styling instead of the latest CSS3 one's which might not be supported by old browsers(like transform property).
Tools like Browserstack can be used to see the screenshots of how the CSS turned out on different machines.
Actually test on different machines and browsers. Although chrome provides a superb emulator but when code actually runs on that particular OS and ecosystem, then it may misbehave. So the best way to ensure is actually test them in every ecosystem.
Use Tools like VirtualBox to be able to test old browsers and different OS.
There is no way to ensure it aside from testing testing testing :-)
I want to generate a thumbnail of a web page in the browser, so I can have multiple scaled down iFrames within a single page.
IE can do this using filters. Mozilla can do this inside a <canvas> with drawWindow() if you have Chrome privileges (like an installed plug-in).
Is there any way to do this in WebKit? Is there any generic cross browser way to do it?
I know you're looking for a client-side way to do this, but considering the spotty support across the board you may want to look into generating the thumbnails on the server.
khtml2png allows you to generate webpage images from the command line. It's not the prettiest solution, but with a little scripting it would allow you to generate thumbnails on the fly, and you wouldn't have to worry about browser compatibility.
WebKit's nightly build (41944 from March 24 2009) has support for transforming elements (including scaling) as well as other goodies like CSS gradients.
There is more information on the WebKit blog and here.
I'm guessing this features are also available in Safari 4 but I haven't checked.
edit: It looks like this is also making its way into Mozilla as -moz-transform.
What, if any, considerations (HTML, CSS, JavaScript) should you take when designing for Google Chrome?
Chrome uses Webkit, the same engine as is used by Safari, OmniWeb, iCab and more. Just code everything based on the standards and verify in each browser.
I think first and foremost you should focus on using HTML and scripting that follows the standards.
After you have that running, file a bug report then make the browser-specific tweaks. If Chrome is worth a flip you shouldn't have to tweak things for it.
The same ones you'd take for Safari, as they share the same rendering engine (with a slight version mismatch).
I'm sure filing a bug report really helps with all those IE rendering issues!
Realistically, you need to test your application in each browser, no browser 100% follows the W3C standards so ultimately you can't rely on following that at all. You need to test everything you do in any browser you wish to support.
As has been mentioned, Google Chrome has the same rendering engine as Safari/iPhone/etc., WebKit which passes Acid3, so there should be minimal issues if you follow the standards. But don't rely on it. Google Chrome currently uses a slightly older version of WebKit than Safari. I'm sure they'll eventually be on the same version at some point, but unfortunately any new browser becomes just another browser to test in.
Are you designing specifically for Chrome, or do you want to make sure your pages work well with Chrome?
Assuming it's the latter, then just use the same design considerations you'd do for any browser. If applicable, keep in mind that many phones and video game consoles have web browsers now.
Chrome uses a new JavaScript engine, so you'll have to test your JavaScript using Chrome as well as Safari. The HTML and CSS may render pretty much the same, but they use different JavaScript engines.