(I’ve changed a couple of details here to maintain confidentiality. On the other hand, I’ll bet something like this has happened where you work, too.)
A while ago I was working with a tester at a client site, and I observed a problem: one word in a status message dialog box was misspelled. Due to a frozen severity classification system and (worse) to the kind of thinking that accompanies it, the tester initially classified this as a low-severity bug. I believed, as I still do, there were good reasons to classify it as higher, even though it might be easy to fall into thinking of spelling errors as trivial. As Jerry Weinberg suggests, it might be tempting to think of bugs as “important” or “trivial” based on the effort required to fix them, but there are other dimensions worth considering.
The spelling error might be a threat to the image of the development organization. A product that looks sloppy on the outside makes me mistrustful: “If they didn’t fix this immediately apparent bug, are there more subtle and more serious bugs that they didn’t fix?” And if you think that all spelling errors are created equal, consider what the people at the Cleveland Pubic Library might think.
The spelling error might add noise to the testing effort. Bugs that are prominent and easy to find tend to get reported, and often multiple times. Reporting a bug takes time away from test design and execution—and therefore from test coverage and other things that may well be more valuable. Duplicate bug reports are like weeds that have gone to seed in your tracking system. “Why didn’t you find that bug?” One very plausible answer is that we were busy dealing with other—and quite possibly less important—bugs.
The spelling error might hamper testability. I remember a product that reported “Configuration complete… exciting”. Truth in advertising; for that product, the fact that the configuration completed at all was fairly exciting. However, an automation script that looked for the correctly-spelled string never saw it. Humans have tacit knowledge that allows them to deal handily with spelling mistakes, as any reader of Twitter knows. Machines don’t perceive the intention of the communication repair it the way people do (look at Harry Collins’ The Shape of Actions for a description of his notion of repair). In fact, it took human eyes on on the output string to determine why the automation was failing, even though the configuration was being completed successfully. The automation shouldn’t be looking for result strings at the GUI level, you say? The GUI was relaying this string from a lower-level interface. The automation should be looking for error codes instead of result strings? Well, of course, the same kind of problem can happen with invalid error codes too, so look for such problems by observing outputs as directly as possible every now and then.
In a case like this one, it might be tempting to adapt the automation to work around the problem. I’d push back on that idea. Eventually someone will go to the trouble of fixing the spelling error, such that the automation that now depends on the error will begin to fail again. This is bad enough for testing in-house, but some products also get tested by people further downstream.
As Freud is rumoured to have said, sometimes a cigar is just a cigar. But a bug is never just a bug; a bug is a relationship between the product and some person—end-users, programmers; other testers. It can be easy to classify problems in a certain way based on a default categorization scheme, but for any bug, there may other factors that simply don’t map to the scheme. Remember to treat your categories as heuristics, not rules. Don’t fall aslep!
I once started a new job to discover that my employer’s flagship product contained five spelling errors on the opening menu display. Individually, one could easily argue (and many had for years) that these were not worth fixing. However, the combination of five spelling errors on the screen at once, on the most viewed screen in the application, made us look bad. These spelling errors were in conflict with the image we intended to project as a provider of accurate information for professionals. Additionally, one of the errors significantly changed the meaning of a legal disclaimer.
When I first reported the spelling errors, I was told that I was being nit-picky; that a few typos weren’t worth fixing. I then made the argument that these typos harmed our credibility and potentially increased our liability. It didn’t take much effort to convince people to fix the issue. All I had to do was reframe these spelling errors and typos into things that negatively impacted our relationships with out customers.
These typos were then fixed in a fraction of the time time that had been spent telling each of my predecessors to not be concerned with spelling errors.
It only took a few minutes to make a change to something that had no impact on functionality but significantly improved first impressions.
Michael replies: The “consistency with image” oracle heuristic is sometimes ignored. This is a nice example of it being applied effectively.
Spelling mistakes are one of those things that the change to working closely with developers helps immeasurably. Just before I read this, I had spotted a spelling mistake in one of our messages and just asked a developer to sort it. No fuss, no bother, no requirement for a defect report before it could be fixed, just done.
It also helps that I can make these changes myself if required.
Michael replies: I am a fan of lightweight approaches to fixing lightweight problems. Some problems don’t really deserve to make it to a tracking system. I do like to be cautious about making changes myself. At least I want others to know about them; that is, I don’t want to make them unilaterally.
Dang. And in my commenting on typos, I make a typo.
All I had to do was reframe these spelling errors and typos into things that negatively impacted our relationships with OUR* customers.
I totally agree that spelling errors shown to an end user should be logged with a higher severity because it does look bad for the organization as a whole. At one client site we added a field to mark if a bug was viewable by the end user or not. If a bug was viewable by an end user it would get a higher priority.
Michael replies: Personally, I’m often just as worried about bugs that are invisible to the end user. Maybe more worried.
I can’t remember a time when I found a spelling-error bug unworthy of being fixed immediately. They’re black eyes that can erode user trust (for non-spelling-challenged users!), and they’re almost always easy to fix. Same goes for stilted usage and poor grammar. I don’t expect error messages, for example, to be high literature, but I do look for them to be crisply written.
Hi Michael. I love that you misspelled the title of the post! Nice touch.
I wanted to chime in and mention that misspelled words in source code is a problem as well for many of the same reasons. It can be difficult to search for code and that leads to maintenance problems and bugs.
Also, on one project most of the static text was stored in a database. I pulled all of those strings out of the table and used a spell check on it and discovered 17 misspelled words. It saved us a lot of time!
Joe
Michael replies: Long, long ago, there used to be a tool called AppPolish that would look through the resource table of Windows program for spelling errors in strings (among other problems). I wonder what happened to it.
And you’re right: misspelled words or variable names in source code can pose persistent problems, especially in languages that don’t require you to declare your variables.
[…] Blog: Mispelled Words? Written by: Michael Bolton […]
You are right Micheal that bugs like these need attention. The real threat they offer is a dent to company’s reputation. Once we were evaluating spell-checking tools and found one tool to be good. During evaluation we spotted a spelling mistake on their home page and thought how can they fix our issues if they can’t fix their own.
Michael replies: Not long ago I watched as a tester used a test tool to help him get things down faster. The degree to which the tool had annoying “features” that slowed him down left me astonished.
One wonders which is worse: the idea that test tool vendors use their own tools to support their own testing, or the idea that they don’t.
“The spelling error might add noise to the testing effort”
In my opinion you can get rid of the word “might” in this sentence. There comes a time when people wonder why the bug backlog is growing bigger and bigger and is no one interested in these bugs?
Another problem is that information gets stale over time. I remember a list of 10 spelling mistakes noted in a poorly documented bug report. It took a day to track down the messages in the system and verify that they had indeed been corrected some time ago. If done immediately that would have been half an hour of work – technical debt is growing over time due to information staleness.
Hi Michael,
Nice post!
Were grammatical errors in your post also intentional?
Was that an exercise for the readers? 🙂
Michael replies: Two errors were deliberate. As usual, I took some liberties with strict grammar. In fact, I don’t know what you’re referring to, so you might want to ask a more specific question. (That’s an important heuristic for testers: be specific.)
Hi Michael, I didn’t mean to point out mistakes (sorry if it appeared that way). I was only curious because there seemed to be errors which appeared deliberate.
Michael replies: I appreciate it when people point out mistakes like that. As a tester, that kind of thing is your job, isn’t it?
It appeared to me that the sentence in your post (below) did not follow grammar
“The automation should be look for error codes instead of result strings?”
either the ‘be’ needn’t be there or the ‘look’ should be ‘looking’
Thank you! Fixed.
Not all typos are created equal. A non-software example, but one of my favorites: The first printing of a certain RPG rulebook had the word “countermeasures” misspelled in the table of contents. They’d left out the “o”.
They did seem appropriately horrified when I pointed this out to them at their Gen Con booth within minutes of picking up a copy of the book.
Seems like this is more suitable here (wrote part of it on a specific typo example sub-post):
There is the trivial typo, which can easily be tested running any speller (MS Word) on the Locale files.
(>>> Though not too many do that – most “prefer” to waste time writing and managing typo bugs testers just happen to encounter – one at a time (or just miss them all together))
And there are such bugs which speller might miss, as its a legal word out of context – these are harder to find – and require human to spot them.
As locale files are now almost in any system from GUI to Embedded, I just can’t figure out those companies who don’t use speller on these.
As this is the shortest way to the target of having as less typos in the system.
You can test any language with this method – while it might not be 100% accurate in these cases where you don’t know the language – at least its a basis to indicate to professional writer where to look at first.
@halperinko – Kobi Halperin
Indeed!!The Errors(misSpelling) Shown To The End User Should Be Give Higer Severity & priority.
But In Most of The Cases Specially In Dialog Box We Assign It Low Severity & Priority.
Michael replies: Well… yes.
Great post.
While I almost always understand that bug fixing involves important project trade-offs (introducing more risk, effort to fix has opportunity costs, etc), I cannot see a good reason for allowing spelling errors in the released product.
In bug reviews, where someone is advocating not fixing spelling errors, these reasons usually win over the decision maker:
– Spelling errors reduce customer confidence in the quality of code that is not visible. (if we can’t get spelling right, what confidence should they have in the business logic?)
– Effort to fix is almost always, literally, a keystroke or two.
– Regression risk is almost always nil. Changing text is one of the least risky changes in a system.
(hopefully, dear readers, you don’t have to make these arguments too often. Having to argue against spelling errors is an indicator of deeper mindset issues in the organization)
Thanks,
John
Thank you for the article. By the way, did you really meant “Cleveland Pubic Library” or was it a Freudian thing?
Michael replies: Was the joke too subtle?
Michael,
Great article. These misspellings also slow me down as a tester because I have to ask myself did I report it before? Did the bug get assigned to a developer? Did the developer not fix it? Do I have the build in which it was fixed?
Is the title suppose to be misspelled? You have it as “mispelled”. I used the google oracle to see how it should be spelled. Would fixing it cause the links to this blog to become stale? Perhaps that would be a reason not to fix it. You would have to weigh that against the impact it makes to your reputation as a tester. The fact that you indicate two intentional mistakes explain the reason for this error unless it wasn’t one of the two.
Also the last word in the original article is “aslep”, but I think you meant asleep.
Michael replies: Thank you for your concern. I’m not worried about the two errors you’ve pointed out, but I am beginning to worry that my jokes are getting too subtle.