Designing Test Plans for Operational Activity Projects

1. Background As business matures and shifts toward operation‑heavy, strategy‑driven models, the number of operational‑activity requirements increases. Through project accumulation and co‑creation with other teams, a set of test points and corresponding test solutions for operational activity projects has been gathered. This article introduces the design thinking and concrete content for creating test plans for such projects.

2. Test Plan Design

2.1 Design Thinking After requirement review, QA designs the test plan by considering preparation, testing methods, and special test points. The plan helps all parties understand the project rhythm, ensure complete test coverage, accurately assess work scope, clarify testing ideas, and prepare in advance.

2.2 Specific Content The test plan can be designed from the requirement, development‑integration, testing, and release phases, each with special focus points for operational activity projects.

2.2.1 Requirement Phase After the PM issues the PRD, QA reviews the following: (1) Clarify the activity’s purpose (acquisition, reputation, order promotion, retention). (2) Ensure the requirement content aligns with the purpose, e.g., acquisition methods, copy attractiveness, link functionality, frequency limits, etc. (3) Verify process completeness (entry → page → participation → reward → after‑sale). (4) Anticipate common test points such as login state handling and feature toggles.

2.2.2 Development & Integration Phase

(1) Interface Testing – Based on technical design documents, identify main‑flow interfaces and create test cases on an interface testing platform, including abnormal scenarios like login‑state errors, timeout, parameter errors, idempotency, and boundary values.

(2) Data Construction – Verify tool availability before testing; if tools are lacking and time permits, develop custom data construction for developer self‑testing and QA.

2.2.3 Testing Phase

(1) Preconditions

Activity timing – verify behavior and copy for not started, ongoing, and countdown‑ended states.

User identity – construct users who can or cannot participate via database or configuration changes.

Frequency limits – test scenarios below, at, and above limits; ensure front‑end entry disables correctly and back‑end logic behaves as expected.

(2) Activity Page

Sign‑in feature – test daily sign‑in,补签, and weekly reward upgrades by modifying DB/cache.

Share feature – verify opening pages on WeChat, Moments, QQ, Weibo, browsers; handle missing login info by clearing cookies; mock invite‑API success to check reward granting.

Prize winning – check prize configuration IDs, lottery flow (message, prize, decrement counters), and SQL verification of prize assignment.

Other – embed event tracking for each step, perform boundary tests (single click vs multiple clicks, low‑stock prize handling, consecutive activities), compatibility tests on Android/iOS and various screen sizes, and concurrency/pressure testing for high‑traffic scenarios.

2.2.4 Release Phase

Data analysis – collect, organize, and analyze online data after launch.

Effect evaluation – assess whether the activity met its expected goals.

Iteration decision – decide on further optimization based on results.

Post‑mortem – review the original objectives versus outcomes and identify strengths and improvement areas.

3. Summary By summarizing the test‑plan for operational activity projects, we not only revisit completed projects but also lay a foundation for future work, enabling QA to participate more fully across stages, improve project profitability, ensure quality, and boost testing efficiency.