Merge branch 'jreporter-master-patch-03070' into 'master'

Update Testing Weight Process

See merge request gitlab-com/www-gitlab-com!96826

development/ops/verify/testing/index.html.md.erb

@@ -18,8 +18,6 @@ The Verify:Testing Group provides automated testing integration into GitLab. We
 
 * [Code Testing & Coverage](/direction/verify/code_testing/)
 * [Performance Testing](/direction/verify/performance_testing/)
-* [Usability Testing](/direction/verify/usability_testing/)
-* [Accessibility Testing](/direction/verify/accessibility_testing/)
 * [Build Artifacts](/direction/verify/build_artifacts/)
 * [Review Apps](/direction/verify/review_apps/)
 
@@ -113,6 +111,8 @@ We use a [release planning issue](https://gitlab.com/gitlab-org/ci-cd/testing-gr
 #### Issue weighting and refinement
 Before issues can be moved from the Planning Breakdown stage into the Ready for Development stage, they must have a weight applied. We use [this table](https://about.gitlab.com/handbook/engineering/development/dev/create/source-code-be/#weights) to decide what weight an issue should have. We follow an asynchronous refinement process in lieu of a synchronous refinement meeting. This helps us be more Inclusive and work more asynchronously. Engineers should take time each week to review the issues that are in [Planning Breakdown](https://gitlab.com/groups/gitlab-org/-/issues?label_name%5B%5D=group%3A%3Atesting&label_name%5B%5D=workflow%3A%3Aplanning+breakdown&scope=all&sort=milestone&state=opened&utf8=%E2%9C%93) for the next milestone and see what they can do to better refine and weight those issues.
 
+The Product Manager and Engineering Manager will use milestone planning issues to identify issues that need to be weighed in advance of the target milestone. We would like to give engineers one full milestone to refine and weight the issues. 
+
 #### Design issues and SSOT
 There may be times in which an issue requires a new design proposal. When those issues are also labeled as `~direction` items we create a separate design issue for them for the Product Designer to work through. The reason for this is to be as accurate as possible in displaying on the [Upcoming Releases page](https://about.gitlab.com/upcoming-releases/) when the feature will be implemented.