New responsibility to submit test coverage requests to QA Wolf after each sprint (#31356)

handbook/engineering/README.md

@@ -205,6 +205,17 @@ If code changes are found for any `fleetd` components, create a new release QA i
 Once a product group completes its QA process during the release candidate period, its QA lead moves the smoke testing ticket to the "Ready for release" column on their GitHub board. They then notify the release ritual DRI by tagging them in a comment, indicating that their group is prepared for release. The release ritual DRI starts the [release process](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/workflows/releasing-fleet.md) after all QA leads have made these updates and confirmed their readiness for release.
 
 
+### Submit test coverage requests to QA Wolf
+
+Fleet QA owns the test planning process and identifies what needs to be automated. After each sprint, we review merged PRs, release notes, and demo recordings to find new automation candidates.
+We track these in a shared [Google Doc](https://docs.google.com/document/d/1jr8wxZZNTvcAB2IMOrsqY4NTW4eceX-3CABiYKpb_pY/edit?usp=sharing) and categorize them as:
+- New test requests (feature + what to test)
+- Existing tests to update
+
+Once coverage is agreed on, Fleet QA submits the request via [QA Wolf’s Coverage Request form](https://app.qawolf.com/fleet/coverage-requests). The most recent sprints are prioritized first.
+This workflow lets QA Wolf focus on test implementation while Fleet QA stays accountable for identifying clear, high-value test needs
+
+
 ### Prepare Fleet release
 
 See the ["Releasing Fleet" contributor guide](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/releasing-fleet.md).