<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ### Problem to solve <!-- What problem do we solve? --> Team leads do not have an easy way to get historical data about unit tests from their project like if it failed the last time it ran, or how many times it's failed in the last 10 executions, how fast did it run, etc. Without this context it is hard to point at why the build is feeling/getting slower and what use cases may to be blame for that. Without that context it's not hard to imagine Delaney and Sasha starting to skip tests and not write tests for new code. ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> #### Use Cases * **Delaney:** I want an at a glance dashboard that highlights trend of quality in a project and links into test data so I can get my team to find out what's up and report back. * **Delaney:** I want to know how the % of tests passing, failing and skipped in the project is changing over time, so I can ensure we have good code coverage. - Issue: TBD * **Delaney:** I want to see how the time to run tests (all of them, a suite, a test) is trending over time, so I can make sure our project's pipeline is staying fast. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> **Outcomes** * **Delaney**: When I hear that builds are slowing down, I want to get historical context (see use cases) about failing unit tests, so that I can confidently coach my team on how to make it better. Proposals are listed in the individual items that address these problems. ### What does success look like, and how can we measure that? This epic will be successful if more instances are generating test data AND viewing the test reports / Test Summary Widget. This will be measured by: * Views of the Report Page <!-- 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? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> This feature is applicable to individual developers who are trying to trouble shoot failed tests in a build. ### Links / references This issue originated in [discussion](https://gitlab.com/gitlab-org/gitlab/issues/23257#note_215179311) of gitlab#23257 which was deemed a duplicate of gitlab#24792 which was assigned to a milestone earlier. Historically we have heard from customers/prospects who use Jenkins that this is possible with a simple [Jenkins plugin](https://plugins.jenkins.io/test-results-analyzer/).