Editing

Communication in QA

/ TIDE and CANUTE / Leave a comment

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.

Empathy, editing, and software QA

/ TIDE and CANUTE / Leave a comment

I’ve been learning about software quality assurance (QA). I’m a QA proofreader for documents and publications. These two areas of QA look quite different, but they both involve empathy for the reader/user.

To QA a website, you need to understand how people really use it. The QA process aims to catch anything that could cause problems for the user. This includes obvious defects, such as broken links, and areas of friction, such as confusing navigation.

Empathy for users is also important in my area of QA.

We often say that editors and proofreaders are “advocates for human readers.” In addition to looking for mechanical defects such as grammatical mistakes, we’re also alert to areas of friction. For example, an editor commissioned to carry out a Plain English edit would identify complex scholarly phrasing as a friction hotspot.

Software QA and editorial QA take different approaches to testing the reader/user experience.

The Think-Aloud Protocol

The Think-Aloud Protocol tests how real people navigate through a piece of software. Observers watch the test participants without intervening. The participants verbalise their thoughts as they go. This allows the observers to spot which areas of the software run smoothly and which cause friction.

In the editorial QA version of this scenario, there is no test with observers and participants. Instead, the editors or proofreaders are the text’s first external readers. In other words, we’re the first people outside the production team to read the text.

As we read, we observe our own reactions and use our own judgement and experience to think about how other readers may react to the text. What we consider may depend on the instructions in the editorial brief. For example, an editor might focus on accessibility.

Empathy and scope in editorial QA

In editorial QA, exercising empathy for the reader is a matter of scope.

If you ask an editor to perform a heavy edit, you’re really asking them to think deeply about many different aspects of the readers’ experience of the text. The editor will find out who the intended readers are. Then they will use their editorial training and experience to make significant changes to the text to make it more suited to those readers.

This kind of editing is both subjective (the editor’s assessment of readers) and objective (known editorial techniques).

When we’re asked to carry out a lighter edit (such as a light edit, proof-edit, or proofread), we don’t focus so deeply on the readers’ experience. Instead, we look for issues in the text as it stands. Are there:

  • contradictions?
  • ambiguities?
  • inconsistencies?
  • unexpected problems?

Empathy for the reader sometimes comes into it, but not always. Here’s how I would categorise some of the issues I might come across when proofreading.

  • Contradiction: The cat is brown on page 1 and white on page 2. (No empathy needed.)
  • Ambiguity: It’s not clear who is doing what in this sentence. (No empathy needed.)
  • Unexpected problem: The same paragraph is repeated three times. (No empathy needed.)
  • Ambiguity: This word has a double meaning in slang that could embarrass the client. (Protectiveness of client)
  • Unexpected problem: The sudden change of topic confused me and could confuse readers. (Empathy for readers)
  • Unexpected problem: This AI output contains biased attitudes. (Protectiveness of client and empathy for readers)

Naturally, this blog post isn’t a definitive guide to the differences between heavy and light editing. I’ve carried out both, so what I say here is based entirely on my experience.

To me, heavy editing is always very heavily stamped with the question of “What is best for readers?” This is balanced with “How can I preserve what the writer originally said?” The editor has to stay true to the writer’s intention while putting significant changes in place. This is an exercise in empathy in itself.

Lighter editorial work seems to leave a lot more space for the pre-existing wording of writers/clients. This is generally because the aim is to change text only when needed and leave feedback only when necessary.

Regression tests and knock-on effects

/ TIDE and CANUTE / Leave a comment

I’m a quality assurance proofreader for documents and publications. I’ve been finding out about the methods used in software quality assurance to see how they can help my work.

Most recently, I’ve learnt about a software QA approach called regression testing.

What is regression testing?

Let’s imagine the website for a major museum. It has hundreds of webpages designed to help visitors learn, book events, buy products, plan their visits, and take full advantage of museum membership. Each webpage has at least five to ten clickable or moving parts that must work. When some don’t, it risks disappointing visitors and making the museum look unprofessional.

Each time a function is added or modified, the QA team carries out regression testing. This means checking that the change works and hasn’t had a negative knock-on effect on related features and areas known to be fragile.

The QA team doesn’t check the complete website. That would take days and cause delays for the museum. Instead, they follow a carefully chosen testing plan, focusing on the parts of the website that could be affected by the new change.

Do proofreaders carry out regression tests?

In my previous blog post, I noted that smoke testing in software QA is similar to something that proofreaders and editors do when working on written materials. I’ve been wondering whether proofreaders and editors ever carry out anything like a regression test.

There are times when a proofreader might be asked to check a new addition to an existing text. Let’s imagine a publication unexpectedly replaces one page immediately before printing. A proofreader would check the page itself and then look for knock-on effects in related areas. They would ask:

  • Has the page numbering been affected?
  • Does the contents page need updating?
  • Is the content of the deleted page referred to on the front cover or anywhere inside?

In this scenario, the proofreader is most likely to be an in-house person who is on shift with the production team until the printing deadline. I experienced it myself as a young intern, waiting in a production office until the print deadline at 9pm.

As a freelance proofreader, I’ve sometimes worked on complete texts with very short deadlines. But I’ve never had to carry out anything like a regression test. It’s unlikely that any team would email a freelancer to ask them to check one thing with just 20 minutes to go before the deadline.

In my role, I usually check the entire document or publication. This is the opposite of a regression test, which focuses on a change and its knock-on effects.

Knock-on effects and multi-author texts

Although I don’t carry out regression tests, looking for knock-on effects is a very significant part of my work. This is especially the case when I proofread multi-author documents. When several people contribute to a piece of writing, the changes they make can affect the material that their co-writers have already added. For example:

  • Author A includes surrounding villages in his description of a town, but Author B only considers the town itself. To readers, the town seems to vary in size and population from one page to another.
  • Author C uses the new name for the town, but Authors A and B use the old name. Some readers are left unsure whether the document is discussing one town or two.
  • Author B writes that no photographs exist of the old town centre in the 1920s. Author C adds a 1920s photo of the old town centre to the last page. Some readers wonder if the photo caption has the wrong date on it.

Authors A, B, and C aren’t real people and the above scenario is a little extreme, but it does show how written documents can be susceptible to the same knock-on issues as websites.

I don’t know how you feel about them, but I’m very interested in knock-on effects. I’ve enjoyed thinking about their significance to both written materials and software.

A malfunctioning button on a website and contradictions within a text are two very different things. But both can result from the unexpected consequences of an addition or modification.