Some developers think that testers are mean. "How dare testers misuse this piece of software causing a bug?" Hence, they try to direct the testers, train them in the application, even tell them how to test and what to test including "where not to click". Sometimes that works with more junior testers.
Unfortunately if the testers do not use the application in ways "it wasn't meant to be used", you can be sure that users will do and will find those undiscovered bugs. I rather have the tester find the bugs that have a user find it.
To make matters worst, those undiscovered bugs tend to be gaps in the specifications that say what the system should do but not what the system should not do, or how should it react to unexpected situations.
Experienced testers, on the other hand, know better and will not fall for the developers complains, They know that this level of testing for the unexpected is important for two different reasons:
The first reason has always marvelled me: Users will find ways to use an application for purposes or in ways you never even thought of. Even making features out of bugs.
The second reason is better known as Murphy's law. One day I was in the Lab helping test a stand alone desktop application. At one point the tester told me: Now, save the transaction. And as I pressed enter she proceeded to unplug the computer. I was cold: How would the system react? Will it corrupt the data? Will the system even start again? While that simple test on its own wouldn't be enough to answer those questions, at least it made me ask them and review the design to ensure we knew how the system would react. Now, every time I go through a website that requires me to follow a set of steps, and I suddenly loose connectivity and I'm forced to start over, I realize that the testers of that site didn't test for Murphy's law.
That experienced tester mentality can help us even before a single line of code has been written. If you have a seasoned testers during specification review, they will ask questions to understand how the system will react to the unexpected. Remember, the sooner you find a potential bug, the easier it is to avoid it.
In my personal experience, If you make testers your best friends, you will end up saving a lot of money and most importantly they will help you keep your reputation as a great developer.
Excellent. Excellent reminder even.
ReplyDeleteAnd certainly reemphasizes the importance of the design / specifications review. (There is always an other side of an 'if' to review and accommodate for.) Not just 'what if', but 'what if not'.
Best friends? Hmmm. Not sure documentation writers will agree with you. (-:
Which leads to another aspect to make sure isn't lost ... how will the user get help? Is there a help system? Is it easy to find?
'cause your example leads to an obvious question ... what just happened to my transaction? How do I go about finding out? Did it go through or do I need to re-enter it? If I do, how do I verify it hasn't been entered twice? Do I have the authority to delete one if so? ...
In these days of RAD and Agile, it's all too easy to lose sight of such. Building in robustness is non-trivial, and sight of it should not be lost. 'cause addressing it after the fact can be more painful than preventing it in the first place.
Thanks again for the excellent article and reminder.