R&D Management 12 min read

Effective Project Test Retrospective: Insights from a Large-Scale Rendering Project

This article shares practical steps and key insights for conducting a project test retrospective, covering purpose clarification, mindset adjustment, documentation preparation, meeting facilitation, feedback collection, and lessons learned, illustrated with examples from the KE offline rendering cloud map project to help teams improve quality processes.

Qunhe Technology Quality Tech

Apr 26, 2024

Effective Project Test Retrospective: Insights from a Large-Scale Rendering Project

Background

As the KE offline rendering cloud map project approached its end, the testing committee requested a project test retrospective. Unlike a general project retrospective, a test retrospective focuses on the quality process and aims to produce documentation that benefits personal growth and team knowledge.

Clarify the Purpose of the Retrospective

Before starting work, two points must be noted:

Define the purpose – focus on key problem improvements. A retrospective discovers problems and seeks solutions, but when many issues exist, multiple rounds may be needed. Prioritize high‑ROI problems such as frequent requirement changes or tight testing schedules.

Adjust the mindset – stay objective and avoid blame. Some members view retrospectives as a waste of time or fear accountability. The process should be rational, focusing on issues rather than individuals, and aim for procedural improvements.

Conducting the Project Test Retrospective

3.1 Prepare the Retrospective Document

Because team members are busy, I explained the benefits of the meeting in advance to encourage participation. Test members were required to join, and developers and product staff were invited optionally. I collected relevant data using the template provided by the testing committee (see image below) and filled in the project‑related testing information before asking others to supplement.

The retrospective document consists of the following modules:

Project Overview: background, goals, and outcomes, usually compiled by the project manager.

Quality Process Review: analysis of each phase (requirement analysis, test planning, test execution, release control) from a testing perspective, highlighting strengths, weaknesses, and actionable improvements.

Quality Analysis: metrics such as workload, bug count, recurring issues; for this project, many visual‑effect problems were identified.

Outcome Summary: team members' takeaways and a concise summary of the retrospective results.

3.2 Hold the Retrospective Meeting

During the meeting we encouraged everyone to speak openly to uncover problems and discuss solutions. Even quieter participants received prompts. Typical issues raised included:

Information gaps and misaligned cognition: later‑stage consensus that material‑effect issues were acceptable because the next phase would focus on streaming rendering, yet this was only communicated within the technical team, causing some members to question project success.

Lack of risk awareness: certain blocks were tackled privately without informing the testing committee, missing opportunities for collective problem‑solving.

Inconsistent acceptance criteria: designers on the cloud side had different expectations from those on the cluster side, leading to subjective effect validation.

To address these, I added a “Risk Items” column to the weekly template, encouraging direct contact with the responsible tester for any block.

3.3 Collect Feedback

After the meeting, participants were asked to evaluate the testing lead. The committee aggregated the feedback, analyzed it, and fed the results and improvement suggestions back to the testing lead. The closed‑loop process provided a clear view of project performance, with feedback such as:

Some members felt testing boundaries were clear but called for more comprehensive test specifications and collaboration processes.

Most members praised the testing lead’s ability to identify risks early and follow up on solutions.

Many appreciated the timely release planning but suggested better utilization of the plan to ensure smooth launches.

Communication and coordination were generally good, though daily sync could be improved.

Overall satisfaction with the testing plan and方案 was basic to satisfactory.

Reflections

Repeated retrospectives help accumulate experience in handling large‑scale projects. Some practical tips include:

Document the testing process actively; otherwise, reviewing later becomes difficult.

The testing lead’s role overlaps with project management: beyond quality and schedule, strong communication and issue resolution are essential.

Integrate existing problem‑location capabilities across teams to boost overall debugging efficiency.

Ensure information synchronization; weekly meetings may not have full attendance, so critical items must be confirmed individually to maintain team consensus.