Test Plan Writing Practices for OMS System: A Step-by-Step Guide

1. Background

The project standard requires a test plan for any project with a schedule longer than three days. Based on surveys and the complexity of requirements or technical implementation, a test plan is also prepared for more intricate cases.

I am responsible for testing the OMS (Order Management System), a critical node in the fulfillment flow that manages order data and connects users with fulfillment processes. Because the system heavily influences overall business flow, its processes must be clearly understood and quality strictly ensured.

2. Writing Method

While most colleagues start their test plans after the technical design review, I begin after the requirement review and continuously refine the plan during subsequent technical design and review stages.

2.1 First Stage: Before Requirement Review

Understand the demand: review background, goals, and design. Identify unclear points such as second‑phase plans, temporary solutions, reusability, missing business steps, boundary clarity, system positioning, and process completeness.

2.2 Second Stage: During Requirement Review and Technical Design

After Requirement Review:

Fill in the test plan with project background, objectives, and clear requirement information.

Communicate to confirm whether the change involves multiple systems and identify responsible owners.

Draw an initial process diagram from a QA perspective, noting any questions.

During Technical Design:

Refine the process diagram by discussing discrepancies with developers to avoid blind design.

Clarify requirement boundaries, milestones, dependencies, and data preparation needs.

Coordinate test rhythm with other systems to plan test schedules and strategies.

2.3 Third Stage: After Technical Design

Clarify configurations, database schema, and workflow implementation; update the test plan accordingly.

Confirm that the final process diagram matches the implementation.

Validate multi‑system interaction order and dependencies.

Verify configuration items (e.g., Apollo, page settings) and sandbox readiness.

Review database design for impact on online flow and data; schedule large‑scale SQL changes with operations.

Check interface changes for added or removed fields, ensuring callers upgrade jars to avoid null‑pointer issues.

2.4 Fourth Stage: Before Test Plan Review

With all designs clarified, coordinate with QA leads of related systems to finalize ambiguous sections of the draft test plan.

Identify data construction dependencies.

Define cross‑system interaction scenarios and responsible parties.

Assess impact of other systems' test schedules and adjust own plan if needed.

Specify deliverables to other systems and expected timelines.

2.5 Fifth Stage: Test Plan Review

Conduct the test‑plan review on the same day as the technical‑design review to capture the requirement “heat,” align perspectives, and clarify the next steps and project rhythm.

Key Takeaways

Follow project regulations: write test plans for projects exceeding three days.

Use the test‑plan template to detail milestones, schedules, and risk mitigation.

Maintain close alignment with product and development to ensure the system stays business‑centric and quality‑driven.

By adopting these habits, I aim to be not only a QA specialist but also a bridge between product and technology, safeguarding system quality and project cadence.