Business Inspection Process and Plan

1. Background

With rapid business iteration, the proportion of development self‑testing requirements and QA testing requirements is comparable. The quality of self‑testing requirements is hard to control, and as self‑testing demands increase, QA’s familiarity with the business may become fragmented.

Some business lines have become stable with few iterations, yet occasional legacy issues arise online, requiring developers to intervene urgently for operational colleagues.

As transaction volume grows, NPS becomes increasingly important; experience‑related problems severely affect user satisfaction and lower NPS, while good interaction design helps improve NPS and user retention.

To address these issues, regular business inspections are organized to enhance system availability, reduce online problems, and foster a user‑centric perspective that raises quality awareness among all participants.

2. Inspection Methods

Before organizing inspections, two questions were considered: how to encourage active participation and how to improve inspection efficiency. Different inspection formats were chosen based on business characteristics, illustrated with two representative services, referred to as Service A and Service B.

2.1. Service A

1) Business Flow

2) Business Characteristics

The workflow is relatively short and simple, with many front‑end interactive features.

3) Business Status

The overall service is stable, primarily operated, with infrequent iterations and minimal functional changes.

2.2. Service B

1) Business Flow

3) Business Characteristics

The workflow is complex and diverse, with each branch representing a distinct business logic.

4) Business Status

The service is in a rapid development stage, with short iteration cycles and frequent functional changes.

Considering the characteristics, Service A adopts a free‑form inspection to simulate user habits, while Service B uses case‑based inspections to ensure broader coverage of complex scenarios.

3. Focus Areas

The inspection concentrates on functionality, pages, and interactions.

Functionality: completeness of each feature.

Pages: full and unobstructed display.

Interaction: user‑centric evaluation of page and feature interactions, identifying optimization opportunities.

4. Inspection Plan

4.1. Define Inspection Scope

First ensure the accuracy of the main workflow, then divide the business into modules, delineate the inspection scope, and detail the functional aspects to be examined within each module.

The following diagram shows the module division and coverage scope:

After module division, specific preparations are made according to the chosen inspection method.

4.2. Pre‑Inspection Business Review

Service A

Although Service A uses a free‑form inspection, participants may not be fully familiar with all modules; therefore, a pre‑inspection business walkthrough is shared to deepen understanding.

Service B

Inspection cases for Service B are prepared in advance, providing test plans for each case to guide participants during the inspection.

4.3. Inspection Frequency

Weekly centralized inspections , lasting 1–2 hours, with QA, RD, and FE jointly participating.

4.4. QA Responsibilities

Two on‑duty QA engineers are assigned per inspection to answer case questions, record issues, and follow up on problem resolution and verification after the session.

5. Issue Recording

Issues are logged as bugs and assigned to the relevant developers.

Issue tracking monitors resolution progress and validates regressions.

Issue summarization periodically aggregates problem types, analyzes causes, and extracts lessons to inform future implementations and avoid repeated pitfalls.

Analysis shows that problems mainly stem from coding errors, user experience, product design, and system compatibility, with user‑experience issues concentrated on mini‑programs. Future reviews will emphasize product design rationality and strengthen mini‑program validation.

6. Gains

The biggest gain from inspections is role transformation: QA engineers ensure functional accuracy and completeness while also adopting a user perspective to evaluate product rationality. The team commits to continue regular inspections, treating them as the final quality gate before release.