Rapid Onboarding and Testing of After‑Sales Business: A Two‑Week Experience

Background

When there are many business tasks and insufficient manpower, colleagues may need to temporarily support different businesses, with varying time requirements; the first step is often the most concerning. This article shares real cross‑business testing experience (order‑business testers testing after‑sales) and explains how to quickly get up to speed with after‑sales testing within two weeks.

Before switching business, I worked on the transaction order promotion and recovery business, so I briefly introduce the order business to understand the relationship between orders and after‑sales.

The order domain covers a wide range of scenarios, from adding items to the cart, confirming the order page, placing the order, to both forward and reverse order processes. It interfaces with B2C, C2C, B2B, POP, 3C externally and with core services such as product, payment, logistics, warehousing, and after‑sales internally. Through daily testing, I have gained some familiarity with after‑sales backend operations, providing a basic foundation for testing after‑sales.

Before Starting

1. Think about the testing direction

Before moving to another business, clarify the main testing focus. Since each large business contains many small modules, a single person cannot master everything in a few days; set small goals, tackle them one by one, and gradually understand the whole business.

2. Understand the business scope

The first step is to grasp the business system, which can be challenging. The easiest way is to review business documentation and flowcharts, then explore the directory structure to become familiar with related components.

3. Hands‑on experience and divergent thinking

When I knew I needed to test after‑sales, I first built a mental map of the after‑sales process, similar to a system module diagram. For B2C after‑sales, I visualized the major steps and the systems involved.

Core B2C After‑Sales Process

1) Select a phone on the app, place an order, and obtain an order number after payment.

2) After shipment, the “apply after‑sales” button appears; the user can apply for after‑sales or cancel, generating a new after‑sales number, establishing a one‑to‑many relationship between order and after‑sales numbers.

3) Customer service claims the after‑sales ticket and performs verification; if the product is not yet shipped, they may close the order and refund, otherwise they approve the after‑sales request.

4) Customer service notifies the user to ship the item and creates a delivery order, linking logistics information.

5) The product arrives at the after‑sales site, staff scan and receive it, generating a tracking document and a quality‑inspection record for each item.

6) After responsibility determination, a resolution plan is confirmed, handling the ownership of money and goods.

7) Upon completion, the order is updated (closed, refunded, repaired, etc.).

8) Finally, the after‑sales item is transferred to the quality‑inspection warehouse.

These steps form a closed‑loop operation.

Below is a diagram of fast refund versus normal after‑sales refund flow.

By experiencing each step in the app, you can also think divergently—for example, non‑B2C after‑sales may involve third‑party approval, or users may cancel after‑sales, requiring order closure and logistics restoration. Understanding the overall flow enables you to navigate complex, changing requirements efficiently.

In Progress

When a requirement arrives, analyze it based on the project’s overall flow, focusing on differences. As a QA, I split requirements into two categories:

1. Reuse‑Pattern Requirements

Review historical documentation and iteration records, including UI designs.

Examine existing test cases for similar features, learn from past pitfalls, and gather environment and data setup information.

Identify original bugs to know where defects are likely to appear.

Check configuration and compatibility aspects using previous technical documents to reduce troubleshooting time.

2. New‑Requirement Integration

Identify differences, such as whether the after‑sales process involves warehouse receipt or not, and how backend data storage varies.

Understand technical implementation by consulting developers, asking about potential workflow blocks or data anomalies.

Clarify goals, create a step‑by‑step plan, and prepare test plans accordingly.

Conclusion

Changing business domains only changes the business context; our existing experience applies across domains. By breaking tasks into modules and assembling them according to requirements, you can quickly become familiar with and master a new business.

Remember to have confidence in yourself!

Want to learn more about ZhaiZhai’s technical practices? Follow the public account below!