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

[kaiser78]

I will this weekend when my project goes live...fingers crossed and wish me luck...

[Paddy]

I have not and I think I have had enough chances to.

Yes, Edlin.exe

[original PM]

They're not bugs, they're features!

I agree all my software releases have been perfect just with some additional features!

Although why is it that no matter how many test cases you have the users will always manage to use the system in such an obscure way that it throws up a bug/system feature!

[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.

[TimberWolf]

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

[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.

[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.

[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.

[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.

[Spacecadet]

They're not bugs, they're features!

[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.

[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]

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.

[suityou01]

Wrote a database migration (50 tables or so) that ran first time, no errors, 100% effective. Mind you that was the brief, it had to be run before year end, and I delivered late, right down to the wire. The thing was I wasn't prepared to release it with bugs, so they got it when I was good and ready.

I reckon deadline pressure creates the most bugs.

HTH

[BlasterBates]

Well the company I was built the Software for the runway lighting at one of the biggest airports in Europe.

They applied real QA, like with huge knobs on and used the then "modern" Yourdon analysis and design technique, with analysis and design tools.

Hardly any real code was written, it was all generated from the design tool.

When it was installed on the date they'd planned 2 years earlier. it worked first time and no errors were ever reported.

I wasn't involved on the project, but I was somewhat impressed.