Has anyone ever released a major build of software that was perfect?

[Mich the Tester]

I don't think perfect software is achievable unless it's functions are pretty limited and straightforward.

Even then it would have to be running on a perfect OS on a perfect machine.

[JimBobTwoTeeth]

It's near impossible for a group of BAs to think of every permutation that a large user group will.

It's near impossible for a group of SAs to think of every permutation that a large user group will.

It's near impossible for a group of Developers to think of every permutation that a large user group will.

It's near impossible for a group of testers to simulate every permutation that a large user group will.

Hence bugs.

[Mich the Tester]

It's near impossible for a group of BAs to think of every permutation that a large user group will.

It's near impossible for a group of SAs to think of every permutation that a large user group will.

It's near impossible for a group of Developers to think of every permutation that a large user group will.

It's near impossible for a group of testers to simulate every permutation that a large user group will.

Hence bugs.

whs

It sometimes leads to interesting (actually rather tiresome) discussions after a system has been tested and then users are faced with issues. One of the things I always try to do when taking on a testing project is to manage the expectations of the clientco. Some clients think that if software is tested there is no possible excuse for bugs being found in production. I try to explain to them beforehand that testing can never prove the absence of bugs, but can only demonstrate the presence of those bugs that can be found using the test cases that are prepared, and that the accuracy of any statement about a system’s quality is related to the specific configuration of software and hardware on which it is tested. Testing is also a time and budget constrained activity, just like development or analysis; give us 2000 years, an unlimited budget and a frozen configuration and we might be able to test every possible path through a very simple piece of software that automatically sends cards to people their birthday. Still, we can’t guarantee the OS or the hardware config.

One loud American CFO once threatened me and his software supplier with legal action if any bugs at all were found after taking a system into production. Both the project manager and I then told him that he had two options;
- never take the system into production, or
- accept our resignation immediately
He then took advice from his legal staff and came back with a more reasonable proposal and a somewhat grumpy look on his face.

[Spacecadet]

They're not bugs, they're features!

[JimBobTwoTeeth]

whs

It sometimes leads to interesting (actually rather tiresome) discussions after a system has been tested and then users are faced with issues. One of the things I always try to do when taking on a testing project is to manage the expectations of the clientco. Some clients think that if software is tested there is no possible excuse for bugs being found in production. I try to explain to them beforehand that testing can never prove the absence of bugs, but can only demonstrate the presence of those bugs that can be found using the test cases that are prepared, and that the accuracy of any statement about a system’s quality is related to the specific configuration of software and hardware on which it is tested. Testing is also a time and budget constrained activity, just like development or analysis; give us 2000 years, an unlimited budget and a frozen configuration and we might be able to test every possible path through a very simple piece of software that automatically sends cards to people their birthday. Still, we can’t guarantee the OS or the hardware config.

One loud American CFO once threatened me and his software supplier with legal action if any bugs at all were found after taking a system into production. Both the project manager and I then told him that he had two options;
- never take the system into production, or
- accept our resignation immediately
He then took advice from his legal staff and came back with a more reasonable proposal and a somewhat grumpy look on his face.

I always make the point that the Business Requirements are IT's contract with the business. Anything that contravenes these is a bug.

Of course it helps to have good BAs who leave no ambiguity in the BRD. So a QA team should always test the docs before the system.

[Mich the Tester]

I always make the point that the Business Requirements are IT's contract with the business. Anything that contravenes these is a bug.

Of course it helps to have good BAs who leave no ambiguity in the BRD. So a QA team should always test the docs before the system.

Another aspect I notice at clientcos is the attempt to save money on testing by getting the users to test a raw, freshly delivered system before a professional tester has seen it. The big risk here is to expose users to all the teething problems and damage their confidence and motivation before the system has even been rolled out. One big advantage of professional testers is they don’t get upset about finding bugs; they (should, if they’re real testers) enjoy it and are happy to do it every day. What testers cannot do is guarantee a system to take into production, however given time and resources and functional information they can help you to present a system to users that stands a reasonable chance of acceptance and doesn’t scare your users into mass rebellion, as some systems have done at clientcos. Unfortunately, by the time someone like me gets hired in it’s usually too late and the users have already been exposed to tulipware with all the concerns that brings for them. Having said that, if I’m honest those are really the situations in which I thrive, and when given a project from the start I sometimes get a little bored. 'Crisis management' tends to pay well too.

[VectraMan]

All my software does exactly what I told it to do, so by that measure is perfect.

Whether I programmed it to do the right thing or not is a different issue. It's not its fault that I'm not perfect.

[Scary]

Everything that comes out of Cupertino is perfect.

If you want to prove that your software is perfect, you could always try specifying it in Z.

[TimberWolf]

The most common way of getting your software perfect, is to define it as perfect, regardless of how borked it is. Sorted.

[VectraMan]

If you want to prove that your software is perfect, you could always try specifying it in Z.

Thanks for that. I've gone years without thinking about Z, and now you've gone and reminded me of it.