22 March 2022

Quality as standard.
Defining the LQA workflow and how to optimize it.

Quality as standard.<br><strong>Defining the LQA workflow and how to optimize it.</strong>

Aristotle said that quality is a habit, not an act. It’s very much the guiding principle behind linguistic quality assurance (LQA), where value is added through a highly structured iterative process aimed at removing mistakes and ensuring consistency.

But what exactly is this process and how does it work best? This white paper provides answers to three key questions:

  • Why do we need LQA?
  • What does the LQA workflow involve?
  • How do we optimize the LQA process?

Why do we need LQA?

Before getting into process details, it’s worth understanding a little bit more about LQA and why it has become an indispensable element of localization services in the 21st century.

The ever-increasing push towards automation is as much a feature of the localization industry as it is in any other. Advances in machine translation and the sophistication of translation management systems offer clients the opportunity to localize greater volumes at higher speeds for lower prices.

But, in the midst of this technologically accelerated workflow, how do we assure quality? Machine translation is undoubtedly improving at a rapid pace but it is far from error-free. Any reputable localization service provider (LSP) always recommends it is used only with a human post-editing stage, unless time or budget absolutely prohibits this.

Whether linguistic content is translated by machines, humans or a combination of both, it has to be migrated onto a technology platform such as an app, a software program, a game, a mobile or web platform. During both the translation and migration of content stages, errors almost inevitably occur. In terms of linguistic quality, common errors – referred to as “bugs” in LQA parlance – include:

  • Inconsistent terminology
  • Grammar, punctuation and spelling mistakes
  • Inconsistent tone of voice
  • Layout issues (such as text not aligning to relevant graphics, buttons, etc)
  • Untranslated content.

When localizing for a critical product launch across multiple territories in a variety of languages, for example, identifying and rectifying these areas requires both a strategic understanding of the overarching goals alongside pinpoint precision in terms of data review and revision.

LQA aims to meet this need. Because this review stage is considered such a crucial part of the localization process, many clients insist on using an LQA service entirely separate to their original translation/localization provider. It ensures that quality checks are carried out in a completely transparent space, where any quality issues are assessed independently and without prejudice.

What does the LQA workflow involve?

While a growing number of businesses understand the value of the LQA process, many who have not previously contracted this kind of service are unclear as to the different stages it involves. This white paper aims to fill that knowledge gap.

Although each LQA process is unique, it is reasonable to expect four key phases. These are:

  • Set-up
  • Pre-testing
  • Testing
  • Post-testing

Set-up

When it comes to setting up an LQA workflow, the first thing to keep in mind is that each client has different needs and a different level of understanding about LQA. The process of setting up the workflow is not merely a process of asking what the client requires and responding with a list of relevant services.

LQA is a complex and relatively new field; sometimes clients without previous experience are unclear as to the scope of their requirements. Often, it is more useful for an LSP to open the dialogue by outlining the kind of services it offers and exactly how they address various issues.

Listening is a really important part of this process. An LSP of course must fully understand a client’s needs and goals in ordered to develop a tailored solution to meet them. This involves being realistic, pragmatic and honest – overselling the ability of technological solutions or raising unrealistic expectations of outcomes is to no one’s benefit.

The importance of this initial dialogue, in which both parties learn more about each other and define a shared set of goals and processes, cannot be overstated within the context of the overall success of the project. Pre-testing

Abraham Lincoln once said “Give me six hours to sharpen a tree and I will spend the first four sharpening my axe”. While the setting is usually less rural, the emphasis on the value of preparation is nevertheless equally valid within the context of LQA testing workflows.

In this phase of pre-testing preparation, seven key elements can be identified.

  1. Test cases preparation. In the first instance, the client provides functional test cases and scope for each testing phase. The LSP then goes through the testing flows and adapts the functional tests to linguistic settings. This testing cycle is then passed back to the client to review and confirm that all relevant pages/flows are covered.
  2. Training. LSPs specializing in LQA workflow testing are familiar with many of the most common testing tools such as JIRA and Rally. However, if the client uses particular workflow testing tools that are unfamiliar to the LSP, training should be provided. The LSP test lead can in turn train the in-house team of testers.
  3. Style guides/glossaries. Style guides and glossaries are crucial in assuring linguistic quality. If the client has language-specific style guides and/or glossaries, these should be forwarded to the LSP in a timely manner so that the testers have time to get familiar with them. If they are not available, an LSP can advise on the best process for creating them.
  4. Reporting progress. Transparency is an essential element of any successful LQA testing workflow. So it is important to identify from the outset the client’s preferences on the best channels through which to provide testing progress updates and the frequency at which this should occur. Tools such as TestRail can prove useful for monitoring daily progress; cloud-based spreadsheets (such as Google Sheets) or emails are other alternatives.
  5. Reporting bugs. Finding (and then eliminating) bugs is of course one of the core aims of the LQA workflow testing process. Identifying an appropriate bug reporting tool is therefore critical; both parties should understand how to use this tool effectively before testing begins. The client may have their own preferences or an industry-standard bug-reporting tool such as JIRA can be used.
  6. Bugs categorization. Categorization of bugs is essential is in optimizing the LQA testing workflow. Prior to testing, the client must approve the categories and level of detail required in bug testing. Common categories include:
    • Grammar mistakes
    • Punctuation mistakes
    • Layout issues
    • Style guide and glossary compliance issues
    • Date/time/currency format compliance issue
    • Mistranslation
    • Untranslated content.

Testing

While each testing process is unique according to the pre-agreed specifications, the workflow follows a set of protocols which often contain many or all of the following stages.

  1. Testing environment is ready. At the start of the testing phase, the client communicates to the LSP test lead that the product is ready for testing. This may be a staggered process as the product may not be ready for testing on all platforms (mobile versus web, for example) at the same time. Once all product access details are provided, the LSP installs the testing build on all in-house test devices such as mobiles or tablets.
  2. Testers receive hand-off. This is an in-house stage for the LSP in which the test lead provides testers with all the relevant details required. This includes staging information, test cases and bug-reporting guidelines as agreed with the client during the pre-testing preparation phase.
  3. Testing starts. When the preparation is complete, testing begins. The testing team carries out all designated tests across specified platforms and logs bugs accordingly in the bug-reporting tool.
  4. Test reporting. Using tools such as TestRail or custom dashboards, progress reports on the testing process are available to both client and test teams on a continuous basis.
  5. Test/client team feedback. According to the data provided in test reports, the test team or client team may identify specific issues for attention. Communicating transparently with the client, the test team lead may then recommend modifications to the test in progress.
  6. End of testing. Steps 3 to 5 repeat until the testing process is complete. The testing phase ends when all the test cases have been executed for all the relevant platforms and all the bugs have been filed.

Post-testing

Once testing is complete, the LSP provides the client with a complete report detailing all bugs and issues found during the testing phase. Three post-testing stages can then take place.

  1. Bug fixing: The client works with its translators and/or bug-fixers to fix the linguistic bugs.
  2. Bug verification. Once the bugs have been fixed, the client provides update builds to the LQA vendor. The testing team checks each bug and if it is verified as fixed, closes it in the bug-reporting system.
  3. Regression phase. Clients can choose to request a regression phase, which involves a new round of testing which takes place after the bugs have been fixed and verified. The aim of this round is to ensure that the product is linguistically sound and that no new bugs have been introduced during the bug fixing phase.

How do we optimize the LQA workflow?

When discussions take place about how best to optimize the LQA process, the “agile” workflow is a paradigm that is often mentioned. It is certainly true that the ability to respond to issues as they arise and to continuously evaluate and recalibrate processes is at the heart of any successful LQA project.

The best kind of agility, nevertheless, is in fact built into workflows from the start. LQA providers with experience know that flexibility and responsivity are values that should be inherent in any workflow process and the platforms upon which it relies. Agile environment tools such as JIRA and Kanban boards help to facilitate this process.

While technology plays a huge part in the LQA process, optimizing it can perhaps be best understood with reference to the three core pillars of empirical process control: transparency, inspection and adaption. These pillars form part of the Scrum Guidelines, a framework initially developed in the 1990s to manage and develop products.

Whether the process is working well or badly, transparency is essential within the LQA workflow, so that both client and LQA provider can understand their responsibilities and are accountable for their actions. In order for transparency to exist, inspection by both parties should form an intrinsic part of the workflow. Following on from inspection, both sides need to understand when changes are required and how to adapt accordingly.

These principles are, of course, simple to understand yet hard to master. Yet to be transparent, to inspect and to adapt as part of a partnership approach between client and LQA service provider provides a guiding framework upon which continuous improvement in quality standards can be built. Aristotle, it is hoped, would have approved.

Looking for LQA support?

Alpha CRC is happy to help. We provide LQA and localization services to clients around the world, helping them maximize impact and improve returns on localized content.