A classic heuristic is the tool of the week. I had to keep this one as is, just added a rhyme and a pretty picture:
“Too little, too much and just right can be tried On all points where data input is supplied A negative number and one ridiculously hight And also a reasonable one you should try“
So, what does it mean?
This should be the most well known heuristic of testing, right? And also one of my favourite kid stories. So of course it had to stay 🙂
The simplest explanation is that we want to try three different things for every input: One that is our happy path – a common value. I usually try to figure out the most common one and use that. (This is my Tester Testsson, firstname.lastname@example.org, 40-isch years old and about as common as common goes)
Then we have a value that is “too small”. This can be different things depending on the scenario. Common values I use are 0 (zero), negative numbers or just smaller than the smallest acceptable value. Here we might have someone zero years old, trying to order -1 beer or why not a 17-year old trying to vote when the age limit is 18.
And then a value that is too high. I have a tendency for drama so I usually go for ridiculously high but sometimes it’s better to go for _just_ too high. But where is the fun in that?!
Goldilocks can be applied to basically anything and is a good heuristic to keep in mind when developing and testing software. It applies to standard input values, say in GUI:s and such, but just as well for things like file uploads, time-outs and other things you might not automatically think of as inputs.
I wrote a story in Temptress’ trails about a change to a file upload function. Short summary: the team tested only happy path and it all crashed when users started uploading files from their mobile apps which, big surprise, were HUGE. I helped out with the testing after the fix and realised some pretty funny stuff during that testing. We had a file size limit before, but forgot it in the new solution. So, first we implemented that again. (If I remember correctly we adjusted it a bit to handle larger images but that is not related to the story) We tested it with very large files – worked as a charm. We tested it with very small files – worked like a charm. I even tested it with “empty” files (as close to zero bytes as I could get) – worked fine.
You know what didn’t work? Files that were exactly on the spot at the limit. First I thought it was a classic case of boundary value-issues but it turned out to be that different applications calculated the file size differently. What my file manager said was x size, the library handling the size check felt it was x – y size. The backend part receiving it felt it was x + y size. All the chaoz!
Taught me a lot about files at least 🙂
Quote of the day
“She tasted the largest bowl, which belonged to the Big Bear, and found it too cold; then she tasted the middle-sized bowl, which belonged to the Middle-sized Bear, and found it too hot; then she tasted the smallest bowl, which belonged to the Little Bear, and it was just right, and she ate it all.”