How to Define Clear Testing Boundaries for Large-Scale Projects

1. Introduction

For simple projects, test boundary division is straightforward, but in complex, multi‑team projects boundaries become fuzzy. This article shares experience from the “Ershi Warehouse Store” project on how multiple testing teams can quickly align on test boundaries, supported by data‑driven tools.

Key pain points in large‑scale testing include numerous systems, complex interactions, many participants, and information gaps. QA must understand each business line’s background early, perform requirement analysis, and grasp the systems involved.

Test boundaries are essentially the interaction relationships between business lines. Early accurate boundary definition and dependency consideration (e.g., MQ messages, API responses) are crucial.

2. Test Boundary Division Methodology

For medium‑to‑large “zero‑to‑one” projects, detailed boundary definition is vital. The following methods are derived from practice.

2.1 Boundary Division Based on Business Process

QA draws an end‑to‑end business flow diagram to identify each system’s responsibilities and interaction points, then marks the test boundaries.

Draw End‑to‑End Business Flow Diagram:

List all systems and processes, clarify each team’s responsibility and hand‑off points.

Identify interaction methods such as data flow, API calls, MQ messages.

Align dependencies in scheduling and test plans to ensure pre‑conditions are met.

After clarifying interaction methods, we further break down dependencies, confirm boundaries with system owners, and continuously track tasks. The following diagram illustrates the analysis.

Example interactions:

(1) System A → System B

Interaction: MQ + API calls

Data Flow: System A pushes data asynchronously via MQ and synchronously via API.

Function: System B updates its data (e.g., order status) based on received information.

Typical Scenario: System A triggers order creation, System B syncs order data.

(2) System B → System C

Interaction: API – Business logic; System B submits processed data to System C, triggering core logic such as risk control or inventory deduction.

Dependency: System C’s response may affect System B’s subsequent flow.

(3) System C → System A

Interaction: MQ + status return API

Status Sync: After processing, System C notifies System A of final status via MQ or API.

Data Closure: Example – System C completes inventory deduction, then System A updates order status to “shipped”.

Summary: By mapping three‑way system interactions from a business‑process perspective, teams can align capabilities and tools, making the core workflow clear.

2.2 Boundary Division Based on Business Details

Beyond overall flow, detailed interaction points must be clarified to avoid missing critical functions such as product price changes, status updates, or accessory information. Business owners need to provide data‑construction capabilities to ensure full test coverage.

3. Results and Lessons Learned

In the Ershi Warehouse Store project, the above boundary‑division approach achieved:

100% test‑point coverage during formal testing, with no blocking issues caused by unclear boundaries.

Clearer team collaboration, with each business line paired with dedicated QA and data‑construction support.

Improved familiarity with inter‑business interaction logic, boosting issue‑resolution efficiency.

Key Takeaways:

Boundary definition is critical for medium‑to‑large projects and should be introduced early in requirement analysis.

During boundary‑review meetings, each business line must present detailed process walkthroughs to clarify responsibilities and sharpen system boundaries.