A Practical Guide to Full‑Process Quality Assurance for Cross‑Department Projects

Background

The author has recently overseen several large, multi‑department projects with long timelines and overlapping roles, encountering common pitfalls such as missing requirement documents, shifting QA ownership, and inadequate technical design artifacts.

1. Requirement Phase

Obtain complete requirement documents before the review and prepare questions in advance.

Participate in the review with prepared questions, record conclusions, confirm final operational configurations, and request updated documents.

Establish a dedicated test communication group including all QA participants.

Track when other parties complete their requirement reviews to ensure alignment.

2. Design & Development Phase

Participate in external technical design reviews to clarify system interactions, data cleaning, and gray‑release plans.

Participate in internal reviews, demanding sequence diagrams for third‑party integrations before integration testing.

Determine and communicate test schedules by estimating effort per module and aggregating QA availability.

Collect and align QA schedules across parties, using shared documents to record timelines.

3. Integration & Smoke Testing Phase

Develop new data‑construction tools after interfaces stabilize, and integrate them into the data‑construction platform.

Attend integration stand‑up meetings to monitor progress and address critical issues early.

Begin core interface testing during the smoke phase to surface defects early.

Perform code diffs before sandbox testing to mitigate regression risks.

4. Testing Phase

Provision a unified test environment and a backup environment for debugging.

Provision a unified sandbox environment, ensuring all branches and configurations are deployed before testing starts.

Execute test cases according to module assignments, adjust plans when deviations occur, and track code coverage.

Conduct joint testing to validate end‑to‑end flows across all parties.

Log external bugs in the test group, create TODO items for unresolved issues, and escalate persistent problems.

Collect daily progress via stand‑ups or communication channels, highlight anomalies, and share summaries in the technical group.

Participate in release plan reviews, confirming rollout order, rollback procedures, gray‑release strategy, and configuration readiness.

Organize product and UI acceptance after functional stability is confirmed.

5. Deployment Phase

After all QA sign‑off, coordinate with technical leads to schedule the production release, confirming any deviations from the plan.

Validate production configurations before live testing to avoid dirty data; verify that only internal users are involved in gray releases.

6. Post‑Release Phase

Maintain a shared spreadsheet to record online issues, including description, expected result, reporter, status, assignee, resolution time, and issue type.

Conduct a post‑mortem in the project group, gather feedback, create actionable TODOs, and track their resolution.

Conclusion

In cross‑department projects, the test lead is responsible for planning, managing, executing, and analyzing quality activities throughout the lifecycle. Early involvement enables proactive defect detection, reduces downstream risk, and enhances the QA team’s value within the organization.