### Problem to solve <!-- What problem do we solve? --> Developers do not have an easy way to get the history of if a test has recently been passing, failing or skipped as they research a test failure in the context of a test run in an MR/Pipeline. Without this context it is hard to point at why the build is feeling/getting slower and what test 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 * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [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 * **Sasha:** When i'm reviewing a failed test, I want to know from the existing interfaces (JUnit report or Test Summary) if this test is flakey or not based on historic pass/fail rate so that I can save everyone behind be time by making a call to fix or disable the test ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> **Outcomes** * **Sasha**: When unit tests fail on an MR, I want to get historical context (see use cases) about failed tests, so that I don't feel like i'm stabbing in the dark to fix the build. 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: * JUnit reports generated - Target improvement of 5% within 30 days of release of the last feature * Page views of the report tab - Target improvement of 10% within 30 days of release of the last feature <!-- 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 research 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/).