Game Product Quality Management – Theory and Practice

This article starts from the theoretical definition of quality management and discusses the author's understanding of game project quality management. It categorises daily QA work according to quality‑management theory, shares real‑world problems encountered in projects, and presents practical solutions.

According to the TQM system, project quality requires the participation of all team members. Senior management sets the quality tone, the project manager is responsible for overall quality, functional managers ensure the effectiveness of the quality system and policies, and each team member is accountable for the quality of specific project activities.

The author emphasizes that management responsibility accounts for about 80% of quality issues. For example, a large number of configuration bugs can be mitigated by establishing a robust table‑check mechanism, but its success depends on promotion within the team and joint enforcement by test and design leads.

Key practical measures include:

Strict commit quality: Hold contributors accountable for submissions that cause blocking issues, foster a quality‑aware culture, and create an internal incident repository with analysis and post‑mortem.

Establish regression mechanisms: Perform daily manual BVT (basic verification testing) to ensure a usable build each day and conduct simple build checks to catch blocking problems early.

Define testing cycles: Introduce version concepts (daily, weekly) and enforce lock‑down points for requirements and releases, using branch control to separate development, testing, and release streams.

Additional challenges addressed:

System independence and coupling: In large MMO projects, responsibilities can become unclear; the solution is to instill a product‑quality mindset across the QA team and ensure clear ownership of issues.

Efficiency‑oriented problem solving: Assign issues to the most efficient resolver based on experience, responsibility, and communication skills, rather than following a rigid, module‑based assignment.

Avoiding “kick‑the‑ball”: Use group discussions and clear leadership to drive issue resolution instead of passing problems between individuals.

For new processes that struggle to be adopted, the author recommends thorough communication (e.g., project‑wide emails, meetings), obtaining consensus, and archiving the standards for future reference.

Applying the PDCA (Plan‑Do‑Check‑Act) cycle continuously ensures that process improvements are verified and refined over time, turning each retrospective into a practical PDCA loop.

Finally, the article highlights the importance of regular retrospectives—weekly demos, milestone reviews, and systematic post‑mortems—as vehicles for continuous improvement and knowledge sharing within the team.