Clarify and document how test plans are to be used
In a test plan issue @victorwu asked:
Has there been guidelines on how these test plans will work for GitLab? Or are we just starting this fresh and the process will evolve? If you have any handbook links that explain the process, please do share them and I can definitely take a look and help in any way.
Is the purpose of this issue to capture only automated tests you will be creating? How about any manual testing that should be done? Should that be managed here or elsewhere? We have the QA issue (e.g. gitlab-org/release/tasks#381 (closed)) and FA issue (e.g. gitlab-org/release/tasks#303 (closed)) monthly as well. So wanted to make sure we were doing things per your guidance.
The aim of this issue is to have a place for further questions like those and to gather the information needed to answer them.
Should the role of test plans be documented in the Quality team's handbook page? Or should it be included somewhere in the release documentation? Or both?
Do we have anything documented somewhere else already?
Regarding QA release issues, I expect test plans could be used by developers performing the tests. So while QA release issues list the MRs that need to be tested, a test plan could be used by a developer to double-check that appropriate tests are done. The test plan should help the developer identify/remember cases that they might not otherwise, without leading them to forget/ignore tests that they would have done without the test plan. Does that work with how the QA issues are used currently?
As for FA issues, they're not about quality assurance:
This is not about quality assurance (QA), as developers are responsible for the quality of their code. This is about feature assurance (FA). Feature assurance is necessary because sometimes there are misunderstandings between the original issue proposal and the final implementation.
Does that mean test plans aren't relevant to FA tasks? Or would it make sense to use test plans during FA tasks as well, since a test plan includes details about how the feature is expected to behave (i.e., its Capabilities as in the ACC model)
/cc @gl-quality