Fringe use cases and obscure bugs are always going to pop up – even the most intense testing won’t necessarily turn up every little issue. Sometimes the tiniest mistakes made during development can turn into embarrassing, public bugs. To catch these bugs before launch testers would need to be very, very meticulous about testing every combination of actions (something that’s just not practical) or pour over every line of code with a sharp, critical eye. Here’s the most recent real-world example:
Sophos’ Naked Security blog dissected a bug in Apple iMessages that has conspiracy theorists going crazy. If you send a message reading “I could be the next Obama” with an extra space at the end of the sentence the message will be delivered with the word “Obama” missing. As it turns out, the bug is likely the result of a very tiny mistake in the code.
The most credible explanation I’ve seen is that the code that presents the message reckons that it will just fit on one line, and prepares a one-line bubble for the purpose.
But the code that actually formats the message reckons that it won’t quite fit on one line, and thus renders it with the last word on a second line.
In short, the word Obama is there; you just can’t see it.
You can imagine how this might happen: a bug that’s a relative of what’s called an off-by-one or fencepost error, because a fence that is X sections long actually needs X+1 fenceposts to finish it off.
Here’s a visual example of this sort of programming mistake:
|
1
2
3
4
5
6
7
8
9
|
/* Is this a one-line case? */if (pixelsize(msg) <= pixelsononeline) { specialonelinemessage(msg);}. . ./* Later, processing the message */if (pixelsize(msg) >= pixelsononeline) { multilinerender(msg);} |
The two comparisons have a nasty discrepancy.
The first considers it a single-line message if it’s no longer than number of pixels available on one line.
The second test looks very similar, but expressed the other way around: it’s checking that the message won’t fit on one line instead of that it does.
But the opposite of “less than or equal to” is “greater than,” not “greater than or equal to.”
In our synthetic example, only a message that is exactly the same pixel length as a line will be treated differently by the two code fragments and trigger the bug; all other messages will be handled correctly.
By the way, that’s one reason why software testing is hard.
In this case, for example, it isn’t enough just to test lots of different messages of randomly-varying length; you also need a structured test where you generate and test messages at all possible pixel lengths.
Read the full article at Sophos >>>
It’s a little mistake that testers were not likely to find. We’re not talking a specific number of characters that’s triggering the bug, it’s pixel length so finding the bug would have been the result of incredibly meticulous testing or a totally random coincidence.
Don’t start hyperventilating and panicking that your testing isn’t good enough. I highlighted this story to remind everyone that QA doesn’t mean software is perfect and bug free – that’s not the point of quality assurance. While QA serves a slew of different purposes, when it comes to testing and bugs, make sure you have people and practices in place that will help you find as many bugs as possible before release. Just as importantly, fix as many of these bugs as possible before launch. More bugs will always appear once your software gets into the hands of users – if you are aware of and/or have fixed as many bugs as you can before launch you’re in a much better position to address these new comers.