I’m a quality assurance proofreader for documents and publications. I’ve been learning about the quality assurance of software. The name of the course is Manual Testing and Defect Management.

It has shown me that software QA and my kind of QA have a lot in common. Clear and methodical communication is crucial in both.

Whether you’re testing a website or proofreading a magazine, you need to explain the problems accurately and clearly so that your client can find them and fix them.

You also need to be sensible about how you assess and communicate the severity of the problems you find. The boy who cried wolf comes to mind here.

In software QA, errors are graded by level of severity and urgency. If you mark everything as urgent, developers will struggle to prioritise the really important tasks and they’ll stop trusting you.

In QA proofreading, if you present every problem as deeply serious, you risk overwhelming your client. You’ll also make it much harder for them to locate your feedback about genuinely severe problems.

I’ve really enjoyed learning about a role that is so similar to my own. Software QA has given me a new way to think about my work.

The two fields aren’t identical, of course. A big difference is the degree to which communication has been formalised.

In software QA, there is an established common system of communication. Testers communicate through dashboards such as Jira, using click boxes, drop-down menus with agreed labelling, annotated screenshots, short videos, and clearly written notes that must contain certain points.

Depending on their job, some QA proofreaders do use Jira (I haven’t yet). But a lot of the time, we communicate with clients by leaving comments on the document itself. I’ve used the commenting features in Word, Google Docs, Excel, and Adobe Acrobat Reader.

Our approach to commenting is often tailored to the client’s unique needs. In other words, clients can ask me to change how I word my feedback and where I put it. If a company has its own particular workflow, I’m happy to learn it.

The comments we leave also have a strong interpersonal dimension. It’s important that the QA proofreader thinks about people’s feelings.

Depending on their team’s emotional makeup, a client may prefer longer or shorter comments. Compare these three:

• “Rude double meaning in slang”
• “This word has an unfortunate double meaning in slang.”
• “Some readers may be aware that this word has a double meaning in slang. It could cause offence.”

A short feedback comment saves time but risks looking brusque or snippy. A lengthier feedback comment is politer and softer but can take longer to read. If a document has 100 to 200 comments, all that polite phrasing can become a snowdrift of woolly waffle that’s difficult to act upon.

The way we leave feedback in editorial QA has a significant impact on the people responsible for the next steps in the production process – particularly when the feedback fails or offends.

I think that’s why I admire the formalised approach used in software QA. It avoids some of the interpersonal risks that come with giving feedback outside a commonly agreed-upon system.

In both fields, the purpose of QA feedback is to enable other team members to take steps to improve things. How we deliver feedback to the people who make things better is just as important as our ability to spot errors.