'Fool-proof' a software

[dee-u]

Could you share some tips on how to fool-proof' an application?

[dglienna]

Don't let fools use it?


Actually, you have to think 'like a fool' and test every possible condition that could arise. Assume that they'll enter numbers in string data, and characters in a text field. Assume that they will leave textboxes empty and then hit the calculate button. I think I have finished my app, and my partner can't find anything wrong with it, so we'll be letting others test it for a while.

[RobDog888]

Additionally, do the illogical and unexpected. You cant expect them to know the order of data entry or data types acceptable. You will never make it 100% error free but its getting the highest acceptable percentage thats the goal.

[Samurai Danny]

I don't think there is any way to fool proof an application. If you can figure it out let me know!

But like Rob and dglienna said do a lot of wacky things to your app and try and make it crash so you know what to expect.

What I usually do after hours of debugging is go through a beta test where I have friends or collegues try and make it crash, have a central error log to let me know what is going on fix the errors and ship the product. Though even after I give the project to a client I'll always have an error log generating.

[GaryMazzone]

My favorate say is

"You can't idiot proof an applciation because someone will always make a better idiot."

you can change idiot to fool if you would like.

[Pradeep1210]

Give away your software for free and correct all the bugs reported back. Over a period of time it will be 'fool proof'

[si_the_geek]

After a decent amount of testing myself, I always used to grab whoever was walking past (nobody who knew about the project), and ask them to use my program without any instruction from me; and if possible, get them to tell me what the program was doing.

Using that method I quite often found minor changes (such as label captions) that really clarified things for the users.

[Hack]

Don't let fools use it?

This is the best advice, but if we all followed it we would all be out of jobs.

Following what GaryMazzone said, I was always told that: "You can make an application fool-proof, but you can't make it idiot proof."

One of the bigger issues with applications, especially during their initial rollouts is "flow". If you (and your should) error trap all of your routines, code your app to the specs provided, you will wind up with what you feel is just a wonderful piece of coding craftsmanship.

Then, you show it to your customers and "nothing works" as far as they are concerned. Meaning, it doesn't make sense to them. Your customers are business people and have a way of doing things from Point A/Start to Point X/Finish and if your program and screens don't follow that "Flow", your customers are going to be completely confused with respect to using the tool you have built for them.

We make a point of getting them, and keeping them, in the whole process development picture and that does help.

[wossname]

Be imaginative, look at your program and try to think of inventive ways to break it. A user is supposed to hit a button after filling in a textbox, but what if he hits it 1000 times, what if he decides to delete all of the config files half way through using the program? What if your user loads up 500 images in MS word and your app runs out of ram?

Failing that just give it to a user and they'll break it instantly.

[Hack]

Failing that just give it to a user and they'll break it instantly.

If they are anything like my customers, they will be much quicker than instantly.

[GaryMazzone]

An actual comment from one of customers was:

"Well you did exactly what I told you but that is not what we want. We realy want this." Also known as the Bring me a rock method. When you bring the rock it's not quite the rock they are looking for and they tell you to bring them another rock until it's the rock they want.

[Hack]

"Well you did exactly what I told you but that is not what we want.

If I had one pitiful little dollar for everytime I've heard this, I could retire.

[si_the_geek]

I once went from one project just like that (even tho I kept them involved all the way thru), to one where they pratically wrote the program spec for me.

The second was still being hailed as 'perfect' six months later (only had a couple of minor bugs), while the first was still requiring minor alterations to fit with what they wanted (multiple bugs added by the alterations!).


The moral of this story is to get the best program definition you can from the users before you start, and keep them close by while you make any decisions that effect their view of the system.

[capsulecorpjx]

Could you share some tips on how to fool-proof' an application?

Constrict their input. For Visual Basic, you can use Regular Expressions, so you know exactly the range of input you are getting.

[DKenny]

"Well you did exactly what I told you but that is not what we want. We realy want this."

I this sums it up nicely.

[eranfox]

Hello dee-u,
I can tell you what a Q.A. Manager told me once:
He said:"Everytime we need to make Q.A. on a big project i bring my KIDS to play with the computers.

they know how to make things to crash.

So if you have small kids or have a little nephew or something like that,
take him/her to test your app - the ultimate Q.A. is in the hands of small children.

Best Regards,
ERAN

[dee-u]

I this sums it up nicely.

[Teckniel]

I think the other problem is: different computer configurations....
On my program: 5 a 7 people from the 100 users where having problems.....
and i had no clue on how to fix it
So my sollution was easy: I gave them a refund.

Problem 2: in most cases it is experience (thats what I think)

Note: this was my first program that was designd for selling.

[mendhak]

I this sums it up nicely.

I was just thinking of posting this image.