Organizations across the globe are modernizing their legacy systems. Because this involves a lot of development work, the quality analyst (QA) is, unfortunately, often sidelined. This is, however, a huge mistake: a QA plays a significant role in eliminating technology debt, making modernized software valuable and delivering sustainable value.
From my exploration of working on legacy modernization projects for customers across the globe, here are some ways in which QAs can help ensure success.
Deep-dive, understand, compare
It’s important that QAs begin by gaining a comprehensive and confident understanding of how the organization operates. Studying how the business has functioned over the last few years and how it sees the world (ie. its customers and users), will make it much easier for QAs to test from the user’s perspective.
QAs then need to perform a comparative analysis. They should ensure that the modernized software offers — at the very least — what the legacy system offers in terms of functionality and business value. These comparative checks should be included in the test validation/verification strategy. A few comparisons that might be incorporated are:
User experience
Populating the page with data from the backend
How easy it is for the end user to use
Business calculation logic
This comparison will help build the necessary foundations to build trust in the modernization project and its eventual output. In turn, this will enable easy adoption.
Make it performant
Organizations modernize their technology to improve performance. Only when that is delivered, will adoption improve. For example, in one of my projects, we brought down the cycle time for payments for an insurance claim from 20 minutes in the legacy system to 4-5 minutes in the modernized system; this was by improving infrastructure and solution design.
A QA must foster these performance improvements and publish performance metrics to get the business teams to buy into the initiative.
Continuously add value
Legacy modernization isn’t just about replacing a system; it’s also about continuously improving it. While there may be many stakeholders involved in such a project or product, a QA should view value-add as their responsibility. This is because, as testers, they’re close to users and in a unique position where they can consider various ways products can be improved that might have otherwise been missed. Some improvements they can bring into the system are:
Eliminating mundane and repetitive tasks
Adding helpers/autofills to make forms easier to use
Adding notifications about changes in state of concerned items in the system
Showing insights and calculations for faster decision-making
Enabling easier access to frequently used references/documents
Introducing fraud identification and prevention
Contract test the integration points
When a new system is integrated with the subsystems of the legacy system — be it upstream or downstream — contract testing is immensely valuable. When run in the pipeline with every commit, contract testing acts as a safety net to prevent breaks in these handshake points.
Enable adoption through before/after tests
Adoption rates usually follow a bell curve. QAs can drive higher adoption from day one. They can, for example, push for the most used features to be onboarded first. They can run before/after tests — this is where a specific functionality is repeated in both legacy and modern systems to identify gaps. This can be very useful in helping teams to understand why adoption might be low and to then take the necessary steps to address issues. It’s important to note that QAs must also have frequent catch ups with users to identify pain points, feeding information back to the wider business and development teams.
Retire subsystems quicker
The goal of any legacy modernization project is to retire the legacy system as early as possible. Being close to legacy systems, QAs are perfectly placed to identify the subsystems that can be easily retired and suggest onboarding these low hanging fruits first. They can actively contribute to devising the legacy subsystem retirement roadmap. By retiring subsystems quicker and more systematically, they can help save infrastructure costs as well.
Choose the right framework for automation
Many engineering teams fail to ensure that their automation system supports the legacy tech stack. This is a mistake; a good automation framework must support both the legacy and the modern system. When this doesn’t happen, QAs are often placed in the difficult position of having to write flaky end-to-end tests. To avoid this situation, QAs must actively participate in choosing the automation framework.
Also, since the legacy system is likely to have been running fine for years, QAs can stub the legacy system’s response as much as possible. This is useful as it means you won’t have to wait for slow interactions that are typical of many legacy systems and will instead have much quicker tests.
Strive for enablement as a by-product
Client delivery teams working on legacy tech stacks are unlikely to be familiar with the modernized application’s stack. QAs can — and should — actively pair with client teams to help them get acquainted faster. They can also facilitate enablement and training on early defect detection, kickoffs and devboxes.
Conclusion
In our experience, the above small, but impactful contributions by the QA will result in higher quality applications, quicker adoption, faster legacy system retirement, and delight for end-users, business teams and developers alike.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
