Proofreading a document can be a tricky task for a software tester. We spend much of our working waking hours testing and checking the result of programming languages rather than our own natural languages.
I don’t write this as any of a perfect, exhaustive, always applicable nor particularly sensible list of approaches, but one that I consider when faced with anywhere from a few hundred characters to a few hundred pages of text in English. Note also, that it’s only roughly ordered:
- If they’re not there already, copy the contents and paste them into a word processing application (of whatever choice takes your fancy). A spelling and grammar checker can be quickly called into action, often providing a quick initial review. If you find that’s already been done, that’s great – it’s only a small amount of effort on your side to have done it again.
- Click the links, whatever they may be. Are they valid, does the link text have any relationship with where the link takes you, does an email template open with the correct email address and subject line already added? Do the links work if I’m outside of, for example, a company network?
- Compare the formatting across different lines, paragraphs, sections and pages. Is the indentation the same, have we changed font, colour, number of spaces after the end of a sentence (aside: a personal favourite to find), do we have headers and/or footers throughout, etc. Consistencies in a document can improve readability, in my opinion.
All of those and we’ve yet to actually start looking at the text itself. If you’re still reading, here are some ideas of where to go next:
- Read the text out loud (or “out loud” with your own internal voice) without paying any attention to content – don’t get drawn in to what it’s saying, remain detached. Your language parsing brain should still spot inaccuracies in the sentence as you’ll try to stick to a general flow and tempo, and things like repeated words, incorrect tense, overly long sentences, missing commas and the like will cause your “voice” to falter – if it does, dig deeper.
- Look at the end of the document, particularly if you’re not the only one on review. It’s natural behaviour on the part of a reviewer to start at the beginning, and often natural behaviour to have lost some focus before the end. Be different – look at something that might have had less coverage.
- Are any of the dates, times, version numbers, etc. out of date? Particularly in the case of a document that existed before that’s being updated or refreshed, things can get missed and remain at their previous values.
- Are there “To Do!” comments or similar in the document? If so, point them out! Yes, the writer may be well aware they’re in there and are still to be done, but they also might think they have already resolved them all and would welcome your note. Just because you think the author probably knows about it already, doesn’t mean they do.
- Often last, I’ll actually read the content of the document. At this point, understanding the material helps but even then, you might be coming at the document from the point of view of a new user, so don’t be put off by something new as it’s an opportunity to learn and ask innocent questions where the document isn’t clear.
What approaches do you use for proofreading documents?