20 Days Of Web Testing > One, Two and many


Unless you are creating a very niche site then you will probably be expecting a reasonable number of visitors to your site.

As such, it would be prudent to check that it works for X number (where X is a number relevant for your context) of users.

One of the trickiest elements of testing for multi-user or even load testing your application is defining the end usage patterns and expected load.


For example, some sites may be used everyday by only a handful of people, but at the weekends visited by many thousand.

There is also the added complexity of mapping out the end user usage patterns. Are all end users going to perform the same actions each and every time they visit your site, and all at the same time?

One of the simplest methods for starting your journey to multi-user testing and then load/performance testing is to use the simple concept of One, Two and Many (or other variants of these numbers)


I personally like the One, Two and Many because it’s easy to explain and it’s also provided me with exceptional value when used. I’ve used it for testing as well as proving automated scripts.


The theory goes like this:

You test with one user to make sure the basics work at a functional level.

You then test with two concurrent users to check that there are no basic deadlock issues and that the application/site allows multi-user activity at a basic level. You’d be surprised at how many issues this test could find. The amazing thing about this sort of test is that it’s quite simple and doesn’t need you to spend months building a giant automation framework to find the basics don’t work.

You then test with many users. The many being whatever value you deem to be right for your goal. That could be ten, twenty or maybe even two million. The choice is yours.


The reason for starting low and then jumping to big numbers is that I’ve seen a few examples where expensive infrastructure and test code was prepared for load testing, only to find the product wouldn’t even allow two users to log in at the same time.



I like rapid feedback so I personally perform the “One” and “Two” manually, maybe with some support by simple automation like Selenium or even ignoring the UI and diving in at the web service level.

For the bigger loads there are countless options, of which I’m not going to explore here.

My personal favourite at the time of writing this book is jMeter, simply because it’s free, easy to get started with and easy to extend.

Saying that, you could opt for any number of solutions, free to very expensive, locally installed or hosted; maybe even a complete managed service.

Whatever your decision never lose site of what your goals are.

Performance and Load testing can become complicated, unwieldy and expensive as you explore any number of variables unless you keep focused of what you’re goals and ambitions are.


Useful Hint

Do a proof of concept or trial run with free or “free to try” tools before opting to buy any product for Load Testing.

Tool quality and suitability can vary greatly.


Useful Links

A list of testing tools – https://en.wikipedia.org/wiki/Load_testing

jMeter – http://jmeter.apache.org/


If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > Check for Dead-links


Almost all websites suffer from something called Link Rot where hyperlinks are left to decay resulting in many links that no longer go anywhere, or they point to out of date and unsupported pages.

The page they linked to may have been removed or they are simply no longer referencing a correct location.

There are also errors in linking which could mean some links on the pages simply don’t work.

It would make sense to keep on top of the links in the first place avoiding time spent maintaining them, but this is easier said than done when faced with developing commercial sites and applications.

Dead-links can hint at other issues and areas of concern for the keen web Tester.



There are many tools out there that will scan your site, provide you with a list of dead-links and then suggest ways to fix the problem.

Mostly it is a case of just removing the offending link from the page but this can also come with it’s own problems.

Download a link-checking tool, like Xenu, add in your URL and then go through the report.


Useful Hint

How about running a dead-link checking tool as part of your Continuous Integration or Overnight Build Process?

That way you can see dead-links after an automated test run.


Useful Links

Xenu Link Checker – http://home.snafu.de/tilman/xenulink.html

W3C Checker – http://validator.w3.org/checklink

Broken Link Checker Tool – http://www.brokenlinkcheck.com/


If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > Back to the beginning again


The security of an application/site doesn’t just concern the usual suspects of cross-site scripting, SQL injections and man in the middle attacks.

Something as simple as hitting the back arrow on a browser and seeing the previous persons information is a low key but effective security breach.

Say for example that you are in an Internet Cafe and you log in to your banking application. You log out, but leave the browser window open on the home page and you leave the cafe. It *could* be entirely possible that the next person to use the computer can see your details by simply clicking “back” on the browser.

Believe me this does happen.



A very simple test would be to authenticate and enter your application. Then log out and hit the back button on the browser to see what happens.

Browsers often offer the ability to skip back a number of pages in one go. Try this and see what pages you can open.


Here are some examples of how this bug could cause problems:

  • You might be able to vote online for a candidate or topic. Then hit back and vote again. And again. And again. And again. And again.
  • You might be able to use a “one time only” coupon to discount a price over and over again by using the back button.
  • You might be able to see someone else’s personal data by going back through their browsing session.
  • You might be using a site where some client side JavaScript fires on page load even if the authentication fails. So although you have logged out, when the page reloads (and doesn’t let you back in) it might still fire some logic to perform an action.


Useful Hint

Holding down the back button often gives you a list of several previous pages to visit.


Useful Links

Stack Overflow question on disabling back capability (which you cannot by the way) – http://stackoverflow.com/questions/7816195/how-to-disable-back-button-in-browser-when-user-logout-in-classic-asp

IE security problem with the Back Button – http://www.wired.com/science/discoveries/news/2002/04/51899?currentPage=all


If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > Change the URL


A good test to run to find sneaky authentication bugs is to edit the URL of the site you are on to see if you can get access to stuff you shouldn’t be able to see.

You might also want to change the URL and see if you can alter the data being sent or received.


Bypass Authentication

Firstly it would make sense to understand how the site hangs together and which pages lead to which other pages.

You can then start to build up a profile that will help you organize your thoughts about how to try and trick the application.

So log in to your application and perform some actions, like submitting some details or checking some sensitive data. On each page copy the URL and paste it to notepad (or other tool).

Once you’ve built up a profile and a list of URLs then log out. This should now terminate that session. To make extra sure you might want to clear the cache, delete cookies and re-open the browser.

Now paste in a saved URL and see what happens. As your session is closed you shouldn’t be able to gain access to anything that required authentication (like your sensitive data).

You may also want to try logging in as someone else and pasting in the same URLs. Some of the URLS may contain account/person specific information. Therefore you may need to authenticate to view the URL. See what happens when you are authenticated as someone else.

Can you see another account?

Are you asked to authenticate again?

Any clues as to whose account it is?

Change the URL

Another trick is to look for any information in the URL that could be changed.

For example:



An obvious test would be to change the rate value and see what happens. How about making the rate a negative value? What about no value?

At the time of writing this a large global bank is in the news over a basic URL error just like this. The URL shown to a logged in user contains an account ID for the user. By simply changing this number to another number, users were able to gain access to someone else’s bank account. It is such a simple test but so often over-looked. And this was a live issue for a giant bank handling millions of peoples money. It happens.


In a sense, the above two test ideas are worthy of a decent Exploratory Testing session or two.

Seek out information, note down what happens, look for clues, work on potential security breach angles, but more than anything, have a go and learn about the potential for URL hijacking.


Useful Hint

Using a recording tool like Selenium will give you each of the visited URLs in the script it creates whilst you work through the site.

It’s a good way of picking out the URLs of interest.


Useful Links

Selenium – http://seleniumhq.org/

OWASP – Direct Object References attacks 


If you want to talk Testing – catch me later this year at EuroSTAR conference.


iPads and Testing

We’ve just taken delivery of a couple of iPads for Testing and Development.

Whilst setting them up I wondered what sort of apps and tools other people use on them for their Testing.

At the moment we’ve got them set up for getting stuff on and off them quickly, so they have email accounts each and they share a Dropbox and Evernote account between them. (Some of us use Evernote for ET notes).

We’ve set up autoupload of images to Dropbox (for screenshots) and set up suitable sharing so we can see the notes and files arrive on our machines almost immediately.

There are a few good apps for monitoring systems and applications but I’ve not yet found anything else in the app store that I think would be great for our testing.

What are other people using? Anything?

20 Days Of Web Testing > Automate the tedious


Sometime the testing of websites/applications can be fairly tedious if you have to constantly navigate to certain points in a form, or create certain sets of data to get to specific pages or configurations to start testing.

In these instances I always find it incredibly useful to create a Selenium IDE (record and playback) UI test or simple SQL scripts to populate the database.

It makes getting to your actual test “point” much easier and quicker.


For Selenium UI tests add Selenium as an extension to Firefox and check out the online documentation on how to get started.

Simply record your navigation through the application and play back as necessary to get to where you need to be.

For example, I was once testing multiple users and cookie management and needed to log out and log in as different users with alarming regularity.

As such I created a simple automated script that would log one user out and then log the other in. This took away a huge amount of tedious button clicking. I wasn’t using Selenium to test the application, but I was using it to automate setup and tedious clicking.


Useful Hint(s)

Learning how to debug test scripts in Selenium IDE will make your script generation and playback more effective and quicker.

Apply caution though. If you find yourself building up an automated suite of tests and relying on them for regression then ask if this is really the right approach. Most of the time it won’t be.

You can often use SQL scripts to populate data ready for testing also.


Useful Links

SQLYog Tool – http://www.webyog.com/en/downloads.php

SQL Learning at W3 Schools – http://www.w3schools.com/sql/default.asp

Selenium Debugging – http://seleniumhq.org/docs/02_selenium_ide.html#debugging

Selenium – http://seleniumhq.org/


If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > Disable CSS


CSS, or Cascading Style Sheets is a mechanism for adding layout and style to a web page. It should be possible to change the CSS and change the whole look and feel of the website, assuming everything within the application has been coded with this in mind.

Yet some people, through either choice or necessity, use browsers that disable the CSS.

It keeps the site simple and ultimately more accessible for many people and tools.

As such it’s important to test the site with CSS removed.

You may be surprised about the flow and order of the site when the CSS is removed.



The simplest way I have found is to open the site in Firefox with the web developer add-on installed.

The add-on has an option in the menu to disable CSS. The site will then be rendered with no styling.

You could also use Firebug or a number of other tools.

With the CSS removed you will typically have a very simple looking site, like the one pictured below:

Image of the Social Tester Site with CSS removed

Image of the Social Tester Site with CSS removed


With the CSS enabled, it looks like this:

Image of the Social Tester Site with CSS enabled

Image of the Social Tester Site with CSS enabled

Useful Hint

Firebug has a CSS tab which shows you the CSS for the site. What happens when you change some of the CSS markup?


Useful Links

W3C standards and advice for CSS – http://www.w3.org/Style/CSS/

Firebug Firefox Extension – http://getfirebug.com/

Web Developer Add-One – https://addons.mozilla.org/en-us/firefox/addon/web-developer/


If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > Explore the competition


A great way to generate test ideas, check compliance/claims and to see what systems your users may have previously used is to check out the competition.

Have a look at what your competitor’s products/services offer and bring some of that learning back to your testing.

There are heated discussions in the testing world about whether a tester should “recommend” enhancements or suggestions to the site under test.

My answer is “Yes. Absolutely”.

I think any tester not contributing their knowledge and insight (assuming it’s welcome) to making the product better is missing out on adding great insight.

Testing isn’t about happy path checking, ticking boxes and not stepping off the pre-defined path.

Testing is about adding value, insight, experience and knowledge.

These insights, if they could improve the product, should very much be aired and communicated..

If there is a chance to improve the software, make it more usable, compete in the market place and generally make a more successful product then isn’t that adding value?

Don’t always assume that someone else is checking out the competition or has the customer experience at the front of their mind.


Information you glean from comparing products could generate new test ideas, ways to improve features or ways to make your product stand out from the crowd. It’s therefore a good testing technique to aid you.

Matching competitors on a like for like basis is not always a good business strategy though, sometimes going around/under/over them is better.

However, you could start to glean some interesting use cases from their product information or think of your own product in new ways.

It’s also a good way of understanding more about the domain you are working in.



A quick Internet search should bring you back some of your competitor’s sites where you should be able to read the marketing material, maybe sign up for a free trial and generally get to know a little more about the product/domain.


Useful Hint

You may find your product/site listed on ‘alternative’ sites such as www.alternativeto.net.

Sites like this show you alternatives to products so it might be a good way to see what the competition are doing and what people think of their products.


Useful Links



If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > Change the locale


The locale of the browser can play a large part in the rendering of the product and the way that it functions.

It’s a simple test idea that could highlight potential multi-language issues, especially if your site actively supports multiple languages.



The process of changing your browser locale is different in each browser but a quick web search should give you the information you need.


For example, in Firefox on MAC:

Firefox > Preferences > Content > Languages


This will give you a dialogue where you can change the language locale of the browser.

Your browser locale (language) settings will steer your browser to look for “locale specific” content in the sites it loads.

So if your site is intended to be used in English and French markets and will change the language of the landing page(s) depending on the browser locale detected, then try removing all locales and see what happens.

How about adding en-us instead of en-gb – does it still render in English?

You can quickly start to build up a number of tests and further areas to explore.


Useful Hint(s)

Try using a Browser Extension to make changing locale easier.

The locale of the browser and the language of the Operating System are two different things.


Useful Links

Quick Locale switching extension – https://addons.mozilla.org/en-US/firefox/addon/quick-locale-switcher/

Changing Windows language – http://msdn.microsoft.com/en-us/library/ms144258.aspx

Changing MAC Language – http://support.apple.com/kb/HT2490#l6



If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > Client and server watching


There are many times as a Tester when it is useful to see what is happening behind the scenes when testing a website.

When interacting with a website there may be some logic happening in your browser (client side) and/or server. Information is flowing between the two. It’s this logic and information that’s so crucial to you as a Tester.

The web pages may also use CSS to make the site look and feel the way it does.

When you click on a link or perform an action the client (your browser) sends a request to the webserver, or does some client side logic (like a calculation).

Either way, actions that a user does are causing something to happen behind the scenes. Most users don’t care, but Testers should.


As an example, here is a simple “log on” mapped out with specific actions.

  • User: Opens a browser and navigates to the web site by typing in the URL
  • Browser: The browser client requests the log on page from the web server
  • Server: The server receives the request and responds with the relevant web page.
  • Browser: The browser displays the page in the browser to the user
  • User: The user fills in the required details (username and password) and hit’s the “log in” button
  • Browser: The browser client sends these log in details to the server securely (like username, password, page requests)
  • Server: The server checks the credentials and sends a response, often with a new page for the browser to go to, or display.
  • Browser: The client takes the command and does some stuff (like loading a page, throwing an error message etc)


This is a simple example for demonstration purposes. Yet even a simple log in generates messages and logic in a number of places.

In more complex examples there could be browser side logic taking place, or the server may be calling out to another web service somewhere too.

It makes sense then to look behind the scenes and understand how your application/site is working and what messages it is sending and receiving.

Mapping out this information will give you a great starting block to explore the system. You can build up a profile, which may include potential test ideas, weaknesses, strengths and potential gaps.


Some things of interest might be:

  • Is the data being sent and received correctly?
  • Is the layout working as expected?
  • Are the response times satisfactory?
  • How do timeouts affect the site?
  • Are there any errors in the code?
  • What happens if I pass in X?
  • What happens if I remove X?
  • What happens if the message is lost completely?
  • Is the site generating lots of traffic for something fairly simple?


There are three core tools I see most seasoned Web Testers relying on.


Charles Proxy

Charles Proxy is a great tool for sniffing web requests (i.e. watching and potentially intercepting requests.)

One of the most useful features of Charles Proxy is the ability to “Throttle” the bandwidth of the traffic between the client (your browser) and the webserver.



Despite a rather dubious name Fiddler is a must have tool for testers.

In a sense it does the same sorts of actions as Charles Proxy but offers a rich interface and command line to get really technical with requests and responses.



I use the Firefox browser a lot for web testing because of the vast array of extensions available. One of the must have day-to-day extensions is Firebug.


Firebug does loads of things but the main uses for me have been:

  • Observing the traffic taking place between client and server
  • Alerting me to code and message errors
  • Showing me the speeds at which the pages are loading
  • Inspecting elements on the web page for automation
  • Changing the CSS and seeing how it renders on the page


Useful Hint

There is another extension called Fire Cookie that extends Firebug’s capabilities to Cookie management.


Useful Links

Charles Proxy – http://www.charlesproxy.com/

Fiddler – http://fiddler2.com/fiddler2/

Firebug – http://getfirebug.com/

Firecookie – https://addons.mozilla.org/en-US/firefox/addon/firecookie/



If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > UX


UX is becoming a bit of a buzzword recently and is typically associated with usability and design.

In my mind, UX is bigger than that. UX is, as the name suggests, about User Experience.

For me, that’s about the bigger picture and involves more than just the product.

Customer Support, release notes, documentation, supporting docs/sites/help, performance, security, ease of use, usability, accessibility, fit for purpose etc. It’s a big topic.



On the surface there are simple things we can think about regarding UX as Testers. Not all of the elements of UX will be applicable to your context but there is no harm in thinking about some or all of the following:

Customer Support

  • Is it available?
  • Do your support team know the details around the product?
  • Is there sufficient support/help available to them?
  • Do they need it?
  • Are the support contact details correct?
  • Is there online help?
  • Is the help correct, accurate and accessible?

Release Notes

  • Are there any release notes?
  • Are they accurate?
  • Are they complete?
  • Are they written for the right audience (too technical, not technical enough)?

Error Tolerant

  • Is the system error tolerant?
  • Are the error messages relevant?
  • Does the system help the user recover from any errors?


  • Is it there?
  • Is it needed?
  • Is it accurate?


  • Is the site performing as per requirements/needs of the customer?
  • Do we even know this information?


  • Is the customer’s data safe?
  • Do they know it is?
  • Are they re-assured that it is safe?
  • Can we prove it is safe?

Usability and Ease of Use

  • Is the product easy to use?
  • Can people find what they want quickly?
  • Is it consistent across all screens/pages?
  • Is it consistent with expectations?
  • Is the site behaviour typical based on other systems/sites/applications?


  • Is the site accessible by people with accessibility requirements?
  • Does it need to be?

Useful Hint

There are a number of resources about design and user behaviour on the web from designers and others working in this exciting domain.

They can offer some amazing insights in to how the design of the product can encourage actions and outcomes.

As a Tester, don’t be afraid to seek out information from sources that aren’t considered “testing” specific.

Useful Links

UX on Wikipedia – http://en.wikipedia.org/wiki/User_experience_design

UX Booth – http://www.uxbooth.com/

UX Mag – http://uxmag.com/

Design with Intent – http://architectures.danlockton.co.uk/



If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > See the source


The source of the web page is often a great place to find bugs, areas for further exploration and potential security flaws and leakage of information.

When I talk about the source I am referring to the source code for the page you are testing. The source code is what’s making the page work and as such contains snippets of information about how the application and page is put together.

There could be comments, usernames and passwords, hints referring to methods and implementations that could be useful from a security point of view. There could be rants and raves and loose comments about the company or the customers. There could be joke comments or comments alluding to partially implemented code.


There could be secret URLs and credentials in there too.

Image : The Page Source to The Social Tester website shown in Page Source Visualisation Firefox extension



When your site is open in your browser click “View” on your browser menu bar and then choose “View Source” (note: This is true for most browser but some may operate differently or call it something other than “View Source”)

The page source will open in a window. Simply reading through it may reveal some interesting areas to explore further.


Useful Hint

Right clicking on the web page typically provides you with a context menu to view the page source too.


Useful Links

Andréas Prins article on Hidden Treasures – http://www.thetestingplanet.com/2010/12/hidden-treasures-for-everyone/

Firefox Extension to visualise page source – https://addons.mozilla.org/en-US/firefox/addon/view-source-chart/


If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > Tab order


There are many people using and operating websites without using the mouse.

If the tab order of the page is not logical then it makes using the keyboard a chore, illogical and in some cases impossible.

Testing tab orders seems like a simple check to do, but always consider the way your page renders, refreshes elements or uses neat tricks to hide content based on selections; these things may all affect the overall order of the tabbing.



For example, if you have a form that has 10 questions on it then the tab order should be fairly logical.

When you press the tab button you should move forward through all ten fields in a logical order (typically left to right, top to bottom, but this will vary for each design) often including any buttons or help icons etc.

However, if that same form reveals questions 11 and 12 if the user answers “Yes” to question 2 then ensure that this too is reflected in the tab order.

In some instances questions 11 and 12 may be missing from the tab order.


Useful Hint

Hitting SHIFT and TAB will do a reverse tab in most environments. Reverse tab is just as important as forward tab.


Useful Links

Tabbing in HTML guidelines – http://www.w3.org/TR/html4/interact/forms.html#h-17.11.1

Web Aim guide to changing tab orders – http://webaim.org/techniques/keyboard/tabindex


If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > Multiple tabs and windows


Opening the application in more than one tab or window can often lead to interesting security bugs, data refresh issues or multiple cookie confusion.

An often-overlooked test is the multiple tabs/windows in the same session test.

What you are doing here is essentially seeing how the application copes with the same and/or different user operating under the same session token, but on different pages or tabs.

Many sites use Cookies (a small file stored on your computer) to store session IDs and other supporting data, hence it is often possible to find bugs around confused data, sessions or security access.

This can manifest itself as incorrect data display issues, security loopholes and actions not being performed as expected.



Here’s a simple example to seek out security flaws.


Open Firefox and in one tab log in to your secure application.

Then right click on a page in your site and open that new page in a new tab.

Both tabs are now considered to be in the same session.


Now log out of the application in Tab 2 and try to perform some actions in Tab 1.


Has it logged you out or let you perform an action?

In most situations it should have logged you out.


In many instances it is possible to log in to two different accounts in the same browser and end up sharing data across both tabs because of cross authentication issues.


It’s not just about authentication though.

What about adding things to a shopping basket in multiple tabs – do they persist in the basket?

What about state changes in your application across several tabs?

Can I login across several browsers in different sessions?

Can I trick browser side validation and restrictions by performing actions across a number of tabs?


The best way to test in multiple browser tabs and sessions is to explore the application with multiple tabs open, checking what effect a change in one tab can have on the other.

As you explore around look for data, states and actions that might be confused by bad cookie management, session management and cross tab problems.

Always have some developer tools open so you can see what requests and responses are being communicated and what the content of these is. A tool to show your cookies and their contents will be undoubtedly useful too, something like Firecookie (a Firefox extension).

Burpsuite security tool is especially useful if you want to start hijacking the session and manipulating stuff.


Useful Hint

In several of the modern tabbed browsers it is possible to open up multiple tabs and then drag a tab out of the main browser “window” to create two ‘Windows” operating under one session. This makes it easier to switch and view the two tabs whilst testing using CTRL and Tab (or CMD and Tab on Mac)

Not all browsers may treat a new “window” as the same session.


Useful Links

Good site about cookies and sessions – http://www.allaboutcookies.org/cookies/session-cookies-used-for.html

Session Hijacking – http://en.wikipedia.org/wiki/Session_hijacking

Security implications of cookies – http://it.toolbox.com/blogs/securitymonkey/successful-hacking-with-xss-cookies-session-ids-11098

Burpsuite – http://portswigger.net/burp/

Firecookie – https://addons.mozilla.org/en-us/firefox/addon/firecookie/


If you want to talk Testing – catch me later this year at EuroSTAR conference.


20 Days Of Web Testing > Cross Browser


There are a growing number of browsers entering the market (including those for tablet and mobile devices) which means your website under test needs to be working well for your supported browsers.

The existing mainstream browsers (Internet Explorer, Firefox, Chrome, Opera, Safari) are also updating themselves very frequently and often without the end user being aware of the update.

This makes testing against this growing number of browsers essential but also increasingly more time consuming.

As with all testing though, ensure you check what is supported and what isn’t by your own product/company. One of the most successful ways to reduce browser testing is to stop supporting older browsers. This is a good strategy for some companies, but not possible for all.

It obviously doesn’t make these old browsers bug free (or even guaranteed to work) but it does mean you can ignore potential problems with these older versions and focus on the version you actively support.


Spread The Risk

One approach could be to run your everyday tests against a mixture of browser environments.

For example, you may be testing a simple web application where the user can log in, generate some reports, send the reports and then log out. The system also has a simple “management” system where sys admins or managers can view who is changing what.

To get a wider coverage you could test your log on functionality in one browser, test the send report functionality in another browser and then the audit trail functionality using a third browser.

This is an effective way of covering different combinations of browsers at the same time as doing your day-to-day testing. The above example won’t highlight a bug with the audit trail functionality in the first and second browser though. So there are plenty of gaps for bugs to slip through, however the time it saves may make this a good option.


Let someone else do it

For appearance issues there are many online tools like Browser Shots, which will load your page in any of the supported browsers (they support a great many versions), take a screen shot and then make these screen shots available to you.

This is great for websites, but applications that require credentials or have a huge number of pages are somewhat more difficult. It will also only check for look and feel issues.



The Browser Shots homepage


Check against standards

You could validate your site against an HTML standards checker. Checking against HTML standards will give you more confidence the site works across many browsers, but there are still some browsers that will render pages differently.

A good standards checker is at the W3.org page.



You could automate your checking using something like Selenium, and then use a tool like Selenium Grid to test against several browsers.

This has infrastructure requirements and is obviously reliant on an automation suite existing (or going to be brought in to existence).

It will also only check what you have told it to check.

Automated checks are great for functionality but will not tell you about layout issues between browsers.


Fight Layout Bugs

You could write some automated tests to check the layout issues your site may face in different browsers.

Fighting Layout Bugs is an open source Java project providing an automated way of checking for potential layout bugs. As it’s Open Source you can add back to the project.


Manually Test It

You could manually test against each version by installing all of the browser versions on different machines. To make this less of a chore it would be worthwhile using Virtual Machines.

These can then be cloned and re-used by others, or centralized somewhere for multiple users to access. This too relies on infrastructure.

It also requires significant time and effort from a Tester, but gives you the human analysis of cross browser compliance.



You could narrow the browsers down to engines.

Chrome and Safari use WebKit. Firefox uses Gecko. Internet Explorer uses the Trident rendering engine. Opera uses the Presto rendering engine.

You could therefore “assume” that testing on Chrome will cover off Safari. This may be an assumption too far for many though.


Emulate it

You could use tools that attempt to emulate the different browsers. There are a number of tools on the market, as well as some inbuilt tools within the browsers themselves to render older versions.

A few words of caution though, they are not wholly accurate in my experience, but they *may* provide insights that are useful.


Outsource Selenium

If you have a suite of Selenium tests but do not have the infrastructure or experience in house to get a grid up and running then you might find services like Sauce Labs and Testing Bot quite useful.


I’ve not even touched on different operating systems or mobile devices but as you can see there are a number of ways to approach the cross browser issues.

Cross browser support may be your biggest pain-point, especially with the rapid rate of release that most of the browser companies are now adopting.

In my experience a nice selection of a number of the above works well.


Useful Hint

Some browsers come with compatibility modes, which allow you to emulate different versions.

Some browsers, like Chrome, have developer tools for rendering pages in different browser and Operating Systems.


Useful Links

Compatibility Mode page on Wikipedia – http://en.wikipedia.org/wiki/Compatibility_mode_(software)

IE9 Browser Compatibility article – http://blogs.msdn.com/b/ie/archive/2010/10/19/testing-sites-with-browser-mode-vs-doc-mode.aspx

Sauce Labs – http://saucelabs.com/

Testing Bot – http://testingbot.com/

Browsers and Rendering Engines – http://en.wikipedia.org/wiki/Web_browser_engine

Selenium Grid – http://selenium-grid.seleniumhq.org/

Standards Checker – http://validator.w3.org/


If you want to talk Testing – catch me later this year at EuroSTAR conference.