How to Write a Test Plan | QA Best Practices from an OMS Expert

Source: TesterHome Community

Background: Why a Test Plan Matters

The project specifications at my workplace require that a test plan be prepared for any project with a testing schedule longer than 3 days.

Based on a survey of colleagues, in addition to following this process, we also create test plans for requirements with complex logic or intricate technical implementations.

Personal Context:

I (the author) am primarily responsible for testing the OMS (Order Management System).

This system is a crucial node in the entire fulfillment process. Its role is to manage order data during fulfillment.The system acts as the link between users and the fulfillment capability process, serving as the core for the transfer between orders and fulfillment.

Given the system’s significant impact on the overall business process, I must have a clear understanding of its process structure and ensure its quality is strictly guaranteed. Drawing from my personal perspective and experience, I’d like to share some of my small habits for writing test plans.

01 The Approach to Writing a Test Plan

Everyone has a different approach. Based on feedback from team members, most begin their test plans after the technical design review.

However, due to system characteristics, my familiarity with the system, and personal writing habits, I start writing my test plan immediately after the requirements review, and then continuously refine it during technical design and subsequent reviews.

Phase 1: Before the Requirements Review

Goal: Preliminarily understand what the requirements are.

• Product managers share requirements in advance.
• I proactively review the requirement background, goals, and design.
• I look for unclear areas, such as:
  • Is there a phase two?
  • Is this a temporary or permanent solution?
  • Is it generic? Are there missing business processes?
  • Is the requirement boundary clear?
  • Does the functionality align with the system’s positioning?
  • Is the process complete and reasonable?

Key Action: Bring these questions to the requirements review. This helps analyze requirements and clarify fuzzy business details beforehand. Aim to confirm as much as possible during a single review session.

Phase 2: After the Requirements Review, During Technical Design

Step 1: After the Requirements Review

1. Fill in the test plan template
2. Add confirmed information from the requirements level, such as project background and objectives.Initial communication
3. Identify whether changes involve multiple business systems. Communicate upfront to clarify boundaries and identify owners of related systems. This allows for quick identification of responsible parties.Clarify the process and draw the initial flowchart

Draw the requirement flow from a QA perspective. For processes, I prefer to re-draw them myself.

Why drawing your own flowchart matters:

Initially, I thought using the product manager’s flowchart would suffice. That changed during a test plan review when a PM joked, “You just copied my flowchart.”

Driven by ownership, I drew it myself.

Discovery: A PM’s flowchart has “blind spots” for QAs. For example:

• State transitions may not be clear enough.
• Logical handling may not be detailed enough.

Drawing the flowchart allows you to thoroughly understand:

• Business flow
• Logical handling
• Outcomes in different scenarios (from a QA testing perspective)

Step 2: During Technical Design

1. First refinement of the flowchart

After completing the initial flowchart, issues often arise:

• Differing understandings of state transition implementation
• Discrepancies between expectations and implementation

Action: Discuss issues with developers and continuously refine the flowchart.

This process bridges the gap between business requirements and technical implementation, acting as an oversight mechanism.

Use the business perspective to guide technical implementation and prevent blind design that leads to rework.

2. Further communication and preliminary clarification

Examples of timeline-driven strategy:

• If a dependent service hands over late → related test tasks should be scheduled later.
• If an upstream service depends on my service and timelines align → cover end-to-end scenarios starting from upstream.
• If upstream hands over late → perform interface testing myself.
• If my service is depended on by multiple systems → complete internal testing early to avoid impacting others.

Benefit: Proactively flag risks related to strong dependencies and significant timeline differences.

Phase 3: After Technical Design

Get clarity on:

• Configurations involved
• Database designs
• Process implementations

Perform a secondary check of the functional implementation plan and update the test plan content accordingly.

Key Confirmation Areas:

1. Process logic

• After technical design review, re-validate whether the flowchart matches the implementation.
• For multi-party interactions, confirm functional and sequence dependencies.

2. Configuration confirmation

• For configurations like Apollo or page setups that impact online processes, confirm with product and development.
• Perform sandbox verification.

3. Database design concerns

• Does the DB design affect online processes or data?
• For field changes on large-scale data tables (must run at night): remind the developer to execute SQL the day before sandbox to avoid delaying validation.
• For state machine changes (critical for OMS): after sandbox deployment, the service cannot be restarted online (risk of failure to start). Communicate with operations beforehand. Requirements with simultaneous changes cannot be merged for online deployment.

4. Interface changes

• Identify if fields in existing interfaces have been added or removed.
• If yes, clarify all callers and confirm if all will upgrade JAR packages simultaneously.

Example risk (adding a field): If the field includes validation logic and a caller hasn’t upgraded the JAR, the field will be null, potentially causing null pointer exceptions. Plan for compatibility regression testing.

Phase 4: Before the Test Plan Review

At this point, requirement design and technical design should be clear to all parties.

Finalize details with the QA leads of each related system, refining any ambiguous parts of the draft.

Checklist:

• Any dependencies for data construction?
• For system interaction scenarios: who leads and who observes the related test cases?
• For dependencies on other systems: assess impact based on their test handover timelines → determine if my test plan/strategy needs adjustment.
• What do I need to provide to other systems, and what are the expected deadlines?

Phase 5: The Test Plan Review

Personal scheduling rule:

I schedule the test plan review on the same day as the technical design review.

Why? While the requirements are still fresh, it is easier to align perspectives and unify timelines and points of divergence. This makes the project rhythm clearer for everyone.

02 Evolving Focus Points in Test Plan Writing

Truly understanding the content of a test plan revealed that our company’s template incorporates the unique characteristics of each system. It acts like a detailed checklist, reminding us to consider factors we might otherwise overlook.

Here is how my mindset evolved over time:

Stage 1: Following the Rules

Approach: Initially wrote test plans solely to comply with the project specification (>3 days). Filled in the blanks without truly understanding the “why.”

Discovery: After writing a few, I realized that the test schedule section helps break down and refine timelines. Understanding milestones from the test schedule perspective helps in logically planning the testing cadence.

Focus: Project Milestones, Project Plan

Stage 2: Broad Research – Know Yourself and the Enemy

Trigger: As OMS began incorporating various business lines (snacks, stores, etc.), I started proactively focusing on:

• System test boundaries
• Handover nodes in multi-system deliveries
• System contacts
• Implementation and dependency order of related systems

Value: This information proved vital during multi-system collaboration. It allowed for faster issue identification, assignment to the correct system/contact, and quicker troubleshooting. Understanding my own business better reduced blind spots regarding other systems.

Focus: Requirement Boundaries, Requirement Decomposition, Multi-system Contacts, Preparatory Work

Stage 3: Clear Strategy

Realization: Arranging testing methods is as crucial as devising a battlefield strategy.

Triggering example: During an OMS internal technical optimization requirement (inventory model adjustment – no external business impact but massive internal structural changes).

Actions taken:

• Deep understanding of technical design
• Refining test plan sections: rollout strategy, configuration, testing strategies, methods
• Confirming regression scope, impacted systems, and regression leads (upfront communication)

Goal: Minimize risk, continuously correct areas needing confirmation, ensure quality.

Focus: Technical Design Process, Test Strategy, Testing Methods, Configuration & Verification Items

Stage 4: Staying Close to the Business

Insight: Truly understanding a system means staying close to the business.

Key elements:

• System positioning
• Development direction
• Future plans

Application: For major requirements, analyze the design based on:

• Business direction
• Long-term goals
• System positioning
• Potential for long-term iteration

Principle: Pay close attention to requirement goals, backgrounds, and implementation – essential for effective quality control. Business must always be the project’s prerequisite.

Focus: Project Background, Project Objectives

03 Conclusion

I aspire not only to be a QA, but also a liaison who connects product and technology.

I want to help both technical and business teams get closer to the business, and I hope product managers can understand the system from multiple dimensions.

While safeguarding system quality, I also strive to be a dependable guardian of the project schedule.

These are some of my personal habits – a small share from me.