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.