Quality Assurance Strategies for Technical Improvement Projects

Technical improvement projects (referred to as "tech‑refactor projects") aim at technology upgrades or architectural changes rather than regular business feature updates. Common examples include large‑scale front‑end or back‑end refactoring, architecture upgrades, database sharding, data migration, cloud migration, and other non‑customer‑facing support projects.

These projects pose unique quality challenges because they modify underlying support layers while preserving existing business functionality, often focusing on non‑functional requirements. Teams may lack business context or awareness of non‑functional quality, leading to significant risk and defects that can disrupt stable operations.

1. Quality Challenges

Risks include under‑estimating effort, irreversible deployment failures, breaking existing stable features, impacting external integrations, schedule changes due to force majeure, and extensive rework caused by poor quality.

Under‑estimated workload or effort inflation, causing missed release dates.

Irreversible deployment with failure risk.

Damage to existing stable functionality.

Impact on external integration systems.

Schedule shifts caused by uncontrollable factors.

Significant rework due to low quality.

These risks are mapped onto a risk‑status matrix to define appropriate intervention levels.

Risk status matrix: early analysis, then step‑by‑step handling.

2.2 Building a Quality Protection Net

For large‑scale tech‑refactor projects, a robust quality protection net is essential. Well‑designed automated tests that can be run frequently form the foundation of quality assurance. Automated testing yields higher ROI when applied to scenarios with extensive regression needs, such as tech‑refactor projects, rather than frequent new‑feature development.

In addition to automated testing, manual gate‑keeping processes are required. Testers should treat each technical or task card like a user story, enforcing clear acceptance criteria and definition of done to ensure high‑quality outcomes.

Quality gate significance: preventing defect loops.

2.3 Designing for Irreversibility

Unlike regular feature releases that can be rolled back, tech‑refactor projects often cannot be reversed. Therefore, development, testing, deployment, infrastructure, and release activities must be designed for irreversibility and rehearsed in production‑like environments through multiple deployment simulations.

3. Maintaining Business Perspective

Technical improvements must not lose sight of business impact. Even non‑customer‑facing changes require business input to ensure continuity, data migration integrity, and supportability. Business stakeholders provide domain knowledge and non‑functional requirements such as traceability, fault tolerance, and high availability.

3.1 Business Input and Review

Business participants should review any change that could affect internal or integrated systems, ensuring a thorough understanding of background and risk before proceeding.

3.2 Risk‑Based Business Prioritization

Given limited resources, prioritize quality investment based on risk levels. The following diagram illustrates test design driven by business priority.

Automated test design based on business priority.

3.3 Early Business Integration

Integrate early by designing without mocks for internal services, identifying migration impacts, and conducting end‑to‑end validation to avoid costly rework later.

4. Technical Implementation Insights

4.1 Deep Dive into Technical Details

Because tech‑refactor projects maintain business continuity while altering low‑level components, testing must probe deep technical details to avoid hidden defects that appear correct on the surface.

4.2 Emphasizing Non‑Functional Requirements

Non‑functional requirements (also called cross‑functional or supporting requirements) describe system behavior or characteristics rather than specific business functions. — Wikipedia

Testing non‑functional requirements targets two quality goals: ensuring stable operation and supporting sustainable system evolution.

Operational quality: observable attributes such as security, performance, and availability.

Evolutionary quality: attributes related to maintainability, extensibility, and architecture.

Tech‑refactor projects must verify that changes do not compromise these non‑functional aspects and that stakeholder expectations remain aligned.

Examples of non‑functional requirement focus areas.

5. Lessons Learned

5.1 Avoiding 1+1<2

Tech‑refactor projects are often handled by senior engineers, creating management challenges. Teams must guard against endless technical debates, balance ROI with improvement efficiency, and ensure a sustainable workload for core members.

5.2 Maintaining a Global View

Projects should consider technical impact, business impact, external integration, current operational quality, and future architectural evolution, bridging technology, business, teams, and time horizons.

5.3 Importance of Business Knowledge Capture

Complex projects require diligent knowledge management and business context documentation to enable effective handover and reduce hidden costs during future challenges.

Play LEGO, learn agile – the "Utopia Plan" large‑scale agile collaboration sandbox will be held in Chengdu (May 28‑29, 2022) and Beijing (July 16‑17, 2022) as an open‑lab to embed multi‑team agile collaboration into development processes and boost efficiency.

Both enterprises and individuals can register to join the challenge.