### Problem to solve <!-- What problem do we solve? --> This issue tackles a sub-scope of https://gitlab.com/groups/gitlab-org/-/epics/1875 and it focuses on the problem of users not being able to find out about the full scope of their tests per pipeline making it hard to look back at test runs to fix failed ones, know if it is required to do so and having to dig through console logs to do this which is time consuming. Additionally, any current test functionality relies on merge requests being used, making it very hard to surface this information if working from just a branch. **For Developers or DevOps Engineers:** When tests in my CI fail, I want a view of the aggregate test results that I can drill into, so that I can save time finding and fixing errors. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> - [Sacha - Software developer](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) - [Devon - DevOps engineer](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> This item moves us forward in our Maturity Plan for Code Quality by moving the CI Views epic forward. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> This issue will focus on the scope of: > An artifact-based view to see the amount of tests vs failed for pipeline pages. This will gather cross job test information and collectively shows it, including metadata. Preferably this view will be flexible and thus usable beyond just Junit. It is, however, acceptable for an MVC to start off with a single format if need be. #### Mockups/wireframes [:gem: __Specs__](https://gitlab-org.gitlab.io/gitlab-design/hosted/dimitrie/24792-junit-spec-previews) ##### Test suite list view | Desktop | mobile `<768px` | | ------ | ------ | |  |  | ##### Test suite detail view (detailing the individual tests) | Desktop | mobile `<768px` | | ------ | ------ | |  |  | #### Data Summary: * Total jobs * Total failures * Total error rate * Success rate * Visual progress bar indicating total/failed * Total time Test suites table: * Suite name * Duration * Failed * Errors * Skipped * Passed * Total Test table: * Class name * Test name * Status * Trace * Duration #### Navigation You'll be able to click a test suite row to inspect it similar to this [example](https://youtu.be/BsU-DjBx-DQ?t=281). This way you'll be able to dive into a test suite to all the individual tests in there. If tests are failed they will be sorted on top automatically and will show a track trace. ##### Animation If possible I'd like to reinforce the back button navigation paradigm with a small animation. When the user clicks the row and we dive into a test suite, the content shifts left. Upon navigating back it will shift back right again. Can you let me know if this is feasible?  ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? 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? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### 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. --> * We will track page views on the test suite detail view to determine the usage of this feature. ### Links / references