If software is being developed for user installation, like most of the software developed by Microsoft, then a major reason for testing is to verify that your software works with everyone else's.
As I've mentioned in earlier discussions, the one absolutely fatal-to-your-business kind of bug is one that prevents your software from installing. As long as the software provides some needed functionality, it can have huge numbers of bugs and users will pay for release 2.0 to fix them, but if it won't install, the box comes back. Why does software fail to install or not run once installed? Well, it could be because of overlooked cases - you never considered the possibility that drive C could be a network drive - these can, in theory, at least, be caught by a constructivist approach. A more common cause of failure, though, is because of someone else's software. It overwrote a key library with a version of its own, or it improperly grabbed a key system resource or .... Perhaps, I lack imagination, but the only way I can see to get around this problem is getting copies of lots of other commonly used pieces of software and testing them to see what they actually do when run. I can't figure a way to use formal methods to get around the problem. In addition to Russel Winder's advice to start with a simple system, I'd add the advice to develop and try an install procedure for that simple system as soon as it start to run. Ruven Brooks ---------------------------------------------------------------------- PPIG Discuss List ([EMAIL PROTECTED]) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
