Empathy, editing, and software QA

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.

Shapes and forms in everyday scenes

Like many people, I enjoy taking pictures with my phone. I keep an online photo album on Foto. During the summer, I spent a lot of time following photographers on Instagram. Looking back now in early autumn, I can see how much their pictures influenced my subject choices and photo editing at the time.

The industrial sublime and the beauty of the ordinary are both very popular on Instagram. I can easily understand why. There’s a thrill in spotting beautiful shapes and forms in seemingly everyday scenes. It’s a way to enjoy life as well. Why assume that beauty only exists in popular tourist destinations? Why wait for your holiday to recognise it?

Some Instagram photographers favour an editing style that gives pictures a smooth, glowing sheen. I saw it most often on colour photographs. It’s often used with great results on Americana, such as roadside diner scenes. This look can be achieved in Snapseed by fiddling around with the different tools, including one called “glow.”

You can see these various influences in the photographs in this blog post.

I took the first picture in a village called Parkgate. It shows Black-headed gulls attracted by tourists and their food on the promenade. I’m not sure whether the birds at the back really had such pale heads or whether I overedited the photograph.

Gulls at Parkgate in Cheshire

The two street scenes below are quick shots taken through a car window. They’re both somewhere on the Wirral Peninsula. The signage and the colours really caught my eye. “Dog happiness” sounds wonderful.

“Ten minutes from here is dog happiness”
Hays Travel

The two photos below show bridges on major roads. As you can see, they’re heavily edited to give them a very glowy look.

The proportions on motorway bridges are often quite beautiful.

Some motorway bridges would make good landscape paintings. I’ve seen several where the bridge, the curve of the road, the surrounding trees, and the colours of nearby lorries combine to create a pleasing scene.

Triangles formed by the exit ramp of a bridge doubling back on itself.

In the picture above and the two below, I liked and still like the repeated shapes.

How many repeating triangles can you see in this picture?
I saw this from a motorway in the Birmingham area. I like the colours.

I’m fond of these photos because they remind me of things I did this year, but I’m not that keen on them aesthetically. I think I went too far with the editing.

Regression tests and knock-on effects

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.