Quality assurance

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.

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.

How smoke testing applies to proofreading and editing

/ TIDE and CANUTE / 1 Comment

I’ve been learning about quality assurance testing for software. Although I don’t have a tech background, I am interested in the methodical and organised approach taken in software QA.

Every field of work has words that are unfamiliar to outsiders. Software QA is no different. I’ve learnt several new software QA terms recently, including “smoke testing.”

The term originates from hardware engineering. If they turned on a new machine and smoke came out, it clearly wasn’t working. Any further quality tests would be a waste of time and resources. The machine was sent to be fixed and QA was postponed.

In software QA, a smoke test checks whether the software works on its most essential level. Let’s say a QA is smoke testing a new shopping website. They check the following areas:

  • Does log in work?
  • Does product search work?
  • Can users put products in the basket?
  • Can users arrange delivery?
  • Can users pay?
  • Can users log out?

If an early stage in the customer journey doesn’t work, there’s no point in QA testing the later stages. Not being able to log in is the equivalent of smoke pouring out of the website. The smoke test approach avoids wasting money on unnecessary quality assurance testing.

I’ve been thinking about how smoke testing applies to proofreading and copyediting.

When I receive a document or publication, I check whether it has all its pages and whether a significant amount of content appears to be missing. I also have a quick look for anything else that might have gone wrong, such as corrupted text. People do sometimes send in the wrong file or file version without realising it.

If I spot an obvious problem right from the start, I ask the client to check that they’ve sent the correct document before I carry on with my QA. I suppose this is as close as I get to a smoke test.

Something similar but different happens in fiction editing for indie authors. There are specialist editors for each stage in the story-writing process. If an editor thinks that it is too soon for a story to be sent to them, they let the author know. This protects the author from wasting money on inappropriate QA. Fiction editors are in an unusual position because their “smoke test” involves evaluating how well developed the content of a story actually is.

I work on written materials such as courses, business communications, and magazines. My smoke test focuses on obvious errors in production (e.g. incomplete, corrupted, or unexpected material).

I don’t look at how well developed the content is.

For example, I wouldn’t turn to the creator of a British English course and say, “I can’t proofread this. Your course is underdeveloped because you focus on just one accent.” The creator’s content choices would be none of my business.

A software QA for a shopping website would be in a similar position. Their thoughts about the product range are irrelevant to their work. Their job is to check whether the website does what it was designed to do for the customer.

I’m looking forward to learning more about software QA. I wonder what other parallels I’ll see with my own work.

Photo by Kindel Media on Pexels.com