Hi again all, welcome once more to a wonderful journey into the world of testing. Or, as we in the industry like to call it, “Testopia”.
Today I shall introduce to you what I call the “Lazy methodology”. The irony of this name is that it actually requires some thinking power to use it, so there really isn’t anything lazy about it at all for the tester. This methodology hearkens back to my days a software developer. Yes, I remember it as if it were only 9 months ago. Usually when you come across any moderately complex programming problem, there are roughly 3 ways of attacking it:
– The right way
– The wrong way
– The way that will look right until someone gives it a little push and it all falls to bits
Often doing things “the right way” results in doing a lot of extra work, like adding in all that exception handling, checking for null values, thinking about lots of different scenarios – all that tedious stuff. So at about 4pm on a Friday, that third option is starting to look pretty tempting, I mean you could just make it basically work and by the time anyone wises up enough to test it thoroughly you’ll probably have gone back to fix it up anyway. So maybe you put in a little “To do” comment or just mentally note it and you check it in and go on your merry way. Or maybe you just think, well, nobody’s going to really notice, and you just do the bare minimum and hope nobody tries to test it too much.
When you find an area where you think this might have happened, this is like finding a gold tooth in your cereal box. It’s disturbing, but if you keep on digging through the cereal you might just be rich. So keep hitting that area for all it’s worth. And sure, that’s the easy part, obviously the hard part is finding these hotspots to begin with.
The best way to do this is to look at an area and think to yourself, if I was a programmer, and I was feeling really lazy, what sort of shortcuts would I take? Good ones to think about are:
– Checking null values, whitespace, invalid characters
– Adding lots of data to a single page
– Adding duplicate values
– If it’s likely to be using an IF statement to check for one value or another, perhaps an ELSE was not also taken into account – check a different value entirely
– If a control looks “borrowed” (if it was originally used elsewhere and has just been adapted for this new section), check to see if it works correctly for this section or if it has just been pasted in there without much checking done
– If something looks like it’s gone, refresh the page to see if it’s really gone
And most importantly, don’t overestimate people. Don’t go thinking things like “well obviously they would have checked the security group to find the security group members”, because you never know when some weasel is going to hard code an array and leave the rest of us looking like turkeys inadvertantly using a hard-coded array as a security group for 2 years.
Till next time, keep on doing what you’re already doing. Go inertia.