<!-- The first three sections: "Problem to solve", "Intended users" and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve Users would like to be able to manage testing in a more integrated way within GitLab. This include organizing their testing into logical groupings, and understand what tests exist. ### User experience goal The user should be able to define a structured test approach within GitLab and execute to that approach fluidly, using existing and familiar constructs. ### Intended users **Software Engineer in Test - SET** > As a test engineer, I need to be able to organize my tests in logical ways such that I can easily understand the completion status and pass / fail status. > As a test engineer, I need to be able to define a test case (set of test steps with defined pass / fail criteria) which can be run against the product. **Release Manager** > As a release manager, I need to be able to have a single source of truth for test results for for the current release to determine if the version is ready for deployment. ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> ### Definitions **Test Case**: A set of steps by which testing occurs, with a defined pass / fail criteria **Test Run**: An instantiation of a **test case** which is run. A single **test case** can be the basis for numerous **test runs**. ### Proposal Create an MVC for Quality Management that will allow users to create test cases in a natural format. This will consist of two primary items: 1. Build on top of the [extensible issue](https://gitlab.com/groups/gitlab-org/-/epics/3354) work being performed and create a new issuable type for test cases. This will allow users to work within GitLab in a natural way to generate test cases. ([Implementation Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/233479)) 1. Based on the output of configured pipelines, create a Test Session issue which will contain the test results for that particular test session, pass / fail status and discussions surrounding the test session. ([Implementation Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/233520)) ### Permissions and Security Need to ensure that proper application limits are put in place so people cannot create a huge configuration file and easily spam issues ### Documentation This will be the MVC for Quality Management, so will therefore require documentation as follows: - Define what quality management is to our users - Document the above feature ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### What is the type of buyer? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->