Widespread delays to the London Underground this week were caused by one of the Tube’s infrastructure operators installing new software.
The new software was loaded over the weekend, presumably to minimise any disruption. There’s no indication of what actually went wrong, or whether it could have been prevented by better (or more, or any) testing.
A recent survey suggests that many websites won’t work well with IE7. Normally, it wouldn’t matter much if sites don’t work with a new browser, as take-up is typically pretty slow. However, many people will be upgraded to IE7 automatically.
I have to admit that I haven’t tested my site with IE7. I’m hoping that it will be OK, though, because I know it works with most other browsers. There are a number of sites out there that really only work with IE6, as they take advantage of its non-standard features. They are the ones that are likely not to work with IE7, which apparently has a different rendering engine.
In this case, it’s definitely a case of “do as I say, not as I do”: don’t skimp on the testing.
Hot on the heels of IE7, Firefox 2.0 appears. I’ve just installed it, and so far, so good.
On the other hand, I haven’t installed IE7 yet. You can’t easily install it alongside IE6 (instead of replacing it) and one of my main uses of IE is for testing web pages that I develop. Given that most users are going to be on IE6 for quite some time, I’ll still need to test pages against it.
I’m sure there is a good strategy for this, it’s just that I haven’t yet worked out what it is.
A recent survey suggests that many applications fail when they are deployed. If you don’t plan for performance issues in advance, during the development process, things can go pear shaped in the production environment. Performance can be significantly affected by network issues, for example: often, development takes place on a LAN, but the production environment is a WAN.
Perhaps the most telling statistic from the survey is that most IT departments (71 per cent) seem to rely on end users calling the help desks to alert them that performance problems exist. This means problems are only reported after their impact is noticed.
The survey is discussing conventional applications, but similar problems can arise with user-developed applications. If other users have different versions of the base software (spreadsheet, modelling package or whatever) Bad Things can happen. An application developed using a personal database such as Access can fail when many users try to use it at once. And, more basically, the developer often makes assumptions about file locations that are not valid for all users.
I think this article is reporting the government as saying the following about ID cards:
So they will be testing, it’ll just be on live data (and hence real people). And just because a product is off-the-shelf it doesn’t mean it’ll work under all circumstances, especially if it’s part of a larger system. Interfaces between different components are always potentially dodgy.
Anyone want to bet that this huge IT project will be delivered and working on time and within budget? Or will it be like the NHS National programme for IT?
When you draw up a specification for a software application that you are developing, are you sure it’s complete?
OK, let’s start again. You should always provide a specification for a software application before you develop it. This applies to everything, even a little one-off spreadsheet. Obviously in the latter case it needn’t be particularly detailed; a single sentence is sometimes adequate. However, remember that you can’t tell if the software is doing the right thing unless you know what the right thing is.
If it’s more complicated than a single calculation, the specification should be more detailed. Typically it would cover what actions the user should be able to perform, and give details of the calculations.
Which brings me to my point. Remember that testers are users too. Unless the application is tested, you won’t be able to tell if you’ve got it right. When you’re testing, you often want to do things that normal users can’t do, such as start afresh, or input large amounts of data. This is especially likely if it’s a database application. It’s extremely frustrating to find that it’s impossible to test an application properly because it doesn’t include the functionality that you need.
And yes, this is the voice of experience speaking.