Testing in IE7

This post is part of the Pride & Paradev series.

What do I think of testing in Internet Explorer 7?

Test everything in IE7

IE7 is a bug magnet: seriously, I find more bugs in IE7 than any other browser. Why? It’s the least forgiving of browsers. If it works in IE7 it’ll most likely work in a more modern browser. It’s like a fussy relative: if they like a gift you give them, chances are your less fussy relatives will also like the same gift.

Even though only 2% of customers use IE7, in a high volume business such as Amazon or eBay this still equates to millions of dollars.

It’s very easy to test in IE7. First you’ll need Windows XP: set up a VirtualBox VM with Windows XP installed and immediately disable automatic Windows Updates otherwise your IE7 machine will quickly become your IE8 machine.

I recommend using a real IE7 browser over a IE7 mode in IE9 or IE10. Why? IE7 mode in IE9 or IE10 is a simulator and doesn’t behave exactly the same as a real IE7 browser.

I don’t expect programmers to use Windows XP, so I just add a “works in IE7 mode” acceptance criteria to every story so that each programmer will test locally in IE7 mode on their development machine: this saves me time testing each story.

Don’t test anything in IE7

Many organizations use current production browser statistics to determine which browsers to support and hence test against.

But you shouldn’t base your browser on current usage: it should be based upon expected future usage, determined by studying browser usage trends. Using this method it’s pretty clear that usage of IE7 is continuing to fall: so why bother testing in it at all?

Customers who use IE7 are probably the sort of customers who aren’t going to spend a lot of money on your web application: otherwise they would’ve got a more modern computer by now.

Besides, using IE7 is a pain. You need a separate VM as you can only use it on Windows XP. It doesn’t contain any developer tools and there’s no JavaScript console: particularly handy for debugging nasty bugs.

Programmers will get annoyed with you when you raise an IE7 bug that doesn’t repro in IE7 mode in IE9 or 10, as they can’t debug it locally.

Is it all worth it? I say no.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

7 thoughts on “Testing in IE7”

  1. Nice arguments in both ways and it definitely depend on the project. Also if I’m not wrong, WindowsXP will be without any tech support from Microsoft in Spring of 2014 (exactly one year from now). So any investment made in that direction should consider the value one will gain.


  2. I think knowing your customers and your potential market is very important when making these decision whether to test in IE7 or not, as time equals money. :) You mentioned the example of amazon and ebay.
    In some corporate companies the IT departments control the browser version and hence it is important to know who you are making your software for and for who you are testing it.


  3. I gotta disagree with this statement, “If it works in IE7 it’ll most likely work in a more modern browser.” I don’t think there is any relation at all.


  4. Gotta disagree with this statement, “If it works in IE7 it’ll most likely work in a more modern browser.” I don’t believe there is a connection.


  5. I would caution against using VMs to test any sort of browser behaviour. I’ve seen both false positive and false negative results come of using VMs for testing purposes – argue amongst yourselves over which of those is the lesser evil. I’d be a rich guy if I had a fiver for every time a Developer had said to me “I’ve fixed that bug you raised; I tested it in an emulator/Virtual Machine/IE7 mode/Bambleweeny 57 sub-meson brain… the app works fine now.” Double that fiver for every time I’ve proven them wrong after retesting the “fixed” bug on a real browser or device and I’d have, well… double the money!

    Sure, if you can’t get a hold of a specific browser or device any other way, use VMs and emulators, but I would always caveat such results by stating what has been tested virtually.

    I disagree with the assertion that IE 7 users “aren’t going to spend a lot of money on your web application,” There are a lot of IE7 (and IE6, even) users in corporate environments who may have a lot of purchasing power. However, their IT Departments don’t want to mess with legacy systems by doing a mass-update of all of the operating systems and browsers unless they really, totally, absolutely, positively have to do so – inertia counts for a lot on those kind of situations.

    A lot of high-up Executives are, well, set in their ways, shall we say? Just because they don’t have the time or inclination to learn what will effectively be a brand new web browser (which is what shifting from IE 6/7 up to 9 or 10 will feel like, never mind all the other OS changes that’ll come with it), doesn’t mean they won’t have a company (or personal) credit card with a 7 or 8 digit limit burning a hole in their pocket. I tested a website a few months ago that was specifically going to be marketed at middle and higher managers, so I had to test it very thoroughly to make sure it worked in a range of older browsers, including IE7, Firefox 3.6 and Safari 4 and 5.

    On a more positive note here, you did say that “If it works in IE7 it’ll most likely work in a more modern browser.” You are so right here, especially when it comes to JavaScript-related errors. The main difference between newer browser versions and older ones is that the JavaScript engines are faster and more efficient. Seeing how fast a web page loads in IE7 will give you a very good indication of now bloated it is (or isn’t) with JavaScript. Maybe if we keep sending back JavaScript bugs to Developers they will learn to be more frugal with their scripting in the future? I live in hope.


Comments are closed.